Scrum'ın geliştiricilerin kendileri için avantajları? [kapalı]

Scrum bir proje yönetimi metodolojisi olarak, mevcut durumundan oldukça memnun olan bir ekipteki geliştiricilere nasıl 'satarsınız'?

Scrum'ın düzenli sürümler almasına, gereksinimleri değiştirmesine ve ekibin önce yüksek öncelikli hikayelere odaklanmasına nasıl izin vereceğini Ürün Yöneticimize açıklamak bana kolay geliyor. TDD veya Sürekli Entegrasyonun bir geliştiricinin günlük yaşamında neler getirdiğini açıklamayı kolay buldum.

Peki geliştiriciler Scrum'ı nasıl kucaklayabilirler? Scrum hayatlarını nasıl kolaylaştırır?

Scrum olup bitenler hakkında çok daha fazla görünürlük sağlayacaktır . Kötü yönetim, son dakika değişiklikleri, baskılar ve bir geliştiricinin genellikle karşılaştığı her türlü şey.

Ancak, aynı zamanda erteleyiciler, kötü niyetli geliştiriciler, çılgın bireyciler, başka bir deyişle, kötü geliştiriciler üzerinde çok fazla görünürlük getirecektir.

Scrum iki ucu keskin kılıç

Scrum size bu sorunları çözme fırsatları getirecektir. Bu yüzden çok güçlü.

Büyük hedefi ("yazılımı tamamlayın") daha küçük parçalara - hikayelere - ayırmak ve mevcut sprint'te hangilerinin yapılacağına karar vermek verimliliği arttırır ve stresi azaltır. Şimdi ne yapmanız gerektiğini özellikle bildiğinizde , üzerinde durulması gereken çok az şey vardır ve büyük parça tarafından boğulmuş hissetmek yerine küçük parçayı yapmaya odaklanabilirsiniz.

Yığın Dereceleri / İş Listesi, dönüm noktası sonlarının ölüm yürüyüşü olmasını engeller

Bir geliştirici olarak, yazılım geliştirmede en çok gördüğüm 'yıkıcı model', bazı 'dış denetçilerin' (örneğin, proje yönetimi, üst yönetim) 'favori özelliğin' bunu yapmayacağı gerçeğinden dolayı çok heyecanlandığı zamandır. takvim tarihi 've ölüm yürüyüşü emri verir.

Scrum, çünkü bir biriktirme listesi listesinde 'önemli özellikleri' sıralamasında geliştiricilerin bu gerilimi proaktif olarak iki şekilde yönetmelerine yardımcı olur. Birincisi, 'en sevdiği özelliği' biriktirme listesinde yüksek olarak sıralayabilirsiniz, böylece büyük olasılıkla mutlu olacaktır. İkincisi, "yanıp sönen widget'ları" 1. sıraya taşıdığımız için çok görsel ve somut bir cevap veriyor, şu anda 7. sırada olduğu için bu sprint'te 'sıçrayan tavşanlar' alamayacağız. Bu ödünleşmeden memnun musunuz? "

Ayrıca kısa sprintlerle 'dış denetleyicilerin' erteleme çalışmaları konusunda daha az üzgün olduğunu gördüm. 'Yanıp sönen widget'lar' bunu 'kilometre taşı 1' ve 'kilometre taşı 2' haline getirmezse 9 ay sonrasına kadar bitmezse, 'yanıp sönen widget'lar' sponsoru çok üzülür. Ancak 'yanıp sönen widget'lar' 1 yerine 7 sıralanırsa, ilk önce yapılması gereken 6 önemli şey daha varsa, bu muhtemelen sprint + 1 veya en kötü sprint + 2'de elde edeceğimiz anlamına gelir. 12 veya 18 hafta sonra gösterilecek (6 haftalık sprintler kullanarak). Deneyimlerime göre, 3 ay beklemek sabırsızlar için 'kabul edilebilir' - ayrıca, 3+ ay kilometre taşları olan 'şelale' modelinde,

Son olarak, sprint'in sonuna ulaşırsak ve işler beklenenden daha uzun sürerse, 5-6-7 biriktirme öğelerini bir sonraki sprint'e itebilmek ve 1-2-3'ü tamamladığımızdan emin olmak çok güzel -4 yüksek kalite ile ve 70 saat hafta olmadan. Sonuçta, 5-6-7 sonraki sprint'e ulaşacağımızdan emin olacağız. Yine, ertelemede yer alan daha kısa zaman dilimleri göz önüne alındığında, 'dış denetleyiciler' genellikle bununla daha rahattır ve kilometre taşını iki hafta boyunca kaydırdığımız ve akşam yemekleri her gece 'sadece onu geçmeleri' için ısrar etmemede ısrar etmiyoruz.

Bir Scrum takımındaki insanlar birçok şeye kendi başlarına karar verirler: bir sonraki sprint'te neler yapılacak, bu hikayeyi görevlerde nasıl kırabiliriz, neyin üzerinde çalışır, vb. -Yönetim.

Gereksinimlerin değişeceği gerçeği en baştan dikkate alınır. Geliştiricilerin kesin tahminlerle ayrıntılı spesifikasyonlar oluşturmasına ve daha sonra yalnızca müşterinin sonucu görür görmez fikrini değiştirdiğini anlamak için bir özellik geliştirerek haftalar geçirmesi gerekmez ...

Benim için, işleri biriktirmeden kendiniz atamanız, geliştirici bakış açısından en büyük satış noktasıdır. Ayrıca, müşteri / ürün sahibiyle olan yakınlık, şeylerin daha büyük düzenini anlamaya yardımcı olur.

Birkaç şey:

• Xavier'in en başından itibaren değişen gereksinimler hakkındaki görüşüne dayanarak - herkes en baştan müşterinin beklediği gibi olmayacağını kabul ettiğinde daha az politik bir atmosfer gelişir. Hızlı teslimat ve inceleme, yanlış iletişim maliyetinin düşük olduğu anlamına gelir ve suçlu oyunu oynamak yerine geliştiriciler, müşterinin beklediği gibi çalışacakları şeyleri değiştirebilirler.

• Hikaye puanları! Hangi geliştirici bir şeyler yapmak için puan almaktan hoşlanmaz !!?! Cidden, SC2 veya Stack Overflow'da rozetler almaktan daha iyidir.

Bir geliştirici olarak scrum hakkında sevdiğim birkaç şey var.

Geliştiriciler önceden daha fazla bilgi verme eğilimindedir. Ürün sahibinin, bir sonraki sprint sırasında yapılacak tüm işleri, iyi tahminlere izin verecek kadar ayrıntılı bir şekilde açıklaması gerekir.

Tam zamanında tahmin, bu tahminlerin makul derecede doğru olduğu anlamına gelir. Herkesin bir sprint'te neyin biteceği konusunda oldukça iyi bir fikri vardır. Bu, programcılara ve proje yöneticilerine mantıksız taleplere karşı itme araçları sağlar.

Her üç ila dört haftada bir geri adım atmak ve bir nefes almak ve en azından bir hız değişikliği yapmak güzel.

Kendi kendini organize eden ekipler, çalışmalarda biraz daha çeşitlilik veriyor gibi görünüyor.

Teoride en azından sprint sırasında daha az kesinti ve 'acil' vardır.

Günlük ayağa kalkma toplantısı, programcıları her gün birkaç kelime söylemeye zorlar.

Hikayeler her bir sprint sonunda açıkça bitirilip incelendiğinde kaydedilen ilerlemeyi görmek daha kolaydır.

Yakma çizelgeleri, ilerlemeyi izlemek için oldukça etkili bir hafif araçtır.

Geliştirici için avantaj erken geribildirimdir (istemci, testçi, Ürün sahibi vb.).

Ayrıca bir geliştirici olarak, her zaman dikkat dağıtıcı olmadan adım adım şeyler yapmakla ilgileniyorum. Scrum bunu sağlar.

PS: scrum bir metodoloji değil, bir çerçevedir.