Şirketimde, tek bir görev asla tek bir kişi tarafından tamamlanamaz. Her görevi KG ve Kod Gözden Geçirme için ayrı bir kişi olacaktır. Bunun anlamı, her bireyin görev başına, tamamlanması için ne kadar zaman alacağına dair tahminlerini vermesidir.

Sorun şu ki, yanmaya nasıl yaklaşmalıyım? Saatleri birlikte toplarsam, aşağıdaki tahmini varsayalım:

10 saat - Dev zaman

4 saat - KG

4 saat - Kod İnceleme.

Görev Tahmini = 18 saat

Her günün sonunda görevin "tamamlanana kadar ne kadar zaman kaldı" ile güncellenmesini istiyorum. Bununla birlikte, her insan genellikle kendi parçası hakkında düşünür. Kalan çabayı işaretlemeli ve daha sonra bu çabayı tahmin etmeli mi? Bunu nasıl yapıyorsunuz?

GÜNCELLEME

Birkaç şeyi açıklığa kavuşturmak için, organizasyonumda bir hikaye içindeki her Görev 3 kişi gerektirir.

1. Birisi görevi geliştirecek. (birim testleri yapın, vb ...)
2. Görevi gözden geçirmek için bir KG uzmanı (öncelikle entegrasyon ve regresyon testleri yaparlar)
3. Bir Tech kod inceleme yapmak yol açar.

Yanlış bir yol ya da doğru yol olduğunu düşünmüyorum, ama bu bizim yolumuz ... ve bu değişmeyecek. Mümkün olduğunca bir hikayenin en küçük seviyesini bile tamamlamak için ekip olarak çalışıyoruz. Bir şey geliştirilinceye kadar gerçekten işe yarayıp yaramadığını test edemezsiniz ve kodun kalitesini de inceleyemezsiniz ... bu yüzden yapabileceğiniz en iyi şey, küçük minimum işlevlerin test edilebilmesi için küçük mantıksal dilimlere bölünmesi ve sürece mümkün olduğunca erken gözden geçirilmiştir.

Bu şekilde çalışanlara sorum, bu şekilde kurulduklarında nasıl bir "görev" yakmak olacaktır. Bir Görevin kendi alt görevleri (JIRA'nın izin vermediği) olmadığı sürece ... günlük olarak "geriye kalanları" izlemeyi başarmanın en iyi yolundan emin değilim.

Bu 3 görevdir, bir değil.

Bir özellik / hikaye olabilir, ancak üç görevdir. Tek bir görev, sınırlı bir zamanda tek bir kişi tarafından tamamlanabilir.

TL; DR

Yanmayı çeşitli şekillerde yanlış kullanıyorsunuz. Görevler ve hikayeler ya yapılır ya da yapılmaz; burn-down'daki zamana dayalı planlama tahminlerinden sapmaları izlemeye çalışarak, aslında kalan iş ürününü tahmin etmek yerine programınızı yeniden tahmin edersiniz.

Scrum'da, Sprint'in zaman kutusunu ölçmek yerine Sprint Hedefine doğru ilerlemeyi ölçmelisiniz. Bu, sürekli zamanlama ayarlarından ziyade ekip kapasitesine ve özellik sunumuna odaklanır.

Görevler ve Öyküler

Görevleri ve hikayeleri karıştırıyorsunuz. Hikayeler, ekibinizin "tamamlanma tanımı" na göre hikayeyi tamamlamak için gereken tüm görevleri içerir. Tüm görevleri tamamlanmadığı sürece hikaye % 100 eksik olarak kabul edilir . Scrum'da hikayeler her zaman bir şekilde tahmin edilir; en sık, hikaye noktalarında tahmin edilir.

Görevler, hikayeyi tamamlamak için gereken adımlar veya kilometre taşlarıdır. Her görevin bağımlılıkları ve önkoşulları olabilir, ancak kod incelemesinin diğer görevlerden bağımsız olarak tamamlanmış olup olmadığını kesinlikle söyleyebilirsiniz.

Kül olmak

Scrum'da, yazma çizelgeniz sürat veya proje için kalan iş miktarını gösterir. Gerçek yanma tabloları genellikle platolara sahiptir; bazı durumlarda, grafik bile yükselebilir. Örneğin, 3 ve 5 puan değerinde iki hikaye içeren bir haftalık bir sprintte, veri puanlarınız şöyle görünebilir:

Mon | Tue | Wed | Thu | Fri
--- | --- | --- | --- | ---
 8  |  5  |  5  |  5  |  0

Bu idealist senaryoda 8 hikaye puanı ile başlıyorsunuz. 3 puanlık hikaye Salı öğleden sonra, 5 puanlık hikaye ise Cuma gününe kadar tamamlanmadı. Öykü noktaları, öykü yapılan tanımla tanışıncaya kadar yanmaktan çıkarılmaz. Hikaye puanları yerine ideal saatleri kullanıyorsanız, değişen tek şey ölçeğinizdir.

Zaman Boks

Genel olarak kabul edilen uygulama, görevlerinizin 1/2 gün ile 2 gün arasında ısırık büyüklüğünde parçalara ayrılmasını sağlamaktır. Bir günden fazla varyans günlük duruşlardan veya Sprint İş Listesinden açıkça anlaşılmalıdır; resmi bir durum çekme işlemi gerçekleştirmeye gerek yoktur.

Sprint'inizin doğru bir şekilde eğilim gösterip göstermediğini belirlemek için yazma tablosunda istatistiksel analiz de yapabilirsiniz. Küçük sapmalar veya platolar normaldir, ancak günlük stand-up'da hiç kimse engelleyici yetiştirmiyorsa, ancak yanmanız sıkışmış görünüyorsa, bu genellikle Sprint İş Listesinin yanlış tahmin edildiğinin veya "görünmez iş" olduğunu gösteren bir işarettir. işleminizde açıkça belirtilmelidir.

Geliştirme görevini KG onların görevini yapmadan önce "tamamlandı" olarak tanımlayabilir misiniz? Kod incelemesini geliştirmeden önce "tamamlandı" olarak tanımlayabilir misiniz? Geliştirici ve kod incelemesi yapılmazsa KG "yapılabilir" mi?

Üç öğeyi tek bir görevde toplamanız gerektiğini ve üç kişinin birlikte çalışması gerektiğini söyleyebilirim.

Scrum, herhangi bir öğenin herhangi bir ekip üyesinin sorumluluğunda olduğunu söylemez. Tam tersi sprint log öğeleri TAKIM'ın sorumluluğundadır. Bir görevi gerçekleştirmek için üç kişi gerekiyorsa, işte bu yeter.

Önemli değil. Hikayeler arasında nispeten tutarlı olduğu sürece, burndown grafiğiniz her iki şekilde de çalışır. Ekibinizin raporlaması için en doğal olan yolu kullanın.

Ekibim, resmi bir anlaşma ile olmasa da, aslında bir çeşit melez yapıyor. Bir görevin iki gün süreceğini düşünürsek 16 saat koyarız, ancak iki kişi bunun üzerinde birlikte çalışırsa, onu değiştirmeyiz.

İlk tahminden sonra, gayri resmi olarak ekibimiz için kalan bir saatten daha fazla bir yüzde tamamlandı. Başlangıçta iki gün süreceğini düşünürsek, ancak bir günden sonra sadece% 25'inin tamamlandığını düşünürsek, orijinal 16 saatten 4'ünü çıkarırız. Teknik olarak 24 tahmin ettiğimiz yerde 12 saat kalıyor, çünkü kalan 3 gün için muhtemelen 4 saat düşeceğiz.

Bu beni ilk başta bir scrum ustası olarak rahatsız etti, ancak göründüğü kadar garip, tahminler yapmak için çok doğal bir yol, çünkü geliştiriciler bir tahmine saat eklemektan gerçekten nefret ediyorlar. Her şey saçmalamayı hala faydalı hale getirmek için ortalama ve önemli olan bu.

Görev kalan süresi çok önemli değil: tüm hikaye bitene kadar hiçbir şey teslim edilemez.

İnsanların görevlerde kalan süreyi doldurmasını sağlayarak bir hikayede (genel olarak) ne kadar zaman kaldığını izlemek istiyorsanız, görevleri kişi başına bölün.

Bahsedilen:

• Büyük görevler, hikayelerinizin çok büyük olduğunun bir göstergesi olabilir. Bu durumda, en iyi çözüm öykülerin kapsamını ve boyutunu azaltmaktır ve eğer onu yeterli ölçüde azaltırsanız, görevler üzerinde kalan süreyi takip etmek artık önemli değildir (ya yapılırlar ya da yapılmazlar - yapılmayan görevlerin tahmini toplamı yeterince ayrıntılı).
• SCRUM, herkesi ne yapılması gerektiğini öğrenmeye teşvik eder. Kişilere (rollerin aksine) görevler veriyorsanız, geliştirici hiçbir şey yapmasa bile, bir hikayeyi iletmenizi potansiyel olarak engellemiş olursunuz - çünkü KG tıkanmış durumdadır.

Görevi birden fazla göreve bölün ve her birinin farklı bir kişi tarafından ele alındığı görevler olarak girin.

Orijinal Görev: Bir şeyi düzeltin

Yeni Görevler: (orijinal görevin üst öğesinin alt öğesi)

• Dev A - Sorunu giderme
• Dev B - Dev A'ya sorunu çözmede yardımcı olma (örn. Çift programlama, kod inceleme)
• Dev A - dev Dataset X kullanarak düzeltmeyi test ediyor
• Dev B - Dataset Y kullanarak düzeltmeyi test etme