Takım büyüklüğü 10'un üzerine çıktığında, yine de sürüm planlamayı birlikte yapabilir misiniz?

Bir sonraki sürüm için ne üzerinde çalışacağınıza karar verirken ve her kullanıcı hikayesi (ve belirli bir hikaye için alt görevler) için zamanlamaları tahmin ederken, bunu bir grupta mı yoksa sadece yöneticilerde mi yapıyorsunuz?

10 kişilik bir takım için bu pratik mi?

Ne kadar sürer?

Önceliklendirme, bir paydaş işlevsel gereksinimlerden olduğu için kodun paydaşı olan ve işlevsel olmayan gereksinimlerden sorumlu olan üst düzey bir geliştirici de dahil olmak üzere çeşitli paydaşların girdisi olan tek bir ürün sahibi tarafından yapılmalıdır.

Tahmin kesinlikle işi yapacak insanlar tarafından yapılmalıdır, asla teslim etmek için baskı altında olan bir yönetici tarafından yapılmalıdır, ancak içgüdüleriniz yarım düzineden fazla insanın bunun üzerinde tartışarak saatler geçireceği doğrudur. İdeal bir dünyada, takımı tek bir takımda 4'ten az ve 7'den fazla olmayacak şekilde yıkmalısınız - 5 idealdir, IMHO.

Bu kesinlikle mümkün değilse, bir nedenden dolayı - ve imkansız olduğunu kabul etmeden önce bu nedene 5 neden uygulamanız gerekiyorsa - o zaman kendi adına tahminler yapmak için takım tarafından 4-5 kişilik bir takım seçilmelidir.

Bence 10 kişilik bir ekip olarak serbest bırakma planlaması YAPMAMALISINIZ. Büyük olasılıkla, herhangi bir tartışmada 6-8 kişinin tamamen bağlantısız ve sıkılmış hissedeceği dev bir toplantıyla sonuçlanacaksınız. Buna 3-4 saatin tükenmesinin birlikte bir odada kilitlendiğini de ekleyin. Ve 10 kişi konuşursa, çok fazla konuşmanın olduğunu düşünün. Eğer konuşmazlarsa, değerli girdiler alamayabilirsiniz.

Joseph'in şirketine çok benzer bir şey yaptık. Önceki sürümde 8 mühendisimiz vardı ve sürüm planlaması 2 hafta sürdü. Ve kesinlikle acımasızdı. Her gün birkaç saat içinde, sanırım hepimiz mümkün olduğunca az konuşmaya çalışıyoruz, böylece toplantımız daha erken biter.

Bu sürüm ekibimizin büyüklüğünü iki katından fazla artırdı. Böylece, bir ürün alanının kalıcı mülkiyetini alacak daha küçük ekiplere ayrıldık. Küçük takımların her birinin bir ipucu vardı. Daha sonra, sadece potansiyel müşterilerle yüksek seviyeli sürüm planlaması yaptık, bu da daha hızlı ve daha verimli geçti çünkü şimdi bir odada sadece 4 geliştiricimiz vardı. Bu süre zarfında hangi ekibin hangi öyküleri yapacağını ve ürünün nasıl bölüneceğini belirledik. Ayrıca bu, tüm ürünün daha büyük resmini verir.

Daha sonra her olası satış kendi ekibine geri döndü ve serbest bırakmanın yalnızca o takımın sorumlu olduğu bölümünü geçti. Bu süre zarfında bazı ayrıntıları doldurduk ve hikaye noktası değerleri belirledik.

Son olarak, her şey bir araya getirildi ve takımdaki herkesin tüm takımda neler olup bittiğini bilmesi için son bir adım attık (tartışmadan çok bir sunum daha yaptık).

Bu yöntemle tam olarak başarılı bir sürümümüz olmasa da, genel olarak sürüm planlamasının öncekinden daha sorunsuz geçtiğini ve çok daha fazlasını elde ettiğimizi düşünüyorum. Kilit nokta, herhangi bir toplantıda asla 3-4'ten fazla geliştiricimizin bulunmamasıydı ve herkesin sesi hala duyuldu.

Mümkünse 10 geliştiricinizi 3 gruba ayırmanızı tavsiye ederim. Genel sürümünüzü çoğunlukla çakışmayan 3 alana bölemezseniz, 2 grup bile bir büyük takımdan daha iyi olacaktır.

Aslında bir potansiyel olarak birden fazla projenin (ve birden fazla ekibin) parçasıyım ve 10'dan fazla olan birkaç tane var. Üzerinde çalıştığım hemen hemen tüm projelerde, sürüm planlaması potansiyel müşteriler ve iş analistleri tarafından yapılır. Ancak, bizim durumumuzda BA'lar yöneticiler değildir, bu nedenle yöneticiler sürüm planlamasına gerçekten katılmazlar.

Tahmin, uygulama ekibi tarafından yapılır ve her iki kısım da ayrı olsa da, çok fazla ilişkilidir.

Tahmin olduğu ne kadar zaman sürüm planlama ise bir görev, halletmek için gereken zaman bu görevler üzerinde çalışılması planlanan olsun.

Planlama iş kaygılarına göre, tahmin ise teknik kaygılara göre yapılmalıdır. Dolayısıyla, tahmin ve planlamanın bozulması.

Bu görev bir yönetici tarafından daha verimli bir şekilde yapılır. Küçük takımlarda, roller karışık olma eğilimindedir. Herkes her şeye karışır. Ancak ekibiniz büyüdükçe, bu yönetilemez hale gelir ve rollerin açıkça tanımlanması gerekir.

Her şeye dahil olma arzusunu elde ettiğim kadar, bu sadece üretken değil.