Geç Agile metodolojilerinde bir anlamı var mı?

Bu, başka bir sorunun ( bu soru ) cevaplarının ve yorumlarının bazılarından ortaya çıktı .

Öncelikle şelale projeleriyle çalıştım ve çevik davranışlar üstlenen ve çeviklik hakkında oldukça fazla şey okuyan geçici projeler üzerinde çalışırken, asla "uygun" çevik bir proje üzerinde çalışmadım diyebilirim .

Benim sorum, "geç" kavramının çeviklikte bir anlamı var mı?

Benim akıl yürütme çevik ile hiçbir ön plana sahip ve başlangıçta hiçbir ayrıntılı gereksinimleri olmasıdır. Aklınızda yüksek bir hedef olabilir ve ona bağlı bir tarih olabilir, ancak her ikisi de değişebilir (potansiyel olarak büyük ölçüde) ve ikisi de kesin değildir.

Dolayısıyla, teslim edene kadar temel olarak ne teslim edeceğinizi bilmiyorsanız ve kullanıcı kabul ederse ve bir sonraki sprint'in ötesinde bir programınız yoksa, herhangi bir şekilde nasıl geç olabilirsiniz? aslında bir anlamı var mı?

(Açıkçası anlıyorum ki bir sürat aşımı olabilir ama bunun ötesinde konuşuyorum.)

Açıkça söylemek gerekirse (şahsen) zamanında şelale projelerinin (nispeten büyük olanlar bile) onları gördüğüm ve onlara dahil olduğum gerçeğine dayanarak mümkün olduğu varsayımından memnunum - kolay veya ortak değiller ama mümkün.

Bu çevikliği vurmak değil, onu anlamakla ilgili. Agile'ın faydasını her zaman son tarihler veya bütçelerle (ya da sadece dolaylı olarak) ilgisi olarak görmedim, bu kapsamla ilgilidir - çevik proje ekibinin kendilerinden önce önemli olduğunu düşünmektense gerçekten önemli olana daha yakın olmasını sağlar. bir şey gördüm.

Çevik bir projenin açık bir planı olmadığına katılmıyorum.

Deneyimlerim, iş analistlerinin, kullanıcı hikayeleri olarak sunulan ulaşılabilir gereksinimlerin ayrıntılı bir listesini bulmak için müşteriler ve geliştiricilerle tasarım toplantılarında çalışmak için oldukça fazla zaman harcadıklarıdır. Bunlar daha sonra deneyimli geliştiriciler tarafından eklenmiş uygun tahminlerle görevlere ayrılır.

Sprint / yinelemenin başında en önemli görevler belirlendikten sonra kodlama başlayabilir. Bu seçim süreci, projenin tamamındaki yinelemenin anlamını belirler ("Giriş işlemini inşa ediyoruz"). Ekibin çeşitli üyeleri, bu kullanıcı hikayesini gerçekleştirmek için gerekli çeşitli görevleri yerine getirir.

Yinelemenin sonunda, bu yinelemenin tüm kullanıcı hikayeleri tamamlanmış olmalıdır, yoksa geç kaldınız . Aynı şekilde, geliştirme her yinelemenin ve serbest bırakılan ürünün sonunda durabilmelidir. Tüm kullanıcı hikayeleri açısından tam olmayabilir, ancak yinelemede istenen kullanıcı hikayeleri tamamlanmıştır ve ürün bu sınırlara kadar çalışabilir.

Çevik bir metodolojide "geç", bir şelale metodolojisinde aynı anlama gelir: tahminler yanlıştı, kapsam ayrılan süre için çok büyüktü, beklenmedik zorluklar ortaya çıktı, müşteri yeterince duyarlı değildi, programcılar tembelleşti, makineler çöktü, köpeğiniz bayt kodumu yedi, vb.

ondan öğrenir ve bir sonraki yinelemeye uyarlanırsın

fark, bunun her 2-4 haftada bir olabileceğidir, böylece dersler öğrenilir ve süreç hızla ayarlanır

Evet, ancak 9 ay yerine 9 aylık-efsanevi-final-proje bitiş tarihini vurmayacağınızı bilmek sadece 1 ay sürecek.

Gerekçeniz, ön planların ve büyük projeler için ayrıntılı gereksinimlerin mümkün olduğu varsayımına dayanmaktadır. Bunu destekleyecek çok fazla kanıt olduğundan emin değilim. Belki de tüm korku hikayeleri anekdottur? Herhangi bir geliştirici, müşterinin tamamen kabul ettiği ve anladığı eksiksiz ve asla değişen spesifikasyonlarla çalışmak ister.

Bir tür taahhütte bulunduğunuzda, geç kalma riskiyle karşı karşıya kalırsınız. Bu çevik için de geçerlidir.

Ancak geleceği tahmin edemeyeceğinizi biliyoruz ve müşterinin fikrini sürekli değiştireceğini biliyoruz ve bunun iyi bir şey olduğu konusunda hemfikiriz. Bunu kabul edersek, tüm taahhütlerin hemen hemen her zaman yanlış olduğunu kabul etmeliyiz, bu da gecikmeyle ilgili soruyu cevaplamayı kolaylaştırır: Her zaman yanılıyoruz (erken ya da geç). Ne kadar iyi cilalanmış olursa olsun, her şey bir tahmin meselesi. Bozuk para atmak.

Bu, geliştiriciler olarak basitçe kabul etmemiz gereken bir şeydir ve bu açıdan, gecikme sorununun çok daha az önemli hale getirildiği başka bir çalışma yolu bulmaya çalışın. Perspektif değişikliği. Bunu yapmanın yolunun, mümkün olan en kısa zamanda, müşteri memnun olduğunda bırakma seçeneği ile çalışan bir yazılım sunmaya odaklandığını düşünüyorum.

Ve çevik olan budur. Gecikmenin bu rahatsız edici fikrini yönetmenin akıllıca bir yolu ve bununla elimizden gelenin en iyisini yapmak zorundayız.

Örneğin, geçerli yinelemenin başında yaptığınız taahhütleri yerine getiremediğinizde geç kalıyorsunuz. Bu beklenen bir durumdur ve bundan bir şeyler öğrenmeli ve bir sonraki yinelemede başarısız olma olasılığınızın azalması için işleminizi uyarlamalısınız. Bunu ele almanın en iyi yolu, yinelemeleri mümkün olduğunca küçük tutmaktır.

Çoklu yineleme planlaması, yani sürüm planlaması için, tamamlanmış yinelemelerden hesaplanan hızı kullanır ve verileri gelecekteki bir çıkış tarihini tahmin etmek için tahmin edersiniz. Bu konuda daha fazla ayrıntı için James Shores'in makalesini veya kendi (daha kısa) makalemi tavsiye ederim . Yine de bunun asla sağlam bir taahhüt olmadığını ve daha çok "bir sonraki özellikleri o tarihe kadar tamamlayacağımızdan% 80 eminiz" olduğunu unutmayın. Bu sizin bir tür geç kalmanıza neden olabilir, ama taahhüt sadece bir olasılıktır, bir gerçek değildir.

Şimdi bunu, her zaman çalışan yazılımı yayınlamaya hazır, tam özellikli ya da değil, çevik temel vaadiyle paylaşın. Bu, müşterinin sistemin yeterince iyi olduğunu düşündüğünde gelişmeyi durdurma özgürlüğü verir, bu da beklenenden çok daha erken gerçekleşebilir. Ayrıca, en son yinelemeden gelen gerçek geri bildirimlere dayalı olarak projeyi yeni yönlere almayı teşvik eder.

Yukarıdaki noktalar, herhangi bir müşterinin gelişimi tam olarak kontrol edebilmesi için yeterli olmalıdır ve umarım bu, çeviklik yöntemlerinde gecikmeyle ilgili soruyu cevaplar.

Agile SCRUM'da iki tür "geç" vardır>

1. Carryover - Bir sprint sonunda "Tamamlanmadı" hikayeleri, geliştiriciler bir PBI yapmak için "taahhüt", bu yüzden yapılmadığında, taşıma olarak kabul edilebilir.

2. Yol Haritası - Kuruluşunuzun bir yol haritasına sahip olduğunu ve tarihlerinin olduğunu varsayarsak, bu tarihler için ana çıktılar kaçırılırsa "geç" olarak düşünülebilir.