Çevik bir ekipteki bir gereksinim belgesini nasıl izlersiniz?


22

Kullanıcı Hikayelerinin çevik dünyaya hükmettiğini anlıyorum, ancak takıma katılan yeni geliştiricilerin gereksinimleri karşılayabilmesi için bu eserler nasıl depolanıyor?

Ne Kullanıcı Hikayesi daha sonra değişirse, nasıl güncellenir ve yapay olarak saklanır? Orjinal öyküyü takip etmek yerine birçok takımın yeni bir bilet / özellik talebi / hata raporu açtıklarını gördüm.


1
En iyi dokümantasyon çalışma kodudur
Robert Wagner 5

Yanıtlar:


11

Öncelikle, @ DXM'in cevabındaki neredeyse hiçbir şey Agile ile olan deneyimimle eşleşmiyor, özellikle Scrum ile değil.

Çevik Manifesto kapsamlı dokümantasyon değerli iken, yazılım çalışma DAHA değerli olduğunu belirtmektedir. Bu nedenle, dokümantasyon kesinlikle kötü bir şey değildir, ancak çalışan bir yazılım oluşturmak için gerçekten de hizmette olması gerekir.

Bireyler ve süreçler ve araçlar üzerindeki etkileşimler

Kapsamlı dokümantasyon üzerinde çalışan yazılım

Sözleşme müzakere konusunda müşteri işbirliği

Bir planı takip etmeyi değiştirmeye cevap vermek

Yani, sağdaki öğelerde değer varken, soldaki öğelere daha çok değer veriyoruz.

Kodlamaya başlamadan önce her detayın geri gönderilmesinin tekrar tekrar boşa çıktığı kanıtlanmıştır, bu nedenle dokümantasyon genellikle JIT (tam zamanında) şekilde ele alınır. Yani, gerçekte neyi kodlayacağınızı belgelersiniz.

Scrum'u yapmanın popüler yollarından biri, Ürün Sahibi tarafından tutulan ve Ürün İş Listesinde tutulan Kullanıcı Öykülerini kullanmaktır. Ürün İş Listesi, bir çözümün yapması gereken tüm öğelerin oldukça yüksek bir listesidir ve bir Kullanıcı Öyküsü genellikle listedeki her şeyi açıklamak için güzel bir boyuttadır. Kullanıcı Hikayeleri zorunlu değildir, ancak ayrıntıları aşmamak ve işbirliğine ilham vermenin iyi bir yolu gibi görünmektedir.

Her neyse, bir hikaye yapıldığında - ekip kabul kriterlerini karşılayan bir şey yarattı, test etti ve kullandı, hikaye CHUCKED değil, sadece backlog üzerinde yapıldı. Her sprintte neler yapıldığı hakkında - hikayeler ve bunlarla ilişkili noktalar. Bu, hızı hesaplamanıza izin veren şeydir ve kendi başına değerli belgelerdir.

Bununla birlikte, bir Kullanıcı Hikayesi, bir gereksinimi anlamak için gereken tüm belgeler olabilir, ancak daha büyük olasılıkla, müşteri ile geliştirme ekibi arasında bir sohbet oluşturmak bir şeydir. Bu nedenle, bu konuşmanın çevresinde yapabileceğiniz birçok şey var. Yüz yüze özel bir şeyse, sık sık olduğu gibi, analist / geliştiriciler (belki de kuruluşunuza bağlı olarak) hangi kararları aldıklarını yazabilir ve Wiki ya da dokümantasyon deposu. Bu bir e-posta sohbeti ise, e-postaları kaydedebilirsiniz. Bir beyaz tahta oturumu varsa, tahtanın resmini cep telefonunuzla çekin ve kaydedin. Mesele şu ki, bunlar kodun yapılmasında size yardımcı olan şeylerdir ve nasıl yaptığınız veya neden yaptığınız gibi bir şey bulmanız gerekiyorsa size daha sonra yardımcı olabilir.

Gereklilikleri yakalamanın başka bir yöntemi, bunları hemen test senaryolarına yerleştirmektir (DXM'nin ne elde ettiğine inanıyorum). Zaten her gereksinim için test etmeniz gerektiğinden bu gerçekten verimli olabilir. Bu durumda, gereksinimlerinizi test aracınızda etkili bir şekilde saklayabilirsiniz.

Bir hikaye tamamlanırsa (ve kabul edilirse) ve kullanıcı ihtiyacını değiştirirse, o zaman muhtemelen yeni bir hikaye oluşturmanız gerekir. Dokümantasyonunuz için bir wiki kullanırsanız, yeni hikayeyi orijinal haline geri bağlayabilir ve aynı şekilde orijinal hikayeyi yeni öğelere yönlendirerek, ona bakacak birisinin bu durumun değiştiğini bilmesini sağlayabilirsiniz. Wikiler hakkındaki güzel şey bu - bağlantıları bağlamak kolay ve oldukça acısız. Teste dayalı yaklaşımı kullanıyorsanız, değişiklikle başa çıkmak için test vakasını güncelleyin ya da yeni ve eski birbirini dışlamazsa, yeni hikaye için yeni test senaryoları oluşturun.

Sonunda, ihtiyacınızın ne olduğuna bağlı. Asıl mesele milleti hızlı bir şekilde hızlandırmaksa, birinin yardım için onboarding bir belge yazması iyi bir fikir olabilir. Yani bunu birileri yapsın. Bahsettiğim gibi, Wiki'ler bu tür bir şeyi sürdürmek için harika bir araçtır, bu nedenle Atlassian'ın hikayelerinizi / görevlerinizi / kusurlarınızı izlemek ve projenizi genel olarak yönetmek için Wira ile Jira ve Greenhopper'ı birleştirebilecek çözümleri düşünebilirsiniz . Seçilebilecek çok sayıda başka araç var.


Cevabınıza tam alıntı yapmak yararlı olacaktır.
EL Yusubov

@ElYusubov Hangi alıntı? Çevik Manifesto?
Matthew Flynn

@Matthew, başvurulan alıntıları ekledim.
EL Yusubov

@MatthewFlynn: Bilgilerimin çoğu kişisel deneyimden gelmedi, aksine çevik gelişim üzerine bir sürü kitap ve blog okumaktan, eğer istersen, sana bir liste verebilirim, böylece hepsini okuyabiliriz ve sonra notları karşılaştırabilir. Benim kişisel tecrübem de azalıyor. Önceki şirketimde, scrum kullanarak 5 sürüm yaptık ve 4 tanesi de iyi sonuçlanmadı. Bir şirketin basitçe "aldatmaca" yapması tehlikesi, yerlerin çoğunun "aldatmaca" veya "kargo kültü" çevikliği ile sonuçlanmasıdır. Grubumuz uzunca bir süre kesinlikle bunu yaptı. Ve evet, backlog'larımız oldu ...
DXM

1
@DXM - Scrum ile de karışık sonuçlar elde ettim, ancak geleneksel SDLC'den daha kötü olmamıştı ve birkaç kez mükemmel çalıştı.
Matthew Flynn

8

[update # 1] @MatthewFlynn'in belirttiği gibi, çevik yanı sıra birçokları (benimkiler de dahil) konusundaki tecrübeleri, burada verdiğim cevaptan çok farklı. Buradaki cevap geçmişte kendi ekibimde neyin işe yarayıp neyin işe yaramadığına dair gözlemlerime dayanıyor, konuyla ilgili okuduğum birçok kitap ve blogla ...

çevik kalkınmaya doğru yönlendirmenin büyük bir kısmı, gereksinim belgelerinin kaldırılmasını özellikle hedef almaktadır.

Çevik birçok belgeyi elinden almaya çalışır ve onların fikirlerine katılıyorum, ancak tüm belgelerde gereksinimler, boğanın gözü üzerine boyanmış. Bunun nedeni (IMO) gereksinim belgelerinin asıl çalışma kodundan ve onları yapan tüm belgelerin en uzağında olmasıdır.

  • en az doğru
  • bakımı zor
  • en az kullanışlı

Ekibi daha sonra neyin geliştirileceği konusunda yönlendirmek için, Agile gereksinim belgelerini, bir sonraki ve en yüksek öncelikli ürünler üzerinde neyin üzerinde çalışmanız gerektiğini tanımlayan bir geri bildirim listesiyle değiştirir (genellikle şimdiki ve gelecekteki kova) Bu listede.

Bununla birlikte, bir birikim, bir gereksinim belgesiyle karıştırılmamalıdır:

  • Bir backlogda, yalnızca N sayıdaki hikayenin ayrıntılarının doldurulması gerekir. Bir hikaye ne kadar ileriyse, o kadar az ayrıntı eklemelisiniz (yani, yarım yıl boyunca gerçekleşmeyecek bir şeyi tanımlamaya çalışırken zamanınızı boşa harcamayın) ).
  • Belli bir noktanın ötesinde, "gereksinimler" öğeleri, 2 serbest bırakma döngüsünden (aka potansiyel kaydırılabilir artışlar (PSI)) fazla ise, bir biriktirme bile içine alınmamalıdır. Gereksinimin önemli olduğunu ve bir noktada yapılması gerekip gerekmediğini bilseniz bile, listeye eklemenin cazibesine karşı durun. Eğer gerçekten önemliyse, bir sonraki sürümde birileri onu hatırlayacaktır. Hiç kimse bunu hatırlamazsa, büyük olasılıkla sonuçta önemli olmadığı için.

Bir hikaye tamamlandığında, bu hikaye backlog'dan silinir ve CHUCKED (1) olur . Yine, hikayeler şart değildir. SADECE ekibe ne üzerinde çalışacaklarını söylerler; Tarihsel kayıt için değiller.

Ancak, uygun çevik süreçte, ne zaman iş teslim ederseniz, bu teslimatın bir kısmı birim / entegrasyon / kabul testleri olmalıdır. Bu testler çok değerlidir çünkü birçok amacı vardır. Tam listeye girmeyeceğim, ancak bu amaçlardan biri mevcut üretim yazılımınız için belgeler.

Bir test, belirli bir girdi ve önkoşul kümesi verildiğinde yazılımın nasıl davranması gerektiğini belgelemektedir. Ayrıca, kodunuzun genel (ve dahili) API'lerini nasıl kullanacağınızı da belgeler. Ayrıca, yeni bir geliştirici bir takıma girdiğinde ve istemeden bir şeyleri kırdığında, kontrol edildikten sonra bu hatayla karşılaşılacak şekilde bir güvenlik ağı görevi görür.

Çevik süreç açık bir şekilde otomatik birim testlerinden mümkün olduğunca yararlanmayı teşvik ediyor, ancak hepimiz biliyoruz ki her bir şey otomatikleştirilemez. Yazılım paketiniz her zaman manuel olarak yapılması gereken bir dizi teste sahip olacaktır. Bununla birlikte, a) geliştiricilerin mümkün olduğu kadar otomatik bir şekilde otomatizasyon üzerinde çalışmalı ve b) QA ekibiniz tarafından el ile yapılan testler düzenli olarak yapılmalı, böylece işlevsellikteki herhangi bir kesinti en kısa sürede keşfedilmelidir.


(1) - “Kısık” kısmı için birkaç cevap aldığımdan beri. Çevik hale geldikten 5 yıl sonra ekibim hiçbir zaman tek bir hikayeyi, planlananların% 30'unu, sonra ertelendiğini ve sonra unutulduğunu bile atmadı. Patronum onları "referans" olarak tutmak istedi ve henüz hiç kimse bu hikayelerin hiçbirine bakmadı.

İnsanlar genellikle kendi verilerine eklenir ve bir şeyi zaten elinize aldığınızda bir şey atmanın zor olduğunu biliyorum, ancak envanteri (fiziksel veya seçmen olsun) elde tutmak serbest değil ve daha fazla düşünüyorum, daha fazla katılıyorum "chucking" ile. Bu, "Çevik Yazılım Gereksinimleri: Ekipler, Programlar ve Kuruluş için Yalın Gereksinimler Uygulamaları" (s.190) - "Uygulamadan sonra kullanıcı hikayeleri güvenle atılabilir. Bu, onları hafif tutar, ekip dostudur ve müzakereyi teşvik eder, ancak kabul testleri, uygulamanın ömrü boyunca devam eder ... "


Gereksinimler ve kullanıcı hikayeleri arasındaki farkı OP'ye işaret etmek için +1.
Frank

Sadece ekibimin ve önceki ekiplerin "kıkırdak" hikayesi olmadığını eklemek istiyorum. Onları referans olarak tutuyoruz.
Simon Whitehead

@SimonWhitehead: Bu yorumu yapan sadece siz olmadığınız için cevabımı güncelledim. Ekibim de asla tek bir hikaye atmadı. Peki, geçmişte 2 yıl geriye gitmek ve referans için bu eski hikayeleri kazmak zorunda kaldınız mı? Ve onlardan ne tür bilgiler aldınız? Hikayelerinizin detayı, Bob Martin'in ( books.google.com/… ) tarif ettiğiyle (özellikle Kullanıcı Hikayeleri bölümünde 3. fıkra uyarınca mı?
DXM

... ekibim her zaman her şeyi tuttu ama öykülerimizde hiçbir ayrıntıya sahip bile olmadık, bu yüzden bu öykülerin sağladığı değeri hala anlamadım, ama diğerleri gibi, patronum da hiçbir şey atmamak konusunda çok kararlıydı.
DXM

Sözünü ettiğin Kabul Testleri, bu ses bana belgelenmiş test vakaları gibi geliyor mu? Doğru muyum, yoksa gerçek uygulanabilir testler mi?
Didier A.

1

Ne Kullanıcı Hikayesi daha sonra değişirse, nasıl güncellenir ve yapay olarak saklanır? Orjinal öyküyü takip etmek yerine birçok takımın yeni bir bilet / özellik talebi / hata raporu açtıklarını gördüm.

Herhangi bir belgeyi yönetmek , çevik öyküler mi yoksa büyük bir ön belge mi kullandığınızdan bağımsız olarak zor olabilir ve yükü azaltmak için, belgeler testler ve uygulamadaki çabalara uyması için aşamalı olarak güncellenmeli ve güncellenmelidir. Bununla birlikte, OP'nin bahsettiği gibi, sadece yazılımın zaman içinde nasıl geliştiğinin tarihini yitiren dokümantasyon risklerini güncellemek de basitçe.

Bu gerçekten önemli mi? Bazen olabilir. Çoğunlukla, hikayeleri / UML'yi / şu anda testler ve kodun kendisi ile birlikte ne olursa olsun, yalnızca bir özelliğin neden belirli bir şekilde uygulandığına ilişkin sorular sorulduğunda, genellikle Özelliğin zaman içinde nasıl değiştiğini görmek için geçmişe bakmak, Y seçeneğinin yerine neden X seçeneğinin seçildiğine dair daha net bir resim çizmek yararlıdır .

Bu tür eserleri takip etmenin birkaç yolu vardır. Daha iyi seçeneklerden biri, öykülerinizi kaynak kodunuzun sürümüne benzer şekilde sürümlendirmenize olanak tanıyan bir araçta tutmak olabilir. Wiki'nin bu konuda çok iyi olma eğilimi var ve Trac veya Redmine gibi proje / sorun yönetimi araçlarından bazıları daBu, kendileri ve bu sistemlerdeki wiki sayfalarındaki değişikliklerin geçmişini tutar. Bununla birlikte, yeni öyküler veya konuların bir şekilde eski ilgili konular ve öyküler ile bağlantılı olmasını sağlayarak, konudan özniteliğe değişiklikleri izleme yeteneğini geliştirmek için biraz daha ileri alınabilir. Bu, daha yeni bir sayının / hikayenin metnine eski bir sayı / hikaye kimliği eklemek kadar basit olabilir, ancak sürüm kontrol sisteminizde bir değişiklik yaptığınızda, yorumunuzu kontrol etmek için herhangi bir sayı veya öykü kimliği eklenerek büyük ölçüde iyileştirilebilir. . Bu yöntem en yüksek değere sahiptir, ancak taahhütleriniz sık ve tek bir hikaye veya sorunla sınırlıysa.

Tabii ki en büyük zorluk, bu tür bir yaklaşımın her ekip üyesinin tutarlı olmasını ve taahhütlerini küçük ve sık tutması ve hikayeleri ve / veya sorun / proje izleme sistemlerini yönetenler için tutması gereken özen ve özen göstermesini gerektirmesidir. Uygulamanızın şu anki durumu ile daha önce gerçekleşmiş olan tüm değişiklikler arasında bağlantı sağlayan eserler üzerinde.


1

Daha önce söylendi, ancak sanırım bunun özü şudur:

  • Gereksinimler birçok faslı kapsayabilir ve genellikle birden fazla hikaye ile sonuçlanabilir.

  • Bir hikaye, bir ekibin çalışmalarını bir sprintin zaman sınırlarına uyacak kadar küçük olan parçalar halinde düzenler.

  • Genellikle belirli bir işlevin doğru çalışması için tanımlanması gereken birçok ayrıntı vardır. Bu, tanımları ayrı bir gereksinim belgesinde tutmanın işe yaramaya başlamasının nedenidir - açıklık, ortak anlayış ve daha sonra referans için.

Efsanevi çevrimiçi evcil hayvan dükkanı örneğini göz önünde bulundurun:

  • Hikaye, "Bir kullanıcı olarak, makbuzumun üzerinde basılı olan KDV'yi görmek istiyorum," diyebilir. Şimdi, KDV'nin hesaplanması (katma değer vergisi) karmaşık bir mesele olabilir ve muhtemelen bu hikayenin önerdiğinden daha fazla çalışmaya ihtiyaç duyuyor.
  • KDV hesaplamasının yapılmasını isteyen ek bir hikaye olabilir (örneğin toplam satış tutarını KDV oranı ile çarpın ), ancak bu hesaplamanın tüm varyasyonlarını içermemesi muhtemeldir.
  • İlk başta, ekip temel modülü sağlamaya, malların ve satış fiyatlarının listesini almaya ve KDV miktarını iade etmeye odaklanacaktı. Bu, bir takımın bir sprint süresi içinde başarabildiği bir şey.
  • KDV hesaplaması için olası tüm durumları kapsayan daha birçok hikaye olacağı muhtemeldir.
  • Birçok farklı KDV hesaplama kuralını tekli sprintlerin ötesinde ve ötesinde görünür kılmak için, KDV'yi hesaplamanın tüm yollarını listeleyen ayrı bir gereksinim belgesinin saklanması mantıklıdır. Bu belge zamanla gelişebilir. Aslında, buna yeni bir bölüm eklemek, tamamlanması bir hikayenin görevinin bir parçası olabilir.

Gereksinimler belgesinin geliştirme sırasında yazılması ve @ kodun fiili çalışmasının bir belgelendirmesi olarak, daha önce gereksinimler listesinin bir belgelenmesi olarak hizmet etmesi için @Matthew Flynn ile aynı hizaya geldiğiniz anlaşılıyor.
Didier A.

“... gelişim boyunca yazılmış” - bu bana çok fazla eksik ses çıkarıyor. Netleştirmek için, gereksinimler bir yan ürün değildir, verimli bir uygulama için ön koşuldur. Ancak çevik bir projede, gereksinimler sadece bir sonraki gelişim turunu uygulamak için gerekli olan dereceye kadar yazılır, daha fazlası değil. Bunu yapmak için formu tanımı gereği kapsamı sınırlayan bir kullanıcı hikayesi, bu yüzden uygulamak için gereken zaman bir sprint uyuyor. Bunu, sonraki aşamaya geçmeden önce gereksinimlerin dakika detayına göre belirtildiği şelale projeleriyle karşılaştırın.
miraculixx

Belirsizdir, çünkü gereksinimlerin kabul ettiğim kullanıcı hikayeleri ile aynı olmadığını söylersiniz. Gereksinimleri, iş mantığının kesin ayrıntıları olarak görüyorum, ki bunun nasıl bir şey olduğu, kullanıcı öyküsünün istenen durum olduğu gibi, daha ne olduğu gibi. Yani yorumunu anladığımdan emin değilim? Örnekte, farklı KDV gereksinimlerini, aynı anda, hepsinin aksine, tek tek teslim edildiklerinde yakalarsınız.
Didier A.

Bir kullanıcı öyküsü gibi bir gereksinim istenen bir durumu belirtmiyorsa IMHO, ne işe yarayacağından emin değilim. Aslında KDV örneğinde, müteakip sprintlerde ardışık olarak belirtilen ve iletilen birkaç kullanıcı hikayesi olacaktır. Emin olmak için hiçbir çevik yöntem, bir ekibin tüm KDV hesaplama kurallarını tek bir yerde belgelemesini engellemez, sadece basit için tamamen ayrıntılı, her şeyi kapsayan gereklilikleri yazmak için önceden harcama yapmanın bir anlamı olmadığı fikrini destekler. Bunun nedeni, dev ekibin, hepsini bir kerede uygulayamayacağının nedeni.
miraculixx

Hala kafam karıştı, cevabındaki ilk nokta bir kullanıcı hikayesinin bir gereklilikle aynı olmadığı. Gelecek sürat için gerekli şartları yakalayan her süratin başında yazılmış başka bir dökümanınız olduğunu mu söylüyorsunuz?
Didier A.

0

Özellikler listesini toplamak için freemind komutunu kullanabilirsiniz . Nasıl yapılır, bu eğitime bir göz atın (ortada bir yerde).

Özelliklerin listesine sahipseniz, kullanıcı hikayeleri yazmaya devam edersiniz. Bu, basit bir metin dosyası veya sözcük belgesi veya çevik bir yönetim aracı kadar karmaşık bir şey kullanarak yapılabilir .

Kullanıcı hikayeleriyle işiniz bittiğinde, önceliklendirilirler. Daha sonra, kullanıcı hikayelerinden insanlar işler üretir, insanlar görev alır ve kod içinde uygular.

Tüm bunlar, çevik video cast serisinin sonbaharında ac # projesinin en baştan nasıl yönetildiği görülebilir .

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.