Bir projenin ilk aşamalarında ne tür kullanıcı hikayeleri yazılmalıdır?

Sadece bir projeye başlarken hiçbir şeyiniz yok --- arayüz yok, veri katmanı yok, ikisi arasında hiçbir şey yok. Bu nedenle, "kullanıcılar fooslarını görebilmelidir" gibi tek bir hikaye çok iş gerektirecektir. Bu hikayeye sahip olduğunuzda, "kullanıcılar fooslarını düzenleyebilmelidir" gibi bir şey daha gerçekçi, ancak bu ilk hikaye bir UI katmanı, bir sunum mantık katmanı, bir etki alanı mantık katmanı ve bir veri erişim katmanı oluşturmayı içerecektir.

Bu benim "görevler" konseptimle uyuşmuyor: bana göre aşağıdaki "görevler" gibi bir şey olmasını tercih ederim:

• Bir kullanıcının HTML için JavaScript nesnelerinden türetilen foolarına ilişkin sahte verileri gösterin.
• Bir sunum mantığı katmanı oluşturun ve JavaScript nesnelerini bu katmana bağlayın.
• Bir etki alanı mantık katmanı ayarlayın ve sunu mantık katmanını bu katmana bağlayın.
• Bir veri erişim katmanı oluşturun ve etki alanı mantık katmanını bu katmana bağlayın.

Bunların hepsi yukarıdaki tek "öykünün" altına mı düşüyor? Eğer öyleyse, hikayelerin bir projenin ilk aşamalarında çok yararlı bir çerçeve olmadığını hissediyorum. Eğer öyleyse, bu iyi --- sadece bir şey eksik olmadığımdan emin olmak istiyorum, çünkü bu çevik metodolojiyi olabildiğince iyi öğrenmeye çalışıyorum.

Bu iyi bir soru ve muhtemelen birkaç iyi cevap var. Benim almam şu:

Hikaye bir kullanıcı hikâyesidir, bu nedenle kullanıcıya nasıl fayda sağladığını açıklayan terimlerle tanımlanmalıdır.

Agile ve hikayeler sizin için işe yarayacaksa, başlangıç ​​aşamalarında bile çalışmalıdırlar. İlk madde işareti tek bir kullanıcı hikayesidir (yine de biraz teknoloji ile ifade edilmiştir), ancak diğer üçü teknik görev tanımlarıdır.

Bir projenin başlangıç aşamalarında, ne zaman yapmak yerine uygun çerçeveler yok CRUD ( C REATE, R ead, U pdate, D elete) geliştirme, hızlı ve kolay, hikayeleriniz çok daha küçük, artımlı olması gerekir adettir.

Yerine "Kullanıcı kendi foo görüntülemek mümkün olmalıdır" böyle bir şey:

1. Kullanıcı örnek verileri içeren bir sayfayı görebilmelidir
2. Kullanıcı etkileşimli örnek veriler içeren bir sayfayı görebilmelidir
3. Kullanıcı, canlı etkileşimli örnek verileri içeren bir sayfayı görebilmelidir

Tek bir sprint'te geliştirilemeyecek kadar büyük görünen çoğu kullanıcı hikayesinin (yaklaşık 8 hikaye noktasından veya geliştirme günlerinden daha büyük bir şeyin çok büyük olduğunu keşfettim) muhtemelen hala anlamlı olan parçalara ayrılabileceğini unutmayın. Kullanıcı.

Hikaye / özellik pazarlanabilir olmak zorunda değil, sadece ürün sahibi için anlamlı olmalı. Yukarıdaki durumda, ne değişti göstermek için bazı hızlı demo parçalar halinde koyabilirsiniz ve bu hikaye şimdi nasıl yapılır veri veritabanında doldurulmuş önceden iki farklı kullanıcıların sayfasından gösterebilir, örneğin, # 3 için - . 2. aşamada, tüm kullanıcılar aynı verileri görür.

Sorduğunuz şey, bir tasarım yapabileceğiniz mantıklı parçalara ayırmak için "sorun alanı hakkında nasıl düşünüyorsunuz".

Buna kullanıcı hikayesi, analiz, ayrışma veya şartname ya da gereksinimlerin toplanması olsun, sonunda normalde bir miktar yinelemeye sahip olacak birkaç şey ortaya çıkıyor.

Kullanıcıların kafalarından istediklerini almanız gerekiyor. (Muhtemelen istediklerinden bazılarını biliyorlar ve tutarsız ama henüz göremeyen şeyler istiyorlar.)

Bunu bir şekilde yakalamanız gerekir - gerçekten sadece 2 seçeneğiniz vardır: kelimeler veya resimler. Her ikisinin de gücü var, eğer mümkünse ikisini de kullanın. Sözler, daha sonra sözleşme anlaşmazlığı açısından en nihayetinde daha güçlüdür.

Bunu geri sunmalı ve anlaşma aramalısınız.

Bazı insanlar iş veya başka bir mantık olmadan erken görsel prototipler yaparlar. Bu güçlü bir teknik olabilir - bir noktaya kadar çünkü hala belirli bir miktar el sallama içerir.

Bazıları hikaye panosu olacak - ve sonra sunacak ve açıklayacaktır.

Bazıları titiz ve dikkatle analiz edilen belgeler yazacaktır.

Her tekniğin avantajları ve dezavantajları vardır.

Vereceğim tek öğüt hakkında: Bir çözümü çok erken kodlamaya başlamak genellikle kötü bir hamle. WHO ve NEDEN için ne yapacağınızı anlamak, bunu yapmadan önce genellikle daha az yeniden işleme ve daha hızlı bir gelişmeye yol açar.

"Görevler" hakkında konuştuğunuzda, bu bana yukarıdaki gibi, kimin ve niçin olduğunu anlayarak, işin bir tür yıkımı gibi görünüyor. Kullanıcı hikayesini bir belgede, yapacağınız işin kapsamı olarak müşteri tarafından onaylayana kadar WELL görevlerini anlayamazsınız. Neyi başarmanız gerektiğini (çıktı) bilmek, görevleri (oraya ulaşma adımlarını) anlamanıza olanak tanır.

Ön uç analiz ve dokümantasyonunu gözden kaçırmayın.

Bence eksik olan şey, kullanıcı hikayelerinin kullanıcının sistemi kullanmayı nasıl beklediğini anlatmak olduğudur. Bu, iş gereksinimlerini belirlemenin bir yoludur . Size teknik olarak ne yapacağınızı doğrudan söylemek için tasarlanmamışlardır, bu da istediğiniz gibi görünmektedir.

Bu tartışmasız bir projenin en önemli parçalarından biridir. İş gereksinimlerini doğru şekilde almazsanız, sistemin kullanıcılar için bir faydası olmayacaktır.