Agile'nin bir parçası olarak tasarım belgeleri

İş yerimde, sık sık "belirsiz gereklilikler, kötü kabul kriterleri, iyi şanslar" anlamına gelen "çevik" bir zorlukla karşı karşıyayız. Bunu genel bir iyileştirme çabası olarak ele almaya çalışıyoruz.

Bu yüzden, bunun bir parçası olarak, kullanıcı hikayesi seviyesinin üstünde ve ötesinde, sistemdeki belirli bir özelliğin etkisinin ön incelemelerinin sonucunu doğru bir şekilde yansıtan ve sahip olduğumuz soruların cevaplarını içeren tasarım belgeleri oluşturmamızı öneriyorum. iş sordu.

Bunun için etkili bir standart var mı?

Şu anda yeni bir özelliğin "büyük çamur topuz" sistemimizdeki birden fazla alanı etkileyebileceği bir durumla karşı karşıyayız ve bu teknik borç nedeniyle tahminler artmaya başlıyor. Umarım daha düşünceli tasarım süreçleri yardımcı olabilir.

internethaber.com "belirsiz şartlar, kötü kabul kriterleri, iyi şanslar!"

evet, bu onları da mahvetmeye çalışsanız bile alabileceğiniz aynı tür şartlar! (bir örnek olarak, bir devlet müşterisini yaratması için 4 yıl süren 10.000 gereklilik belgesi hala tutarsızlıklar, belirsizlikler ve hatta içsel olarak çelişkili ifadelerle doluydu. hiç belirsiz olmayan bir şey alabileceğinizi düşündünüz mü?)

Yani ... çevik yol, bu olayın gerçekleştiğini ve onunla çalışmayı denemek yerine onunla çalışmak olduğunu anlamıştı.

“Ne istiyorsun” diye sormaya başlarsınız ve müşteri “böyle bir şey” ile cevap verir. Bazı işler yapar ve sonra müşteriye geri dönersin ve "istediğin gibi mi budur?" Deyin ve müşteri genellikle "evet ama ..." der, bunun üzerine "ne istersin" diye sorarsın.

Sonunda ne istediğini bilmeseler bile müşterinin istediğini tam olarak alırsın! (cehennem, ne istediklerini asla bilemezler, tam olarak değil).

Ekibimizde, çevik davrandığımızdan beri, gerçekte ne kadar belge gerekli olduğunu anlamaya ve daraltmaya çalışıyoruz. Şimdiye kadar öğrendiklerimizi sizinle paylaşabilirim.

Her şeyden önce, bu makaleyi Çevik / Yalın Belgeler ile okuduğunuzdan emin olun . Çok iyi okumak.

İkinci olarak, hikayeler üzerinde yapılan ön çalışmaların ardından tasarım belgeleri hazırlamayı tekrar gözden geçirmenizi şiddetle tavsiye ederim. Bunu daha önce denedik ve israf olduğunu ispatladı. Son sürümün ortasında, SADECE öykü kodunu teslim ettikten sonra tasarım dokümanlarını güncellemeye karar verdik. Ve şimdi düşünüyorum bile bunun çok erken olduğunu.

Kodlamadan önce neden tasarım dokümanları yapmak istediğinizi kendinize sormanız gerekir. Bizim için bunlar nedenlerdi:

1. Bir ekip olarak hikayenin tasarımı nasıl etkileyeceğini anlamamız gerekiyor.
2. Yeni (veya geçici) üyeler takıma katıldığında veya hiç kimsenin bir yıldan fazla süredir çalışmadığı bir koda geri döndüğünde tasarım belgelerine sahip olmanın faydalı olduğu kanıtlanmıştır. Bu nedenle, kodun nasıl çalıştığını anlamalarına yardımcı olmak için kurumsal bellek için kullanışlıdır.
3. Tasarım belgeleri, sürümden sonra kodu gidermesi gereken bakım mühendisleri için kullanışlıdır.

Tatmin etmek için (1) gerçek bir tasarım belgesi üretmenize gerek yoktur. Takımınız hala kodlamadan önce bir tasarım aşamasına sahip olmalıdır, ancak bu aşama bir beyaz tahta veya peçetenin önünde 15 dakikalık bir seans kadar basit olabilir. Sadece tasarım değişikliklerini tartışmak için saatler süren (günler olmasa da) sürecek gerçek bir belge oluşturmanıza gerek yoktur.

(2) veya (3) mevcut öykünün gelişimi sırasında gerekli değildir ve daha sonraki birkaç yineleme için gerekmeyeceklerinden daha büyük olasılıkla vardır.

Ayrıca, bir ekip üyesi tasarım dokümanlarını her yazarken / güncellerken, kodun yazılmadığı zaman olduğunu unutmayın. Dokümanları gerçek koddan önce yazdığınızda, kodlama tasarımına başladığınızda her zaman değiştirilmeleri bittiğinden, güncellenmeleri gerekme olasılığı neredeyse% 100'dür. Ve kodumuzdan sonra tasarım dokümanları yazsanız bile, ekibimizin öğrendiği gibi, sonraki hikayelerden kaçınmak hala tasarımı değiştirir.

Peki ne tavsiye ederim:

1. Başlangıçta, yeterince geçici tasarım / model üreterek ekibinizin kodlamadan önce akıllıca konuşabilmesini sağlar. Bunları saklamayı beklemeyin ve resmileştirmeye zaman kaybetmeyin.
2. Sadece resmi bir tasarım dokümantasyonu hazırlayın, birileri ihtiyaç duyarsa (örneğin, ekibinizin organizasyon hafızasına gerçekten ihtiyacı var)
3. Yalnızca stabilize edilmiş kodla ilgili tasarım belgeleri oluşturun. Her yinelemede değişmeye devam eden bir modülü belgelendirmenin bir anlamı yoktur.
4. Bir modülü (veya ürünün bir bölümünü) tamamen tanımlayan tasarım belgeleri üretin. Geçmişte yapılması gereken değişiklikleri belgeleyen tasarım dokümanları yazardık. Bu dokümanlar, tahliye yapıldığı andan itibaren tamamen değersizdi.
5. Belgeyi çok yüksek tutun. Mimariyi ve çok üst düzey tasarımı kapsayan 20 sayfa yazarsanız, bu belge a) gerçekte başkaları tarafından okunacak ve b) insanların kodunuzun genel düzenini tanımalarına yardımcı olacaktır. Ayrıntılar için insanlar doğrudan koda girebilir. 700 sayfalık ayrıntılı bir özellik yazarsanız, neredeyse her zaman gerçekliğe uymayacak, herkesin okuyamayacağı kadar çok şey olacak ve gelecekteki değişiklikler yapıldığında 20 yerine 700 sayfayı sürdürmek ve güncellemek zorunda kalacaksınız.

Çevik "mantra" tamamen dokümantasyon olmadan yapmak değildir.

Çevik mantra, " Kapsamlı dokümantasyon üzerinde çalışma yazılımı " nı tercih etmektir . Ancak manifesto altındaki dibine dikkat edin.

Yani sağdaki eşyalarda değer varken , soldaki eşyalara daha çok değer veriyoruz. "

Bob Amca'nın dokümantasyon için iyi bir politikası var.

Acil ve önemli olmadığı sürece hiçbir belge üretmeyin .

Bazı kişilerin Agile'yi dokümantasyon üretmemek için bir bahane olarak kullanmaları haklısınız, ama bu kötü Agile. Yukarıdaki alıntılarda vurguladığım bitleri görmezden geliyor.

Bütün bunlar, 'şu anda yeni bir özelliğin "büyük çamur topumuz" sistemimizdeki birçok alanı etkileyebileceği bir durumla karşı karşıya olduğumuzu söylediğinizde, Çevik olacaksanız, bunun için bir şeyler yapmanız gerekir.

Dokümantasyonunuz olduğunda, kodunuzu modülerleştirmek için kullanın. Bu şekilde, uzun süreli ihtiyacı ortadan kaldırarak dokümantasyonu sürdürme ihtiyacını ortadan kaldırırsınız (ki olmayacak).

yani. İhtiyacı anında ve önemli hale getirin.

Çevik olan şey, dokümantasyon çabalarının gerçekten scrum ekibi tarafından yönlendirilmesi gerektiğidir. Geliştiriciler dış belgelerin ihtiyaçları için yeterli olduğunu düşünmüyorsa, kullanıcı hikayesi bunu yapana kadar engellenir. Eğer işletme geliştiricilerin yeterli belge üretmediğini düşünüyorsa, ürün sahibi kabul kriterlerinin bir parçası olmakta ısrar ediyor. Bu nedenle, belgelendirmeye gittikçe daha odaklı ve etkili olduklarını gördüm.

Kullanıcı öykülerimizi izlemek için VersionOne kullanıyoruz , ancak yöntemlerimizin diğer sistemlere de uygulandığından eminim. Kullanıcı hikayelerine dosya eklemenizi sağlar. Tasarım belgeleri koymak için son derece yararlı bir yer olduğunu bulduk.

Bizim için gerçekten iyi çalışan bir örnek için, prototip oluşturulduktan sonra yeni bir devre kartı tasarımını olabildiğince hızlı bir şekilde test etme ihtiyacımız vardı. Test yapılması gereken her şey için iki kullanıcı hikayesi hazırladık: biri testi tasarlamak, biri testi uygulamak için. Tasarım hikayesi için bir kabul kriteri, test prosedürünün yürütme hikayesinde tam olarak belgelenmesiydi.

Test kısmına ulaştığımızda, gördüğümden daha sorunsuz geçti. Kullanıcı hikayesini yeni açtık ve adım adım prosedürü takip ettik. Belgeler, hikayeyi tamamlamak için tam ihtiyacımız olan şeydi, daha fazla ve daha az değil.

Diğer ekiplerin kendi ürünleri için almalarını kolaylaştırmak amacıyla kullandığımız bir çipin dokümantasyonunu iyileştirmek için birikimimizde başka bir hikayemiz var.

Özetle, belgelerinizin acı çektiğini düşünüyorsanız, çözüm bunun için ayrı bir kullanıcı hikayesi hazırlamak ve / veya kabul kriterlerinin bir parçası yapmak kadar kolaydır.

Zayıf gereksinimlerden bahsettiğinizde, aklıma gelen ilk şey, test kriterlerine sahip olduğunuzdan emin olmaktır. Mümkünse, sistemin mevcut parçaları için bazı yeniden kullanılabilir otomatik test durumları oluşturun. Herkes bununla rahatlaştığında, kod yazılmadan önce test senaryolarını yazmaya gidin. İyi test durumları bir sistemin davranışlarını belgelemek için çok şey yapabilir.

Hangi özel tasarım dokümanlarını kullanacağına gelince, diğerlerinin de söylediği gibi, ekibin ihtiyaçlarına ve üstlenecekleri görevlerin ne olduğuna bağlı. Mümkünse, kullanacağınız belgeleri (koddan) üretebilecek araçları kullanmayı deneyin veya kodu belgeden oluşturun. Dokümantasyonun bakımı oldukça pahalı olabilir, bu nedenle bir tasarım belgesine devam ederken akıllıca seçin.

Şahsen kod ve fitnesse test durumlarından elde edilen sınıf diyagramları ile iyi bir başarı elde ettim. Ekip birkaç sınıf şeması yazdırır, ürün sahibiyle bir işaretleme oturumu yapar ve daha sonra oradan bir tahmin oluşturur. Fitnesse gelince, elektronik tablolarda ne istediklerini ifade etmekte çok başarılı olan birkaç ürün sahibi ile çalıştığım için şanslıyım.