Scrum, gereksinimlerin değişmediği projeler için ek yük yaratıyor mu?

Scrum'u okuyorum - Gunther Verheyen'in Cep Kılavuzu ve şöyle diyor:

Standish Group'un 2011'deki Kaos raporu, bir dönüm noktası oldu. Çevik yöntemleri kullanan projelerle geleneksel projelerin karşılaştırılmasında kapsamlı araştırmalar yapıldı. Rapor, yazılım geliştirmeye Çevik bir yaklaşımın, yazılımın zamanında, bütçe ve vaat edilen tüm kapsam dahilinde verilmesi gerektiği gibi eski beklentilere rağmen, çok daha yüksek bir verime yol açtığını gösteriyor. Rapor, Çevik projelerin üç kat daha başarılı olduğunu ve geleneksel projelere kıyasla üç kat daha az başarısız Çevik proje olduğunu göstermektedir.

Bu nedenle, bazı projeler için (şartların değişmediği tıp / askeri gibi) Agile'nin (ve özellikle Scrum'ın) tüm toplantılarla yükümlü olduğunu söyleyen meslektaşlarımdan biriyle tartışıyorum. örneğin şelale kullanmak için.

Benim görüşüme göre, Scrum'un bu tür projelerde benimsenmesi gerektiği, çünkü süreci daha şeffaf hale getirecek ve bir ekibin üretkenliğini artıracak. Ayrıca, gerekli olmadığında Scrum etkinliklerinin fazla zaman almayacağını düşünüyorum çünkü Sprint Planlama'da 8 ay boyunca 1 aylık sprint sürmemize gerek yok. Hepimizin aynı sayfada olduğundan ve çalışmaya başladığımızdan emin olmak için 5 dakikanızı ayırabiliriz.

Öyleyse, Scrum gereksinimlerin değişmediği bir proje için ek yük yaratacaktır?

Gereksinimlerin değişmediği projeler olduğunu söylemek yanlış bir varsayım olduğuna inanıyorum. Hem savunma endüstrisinde hem de ilaç endüstrisi yapım yazılımında çalıştıktan sonra, yazılımın konu uzmanlarının eline geçtiğinde (iç veya dış), geri bildirim olduğunu söyleyebilirim. Bazen, bu geri bildirim, gereksinimin yerine getirilme yolundadır ve diğer durumlarda, gereksinimlerin aslında yanlış veya eksik olması ile ilgilidir.

Çeviklik, bu geri besleme döngüsünü azaltmak ve çalışan yazılımı daha hızlı bir şekilde elinize almak, bu geri bildirimi almak ve müşterinin yazılımı kabul etmeye karar verdiğinde, teslim edilenin değer kattığından emin olmak için bir sonraki adımın ne olacağına karar vermekle ilgilidir. Özel donanıma sahip gömülü sistemler gibi alanlarda bile (havacılık, otomotiv veya tıbbi cihazlar gibi alanlarda bulabileceğiniz gibi), hızlı bir şekilde bütünleşmek ve prototip yapmak için ince işlevsellik dilimleri sunmak, yazılım ve donanım sisteminin çalışacağından emin olmanıza yardımcı olabilir amaçlandığı şekilde ve son kullanıcıya yardımcı olacak şekilde çalışın.

Geri besleme döngüsü uzunluğundaki azalma, risk azaltmada büyük bir faktördür. Proje yönetimi açısından, bir projeyi 2-4 hafta boyunca finanse ediyorsanız ve düzenli bir ilerleme sağladığınızda, takipte olduğunuzu garanti eder. İnce işlevsellik dilimleri sunabiliyorsanız, kademeli olarak hedef duruma doğru çalışırsınız ve oraya ne zaman varacağınızı tahmin etmeye başlayabilirsiniz. Eğer zaman bir kısıtlama olursa, önce yapılan işin yüksek değerli bir fonksiyon olması ya da yüksek değerli bir fonksiyon için bir etkinleştirici olması gerektiğinden, düşük değerli fonksiyonların altından kalkabilirsiniz. Herhangi bir noktada, çabayı finanse etmeye devam etmenin ya da farklı bir yöne gitmeye ve bir projeyi çok geç olmadan durdurmaya değip değmeyeceğine karar verebilirsiniz.

Çok kısa cevap evet, Scrum tasarım gereği daha pahalı bir yaklaşımdır, ancak bunu bir proje olarak adlandırıyorsanız, bunun kesinlikle bir önemi yoktur ve sonuçta neredeyse kesinlikle her zaman daha iyi bir yatırım getirisine neden olur.

Daha eksiksiz cevap şudur:

Genel olarak konuşursak, üç süreç kontrol şekli vardır: Tanımlanmış Süreç Kontrolü, İstatistiksel Süreç Kontrolü ve Emperical Süreç Kontrolü. Tanımlanmış Proses Kontrolü, en ucuzudur. Bu, sık sık tekrarlanabilen işlerin, işi yapmanın "en iyi" yolunu bulmak için zaman içinde rafine edilmiş olmasıyla mümkündür. Yazılım geliştirmedeki CI / CD bu kategoriye girer. Yapım sürecinizde değişiklik istemezsiniz, bu nedenle süreci standartlaştırır, mutlu oluncaya kadar ayarlayın, sonra otomatikleştirin. Bu otomatik sürecin, bir dağıtımda elle mücadele etmekten çok daha düşük maliyetli olduğu açıktır.

İstatistiksel Süreç Kontrolü bir sonraki en ucuz olanıdır, ancak bilinen bir süreçteki varyasyonları açıklar. Plana göre uygulanan tıbbi prosedürler bu kategoriye girmektedir. Her seferinde bir baypas ameliyatını yeniden icat etmek istemiyorum. Temel süreci takip ediyorum ve varyasyon için ayar yapıyorum. Bu nispeten düşük bir bilişsel yüke ve oldukça yüksek bir başarı oranına sahiptir.

Sırada en pahalı olan Ampirik İşlem Kontrolü var çünkü süreci ilerledikçe keşfetmeniz gerekiyor. Öğrenme inanılmaz derecede yüksektir, ancak verimlilik ve verimlilik pahasına. Ancak, neredeyse tüm proje çalışmaları bunu gerektirir çünkü daha önce çok az proje yapılmıştır. Tabii ki istisnalar var. Büyük bir aktif dizin ortamı oluşturmak daha İstatistikseldir, çünkü şartların gerektirdiği şekilde biraz saptığınız denenmiş ve doğru talimatlarla çalışırsınız. Ancak, siz daha önce yapılmış tam bir işi yapmak için proje yapmadığınız sürece, kesinlikle kesinlikle İşlem Süreci Kontrolü'nü gerektirir.

Scrum'a geri getirmek için, Scrum, Emperical Process kontrolü ile sorunları çözmek için tasarlanmıştır. Bu nedenle, evet, diğer yaklaşımlardan daha fazla ek yükü var. Ancak, çoğu proje bu yaklaşımı gerektirdiğinden, bu çok tartışılmaz bir tartışmadır.

Tıp ve askeri projelerle ilgili olarak, hatalı mantık gibi görünüyor. 500 uçak için bir emir yerine getiriyorsanız, evet, tam olarak bir şeyi yeniden yaratıyorsunuzdur ve Scrum muhtemelen faydalı değildir. Yeni bir uçak inşa ediyorsanız ve gereksinimleriniz asla değişmezse, o uçağı uçurmazdım.

Tabii ki, önünüzde kristal netliği gereklilikleri olan bir projeniz varsa, bunları geliştiricilerin önüne suyla dökebilir ve iki yıl sonra hayallerinizdeki yazılımı karşılamak için geri dönebilirsiniz.

Ancak yazılım projelerinin büyük çoğunluğu böyle değildir.

Genellikle müşteri neye ihtiyaç duyduğunu bilmiyor. Tam ve özel gereklilikler sağlayamıyorlar. İteratif yaklaşımlar burada yardımcı olur: küçük bir şey oluşturun, ardından müşteriden geri bildirim isteyin. Evet, bu "demolar" ve bir sonraki yinelemeyi planlamak için zaman harcar. Ancak bir sprint için yanlış olanı inşa etmek ve ardından gereklilikleri hızla düzeltmek, projenin tamamı için yanlış olanı inşa etmekten çok daha iyidir. Diğer bir deyişle, ön şartlar daha verimli bir gelişim için izin verebilirken , yinelemeli yaklaşımlar daha etkili olacaktır .

Geliştiriciler, faydalı bir yazılım oluşturmak istiyorlarsa gereklilikleri doğru olarak anlamalıdır. Çok geç olmadan yanlış anlamaları keşfetmenin iyi bir yolu nedir? Yine, yinelemeli yaklaşımlar yardımcı olabilir. Ancak geliştiricilerin, yalnızca bir gereksinim belgesi yazarı aracılığıyla filtrelenmiş bilgiler almak yerine, müşteriyle işbirliği yapmaları da önemlidir.

Sonunda, dünya proje sırasında ayakta durmuyor. Dış sistemler değişir, öncelikler değişir, insanlar değişir. Bir yazılım projesinin gereksinimlerinin değişmeyeceğini iddia etmek, kısa projeler dışında, kötü bir fikirdir.

Bu süreç düzeyindeki faydaların tümü, çevik yaklaşımların günden güne avantajını kaçırmaktadır: Doğru yapıldığında çevik, herkesi mutlu eder. Bunlardan en büyüğü, çevik tekniklerin kısa zaman dilimlerinde gerçek değer sağlamaya odaklanmasıdır. Bu gelişme sürecine görünürlük kazandırır, paydaşlara proje üzerinde makul bir kontrol seviyesi sağlar ve uzak bir hedefe çalışmaktan çok daha motive edicidir. Bununla ilgili olarak çevik ekiplerin büyük oranda kendi kendini organize ettiği fikridir. Günlük işleri kontrolünde hissetmek, insanların kendilerini değerli hissetmelerini sağlar ve bu nedenle ellerinden gelenin en iyisini yapma olasılıkları artar.

Meslektaşınız şelale tarzı projelerin yerlerini alabilmesi için yanlış değil. Bazı çevik uygulamaların zaman harcayan ritüeller olabileceği konusunda yanlış değilsin. Ancak çevik ve yinelemeli yaklaşımların, özellikle daha iyi risk yönetimi ve bireylere saygı duymanın faydalarını görmezden gelmek tamamen aptalcadır. Bunlar her projede istediğin şeyler. Gerekirse, bir takım bunu içsel olarak uygulamaya çalışabilir, ancak herkes gemideyken işler daha iyi sonuç verir.

Sanırım bu @Cort Ammon'un söylediklerinin dezavantajı olabilir, ama işte benim düşüncem:

Dış gereksinimler (“teslim edilebilirleri” açıklayan) bir projedeki tek gereksinimler değildir. Dış gereksinimler değişmese bile, "iç" gereksinimleriniz değişecek ya da çalışırken değişmesine izin verilmesi gerekecektir. Geliştiriciler bir yaklaşmanın önündeki engelleri veya sorunları keşfedecek ve bu takımdaki diğer kişilerin çalışmalarını etkileyecektir. Günlük bir stand-up bu içsel değişikliklerle herkesi güncel tutacaktır.

Bunu bir düşün:

• Sabit fonksiyonel gereksinimler olsa bile, bunları teknik gerekliliklere dönüştürmeniz gerekir. Ve bu, yinelemelerle daha iyi yapılabilir. Projenin ortasında sorunu çözmek için daha iyi yollar keşfedebilirsiniz.

• Bazı gereksinimler çok genel veya belirsiz olabilir: "kullanımı kolay", "güvenli olun". Tamamlanmadığı bir sistemin güvenliğini veya kullanılabilirliğini analiz etmek zor. Bazılarının gizli sonuçları olabilir veya iyi anlaşılmamış olabilir.

• Bazı gereksinimler geliştirilebilir. 200ms içinde cevap vermek iyi olabilir, ancak 100 kişi daha iyi olabilir. Mümkün olan en iyi sonucu hedefleyebilirsiniz ancak proje sırasında gerekirse feda edebilirsiniz.

• Sözleşmeye yazılmayacak bazı gizli gereklilikler keşfedebilirsiniz ancak projeyi başarısızlıktan başarıya değiştirebilir. Projeyi teslim etseniz bile müşteri memnun olmayabilir. Projede tasarlayabileceğiniz yeni özellikler için erken aşamalarda daha ucuza eklemek için (ve ücretlendirme) sözleşmeyi değiştirmeleri gerekebilir.

• İhtiyaçlarınızı belirli bir zamanda yerine getiremeyeceğinizi keşfedebilirsiniz. Yazılım projeleri hiç geç kalmamış gibi. Bu nedenle, en iyi değeri sunmak, hangi özellikleri bırakacağınızı yeniden ilişkilendirmenize olanak sağlar.

• Daha erken bir şey sunmak entegrasyona yardımcı olacak ve bu projenin sonuç verebileceğini gösterecektir.

Birisi, tüm gerekliliklerin mükemmel bir şekilde yerine getirilmesi durumunda, bu gereklilikleri mümkün olan en hızlı şekilde karşılayan yukarıdan aşağıya bir yaklaşımın mevcut olduğu argümanını yapabilir. Bununla birlikte, bunlar iyi gereklilikler ise, nasıl yapılacağını değil, ne yapacağınızı söylerler. Size nasıl yapılacağını söyleselerdi, “gereklilikler” yerine “çalışma talimatları” olarak adlandırmayı seçerdim ve farklı bir tür sorunu tartışırdık.

Buna göre, her zaman gereklilikleri uygulayan şirket veya ekibin içinde bulunan “nasıl” ın geliştirilmesi süreci vardır. Ampirik olarak konuşursak, tasarımcılardan oluşan bir ekibin bu gereklilikleri karşılamak için yüksek seviye sistemi tasarladığı ve daha sonra ayrıntılarımızı derleyen daha küçük ekiplere "gereksinimler" sağlamak için bu üst düzey sistemin özelliklerini kullandığı güçlü bir hiyerarşik yaklaşıma güveniyoruz.

Şelale işleminde bu, tasarım ve uygulama arasındaki tek yönlü okla görülebilir. Ancak, bu şartlar, müşterinin sağladığı gibi, taştan belirlenmemiştir. Bunlar dahili olarak tanımlanmıştır ve yinelemeli süreç için yer vardır. Uygulamada, tasarımcıların bu yinelemenin eksikliğini hesaba katmak için ya da yinelemeli bir süreç aramak için süreçte önemli bir fark yarattığını görüyoruz.

SCRUM ve diğer birçok çevik yöntem, bu yinelemeli işlemi yapmak için titiz bir çerçeve sağlar. Çevik yaklaşımların bir ticari markası, bu yinelemeli modeli, zorlu gereksinimlerin dış katmanına odaklanmak yerine, sürecin özü olarak optimize etmeyi düşünmeleridir. Diğerlerinin de belirttiği gibi, gerçek sabit gereksinimler nadirdir, ancak varlığında bile, SCRUM, yinelemeli yaklaşımı, içine sığdığı sözleşme yaklaşımını kontrol etmek için bir metodoloji olarak kullanır.

Bunu başarmada başarılı olup olmadığı açık tartışma konusudur. Diğerleri bu amaçla birçok ölçüm sağladı. Sadece, altlarında meydana gelen yinelemelerin yukarıdaki sözleşme sistemine doğru bir şekilde uymasını sağlamanın liderliğin gücüne bağlı olduğunu not edeceğim. Bu, kalkınmaya yönelik herhangi bir yaklaşım için geçerlidir, ancak çevik yaklaşımlarda daha belirgindir, çünkü daha yukarıdan aşağıya yaklaşımın "normal" ve eğitimli liderler olduğunu varsaymak için yetiştirildik.