it-swarm.dev

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

İhtiyaçların bulanık olduğu ve son kullanıcının fikirlerini şekillendirmek için çok fazla etkileşim gerektiren projeler için çevik bir yaklaşımın en iyisi olduğuna inanıyorum.

Ancak ... Profesyonel çalışmamda, "çevik" bir yaklaşımın kullanıldığı şirketlere devam ediyorum neden ön tasarımda hiçbir çaba harcanmadı; gereksinimler iyi anlaşıldığında.

Çevik yaklaşımın etrafında olmasaydı, burada güzel bir üst düzey spesifikasyonla oturuyordum ve başka bir şey ortaya çıktığında her iki günde bir aynı ekranı ve işlevselliği tekrar ziyaret etmek zorunda kalmayacağımı düşünemiyorum. ve bunu hiç düşünmemişti.

Çevik metodolojilerin faydaları kovboy teknik ipuçlarına verdiği topyekün bahanesini aşmak için gerçekten yeterli mi?

Güncelleme: İronik bir şekilde artık sertifikalı bir Scrum Master'ım. Scrum kursunda sunulan çalışmalardan biri, en iyi geliştirme sürecinin, tasarım kararlarını veren tek bir uzman veya gurunun olduğu, ancak bunun belirgin zayıflıklara sahip olduğu bir süreç olduğunu gözlemledi. Scrum, kaliteli yazılım üretme sorumluluğunu "Takım" a kaydırır, bu da bir alt standart ekibin diğer Çevik ve Çevik olmayan geliştirme süreçlerinden farklı olmadığını tahmin ettiğim spagetti'yi ortadan kaldırabileceği anlamına gelir.

73
sipwiz

I'm Glad it has a name

Agile geliştirmeyi kovboy tarzı programlama için bir bahane olarak kullanıyorsanız, o zaman Agile gelişimini gerçekten takip etmediğinize inanıyorum. Kovboylar, onlara hangi süreci verirseniz verin, daima kovboylar olacaktır.

87
Dean Harding

Agile, BDUF'den ziyade zayıf geliştirme uygulamaları için sorumlu değildir. Sorun, uygulamaların uygulanmasındaki disiplin veya eksikliğidir. BDUF uygulamalarının amacı, projenin yönünü ve riskleri önceden belirlemektir. Çevik uygulamaların amacı, geliştirme durumunu hızlı bir şekilde yön değiştirecek kadar esnek tutmaktır. Çevik bir proje son derece ayrıntılı kullanıcı hikayeleri hazırlayabilir, böylece ekip gelecekteki yönergelerin farkındadır ve yine de tam olarak uygulamak için yineleme başına sadece 2 veya 3 seçer. Hangi yöntem kullanılırsa kullanılsın sorun aynıdır: yönetim kovboyların amuck çalıştırmasına izin vermektedir.

[BDUF: Ön tarafta büyük tasarım]

20
Huperniketes

Çevik, herhangi bir şey gibi, kötü bir davranışı kapatmak veya takımın sorumlu olmadığını düşündüğü bir sorunu çözmeye çalışmak için kullanılabilir.

Bununla birlikte, Scrum gibi bazı Çevik metodolojilerindeki sihir, kuruluştaki sorunlara çok fazla görünürlük sağlamalarıdır. Takım içerisindeki problemler dahil!

Daha sonra, ortaya çıktıklarında bunları çözme fırsatı verilecektir.

Sorun kovboylara aitse, bu ilk iterasyondan sonra çok görünür olacaktır. Sorun başka bir yerde ise, çok yakında göreceksiniz.

13
user2567

İşin tuhafı, katıldığım "çevik" projelerden, daha çok, gereksinimlerin toplanma aşamasını atlamak için bir kovboyun basitçe kodlamaya başlamak arzusundan daha fazla gibi görünüyor. Projelerim son derece sinir bozucu oldu çünkü etkileşimde bulunacağımız son kullanıcı yok var. Bunun yerine, müşterilerin ne istediklerini öğrenmek için satışlarla konuşan, daha sonra bir toplantıyı çağıran ve yöneticilere açıklayan ve daha sonra geliştiricilere görev atamaya başlayan bir yönetmenimiz var. "İyi" bir projede PP sunuya başvurabiliriz, ancak genellikle günlük scrum toplantılarımızı bazı özelliklerin nasıl çalışması gerektiğini sorarak harcıyoruz ve yönetici soruları yazıyor ve yönetmene sorar: Çok büyük bir zaman kaybı - ama "çevik"!

12
TMN

Şelalenin hayranı olduğumu söylemeyeceğim, çünkü sürekli sinir bozucu kapsam sürünmesiyle uğraşıyorum, ama Agile'ı her zaman soruna karşı bir taviz olarak gördüm, onunla savaşmanın etkili bir yolu değil. Erken yinelemeli testler ve çok sayıda kağıt prototipiyle iyi bir tasarım çok daha etkili görünüyor.

7
Morgan Herlocker

Çevik Gelişim savunmasını kovboyların yol açtığı hatalardan sorumlu olmadığını söyleyerek görüyorum. Agile ile başarı, titizlik ve zeka gerektirir.

Aynı imtiyazı diğer metodolojilere uyguladığınız sürece, bu makul bir pozisyon gibi görünüyor. Kovboyların neden olduğu proje başarısızlıkları için Agile'ı suçlayamazsanız, kovboyların neden olduğu proje başarısızlıkları için Agile olmayan yöntemleri suçlayamazsınız.

Daha sonra Agile ve kovboylar arasında bir ilişki (nedensellik değil!) Olup olmadığını tartışabiliriz. Sadece anekdotlarla kanıt olduğuna inanıyorum. Yönetim tarafından algılanmadan kovboy uygulamalarına katılmak için iyi bir yol olarak mı algılanıyor?

Tabii ki, kovboyların metodolojilere eşit olarak yayılmayabileceğini kabul edersek ve kovboyların bir sürecin başarılı kullanımını zayıflattığı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 (bir bağlam dahilinde) iddiası değiştirilemez hale gelir. Mesleğimle ilgili utanç içinde kafamı asmamı sağlayan konulardan biri bu - iddiaların çoğunun bilimsel dayanaksızlığı.

(Bu arada, Agile "şelalesi" için alternatif (ler) denmekten nefret ediyorum, çünkü şelale süreçleri herkesin saldırdığı bir samancı gibi görünüyor, ancak çok az insan aslında herhangi bir yineleme olmadan kullandı.)

6
Oddthinking

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

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

Çeviklerin arkasındaki fikirlerin çoğunu seviyorum, ancak tekrar tekrar göremediğim, yöneticilerin, tüm çeviklik kavramının karşısında uçan, takımların kendileri olması gereken sıkı bir "çevik süreçler" kümesi bastırmasıdır. organize olan.

"Kovboylara" göre, bulunduğum tüm çevik takımlar için süreçlerin onları vahşileşmelerine izin vermekten daha yavaşlamaya hizmet ettiğini görüyorum. Çevik hizmet etkinleştirmek bir "kovboy kodlayıcı" hizmet nerede hiç yaşamadım.

İyi ekipler için iyi çalışıyor gibi görünüyor (o zaman yine, çoğu süreç iyi bir ekibiniz olduğunda iyi çalışıyor gibi görünüyor, bu nasıl çalışıyor komik değil mi?).

Diğer takımlar için, tecrübelerime göre, kötü insanların daha iyisini yapmasına asla yardımcı olmaz, ancak bazen üretken insanları aşağı çekmeye hizmet eder.

Genel olarak, önemli olanın iyi bir ekip oluşturmak, onlara neye ihtiyacınız olduğunu anlatmak ve sonra yoldan çıkmak olduğunu düşünüyorum. Herhangi bir terim dizisinin uygulanmasının kötü bir takım olması sorununu çözeceğini düşünmüyorum.

(Yukarıdakilerden anlamamışsanız, en azından "Capitol-A Agile" hayranı değilim. Öte yandan, kovboyları da teşvik ettiğini sanmıyorum.)

5
TM.

Çevik düzgün yapıldığında "kovboy" teknik liderleri ve "kahraman" programcıları dizginleme etkisi olmalıdır. Bu etkiyi gözlemlemezseniz, çevik uygulamanızda önemli bir şeyin eksik olduğuna dair bir işaret olabilir.

"Agile" ın gerçekten bir arayüz olduğunu eklemek istiyorum (burada nesne yönelimli bir metafor kullanıyorum) ve bunu başlatamazsınız. Somut uygulamanız XP ise, o zaman kovboy programlama için çok az alan bırakan bir çok disiplinli teknik uygulamaları takip etmeniz gerekir. Başka bir olasılık, iyi organize olmuş bir Scrum ekibinin ekip çalışmasını kontrol altında tutacağıdır.

3
azheglov

Kovboy kodlayıcıları da çok test edilemeyen kod yazma eğilimindedir ve yazma testleri sevmezler. Bence herkesin TDD yapması kovboy tutumunda hüküm sürmeye yardımcı olabilir ve geliştiricilerin mimarlık hakkında biraz daha düşünmesini sağlayabilir. Hiçbir metodoloji elbette mükemmel değildir.

3
Matt H

Şu anda durumun olduğu bir dükkanda çalışıyorum, ancak organizasyonel kültürle ilgili olarak belirli bireysel kovboylardan daha fazla.

Organizasyon her zaman nispeten gevşek, "gayri resmi bir Çevik" yaklaşımla faaliyet gösterdi. Ben gerçekten Çevik olduğunu söyleyemem, daha çok "Adında Agile", ama pratikte sadece varolmayan metodoloji. Farklı ekipler farklı şekilde çalışırlar, ancak genel örgüt kültürünün çok gevşek bir “sadece adıyla çevik” süreç dışında başka bir metodolojisi olmadığı için - özellikle de entegrasyonda nispeten kovboy ve kaotik genel olarak (ve bunun birçoğu var) ).

Hikayenin ahlaki - Evet, bu oluyor. Şu anda iş arama olsaydım, buna çok dikkat ederdim. Bir dükkan Agile olduğunu iddia ederse - röportajda sadece Agile'ın yanlış bir adından daha fazlasının takip edilmesini sağlamak için oldukça zor sorular soracağım.

3
Bobby Tables

Kullanıcıların yalnızca kullanabildikleri bir uygulamaya sahip olduklarında, veri girebilecekleri ekranlarda bize geri bildirim verebileceklerini gördüm. Ancak o zaman, gereksinim belgelerinde ne söylediğimizi gerçekten anlıyorlar (müşterilerin imzaladığı ancak herkesin anlamın kendi versiyonu var). Çevik bir gelişme değilse, bütçeyi aşan bir şelale projesi olacak, ancak uygulama bir kez teslim edildiğinde değişecek. İlk sürümünüz, kullanıcıların gereksinimlerin ne olması gerektiğini tartışması için bir prototipten başka bir şey değildir. Bu yüzden bütçeye göre daha çevik diyorum.

2
Veronica Buitron

Bence bu doğru, bazı ortamlarda Agile disiplinsiz bir bahane olarak kullanılıyor. Asıl sorun, neden herhangi bir metodolojimiz olduğunu gözden kaçırdık. Şahsen, metodolojinin, sistem mimarisinin işlevsel olmayan, kalite özelliklerine hitap etmesi gerektiği anlamında mimari bir mesele olduğunu hissediyorum, metodoloji aynı özelliklerden bazılarını ele almalıdır (sürdürülebilirlik, kalkınma verimliliği, bilgi transferi, vd.)

Metodolojiyi süreç nitelikleri için bir kontrol olarak görmek birkaç şeyi ima eder: 1) metrikler olmadan bir metodolojinin diğeriyle olan etkinliğini karşılaştıramayız, 2) hangi özelliklerin önemli olduğu konusunda aktif bir karar verilmesi gerekir (teslim süresi vs kodu bilgi aktarımına karşı kalite).

Hem metriklere hem de somut bir hedefe sahip olmadan, sadece "sihirli tüy" olarak bir metodoloji seçeriz; eğer sıkı sıkıya tutursak, yazılım sunabiliriz.

Şimdi Agile, XP, Scrum, vb. Söyleyenler o belirli metodolojiler kategorisinin kırılganlığından bahsediyorlar. Tartışma şudur: Neden tüm kurallara uymak için disiplini olmayan bir kişi tarafından sabote edilebilecek bir metodoloji kullanılmalı? Soru geçerli bir sorudur; ancak, bu belirtidir, nedeni değil. Eğer doğru ve anlamlı (zor kısmı) bir dizi süreç metriği tanımlanırsa, test edilir ve zamanında geri bildirim verilirse, bence belirli metodolojinin başarı ile çok az ilgisi olduğunu keşfedeceğiz. (Anekdotsal olarak konuşursak, sayısız metodoloji kullanan başarılı projeler gördüm ve aynı metodolojileri kullananların iki katı başarısız oldu)

Peki metrikler neler? Projeden projeye, ekipten ekibe ve zaman zaman değişiklik gösterirler. Teslimat planının önemli olduğu durumlarda kullanışlıdır, kişisel olarak kullandığım tahmin yeteneği ve kalitesidir. Çoğu geliştirici, bir hafta veya daha kısa olan görevleri doğru bir şekilde tahmin edebilir. Dolayısıyla bir yaklaşım, projeyi geliştirici hafta süren görevlere ayırmak ve tahminleri kimin yaptığını izlemek. Proje ilerledikçe tahminlerini değiştirebilirler. Bir görev tamamlandıktan sonra,% 10'dan fazla (günde 1/2) kapalı ise, bunu bir hata ile aynı şekilde ele alırız - tahminin neden kapalı olduğunu (yani bir veritabanı tablosu dikkate alınmadı), düzeltici eylem (yani tahminde DBA'yı dahil edin) ve sonra devam edin. Bu bilgileri kullanarak haftada # tahmin hatası, geliştirici başına hata sayısı, KLOC başına hata sayısı, geliştirici-KLOC başına hata sayısı vb. Gibi metrikler oluşturabiliriz. yönetimsel bakış açısından, birkaç hafta sonra, sonraki geliştirme haftalarının tahmini bir modelini oluşturabilirsiniz.

Ne olmuş yani? İşte o zaman metodolojiler devreye giriyor - süreç kalitelerini karşılamayan öngörücü bir modeliniz varsa, metodolojinin bir yönünü eklemeyi veya kaldırmayı ve modelinizi nasıl etkilediğini görebilirsiniz. Elbette, hiç kimse başarısızlık korkusu için bir gelişim süreci ile oynamak istemiyor, ancak 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'ın ekibiniz için mükemmel bir metodoloji olduğunu fark edebilirsiniz, ancak ideal olarak RUP, şelale veya sadece en iyi uygulamaların bir karışımını bulabilirsiniz.

Dolayısıyla benim önerim, süreç dediğimiz şey hakkında endişelenmeyi bırakıp geliştirme süreci hedeflerimizle ilgili kontroller yapmamızı ve bu süreci geliştirmek için farklı teknikler denememizi sağlar.

2
TEC

Kovboy kodlayıcılar iyidir, çünkü işlerin çabucak yapılmasını severler. Genellikle büyük resim sorunları veya kod kalitesi ile ilgili değildirler, bu yüzden "kovboy kodlayıcı" genellikle bir epitettir. Yöntemleri, geç proje teslimi için fırsat maliyeti risklerini azaltır.

Kovboy olmayan kodlayıcılar işlerini güvenli, disiplinli ve düzenli bir şekilde yapmaktan hoşlanırlar. Doğru inşa etmeyi ve bir kez inşa etmeyi severler. Sonsuza dek bilgi toplayıp, ne olursa olsun, kimsenin okumadıkları büyük belgeler üreterek ve sistemleri geç veya çok geç teslim ederek sonsuza dek bilinirler. Yöntemleri düşük kaliteli yazılım risklerini azaltmaya çalışır.

Agile metodolojilerinin parlaklığı, kodlayıcılardan hızlı bir şekilde küçük yüksek kaliteli iş parçaları üretmelerini isteyen kısa zaman sınırlı çalışma iterasyonlarını zorlayarak her iki kodlayıcı tipinin gücünü kullanmalarıdır. Ve her bir yineleme hem geç teslimatın fırsat maliyet risklerini hem de düşük kaliteli yazılım risklerini azaltır.

1
Jay Godse

Kimsenin kendilerini kovboy kodlayıcı olarak düşünmemesi çok komik. Bahse girerim posterlerin çoğu vardır ya da olmuştur;)

1
user5206

Burada güzel bir üst düzey şartname ile oturmak ve başka bir şey ya da öylesine düşünmek gibi bir şey kırpmak gibi her iki günde bir aynı ekran ve işlevselliği tekrar ziyaret etmek zorunda değilsiniz.

Bu, meslektaşımın üzerinde çalıştığı "çevik" proje deneyimiyle uyuşuyor gibi görünüyor (hiç bir zaman kendimde olmadım): bazı spesifikasyonlara bir parça kod yazması isteniyor, daha sonra test etmeyi bitirdiğinde ve değiştirmeye ve yeniden test etmesini gerektiren yeni bir gereksinim ortaya çıkmaya hazırdır. Sinir bozucu buluyor.

Çevikliği vurmuyorum, takımın çevikliğini düzgün yapmadığından şüpheliyim - ama dediğin gibi, "çevik" terimi bazen kovboylar tarafından sivri başlı yönetimin yarı pişmiş tasarımın olumsuzdan ziyade olumlu olduğuna ikna etmek için kullanılabilir. .

1
Tony Andrews

Çevik tasarımın ön tasarım/spesifikasyonlara çok az vurgu yapmasının nedeni sadece gereksinimlerin değişebilmesi değil. Daha derin nedeni, gereksinimler istikrarlı olsa bile, spesifikasyonların:

  • yanlış - gereksinimleri yakalayamıyor.

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

  • müstakil - çalışan (dejenere olmasına rağmen) bir sistemden değerli geri bildirimler içermezler.

0
Itay