Çevik Belgeleme: Hız ve Bilgi Tutmayı Dengeleme

Yayınlanan: 2022-03-11

Üretimleriyle ilgili çeşitli belgeler, eserler ve süreçler, Şelale modelinin ana sembollerinden bazılarıdır. Yalın'dan ödünç alan Agile, geliştirme yaşam döngüsünü düzene sokmak için ortadan kaldırılması gereken birçok belgeyi “atık” olarak değerlendirir.

Birçok proje yöneticisi için, Şelale aşamalarının nasıl sürat koşularına dönüştüğünü anlamak çok zor değil - aynı iş başarıldı; sadece farklı bir şekilde organize edilmiştir. Bununla birlikte, çoğu belgenin kaldırılması, tamamen farklı bir çalışma biçiminin altını çizdiği için yutulması daha zor bir haptır. Kontrolün dizginlerini gevşetmeyi, bilinmeyeni kucaklamayı ve teslimat ekibinin yerinde kararlar vermesini sağlamayı gerektirir.

Belgelemeye Geleneksel Yaklaşıma Meydan Okunuyor

Şelale metodolojisinde, proje gereksinimlerini belgelemek ve çözümleri detaylandırmak için çok zaman harcanır. Bu süreç, gereksinimler tamamen açık olduğunda çalışır ve yakalanan ve temel alınandan hiçbir şeyin değişmeyeceğinden eminiz. Yine de çoğu şirketin son birkaç on yılda edindiği deneyimler bunun neredeyse hiçbir zaman doğru olmadığını göstermiştir. Günümüz dünyasında, değişimin hızı o kadar dinamik ki, biz dokümantasyon aşamasını tamamlayana kadar müşterinin ihtiyaçları önemli ölçüde değişiyor.

Agile'ın odak noktası, işleri halletmek ve paydaşlara değer katmaktır. Model, çevre birimleri üzerinde ve müşteriye doğrudan ve anında değer katmayan faaliyetler üzerinde çalışmayı caydıracak şekilde inşa edilmiştir.

Şelale ve Çevik'te Belgeler

Her şirketin, proje düzeyinde bile farklılık gösterebilecek farklı bir belge düzeyi vardır. Ancak Şelale ve Çevik projelerde tipik dokümantasyon prosedürleri şöyle görünür:

Şelale Atik
Belgeler çoğu zaman zorunludur. Belgeler tamamlanmadan hiçbir iş ilerlemez. Sadece çalışmaya başlamaya yetecek kadar anlamak için temel belgeler teşvik edilir.
Belgeler uzun bir inceleme sürecinden geçer ve birden fazla tarafça onaylanmalıdır. Resmi bir inceleme ve onay süreci yoktur ve proje yöneticisi kilit karar vericidir.
Standartlaştırılmış şablonlara uyulmalıdır. Belgeleme için resmi şablonlar yoktur; bunun yerine en iyi uygulamalar kullanılır.
Farklı aşamalarda çeşitli belge türleri gereklidir: proje başlatma belgesi, vizyon beyanı, iş gereksinim belgesi, işlevsel ve işlevsel olmayan gereksinimler, yüksek düzeyli tasarım (HLD) ve düşük düzeyli tasarım (LLD) belgeleri, vb. Yalnızca yaklaşan sprintte işlevsellik sağlamak için gerekli olan belgeler gereklidir.
Belgelerde değişiklik yapmak zordur çünkü tüm belgeler iç içedir. Belgelerdeki değişiklikler çok daha kolaydır.
Çok sayıda belgeyi yönetmek için bir sistem veya süreç gereklidir. Dokümantasyon minimumdur, dolayısıyla yönetimi kolaydır.

Dokümantasyon Vakası

Şelale, dokümantasyona çok daha katı bir yaklaşımı teşvik eder ve bu da aşırı görünebilir. Ancak bunu “atık” olarak reddetmeden önce, güçlü dokümantasyon prosedürlerine sahip olmanın birkaç faydası vardır.

Stratejik Düşünme Fırsatı

Plan yapamayanlar, başarısız olmayı planlarlar. Belgeleme, bir proje yöneticisini oturup bir şeyler düşünmeye ve ardından en iyi çözümleri bulmaya zorlar. İnsanlar bazen kapsamlı belgeler yerine çalışan yazılımın Çevik değerini hiçbir belgeye gerek olmadığı anlamına gelecek şekilde yanlış yorumlarlar. Daha sonra, Intercom'da Ürün Başkan Yardımcısı Paul Adams'ın, duvara bir şeyler fırlatıp neyin yapıştığını görmek olarak tanımladığı bir hareketle pazara koşarlar. Çözüm tasarlama, planlar oluşturma, eylemleri müzakere etme—bu faaliyetler, akla gelen her bir özellik fikrini geliştirmeme konusunda zaman kazandırarak değer yaratır.

UX ve İşlevsel Tutarlılık

Şirketler birkaç kurucudan yüzlerce veya binlerce çalışana büyüdükçe, aynı veya ilgili ürünler üzerinde birçok farklı ekip çalışmaya başlar. A Takımı, üzerinde çalıştıkları şeyin B takımının üzerinde çalıştığı şeyle ilgili olmadığını düşünebilir, ancak son kullanıcı için hepsi aynı üründür. Çapraz işlevli ekiplerin kendi işlerini yapması yerine, kullanıcı deneyimi ve işlevsel düzeylerle ilgili net belgeler, ayrık bir kullanıcı akışını önler.

Dokümantasyon Kullanım Kılavuzlarına Dönüştürülebilir

Waterfall'da, çözümleri ve bunların nasıl kullanılacağını detaylandırmak için çok zaman harcanıyor. Ön uç geliştiriciler için aslına uygun tasarımların resimleri oluşturulur. Tüm bu varlıklar, dahili veya harici kullanıcı kılavuzlarına dönüştürülmeleri için onları sıfırdan oluşturmaktan daha az iş gerektirir.

Çevik Belgelendirme İhtiyaçlarını Nasıl Azaltır?

Belgeleri zorunlu kılmak için tekrar tekrar bir bahane olarak ortaya çıkan bir faktör, çalışan devridir. Yöneticiler, insanlar ayrıldığında ve onların yerine yenileri katıldığında kurumsal bilgiyi kaybetmekten korkarlar. Neyin uygulandığını ve nasıl çalıştığını nasıl bilecekler? Yakalamaları ne kadar sürer? Mevcut ekip, yeni ekip üyelerini tutmak için bant genişliğine sahip olacak mı?

Umut, iyi dokümantasyonun çoğunlukla bağımsız olarak çalışan yeni çalışanları hızla hızlandırmasıdır. Ancak Agile, aynı zamanda işe alım süresini azaltan işbirliği teknikleri aracılığıyla dokümantasyon ihtiyacını doğal olarak azaltır. Çevik'in belgeleme ihtiyacını azaltmanın birkaç yolu vardır.

Ürün Ekipleri ve Çevik Ekip Üyeleri Arasında Düzenli Etkileşim

Çevik Manifesto, “süreçler ve araçlar yerine bireyleri ve etkileşimleri” teşvik eder. Bir proje sırasında gereksinimler değişme eğiliminde olduğundan ve yeni fikirler ortaya çıktığından, Agile, sürekli güncellenmesi gereken yazılı eserlere bağlı kalmak yerine, gereksinimlerin doğrudan kaynaktan netleştirilmesini sağlar.

Bakım ve Planlama Görevleri Bölümlere Ayırır

Biriktirme listesi düzenleme ve sprint planlama, özellikleri kolayca anlaşılan ve bağımsız olarak üzerinde çalışılabilen belirli, uygulanabilir parçalara böler. Bu, tüm projenin büyük resmini henüz tam olarak anlamamışken, yeni işe alınanların erkenden üretken olmaları için bir fırsat yaratır.

Kullanıcı Hikayeleri Verimli Dokümantasyon Sağlar

Çevik belgeler için kullanıcı hikayesi şablonu.

Kullanıcı hikayelerinin basit formatı, proje yöneticilerinin tüm ekip üyeleri arasında ortak bir anlayış yaratan çıplak minimum gereksinimleri yakalamasına olanak tanır. Bir kullanıcı hikayesi onu bir sprint haline getirmese bile, bu dokümantasyon yapıtını yaratmanın israfı çok düşüktür. Kullanıcı hikayeleri sprintlere dönüştükçe, bunlar ayrıntılı hale getirilebilir ve tel kafesler, tasarımlar, kabul kriterleri vb. gibi diğer gerekli bilgilerle desteklenebilir. Bu süreç, yüksek oranda atılabilir ve en uygun geliştirme aşamalarında üretilen çok verimli bir dokümantasyon teslimi sağlar.

Daha Az Kod Belgelendirme İhtiyacı

Eşli programlama ve kod incelemesi gibi teknikler, teknik bilgiyi ekip içinde, özellikle de yeni ekip üyelerine yaymak için sürekli fırsatlar yaratır. Sürekli geri bildirim, bir yerde bir belgede hızla güncelliğini yitirmek yerine yeni koşullara uyum sağlama esnekliğine sahip ortak bir anlayışa yol açar.

Çevik Törenler

Günlük stand-up'lar, sprint incelemeleri ve retrospektifler, sorunları çözmek ve e-posta ve belgelere güvenmek yerine yüz yüze kararlar almak için geniş fırsatlar yaratır. Tüm törenlerin sınırlı zaman çerçevesi, muhtemelen hiçbir zaman kullanılmayacak olsa bile, her şeyi belgelemek için zaman harcamak yerine yalnızca en önemli bilgilere öncelik verilmesini sağlar.

Yukarıdakilerin tümü, doğrudan veya dolaylı olarak dokümantasyonu azaltır ve dokümantasyon eksikliğinden gerçekten hiçbir şeyin kaybolmamasını sağlarken proje hedeflerinin gerçekleştirilmesine öncelik verir.

Dokümantasyona Hibrit Yaklaşımlar

Bazı şirketler, Çevik bir ortamda bile bazı belgelere sahip olmayı tercih ediyor. Çevik, kuralcı değildir, çünkü her proje farklıdır ve ele alınması gereken benzersiz bir dizi koşula sahiptir.

Aşağıda, Agile'ın daha fazla zaman alan dokümantasyon yöntemleriyle nasıl birleştirilebileceğine dair bazı örnekler verilmiştir.

UML ve Agile'ı Birleştirme

Örnek UML diyagramı

Bir sistemi görselleştirmek için çok yapılandırılmış ve tanımlanmış varlıkları olan Birleşik Modelleme Dili (UML) gibi standart bir modelleme dili kullanmayı düşünün. Bu, içeriği çok basit tutmaya ve ihtiyaç duyulana odaklanmaya yardımcı olur ve yazılı dilin minimum düzeyde kullanılmasını sağlar. Diğerleri arasında StarUML ve Draw.io gibi araçlar uygun seçeneklerdir.

Kod Belge Üreticileri

Diğer bir yaklaşım, sınıf ayrıntılarının, yöntem ayrıntılarının, parametre kullanımının, bağımlılıkların vb. bir parçası olarak daha yapılandırılmış ve ayrıntılı yorumlar ekleyerek kodun çok daha okunabilir olmasını sağlamaktır. Kaynak koddan faydalı belgeler oluşturma sürecini otomatikleştiren birçok araç vardır ve bunlara belge oluşturucu denir. Genelden programlama diline özgü olanlara kadar çeşitlilik gösterirler.

Detaylı Tasarım ve UX Belgeleri

Tel kafesler, maketler, kullanıcı akış diyagramları, sıra diyagramları vb. kullanarak gereksinimlerin tanımlanması, proje akışlarının basitleştirilmesine yardımcı olur ve ayrıca teknik ekibe neyin geliştirilmesi gerektiğini açıkça belirtir. Tasarım belgeleri, değişen düzeylerde daha katı belgelere sahip olmanın harika bir yoludur. Bu görevler için aralarından seçim yapabileceğiniz çeşitli tel çerçeveleme ve UX araçları vardır.

Proje Yönetim Araçları Belgeleri Otomatikleştirin

Daha güçlü proje yönetimi ve JIRA, Confluence, Asana ve Basecamp gibi ilgili araçlar, projeyle ilgili tüm bilgileri tek bir yerde tutmanın bir yolunu sunar. Görevler bağlanabilir, etiketlenebilir, iç içe yerleştirilebilir ve daha sonra yorum bırakabilecek ve sorunları bildirebilecek farklı ekip üyelerine atanabilir. Bu araçların tümü, bu araçları uyarlama esnekliğinin yanı sıra, çok az çabayla veya hiç çaba göstermeden önemli miktarda belge oluşturabilir.

Ayrıca, tarihsel olarak, dokümantasyon gereksinimlerinin bir kısmı raporlama gereksinimlerinden kaynaklanmaktadır. Paydaşlar, ekip performansına veya diğer ilgili metriklere erişmek ister. Proje yönetimi araçları, proje ilerlemesini yansıtan özel panoları ve görünümleri otomatikleştirmeyi ve araç içindeki ilgili belgelere geri dönmeyi kolaylaştırır.

Dokümantasyon Yönetimi Bir Dengeleme Yasasıdır

Çevik Manifesto'nun yaratıcıları, "çalışan yazılıma kapsamlı dokümantasyondan çok" değer verdiklerini yazıyorlar. Bununla birlikte, “sağdaki öğelerde değer varken, soldaki öğelere daha fazla değer veriyorlar” diye bir sorumluluk reddi de ekliyorlar. Çevik, tüm belgelerin kaldırılmasını önermez, çünkü bazı belgeler açıkça değer sağlar; sadece önceliğin çalışan yazılım üzerinde olması ve yalnızca projenin koşullarına bağlı olarak ve geliştirme ilerlemesini büyük ölçüde engellemeden gerekli olduğu kadar belge eklemesi gerektiğini önerir.

Proje yöneticileri, dokümantasyona daha az zaman harcamak ve çalışan yazılımları teslim etmek için daha fazla zaman harcamak ve uzun vadeli başarı için bir tür dokümantasyonun nerede gerekli olduğunu gerçekten bulmak arasında bir denge sağlamalıdır.