Scrum Takımı, Tamamlandının Tanımını ne zaman hazırlamalıdır? Scrum Kılavuzu bununla ilgili herhangi bir bilgi vermez, sadece bunun var olması gerektiğini ifade eder.
Bunun nedeni, Scrum’ın bir çerçeve olmasıdır. Adım adım ne yapmanız gerektiğini açıklayan bir metodoloji değildir.
Peki, bu durumda, Tamamlandının Tanımı ne zaman oluşturulmalıdır? Cevap, ne zaman isterseniz.
Çoğu zaman, insanlar her şeyin Scrum etkinliklerinden birinde olması gerektiğini düşünür ve bu doğru değildir.
Scrum Takımı, kendi içinde belirsizlikleri giderecek şekilde farklı toplantılar yapabilir. Bu, Scrum tarafından yasaklanmış değildir.
Scrum Takımının, ilk Sprint başlamadan önce Tamamlandının Tanımının ilk versiyonunu hazırlanmasında hiçbir sakınca yoktur. İlk hali, mükemmel veya nihai olmak zorunda değildir.
Zamanla ihtiyaçlar şekillendikçe veya kalite sorunları yaşandıkça, tamamlandının tanımı da gelişir. Özellikle, Retrospektif toplantılarında ekip deneyimlerini paylaşarak, Tamamlandının Tanımını iyileştirmek için önerilerde bulunabilirler.
Pratik açıdan bakıldığında, zorunlu olmadıkça, sprintin ortasında Tamamlandının Tanımını değiştirmek çok tercih edilen bir yöntem değildir. Bunu bir oyunun kurallarını oyun başladıktan sonra değiştirmek gibi düşünebilirsiniz. Kurallar, oyun başlamadan önce belirlenir. Eğer istenmeyen bir sonuç ile karşılaşılırsa, kurallar, oyun tekrar başlamadan önce oyuncular tarafından konuşulur, anlaşmaya varılır ve oyun ondan sonra başlar.
Tamamlandının Tanımını Sprint’in ortasında değiştirmek tahmin değerlerini ve tamamlandığı düşünülen işleri olumsuz etkileyebilir.
Bu derste, tamamlandının tanımı ifadesine biraz daha detaylı göz atacağız. Bir önceki videomuzda “Başlangıç Sayfası Oluşturma” öğesi için kabul kriterlerini tanımlamıştık.
Burada gördüğünüz ifadeler ise “Başlangıç Sayfası Oluşturma” adlı ürün birikim öğesi için daha detaylı hazırlanmış ve kriterleri gösteren bir örnektir. Yazılanların doğruluğu veya detay seviyesi önemli değildir. Bu örnek, yazılımla ilgili olduğu için, ekranda göreceğiniz ifadeler, bazılarınız için anlamsız olabilir. Bu ifadelerin sadece bir örnek olduğunu dersimiz boyunca unutmayınız.
Öncelikle, tamamlandının tanımı bir kontrol listesi gibi görünse de, Scrum literatürü içinde kontrol listesi ifadesi kullanılmaz. Bu durumu, doktorların veya avukatların kullandığı özel kelimeler gibi düşünebilirsiniz. Her disiplinin kendine özel kavramlarının olması normaldir. Önemli olan bu kavram yapısını bilmek ve diğer meslektaşlarla aynı dili konuşabilmektir.
Konumuza dönersek; bir ürün birikim öğesinin tamamlanmış olarak kabul edilmesi için aşağıdaki kriterlere uyması gerektiği gözükmektedir.
Bu listede ilk maddeye baktığımızda “Kabul Kriterlerinde belirtilen şartların sağlanması” ifadesi gözükmektedir. Bir önceki dersimizde, bu maddeler hakkında örnekler paylaşmıştık. Bu kriterler, genellikle ürünün nasıl gözükeceğini içeren özelliklerdir. Kabul kriterlerinin neler olduğunu görmek için 12.video olan Artırım ve Tamamlandının Tanımı adlı videoyu izlemenizi tavsiye ederiz.
Şu an ekranımızda ise ürünün etkin çalışabilmesi için uyulması gereken farklı kriterlerden de bahsedilmiştir. Bu kriterler, ürün sahibinin bilemeyeceği kriterler olabilir. Bu yüzden, bu kriterler, Scrum takımı tarafından hazırlanır.
Örneğin, hazırlanan kodun, uzman bir geliştirici tarafından gözden geçirilmesi kriteri, daha sonra oluşabilecek kusurları engelleyebilir ve deneyimsiz olan geliştirme ekibinin yeni şeyler öğrenmesini sağlayabilir.
Teknik dokümanın hazırlanmış olması ifadesi, ilgili sayfanın bilgi akışı veya süreç akışını gösteren içerikler olabilir. Bu bilgiler, baştan belgelenmediği takdirde, ve sistemin zamanla büyümesi durumunda, sistemin kontrolü imkansız hâle gelebilir.
Birim testinin geçmesi, hazırlanan fonksiyonun doğru çalışıp, çalışmadığını test etmek ve onaylamak iken, kabul testinden geçmek sistemin bir bütün olarak kabul edilebilir olmasıyla ilgili testlerdir.
Sistemin farklı web tarayıcıları üzerinden test edilmesi ve o tarayıcılarda da sorunsuz çalışması bir başka kriter olarak gözükmektedir. Benzer bir değerlendirme, mobil cihazlar için uygulanabilir. Oluşturduğumuz giriş sayfasının farklı cep telefonlarının ekranlarında nasıl gözüktüğü bir kabul kriteri olabilir.
Bütün bunlara ek olarak fonksiyonel olmayan gereksinimler altında performans, uygunluk ve güvenlik gibi kriterler tanımlanabilir ve üretilen birikim öğesinin bu kriterleri de sağlayıp, sağlamadığı denetlenmiş olur.
Bütün bu kriterlerin olumlu sonuç vermesi halinde, ilgili birikim öğesi “tamamlandı” olarak kabul edilmiş olacaktır.
Müşteri veya ürün sahibi, Sprint içinde geçen süreyi ve harcanan eforu sadece istenen ürünü üretmek olarak düşünmemelidir. Karmaşık bir projede, burada örnek olarak gözüken kabul kriterlerinin sayısı onlarca olabilir. Bu yüzden, Scrum ekipleri, ortaya çıkaracakları ürün birikim öğesinin bu kriterlere uyup uymadığını test etmek zorundadır. Bir projede, ekipleri acele ettirmek, diğer ifadeyle, az zamanda çok fazla şeyi talep etmek ve ekibe baskı kurmak, kalite kriterlerinin yeterince sağlanmadan ürünün teslim edilmesine sebep olur. Bu da, ortaya çıkan ürünün kalite sorunları yaşamasına, ve ekibin düzeltmeler yapmak için tekrar tekrar ürün üzerinde çalışmasına, neden olur.
Artırım, ürünün yeni bir sürümüdür ve önceki tüm sprintlerden gelen artırımlara eklenir.
Bunu, tamamlanmış önceki tüm işlerin üzerine yerleştirilmiş bir yapı taşı gibi görebilirsiniz.
Geliştiriciler, her sprintte en az bir adet yeni ürün artırımı sağlamak için çalışır.
Her yeni artırım, ürünün geliştirilmiş ve kullanılabilir bir sürümüdür.
Artırımın, müşterinin kullanımına sunulma zamanına, yani yayınlanmasına, sadece ürün sahibi karar verir. Bununla birlikte, artırımın kendisi, test etme, belgeleme ve hatta diğer Scrum ekiplerinin yaptığı işlerle entegre etme gibi, herhangi bir ek çalışmaya ihtiyaç duymayacak şekilde, kullanılabilir olmalıdır.
Bir ürün birikim öğesi tamamlanmış olarak kabul edildiğinde, herkes tamamlanmış ifadesinin ne anlama geldiğini anlamalıdır.
Çoğunlukla “tamamlanmış” ifadesi için kalite yönetiminden bildiğimiz kabul kriterleri referans alınır.
Eğer 7. videoda başlattığımız örnekte, ilk ürün birikim öğemiz “Başlangıç sayfası oluşturmaktı. Sonraki bir videomuzda bu öğe için kullanıcı hikayesi yazmıştık. Bir başka videomuzda ise kabul kriterlerini tanımlamıştık.
Kurumun logosu sayfada gözükmeli.
Marketin bina görseli sayfad gözükmeli.
Şirketin adresi, telefon numarası ve email adresi sayfada gözükmeli.
Yine bir başka videomuzda, ekibin yönlendirmesiyle, ürün sahibi, kabul kriterlerinin içine şu iki maddeyi eklemişti.
Logo dijital olarak çizilmiş olmalıdır.
Binanın fotoğrafları profesyonel olarak çekilmiş olmalıdır.
Tam bu noktada lütfen dikkat. Kabul kriterleri hiç bir zaman subjektif ifadeler içeremez. Dikkat ederseniz, “Profesyonel fotoğraf çekimi” ifadesi bile yoruma açıktır. Bu yüzden, çekilecek fotoğrafların çözünürlüğü sayısal verilerle ifade edilmelidir. Amaç, çıkan sonucun ki bu örnekte çekilen fotoğrafların çözünürlüğü, yoruma açık olmaksızın, test edilebilir ve doğrulanabilir olmalıdır.
Her sprint, kalite planlamayı ve kalite kontrolü kendi içinde barındırır. Scrum ekibi, sprint sonlarında yapacakları retrospektif toplantısında öğrendikleri derslerden yola çıkarak, kaliteyi sürekli artırmanın yollarını arayacaklardır.
Scrum’ın en kafa karıştırıcı kısımlarından biri, sprint kapsamı ile sprint hedefi arasındaki farkı anlamaktır. Sprint hedefi sabit kalmakla beraber, sprint kapsamı müzakereye açık bir konudur. Bu dersimizde bu konuyu tüm yönleriyle ele alacağız.
Hemen basit bir örnekle konuyu netleştirmeye çalışalım. Bu hafta sonu evinizde temizlik yapmaya karar verdiğinizi varsayalım. Bu çerçevede, sprintin amacını, temiz bir yaşam alanına kavuşmak şeklinde tanımlayabiliriz. Kapsam, bu hedefe ulaşmak için yapmak istediğiniz çalışmanın ne olduğudur.- Örneğin, Elektrik süpürgesiyle yerleri tozunu almak, ardından yerleri nemli bezle silmek, çamaşırları yıkamak, camları silmek, mutfak dolaplarının içini temizlemek şeklinde detaylar oluşturulabilir. Amaç aynı kaldığı sürece sprintin kapsamı ekip tarafından müzakere edilebilir.
Hafta sonu işe giriştikten sonra, eğer belirlediğiniz kapsamın yetişmeyeceğini fark ederseniz, kapsamı daraltabilirsiniz. Örneğin, mutfak dolaplarının içini temizlemeyi bir sonraki sprint’e bırakma kararı verebilirsiniz. Bu durumda, kapsamınız biraz değişmiştir, fakat temiz bir yere ulaşma hedefinizde değişiklik olmamıştır.
Bu yüzden, sprintin bir hedefinin olması sizi odaklanmanız gereken konu üzerinde, sabit tutacaktır. Hedefe odaklandığınız takdirde, çalışma kapsamınızın içine hiç bir zaman “arabanızı temizlemek” gibi bir aktivite girmeyecektir.
Bununla birlikte, başta hiç düşünmediğiniz detaylar, bir anda karşınıza çıkabilir ve kimi zaman sprint kapsamını, hatta ürün birikim listesini etkileyebilir. Bunu da bir örnekle açıklayalım. Hafta sonu temizliğe başladınız ve oturma odasındaki resim albümlerinin tozunu alırken fark ettiniz ki, pek çok aile resmi, albümlere girmeden karışık bir biçimde büyükçe bir kutunun içinde duruyor. Resimleri tarih sırasına göre albüme dizme fikri aklınıza gelebilir. Fakat bu işi baştan hiç düşünmemiştiniz ve o hafta sonu yapılacak temizlik kapsamına dahil etmemiştiniz. İşin büyüklüğüne göre, diğer Scrum ekibinin değerlendirmesine de başvurarak bu işi mevcut sprintin kapsamına alabilir veya ürün sahibine öneride bulunup, fotoğraf albümlerinin düzenlenmesini yeni bir ürün birikim listesi öğesi olarak ekletebilirsiniz.
Sprint hedefine doğru ilerlerken kesinlikle vazgeçilmez olan kriter, kalitedir. Kapsam içinde yapılacak çalışmaların ulaşılması gereken sonuçları için kabul kriterleri tanımlanmalıdır. Kabul kriterleri hakkında detaylı bilgi sonraki videolarımızın içinde yer alacaktır. Kaliteden ödün vermeyecek şekilde ilerlemek, bazen kapsamdan feragat etmeyi gerektirebilir ve bu durum normaldir.
Bu konuyla ilgili olarak, proje yönetiminde şu iki kavram arasındaki ödünleşmeyi sürekli dikkate almak gerekir. Bir ürünün sınıfı, o ürünün içindeki özelliklerinin sayısını ifade etsin. Müşterinize yüksek sınıflı bir ürün teslim etmeye çalıştığınızı varsayalım. Fakat, sizi o kadar acele ettiriyorlar ki, bazı özelliklerin çalışıp, çalışmadığından emin olmadan, yani test etmeye zaman kalmadan, ürünü teslim ediyorsunuz. Özelliği fazla, fakat çalışıp, çalışmadığından emin olmadığınız bir ürünü, müşterinize teslim etseniz, içiniz rahat olur muydu?
Buna karşılık, özelliği az, ama en azından çalıştığından emin olduğunuz bir ürünü, müşterimize teslim etseniz içiniz daha rahat olurdu, elbette. Şunu lütfen unutmayalım; kaliteden ödün verilmediği takdirde kapsamı genişletmek çok kolaydır. Fakat kalite sorunu yaşayan bir ürün, proje ekibinin sürekli hata düzeltmek için efor ve zaman harcamasına sebep olacaktır.
Her sprint planlama toplantısında ürün sahibi, ürünün değerini, diğer ifadeyle kıymetini, artırmak için bir sonraki adımda yapılması gerekeni Scrum ekibine anlatır. Ve tüm Scrum ekibi, sonraki sprintin hedefini oluşturmaya odaklanır.
Scrum ekibi, ürün sahibi ile işbirliği yaparak, ürün birikim listesinin en üstünden başlayarak hangi öğelerin sprint birikim listesine ekleneceğine karar verecektir.
Ayrıca, sprint birikim listesi, ürün artışını sağlamak ve sprint hedefini gerçekleştirmek için bir plan içerir.
Tam bu noktada, ürün birikim listesi ile sprint birikim listesi arasındaki farkı anlamak için kısa bir açıklama yapalım.
Ürün birikim listesi, üründe olması gereken veya olabilecek fikirlerin veya özelliklerin sıralı bir listesidir. Sprint birikim listesi, her sprint’in başında sıfırdan oluşturulur ve mevcut sprint’te yapılacak ürün iş listesi öğelerini ve planı içerir. Sprint birikim listesindeki tüm öğeler, ürün birikim listesinden gelir.
Plan ise ortaya çıkacak fonksiyonun ve sprint hedefinin nasıl sağlanacağını açıklar. Plan, scrum ekibinin bir artış oluşturmasına izin veren ürün birikim listesi öğesinin ayrıştırılmasıdır. Ayrıştırma ile sprint içinde yapılacak aktiviteler tanımlanmış olur.
Ürün birikim listesi kalemleri, NE’yin teslim edileceğini açıklar. Plan, bunun NASIL olacağını ele alır. Sprint hedefi, sprintin NEDEN değerli olduğunu gösterir. Hepsi, sprint birikim listesinin bir parçasıdır.
Scrum ekibi, bir sprint için ürün birikim listesi öğelerini seçtiklerinde, neyin teslim edileceğine dair bir tahmin oluşturmuşlardır. Sprint için yapılan tahminler asla bir garanti, söz veya taahhüt değildir. Sprint sırasında beklenmedik şeyler olabilir.
Sprint birikim listesini, yalnızca sprint sırasında var olan geçici bir yapı olarak görüntüleyebilirsiniz. Her sprintin yeni bir sprint birikim listesi olacaktır. Sprint’in sonunda sprint birikim listesinde kalan herhangi bir bitmemiş iş, ürün birikim listesine geri konulacaktır.
Bundan sonra ne olması gerektiğine ürün sahibi karar verecektir. Ürün birikim listesi, ürün sahibinin sorumluluğundayken, sprint birikim listesinden, scrum ekibi sorumludur.
Ekip, sprint hedefine ulaşmak için, sprint boyunca gerekli gördükleri değişiklikleri yapabilir. Yapılması gereken işleri belirlediklerinde, sprint birikim listesine eklemeler de yapabilirler.
Sprint birikim listesinde kalan toplam iş, her gün en az bir kez yapılan toplantı ile takip edilir. Ekip üyeleri, sprint hedefine doğru ilerlemeyi takip etmekten sorumludur.
Bir önceki dersimizde kullanıcı hikayeleri için açıklama ve kabul kriterlerini oluşturmaktan bahsetmiştik.
Bu dersimizde ise bir hikayenin içeriğini herkesin ortak anlamasından ve hikayeyi boyutlandırmaktan, diğer bir ifadeyle, tahminlemeden bahsedeceğiz.
Bunu bir örnek üzerinden görelim.
Ürün sahibi Başlangıç Sayfası Oluşturma maddesini Scrum ekibiyle daha detaylı değerlendirmek üzere bir çalışma başlatır. Gelin birlikte ekip üyemiz Ali Bey, ürün sahibi Zeynep Hanım ve Scrum Ustası Furkan Bey arasındaki konuşmaya bakalım.
Ali: “Aklıma şöyle bir şey geldi, sizinle de paylaşmak istiyorum. Başlangıç sayfasında, telefon numarası, adres bilgileri veya kullanılacak görsellerin kolayca değiştirilebilmesi için bir yönetici paneli gerekir diye düşünüyorum.”
Zeynep: “Evet haklısın, buna ileride kesinlikle ihtiyacımız olacaktır, çok iyi düşündün.”
Ali: “O zaman bu özelliği de ürün birikim listesi öğelerinin içine eklememiz gerekir.”
Zeynep: “Doğru söylüyorsun Ali. Pekî arkadaşlar, sizce bu öğeyi hangi sıraya eklemeliyim?”
Furkan: “Ürün sahibi olarak, kullanıcı hikayesini istediğin sıraya ekleyebilir ve istediğin zaman sırasını değiştirebilirsiniz. Zaman içinde ihtiyaçların aciliyeti ve önem seviyeleri daha da şekillenecektir, ve böylece sırayı belirlemek kolaylaşacaktır.”
İleriki derslerimizde öncelik sırası oluşturma ile ilgili farklı teknikleri detaylı olarak inceleyeceğiz.
Zeynep: “Eğer başka sorunuz yoksa, Başlangıç Sayfası Oluşturma öğesi için boyutlandırma çalışması yapmayı öneriyorum.”
Boyutlandırma veya Tahminleme, belirli bir görevi yerine getirmek için gereken çabanın bir öngörüsüdür. Tahmin, asla bir taahhüt veya verilen söz değildir. Tahminler, varsayımları, belirsizlikleri, riskleri içinde barındırır.
Scrum yaklaşımında tahminler birimsiz değerler üzerinden yapılır. Bir diğer ifadeyle, göreceli büyüklük yaklaşımı esas alınır. Basit bir örnekle açıklayalım. Büyükçe bir binaya baktığınızda, o binanın kaç katlı olduğunu söylemek oldukça zordur, bunun yerine iki binayı karşılaştırıp, hangisinin daha büyük olduğunu söylemek çok daha kolaydır. Buna göreceli boyutlandırma adı verilir.
Benzer başka bir bakış açısı şu şekilde olabilir. Örneğin, parkta yürüyüş yapmak, harcanacak çaba açısından sadece 1 rakamı ile temsil edilsin. Buna karşılık, Everest gibi bir dağa tırmanmanın zorluğu ve karmaşıklığı 100 rakamı ile temsil edilsin. Böylece, ölçek olarak kullanacağımız kriterleri belirlemiş olduk. Bundan sonra, işlerimizin büyüklüğünü düşünürken, parkta yürümeyi, bir yokuşa veya küçük bir tepeye çıkmayı, şehrimizin yakınlarındaki bir dağa tırmanmayı ve en nihayetinde Everest’in zirvesine ulaşmayı düşünerek, tahminleme yapabiliriz. Tahminleme esnasında verilen sayıların doğrusu ve yanlışı yoktur. Takım üyelerinin her birisi, kendisi için işin zorluğunu ve karmaşıklığını düşünerek bir tahminde bulunur.
Ekip üyeleri, “başlangıç sayfası hazırlama” öğesi için tahminlerini birbirlerinden bağımsız olarak bir kağıda yazarlar ve aynı anda birbirlerine gösterirler. Burada amaç, birbirlerinden etkilenmemelerini sağlamak ve her birinin bağımsız tahminde bulunmasını garanti altına almaktır.
Örneğin 9 – 12- 15- 22 – 28 şeklinde rakamlar yazmış olsunlar. Scrum Master, ekip üyelerinden bu rakamları aşağıdaki sayı dizisine uygun şekilde revize etmelerini ister.
0- 1- 2- 3- 5, 8, 13, 20, 40 ve 100 – Bu sayılar, planlama pokeri olarak adlandırılan sayı dizisidir.
Böylece, verilen tahminler 8 -13 – 13 -20 ve 20 olarak revize edilir. Burada amaç, verilen tahminlerin birbirine yakın olanlarını kategorize etmek ve benzer bir ölçeğin içine yerleştirmektir.
Bu tahminlerden sonra, ekip üyeleri tahminler arasındaki farkların neler olduğunu belirlemek üzere tartışırlar. 20 rakamını seçen bir takım üyesi, siteye koyulacak logonun dijital olarak hazır olmadığını ve çizim yapılması gerektiğini söyler. Diğer bir takım üyesi, ana sayfada kullanılacak resimler için profesyonel fotoğraf çekimi gerektiğini ifade eder. Diğer takım üyeleri, bu detayları düşünmediklerini kabul ederler ve işin zorluk seviyesi olarak ekipçe 20 rakamı üzerinde ortak karara varırlar. Bunun üzerine Furkan ekibe bir hatırlatma yapar.
Furkan Scrum master: “Arkadaşlar, bu 20 rakamının karşılığının 20saat veya 20 gün olmadığını hatırlatmak isterim. Fakat bundan sonra, diğer öğeleri tahmin ederken, bu öğe ile karşılaştırıp, zorluk ve karmaşıklık açısından puan vermemiz daha kolay olacaktır.”
Diğer öğelerin tahminlenmesiyle, ürün birikim listesindeki öğelerin her birisine, hikaye puanları verilmiş olur.
En son dersimizde, bir market için online alışveriş sistemi kurma projesi için ürün birikim listesi öğelerini belirlemiştik.
Bundan sonra, ürün sahibi, takımla birlikte çalışarak birikim listesindeki öğelere daha fazla ayrıntı ekleyecektir.
Ürün birikim listesi öğeleri, açıklama, sıra, boyut, değer ve kabul kriterleri gibi özellikleri barındıracak şekilde detaylandırılmalıdır.
Pratiğe baktığımızda, birikim öğeleri için kullanıcı hikayeleri oluşturma yöntemi oldukça yaygındır. Hatta, o kadar yaygındır ki, ürün birikim listesi öğelerine çoğu zaman kullanıcı hikayeleri denir.
Kullanıcı hikayeleri, fonksiyonu isteyen kişinin bakış açısından yapılan kısa bir açıklamadır.
Bir kullanıcı hikayesi şablonu tipik olarak şöyle gözükür. “Şu kişi olarak, şu hedefe ulaşmak için, şunu istiyorum.”,
Örneğin, listemizdeki ilk ürün birikim öğesi olan “Başlangıç sayfasını oluşturmak.” ifadesini ele alalım. “Ben, bir müşteri olarak, hızlı sipariş verebilmek için bir web sitesi üzerinden, marketin iletişim bilgilerine ulaşmak istiyorum.” şeklinde bir cümle kim, ne ve neden sorularına cevap veren bir yapıya sahiptir.
Ürün birikim listesi öğesinin içerdiği bilgiler kısa ve öz olmalıdır. Böylece, yapılacak iş hakkında ortak bir anlayışa sahip olmak mümkün olacaktır.
Kullanıcı hikayelerinin istediğimiz sonuca ulaşabilmesi için kabul kriterlerinin de tanımlanması gerekir. Bu, hikayenin tamamlanıp tamamlanmadığını test etmenin bir yoludur.
Başlangıç sayfası oluşturma öğesine bir kaç kabul kriteri ekleyelim.
Kurumun logosu sayfada gözükmeli.
Marketin bina görseli sayfada gözükmeli.
Şirketin adresi, telefon numarası ve email adresi sayfada gözükmeli.
Devam edelim ve başka bir öğenin nasıl görünebileceğini inceleyelim. Örneğin “Bir adet ürün görüntüleme” öğesi. Varsayınız ki, bu mağazanın en çok satılan ürünü Çiçek Balı olsun. Mevcut müşteriler tarafından en çok talep edilen ürün, web sitemizde de özel bir yere sahip olmalıdır.
Böyle bir ürünü web sitemize yerleştirmek için bir kullanıcı hikayesi ve kabul kriterleri oluşturalım. “Ben, müşteri olarak, Çiçek Balı ürünü hakkında detaylı bilgi almak istiyorum.” şeklinde bir ifade yeterlidir.
Bu öğenin kabul kriterleri şu şekilde olabilir.
Ana sayfadan ürün sayfasına bağlantı var mıdır?
Ana sayfada ürün hakkında resim var mıdır?
Ana sayfada ürünle ilgili kısa bir açıklama var mıdır?
Ürünü sayfasında ürünün faydalarının açıklaması var mıdır?
Ürün sayfasında üretim ortamı hakkında bilgiler veriliyor mu?
Görüldüğü üzere, bu kontrol listesinde de soru cümleleri yer almıştır. Kabul kriterlerini okuyan bir kişi, bu sorulara evet cevabını verdiğinde, ilgili öğe veya kullanıcı hikayesi tamamlanmış kabul edilecektir.
Kullanıcı hikayesi veya kabul kriterleri belirsizliklerden dolayı başlangıçta çok net olmayabilir. Örneğin, şu anki kabul kriterlerimizin içinde balları satın almakla ilgili hiç bir madde yoktur.
Sepete ekleme ve kredi kartı ile ödeme imkanları sonraki sprintlerde sitemizin içine eklendiğinde, çiçek balı sayfasından satın alma sayfasına geçişlerin yapılması gerekecektir. Diğer bir ifadeyle, ürünümüz geliştikçe ve biz daha fazla bilgi edindikçe, ürünümüze yeni öğeler ekleyeceğiz veya var olan öğeleri daha da iyileştireceğiz.
Bir mağazanın, ürünlerini sanal ortamda duyurmak ve satmak istediğini düşünelim. Scrum metodolojisiyle bu projeyi hayata geçirmeye karar vermiş olsunlar.
Pazar şartlarını bilen, deneyimli bir ürün sahibinin yapması gereken ilk şey, bir ürün hedefi belirlemek ve ilk sprinte başlamadan önce ürün birikim listesini oluşturmaya çalışmaktır.
Unutmayınız ki, ürün sahibi, bir ürün hedefi belirlemekten ve ürün birikimini yönetmekten sorumludur.
Bu nedenle, projede neyin gerekli olduğunu anlamak için paydaşlarla birlikte çalışması gerekecektir.
Scrum’da başlangıçta oluşturulan ayrıntılı bir plan yoktur.
Ürün sahibi, paydaşlarla birlikte yaptığı toplantılarda 1 sene içinde 1.000 adet siparişi online yapmaları gerektiği konusunda anlaşmaya varmış ve bunu ürün hedefi olarak belirlemiştir.
Bir sonraki adım, ürün birikim listesi hazırlamaktır. Başlangıçta, ürün birikim listesi, sadece birkaç fikirden oluşan bir içeriğe sahip olabilir. Çok ayrıntılı bir içeriğe sahip olmak zorunda değildir.
Scrum’da ürün birikim listesi, şeffaflık, denetim ve adaptasyon için fırsatlar sağlamak üzere tasarlanmış bir eserdir.
Ürün birikim listesi, üründe ihtiyaç duyulan her şeyin sıralı bir listesidir.
Birikim listesi, var olanlara ek, yeni özellikler, iyileştirmeler veya değişiklikler içerebilir.
Ürün birikim listesindeki her bir madde, ürün birikim öğesi olarak adlandırılır.
Bir birikim öğesinin, açıklaması, sırası, boyutu ve değeri gibi özellikleri tanımlanır. Ayrıca, işin tamamlanıp tamamlanmadığını test etmeye yardımcı olacak kabul kriterleri de yer almalıdır.
Ürün birikiminden sorumlu kişi, ürün sahibidir.
Ürün birikim listesinde değişiklik yapma faaliyetine ürün birikim yönetimi diyoruz.
Peki ürün birikim listesi tam olarak nasıl oluşturulur ve yönetilir?
Her şey, bir hedef veya vizyonla başlar.
Ürün sahibinin, ürünün ulaşması gereken hedefi tanımlaması beklenir.
Ürün sahibi, paydaşlarla sürekli işbirliği yaparak, piyasa koşullarını, rakipleri, yasal düzenlemeleri inceleyerek iş gereksinimlerini belirler.Ürün birikim listesinde sadece ve sadece ürün hedefine ulaşmamıza yardımcı olacak öğeler bulunmalıdır.
Ürün hedefi, ürün birikim listesi için bir taahhüttür. Bir seferde, sadece, bir ürün hedefi olmalıdır.
Ürün birikim listesini yönetmek, devam eden bir süreçtir. Ürün sahibi ise, ürün birikim listesinden sorumludur ve istediği zaman ürün birikim listesi öğelerinin sırasını değiştirebilir, yenilerini ekleyebilir veya var olanları çıkarabilir.
Ürün sahibinin, geliştirme ekibiyle yakın çalışması çok önemlidir. Ürün birikim listesi iyileştirme etkinliği sırasında, ürün sahibi ve geliştiriciler, büyük öğeleri daha küçük parçalara bölmek için işbirliği yapar. Öğeler, ne kadar küçük olursa, yönetimi ve kontrolü o kadar kolaylaşır.
Ayrıca, ürün birikim listesi üzerinde, öğelerin detaylarını, boyutunu ve sırasını belirlemek için de çalışacaklardır. Bir öğenin boyutu, işi yapma çabasının ne kadar büyük veya küçük olduğunu gösterir. Bir öğenin boyutunu bulma işlemine, boyutlandırma veya tahmin etme denir.
Ekip üyeleri, yani geliştiriciler, boyutlandırmadan sorumludur.
Ürün birikim listesi, ürün yaşadığı sürece mevcut olan bir belgedir. Ürünün kendisiyle birlikte büyür ve iş gereksinimlerine, pazar koşullarına, kanunlardaki değişikliklere ve buna benzer faktörlere göre içeriği değişir.
Ürün birikim öğlelerinin, bir sonraki sprint için seçime hazır oldukları kabul edilir. Bu, öğelerin bir sprint içine sığacak kadar küçük olduğu anlamına gelir. Böylece, ekip hemen bu gereksinimler üzerinde çalışmaya başlayabilecektir.
Scrum’daki en temel eser, ürün birikim listesidir.
Ürün birikim listesi, ürünü ortaya çıkarmak için hazırlanır. Ürün ise, kullanıldığında fayda sağlayan her şey olabilir. Bilgisayar, araba, telefonunuzdaki bir uygulama veya bir bilgisayar oyunu düşünebilirsiniz. Ürünü kullanan kişiler üründen fayda elde ettikçe bir değer üretilmiş olur. Elde edilecek fayda artıkça, ürünün değeri yani kıymeti de artar.
Basit bir örnek vermek gerekirse, yeni bir akıllı telefon satın aldığınızda, pek çok işinizi bilgisayarınızı açmadan yapar hâle gelebilecekseniz, alacağınız telefon, size zaman ve mekan özgürlüğü getirecektir. Bu özgürlüğe ulaşmak için, telefona biçilen değeri ödemeye hazırsınız, çünkü bu sayede siz de, yaşam kalitenize değer katmış olacaksınız.
Gelelim birikim ifadesine.
Ürün Birikim listesi, hedeflenen ürünün ortaya çıkabilmesi için tamamlanmayı bekleyen ihtiyaçlardır. Bu nedenle, ürün birikim listesi, ürünle ilgili yapılmamış başlıkları içerir. Bunu, Yapılacaklar Listesi olarak da görebiliriz.
Örneğin tatile gitmek istiyorsunuz. Tatilinizin keyifli geçmesi için yapılacaklar listesi oluşturmaya başlarsanız şu maddeler aklınıza kolayca gelecektir.
Nereye gitmek istediğinize karar vermek.
Uçuş rezervasyonu yapmak.
İşyerinizden yıllık izin talep etmek.
Tatil için alışveriş yapmak.
Pasaport – Vize işlemleri yapmak.
Otel rezervasyonu yapmak.
Bu maddelerin hiç birisi henüz yapılmadı. Yapılmayı bekleyen işlerin birikimi olarak listeledik.
Bu arada, listedeki öğeleri aklımıza geliş sırasına göre yazdık. Bizim, bu maddeleri yapılış sırasına göre dizmemiz gerekecektir.
Yapmanız gereken ilk şey ne olurdu? Örneğin, yıllık izninizi almadan, uçak bileti alamazsınız, çünkü istediğiniz tarihte izin alıp, alamayacağınızı henüz bilmiyorsunuz ve bu belirsizlikten dolayı, uçak bilet parasını riske atmak istemezsiniz.
Benzer şekilde, ne zaman ve nereye gideceğinizi bilmeden, otel rezervasyonu yapamazsınız. Gideceğiniz yeri kesinliğe kavuşturduğunuzda ve yıllık izinle ilgili belirsizlik de ortadan kalkınca, otel rezervasyonu yaptırmak risklerinizin azalmasını sağlayacaktır.
Özetle, birikim listesinin içindeki maddeleri, sizi hedefinize ulaştıracak şekilde sıralamanız gerekecektir.
Bazen, yapılması gereken maddeleri yazmış olsanız bile, halen bu maddelerin iç detayları belirsizlik içerebilmektedir.
Örneğin; nereye gideceğinize karar verme konusunu eşinizle konuşuyorsunuz. Eşiniz, tatilde farklı kültürleri tanımak istediğini, müzelerin, tarihi eserlerin yoğun olduğu bir yere gitmek istediğini söylese, buna karşılık siz de sene boyunca çok yorulduğunuzu ve ağırlıklı olarak denize girmek ve hareketli olmayan bir tatil istediğinizi belirtseniz, bu birikim maddesi üzerine beklentiler konuşulmaya başlanmış olur. Amaç, müzakere yoluyla birikim listesindeki maddelerin içeriğini tanımlamak ve belirsizlikleri azaltmaktır. Anlaşmaya çok kısa sürede varmak mümkün olmayabilir, önemli olan paydaşların isteklerini açık ve net olarak birbirlerine anlatabilmeleridir. Buna, şeffaflık diyoruz.
Bir birikim maddesini, daha fazla detaylandırmak gerektiğinde, örneğin, gidilecek yerdeki tarihi mekânları belirleme, araç kiralama, bir rehber ile anlaşma, gezilecek yerlerin rotasını çıkarma gibi ayrıntıları açmak mümkündür. Buna, iyileştirme diyoruz.
Üzerinde anlaşılan bir birikim maddesinin beklenene uygun olarak yapılıp, yapılmadığı proje boyunca kontrol edilmelidir. Buna da tetkik veya denetim diyoruz.
Denetimler esnasında, bir takım eksiklikler ortaya çıkabilir veya baştan düşünülemeyen durum ve şartlarla kaşılaşabiliriz. Örneğin, yurtdışı geziniz için tüm ayarlamaları yaptınız fakat gideceğiniz ülkeden vize alamadığınızı düşünün. Planlarınızı hızlıca değiştirip, yurt içi organizasyona dönüş yapmanız gerekebilir. Buna adaptasyon diyoruz.
Bugün hayatımızın içindeki pek çok ürün, organizasyonların ortaya koyduğu vizyonların sonucudur.
Bir firma, dünyanın en iyi bilgisayarını üretme vizyonuna sahiptir ve bunu ortaya koyduğu ürünlerle sağlayabilir.
Bir başka firma, müşterilerine 10 dakika içinde sıcak yemek servisi verme vizyonuna sahiptir ve oluşturduğu restoran ağı ile bu imkanı sunabilecek seviyeye gelir.
Bir başkası, dünyanın en yüksek güvenlik seviyesine sahip otomobilini yapmayı hedefler ve tüm kaynaklarını bu konuda uzmanlaşmaya ve ürünler üretmeye yönlendirebilir.
Bu çerçevede, bir kuruluşun geliştirmeye çalıştığı ürün, şirketin vizyonuna göre şekillenmektedir. Vizyon, o kuruluş için iddialı hedeftir. Her şirket, dünya genelinde iddialı hedefler koymak zorunda değildir. Elbette, iç pazara yönelik ürün geliştiren bir şirket de kendisi için iddialı hedefler tanımlayabilir.
Organizasyonun üst yönetimi, bir vizyon tanımı yaptığında, bu vizyona hizmet edecek ürünü yapmak üzere ara hedefler belirlenir. Örneğin, aya insanlı bir uzay aracını ilk defa indireceğimizi hayal edelim. Biz, bunu iddialı bir hedef olarak tanımlıyoruz. İlk hazırladığımız roketlere insanları yerleştirip, gönderemeyiz. Öncelikle, insansız roketleri gönderip, geri dönen parçaların sorunsuz olarak geri döndüğünden emin olmamız gerekir. Bundan emin olduktan sonra, hayvanları, kobay olarak gönderip, onların da sağlam döndüklerinden emin olmamız gerekir. Bütün bu evreler esnasında proje ekibi de pek çok yeni bilgi edinir ve varsa hataları düzelterek, ürünü iyileştirir. İnsanlı bir aracı göndermek, en son adım olarak görülmelidir. Böylece, risk ve belirsizliklerin neredeyse tamamen ortadan kaldırıldığından emin olmalıyız.
Scrum yaklaşımında işler, ilginç bir şekilde yukarıdaki örneğe benzer.
Bir ürün oluştururken, vizyonla uyumlu bir ürün hedefi ortaya koymak gerekir. Scrum Kılavuzu, bir vizyondan bahsetmese de, genellikle şirketlerin stratejik hedefleri çerçevesinde vizyon tanımlanır.
Ürün hedefi, uzun vadeli bir hedefi temsil eder. Bir proje ekibinin odaklandığı yalnızca bir ürün hedefi vardır. Böylece, ortak enerjiyi tek bir hedefe yönlendirmek mümkün olacaktır.
Ulaşılan her sprint hedefi ve teslim edilen her artış, ürün hedefine ulaşmak için bir adımdır. Scrum’a dahil olan herkes, yapılan işlerin sprint hedefine, ürün hedefine ve daha geniş ürün vizyonuna ulaşmakla ilişkili olduğunu anlamalıdır.
Eser kelimesi (İngilizce’de Artifact) biraz kafa karıştırıcı olabilir. Bu konuyu biraz açalım.
Eser, aslında insanlar tarafından yapılan veya şekil verilen, sanatsal bir özelliği olan ürünler için kullandığımız bir kavramdır.
Scrum’da eser ifadesi, yaratılan herhangi bir şeydir.
Scrum kılavuzu şu üç eserden bahseder.
1- Ürün birikimi.
2- Sprint birikimi.
3- Artış veya ürün artışı
Bütün metot ve yaklaşımlarda olduğu gibi Scrum yaklaşımının da kendine özel bir terminolojisi vardır. Bu kavramları baştan öğrenmek, sonraki videoların içeriğini anlamanızı kolaylaştıracaktır.
Tekrar dönelim Scrum’daki eserlere…
Scrum eserlerinin her biri taahhüt içerir.
Örneğin, Ürün birikimi, uzun vadeli bir hedef olan ürün hedefine ulaşmak için hazırlanır.
Sprint birikimi, her sprint için tanımlanan sprint hedefine ulaşmak için vardır.
Ürün artışı, ürünün sahip olması gereken kaliteyi tanımlayan “bitmişin tanımını” yerine getirmeyi taahhüt eder.
Bu durumda, taahhüt, belirli bir şeyi başarmaya odaklanmak anlamına gelmektedir.
Bir taahhüde sahip olmak, herkesin çalışmanın neden önemli olduğunu ve istenen sonucun ne olduğunu anlamasını sağlar.
Bundan sonraki videolarımızda Scrum’ın eserlerini daha detaylı olarak göreceğiz.
Scrum, yeni ürün geliştirirken karmaşık işlerle başa çıkmak için kullanılan bir çerçevedir.
Sürekli değişen piyasa koşulları ve teknolojik gelişmelerden dolayı fazlasıyla belirsizlik yaşanan günümüzde, bir ürünün nasıl geliştirilmesi gerektiğini baştan düşünmek imkansızdır. Diğer bir ifadeyle, müşterilerin bundan altı ay sonra ne isteyeceği konusunda şimdiden net bir fikrimiz olamaz. Bu yüzden, gereksinimleri baştan detaylı anlamaya çalışmak ve buna göre ayrıntılı bir plan oluşturmak, değişimin yoğun olduğu sektörlerde işe yaramamaktadır.
Onun yerine, ürünü başarıya ulaştırmak için zaman kutuları ile çalışmak ve potansiyel değişikliklere hızlı adapte olabilmek daha önemli hale gelmiştir. Scrum, belirsizlikle başa çıkmak için zaman kutularının sonunda geri bildirimler almaya ve küçük artışlar yaparak ürünü geliştirmeyi sağlayan bir yaklaşımdır.
SCRUM, bir ürün geliştirmek için gereken tüm adımları, ürünün küçük bir parçası için yapmayı hedefler. Örneğin bir projedeki gereksinimleri toplama, tasarlama ve prototip oluşturma, geliştirme, test etme, dokümante etme gibi adımların hepsi sprint adı verilen sabit uzunlukta bir zaman kutusunun içine yerleştirilir.
İlk sprintten itibaren, ekip üyeleri, müşterilere piyasaya sürülmemiş olsa bile, çalışan, test edilmiş ve potansiyel olarak yetenekli bir ürün yaratmayı hedefler. Her sprintten sonra, ekip neyi başardıklarını müşteriye gösterir ve daha sonra ne yapacaklarını tartışır.
Şöyle bir kabul vardır: Müşterilerin gerçek ihtiyaçlarını anlayabilmeleri ve tarifleyebilmeleri için önce yanlış ürünü karşılarında görmeleri gerekir. Sonra kısa yinelemeler yani zaman kutuları ile müşteriler sürekli ekibe geri bildirim vererek ürünün iyileştirmesinde görev alırlar. Bu yöntem, müşterilerin istediği ve sevdiği bir ürüne ulaşma olasılığını önemli ölçüde artırır.
Bunu başarabilmek için, ekibin gereksinimleri anlaması, tasarım yapabilmesi, ürünü geliştirebilmesi ve test yapabilme becerisine sahip olması gerekir. Böylece, sprint sonunda potansiyel olarak müşterinin onay verebileceği ve çalışan bir ürün ortaya çıkmış olur.
Bir Scrum takımı, bir Scrum Master, ürün sahibi ve geliştiricilerden oluşur.
Ürün sahibi, ürün birikim listesi adı verilen özellikler listesini oluşturacak ve bu listeyi maksimum miktarda değer elde etmek için düzenleyecektir.
Geliştiriciler çalışır ve listedeki öğeleri sunulabilir bir ürün parçasına dönüştürmeyi hedefler.
Yol boyunca Scrum Master, ekibi sprint hedefine odaklar ve onları etkileyen tüm engellerin kaldırılmasına yardımcı olur.
Sprint’in son etkinliği, retrospektif toplantısıdır. Scrum takımı, sprintin nasıl gittiğine bakar ve iyileştirme noktaları bulur. Ardından bir sonraki sprintin planlaması ile süreç baştan başlatılır ve döngü tekrar eder.
Project Management - MS Project - PMP Exam Tips 