Çevik bir yaklaşım düşünün. Yani, gerekçelerinizle birlikte verdiğiniz her tasarım kararını yazmak için zaman kaynaklarınız ve mükemmel yazma beceriniz varsa, her şeyi belgeleyin. Gerçekçi konuşursak, sanırım böyle bir durumda değilsin. Çevik bir yaklaşım, gerekçelerin belgelenmesi için önemli bir zorluğa yardımcı olabilir: çoğu zaman hangi gerekçelerin önemli olduğunu bilmiyorsunuz.
Soruna bütünsel bir bakış açısıyla yaklaşalım. Siz kararınız için gerekçeleriniz var. Şu an squishyware içinde kalmışlar, takımın beyni. Kredi belgelerinin miktarına rağmen, rasyonelleri sqishyware'de depolamak o kadar da kötü değil. Aslında önemli şeyleri hatırlamakta bir tür olarak gerçekten iyiyiz . Her büyük şirketin neden bu aşiret bilgisini belgelemeye çalışsalar bile, "kabile bilgisine" sahip olmasının nedeni budur.
Şimdi bir problemin var. Sqiushyware'in gerekçeleri yeterince iyi tutmuyor olduğunu görüyorsunuz. Bir sorun olduğunu fark ettiğiniz ve çözülmesi gerektiğini belirlediğiniz için iyi bir şey! Bu her zaman kolay bir adım değil! Bu yüzden, çözümün bu mantığın bir kısmını dokümantasyona boşaltmak olduğundan eminiz. Ancak, bu yeterli değil. Bir karar vermeniz gerektiğinde gerekçeyi squishyware'e yeniden yükleyen bulmacanın ikinci yarısını asla unutamayız. Delice gibi her şeyi belgeleyen çok sayıda ekip gördüm, ancak içerik aslında iyi kararlar almak için organize değil, bu yüzden yazılsalar bile gerekçeleri unutuyorlar .
Demek iki aşamalı bir sürecin var. Gerekçeyi squishyware'den ve dokümantasyondan çıkarmanız gerekir. Öyleyse, gerek duyduğunuzda rasyonel olarak squishyware'i geri getirebilecek kadar iyi organize edildiğinden emin olmalısınız! Şimdi, zorlukların nerden hoşlanacağını anlamak için yeterince problemli bir ifademiz olduğunu düşünüyorum. Belgeleme yaparken, genellikle kimin daha sonra bakacağını ya da ne aradıklarını bilmiyorsunuzdur. Aynı şekilde, belgelere tekrar bakarken, genellikle ne aradığınızı bilmiyorsunuz (en iyi ne zaman bildiğinizi).
Yani büyük bir şirket bunu iki büyük blokta ele almaya çalışabilir. İlk önce, insanların belgeleri araştırırken neye ihtiyaç duyduklarına dayanarak gereksinimler geliştirebilirler. Ardından, söz konusu dokümantasyonu geliştirmek için bir süreç oluşturmak için bu gereksinimleri kullanırlar. Ve söylemeye cesaret edersem, o zaman herkes şikayet eder, çünkü neredeyse hiç kimse tam olarak hangi belgelerin ilk gün nasıl görünmesi gerektiğini bilmiyor . Belgeler her zaman eksiktir ve geliştiriciler her zaman sürecin çok ağır olduğundan şikayet eder.
Çevik olma zamanı.
Tavsiyem, dokümantasyon sürecinizi iyileştirmek için çevik bir çaba başlatmak olacaktır: squishyware'den belgeye ve squishyware'e geri dokuz metre. İşleminizi mükemmel olmadığı için bazı bilgileri kaybedeceğinizi kabul edin, çünkü bu işlem tamamdır, çünkü hala süreci anlamaya çalışıyorsunuz! Tüm çözümlere uyan tek bir beden oluşturmaya kalkarsanız daha fazlasını özlersiniz.
Bazı özel haberlere bakarım: * Gayri resmi belgeleri keşfedin. Resmi belgeler harika, ancak zaman alıcı. Dokümantasyonun amaçlarından biri, geliştirici squishyware bilgisini serbest bırakmak ve kağıda koymaktır. Gayri resmi belgeler bunu yapmanın maliyetini minimumda tutar.
- Güvenilir olmayan dokümantasyon biçimlerini kabul edin. Hiçbir şey ilk kez doğru olmayacak. Veriyi almak ve daha sonra nasıl güvenilir hale getirileceğini bulmak daha iyidir. Örneğin, gerekçelerinizi bir <rationale> </rationale> bloğunda veya benzer bir şeyle belgeleyebilirsiniz; bu, daha sonra bu verilerin toplanmasını kolaylaştıracaktır. Gerekçeleri bir kullanıcı hikayesinde saklamak, şimdilik, sorun değil!
- Organizasyonun değerini asla unutma. Bir ekip olarak, dokümantasyondaki rasyonelleri nasıl aradığınızı öğrenin ve bunu belgelemeye çalışın. Her takımın farklı bir süreci olacak. Ekiplerimden birinde, üzerinde mantıklı olan bileti hemen bulamadık. Yapabileceğimiz şey, önemli olan bir kod satırı
svn blamebulmak, ne zaman değiştiğini ve nedenini bulmak için bir şeyler yapmak ve ardından biletlere bakmak. Bir zamanlar oradaydık, genelde tam da ihtiyacımız olan mantığı bilete koyduk. Bu sadece bizim için çalıştı, sizin için neyin işe yaradığını öğrenin.
- Organik belgeler zamanla büyüyebilir. Geliştiricilerin yazmak için ihtiyaç duydukları gün hangi gerekçelerin en önemli olduğunu bilmeleri nadirdir. Genellikle hangilerinin önemli olduğunu bulduk. Geliştiricilerin kendi küçük gerekçeler bahçesini yönetmelerine izin veren belgeler için bir tımar işleminiz varsa, önemli olanlar yüzeye çıkacaktır. Daha da önemlisi, gerekçeler değişebilir. İki farklı mantığa sahip iki farklı değişimin, her ikisi için de işe yarayan tek bir mantık tarafından gerçekten en iyi şekilde tanımlandığını fark edebilirsiniz. Artık kararlarla aranızda daha az içerik var!