Çevik projelerle gereksinim yönetimi uzun vadede nasıl çalışır?

Gereksinimler Çevik projeler için kısa vadede yönetim benim için çözülmüş bir sorun gibi görünüyor.

Scrum açısından yeni gereksinimler veya mevcut gereksinimlerdeki değişiklikler Kullanıcı Öyküleri aracılığıyla sağlanır. Ve bir Epic veya Feature altında gruplanan Kullanıcı Öyküleri daha büyük ve karmaşık gereksinimlerin karşılanmasını kolaylaştırır.

Elbette, bir Kullanıcı Hikayesi teknik olarak bir gereklilik belgesi değildir. Genellikle Dikey Dilim işlevselliği olarak adlandırılan şeye eşlenen yönetilebilir bir çalışma grubudur . Ve bu hikayelerin kapsamı, Kabul Kriterleri (AC) kullanılarak açık bir şekilde tanımlanabilir.

Bu nedenle, Kullanıcı Öyküleri resmi gereksinimler olmasa da, bunlara göz atmak, temel gereksinimleri hakkında oldukça net bir fikir verebilir. Kısa dönemde.

Kısa vadede diyorum çünkü bir proje ilerledikçe Kullanıcı Öyküleri sayısı artıyor. Böylece, bir Gereksinim bulmak için gittikçe artan bir Öykü listesine göz atmak zamanla gittikçe daha az verimli hale gelir.

Önceki Hikayeleri genişleten, yerini alan veya hatta olumsuzlayan Kullanıcı Öyküleri'ni düşündüğünüzde bu sorun daha da karmaşıklaşır.

Şimdi, bir projedeki geliştirme iterasyonları arasında 2 yıllık bir boşluk olduğunu düşünün (üretimde kararlı). Orijinal ekip gitti ve onların bilgisi de öyle.

Orijinal ekip bunun olacağını biliyorsa (örneğin, bu işin doğasıdır), sonraki ekiplere yardımcı olmak için ne gibi önlemler alabilirler?

Elbette, biriktirme listesi bazı bilgiler sağlayacaktır, ancak kolayca taranabilir bir biçimde değildir.

Peki, sonraki ekiplerin projenin durumunu anlamalarına yardımcı olmak için ne yapılabilir ve neden oraya nasıl ulaşılır?

Deneyimlerime göre, aşağıdaki şeyler işe yaramıyor:

• Biriktirmenin gereksinimler belgesi olarak okunabilmesi için önceki Kullanıcı Öykülerini silmek veya güncellemek için biriktirme listesi bakımı .
• Belgeler Ekip üyelerinin sistemin geçerli durumunu belgelemekle görevlendirildiği sprintler .
• Davranış Testleri ile Dokümantasyon . Bu yaklaşım, çalışmaya yaklaştığımı gördüğüm tek yaklaşım. Ne yazık ki, Kodlu Davranış testleri Adlandırma Sorunu'nun kurbanlarıdır. Testler sistemi düzgün bir şekilde belgeleyebilse de, aynı Etki Alanı terminolojisi, ifadeleri ve stilini izleyerek dalgalı bir geliştirici ekibinin testlerini yazmasını sağlamak neredeyse imkansızdır.

Tekrarlamak gerekirse:

Çevik proje gereklilikleri uzun vadede nasıl yönetilir?

Bana öyle geliyor ki Agile projeleriyle odada konuşulmamış fil gibi görünüyor: onların kaosa dönüşmelerini nasıl önlüyorsunuz?

Bir an için Çevik Manifesto'ya bakalım. Çevik arzular:

1. Erken ve sürekli teslimat
2. Değişen gereksinimleri benimsemek
3. Çalışan yazılımı sık sık teslim etme
4. Her gün birlikte çalışan geliştiriciler ve iş ortakları
5. Motive olmuş bireylerin etrafında projeler oluşturmak, onlara ihtiyaç duydukları ortamı ve desteği vermek ve işi yapmak için onlara güvenmek
6. Birincil iletişim modu olarak yüz yüze görüşme
7. İlerlemenin birincil ölçüsü olarak çalışan yazılım
8. Sürdürülebilir kalkınma
9. Teknik mükemmelliğe ve iyi tasarıma sürekli dikkat
10. Basitlik - Yapmanız gerekmeyen işleri en üst düzeye çıkarmak
11. Düzenli aralıklarla ekip, nasıl daha etkili olabileceğini düşünür, ardından davranışını buna göre ayarlar ve ayarlar.

Son dördünü vurguladım. Neden? Çünkü onlar projenin kendi ağırlığı altında çökmesini önleyecek olan onlar.

Sürdürülebilir kalkınma, (umarım) genel geliştirme sürecini denetleyen birisine, gemiyi bir seferde yazılımı biraz büyütmenin ötesine yönlendirebilen birine, tüm projeyle ilgili kapsamlı bir vizyona sahip birine, keskin bilgiye sahip birine sahip olduğunuz anlamına gelir. yazılım mimarisi, sistem tasarımı, iş mantığı ilkeleri ve kullanıcı arayüzü ergonomisi. Başka bir deyişle, bir mimar.

Mimar, "Bunu istediğini biliyorum, ama başka bir şey inşa edersek, sadece kafa karıştırıcı olan ve temel gereksinime odaklanan bu üç özellikten kaçınabiliriz" diyen mimar. Ekibe teknik borcu azaltması için zaman tanıyan o. Projeye kapsayıcı bir yapı ve organizasyon getiren o. Ekibin bir araya geldiği ve "İşleri nasıl daha iyi yapabiliriz?"

Ve asıl gereksinimler belgesini koruyan odur.

Gereksinim Sürecinde Mastering kitabında , yazarlar üç çeşit müşteri, üç çeşit yazılım projesi olduğunu iddia ediyorlar: Tavşanlar, Atlar ve Filler. Tavşanlar sadece gayri resmi gerekliliklere ihtiyaç duyan küçük yazılım projeleridir; küçük sprintlerde doğrudan müşteriyle çalışırsanız, projenin kapsamı makul şekilde kısıtlanır ve yazılım nispeten kısa bir zaman dilimi içinde yapılır. Filler, çok fazla ön planlama, muazzam miktarda belge ve uzun bir zaman ufku gerektiren mamut projeleridir. Agile kullanarak inşa edilebilecek daha küçük projelere ayırabilseniz de, tartışmasız çevik değildirler.

Çevik bir perspektiften biraz karışık olan Horse projeleri. Yine de yinelemeli olarak inşa edilebilirler, yine de kısa sprintler kullanabilirsiniz, ancak gereksinim toplama ve planlama süreçlerinde bir disiplin olmadan, raylardan kolayca kaçabilirler. Bunlar, disiplinli bir gereksinim toplama sürecinden faydalanabilecek ve daha sonra proje büyüdükçe bu gereksinimlerin dikkatli bir şekilde uyarlanabileceği ve değiştirilebileceği ve tüm proje için kapsayıcı bir vizyonun korunduğu projelerdir.

Kişisel bir bakış açısıyla, yaklaşık bir düzine geliştiriciden oluşan küçük bir ekiple çalışıyorum. Herhangi bir anda, birkaç bin satır koddan 100.000'in üzerine kadar değişen üç yazılım projesi üzerinde çalışıyor olabiliriz. Müşterimiz tavşan olduklarını düşünüyor, ama onlar gerçekten bir at. Müşteri meşgul, ancak günlük olarak değil.

Şimdiye kadarki en zayıf alanımız spesifik, test edilebilir, ölçülebilir gereksinimler toplamak ve müşterinin beklentilerini proje kapsamına göre yönetmek. Ama bunun üzerinde çalışıyoruz.

Soru tam olarak açık değil, ancak gereksinimlerin izlenebilirliği ile ilgilendiğiniz anlaşılıyor . Deneyimlerime göre Agile'da kaybolma eğiliminde olan bir fikir, iş gereksinimlerinin müşterinin sistemin yapmasını istediği şey olduğu, kullanıcı hikayeleri ise sistemin nasıl çalıştığını gösteren gerçekten işlevsel gereksinimlerdir . "Bir kullanıcı olarak, X yapabilmek istiyorum." Ancak bu, kullanıcı hikayesinde kaybolabilecek bir gereksinimi karşılamak için yapılır.

Deneyimlerime göre işe yarayan şey, iş gereksinimlerini ve kullanıcı hikayelerini her iki yönde birleştirmektir. BR # 1, A ve B hikayeleri ile gerçekleştirilebilir. Hikaye C, BR # 2 ve # 3'ü kapsayabilir. Bunu ne kullanırsanız kullanın proje izleyicinize, e-tablonuza koyun.

Uzun vadede bu, müşterinin ne istediğini (BR) sistemin bu gereksinimleri karşılamak için yaptıklarıyla (hikayeler) bağlantılandırmasına yardımcı olur. Bu, hiç kimsenin ihtiyaç duymadığı dokümanları üretmemenin ve güncelliğini koruyabilmenin çevik zihniyetine uyması, sürdürülmesi zahmetli olmayan oldukça minimal bir doküman olmalıdır.

Ayrıca arkalarında tarihini almak için gözden bir şey var yana yeni proje üyeleri hıza ulaşmak için bir yol sağlar neden yazılım ne yaptığını yapıyor.

Aslında orijinal geliştiricilerin artık mevcut olmadığı büyük bir web mağazasının bir kanban bakım projesinde çalışıyorum.

her kullanıcı / gereksinim / hata düzeltmesinin bir bilet numarası vardır ve her kaynak kodu değişikliği sourcecontrol-comment-alanında bir bilet numarasına bağlıdır.

sourcecontrol-checkin-s (svn) otomatik olarak coresponding bilet güncelleme, böylece bilet ben tüm sourceconrtol-değişiklik kümelerine bir bağlantı var.

Bir modül / işlev yeni uygulanırsa, kaynak kodunda da bilet numaraları bulunur.

Bilet sisteminde (redmine) biletler birbirleri ile bağlantılıdır (kopya olduğu, hata olduğu, geliştirildiği, ....)

böylece biletleri takip edebilir ve zaman içinde gereksinim değişikliklerini görebilirsiniz.

Örnek: "orderConfirmation-Web sayfası" bir şey chage gerekir. Sayfanın kaynak kodunda bir yorum görüyorum: '"# 4711" için yaratıldı', böylece yeni biletimi eski bilete "4711" ya da haleflerinden birine bağlayabilirim.

Şahsen, kullanıcı hikayelerini sistemin ne yapabileceğine dair bir belge kaynağı olarak atıyorum. Belgeleme oluşturmak için aktif adımlar atılmadıkça (daha geleneksel müşterilerimizden bazıları için yaptığımız) uygulama tabanı gerçekten en iyi belgelerdir.

Yine de, bu yeni bir şey değil.

Agile'ın ( SAFe gibi ) daha ölçeklendirilmiş bir sürümünü kullanıyorsanız , uygulama biriktirme listesi olmayan başka birikmiş işler olur. Temelde şöyle görünür:

1. Portföy İş Listesi (Destanların ve bütçelerin stratejik planlaması)
2. Program / Sürüm İş Listesi (Özellikler ve Destanlar)
3. Proje / Takım İş Listesi (Hikayeler, Sivri Uçlar, Hatalar)

Ekip İş Listesi düzeyinde dokümantasyon önermem. Çok parçalı ve nadiren kimse bu ayrıntı düzeyine gitmek istiyor. Bir Sürüm içinde Ekip birikimindeki önceki hikayelerle çelişen hikayeler olabileceğinden bahsetmiyoruz bile.

Bunun yerine, Sürüm düzeyinde belgeler sağlamak için Sürüm İş Listesi düzeyinde çalışmanızı tavsiye ederim. Bu hikayeler, belirli bir sürüme atandığında nadiren patlar ve belirli bir sürümde neyin üzerinde çalışıldığını gözden geçirmenin istikrarlı ve hızlı bir yolu olabilir.