Çevik süreç: nasıl ve ne belgelenmelidir?

Bir süre önce çalıştığım şirket bir geliştirme projesini üçüncü bir tarafa yaptırmıştı. Çözümü geliştirmek için çevik uygulamalar kullandılar. Ancak dokümantasyon istendiğinde sadece bir wiki'ye dahil edildiği veya sprint'lerinin bir parçası olarak gerekli olduğunu söylerlerdi.

Projenin tamamlanmasından sonra proje ekibinden biri hariç tümü ile ayrıldılar. Yıllık abonelik sona erdiğinde proje wiki sitesi kapatıldı.

Gittiklerinde, kendileriyle neyin geliştirildiğine dair bilgi ve anlayışın çoğunu aldılar.

Bu yüzden 2 ana sorum var;

1. Bu çevik için normal mi yoksa yazmak istememek için bir mazeret mi?
2. Geliştirme gereksinimlerini, tasarımlarını, kilit kararları ve bağlamı kaydetmek için çevik projelerde dokümantasyon için endüstri normları nelerdir?

Bu çevik için normal mi yoksa yazmak istememek için bir mazeret mi?

Benim teorim, çevikliğin bu kadar hızlı yayılmasının nedeni, özellikle de scrum olmasıdır . Kendilerini korumak için çeviklik isteyen çok fazla takım gördüm (tüm şirket yerine). Sorun, çoğu durumda, metodolojinin yönetim tarafından onlara karşı kullanılmasıdır (çünkü kendilerini de korumak isterler!).

Bu çevikliğin hiç çalışmadığı anlamına mı geliyor? Tabii ki değil, bu sadece çevikliğin birkaç yaygın sorunu çözmenize yardımcı olduğu anlamına gelir, ancak yine de diğerlerinden sorumlusunuz. Ve çoğu durumda çeviklik o şirketteki takım için uygun değildir.

Geliştirme gereksinimlerini, tasarımlarını, kilit kararları ve bağlamı kaydetmek için çevik projelerde dokümantasyon için endüstri normları nelerdir?

Kısa olmak gerekirse:

Ekip ne kadar belgeye ihtiyaç duyduklarını tanımlamalıdır

Etki alanını biliyorlar, uzmanlar ve daha da önemlisi şeyi inşa ediyorlar!

İşte en neyi kapsamlı dokümantasyon üzerinde Çalışma yazılım içinde Çevik Manifesto yollarla.

Size bir dizi TDD Testi, Kabul Testi veya diğer Birim Testi bıraktılar mı? Bir uygulamanın nasıl çalıştığını ve çalışmasının beklendiğini belgelemek için iyi bir iş çıkarmanın yanı sıra geliştirilen şeyin nasıl kullanılacağına dair örnek bir uygulama sağlarlar.

Hiçbir şekilde Agile uzmanı olmasam da, bir cevap verme girişimim:

1. Özel belgeler isteyen bir hikaye / gereklilik var mıydı? Değilse, bir dereceye kadar talep edilen şeyi elde ettiğinizde bu sorunun bir parçasıdır. Bu bir bahane ve burada "normal" ile ne demek istediğini merak edebilirim. Çevik ilkeleri takip edenlerin çoğunluğu normal bir şey midir yoksa beklenen sürecin bir parçası mıdır? Bunlar bunun için görebildiğim iki görüş. EDIT: Takımların çoğunluğunun belgeleme söz konusu olduğunda aynı olan bir şey olduğundan şüpheliyim, ama bu benim için bir tahmin.

2. İlginizi çekebilecek bir çift bağlantı, bu konuda yapabileceğim en iyisi hakkında:

   • Çevik / Yalın Belgeler için En İyi Uygulamalar
   • Çevik ve Teknik Belgeler

Çevik, manifestoda , notla birlikte bunu işaret ettiğim belirli noktalara sahiptir :

Kapsamlı belgeler üzerinde çalışan yazılımlar

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

Sadece korkunçlar. Çevikliğin hiçbir belge olmadığı anlamına gelmez. En azından uygulama açıklamasını takip etmelidirler. Wiki'lerinin dışa aktarılması iyi olurdu ya da bir başkasının servis ücretini almasına izin verirdi.

Bazı denemeler kadar ayrıntılı olmayabilir. Teori, zaman sıkışıklığındayken, spesifikasyonlar artık kodla eşleşmiyor. Bu yüzden kodu yazmak ve ayrıntılı olarak tanımlamaya çalışmak için yeterli belgeleriniz var (Kodu sözde sözlü metin / diyagram kodunda ve sonra gerçek kodda yazmak gibi.)

Sorununuzun Agile ile bir ilgisi yok. İstediğiniz belgeleri hazırlamış olmalıdırlar. Proje kötü yönetildi.

Özelliklerin, kullanıcı hikayelerinin ve test senaryolarının en azından bir yerde tanımlanması gerekir . BT, projelerde ReadMe dosyalarında olabilir, kaynak kodu yorumlarında olabilir, tasarım belgelerinde olabilir; yukarıdakilerin hepsi olabilir ... ya da MIA olabilir!

Deneyimlerime göre her zaman dokümantasyon isteyen bir çok insan var (onlardan biri oldum) ama pratikte kimse gerçekten onları oluşturmak için zaman ya da arzu duymuyor. Bazen çabalar vardır, ancak oluşturulan belgeler genellikle çok hızlı bir şekilde eski olur ve sistemin gerçek işleyişi ile senkronize olmaz. Bu, hiç kimse dokümantasyonunuz olmasa bile gerçekten kontrol edemediği bir duruma yol açar, çünkü bunların doğruluğuna güvenmezler.

Gerçek doğruluk ve güvenilir bilgi için kod ve testleri okuyabiliyor. Sisteminin ne yaptığını (yeniden) keşfetmek isteyen bir müşteri, daha sonra sistem hakkında gerçekleri sunabilecek bir programcıyla her zaman görüşebilir ve sorgulayabilir.

İyi belgeler oluşturmak önemsizdir ve oldukça maliyetli olabilir. İkincisi, seyirciyi merak edebilir, belgelerin kim olduğu ve ne sağlaması amaçlanıyor?