Bir kullanıcı hikayesi geliştiriciler arasında paylaşılmalı mı? [kapalı]

Genellikle arka uç ve ön uç gelişime sahip hikayeler görüyorum. Örneğin, birkaç tablodan ve bazı dinamik kontrollerden oluşan büyük bir iletişim kutusunu düşünün. Birkaç hikaye yapacağız (belki her tablo için bir tane, dinamik kontrol sistemi için bir diğeri).

Geliştirme ekibi daha sonra arka uçta bir kişi ve ön uçta başka biriyle ayrılacak. Bu, arka uçtaki kişinin sadece SQL katmanının yapısı hakkında endişe etmesini kolaylaştırırken, ön uçtaki kişi yerleşim düzeni gibi şeylere odaklanır. Ön ve arka uç arasındaki ilk arabirimin kararlaştırılmasından sonra, iki geliştirici, sprintin sonuna kadar rollerini almak için dikkatlerini odaklayabilir.

Sonra kaos geliyor. Kim hangi hikayenin "sahibi"? "Devam ediyor" ne demek veya "yapılır"? Arka uç ve ön uç için iki ayrı hikaye yapmalı mıyız? Öyleyse, bu özellik temelli kullanıcı hikayeleri fikrini kırmaz mı? Sistemimiz, bu sorunların bazılarını kolaylaştıran "alt görevler" kavramına sahiptir. Ancak alt görevler ekstra bir karmaşıklık ekler. Daha iyi bir yolu var mı? Bu Scrum'u kullanmanın "kötü" bir yolu mu?

Son birkaç yıldır birkaç yerde bazı Çevik formları kullanıyorum. Henüz resmi bir eğitimim yok, lütfen yanlış terminoloji veya ideolojiyi affedin. Ben sadece sürecimizi iyileştirmenin pratik yollarını öğrenmeye çalışıyorum.

Bir "hikaye", bir müşteri perspektifinden tam ve iyi bir hikayeyi temsil ettiği için adlandırılmıştır . Ön uç veya arka uç olmadan, müşterinin yürütmesi için kullanım yolu yolu yoktur.

Senin durumunda, hem ön hem de arka ucun tek bir hikaye olması gerektiğini düşünüyorum. Görevleri böl. Geliştiriciler farklı görevlere sahiptir. Bu görevler, aşamaları boyunca ayrı ayrı izlenebilir - Devam Ediyor, Yapılan Kodlama, Yapılan Test Modülü, vb.

QA tarafından atanmış görevleri aynı hikayeye dahil ettiğinizden emin olun - doğrulama olmadan bir hikaye işe yaramaz. KG, bir müşterinin göreceği uçtan uca entegre hikayeyi test edecektir. Ancak öyleyse, genel hikaye Tamamlandı olarak işaretlenmelidir. İdeal bir Çevik ortamda, gerçek bir müşteri veya müşteri proxy'si, çalışan bir uygulamadaki hikayeyi dener ve kararlaştırılan gereklilikleri karşılıyorsa Kabul Edilmiş hikayesini işaretler.

Daha hızlı geri bildirim döngüleri istiyorsanız, kullanım durumunu daha küçük uçtan uca özelliklere bölmeyi deneyin. Örneğin, "Bir müşteri bir alışveriş sepetini kullanarak bir şeyler satın alabilir" gibi bir kullanım durumunun yerine, "Bir müşteri bir alışveriş sepetine bir ürün ekleyebilir" şeklinde ayırın ... yukarıda açıklandığı gibi uçtan uca.

EDIT: Yukarıdaki noktaları bazı kaynaklarla desteklemek istedim. İyi bir kullanıcı hikayesinin özellikleri, " YATIRIM " olarak adlandırılan bir kısaltma ile tam olarak temsil edilir . Bill Wake tarafından yaratıldı ve Scrum hareketi tarafından popülerleştirildi. Özellikle öykülerdeki öğelerin Bağımsız ve Dikey olduğunu unutmayın.

Burada ve burada biraz daha fazla bilgi .

Kim hangi hikayenin "sahibi"?

Kim hikayeyi kaparsa. Örgütsel bakış açısından anahtar , işlerden bir kişinin sorumlu olmasıdır. İki kişiyi yakaladığınızda, parayı geçmek çok kolaydır.

Arka uç ve ön uç için iki ayrı hikaye yapmalı mıyız? Öyleyse, bu özellik temelli kullanıcı hikayeleri fikrini kırmaz mı?

Değişir. İki yolun da çalıştığını gördüm. Hikaye, iki geliştiricinin üzerinde tam zamanlı çalışmasını sağlayacak kadar büyükse, belki de bölünmüş olmalıdır. İki geliştirici iki farklı ekibin parçasıysa, belki de bölünmüş olmalıdır. İki geliştirici farklı sprintler sırasında üzerinde çalışacaksa, belki de bölünmüş olmalıdır.

Bu Scrum'u kullanmanın "kötü" bir yolu mu?

Hatırlanması gereken anahtar, işlemin tam tersi değil, size hizmet etmek için var olmasıdır. Kullanıcı hikayeleri, teknik kişilerin ve teknik olmayan kişilerin iletişimi kolaylaştırmanın bir yoludur. İstediklerini dile getiriyorlar, herkes pazarlık ediyor, ve sonra hikayenin ilerleyişi hakkında geri bildirimde bulunuyorsunuz.

İşlem sizin için çalıştığı sürece, o kadar da kötü olamaz.

Scrum modellerini uyguladığımız yerde, birden fazla geliştiricinin tek bir kullanıcı hikayesine dahil olması beklenir. Veri katmanı, entegrasyon, ön uç CSS, altyapı, vb. İçin iş olabilir. Ekip, bir hikayenin gerçekleşmesi için çeşitli alt görevlerde bir araya gelebilir.

Söylendiği gibi, bir kişi hikayenin sahibidir ve ilerlemesini güncellemek ve herkesin eserini yapmasını ve birlikte çalışmasını sağlamaktan sorumludur. Bu, bizim için bir hikayenin "yapıldığını" bildiren kişidir.

Diğerlerinin önerdiği gibi, ekibim de kullanıcı öykülerimizi görevlere böler. Bu, kullanıcı öykülerinizi yazılımla (JIRA veya Rally gibi) yönetiyorsanız, yapmak genellikle kolaydır. O zaman hikayenin hangi kısımlarının ilerlediğini anlamak kolaydır.

Ancak görevler için bir alternatif, her biri kendi görevini tamamladığında mülkiyeti yeniden atamak olacaktır. Öyleyse hikaye etrafından dolandı - belki de geliştirici 1 arka uç çalışmasıyla başlıyor, ardından kullanıcı arayüzü oluşturmak için geliştirici 2'ye geçiyor. Ardından, doğrulama için QA test cihazınıza iletilir. Bu yöntem, duvardaki gerçek kartları kullandığınız ortamlarda veya yazılımınızın görevleri izlememesi durumunda iyi çalışmalıdır.

Ancak her durumda, takım testin yapıldığını kabul edene kadar asla "yapılan" bir hikaye demeyi tavsiye etmiyorum. Bu şekilde herkes girdilerini verme şansına sahip. Ve bunu ortak kod sahipliği ve kod incelemeleriyle ilgili fikirlerle birleştirirseniz, o zaman her hikaye yine de takıma aittir. Yol boyunca farklı insanlara "atanmış" olabilir, ancak birisi dışarıda kalırsa (hasta / tatil / çok fazla toplantı? / Diğer) çalışma hala yapılabilir.

Ekibim sık sık sabah stand-up / SCRUM toplantımızın bir parçası olarak kullanıcı hikayelerini kabul ediyor. Bu şekilde herkes gerçekten "yapıldığını" kolayca kabul edebilir veya tartışabilir. Diğer zamanlarda, sadece QA mühendisimizin bunu yapmasına izin veriyoruz - eğer test edildiğinden ve çalıştığından memnunsa ve tüm görevler tamamlandıysa, o zaman bunun için tamam diyoruz.

Bugün bulunduğum yerde bu daha büyük projeye "epik" diyoruz. Bir destan birden fazla hikayeden oluşur ve birden fazla sprint / yineleme yapabilir. Bir hikaye, bizim için her zaman tek bir geliştiriciye verilir ve tek bir sprint içine sığmalıdır. Tek bir hikaye daha sonra görevlere bölünür. Görevlerin her biri bu hikaye üzerinde aynı geliştirici tarafından tamamlandı. Görevler, sprint / yineleme sırasındaki hikayenin ilerleyişi hakkında fikir vermek içindir. Her hikaye tamamlandığında, her geliştirici tarafından, epik ilerleme gösterir.

Destanın amacı, tek bir sprint / yinelemeye uyması gerekmeyen daha büyük bir hedefe sahip olmaktır. Zamanla tüm hikayeler tamamlandı ve epik bitti. Destanlar bir sürüm içine yerleştirilir.

Sonra kaos geliyor. Kim hangi hikayenin "sahibi"? "Devam ediyor" ne demek veya "yapılır"?

Her iki haftada bir, bu sprint / yinelemeyle ilgili hikayelerin paydaşlara gösterilmesi ve onaylanması gerektiği şekilde demo kodu düzenliyoruz. Bu bağlamda bir hikaye için "yapıldı" demek size ne yaptığını gösterebileceğim anlamına gelir. Bir geliştirici öyküsünün sahibidir ve göstermekten sorumludur (bu bölüm biraz aşırı basitleştirmedir, ancak bu cevap için yeterince iyi; gösterilerimizi tek bir kişi üzerinden koordine ediyoruz). "Tamamlandı", başarıyla gösterilebileceği anlamına gelir. “Devam ediyor” demek, bekleyen işlerim var ve hikaye tamamlanmadı. Bir destan, bu destanın hikayelerinin tümü başarıyla gösterildiğinde tamamlandı.

Şimdi bu mükemmel bir vaka ilerlemesidir. Başarısız olan hikayelerimiz ve demolarımız var, başka bir şey isteyen kullanıcılar, vs.