Yöneticim ekibe " artık başarılı kullanıcı hikayeleri değerlendirme için değerlendirilecek! "
Biz orada şok ederken oturdu ve o bize verdi birkaç çene bırakarak anlardan biriydi :-)
Bunun aptalca bir fikir olduğunu düşündük, çünkü bu çevik gelişim metodolojisinin tüm konseptini ve hedefini mahvedecektir.
Bana ne düşündüğünü söyle? ve onu nasıl ikna edebiliriz?
Yanıtlar:
Sandy, maalesef yöneticinizin ifadesi, scrum'un klasik ve genel olarak çevik bir yanlış anlamadır.
Önerilen yaklaşım, işbirliğini öldürür ve toplu kod sahipliği ilkesini ortadan kaldırır . Agile'daki kullanıcı hikayeleri (gerçek bir çevikse), birden fazla kişi tarafından dokunulmadan önce nadiren tamamlanır. Ayrıca, yinelemenin tamamlanması için zaman zaman kümelenmesi gereken kullanıcı hikayeleriniz olacaktır . Bireysel teşvikler ters yönde 180 derece hizalandığında bunu nasıl başaracaksınız?
Takım içgüdüleriniz doğru. Yöneticinize verdiğiniz yanıtı beyin fırtınası yaparken kısa vadede okumanız için hangi kaynakları öneririm? Mike Cohn , Martin Fowler , Elizabeth Hendrickson , Jurgen Appelo , Esther Derby ve diğerleri gibi ünlü çevik uzmanların bloglarına bakın ve çevik ekip organizasyonu hakkında makaleler arayın.
Bu değerlendirme yöntemine temel itirazım, geliştiriciler arasındaki işbirliğinin önünde bir engel olabileceğidir. Bir geliştirme ekibinin verimliliğinin önemli bir kısmının ekip üyelerinin birbirlerine yardım etmeye istekli olmaları olduğunu düşünüyorum. Önerilen şemayı anladığım gibi, geliştiricilerin kendi görevlerine sadık kalmasına ve sıkışmış ve biraz yardımla kolayca çıkarılabilen diğer ekip üyelerini görmezden gelmesine yol açabilir.
Programcının ekibe ve işletmeye yaptığı katkıyı her zaman arıyoruz.
Bu, kod satırlarını veya hata sayısını ölçmekle aynıdır - ancak biraz daha karmaşıktır.
İlk bakışta ölçümde yanlış bir şey yok, ancak bunu düşündüğünüzde itirazları artırmaya başlıyorsunuz:
akla gelen en belirgin olanı - eminim başkaları da var.
Yöneticiniz açıkçası bunun iyi bir fikir olduğunu düşünüyor, bu nedenle itiraz ettiğinizde de çözümler sunabileceğinize dikkat etmelisiniz. Bu çözümün yeni bir şemadan ziyade planında bir değişiklik olması gerekebilir.
Örneğin, sadece "kolay" hikayeler üzerinde çalışan birinin daha "zor" bir hikayede çalışandan daha fazlasını tamamlayacağına ve bu da gelişimin daha az önemli yönleri üzerinde yoğunlaşmaya yol açabileceğine işaret etmek isteyebilirsiniz . Yani bir çözüm, sadece hikaye sayısından ziyade hikaye noktalarının sayısını dikkate almak olabilir.
ChrisF ile bunun herhangi bir ölçümde aynı soruna geri döndüğüne katılıyorum. Ne övgü alırsan onu alırsın. Sistem ne olursa olsun, sistemi oynayan insanlar her zaman olacaktır.
Programcıları ödüllendirmek için bulduğum tek gerçek etkili yöntem üç adımla geliyor.
Tüm anahtar, programcıların istatistiklere bakarak 'ayarlanabilen' bir makinedeki çarklar olmadığıdır. Gerçek insanların bir bütün olarak incelenmesi ve geliştirilmesi gerekir ve ekibin rekabetçi bir şekilde değil, bir işbirliğine güvenebilmesi gerekir.
Takımdaki fakir sanatçılara, bırakılmaları düşünülmeden önce iyileştirme ve zenginleştirme için her fırsat verilir. Nihayetinde, iyi programcılar bu ortamda gelişecek ve geliştirilmeyi reddeden fakir programcılar serbest bırakılacak.
Çoğu zaman, Kullanıcı Öyküleri toplu bir çaba ile tamamlanır. Bu, bireysel değerlendirmeyi bu metriğe dayandırmayı neredeyse imkansız hale getirir.
Planlama süreci de bir takım çabası olduğundan ve daha sonradan tüm sistem hileli hale geldiğinden metriğin kendisi kolayca manipüle edilebilir. İnsan odaklı bir süreçte kesinlikle istemediğiniz şey budur.
İyi performansın, takım başarısına dayalı bir tür bonus sistemi tarafından tanınması gerektiğini düşünüyorum, ancak Kullanıcı Hikayeleri başarının iyi bir göstergesi değil.