Her sprint başında erken alt görevler

Agile / Scrum kullanan yeni bir ekibe katıldım ve gelişim süreçleri şöyle:

1) geliştiriciler, kritik bir şeyi kaçırmamak için her sprint'ten önce her hikayeyi gözden geçirir. İş akışında bunun resmi bir durumu var.

2) Sprint başlama sırasında, tüm takım her bir hikayenin kaç hikaye puanına mal olacağına dair bir tahmin yapar (poker planlaması).

3) son olarak, her sprint başladıktan hemen sonra, her geliştiricinin atanan tüm hikayeleri zaman tahminleriyle alt görevlere hevesle ayırması gerekir (her hikayeye başlamadan önce alt görevlerin aksine).

Son adımın ana argümanı, bir hikayenin uygulanmasının beklenenden daha uzun sürüp sürmeyeceğini ve scrint ustasını eksik sprint son tarihlerinin potansiyel riskleri hakkında uyarıp uyarmayacağını keşfetmesidir.

Yine de, bu, özellikle aşağıdaki nedenlerden dolayı karşı üretken buluyorum:

• eğer amaç kaba bir tahmin sağlamaksa, işin hikayesi (adım # 2) budur. Aksi halde neden hikaye noktaları ile uğraşasınız ki? - Sadece alt görevleri erken yapın.
• amaç doğru tahminler sağlamaksa, bu, İnsan Görevi Anahtarları Zararlı Olarak Kabul Edilmesinin açık bir örneğidir . Bu, özellikle, yapılması gerekenleri anlamanın zamanın% 50'sini alabileceği büyük projelerde mevcut ekiplere katılan taze geliştiriciler için böyledir. Bir çok bilgi karmaşası veren 1 numaralı hikaye, sonra 2 numaralı hikaye, 3 numaralı vb.

Ayrıca bana bu tür bir uygulamanın "kitap tarafından" olduğu söyleniyor ve bunu tartışmam bile istenmiyor. Scrum İncillerinde açıkça tanımlanıp tanımlanmadığı ve / veya belki de fazladan içgörü sağlayıp sağlamadığı gibi biri bu tür uygulamalara referans verebilir mi?

Bu, scrum sürecimizin bazılarını nasıl yürüttüğümüzden farklı değildir. Biz

1. "Hikaye noktaları" nda birikmiş işin üst kısmına yakın hikayeleri tahmin edin
2. Sprint'i "oluşturacağını" düşündüğümüz hikaye noktalarına göre hikayeleri seçin / açıklayın
3. Hikayeleri daha ayrıntılı teknik görevlere ayırın
4. Teknik görevleri tahmin edin ve orijinal hikaye puanları tahmini ile karşılaştırın (bir hikaye noktasının normalde ne kadar gelişme süresine eşit olduğunu biliyoruz)

Ama bilmek istediğiniz şey neden iki kez tahmin ediyoruz!

• Kaba bir tahmin yapıyoruz (hikayeye dayanarak) çünkü bir sonraki sprintte ve belki de bundan sonra ne olabileceğine dair tahminlerde bulunmayı seviyoruz . Nihayetinde yönetim, olası zaman ölçekleri hakkında müşteriyle iletişim kurabilmelidir, bu nedenle bu kaba ölçek tahminine sahip değilseniz, uzun vadeli planlama neredeyse imkansızdır.
• Açıkçası, bu, mevcut sprint'ten daha fazlası için kaba tahminler yaptığımız anlamına gelir. Birikmiş siparişin bir sonraki sprint için değişmeyeceğine dair bir garanti olmadığından, görev kesintileri ve hassas tahminler yapmak için gereken zamana yatırım yapmak istemiyoruz.
• Tüm görevlerin numaralandığından ve hikayelerin paralel olarak daha kolay çalışılabileceğinden emin olmak için görevi yıkıyoruz.
• İnce ölçekli tahminler yapıyoruz (göreve dayalı), çünkü bu bize daha düzgün bir yanma grafiği veriyor (özellikle büyük bir hikayeyi uygulanabilir "özelliklerden ayırmanın kolay bir yolu olmadığında).
• İkisini de yaptığımız için, birbirleri üzerinde akıl sağlığı kontrolleri yapıyorlar - vahşi bir tutarsızlık, tanımlamamız gereken bir yerde bir hataya ihtiyacımız olduğunu gösteriyor. Bu yararlı bir yan üründür, ancak kendi başına "iki kez" tahmin etmemizin nedeni değildir.

Sorunuzu ve yorumunuzu tekrar okuduğumda, iş akışımızla sizinki arasında bazı farklılıklar olduğunu görüyorum.

• Bir takım olarak arızalar yapıyoruz, genel gider daha büyük olmasına rağmen, bundan aldığımız teknik tartışma genellikle çok değerlidir ve hikayemizdeki eksiklikleri tespit edebilir. Deneyimimiz, bilgimiz veya yetenek eşitsizliğimiz olduğunda, bu tartışma aynı zamanda daha fazlasına sahip olanların daha az olanlara (yeni işe alımlarda çok yararlı) yardımcı olabileceği yerdir.
• Bir ekip olarak görev düzeyinde tahminler yapıyoruz , "poker planlamanın" çalışmasının nedenlerinden biri "kalabalığın bilgeliği" olgusundan kaynaklanıyor - yorumlarda söylediğim gibi, bu noktada bir görevin tahmin edilmesi 30 saniyeden daha az sürmeli , bu nedenle ek yük ihmal edilebilir.

Ekibinizin görev arızaları yapmasının ve görev tahminlerinin sorunsuz bir yanma nedeni olduğu anlaşılıyor - bu iyi, hepsi sprint'in ilerlemesini izlemenin ve scrum-master'ınızın sorunları erken tespit etmesine ve çözmesine izin vermenin bir parçası. Bu bilgiyi istiyorsanız sahip arızaları ve tahminler yapmak ve var önce onları yapmak.

Benim görüşüme göre, görev değiştirmenin sizin için bir sorun olması muhtemel değildir, farklı görevleri parçalamanın gerçekten bir görev anahtarı olduğunu düşünmüyorum, aynı anlamda bir özellik geliştirmekten başka bir kısma geçiş yapmak bir görev anahtarıdır. . Bence sprint genel "mimarisi" hakkında bir anlayış kazanmak muhtemelen oldukça yararlı bir şey.

Ancak, düşünebileceğiniz başka sorunlar da olabileceğini düşünüyorum. Her zaman olduğu gibi çevik ile ilgili bir problemi tanımlamalı ve bir çözüm önermeli , sonra çözümünüzün geriye dönük olarak çalışıp çalışmadığına karar vermelisiniz . Bu, şirketiniz ve ekibiniz için çalışan çevik bir çözüm oluşturmanın temel noktasıdır. Yani, bazı problemleriniz olabilir :

• Ayrı ayrı arızalar yapıyorsunuz - peki genç / deneyimsiz ekip üyeleriniz kıdemli ekip üyelerinizden nasıl öğreniyorlar? Elbette, muhtemelen her şeyi kendileri öğrenebilirler - ancak mentorluk yapmaları halinde daha hızlı öğrenirler. Genç takım üyelerinin işleri yıkması uzun zaman alıyor mu? Uzun vadede takımın zamanına mal olacak hatalar mı yoksa eksik şeyler mi yapıyorlar? Takım olarak ayrılmak burada yardımcı olabilir.
• Tek tek tahminler yapıyorsunuz - ilk nokta için de aynı şey geçerli, ancak ek olarak bu tahminler olabildiğince daha az doğru mu?
• Sprint başlangıcında görevler atandı gibi görünüyor, ancak bu durumda ödevi değiştirmek zorunda kaldığınızda ne kadar pahalı buluyorsunuz? Birisi geride kalırsa veya hastalanırsa, bir başkasının görevlerini alması ne kadar kolaydır? Görev aksaklıklarından geçip orijinal görevliyi kesintiye uğratmadan onları anlamaya çalışıyorlar mı? Eğer bir takım olarak arıza yapar ve tahmin ederseniz, o zaman herkes her şey üzerinde çalışabilmelidir!
• Hikayeleriniz çok mu büyük? Eğer parçalanma zamanın% 50'sini alırsa, hikayeler çok ilgilendikleri gibi geliyor - belki daha küçük yapılabilirler? Hikayelerimizi 1 haftalık çalışma haftasında tutuyoruz.
• Görevleriniz çok mu küçük? Görev listeleri yapmak için uzun zaman harcıyorsanız belki de çok fazla ayrıntıya giriyorsunuz? 1 ila 8 adam saat değerinde iş yapma eğilimindeyiz, böylece bir gün boyunca herkes bir sonraki günlük duruşmada rapor vermek için biraz ilerleme kaydeder.

Şirketiniz bu şekilde gelişmelerini yürütmek ve tartışmayı kapatmak isterse, seçimleriniz sınırlıdır veya en azından insanları üzme riskiniz vardır.

Çevikliğin nihai amacının değerli bir yazılım olduğu göz önüne alındığında, ekibinizin teslim etme yeteneğini (teslim edilen / tahmin edilen puanlar, sprint hataları, test sayısı, kod kapsamı, çalışma süresi, üretilen satışlar) ölçerek yardımcı olmayı teklif etmeyi deneyebilirsiniz. her neyse). Tüm sonuçlara hazırlıklı olun - bu çalışma yöntemi sizin için bir anlam ifade etmese bile onlar için çalışır. Eğer haklıysan atık kendini belli eder.

Proses uğruna süreci takip etmeye dikkat edin - bu zaman kaybettirir ve yine de zayıf ürünler sunar. İyi bir çevik takım deneyleri, ölçümleri ve öğrenir. Düşünceye inmeden davranışı değiştirmenin en iyi yolu kanıta dayalı kararlardır.

Bu da benim görüşüm. Kendiniz deneyin ve sonucu ölçün - orada ne yaptığımı görün :)

Sprint Başlangıcınızın Sprint Planlama toplantısı anlamına geldiğini varsayabilirim. Scrum Master'ınız bu toplantının nasıl olması gerektiğini yanlış yorumladığını düşünüyorum. Sadece hangi hikayeleri geliştireceğinize karar vermekle kalmaz, aynı zamanda ekibinize hiçbir şeyi kaçırmamalarını sağlamak için hazır tanımını test edersiniz (genellikle INVEST kullanarak ) ve ayrıca bu hikayeleri görevlere ayırırsınız. Mike Cohn'u (Scrum Alliance'ın kurucularından) alıntılamak için ;

Sprint iş listesi, sprint planlamasının diğer çıktısıdır. Sprint biriktirme listesi, ekibin dağıtmayı taahhüt ettiği ürün biriktirme listesi öğelerinin yanı sıra bu ürün biriktirme listesi öğelerini iletmek için gerekli görevlerin listesidir. Sprint biriktirme listesindeki her görev de genellikle tahmin edilir.

Dolayısıyla öyküleri parçalamak ve tahmin etmek Sprint Planlama oturumunun bir parçasıdır; planlama oturumu bittikten sonra değil, bireysel olarak değil.

Daha fazla bilgi sağlamak için Sprint Planlama toplantısı sırasındaki iş akışımız aşağıdaki gibidir:

1. ürün biriktirme listesinin en üstünden bir hikaye alır ve bunları görevlere ayırırız. Genel bir kural olarak, bir görev genellikle bir günden daha küçük olmalıdır.

2. Yaptığımız görevler düşünüldüğünde hikayeyi tahmin ediyoruz. Hikaye büyük olursa, hikayeyi daha küçük hikayelere ayırmaya çalışırız.

3. Durulayın ve toplam tahmini noktaya ulaşıncaya kadar tekrarlayın

Cohn'un söylediklerinin aksine, görevlerin bir günden daha küçük olduğu belirtildiği için, görevlerin her birini ayrı ayrı tahmin etmenin gerçek bir gereği olmadığını buldum. Görevlerin bir günlük çalışmadan daha küçük olduğu göz önüne alındığında, belirli bir görev üzerinde çalışan kişi hala üzerinde çalıştığını söyleyeceği için bir görevin beklenenden daha uzun sürdüğü Günlük Standuping sırasında kolayca fark edebilirsiniz.

Sprint sırasında takım hikayeler boyunca ilerler ve sonunda takım gerçekten ne kadar yapıldığını düşünmelidir. Scrum retrospektif toplantısının amacı budur. Masanın üzerinde hala hikayeler varsa, tahmininizin çok iyimser olduğu sonucuna varabilir ve bir sonraki sprint için harekete geçebilirsiniz. Alternatif olarak, ne kadar yaptığınızı, vb. Etkileyen bazı olaylar meydana gelmiş olabilir.

"kitabın yanında" - bu senin sorunun. Şelaleler çalışıyor olsaydınız sahip olduğunuzdan daha fazla süreçte boğuluyorsunuz.

Agile için bir 'kitap' yok, sadece "tüm yükü olmadan işleri hallet" yazan çevik manifesto var. Yani, boyutları tahmin ediyorsanız ve daha sonra hikayeleri yeniden tahmin etmek için görevlere ayırıyorsanız, bu daha verimli hale getirilmesi gereken anlamsız bir süreç yüküdür - çeviklik budur. Scrum ve diğerleri çevikliğe nasıl başlayacağınıza dair gerçekten başlangıç ​​noktası yönergeleridir. Bunu yaparken, mantıklı olmayan veya ekibinizin daha etkili çalışmasına yardımcı olmayan bu noktaları belirlemelisiniz ve bunları değiştirmelisiniz.

Bununla birlikte, bazı insanlar, ne kadar aptal olursa olsun, yasaklanmış çalışma yollarının taşla yazılması ve asla sapmaması gerektiğini düşünmektedir. Scrum toplantısından önce hikayeleri görevlere ayırmaya çalışacağım - geliştiricilerin her bir hikayeyi gözden geçirmeleri gerektiğini söylüyorsunuz, işte, bölünmeyi incelemenin bir parçası olarak aynı anda yapma şansı. Daha sonra, scrum toplantısında hikayeyi oluşturan görevleri bildirebilir (onlara zaman ayırmayın!) Ve insanların içerdiği bu ek bilgilere dayanarak hikayenin ne kadar büyük olduğuna karar vermesine izin verin (bu asla kötü bir şey değildir, Bilgilendirilmiş karar verme, tahmin çalışmasından çok daha iyidir, ancak karar verme sürecini besleyecek bilginiz olduğunda yapılabilir).

Toplantıdan sonra, görevlere zaman atayabilirsiniz (bunun noktasını göremiyorum, sprintler zamana dayanmıyor, hikaye noktalarında ölçülen "ne kadar şey yapmayı beklediğinize" dayanıyor Bu, scrum ile ilgili yaygın bir sorundur, puanlar zaman anlamına gelmez, ancak iki haftada 20 puan tamamlamanız gerekir, bu nedenle 2 puan = 1 günlük iş. Ne kadar görev koymak için hızlı bir tahmin olması gerekiyordu Ne kadar aşırı ne de fazla çalışılmamış olursunuz, kaç kişinin gerçekten yapılacağını değil. En iyi sprintler, birkaç görevi geride bırakmışlardır, bu da size mükemmel bir şekilde tahmin edildiğini gösterir. sonunda onları tamamlamayı geciktirdi - ikisi de üretken değil).

Kısacası, Agile Manifesto'nun ve anti-agile versiyonunun bir kopyasını yazdırın . Eminim çeviklikten daha fazla anti yapıyorsun. Scrum böyle olma eğilimindedir. Bunu düzeltmenin tek yolu ekibinizle ilişki kurmak ve değişim için katılım sağlamaktır. Yönetimin size ekibinizin nasıl çalışacağını söylemesine izin vermeyin, bu da çevik değildir ve bu Kitapta yazılır.

Her Sprint sırasında bir noktada Ürün İş Listesi Arıtma Toplantısı yapmanız gerekir . Bu toplantıda, Ürün İş Listesi'nin üst kısmının, o bölümdeki öğelerin bir sonraki Sprint İş Listesi'ne eklenmesi için yeterince parçalandığından emin olursunuz.

Ürün İş Listesi İyileştirmesi iyi yönetiliyorsa, Sprint Planlama Toplantısı daha verimli olabilir. İdeal olarak, bu Sprint başladıktan sonra geliştiricilerin hikayeleri "hevesle yıkma" ihtiyacını ortadan kaldıracaktır .

Gerçekçi bir şekilde tahmin etmek için yeterince ayrılmadan önce Ürün İş Listesi kalemleri Sprint İş Listesine eklenirse, bu Sprint'e ne ekleneceği konusunda iyi kararlar almayı zorlaştıracaktır.