Gereksinim özelliklerini hikayelere göre yazmak iyi bir fikir mi?

Şu anki projemde çevik yöntemler kullanıyoruz ve bunun gibi birçok hikayemiz var:

• Bir asistan olarak, bir müşteriye, talep ettiklerinde biraz para alabilmeleri için geri ödeme yapmak istiyorum

• Bir müşteri olarak, öğemi alabilmem için bir satın alma işlemi için ödeme yapmak istiyorum.

Şimdiye kadar yaptığımız her sprint en önemli hikayeleri seçmek ve bir dizi resmi gereksinim spesifikasyonuna ayırmaktır (aynı spesifikasyonda birbirine benzeyen bazı hikayeleri birlikte gruplandırıyoruz). Hikayeye bağlı olarak, sadece bir ekranda veya tüm iş akışında bir düğme olabilir.

Şimdi sorun şu ki, çok fazla hikaye olduğu için, sistemin hikayelerin onunla ilgili olduğu herhangi bir kısmı için hemen net değil.

Geliştiriciler zamanında çalışır, her sprint geliştirici sadece ne yapmaları gerektiğini ve yapmaları gereken değişiklikleri özetleyen bir özellik alır. Ancak bu hikaye listesini korumak ve test etmek için, gerçekten zor izleme hataları almaya ve genel olarak sadece özellikleri korumak, çünkü ekrandaki bir işlevsellik, bir dizi farklı yerde belgelenmiş olabilir. hikayeye göre bölün.

Hikayelere dayalı özellikler yazmak iyi bir fikir midir? Hikayeleri yanlış bir şekilde yazdık mı?

Bu tartışmalı olabilir ama işte gidiyor!

Geçmişteki patronlarımdan birinin ÇEVİK yapalım önerdiği gerçek zamanlı bir sistem üzerinde çalıştık! Bu konuda yönetim kazanmak gerçekten kolaydı; ancak söylemesi yapmaktan daha kolaydı.

Hikaye kavramı iyidir - ama çok açık olmak gerekirse, oldukça belirsizdir. Gerçekten hikaye nedir? Asıl mesele, öyküleri kullanmanın alone(ve Kullanım vakaları için de aynı şeylerin) çeşitli sorunları olmasıdır - aşağıdaki gibi:

1. Gereksinimler bağlam dışı olamaz (çok fazla brüt tekrarlama yapmadığınız sürece). Belirli bir gereklilikle bağlantılı varsayımlar, arka plan bilgileri ve diğer gereklilikler vardır; sadece bir bağlam ve sadece belirli bir düzen altında mantıklıdırlar. En önemlilerini uygulamak ilk önce mantıklıdır, ancak en azından dosyaladığınız zaman, bunları topladığınızda baştan itibaren eksiksiz bir referans tutun. Gereksinim kelimesinin kendisi karmaşıktır ve Use-Case / Stories ile sınırlı değildir. Gerçekten de hikayeler eyleme geçirilebilir, ancak performans, uyulması gereken kısıtlamalar, iş kuralları vb.

2. Gereksinimlerin boyut olarak ve ölçülebilir bir şekilde uygun olması gerekir, başka hiçbir zaman 1'den fazla büyük hikayeye ihtiyaç duymazsınız! Tam olarak 1 hikaye nedir?

   • ayrıntılı bir senaryo mu? (örneğin ATM'nin bir işlemi reddettiği bir hikaye)
   • kullanıcının gerçekleştirdiği bir eylem grubu mu? (örneğin, geri çekilmeyle ilgili tüm hikaye)
   • veya kullanıcı arayüzünde bir ekran mı? (örn. tam bir hikaye olarak para çekme ekranı).
   • Gerçekten çok keskin iş kurallarını hikayelerle nasıl ölçebilirim? Dürüst olmak gerekirse, yukarıdakilerden herhangi biri olabilir. Mesele şu ki, ne kadar sınırlı ve ayrıntılı bir şekilde gittiğiniz oldukça kişisel bir stil. Çalışırsa -güzel;

3. Alan bilgisi gerçekten şart! Cam, Çelik ve Ahşap'ın çeşitli özelliklerini bilen bir Mimar'a basit bir örnek. bu bilgi bina başına ihtiyaç belgesinin bir parçası değildir! Aynı şekilde, bir bankacılık yazılımı yazıyorsanız - bankacılık hakkında birçok kavram vardır. Gibi onları belirten Gereği kendisi olmayan uysal o size değil çünkü kılan yazılım ne yapması gerektiğini aksine dünya nasıl işler . Hikaye bu tür alan adı karmaşıklıklarını içeriyor mu? yoksa bunu hariç tutuyor mu?

4. Dünyayı modellemek ön koşul değildir.
   Modelleme konusunda, dünyanın nasıl çalıştığını anlamaya odaklanan çok sayıda literatür vardır. Modelleme, gereksinimlerin net bir anlam kazandığı sağlam bir temel oluşturur; ancak böyle bir şey açık olmalıdır. Ne yazık ki, çevik uygulamaların çoğu, daha hızlı ve daha zayıf teslimatlar için ön modellemede değeri reddediyor; ama yine de işler ölçeklendiğinde büyük bir gösteri durdurucusu olduğunu düşünüyorum. Birçok proje, modellemenin alakasız olduğu için başarılı değildir - ancak deneyimli mühendisler bunları başlarından tanır ve çok açık bir rehberliğe ihtiyaç duymaz.

Sorunuza geliyor:

Hikayelere dayalı özellikler yazmak iyi bir fikir midir? Hikayeleri yanlış bir şekilde yazdık mı?

Kullanıcı öykülerinin müşteri tarafından verilen açık bir karar olarak değeri olduğunu düşünüyorum. Ancak eğer kötü organize olmuşlarsa ve yeterince ayrıntılı değilse (veya belirsiz) bir sorun vardır. Daha geniş bir anlayış (alan bilgisi) ve kapsamı (toplam spesifikasyon) biriktirecek daha büyük bir yapıya sahip değilseniz. Kullanıcı öyküleri yalnızca bu tür daha büyük sistemdeki segmentler veya öğeler için.

Not: Kullanım durumları hakkında kesin görüşüm var (oval diyagramlarda gösterildiği gibi), onları uygun bağlamda ve uygun ayrıntı düzeyinde koymadıkça iyi bir iş yapmadılar. (Onlara işe yaramaz davalar diyorum ). Yapmak için bulduğum tek güvenilir kaynak Kullanım senaryosu yazımını gerçekten ölçeklenebilir ve anlamlı yapmak Cockburn tarafından etkili kullanım örnekleri yazmak

> Writing specs by stories? a good idea?

Hikayelerinizin bağımlılıklarını ve önceliklerini yönetebiliyorsanız evet .

İşte birçok kullanıcı sipariş etmenize ve yönetmenize yardımcı olabilecek hikaye haritaları hakkında bir makale .

Bu yanıtı yazarken, bunun testle ilgili olmadığını, dokümantasyonla ilgili olduğunu fark ettim. Önce çevik manifestoyu okumalısınız :

[Biz değerli] çalışma yazılım kapsamlı belgeler üzerinde

Bu nedenle, spesifikasyonlarınızı yürütülebilir hale getirmelisiniz, yani bunları tam otomatik bir test seti olarak yazmalısınız.

Hikayelere dayalı özellikler yazmak iyi bir fikir midir?

Evet, imho, öyle. Buna "davranış odaklı geliştirme" veya "örnekle belirtme" denir. Ruby'de bu kadar yardımcı olan harika bir salatalık aracı var .

Şimdi sorun şu ki, çok fazla hikaye olduğu için, sistemin hikayelerin onunla ilgili olduğu herhangi bir kısmı için hemen net değil.

Neden net olmasını istiyorsun? Yani, gerçekten bir "test / kod" izlenebilirlik matrisine ihtiyacınız var mı? Testleri şartname olarak yazmanın avantajı, ayrı bir "gereksinimler / testler" izlenebilirliğine ihtiyaç duymamanızdır, çünkü testler gereksinim haline gelir. Entegrasyon testi amacıyla, yazılımınıza ayrı parçalar olarak değil bir bütün olarak bakmalısınız.

Sisteminizin teknik özellik testlerinizin kapsamında olmayan kısımları olan "ölü" modüller olup olmadığını görmek için bir kapsam aracına ihtiyacınız olabilir. Ancak bu özel kodun hangi spesifikasyona karşılık geldiğini gerçekten önemsememelisiniz. Bunun tersi olmalıdır: belirli bir spesifikasyondan sistemin hangi kısmının buna karşılık geldiğini bilmelisiniz. Spesifikasyonlarınızda bazı tekrarlamalar konusunda endişelenmemelisiniz. Kodunuza bir KURU ilkesi uygularsanız , aynı kodu çalıştıran düzinelerce özellik olacaktır.

Geliştiriciler zamanında çalışır, her sprint geliştirici sadece ne yapmaları gerektiğini ve yapmaları gereken değişiklikleri özetleyen bir özellik alır. Ancak bu hikaye listesini korumak ve test etmek için, gerçekten zor izleme hataları almaya ve genel olarak sadece özellikleri korumak, çünkü ekrandaki bir işlevsellik, bir dizi farklı yerde belgelenmiş olabilir. hikayeye göre bölün.

Kritik bir modülde küçük bir değişiklikle yüzlerce entegrasyon testinin kırılması nadir değildir. Burada birim testi devreye girer.

Testlerinizi, belirli bir testin yüksek düzeyde bir gereksinimi mi yoksa sadece ince bir ayrıntısını mı kapsadığını anlayabilmeniz için yapılandırmalısınız. İkincisi ise, bu testi entegrasyon testleri paketinizden ayırmalısınız. Birim testinin amacı, hataları yerelleştirmektir. Eğer bir hata verirseniz, bir ve sadece bir test hatası olacaktır.

Hikayeleri yanlış bir şekilde yazdık mı?

Bence, hikayelerinizi kullanıcı tarafından, örneğin "Müşteri", "Asistan" veya özellikler / ekranlar / iş akışları ("Satın Alma", "Geri Ödeme") gibi destanlar halinde organize etmeniz gerekir.

Ve yine, spesifikasyon testleri birim testinin yerini tutmaz. Daha fazla oku

Bir sorundan ve nasıl çözdüğünüzden bahsettiniz, ancak özellikleriniz ve gruplandırmanızla ilgili bazı örneklerden ve ürününüzü geliştirme şeklinizle nasıl ilişkili olduğundan bahsetmeyi unutuyorsunuz.

Hikayelere göre özellikler mi yazıyorsunuz? iyi bir fikir?

Agile bunu yasaklamıyor. Çevik olarak, sürdürülebilir hızda maksimum iş değeri sunmak için ihtiyacınız olan her şeyi yapabilirsiniz. Bu yüzden, daha fazla iş değeri sunmak için ihtiyaç duyduğunuz bir şey varsa, bunu yapmak kesinlikle sorun değildir.

Örneğin, iki kullanıcı hikayesi gösterir. Belki de bir şekilde iş mantığınızla ilişkilidirler ama bu çok yaygın bir senaryodur.

Kullanıcı hikayelerine işlevsellik kazandırmanız gerekiyorsa, dokümantasyon, bazı diyagramlar veya "spesifikasyon" dahil olmak üzere size en uygun olanı tekrar kullanabilirsiniz, ancak bu uygulamaların korunmasının, gelişmiş uygulamanın karmaşıklığınız arttıkça size daha pahalıya mal olacağından emin olmalısınız. Bu durumda cevaplamanız gereken tek soru şudur: Teknik özelliklerimi kullanmazsam bize daha pahalıya mal olur mu?Cevap evet ise daha iyi bir seçenek seçtiniz.

Küçük ekip ile küçük ve orta ölçekli projeler için çevik en iyi çalışır, tüm mimari ekipte örtük bilgi olarak tutulur. Yineleme planlaması sırasında seçtiğiniz öykülerin üzerinden geçecek, mevcut uygulama üzerindeki bir etkiyi tartışacak ve öyküyü tamamlamak için gereken bazı görevleri yazacaksınız. Bu durumda gerçek dokümantasyon, otomatik kabul ve entegrasyon / birim testleri içeren test takımı olacaktır. SW'niz veya ekibiniz büyüdükten sonra örtük bilginin kısmen bazı belgelere geçmesi gerekecektir.

İşte bu noktada soyutlama önemli bir rol oynamaktadır. Hikayelere, ilgili bakış açısıyla bakmanız gerekir. İfadelerde isimleri ve fiilleri toplayın ve onaylayın. Modellerinizi kişisel varsayımlara dayandıramazsınız.Ayrıca ayrıntılara dikkat edin.

Kullanıcı hikayelerine dayalı özellikler yazmak doğru olamaz. Ekstra ayrıntı kazmanız ve bazen alakalı olmayan ayrıntıları göz ardı etmeniz gerekir. Özellikler, analistinizin onayı ile modeliniz tamamlandığında ve doğru olduğunda yazılmalıdır.