Sprint öğesinin tamamlanması beklenenden daha uzun sürüyor. Ne yapmalıyız?

Scrum'daki bir öğe beklenenden daha uzun sürerse ne yapmalıyız? Bunu soruyorum çünkü geliştiricilerin başlangıçta düşünüldüğünden çok daha zor olduğu için tamamlamaya çalıştıklarını fark ettim.

Böyle bir durumda

• sprint zaman çizgisini karşılayabilmemiz için öğeyi sprint'ten ürün kataloğuna geri alabilir miyiz?
• daha kolay sprint öğesine hareket et ve zaman çizelgesinin sonuna kadar sorunlu sprint bırak
• sprint incelemesinde haklı neden maddenin mevcut sprint'te paydaşlara tamamlanamaması?

Gelecekte böyle bir durumu nasıl önleyebiliriz? Önceden planlama eksikliğinden mi yoksa sprint öğesini daha küçük bir öğeye bölmek için çaba göstermedik mi?

"Eşya" ile, "görev" demek istediğinizi varsayalım.

Yazılımda iyimserliği planlama, yazılımın kendisi kadar eskidir. Scrum ile ilgili en iyi şey, yakında karşı karşıya gelmeniz ve görünürlüğü yaratmanızdır: bu nedenle takımların hızı, gelecekteki tahminlere değil, geçmiş verilere dayanmaktadır.

Bir hikayeyi tamamlamak için, beklenenden çok daha zor olan görevleri de tamamlamanız gerekir. Onları ertelemek için mazeret yok. (Bu yüzden Yapılan Tanımı çok önemlidir). Bu, ekibin bir hikaye başarısız olduğu anlamına gelirse, o zaman çok kötü, bir sonraki retrospektifinizde konuşacak bir şeyiniz olacak. Hız azalacak (daha gerçekçi hale gelecek) ve takım daha iyi tahminler yapmayı veya öngörülemeyen görevler için daha fazla güvenlik marjı bırakmayı öğrenecek. Ürün sahibi, sürüm planlaması hakkında daha gerçekçi bir görüş elde edecektir.

Scrum'daki bir öğe beklenenden daha uzun sürerse ne yapmalıyız?

Öğe demek istediğinizi varsayarsak, sprint sonunda genellikle ürün biriktirme listesine geri koyarsınız (ve muhtemelen bir sonraki yineleme için planlıyorsunuz). Takım, mevcut iterasyonda bunun için sıfır puan alır.

Başka bir alternatif, eğer hikaye yeterince büyükse, dikey olarak dilimlemektir . Örneğin, "ürün kataloğu araması" hikayesi, "kategoriye göre ara" ve "tam metin araması" içinde bölünebilir, ancak "arama formu" ve "arama sonuçları" nda bölünemez.

Gelecekte böyle bir durumu nasıl önleyebiliriz?

Bunun kolay bir doğrudan cevabı yok. Scrum'da, tipik olarak bu tür şeyleri ekiple tartıştığınız her yinelemede sprint retrospektifleri yaparsınız. Birçok farklı olasılık var:

• Takımın veya bazı takım üyelerinin kötü bir haftası var
• Ekibinizin boru hatları iş öğelerini yatay olarak (örn. Arka uç -> ön uç -> KG)
• Hikayeler yanlışlıkla çok büyük
• Takım, hikayenin tamamlanması için kesinlikle gerekli olmayan ekstra işler ekleyerek hikayeleri "altın tabaklar" haline getirir.
• Hikayeler doğada çok büyük, daha uzun sprintlere ihtiyacınız var (olası değil)
• Ekip hikayeleri kesin olmayan bir şekilde tahmin ediyor (tutarsızca)
• Projede çok fazla teknoloji borcu / çürük kod tabanı var ve hızınız çok düşük
• Sprint kapasitenizi (veya hiç) doğru bir şekilde ölçmüyorsunuz ve tahmin etmiyorsunuz.

vesaire vesaire.

Bitirmeyeceğinizi söylüyorsunuz, ama bu kötü değil, bu sadece veri.

"Sprint zaman çizelgesiyle tanışın" bir hedef değil. Amacınız kullanıcı hikayelerini tamamlamaktır. Zaman çizelgesi sadece bir sprint'te ne kadar iş yapabileceğinizi ölçmenize ve öğrenmenize yardımcı olan bir araçtır.

Sprint'teki çalışmayı bitiremeyeceğinizden eminseniz, çözümlerden biri öncelik listesinin en altına taşımak ve önce sprint'teki diğer öyküler üzerinde çalışmaktır. Sonra, kalan süre ile üzerinde çalışmaya başlayabilirsiniz. Bir sonraki sprint'e giden çalışmayı yeniden tahmin edin ve sonra bitirin.

Geçmişinizde, gelecekte tahminlerinizi iyileştirebilmeniz için neyin yanlış gittiğini tartıştığınızdan emin olun.

Eğer bir görev beklenenden daha uzun sürerse, bu retrospektifte gündeme getirilmeli ve tartışılmalıdır. Erken analizde kaçırılan bir parça var mı? Bu, ekip tarafından sık sık yapılmayan bir şey miydi? Bir şeyin başlangıçta tahmin edilenden daha uzun sürmesinin birçok olası nedeni vardır.

Ekip, görevi mümkün olan en iyi şekilde yerine getirmeye çalışmalı ve daha sonra geriye dönük olarak, bu konudaki stratejileri gelecekte tartışmalıdır. Takım Scrum'ı kullanmakta oldukça yeniyse, takımın başlangıç ​​hızını hesaplamanın bir parçası olabilir. Bazı takımlar 20 puan yapabileceklerini düşünebilir, bazı takımlar 60 puan yapabilir, her sprintte aynı sayıda puan ne kadar tutarlı bir şekilde yapılabilir.

Bu, gelecekte ekibin yeni görevler yapması gerektiğinde, tahminlerde bulunma karışıklıklarını çözmek için biraz zaman geçeceğinden gelecekte gerçekleşecektir. Bu gerçekten şaşırtıcı olmamalı öğrenme sürecinin bir parçası.

Bir görev beklenenden daha uzun sürmeye başladığında şirketimizde genellikle yaptığımız şey, daha küçük görevlere bölmektir.

Bu şekilde, geliştiricinin çok yavaş olduğu için tüm suçu üstlenmiyoruz, ancak görevin yanlış tasarlandığını da kabul ediyoruz.

Başka bir şey, geç geliştiricinizin kendini bir deliğe kazmasını önlemek için görevi Geliştirme Ekibinizin başka bir üyesine atamak olabilir. Ve eğer görev gerçekten kritikse, bazı XP çözüm olabilir.