Proje başlangıcında karmaşık bir hikayeyi yıkmak

Çevik proje yönetimi (Pivotal Tracker ile) ile uğraşmaya çalışıyorum ama bir projenin ilk birkaç hikayesini tanımlamaya çalışırken kendimi duvarlara koşmaya devam ediyorum. Örneğin bu çok basit hikayeyi ele alalım:

"Kullanıcı bir ürünü etiketleyebilmelidir"

Zaten başka bir yerde "ürün" tanımladığımı varsayarsak, bu hikaye muhtemelen kaputun altına bir polimorfik etiketleme sistemi yazmayı içerecektir, bu sistem kimliğinin tamamlanmasının sonunda bir ürünü etiketleme yeteneğini ekleyebilecektir.

Benim sorunum, bu hikayede gizlenen iş miktarıyla ilgili. Hikayeyi tamamlamak için görevler tanımlayabilirim ama hikayelerin bir bütün olarak 1-2 gün çalışması gerekiyordu? Sadece buzdağının ucunu açığa vuran hikayeyi doğru hissetmiyorum ama Kullanıcı ile ilgili tek kısım bu.

Bu tür şeylerin üstesinden nasıl gelirsiniz? En iyi uygulamalar nelerdir?

GÜNCELLEME 25/08 Rehberliğiniz için herkese teşekkürler, hikayeleri nasıl tanımlayacağınız konusunda tüm tavsiyeleri aldım. Şimdi hikayeler (ödev, tahminler vb.) İçindeki görevler için daha iyi desteği olan ve sprint başladıktan sonra geliştirme görevlerini takip eden Jira Grasshopper'a geçiyorum.

Geliştirici çalışmalarının her birinin 1 ila 2 gün olmak hikayelerini gerekiyorsa, belki de belirli kullanıcı görevleri içine her hikaye kırmalıyım olan geliştirici çalışmalarının 1 ila 2 gün.

Aşağıdaki "kullanıcı hikayesini" düşünün:

Kullanıcı satın alınan bir üründen fatura alabilmelidir.

Kullanıcıya bu özelliği sunarak sadece veritabanı tasarımında nelerin bulunduğunu düşünün. Bir müşteri tablosuna, bir fatura başlık tablosuna ve bir fatura satır öğeleri tablosuna ihtiyacınız var ve henüz ödemeleri kabul etmekten bile söz etmedik.

Gerçekte, kullanıcı hikayeleri bu kadar basit değildir. Tam kullanıcı hikayeleri, ilgili kullanıcı adımlarının izlenmesini içerir:

• Kullanıcı ürünü sepete koyar
• Kullanıcı miktarı belirtir
• Kullanıcı gönderim türünü belirtir

ve bunun gibi. Kısacası, kullanıcı hikayelerinizi daha ince ayrıntılara ayırmanız gerekir.

Hikayeler "1-2 gün iş" olmak zorunda değildir. Scrum altında hikayeler normalde göreli bir boyutlandırma sistemi olan Story Points kullanılarak tahmin edilir. Eğer poker öyküleri planlıyorsanız puan kazanırsınız - öykünün uygulanması için gereken süre ekibinizin belirlediği hıza bağlıdır.

Hikayenin karmaşıklığı gizlediğini düşünüyorsanız (buna Epik bir hikaye diyebilirsiniz ), daha küçük hikayelere ayırmalısınız. Yeni hikayelerin YATIRIM kriterlerine uyduğundan emin olun .

Ama bunu aşırıya kaçıyor olabilirsiniz; YAGNI'ın XP ilkesi burada geçerlidir. Açıkçası, gerçekten gerekmedikçe, "başlık altında polimorfik etiketleme sistemi" uygulamamalısınız. O zaman bile, iyi bir test paketi ile geliştirdiğiniz mevcut sistemi geliştirerek tasarlanmalıdır.

Bu karmaşık etiketleme sistemine ihtiyacınız olduğundan eminseniz, karmaşıklığı ayrı hikayelerde çağırmanız gerekir. Mike Cohn, tasarım yaklaşımını " Kasıtlı ama acil " olarak tanımlıyor

Öyleyse hikayeleri ve görevleri karıştırıyorsunuz.

Kullanıcı hikayesi

Bir kullanıcı hikayesi, ürüne eklendiğinde ürüne daha fazla değer sağlayan eksiksiz bir "özellik" tir.

Bir kullanıcı hikayesi bir sprint sırasında uygulanabileceğinden daha büyük olmamalıdır . Sprint planlamasının ilk bölümünde, sprint sırasında hangi kullanıcı hikayeleri üzerinde çalışmak istediğinize karar verirsiniz. Sprint'in amacı bu kullanıcı hikayelerini tamamlamak ve böylece ürüne daha fazla değer katmaktır.

Görev

Sprint'in planlama aşamasının ikinci bölümünde, geliştiriciler hikayeyi görevlere ayırır . Görevler geliştirme görevleridir. "Veritabanına sütun ekle", "Hizmeti genişlet x" vb. Gibi şeyler olabilir. Bir görev, bir günde tamamlanamayacağı kadar büyük olmamalıdır.

Günlük scrum sırasında bu görevlerin ilerlemesini değerlendirirsiniz. Bir görev birden fazla günlük scrum için devam ediyorsa, çok uzun sürüyor ve ekip olarak bu durumu çözme sorumluluğuna sahipsiniz.

Unutmayın, kullanıcı hikayeleri hissedarlar için iş değerini temsil eder. Paydaşlar görevlerin değil kullanıcı hikayelerinin tamamlanmasıyla ilgilenmelidir.

Görev bölümü, geliştirme ekibinin sprint'i yönetmesi, bir sprint sırasında kullanıcı hikayelerinin ilerlemesini izlemesi ve olası sorunları görselleştirmesi için bir araçtır.

Paydaşlar bu geliştirme görevleri ile ilgilenmemelidir. Ne yazık ki, özellikle çevik gelişime yeni katılan kuruluşlar için sık sık yaptıkları deneyimlerim. Ancak bu durumla başa çıkmak farklı bir konudur.

Epik

Bir kullanıcı hikayesi, bir sprint'te tamamlayabileceğinizi düşündüğünüzden daha büyükse, buna destansı denir. Bir ekip olarak çalışmaya başlamadan önce, bunun birkaç küçük kullanıcı hikayesine bölünmesi gerekir.

Bir kullanıcı hikayesinin son kullanıcıya değer kattığını unutmayın, bu yüzden bir destanı bir "ön uç" ve "arka uç" hikayesine bölmek doğru yol değildir. Yeni bir özelliğin arka ucunu eklemek kendi başına son kullanıcılara değer sağlamaz.

Bir destanı bir süratin zaman çerçevesi içinde yönetilebilen kullanıcı hikayelerine bölmek, bunu yapmadığınız zaman her zaman kolay değildir.

Pivotal Tracker'ı kullanma

Bence Pivotal Tracker kullanıcı hikayelerini izlemek için harika bir araç. Ancak bu bir scrum aracı değildir ve scrum'un hikayeleri görevlere bölmeyi öğretme biçimi, önemli izleyici tarafından kolayca ele alınmaz. Kullanıcı öykülerine görev ekleme özelliğini etkinleştirebilirsiniz. Ancak scrum kullanarak bir proje yürütüyorsanız, bir sprint sırasında görevlerin ilerlemesini izlemek için bir beyaz tahta ve yapışkan notlar kullanmanızı öneririm.

Bir polimorfik etiketleme sistemi uygulamak için bir tasarım amacına sahip olmak iyidir, ancak yine de müşterinin istediği özellikleri uygulamaya odaklanmalısınız. Bu, ince taneli Kullanıcı Hikayesi ile ince taneli Kullanıcı Hikayesi, sisteminizin zamanla polimorfik bir etiketleme sistemine sahip olması anlamına gelebilir. Ancak bu yolculuğun herhangi bir noktasında, uyguladığınız Kullanıcı Öyküleri koleksiyonuyla tanımlanan çok sayıda küçük ve test edilebilir özellikten oluşan bir sisteminiz olmalıdır.

Bu durumda, sisteminizdeki "Ürünleri Etiketleme" gibi bir Epik olabilir, yani tek bir Kullanıcı Hikayesinden çok daha büyük bir şey ve biraz çaba ile birkaç küçük hikayeye ayrılabilir. Yeterli miktarda sanatsal lisans alarak, gereksinimleriniz için kabaca geçerli olabilecek aşağıdaki Kullanıcı Hikayelerini düşünebilirim:

• Sistem yöneticisi olarak, kullanıcıların etiketleme özelliğini ilk kullandıklarında seçebilecekleri bazı değerlere sahip olmaları için sistemi geçerli bazı etiketlerle tohumlamak istiyorum.
• Sistemin bir kullanıcısı olarak, daha sonra etiketleyebilmem için bir ürünü adıyla arayabilmek istiyorum.
• Sistemin bir kullanıcısı olarak, bir ürünün açıklamasını okuyabilmek istiyorum, böylece hangi etiketlere sahip olması gerektiğine karar verebiliyorum.
• Sistemin bir kullanıcısı olarak, hangi etiketlere sahip olması gerektiğine karar verebilmem için ürünün bir resmini görebilmek istiyorum.
• Sistemin bir kullanıcısı olarak, tek bir ürüne tek bir etiket ekleyebilmek istiyorum.
• Sistemin bir kullanıcısı olarak, tek bir üründen tek bir etiketi kaldırabilmek istiyorum.
• Sistemin bir kullanıcısı olarak, birden fazla ürüne tek bir etiket ekleyebilmek istiyorum.
• Sistemin bir kullanıcısı olarak, tek bir ürüne birden fazla etiket ekleyebilmek istiyorum.
• Sistem yöneticisi olarak, sistemde kullanılan etiketlerin ayrı bir listesini görmek istiyorum, böylece bunlardan herhangi birinin kopya olup olmadığına karar verebiliyorum.
• Sistem yöneticisi olarak yinelenen etiketleri birleştirmek istiyorum.

... ve devam edebilirim.

Bunlardan herhangi birinin o kadar gerçekçi olacağından şüpheliyim, ancak umarım Kullanıcı Hikayelerinizle gidebileceğiniz ayrıntı türlerini gösterirler.

Bir Kullanıcı Hikayesi gerçekten daha küçük hikayelere bölünemezse ve yine de bir seferde uygulamaya çalışmanın çok büyük olduğunu düşünüyorsanız, dikey dilimlere bölebilirsiniz. Bu, her bir Kullanıcı Hikayesi altındaki özelliğin yalnızca bir bölümünü sunmak anlamına gelen bir tekniktir, ancak her bir bölüm teknolojinin tüm ilgili katmanları boyunca test edilebilir bir dilimdir, örneğin bir web sitesi için bu, veritabanının, uygulamanın ve UI katmanlarının değiştirilmesi anlamına gelebilir. Veritabanı çalışması için bir Kullanıcı Hikayesi, diğeri uygulama için ve diğeri kullanıcı arayüzü için kullanmaktan kaçının, çünkü bunlar ayrı ayrı test edilemez.

Daha da sanatsal lisans alarak, "Sistemin bir kullanıcısı olarak, tek bir ürüne tek bir etiket ekleyebilmek istiyorum." aşağıdaki dikey dilimler halinde:

• Tek bir ürüne bakan bir sistem kullanıcısı olarak, hangisinin uygulanacağına karar verebilmem için bir etiket listesi arayabilmek istiyorum.
• Tek bir ürüne bakan sistemin bir kullanıcısı olarak, o ürüne uygulamak için bir etikete karar verdikten sonra, onu uygulayabilmek istiyorum.
• Sistemin tek bir ürüne bakan, o ürüne bir etiket uygulayan bir kullanıcı olarak, ekranda başarıyla kaydedildiğini bildiren bir onay mesajı istiyorum.

Bunların her biri test edilebilir - kendi başlarına özellikle değerli değilse.

İhtiyaçlarınızı tanımlamak ve yıkmak için doğru yolu bulmak amacıyla yazılmış kitaplar vardır. Yani kolay bir iş değil.

Çoğu zaman geliştirme ekiplerini en basit çözümler yerine karmaşık çözümler bulmaya çalışırım. Bunun nedeni hikayenin kendisidir ya da ekip sadece bu hikayeyi çözen değil, aynı zamanda x, y ve z hikayelerinin de temelini oluşturan aşırı karmaşık bir çözüm bulmak istiyor olabilir. Bu iyi bir niyettir, ancak aynı işin daha az çalışma ile yapılabileceği kapsamı şişirir. Gelecekteki hikayeleri tasarıma zarar vermemek için ne kadar tasarımın bir hikayeye girmesi gerektiğine karar vermek her zaman zordur. Bu karar ekibin vermesi içindir.

Bir ürün sahibi olarak bunu ancak hikayeleri daha küçük parçalara bölerek etkileyebilirsiniz. Kendinize şunu sormalısınız: Hikaye şu an düşünebileceğimiz en küçük çözüm mü? Bir gün "her zaman istediğim büyük esnek etiketleme sistemi" haline gelecek olan, azaltılmış özellik kümelerine ayırabilir miyiz? Yalnızca tek bir etiket için bir etiket sistemi ile başlayabilir, daha sonra önceden seçilmiş etiketlerin bir listesini içerecek şekilde genişletebilir ve ardından kullanıcının etiketleri vb. Tanımlamasına izin verebilirsiniz.

Geliştirici ekibi için şunları yapar: Hikayeyi gerçekleştirmek için daha basit bir yaklaşım bulabilir miyiz, ancak gelecekteki özelliklerden ödün vermeden bugün işi tamamlayan sağlam bir mimariye sahip olabilir miyiz.

Ara çözümleri kabul etmeye açıksanız ve geliştirme ekibi de en basit, ancak iyi çözümü sunmaya çalışırsa, muhtemelen yapmak istediğiniz hikayelerin boyutunun doğru olduğu tatlı noktayı bulacaksınız (ne kadar küçük o kadar iyi) . Bu sadece küçük hikayeleriniz olduğu anlamına gelmez. Bazıları diğerlerinden daha büyüktür, bu sadece kabul etmeniz gereken bir gerçektir veya çok büyükse, hikayeleri daha küçük parçalara ayırın.