Sprint planlaması: Agile en iyi uygulamalar

Planlamanın temelleri

İyi bir sprint planlaması belli bir düzen ister. Önceki sprintlere bakılır, takımın gücü tartılır, hedefler açıkça yazılır. Daha fazla bilgi: IT Ekipleri için BT Proje Yönetim Yazılımı.

1. Hazırlığa erken başlanmalı. Product Owner backlog'u toplantıdan en az bir gün önce toparlayıp önceliklendirir. Geliştirme takımı da user story'leri önceden okuyup aklına takılan soruları sorabilmeli.
2. Klasik kural: sprintin her haftası için iki saat planlama. İki haftalık sprintte bu dört saat eder — ama pratikte bu süreyi tek ve uzun bir toplantıya yığmak yerine birkaç kısa oturuma bölmek çoğu zaman daha iyi sonuç verir.

Hazırlık aşaması

Hazırlığı iyi yapılmamış bir planlamayı düzeltmek mümkün değil. Bu aşama çoğu zaman hafife alınır — oysa bütün sürecin kaderi burada belirlenir.

• Definition of Ready (DoR), bir user story'nin sprinte alınmadan önce hangi koşulları sağlaması gerektiğini tanımlar. Her hikâyenin net kabul kriterleri, karmaşıklık tahmini ve diğer görevlere bağımlılıkları belli olmalı. DoR'a uyulmazsa planlama dağılır; takım işi planlayacağı yerde neyin kastedildiğini çözmeye uğraşır.
• Backlog refinement yalnızca planlamadan hemen önce yapılan bir iş olmamalı — düzenli yürümeli. Bunun için sprint süresinin %10'unu ayırmak yaygın bir uygulamadır. Takım haftada birkaç kez kısa refinement oturumu yapıp gelecek sprintlerin hikâyelerini adım adım olgunlaştırabilir.
• Velocity analizi, takımın gerçekte ne kadar iş teslim edebildiğini gösterir. Son 3-5 sprintin ortalama Velocity'sine bakmak yetmez. Yaklaşan sprinti etkileyebilecek şeyleri de hesaba katmak gerekir: planlı izinler, resmî tatiller, birikmiş teknik borç, dış bağımlılıklar.

Planlama oturumları

Sprint planlaması iki adımdan oluşur. Önce sprintte ne teslim edileceğine karar verilir, sonra seçilen işin nasıl yapılacağına. İki adım farklı girdilerle çalışır ve farklı sonuçlar üretir — ikisini karıştırınca ikisi de zayıflar.

1. Takım, Product Owner ile birlikte, seçilen tüm user story'leri bir araya getiren sprint hedefini belirler. Hedef spesifik ve ölçülebilir olmalı, herkes için bir anlam taşımalı. Zayıf hedef: "Kullanıcı deneyimini iyileştirin." İyi hedef: "Kullanıcılar tek tıklamayla sosyal medya üzerinden kayıt olabilecek."
2. Geliştirme takımı seçilen hikâyeleri görevlere böler ve saat cinsinden tahmin eder. Hikâye düzeyinde görünmeyen karmaşıklıklar ve bağımlılıklar bu sırada ortaya çıkar. Hiçbir görev 8 saatten uzun sürmemeli — bu sınırı aşan görevler alt görevlere bölünür.

Roller ve sorumluluklar

Planlamanın iyi geçmesi için her katılımcının kendi rolünü bilmesi ve onun sınırları içinde kalması gerekir.

• Scrum Master süreci yönetir, timebox'lara uyulmasını sağlar ve takımın karar vermesine yardım eder. Çözümü o dayatmaz. Doğru soruları sorar, tartışmanın dağılmasına izin vermez.
• Product Owner backlog önceliklerinden ve hangi özelliğin önce yapılacağından sorumludur. Her hikâyenin iş açısından neden değerli olduğunu anlatabilmeli, geliştiricilerin sorularını da tahmin yapılabilecek kadar ayrıntılı yanıtlayabilmelidir.
• Geliştirme takımı sonucu teslim etmeyi üstlenir. Bu söz dışarıdan verilmez — takımın kendisinden çıkar. Takımın kendi verdiği söz, tepeden konmuş bir hedefle kıyaslanmayacak ölçüde motivasyon ve sorumluluk duygusu yaratır.

Yaygın hatalar

• En sık yapılan hata, takımın gücünü abartmaktır. Takımlar yapabileceklerinden fazlasını üstlenir. Bu özellikle projenin başında ve iyi geçmiş bir sprintin ardından olur. Kural basit: az söz verip fazlasını teslim etmek daha iyidir. Tutulmayan sözler paydaşların güvenini aşındırır, sonraki sprintlerde takımın hevesini de kırar.
• Zaman tamponu bırakmamak ciddi bir yapısal hatadır. Sprint planında beklenmedik görevler, hatalar ve teknik destek talepleri için %10-20 tampon süre olmalı. Bu yedek önceden ek hikâyelerle doldurulmaz — her sprintte mutlaka çıkan plansız işi karşılamak için vardır.
• Bağımlılıkları görmezden gelmek sprintin ortasında tıkanmaya yol açar. Dış bağımlılıkların hepsi planlama sırasında tespit edilip çözülmeli. Bir görev başka bir takıma ya da dış tedarikçiye bağlıysa tarihler önceden konuşulur, onaylar sprint başlamadan alınır.

Süreç izleme

Olgun Agile takımlarında planlama sürecinin kendisi de sürekli iyileştirilir. Retrospektiflerde yalnızca sprintin nasıl geçtiğine bakılmaz. Planlamanın kalitesi de — ayrı bir girdi olarak — masaya yatırılır.

Analiz için metrikler:

• Tahmin doğruluğu — her hikâye ve görev için planlanan süreyle gerçekte harcanan sürenin karşılaştırılması
• Tamamlanan hikâyelerin yüzdesi — sprinte alınan hikâyelerden sprint sonuna kadar teslim edilenlerin oranı
• Planlamadan sonra sprintte yapılan değişikliklerin sayısı — planın ne kadar sağlam, gereksinimlerin ne kadar net olduğunu gösterir
• Planlamaya harcanan zaman — standart süreyle karşılaştırılır, böylece sürekli fazla ya da eksik zaman ayrıldığı görülür

Burndown grafikleri sprint boyunca ilerlemeyi izler ve sorunları müdahale etmeye vakit kalacak kadar erken gösterir. Grafik planlanan işin yetişmeyeceğini söylüyorsa harekete geçmek gerekir: kalan görevler yeniden önceliklendirilir ya da en düşük öncelikli user story'ler sprintten çıkarılır.

Planlamayı uyarlama

• Uzaktan çalışan takımlarda sprint planlaması biraz farklı kurulur. Uygun işbirliği araçları hazır olmalı ve uzaktaki herkesin eşit ölçüde söz alması bilinçli olarak sağlanmalı. Dağınık takımlarda tek uzun toplantı yerine birkaç kısa oturum yapmak katılımı da çıktının kalitesini de artırır — bu defalarca görülmüş bir şey.
• Birden çok takımın çalıştığı büyük programlar program düzeyinde koordinasyon ister. Scrum of Scrums ya da SAFe (Scaled Agile Framework), ortak bağımlılıkları olan takımların sprint planlarını birbirine uydurmak için hazır bir yapı sunar.
• Bakım projelerinde — sprint süresinin büyük kısmı destek ve hata düzeltmeye gidiyorsa — plansız iş için kapasiteyi açıkça ayırmak şarttır. Sprint kapasitesinin %30-50'sini destek işine ayırıp geri kalanı yeni özelliklere bırakmak standart bir yaklaşımdır. Destek işi planın dışında bir yük gibi görüldüğünde teslimatlar aksar; bu ayrım bunu önler.

İlgili makaleler:

Proje yönetimi çerçeveleri ve kısıtlar arasında denge kurmak için okuyun: Proje yönetimi üçgeni: Kapsam, zaman, maliyet dengeleme.

Kanban panolarına ve görsel iş akışı yönetimine pratik bir bakış için okuyun: Kanban panosu nedir? Görsel iş akışı yönetimi için bir rehber.

Agile takımlarının gerçek kullanıcı ihtiyaçlarından kopmamak için personaları nasıl kullandığını öğrenmek isterseniz okuyun: Agile personalar: Agile projelerinde kullanıcı odaklı geliştirmeyi geliştirme. Ayrıntılar: Kanban tahtası.

Sonuç

İyi bir sprint planlaması sistemli bir yaklaşım ve sürekli iyileştirme ister. Proje bittikten sonra hatırlanan bir şey olmamalı — bilinçli bir alışkanlık olmalı. Retrospektifler bunun için hazır bir araçtır. Orada sprintin sonucuna bakılır — ve o sonucu doğuran planlama girdilerine de. Böylece Agile'ın ürüne uyguladığı adım adım iyileştirme, planlama sürecinin kendisine de uygulanmış olur.