Sanırım başkaları zaten iyi cevaplar verdi ama benimkini ekleyeceğim, çünkü takımınızın Scrum'a yeni geçtiğini düşünüyorum ve şimdi siz başladığımızda çok benzer bir konumdasınız.
Öncelikle, Agile ve daha spesifik olarak Scrum'a girişimiz çok düzgün değildi. Temel olarak yönetim çöktü ve bu günden itibaren Scrum'ı yapacağınızı söyledi ve bu hepinizin izleyeceği bir süreç. Süreçteki İnsanlar için çok fazla .
Başlangıçta takip ettiğimiz süreç (körü körüne ekleyebilirim), tarif ettiğiniz şekilde çok benzerdi. İnsanlar görevlendiriliyor, herkes rezerve ediliyor ve hepimiz masalarımıza geri dönüp takılıyoruz. Sonra her gün sıkıcı bir stand-up toplantımız var.
Fark etmenin anahtarı Agile ve Scrum'ın aslında insanlar hakkında olduğudur. Ekip yineleme planına girdiğinde, Scrum ustanızın (muhtemelen yöneticiniz olan) size saat, hikaye ve görev atamasına izin vermeyin. Tamamen EKİBİ KADAR. Bence bir çok insan için bu çok zor bir kavram. Scrum'a dalarlar, ancak herkes (scrum ustasının kendisi dahil) aynı modda çalışmaya devam eder.
Bir gün bundan bıkacaksınız, böylece kitap, blog okumaya başlayacak ve yığın alışverişinde böyle sorular sormaya devam edeceksiniz. Alacağınız farkındalık, geliştirici ve takım arkadaşlarınız olarak hikayelere bağlılık ve görevler vermenin arkasındaki itici güç olmanızdır. Eğer çift programlamadan faydalanacağınızı düşünüyorsanız, her bir mühendis için 2 görev oluşturun ve her ikisine de saat verin. Scrum master'ın yapması gereken tek şey, önceki yinelemede TAKIM OLARAK teslim ettiğiniz tamamlanmış hikayelere karşı hızı ölçmektir.
Ayrıca boktan beni rahatsız eden başka bir şey, insanların kapasitelerinin HER ZAMAN toplam saatlerin% 75'i olduğu söylendiğidir, bu yüzden taahhüt ederler ve daha sonra tüm tekrarlama süresi boyunca şikayet ederler. size yardımcı olurlar ya da b) doğru şeyi yapamazlar çünkü çok fazla saat atandılar. İnsanlara kaç saat taahhüt edileceği söylenmemeli ve scrum ustası böyle bir şey çekmeye çalışıyorsa kesinlikle geri itmeliler! Herkes tam olarak neyin rahat olduğunu taahhüt etmelidir. Örneğin, ben bir takım lideriyim ve sık sık rastgele planlanmamış bir tasarım tartışmasına ya da kodlu birine ya da garip şeyleri gidermeye yardımcı oluyorum, bu yüzden kapasitem asla% 50'nin üzerinde değil.
Bahsettiğim şeyleri yapmamayı öğrenmek için ekibimize 4 serbest bırakma döngüsü geldi ve kesinlikle iyileşmiş olsak da, uzmanlara sorarsanız bile yarı çevik değiliz. Yani hâlâ yapılacak çok şey var.
Güncelleme 1: Cliff'in yorumuna yanıt
Kulaklarınızı teklif ettiniz, işte burada ...
Haklısınız, kültürel değişim anahtardır, ancak bu değişikliğin yönetici düzeyinde gerçekleşmesi gerekmez. Kendi grup yöneticiniz, ekibinizdeki kültürü değiştirebilir ve sizi ilgilenmesi gereken kurumsal BS'den ayırabilir. Açıkladığınız şey, 2007'den 2010'a kadar TAMAMEN bize oldu. Ekibimiz (ve diğer ekipler de) serbest bırakıldıktan sonra serbest bırakıldı. Yönetimin "çevik olma sürecini" kullanan sürümlerden birinde 9 kişinin genellikle tek bir kişi tarafından yapılacak işi üretmesini sağlamayı başardık ve bu bizi iki katına çıkardı. Çok fazla boş zamanım vardı, özgeçmişimi bile güncelledim.
Sonra, patronumla bir görüşme yaptım ve tüm bunları ona insanlar hakkında ne kadar çevik olduğunu açıkladım ve ürünü önemsememizi istiyorsanız, ürün üzerinde nasıl çalıştığımızı ve teslim ettiğimizi etkileyen kararlar verelim. Bence bunu bir deney yapmaya karar verdi, her değişikliği biz yaptık ... çoğunlukla kendim, ama ekibin geri kalanıyla çok konuşuyorum, dolayısıyla% 50 kapasite :) ... önerdi. İstediğimiz tüm değişiklikleri yaparsa ve hala başarısız olursak, muzaffer bir "Sana söyledim" ile geri döneceğini düşünmüş olabilir.
Son 12 ayda çok komik olan aptallığı ortadan kaldırdık. Stand-up toplantılarımız aslında mantıklı çünkü tek başına değil birlikte çalışıyoruz. Hâlâ ürünün belirli parçalarının (en azından şimdilik) sahipliğimiz var, ancak birbirlerinin kodlarına da çok sık geçiyoruz. Kod incelemelerini sürekli olarak yapıyoruz, böylece sadece ekip üyeleri diğer kodları öğrenmekle kalmıyor, aynı zamanda daha iyi kodlama ve tasarım tekniklerini de öğreniyorlar. Monolitik, dev "çevik" ekibi 3 farklı takıma ayırdık, bu yüzden planlama ve diğer toplantılar çok daha kısadır ve insanlar aslında onları önemsiyorlar, çünkü etrafta oturup umursadıkları şeyleri dinlemiyorlar. BEN' 5 kişiden 4'ünün (ekiplerden biri) gece 11'de çevrimiçi olacağı ve hiç kimsenin bize çok çalışmak zorunda olduğumuzu veya 40 saatin üzerinde çalışmak için baskı yaptığımızı söylediği geceleri gördük. Yarım yıl önce daha az umursamayan insanlar, aniden yaptıkları iş hakkında meşgul ve heyecanlılar. Yöneticimizin yapması gereken tek şey, "siz neyin doğru olduğuna siz karar vermeniz ve ne yapmanız gerektiğini yaparsanız kurumsal BS'yi ekibimden olabildiğince uzak tutacağım" demekti.
Deney olarak başladı (şüphem bana bunu asla söylemedi), ama şimdi grubumuz bölümdeki diğer geliştirme gruplarına kıyasla popo tekmeliyor ve hatta şimdi gelip bize katılmaya çalışan başka geliştiricilerimiz var.
Bu değişimin gerçekleşmesinden bu yana bizim için en büyük engel (ve bugün hala bir sorun), normal kurumsal ortamdaki mühendislerin bir kafesdeki deney fareleri gibi olmasıydı. Yöneticiniz gerçekten "çevik" olmaya karar verdiğinde ve kafesi kaldırsa bile, herkes uzun zamandır bu kafeste bulunuyor, özgür olduklarının farkında bile değiller. Böylece tüm özgürlüklerle bile, hala kısıtlanmış gibi davranmaya devam ediyorlar. Bence yardımcı olabilecek en az sayıda takımın (sizin gibi) grubun sınırları dışına çıkıp daha iyi şeyler yapmanın yollarını araması. Sonra bu gruba geri dönün ve biraz karıştırın.
Durumunuzda, takıma gelip nasıl çalışacaklarını söylemek için başka bir dış güç arıyorsanız, eşleştirilmiş programlama bir çözüm değildir. Bunun yerine, kuralları dışarı atın, yönetim olmadan oturun ve ne yapmak istediklerini sorun. Onları ne mutlu edecek? Üretken? En büyük sorunları tespit edin ve ardından TAKIM'a çözümün ne olması gerektiğini düşündüklerini sorun.