Çevik yazılım geliştirmeyi bu kadar çekici yapan nedir?

Çevik yazılım geliştirme bugünlerde oldukça eğlenceli bir terim haline geliyor.

Bir geliştirici olarak, yinelemeli gelişimin pragmatik değerini anlıyorum, ancak (çoğunlukla) yazılım geliştirmeye Agile yaklaşımını benimsemek bir geliştirici tercihi değildir. Yukarıdan aşağıya bir yönetim seçimi! Kristal, çevik yöntemler, dsdm, rup, xp, scrum, fdd, tdd olsun. Bir geliştirici seçimi değil.

Dışarıdaki tüm yöneticiler için , (tecrübelerime göre) çoğu yönetici hayatlarında bir parça koda dokunmadığında Agile geliştirme yapmayı seçmenin en büyük nedenleri nelerdir !

Vites değiştirme gereksinimleri, daha hızlı teslimat

Agile caziptir çünkü değişen ihtiyaçlara daha hızlı (veya hiç) adapte olma ve bu değişiklikleri müşteriye daha hızlı teslim etme imkanı verir.

Bu nedenle Agile / Scrum kullanırken birçok şirket başarısız oluyor: Yöneticiler, büyük bir güçle (daha hızlı yayın tarihlerini belirleme ve gereksinimleri sık sık değiştirme) tahminler için geliştiricilere güvenme sorumluluğunun geldiğini anlamıyorlar . Agile'ın çalışması için yöneticinin kapsamı kesmeye istekli olması gerekir.

İkisinin de gücünü istiyorlar.

Trendleri takip etmek

Bazen insanlar bir şeyleri yaparlar, gittikleri şeyin değeri nedeniyle (çevik) değil, sadece popüler olduğu için ve diğer insanlar da aynı şeyi yapmaya çalışırlar.

"Ne? Macrojam Agile yapıyor? Neden değiliz? Yavaş değiliz, Agile'yiz, kahretsin!"

Bazı insanlar çevik olmanın gerçekte neyi gerektirdiğine dair iyi bir lanet vermez. Sadece varlıklarını haklı çıkarmak için bir araçtır. Koyun, akran baskısı vb.

Kodlamanın kendisi, yöneticilerin bir yöntem olarak çevik seçmeye ikna edilmesinin başlıca nedeni değildir. Değişen gereksinimlere ve önceliklere daha hızlı tepki verebilmeniz caziptir. Sondaki 'yönetici' son kullanıcıya / müşteriye / yöneticisine bir çözüm sunmalıdır.

Projeyi başlatırken önemli görünen fonksiyonlar projenin ortasında kaldırılabilir ve yerine yeni, daha ilgili gereksinimler getirilebilirse, bu büyük bir avantajdır.

Ayrıca önemli olan, çoğunlukla (örn. Scrum'da olduğu gibi) her bir ara teslimatın üretime hazır hale gelmeye neredeyse hazır olması gerekir. Aynı zamanda, en acil fonksiyonlar önce geliştirildi. Bu nedenle, bazı kurumsal kararlar nedeniyle projenin iptal edilmesi durumunda, yönetim işe yarayacak ve üretilebilecek bir şeyle sonuçlanacağınızdan emin.

Bu yardımcı olur umarım.

Neler olup bittiğine ilişkin görünürlüğü artırın ve verimliliği artırın

1. Yöneticiler genellikle çeviklik, özellikle scrum gibi görünürlük ile ilgilenir . Yöneticileri hedefleyen seminerlerde en çok kullanılan satış noktalarından biri.

2. Gösterilmesi kolay olduğu için (görünürlük sayesinde) yüksek verimlilik de onları çekmek için yaygın olarak kullanılır. Bazı çevik evangelistler onlara mevcut çalışanlarından olağanüstü verimlilik vaat ediyor. “Ne? Onlara zaten limon gibi bastırıyorum ve sen bana daha da fazlasını alabileceğimi söylüyorsun ” ?

Birçok yönetici, çalışanlarını biraz daha fazla ezmek için çevik kullanıyor ve onları büyük bir şirkette daha yavaş bir avcılık makinesi olarak yakma tablosunu kullanarak gördüm.

Sonuç? Birçok ekip distress. Çeviklerin tüm sorunlarını çözeceğini düşünüyorlardı, ama tam tersini yaptı. Sorun başka bir yerdeydi.

Ben aktif olarak buna karşı savaşıyorum. Bu yüzden bazen çevik metodolojiden daha yüksek bir olasılık olduğu zaman pervertedyönetim tarafından gerçekleşirse, şirket içinde bundan bahsetmemenizi öneririm.

Bu sorunun cevabı bir kitabı doldurabilir.

Bence ana nedenlerden biri çevik gelişimin teslim edilebilirliğe odaklanmasıdır. Daima burada ve şimdi en acil olanı vermeye odaklanır.

Diğer bir neden, çevik süreçlerin izlediği hikaye tabanlı planlama ve tahmin uygulamalarının neyin ne zaman ve ne zaman verilebileceğine dair çok daha iyi bir tahmin vermesidir.

Hikayeye dayalı planlamanın ne kadar etkili olduğuna iyi bir örnek çalıştığım bir projedir. Birkaç ay boyunca (çevik gelişimi kabul etmeden önce), proje lideri zamanında teslim edebileceğimize inanıyordu ve bu süre son teslim tarihinden itibaren yaklaşık 18 aydı. Tüm geliştiriciler muhtemelen gerçekçi olmayan bir duyguya sahipti. Çevik planlamaya başladıktan sonra, proje lideri hala durumun iyimser bir değerlendirmesine sahipti. Ancak sadece birkaç sprintten sonra, proje lideri ekibin tüm gereksinimleri beklenen zamanda sunma kapasitesine sahip olmadığını fark etti. Ve bu son teslim tarihinden itibaren 12 aydan fazla bir süre geçti.

Bu yüzden çevik uygulamalar gerçekliği daha erken netleştirir.

Ve son olarak, çevik ekipler daha iyi kod kalitesi oluşturan uygulamaları, örneğin test odaklı geliştirme, sık yeniden düzenleme, sürekli entegrasyon, akran kodu gözden geçirme / çift programlama vb. o kadar odaklanmış olmayın.

çoğu yönetici hayatında bir koda bile dokunmadı!

12 yıldır bir geliştiriciydim ve şimdi 5 için bir yöneticiydim. 5 yıl boyunca, hala saf bir yönetici olarak kodlanan bir yöneticiden aşamalı olarak geçtim (hala zaman zaman hataları düzeltirim veya prototip egzersizleri yapıyorum).

Çevik geliştirme yapmayı seçmenin en büyük nedenleri nelerdir?

• Görünürlük veya Hızlı Başarılı / Hızlı Başarısız - 6 aydan 24 aya kadar döngüleri olan bir ürün geliştirme mağazasıyız. Çalışma, test edilmiş özellikler ile yinelemeli geliştirme, proje durumunu yansıtmada daha iyi bir iş çıkardı.
• Değişim - Ortamımızda gereksinimler ve zaman sabit olma eğilimindedir. Ancak, iş çok düzenli bir şekilde hızlı, sarsıntılı değişiklikler yapıyor. Yinelemeli, görünür gelişme, projelerin yön değiştirmesini kolaylaştırdı.
• Hikayeye dayalı gereksinimler, yinelemeli geliştirmeyle, gereksinimlerin teknik yönlerini her zaman anlamayan veya bazı ayrıntıların iş sürücülerini tam olarak anlamayan işlerle çalışmayı kolaylaştırdı. Geçmişteki çabalarımızda, üst düzey spesifikasyonlar veya pazarlama gereksinimi belgeleri her zaman yeterli değildi. Şimdi, projeler geliştikçe, bazı paralel pazar ve müşteri araştırmaları olabilir.
• Süreç değişikliği, TDD, otomatik ve manuel test, daha sıkı test döngüleri (artık bir QC grubumuz yok, sadece bir QA grubumuz yok) ve kaliteye ilişkin daha yüksek bir takdir ve çaba gibi diğer birçok geliştirme özelliği ile geldi. çok daha fazla araç ve metrik).

Bunu başka şekillerde başarabilirdik, ancak çevik metodolojilerden ve fikirlerden yararlanmak bize çok yardımcı oldu.

Ayrıca sürecimizi geliştirmeye devam ediyoruz. Örneğin, ön tasarım çalışması ile uygulamanın hemen önündeki tasarım arasındaki denge. Geçmiş tasarım kararlarını erteleyip erteleyemeyeceğimizi belirlemek için tüm kararlarımızı düzenli olarak inceleriz. Ve işler ters gittiğinde, hata tespit edilinceye kadar ne kadar daha fazla ön çalışma gerekli olurdu. Çoğu zaman, başarısızlıklar derin analiz gerektiren köşe vakalarıdır. Bu ayrıntıyı ortaya koyma çabası genellikle yol boyunca çözme ve yeniden düzenleme maliyetiyle aynıdır. Takımlar bu tür hatalar nedeniyle cezalandırılmaz ve daha agresif olmaları teşvik edilir.

Çevik "yapan" birkaç şirket gördüm. Ne yazık ki, çok azı çevikliği benimser . Demek istediğim, sadece yinelemeli gelişim yapmak ve günlük takımlar (ekibin çoğunun oturduğu yer) takımı Çevik yapmıyor. TDD, Yeniden Düzenleme, Sürekli Entegrasyon, Müşteri Varlığı, SOLID uygulamaları ekibi Agile yapar. Bunlar olmadan, sadece daireler çiziyorsunuz.

Agile'nin mesajının getirdiği çok fazla çekicilik var. Değişime uyumun en büyük olması. Ne yazık ki, kodunuz sadece projeyi yönetme şeklinizi değiştirdiğiniz için daha uyarlanabilir hale gelmiyor. Daha fazla şirket bunu fark edinceye kadar, daha fazla başarısız çevik projeyi duyacağız.

Vızıltı kelime kısmı hakkında bilmiyorum. Bunu başından beri resmi olmayan ya da tanımlanmış bir süreçte yapıyorum. Müşteriler, web sitelerini oluştururken tam anlamıyla omzuma baktım. Yaklaşık 50 e-posta kaydetti ve müşteri bu işlem hakkında bir şeyler öğrendi - bu kolay değil.

Kullanıcının yazılımın yapmasını istediği her şeyi yazmak için uzun bir süre alacağımız düşüncesi, daha sonra, uygulamayı denedikten sonra sadece 2 saniye içinde keşfetmek istediklerini düşündüğümüz şeyi oluşturmak için daha uzun bir süre alacağız. bekledikleri gibi değil bulantı. Herhangi bir projeyi veya uygulamayı başka bir parça inşa etmeden önce inşa etmek ve geri bildirim almak için bazı makul parçalara ayırmak ne kadar zor?

Bunun aşırı basitleştirme olduğunu ve gerçek geliştirici uygulamalarını ele almadığını biliyorum, ancak en teknik olmayan yöneticiye veya müşteriye bile satmak zor değil. Başka hangi yaklaşım daha caziptir? Müşteriler, programcıların bir şelale projesi sırasında gelişirken 6-12 ay boyunca saçlarından çıkmalarını gerçekten seviyorlar mı? Bu şekilde bir ev inşa etmek için birini işe alır mısınız?

Yönetim bunları geliştiricilere zorlamaz. Geliştiriciler ve ekipler inisiyatif almalı ve işlerini daha iyi yapmak için onlara doğru çaba göstermelidir. Yönetimin işi bu girişimlere destek sağlamaktır.

Kariyerimde adil bir kod yazmış bir yönetici olarak, buna cevap vermek için aradığınız kişi olmayabilirim. Her halükarda, bu günlerde Agile'a çekmenin, müşteri ihtiyaçlarına daha hızlı yanıt vermenin yanı sıra şartname, kodlama, test ve müşteri arasındaki geri bildirim döngüsünü kısaltmakla ilgili olduğunu düşünüyorum. Bu sebeplerden dolayı daha Çevik gelişmeye doğru ilerliyoruz.

Bence Çevik süreci ve kodlama / geliştirme uygulamalarını karıştırmamalısınız. Örneğin, Scrum size kodunuzu nasıl geliştirmeniz gerektiğini söylemez - her şey değişiklikleri memnuniyetle karşılayan süreçle ilgilidir.

Günün sonunda, geliştiriciyi güçlendirmekle ilgili; bu, hiyerarşinin en altındaki bu adamların ne yapılması gerektiğini ve nasıl yapılacağını gerçekten anlayan tek kişi olduklarını kabul etmekle ilgilidir, bu yüzden onları uzmanlıkları için zaten işe aldıysanız - neden Tam kontrolü ele almalarına izin vermemek veya daha doğrusu, neden gerçek karar alma süreçlerinden uzaklaştırma