Kullanıcı Öyküleri kullanılarak karmaşık iş kuralları nasıl tanımlanır?

Kullanıcı Hikayesinin hızlı ve kirli bir tanımı :

"As a <role>, I want <goal/desire> so that <benefit>"

Yaygın olarak kabul edilen bu tanımda, iş kurallarını, kısıtlamaları veya kullanıcı girdisini tanımlamak için çok az yer vardır.

Sadece açıklamak için önemsiz örnek:

"As a <librarian>, I want to <register new books> so that
<students can find their availability online>"

Bu aptal örnekte, bir kitap kaydederken gereken alanlar nerede tanımlanır? Herhangi bir yere yazılmalı mı? Yoksa gerekli iş kuralları Ürün Sahibi tarafından sözlü olarak mı aktarılmalıdır?

Alanlar, yapılması gereken konuşmanın bir parçasıdır . Yararlıysa, ancak bu bir karar çağrısı ise yazılabilirler. Belgelerin güncel tutulması zor olabilirken, çalışma yazılımı bir dereceye kadar belge olarak görülebilir.

Kullanıcı Hikayesi - Konuşma sözü, bununla ilgili bir blog girişi olacaktır.

Önemsiz örneğinizde bunu ne kadar iyi fark edeceğinizi bilmediğim birkaç nokta var. "Yeni kitaplar kaydettirmek" ne anlama geliyor? "Çevrimiçi kullanılabilirliklerini bulun?" Nedir? Bunlar konuşmanın başladığı yerdir ve hikaye tamamlandıktan sonra yeni hikayeler olabilir, çünkü belki de bu kayıtlar dosyada tutulmalı veya raporlar periyodik olarak oluşturulmalıdır.

Önceki cevaplar özel bir ilgili, geçerli puan sağlayan kullanıcı hikaye bir varlık bir görüşme hatırlatma . Dikkate alınacak diğer şeyler:

1. Hikaye çok karmaşıksa, muhtemelen bir destan . Destanları şimdi veya ürün biriktirme listesinde öncelik kazandıktan sonra daha küçük hikayelere bölebilirsiniz

2. Test senaryolarını ima eden ayrıntılar hikayenin kendisinden ayrılır. [ Mike Cohn ]

   Öykü kartının arkasına ekleyebilir, gerçekten önemliyse küçük notlar alabilir veya bunları kabul testleri belgesine koyabilirsiniz .

Kullanıcı hikayelerinizin iyi olup olmadığını değerlendirmek için bir rehber olarak Bill Wake'nin önerisini takip edebilirsiniz :

• Ben başkalarının öyküsüne sahibim
• N örneklenebilir
• V aluable (kullanıcı veya müşteri için)
• E uyarılabilir (iyi bir yaklaşım için)
• S alışveriş merkezi (tahmin edilebilir)
• T estable

Mike Cohn tarafından Kullanıcı Öyküleri Uygulandı kitabının 2. Bölüm "Yazma Hikayeleri" kitabını okumak isteyebilirsiniz .

Tipik olarak birçok yönü olan geniş kapsamlı bir kullanıcı hikayesinde, hikayenin en genel örneğini almaya çalışıyorum ve daha sonra spesifikasyonlar için ondan miras kalan çocuk kullanıcı hikayeleri oluşturuyorum. RallyDev gibi birçok Agile proje yönetimi aracı bunu kolayca yapmanızı sağlar ve bunun mantıklı olduğunu düşünüyorum.

Yeni kitapların kaydedilmesi oldukça geniştir, bu nedenle <role>kitapların nasıl kaydedilmesini istediğinizle ilgili belki de 10 çocuk kullanıcı hikayesi daha vardır.

Bunların uç detayları veya tuhaf saçak detayları genellikle o kullanıcı hikayesi altında bir veya daha fazla görevde tanımlarım. Görevler, bu kullanıcı hikayesini karşılamak için (genel düzeyde) yapılması gereken geliştirme ve tasarım çalışmalarının tanımlanmasına yardımcı olur (Örn. Açıklama alanındaki girdinin 50 karakterden az olmasını sağlamak için geçerli bir yazı yazın ...) EDIT: Sadece eklemek istedim kullanıcı ayrıntılarını aşırı ayrıntılardan uzak tutmak muhtemelen daha iyidir çünkü büyük olasılıkla bir kullanıcının gerçekten fazla önem vereceği bir şey değildir. Kullanıcılar yazılımı genel olarak açıklamak ister ve detayları geliştirip gizlemek için yazılım geliştiricilerine bağlıdır.

Soruna bu şekilde yaklaşıyorum ama eminim ki birkaç farklı yol var.

Cevap basit, iş kurallarını kabul kriterlerine dahil edin.

Sadece açıklamak için önemsiz örnek:

Bir kütüphaneci olarak, öğrencilerin uygunluklarını çevrimiçi olarak bulabilmeleri için yeni kitaplar kaydetmek istiyorum.

Ne zaman memnun kalacağım: * Aşağıdaki alanları kaydedebilirim: - ISDN - Yazar - Dewey Ondalık blah blah * Kitabın sistem tarafından kaydedildiğini teyit edebilirim * Kitabı sistemde görebilirim

Kullanıcı Öyküleri kullanılarak karmaşık iş kuralları nasıl tanımlanır?

Kullanıcı hikayeleri bunun için değildir. Uygulamayı yazmak için gereken tüm ayrıntıları veya iş kurallarını yakalayan yazılım gereksinimleri değildir. Bunlar, uygulamanın kullanıcının bakış açısından ne yapması gerektiğinin bir açıklamasıdır.

Neyin önemli olduğunu unutmayın: uygun yazılımı oluşturmak. Bunu yapmak için gerekli olan her şeyi kullanırsınız ve kullanıcı öyküleri sadece uygulamanın gerekli özelliklerini topladığınızdan emin olursunuz, böylece daha sonra bunlar hakkında konuşabilir, öncelik sırasına koyabilir, tahmin edebilir, vb. hikaye (bir ... istediğim gibi ... böylece) yazılım geliştirme dahil olanlar arasındaki iletişim hakkında.

Kabul kriterleri, alt öyküler, kullanıcı öyküsüne eklenmiş teknik görevler, bir şartname belgesinde veya herhangi bir şekilde ayrıntılara sahip olmak, kullanıcı öyküsünün size yardımcı olduğu şeyin ötesine geçer. Kullanıcı, yazılımın nasıl oluşturulacağına karar verirken konuşmanın “konusudur”.

Verilen örnekte, geliştiricilerin Dewey veya diğer sınıflandırma sistemleri, ISBN'ler, edinim numaraları, yinelenen kopyalar / başlıklar / yazarlar, diğer baskılar vb. Yeni bir sistem için bu tür ayrıntılar gerekir müşteri tarafından sağlanacak (ve bir kütüphaneci, tüm insanların, olacak elbette onları önemseyen).

Steve O'Connell'den alıntı yapmak için, "Spesifikasyonlarda gerekli ayrıntıya sahip olmayan geliştiriciler tarafından ne kadar iş politikasının yaratıldığını düşünmek çok korkutucu.