Çevik yaklaşım, kovboylar için çok uygun bir mazeret midir?

Gereksinimlerin bulanık olduğu ve son kullanıcının fikirlerini şekillendirmek için çok fazla etkileşimin gerekli olduğu projeler için çevik bir yaklaşımın en iyisi olduğuna inanıyorum.

Ancak ... Profesyonel çalışmamda neden "çevik" bir yaklaşımın ön plana çıkma çabası göstermediğinin bir mazereti olarak kullanıldığı şirketlere son veriyorum ; Gereksinimler iyi anlaşıldığında.

Yardım edemem ama çevik yaklaşım yaklaşmazsa, burada güzel bir üst düzey spesifikasyonla oturuyor olacağımı ve başka bir şey ortaya çıktığında her gün aynı ekranı ve işlevselliği tekrar ziyaret etmek zorunda kalmayacağımı düşünerek ve böylece bunu düşünmemiştim.

Çevik metodolojilerin faydaları, kovboy teknik liderlerine verdikleri topal olma bahanesinin ağır basması için gerçekten yeterli midir?

Güncelleme: İronik olarak ben artık sertifikalı bir Scrum Master'ım. Scrum kursunda sunulan makalelerden biri, en iyi gelişme sürecinin, tasarım kararlarını veren tek bir uzman veya gurunun bulunduğu, ancak bunun açık bir zayıflığı olduğu gözlemlendi. Scrum, kaliteli yazılım üretme sorumluluğunu “Alt” bir gruba taşıyor; bu da alt standart bir ekibin diğer Çevik ve Çevik olmayan gelişim süreçlerinden farklı olmadığını tahmin ediyorum.

Agile gelişimini kovboy tarzı programlama için bir bahane olarak kullanıyorsanız, o zaman gerçekten Çevik gelişmeyi takip etmiyorsunuzdur. Kovboylar, onlara hangi süreci verirseniz verin, daima kovboy olacaklar.

Çeviklik, zayıf kalkınma uygulamaları için BDUF'tan daha fazla suçlama yapmak değildir. Sorun, uygulamaların uygulanmasında disiplinin ya da eksikliğin olmasından kaynaklanıyor. BDUF uygulamalarının amacı, projenin yönünü belirlemek ve önceden riskleri belirlemektir. Çevik uygulamaların amacı, gelişme durumunu hızlı bir şekilde yön değiştirebilecek kadar esnek tutmaktır. Çevik bir proje oldukça ayrıntılı kullanıcı hikayeleri hazırlayabilir, böylece takım gelecekteki yönlerden haberdar olur ve yine de tam olarak uygulamak için her yineleme için sadece 2 veya 3'ü seçer. Sorun, hangi metodolojinin kullanıldığı ile aynı kalır: yönetim kovboyların kötü çalışmasına izin veriyor.

[BDUF: Önde Büyük Tasarım]

Çevik, her şey gibi kötü bir davranışı örtbas etmek veya ekibin sorumlu olmadığını düşündüğü bir sorunu çözmeye çalışmak için kullanılabilir.

Bununla birlikte, Scrum gibi bazı Çevik metodolojilerdeki sihir , organizasyon içindeki problemler üzerinde çok fazla görünürlük sağlayacak olmalarıdır. Takım içindeki sorunları da dahil etmek!

Daha sonra bunları ortaya çıktıkça çözme fırsatı verilecektir.

Sorun kovboylara yatarsa, ilk yinelemeden sonra bu çok belirgin olacaktır. Sorun başka bir yerde ise, çok yakında da göreceksiniz.

İşin içine girdiğim "çevik" projelerden, kod toplama isteğinden ziyade gereksinim toplama aşamasını atlamak bir yönetim bahanesi gibi gözüküyor. Biz çünkü benim projeler son derece sinir bozucu olmuştur sahip etkileşim için herhangi son kullanıcılara. Bunun yerine, müşterilerin ne istediklerini öğrenmek için satışlarla konuşan, daha sonra bir toplantıyı arayarak yöneticilere açıklayan ve daha sonra geliştiricilere görevler vermeye başlayan bir yöneticimiz var. “İyi” bir projede atıfta bulunacak bir PP sunumumuz olabilir, ancak genellikle bazı özelliklerin nasıl çalışması gerektiğini soran günlük toplantı toplantılarımızı harcıyoruz ve yönetici soruları yazıyor ve müdürü soruyor. Çok büyük bir zaman kaybı - ama "çevik"!

Şelalenin hayranı olduğumu söylemeyeceğim, çünkü sürekli sinir bozucu kapsam süngeri ile de uğraşıyorum, ama her zaman Agile'yi bu sorunla mücadele etmenin etkili bir yolu olarak görmedim. Erken yinelemeli test ve çok sayıda kağıt prototip ile iyi bir tasarım çok daha etkili gibi görünüyor.

Kovboyların neden olduğu başarısızlıklardan sorumlu olmadığını söyleyen Çevik Kalkınma savunmasını görüyorum. Çevik ile başarı, özen ve zeka gerektirir.

Aynı imtiyazı başka metodolojilere uyguladığınız sürece bu makul bir durum gibi görünüyor. Kovboyların neden olduğu proje başarısızlıkları için Agile'yi suçlayamazsanız, kovboyların neden olduğu proje başarısızlıkları için Çevik olmayan metodolojileri suçlayamazsınız.

Daha sonra Çevik ile kovboylar arasında bir korelasyon olup olmadığını (nedensellik değil!) Tartışabiliriz. Sadece anekdot kanıtlarla, olduğuna inanıyorum. Yönetim tarafından tespit edilmeden kovboy uygulamalarına girmenin iyi bir yolu olarak algılanıyor mu?

Elbette, kovboyların metodolojiler arasında eşit bir şekilde dağılmayabileceğini kabul edersek ve kovboyların bir sürecin başarılı bir şekilde kullanılmasını baltaladığını kabul edersek, bir sürecin başarılı olup olmadığını test etmeyi çok zorlaştırdık. Bir sürecin daha iyi olduğu iddiası (bağlam içinde) yanlışlanamaz hale yaklaşır. Bu beni, mesleğim hakkında utandırmakla meşgul eden sorunlardan biri - iddiaların çoğunun bilimsel temelinin olmaması.

(Bu arada, alternatifleri Çevik "şelale" ye çağırmaktan nefret ediyorum, çünkü şelale işlemleri herkesin saldırdığı bir pipo gibi gözüküyor, ama çok az kişi aslında herhangi bir yineleme olmadan kullanılmış.)

Çevik, ekibiniz için çalıştığı sürece iyidir.

Çok fazla sayıda insan bunu kötü bir takımı iyi bir takıma dönüştürmenin bir yolu olarak satıyor ve bu şekilde çalışmıyor. Kötü insanları alıp aniden faydalı kılmak için bir süreç uygulayamazsınız.

Çevikliğin arkasındaki fikirlerin çoğundan hoşlanıyorum, ancak zaman ve tekrar tekrar gördüğümde başarısızlık, yöneticilerin tüm çevik konsept karşısında uçan ekiplerin kendisinin olması gerektiği gibi katı bir "çevik süreçler" dizisini bastırmasıdır. organize olan.

"Kovboylar" kadar, bulunduğum tüm çevik ekipler için, süreçlerin onları vahşi hale getirmekten daha fazla yavaşlatmaya hizmet ettiğini görüyorum. Hiç çevik bir "kovboy kodlayıcı" sağlamak için hizmet veren bir durum yaşamamıştım .

İyi takımlar için iyi çalışıyor gibi görünüyor (o zaman yine, çoğu takım iyi bir takımınız olduğunda iyi çalışıyor gibi görünüyor, komik olması işe yaramaz değil mi?).

Diğer ekipler için tecrübelerime göre, kötü insanların daha iyisini yapmasına asla yardımcı olmuyor, ancak bazen üretken insanları boğmaya çalışıyor.

Genel olarak, bence önemli olan iyi bir takım oluşturmak, onlara neye ihtiyacınız olduğunu söylemek ve yoldan çekilmektir. Buzzwords dizisi uygulamanın kötü bir ekibe sahip olma sorununu çözme ihtimalinin yüksek olduğunu sanmıyorum.

(Yukarıdan çözemediyseniz, en azından "Capitol-A Agile" nin hayranı değilim. Öte yandan, kovboyları da cesaretlendirdiğini sanmıyorum.)

Düzgün yapıldığında çevik, "kovboy" teknik ipuçlarında ve "kahraman" programcılarında reinaj etkisine sahip olmalıdır. Bu etkiyi gözetmezseniz, çevik uygulamanızda önemli bir şeyin eksik olduğuna dair bir işaret olabilir.

"Çevik" in gerçekten bir arayüz olduğunu eklemek istiyorum (burada nesne yönelimli bir metafor kullanıyorum) ve bunu başlatamazsınız. Eğer somut uygulamanız XP ise , kovboy programcılığına çok az yer bırakan birçok disipline sahip bir dizi teknik uygulamayı takip etmeniz gerekir. Diğer bir olasılık, iyi organize olmuş bir Scrum ekibinin ekip çalışmasının onu kontrol altında tutmasıdır .

Kovboy kodlayıcıları ayrıca çok test edilemeyen bir kod yazma eğilimindedir ve test yazmayı sevmezler. TDD yapan herkesin kovboy tutumunda hüküm sürmesine yardımcı olabileceğini ve geliştiricilerin mimarlığı biraz daha düşünmesini sağlayabileceğini düşünüyorum. Elbette hiçbir metodoloji mükemmel değildir.

Halen böyle olduğu bir mağazada çalışıyorum, sadece özel kovboylardan ziyade örgütsel kültürle ilgisi var.

Örgüt her zaman göreceli olarak gevşek, "gayri resmi" Çevik bir yaklaşım izlemiştir. Bunun gerçekten Çevik olduğunu söyleyemem, daha çok "adına çevik", ancak pratikte var olmayan düz bir metodoloji. Farklı ekipler farklı şekilde çalışırlar, ancak genel organizasyon kültürünün çok gevşek bir "Yalnızca İsmi Çevik" bir süreç dışında başka bir metodolojisi olmadığı için - genel olarak göreceli olarak kovboysu ve kaotik - özellikle entegrasyonda (ve çok ).

Hikayenin ahlaki - Evet, bu olur. Şu anda iş avında olsaydım, bu konuda çok dikkatli olurdum. Bir dükkan Çevik olduğunu iddia ediyorsa - sadece bir Çevik yanıltıcıdan daha fazlasının takip edildiğinden emin olmak için röportajda oldukça zor sorular sorardım.

Kullanıcıların bize yalnızca kullanabilecekleri bir uygulamaya, veri girebilecekleri ekranlara sahip olduklarında geribildirim verebileceklerini öğrendim. Ancak o zaman, gereksinim belgelerinde ne söylemeye çalıştığımızı gerçekten anlıyorlar (müşterilerin imzaladığı ancak herkesin anlamın kendi sürümü var). Çevik bir gelişme değilse, bütçeyi aşan bir şelale projesi olacak, ancak bunu teslim ettikten sonra uygulama değişecek. İlk versiyonunuz, kullanıcıların gereksinimlerin neler olması gerektiğini tartışması için bir prototipten başka bir şey değildir. Bu yüzden bütçeyi aşmak yerine çevik olarak adlandırıyorum.

Bunun doğru olduğunu düşünüyorum, bazı ortamlarda Agile, disiplinsiz bir bahane olarak kullanılıyor. Asıl sorun, neden herhangi bir metodolojiye sahip olduğumuz konusundaki görüşümüzü yitirdik. Şahsen, metodolojinin işlevsel olmayan, kalite niteliklerine hitap etmesi gerektiği, sistemin mimarisinin işlevsel olmayan, kalite özelliklerini ele alması gerektiği yönündeki mimari bir mesele olduğunu düşünüyorum; ve ark.)

Metodolojiyi proses nitelikleri için bir kontrol olarak görmek birkaç şeyi ifade eder: 1) metrikler olmadan bir metodolojinin etkinliğini diğerine göre kıyaslayamayız, 2) hangi özelliklerin önemli olduğu konusunda etkin bir karar verilmesi gerekir (teslimat süresi ve kod kalite vs bilgi aktarımı).

Hem metriklere hem de somut bir hedefe sahip olmadan, basitçe "sihirli kuş tüyü" olarak bir metodoloji seçiyoruz, eğer sıkı tutarsak, yazılımı sunabileceğiz.

Şimdi, Agile, XP, Scrum, vb. Söyleyiciler, bu belirli metodoloji kategorisinin kırılganlıklarından bahseder. Argüman şu: neden tüm kuralları takip etmek için disipline sahip olmayan bir kişi tarafından sabote edilebilecek bir metodoloji kullanıyorsunuz? Soru geçerli bir soru; Ancak, bu belirti, nedeni değil. Doğru ve anlamlı (bu zor kısım) süreç ölçümleri kümesi tanımlanır, test edilir ve zamanında geri bildirim verilirse, belirli bir metodolojinin başarı ile ilgisi olmadığını keşfedeceğimizi düşünüyorum. (Anektolojik olarak konuşursak, sayısız metodolojiyi kullanarak başarılı projeler gördüm ve aynı metodolojileri kullanarak iki katı başarısız oldum)

Peki ölçütler neler? Projeden projeye, takımdan takıma ve zaman zaman değişiyorlar. Teslimat planının önemli olduğu durumlarda kullanışlıdır, şahsen kullandığım bir tahmin yeteneği ve kalitesi. Çoğu geliştirici, bir hafta veya daha kısa süren görevleri doğru bir şekilde tahmin edebilir. Bu yüzden bir yaklaşım, projeyi bir hafta boyunca geliştirici olarak görevlere bölmek ve bu tahminde bulunanı takip etmektir. Proje ilerledikçe tahminlerini değiştirebilirler. Bir görev tamamlandıktan sonra, eğer% 10'dan daha fazla (günde 1/2) kapalıysa, bunu bir hata olarak görüyoruz - tahminin neden kapalı olduğunu tespit ediyoruz (yani bir veritabanı tablosu düşünülmedi), düzeltici eylem (yani tahminde DBA'yı dahil edin) ve sonra ilerleyin. Bu bilgileri kullanarak, haftada tahmin sayısı, geliştirici başına hata sayısı gibi metrikler oluşturabiliriz,

Ne olmuş yani? Metodolojiler ortaya çıktığında - süreç niteliklerini karşılamayan yordayıcı bir modeliniz varsa, metodolojinin bir kısmını eklemeyi veya kaldırmayı seçebilir ve modelinizi nasıl etkilediğini görebilirsiniz. Kabul edilirse, hiç kimse başarısızlık korkusuyla ilgili bir gelişim süreci oynamak istemez, ama biz zaten sürekli olarak yüksek ve öngörülebilir bir oranda başarısız oluyoruz. Bireysel değişiklikler yaparak ve sonucu ölçerek Agile'nin ekibiniz için mükemmel bir metodoloji olduğunu öğrenebilirsiniz, ancak RUP, şelale veya en iyi uygulamalardan oluşan bir çit yuvasını kolayca bulabilirsiniz.

Bu yüzden önerim, süreç olarak adlandırdığımız şey hakkında endişelenmeyi bırakıp, gelişim süreci hedeflerimizle ilgili kontrolleri yerine getirmemize ve bu süreci iyileştirmek için farklı tekniklerle denemeler yapmanıza izin vermektir.

Burada çok güzel bir spesifikasyonla oturuyordum ve her saniye aynı şeyleri ve başka şeyleri ektikçe aynı ekranı ve işlevselliği tekrar gözden geçirmek zorunda kalmıyorum ve bunu düşünmemiştim.

Bu, meslektaşımın üzerinde çalıştığı “çevik” projeyle ilgili tecrübesiyle dolu görünüyor (hiç bir zaman kendimde bulunmadım): bazı özelliklere bir parça kod yazması isteniyor; değiştirmeye ve tekrar test etmeyi gerektiren yeni bir gereksinim ortaya çıkmaya hazır. Sinir bozucu buluyor.

Çevik değil .

Komik, kimsenin kendini kovboy kodlayıcısı olarak düşünmemesi komik. Bahse girerim posterlerin birçoğu vardır;)

Kovboy kodlayıcıları iyidir çünkü hızlıca işleri halletmeyi severler. Genellikle büyük resim sorunları veya kod kalitesiyle ilgilenmezler, bu yüzden "kovboy kodlayıcı" genellikle bir epitettir. Metodları, geç proje tesliminin fırsat maliyeti riskini azaltır.

Kovboy olmayan kodlayıcılar işlerini güvenli, disiplinli ve düzenli bir şekilde yapmaktan hoşlanır. Doğru inşa etmeyi ve bir kez inşa etmeyi seviyorlar. Sonsuza dek bilgi topladıkları, ne olduğu düşünülerek, hiç kimsenin okumadığı büyük belgeler üretmeleri ve sistemleri geç veya çok geç teslim etmeleriyle bilinirler. Metodları düşük kaliteli yazılım risklerini azaltmaya çalışıyor.

Çevik metodolojilerin parlaklığı, kodlayıcılardan hızlı bir şekilde küçük yüksek kaliteli iş parçaları üretmelerini isteyen kısa süreli çalışma yinelemelerini zorlayarak her iki kodlayıcı türünün de güçlü yanlarını kullanmalarıdır. Her yineleme, geç teslimatın fırsat maliyeti risklerini ve düşük kaliteli yazılım risklerini azaltır.

Çevik olmanın sebebi, ön tasarım / şartnamelere çok az vurgu yapmaktır, çünkü sadece gereklilikler değişebilir. Daha derin bir sebep, gereksinimler kararlı olsa bile, özelliklerin şu şekilde olma eğiliminde olmasıdır:

• yanlış - gereksinimleri yakalayamadım.

• tutarsız - çelişkilerle dolu çünkü yazar / okuyucunun onları yakalamasını imkansız kılacak kadar yeterli bilgi içeriyorlar.

• ayrılmış - çalışan (yozlaşmış olsa da) sistemden değerli geri bildirimler içermezler.