Çevik yanlış giderse [kapalı]

Son zamanlarda görüştüğümüz bazı yeni adamlar için Çevik bir kurs yazıyorum ve Çevik'in tüm projeler için olmadığını anladıkları için uyarıcı bir hikaye eklemek istiyorum.

Benim sorunum, Agile ile birlikte çalıştığım projelerin doğası gereği, şu ana kadar oldukça iyi çalıştığı için neyin yanlış gidebileceğini ve neyi yanlış bir projede kullandığınızı dürüstçe belirtemiyorum.

Çevik bir proje yanlış gittiğinde nelere dikkat edilmeli?

"Çevik" ekiplerin en büyük başarısızlığı, Kargo Danışmanlığı denilen şeyin bir sonucudur . Temel olarak, takımlar başarılı çevik ekiplerin etkilerini istiyorlar, bu yüzden görünür eylemleri taklit ediyorlar

• Günlük standups (bir saat kadar devam eder)
• İşi sprintlere bölmek
• Kullanıcı hikayeleri (genellikle bir cümleden biraz daha küçük ancak bir tahmin beklenir)

Bunlar, bu ortamlarda tutarlı bir şekilde "uygulanmış" olduklarını göreceksiniz, ancak gerçekte çevik olmalarına çok az bağlılık. Aslında yönetimin “çevik” olduğumuzu söylediğini duyacaksınız. (Bu iki kelimeden kaçın, bu kötü bir işarettir.)

Ayrıca teknik borç hakkında çok şey duyacaksınız, ancak teknik borç tanımları "hızlı ve kirli yapın ve belki daha sonra daha iyi hale getirmek için etrafa bakacağız." (Tercüme: Sürdürülebilirlikle ilgileniyormuşuz gibi ses çıkaracağız ama gerçekte aynı kazan dairesi zihniyetini koruyacağız çünkü geçmişte bizim için işe yarayan şey buydu).

Diğer önemli ifadeler: "Bu hikayelerin tam olarak tanımlanmadığını biliyorum ama çevik davranıyoruz, böylece gittikçe düzeltebiliriz."

“Çevik geliştirme yapıyoruz, bu yüzden tanımladığım gibi sprint içinde ihtiyacım olanı da karşılayabiliyor olmalısınız.”

“Sprintin başlangıcında taahhütlerimizi kilitleyemiyoruz, çünkü ihtiyaçlar sprintin ortasında değişmeye devam ediyor.”

Çevik bir projenin başarılı olup olmayacağının ana göstergesi, proje liderinin (scrum master veya her hangi bir rol) çevik bir projeye liderlik etme konusunda tecrübeli veya resmi bir eğitime sahip olup olmadığıdır. Çok sık insanların bir kitapta Çevik'i okuduğunu ya da bir dolandırıcılık ustası olma konusunda iki günlük bir kurs aldıklarını ve başarılı bir şekilde uygulamak için pirzola sahip olduklarını düşündüm. Maalesef kaptan olmadı.

Çevikliğin ne olduğunu (?) Anlamayan ve bunu uygulayan kişiler:

• Son teslim tarihine kadar yorum yapamayan müşteriler
  ... ve sonrasında yasal işlem yapılmasını tehdit ederler ;

• geliştiricileri müşteriden uzak tutan yöneticiler (muhtemelen biraz para ödediklerinden ve gemileri atlayabildiklerinden, söz konusu müşteri için çalışacaklarından) ve umutsuz (genellikle başarılı olsalar) girişimlerinde " bozuk telefon " oyununu oynayabilirler meşgul ve kullanışlı görünmek,

  Ayrıca bakınız: mantar yönetimi , aka "belirsiz, gübre beslenir" ve sivri saçlı patronlar . :)

• bir yere gidemeyecek kadar büyük olan takımlar ;

• Muhteşem, pratik olmayan, gerçekleştirmesi zor, UML sagrada familyalarını fazla abartmak suretiyle, gerçek kodlama teknesini gözden kaçırdıkları gerçeğine dikkat çekmeyen, bir zamanlar ünlü sistem mimarisi tasarımcılarının maaşlarını elinde tutan şirketler .

Çevik, sabit vadeli veya sabit fiyatlı sözleşmeler için uygun değildir. Böyle bir canavara kaydolduktan sonra, teslim etmek zorundasın. Çevik, müşterilerin fikrini değiştirmesi ve gereksinimlerini “netleştirmesi” nedeniyle, sürekli gelişim için çok iyidir. Bu, paranın tükendiği gün size yardımcı olmuyor, ancak yine de işi bitirmek zorunda.

Ancak, aşamalı güncellemeler ve hata düzeltmeleri yaparken çevik proje sonrası aşama için çok iyidir.

Agile'nin başarısız olduğu diğer bir konu ise, çevik proje hatası, ön tasarımları ve zayıf iletişim hatları gibi tüm eski şeyler konusunda ısrar eden insanların suçudur. ( Yarı silahlı çevik manifesto ).

İşte, Çevik'te yapılan bir girişimin başarısız olabileceği bir örnek bulma açısından bir cevap aramaya yarayabilecek birkaç soru:

• Çevik yeni mikro yönetim mi?
• Çevik süreç: nasıl ve ne belgelenmelidir?
• Yeni bir projede planlama ve programlamanın doğru karışımı

Hiç "sözde Çevik" duydunuz mu? İşte bununla ilgili birkaç blog girişi:

• Sözde Agile'den Şelaleye - Küçük ve yeni bir yazılım şirketinin yolu
• Sahte Çevik!

Çevik olanın ne olduğuna dair kendi görüşlerini alabilen ve onu başka bir şeye kesebilecek şirketler için söylenecek bir şey var.

Son derece başarılı bir Çevik ekiple ve Çevik girişimde bulunan birkaç kişinin üzerinde çalıştım, ancak işe yaramadı.

Başarılı olan şu unsurlara sahipti:

• Gerçekten "Çevik" gereksinimleri. Kullanıcı hikayeleri vardı ve biz de kodladık.
• Mevcut ürün sahibi. Kodladığım bir kullanıcı hikayesi eksikse, ürün sahibine kolayca gidebilir, orada ne olması gerektiğini sorabilir, ekleyebilir ve kodu tamamlayabilirdim.
• Sürece bağlılık ve bunun bir öğrenme eğrisi olduğunun farkına varma.
• Odaklanmış takım
• Çalıştırmak için kararlı olan şeyleri yapmanın Çevik yolunu bilen ve anlayan yöneticiler.

Başarılı ekip Çevik yaptı ve çok iyi yaptı. Yukarıdaki noktalardan herhangi birine sahip değilseniz, oldukça kolay bir şekilde başarısız olabileceğinizi düşünüyorum. Birinci ve ikinci şeyler el ele gider ve eğer sizde yoksa Agile çalışmaz.

Üzerinde bulunduğum takım Çevik bir şey yapmadı, birkaç elementi de vardı:

• Yönetimden bağlılık eksikliği. Yönetim felsefeye inanmadı ve sonuç olarak karar vermekte tereddüt ettiler.
• Gereksinimler, kullanıcı öykülerinden başka yerlerde belgelenmiştir. Yönetim taahhüdü hakkında yukarıya bakın. Ayrıca, yüksek oranda ödeme gereksinimi analistleri ve birinin kullanımını haklı çıkarmak için ihtiyaç duyduğu büyük pahalı gereksinim araçlarına sahip olduk.

Tecrübelerime göre çevik ve özellikle Scrum’ın ancak yönetim ve ekip olup bitene çok fazla görünürlük getirmek istiyorsa işe yarayacağını bildiren harika cevapları ekleyeceğim.

Bu, kamu şirketlerinde (örneğin hükümetlerde), düzgün çalışmasını sağlamak çok zor olacağı anlamına gelir.

Benim düşünceme göre çeviklik, pratik yapan ekibin kültürüyle ilgili. Kültür berbat olursa, ekip üyeleri iyi geçinemez ve insanlar sprint taahhütlerini yerine getirmek için işbirliği yapmazlar, o zaman kültür veya ekip eksik kalır.

Şelalenin mutlaka böyle bir ortamda çalışacağını söyleyemem, bu siyah beyaz bir durum değil, çok az gerçek siyah beyaz.

İyi bir Çevik ekip ortaktır. Bütün üyelerin aynı amaçlara yönelik çalıştığı bir kabile topluluk ruhuna sahipler. Takım birlikte başarılı veya başarısız olur. Sorunları çözmek için birlikte çalışırlar. Bir ekip üyesi, mücadele eden bir ekip üyesine yardımcı olmak için görevleriyle yaptığı şeyi durdurur. Her şey batıyor ya da yüzüyor.

Durum böyle olmadığında, yanlış olan ne varsa hızla ortaya çıkıyor. Eğer ekip üyeleri oturuyorlarsa, dizüstü bilgisayarlarına veya mesajlaşmalarına yazıyorlarsa veya günlük stand up sırasında zon yapıyorlarsa, o zaman iyi bir Çevik ekibiniz olmaz. Eğer proje yöneticileriniz tüm Scrum prosedürlerini, tanımlarını ve terminolojilerini uyguluyorlarsa, fakat herkes sadece temposunu koruyor ve dudak hizmeti ödüyorsa, o zaman bu sadece Çevik'in gerçekte ne olduğu konusunda oldukça açık bir zorluktur ve bu birçok yönden takım işlevsizliğine neden olur. , teslim tarihlerini ve başarısız projeleri kaçırdı.

Faile Agile, pek çok açıdan orta derecede başarılı bir Waterfall ekibinden çok daha kötü durumda ve muhtemelen daha düşük proje başarı oranlarına sahip.

Bunu kişisel deneyimimden bilmiyorum, ama varsayımsal olarak çevikliğin en iyi seçenek olmadığı durumlar vardır.

• Ürünü hayati veya mülkiyeti kritik olan projeler - Örneğin, kalp pilinizi çalıştıran yazılımı geliştirmek için çevik kullanmak istemezsiniz. Niye ya? Çünkü hatalara sıfıra yakın toleransınız var. Therac 25 ile ilgili olarak tıp içindeki klasik bir programlama hatası örneği düşünün . Kabul edildi, çevik olarak inşa edilmedi, ama mesele şudur: Hayatı veya mülkü kritik hale getirmek, “bir sonraki adımda temizleyeceğiz” veya “harika, ihtiyacımız yok, sadece iyi” diyecek bir yer değil. yeterli."

• Çok sayıda küçük geliştiriciye sahip projeler - Agile, katılımcı grupta belirli bir miktarda özerklik beklemektedir. Takımda yeterince deneyim yoksa, otonomi size karşı çalışabilir.

• Agile ile geleneksel olarak sunulanlardan daha yüksek düzeyde kontrol veya planlama gerektiren projeler.

Sanırım ya başkasının atlayıp daha iyi örneklerle yardım edeceğini ya da yazdığım bu işkencenin aşağısını azaltacağını farz ediyorum ;-).

Unutmayın, sahip olduğunuz tek alet bir çekiç olduğunda, her sorunun bir çivi gibi göründüğünü unutmayın. Tüm projeler çivi değildir.