Makale Özeti

Bu yazımda Scrum süreçleri için çok önemli bir yere sahip olan Product Backlog Item konusunu anlatmaya çalışacağım.

Makale

Team Foundation Server ile Scrum Öğreniyorum Serisi 4
Product Backlog
 
Bu yazımda Scrum süreçleri için çok önemli bir yere sahip olan Product Backlog Item konusunu anlatmaya çalışacağım.
 
Product Backlog üründen beklenen bütün özelliklerin listesidir. Scrum sürecinin başladığı parçadır. Müşteriden ürünle ilgili tüm gereksinimler bir liste halinde Product Owner tarafından toplanır. Sonra bunların önem sıraları öğrenilir. Scrum Takımı(Product Owner-Scrum Master-Scrum Members) bu listeyi önem ve yapılabilirlik durumlarına göre sıralar. Artık elimizde sıralı bir genel yapılacaklar listesi vardır.
 
Product Backlog listesinden önceliği yüksek ve birbiriyle ilişkili bir grup eleman alınıp yeni bir liste oluşturulur. Bu listenin adı Sprint Backlog’dur.
 
Product Backlog sürekli olarak yeni ihtiyaçlarla beslenir. Bu beslenmenin temel nedenleri ürüne yeni ihtiyaçların eklenmesi veya release(yayın) sonucunda ortaya çıkan eksikliklerdir. Bu eksikler sonraki sprintlerde çözülmeyi bekler.
 
Aşağıda bu mimariyi çok güzel anlatan bir resim mevcut.
 

 
Product Backlog elemanları belirlenirken belirli özellikleri barındırıyor olması gerekir. Bu özellikler scrum süreçleri içerisinde “INVEST” olarak adlandırılan maddelerdir.
 
Independent: Product Backlog listesindeki her bir eleman birbirinden bağımsız olmalıdır. Örneğin A elemanı B elemanı başlamadan başlayamıyor olmamalıdır. Eğer iki elemanın birbiriyle çakıştığını düşünüyorsanız onları tek bir elemanda birleştirmeniz önerilir.
 
Negotiable: Sprintler sırasında Product Backlog elemanları değiştirilebilir olmalıdır.
 
Valuable: Product Backlog elemanları müşteri merkezli olmalıdır. Ortaya çıkan özellik müşteriyi memnun edecek olmalıdır.
 
Estimable: Product Backlog elemanları tahmin edilebilir olmalıdır. Yani herkes elemanın sınırlarını anlamalıdır. Böylece planlama daha kolay olacaktır.
 
Small: Product Backlog elemanları olabildiğince küçük olmalıdır. Kısacası bir eleman sprintin büyük bölümünü kaplamamalıdır.
 
Testable: Eleman test edilebilir olmalıdır. Yani elemanın müşterinin onayından geçmesini sağlayacak bütün özellikleri belirtilmiş olmalıdır. Bu genellikle “Acceptance Criteria” dediğimiz “Kabul Kriterleri” listesinin kaliteli hazırlanmış olmasıyla alakalıdır.
 
Team Foundatin Server İle Product Backlog Item Girişi
Product Backlog değerleri genellikle “User Story” denilen bir gereksinim giriş aracı ile girilir. Microsoft Scrum 1.0 üzerinde bu tür bir gereksinimi girmek için “Product Backlog Item” isminde bir adet “Work Item” mevcuttur. Şimdi bir adet PBI oluşturalım.
 
1.Adım: Visual Studio ile takım projenize bağlanınız.
 
2.Adım: Work Items/New Work Item / Product Backlog Item seçeneğini seçelim.
 

 
3.Adım: Karşımıza aşağıdaki gibi bir ekran gelecektir. Daha sonra tüm alanları tanıyalım.
 

 
Title: PBI’ın kısaca ne işi yaradığını en iyi özetleyen cümledir. Kısa ve öz olmalıdır. Bunu duyan takım üyesi genel olarak ne yapacağını anlayabilmelidir.
Örnek: En Popüler Makaleler Listesinin Oluşturulması
 
Iteration: PBI’ın o anki konumunu anlamanızı sağlayacak elemandır. Default olarak takım projesininin adının olması, bu elemanın şu an listede olduğu fakat herhangi bir sprint, release konumuna geçirilmediği anlamına gelir. Mesela bir sprinte dahil etmek için yapılması gereken tek şey, listeden ilgili sprinti seçmektir.
 

 
Assigned To: PBI’ın içeriği konusunda en bilgili kişidir. Bu da genellikler Product Owner olur. Zaten buraya girişleri Product Owner’ın yapması beklenir.
 
State: PBI’ın o anki durumunun belirtildiği alandır. Beş adet değer alabilir.
 
New: Girişi yeni yapılmış ve herhangi bir onay sürecinden geçmemiş PBI’dır.
Approwed: Product Owner tarafından onaylandıysa bu değeri alır.
Committed: Sprinte atanıp takım tarafından onaylanmışsa bu değeri alır.
Removed: Genellikle mükerrer veya çatışan PBI2lar ihtiyaç duyulmadığında bu değeri alırlar.
Done: Bütün Kabul Kriterlerinden geçmişse bu değeri alır.
 
Reason: PBI’ın State’deki duruma neden düştüğünün belirtildiği alandır. Bu yüzden State değerleri ile beraber aktarıyorum.
 
New:
New Backlog Item: PBI’ın ilk kez oluşturulduğu anlamına gelir.
Reconsidering Backlog Item: PBI’ın Remove durumdayken yeniden düşünülmesi için bu duruma alındığı anlamına gelir.
          
          Approved:
Approved by The Product Owner: Product Owner PBI’ı kabul etti ve artık bir sprinte koyulmayı bekleniyor.
Work Stopped: Product Owner kabul etti ama takım reddetti. Başka Sprintlere aktarılacak.
         
          Committed:
                   Commitment Made by The Team: Takım PBI’ı ilgili sprint için onayladı. Yapılmayı bekliyor.
                   Additional Work Found: PBI’ın “Done” durumundayken, eksik yönlerinin kaldığı anlaşıldığında tekrar “Committed” durumuna çekilmesidir. Çünkü henüz PBI ile ilgili yapılacaklar vardır.
 
Removed: PBI listeden kaldırıldı.
 
Done: PBI bütün kabul kriterlerinden geçti.
 
Backlog Priority: PBI’ın Product Backlog listesindeki önceliğinin belirtildiği alandır. Scrum süreçlerinde bu değerin doğru verilmesi önemlidir. Değer ne kadar küçükse o kadar önceliklidir.
Default değeri 1000 dir. Boş geçmenizi tavsiye etmem. Nedeni TFS’in sorgularda default olarak Backlog Priority değeri küçük olan elemanları üste koymasıdır. Fakat değer boş olduğunda TFS en üste bunları getiriyor.
 
Effort: PBI’ın bitirilmesi planan zaman değeridir. Zaman birimi projenin türüne göre saat ,gün veya hafta olabilir. Aslına bakılırsa burada zaman yerine sizin belirlediğiniz kriterler de (Story points) kullanılabilir. Örneğin 1 Zor, 2 Orta, 3 Kolay Seviye uzunlukta gibi. Fakat benim tercihim genellikle zaman dilimleri üzerinde oluyor. Zaman dilimlerini belirtirken Fibonacci serisinin kullanılması idealdir. 1,2,3,5,8,13,21...
Effort değerini saptamaya çalışırken en ideal yöntemlerden biri olan “Planning Poker” oyununu sonraki yazılarımda anlatacağım.
 
Business Value: Genellikle 1-100 arasında verilen ve bu PBI’ın müşteri için öneminin belirtildiği alandır. Değer ne kadar yüksekse müşteri için o kadar önemlidir.
 
Area: Bu alan özellikle proje modüllerinin kolay yönetilmesi için idealdir. Anasayfa,Login,Siparis... gibi.
Default olarak ilk Area değeri projenin adıdır fakat Takım Projesi ismi üzerinde sağ tıklayıp Team project Settings/Areas and Iterations seçeneği yeni area veya iteration ekleye bilirsiniz.
 

Description: Bu alan PBI’ı detaylandıran en önemli alanlardan biridir. TFS üzerinde çalışırken zaten bir açıklama örneği karşınıza gelir.
 

Böylece hangi kullanıcı, neyi, ne için istiyor? Çok net bir şekilde ifade ediyor.
 
Ben örneği türkçe olarak aşağıdaki gibi gösteriyorum.
 

Acceptance Criteria: Bu alan PBI’ın kabul edilme koşullarının sıralı ve net belirtildiği alandır. Böylece geliştirici(developer) yaptığı işlemin doğruluğundan emin olur. Genellikle “test case” leri bu alandaki maddelere göre yapılır.
 
Bu yazımda Scrum için çok önemli yeri olan Product Backlog objesini net bir şekilde açıklamaya çalıştım. Test Cases, Tasks gibi menü seçenekleri de var ama bunları daha sonraki yazılarımda anlatacağım.
 
Aşağıda bir Product Backlog Item örneği veriyorum. Fakat unutmayın PBI içeriği projenin büyüklüğüne göre daha detaylı veya detaysız olabilir.
 

 
Faydalı olması dileğiyle.
Engin Demiroğ,MCT,engin@yazilimDevi.com
www.YazilimDevi.com