Çevik, Şelale ve ihtiyaç değişiklikleri

Herkes 'Agile' olarak tanımlanan bir projenin bu gereksinim değişikliklerinden ötürü aşılmasını sağladı mı? 4 haftalık Sprint'te yürütülen bir geliştirme projesi üzerinde çalışıyorum ancak bu Sprint'ler arasında her zaman değişiklikler var. O zaman hala Agile olarak mı tanımlanıyor? Bunun bir tür alt Çevik süreç olduğunu hissediyorum - Çevik bir sürecin gereksinimleri bir sprint başlangıcında tanımlanmalı ve sonuna doğru gözden geçirilmelidir. Bunda haklı mıyım? Lütfen bu konudaki deneyimlerinizi bana bildirin.

Çevik bir sürecin gereklilikleri bir sprint başlangıcında tanımlanmalı ve buna göre gözden geçirilmelidir. Bunda haklı mıyım?

Hayır, bu projenin (ve sürecin) doğasına bağlıdır.

Sprint sırasında gereksinimlerin düzeltilmesi gereken bazı çevik geliştirme modelleri vardır ve sadece bir sonraki sprint için değişmelidir (göze çarpan bir örnek Scrum'dır).

Bununla birlikte, değişikliklerin neredeyse her zaman gerçekleşebileceği süreçler de vardır (müşteri gecikmeleri ve değişikliğin neden olduğu ekstra işi kabul ettiği sürece). Kanban genellikle bu iş akışlarını yönetmek için kullanılır (Kanban Scrum ile de birleştirilebilir).

Hangi modeli izlediğiniz her projenin detaylarına bağlıdır.

Bu nedenle evet, müşteri gereksinimleri sürekli olarak değiştirme olasılığına ihtiyaç duyduğunu hissediyorsa, çevik bir süreç bunu karşılayabilir. Ancak, müşteri sürekli değişikliklerin sonuçlarının farkında olmalı ve projeyi yavaşlatacaklarını anlamalıdır.

Bu, çevik manifestodaki prensiplere dayanır - "Süreçler ve araçlar üzerindeki bireyler ve etkileşimler" ve "Bir planı takip ederek değişime tepki vermek".

Sanırım sormanız gereken soru şudur: Neden gereksinim değişikliklerinden fazla abartılıyorsunuz? Yaygın nedenler şunlardır:

• Geliştiricilerin son kullanıcılarla (yeterli) temasları yoktur, bu nedenle kullanıcıların ihtiyaçlarını anlayamazlar. Bunun yerine gereksinimleri soyut bir Rubik küpü gibi ele alıyorlar - ruhlarını anlamaya çalışmadan gereksinimlerin harflerini takip ediyorlar
• Birisi (örneğin pazarlamadan), son kullanıcı için anlamlı olmayan (ancak bir broşürde kulağa hoş gelen) gereksinimler ekliyor. Dolayısıyla, "gerçek" gereksinimler ile geliştiricilerin sırtında "diğer" gereksinimler arasında bir savaş var
• Projenin kapsamı tanımlanmadı ("Yine de bir kelime işlemci uyguluyorsanız, bordro muhasebemizi yapan küçük bir modül ekleyemez misiniz? Oh ve diğer geliştirme ekibinden Bill bunun ne kadar zor olacağını sordu kelime işlemci C ++ kodu da derlemek için yapmak? ")

Kök sorunu ne olursa olsun, bunu düzeltmeniz gerekir. "Agile" (veya başka bir metodoloji) katmanları altında boğulmak işe yaramaz.

En azından bugünlerde yönetim türleri arasında en popüler olan Çevik süreç gibi görünen Scrum'da bir Sprint kapsamı sabittir. Sprint İş Listeniz sprint sırasında değişiyorsa, bu Scrum değil, kaos. Sprint İş Listesi sprint başlangıcında oluşturulmalı ve sprint sonuna kadar sabit kalmalıdır (bu noktada bir sonraki sprint için yeni bir Sprint İş Listesi oluşturursunuz).

Sprint sırasında Ürün İş Listeniz değişiyorsa, önemli değil. Değişiklikler sadece öncelikli, tahmin edilen ve bir sonraki sprint için herhangi bir gereklilik gibi seçilen yeni bir iş haline gelir. Gereksinimler o kadar çok değişirse, Ürün Sahibi sprint'i düzenli olarak iptal etmek zorunda kalırsa, büyük bir 'T' ile ilgili sorun yaşarsınız.

Belki daha kısa sprintlere ihtiyacınız var?

Programcıların akıl sağlığı için bir revizyon / sprint sırasında gereksinimlerin değişmemesi en iyisidir.

Durumunuzda, iki belirgin seçenek vardır:

1. daha kısa sprintler
2. tüm revizyon / sprint iptal edilmediği ve yeniden planlanmadığı sürece müşterinin bir revizyon / sprint sırasında gereksinimleri değiştirmemesini kabul etmesini sağlayın

Her ikisini de tavsiye ederim .

Ana sorun, Scrum kullandığınıza inanmanızdır, ancak kullanmamanızdır. Özellikle ürün sahibiniz bunu takip etmiyor. Scrum'da sprint güvenli bir bölgedir ve geçerli sprint iptal edilmedikçe taahhütlü kullanıcı hikayelerinde değişiklik yapılamaz. Bunu uygulamak Scrum ustasının sorumluluğundadır. Bu, ortamınızda çalışmazsa, bir işlem sorunudur = Scrum kullanmıyorsunuzdur.

Yapabileceğiniz en basit değişiklik (Scrum'ı takip etmek istiyorsanız) sprintinizi kısaltmaktır - örneğin bir hafta. Scrum'ın ilk günlerinde 4 haftalık sprintler seçenek olarak kabul edildi, ancak bugün ortak 1-2 hafta ve 3 hafta üst sınır olarak kabul edildi. Değişen ortamda 4 hafta çok uzun sürüyor.