Agile ile başarılı olmak için neye ihtiyacınız var?

Çevik benimseme bazı kuruluşlarda başarısız olabilir, hatta şelalenin tek (gerçek) yol olduğu bir şirkette bile çalıştım, ancak sadece Agile'ı bir projede denediklerinden ve başarısız olduklarından.

Hala hatırlayan insanlara sorduğumda (ben küçüktüm) onlara gerçekten kötü bir kabus hatırlatıyormuşum gibi, kapandım.

Projenin neden başarısız olduğunu bilmiyorum. Web'de Agile'ın neden başarısız olduğu bazı şirketler var, ancak neden çoğunlukla ekonomik. Bu yüzden burada bazı geri bildirimler önermiş olduğumu düşündüm.

Çevik evlat edinmenin bazı kuruluşlarda başarısız olmasının nedenleri nelerdir? Ya da başka bir deyişle .. Agile ile başarılı olmak için neye ihtiyacınız var?

Agile düşünme biçimini ve Agile yöntemlerini anlamak ve desteklemek için her birine yönetim, müşteri ve geliştiricilere ihtiyacınız vardır. Daha ayrıntılı olarak:

• Yönetim, geleneksel olarak duymayı beklediklerinin aksine (yani, evet, proje yolunda ”11 ay boyunca, gerçeği duymakta rahat olmalı ... o zaman aniden” ay, son tarihi birkaç hafta ertelemeliyiz ... erm, ay ... erm ... "en sonunda). Ayrıca, her bir tarafın işini yapmasına (ve sorumluluk almasına) izin vermekten de rahat olmalıdırlar. En belirgin şekilde, geliştiricilerin teknik kararlar ve tahminler yapmaları gerektiğidir. Yani sıkı kontrol ve mikro yönetim yok.
• Müşteriler, Agile'ın sadece "sipariş vermek" değil, aynı zamanda birkaç ay sonra teslimatı almak için geliştirme sürecine derin ve sürekli katılımlarını gerektirdiğini anlamalıdır. Ayrıca, Büyük Sabit İhtiyaç Şartnamesi bulunmaması ve geliştirme ekibinin başlangıçta talep ettikleri şeyi teslim etme taahhüdünün eksikliği konusunda da rahat olmalıdırlar.
• Geliştiriciler sorumluluk almak, karar vermek, açık iletişim kurmak ve ekip olarak çalışmak konusunda rahat olmalıdır. Yani "kod sahipliği" yok, "yalnız kovboy" yok ve ekibin kendisi tarafından çözülebilecek sorunlar için başkalarının meyvesiz suçlaması yok.

Deneyimlerime göre, başarısız Agile projelerinin ardında yatan ilk nokta, ancak diğer ikisi de sorunlara neden olabilir.

Güncelleme

"Yönetim" ile sadece doğrudan proje yöneticisini değil, aynı zamanda daha yüksek seviyeleri de kastediyorum. @Michael'in çok haklı olarak belirttiği gibi, bazı az ya da çok dış taraflar (örneğin KG veya harici görev ataması) Agile projelerinin başarısını / başarısızlığını da etkileyebilir, ancak bunun ancak ilgili liderleri izin verdiği takdirde mümkün olabileceğini ve / veya kuruluş içinde sorumluluklar ve komut satırları net değilse.

Gerekenler:

• Çok açık ve dürüst olmak isteyen insanlar . Görünürlük her şeydir, çünkü her türlü katman sınırına güvenmeniz gerekir.
• Gerçeği gerçekten duymak isteyen müşteriler ve yöneticiler .
• Şu anda ihtiyaç duyulan şeylere uygun olarak rollerini yeniden tanımlamaya istekli ve istekli insanlar .
• Özgürlük çalışmayan süreçlerini değiştirmek için şu anda .
• Hataları kabul etmek ve tersine çevirmek isteyen insanlar .
• Yetenek inşa ve test ortamları birlikte atmak at will . (Bu, insanların kredi vermesinden daha önemlidir ve daha pahalıdır.)
• Duvarlarınızı doldurabildiğiniz kadar beyaz tahta.

Çok basit görünüyor, ancak bunların çoğu bu endüstride büyük sorular.

Çevik bir proje çoğunlukla, kilit bir oyuncu çevik olmayı reddettiğinde veya birisi projenin başarısıyla dürüstçe ilgilenmediğinde veya açıkça sabote ettiğinde başarısız olur. İkincisi herhangi bir projeyi öldürebilir (bir dizi başka şey gibi), ancak çevik süreçler insanlara daha fazla esneklik sağlar ve bu da yıkıcı siyaset oynama esnekliğini içerir.

Örnekler:

• KG, müşterilerin bir ay süren manuel test döngüsünü geçmedikçe yazılımı görememeleri konusunda ısrar ediyor
• Yönetim gerçekçi olmayan teslim tarihleri ​​getiriyor
• Müşteri gereksinimlerini öncelik reddediyor ( "onlar bütün yüksek önceliğe sahiptir!")
• Anında pay sahibi olmayan ancak siyasi nüfuz sahibi olan biri, kilit bir ekip üyesine uzun, ilgisiz görevler vermeye devam ediyor ve proje yöneticisi bunu engelleyemiyor.

Tavsiyemi sadece kendi kişisel deneyimlerimden verebilirim.

Agile'da tamamen başarısız olduğum bir işveren. İş geçici olarak yapıldı, test mevcut değildi ve gereksinimler e-postalarda ve toplantı tutanaklarında belgelendi. Kullanılan tek geliştirme yöntemi anarşi veya 'ateşle ve unut kodlaması' idi. Geliştiriciler bir tür hikaye izleme proje yönetimi yazılımı kurmak için çok fazla çalıştıkları için bir tür yazılım mühendisliği yöntemi uygulamak imkansız olurdu.

Başka bir işverende, ekibimiz çaresizce bazı Çevik en iyi uygulamaları kurmaya çalışan bir kahraman üyeye sahipti - bir Kanban yönetim kurulu vardı, sorun izleme, TDD ve BDD kullandık (kendi içlerinde Çevik olmasa da, Agile gruplarında bulunma eğilimindeler) . Ne yazık ki, hikaye noktaları, tahmin oturumları, kapasite planlama, yazma çizelgeleri, hız grafikleri - işin sorunsuz bir şekilde akmasına izin veren yararlı Agile proje yönetimi türlerinden yoksundur. Klasik Agile belirtisi yanlış gittiğinden, Kanban panomuz çok dolduğunda daha büyük bir tahta aldık: /

Şu anda bulunduğum yer, iki haftalık yinelemeler, TDD, günlük standup'lar, yinelemeli yinelemeli zaman kutulamalı retrospektifler ve çoğu şeyde çift programlama ile kapasite planlama yöntemi olarak hikaye noktalarını kullanıyor. Bu, toplam yönetim katılımı ve müşteri eğitiminin bir sonucudur.

Agile'nin bir şirkette başarılı olabilmesi için aşağıdakilere ihtiyacınız olduğunu düşünüyoruz:

• Çevik'i anlayan ve araçları uygun şekilde kullanacak proje yöneticileri.
• Agile'yi açık ve dürüst olan Agile disiplini ile anlayan geliştiriciler
• Müşteriden satın alma. Agile'ın faydalarını tanımalılar ve belirli bir zaman dilimi içinde nelerin geliştirilebileceği konusunda geliştiricilerinden tavsiye almaya istekli olmalılar.

DÜZENLEME: Günlük stand-up'lar ve kısa yinelemeler gibi nedenleri iyi anladığınızdan emin olmak da çok önemlidir.

Çevik başarısızlıkla ilgili deneyimlerimin ekonomi / şirket / departman / kişisel politika ile ilgisi yoktu.

Kişisel düzeyde, sadece kişilikleri çatışacak bazı insanlar var. Onları Agile ekibine zorlamak, hatta daha da kötüsü eşleştirilmiş bir programlama ekibi, birbirlerinden hoşlanmamalarını bir kaynama noktasına yükseltir. Bu çok kötü, çok çabuk olabilir ve bir gerçeklik şovuna layık sabotaj eylemleri, scrum toplantılarını dairesel bir ateşleme takımına veya daha da kötüye dönüştürebilir.

Bunun üzerinde geliştirme yönetimi var. Bunun iki farklı şekilde yanlış gittiğini gördüm.

Birincisi, yöneticinin manifestoyu ve okudukları her türlü sınıf / kitap / web sitesini neden ve ne zaman kullanacaklarını ve ne zaman doğaçlama yaptıklarını anlamadan ısrar ettiği 'kargo kültü Agile'. Agile yöneticisi büyünün gerçekleşmesini bekliyor çünkü büyüyü tam olarak takip ediyorlar. Agile'nin bu procrustean uygulaması, proje başarısızlığına yol açacak bir takım sorunlara yol açabilir.

Diğeri, sprintler ve scrum gibi terminolojinin kullanıldığı, ancak sadece mikro yönetim, sahtekârlığın hem komuta zincirinde yukarı ve aşağı gidiş, uzun yararsız statü toplantıları ve benzeri şeyler üzerindeki etiketler olduğu 'Sadece Agile In Name'. . Projeler eskisi gibi başarısız oluyor ama şimdi Agile kötü yönetimden ziyade suçlanabilir.

Yukarıda, projenin müşterisi / müşterisi tarafından satın alma eksikliği vardır. Bu insanlar kendi departman önceliklerine sahip olacaklar ve yönetim tarafından işlerinin önemli bir parçası olduğu açıkça belirtilmedikçe bir geliştirme ekibi ile çalışmaya karşı dirençli olabilirler. Bu, bölüm politikaları veya şirket politikaları ile daha da kötüleşebilir. Örneğin, hem operasyonlar hem de pazarlama bir projeye girdi ve iki taraf hiçbir şey üzerinde anlaşamadığı için ekibiniz tekerleklerini döndürüyor. Diğer bir örnek, zaman yönetimi ve faturalandırmaya ilişkin kurumsal politikanın çatışmalara neden olmasıdır. Aslında dış müşterilerin başa çıkmanın iç müşterilerden daha kolay olduğunu gördüm. Süreçten aldıkları ilgiyi beğendiler ve paralarının karşılığını aldıklarını biliyorlardı.

IMO "Agile" uygulamaların toptan alımı olmadığında başarısız olur. Demek istediğim, Agile'ın "müşteri" ye (genellikle başka bir departman ya da yönetici) aşağıdakileri anlaması gerektiğidir:

1. Yazılımın ne yapmasını istediklerini% 100 bilmiyorlar, yaptıklarını düşünüyor olsalar bile
2. Yaptıklarını düşünüyor olsalar bile, ne kadar sürede tamamlanmaları gerektiği konusunda hiçbir fikirleri yok
3. Onlara ne kadar sürecekleri ve bunu kabul etmeleri ya da bir son tarihe ulaşmak için özellikleri azaltmaları gerektiği söylenecektir
4. Onlar özelliği mevcut her yineleme seçmek zorunda kalacak ve olacak değil tek seferde tam,% 100 tamamlandı uygulamayı olsun.

Bunların hepsi çoğu yöneticinin yutması için çok zor şeylerdir ve IMO'nun Agile yapmanın zor olmasının 1 numaralı nedeni - yöneticiler "x tarihe kadar yapılacak" ve o tarihe kadar "Büyülü" yapılacak (geliştiriciler 80 saatlik haftaya koyduktan sonra) ve geliştirme ekibinin bu projenin 3 ay içinde yapılacağını söyleyeceğini anlamak 180 , ve sahip olduğunuz tek seçenek onu kabul etmek veya almak için gereksinimleri azaltmaktır. daha erken yapıldı.

İkincisi, geliştirme ekibine güvenmek gerekir. Yukarıda # 1 ile el ele giderek, çok az yönetici aslında uzman olarak işe alınan insanların görüşüne güveniyor gibi görünüyor; bir geliştirici bir projenin x zaman alacağını ve x'in yönetimin düşündüğünden daha fazla olduğunu söylüyorsa, asla "Yazılımın nasıl yazılacağını bilmiyorum, dolayısıyla geliştirici büyük olasılıkla daha fazla" Bu işe yaramaz geliştiriciler, işten vazgeçmek istiyorlar, böylece 3 ay süreceklerini söylediler ".

Üçüncüsü, geliştirme ekibinizin Agile arkasında olması gerekir; bu, köşeleri kesmemek ve sürekli geri bildirimi ve "Bu doğru mu? x olduğunda Y ne yapmalı?" sorusunu göz ardı etmemek anlamına gelir. TDD veya Çift Programlamayı izlemeseniz bile, geliştirme ekibinizin çevik süreçleri (örneğin sprintler, iterasyonlar) takip edecek kadar yetkin olması gerekir. Bu, görevleri doğru bir şekilde tahmin edebilen ve her özelliği bir öncelik haline getirmeniz gerekmediğini anlayan bir lider / yöneticiye sahip olmayı içerir, bir iş biriktirme işine sahip olmak sorun değildir ve insanları fazla çalıştırmamalısınız.