Kullanıcı öyküleri yazmayı ve kodlamaya ne zaman başlamalı?


9

İlk sprint için hikayeler keşfederken, yazmayı ne zaman durduracağınızı ve ne zaman ilerleyeceğinizi nasıl bilebilirsiniz?

Tanıdığım birkaç kişiye sordum ve temel olarak aldığım yanıt, projenin var olduğu bağlama ve projenin ne kadar zamanlanmış olduğuna bağlı.

Kullanıcı öyküleri yazmayı ne zaman durduracağınızı bilmenin standart bir yolu var mı ve eğer öyleyse, bunun temeli nedir ve gelecekteki sprintler için nasıl geçerlidir?


2
A turunun finansmanı biter bitmez.
İş

Yanıtlar:


15

Her hikayeyi etledikten sonra tahmin etmelisiniz - bu, hikayelerinizi öncelik sırasına göre aldığınız ve bunların gelişim için yeterince detaylandırıldığını varsayar.

Bir yineleme için yeterince tahmin ettiğinizde kodlamaya başlayın.


+1 @Oded: Evet, karşılaştığım bir yaklaşım ilk önce destanları, sonra temaları bularak başlıyor ve son olarak "önemli" destanlar / temalar "yapıldıktan sonra yürütülebilir hikayelere geçiyorsunuz ... ya da olabildiğince hızlı yürütülebilir öykü bulmaya ve ilerlemeye çalışıyor musunuz?
gaflar

1
Evet, ürün sahibiniz (veya her kim) size bu hikayeleri öncelik sırasına göre besliyor olmalıdır. Bir sprint'te yapabileceğinizi düşündüğünüzden biraz daha geçmek isteyebilirsiniz, bu yüzden fazladan bir şeyleriniz var ... Bu her iki şekilde de boşa gitmiyor, işi ne olursa olsun yapacaksınız, bu sadece ne zaman yapıldığına dair bir soru.
Brandon

1
@blunders - En yüksek önceliğe sahip olursunuz. Tahmin etmek ve uygulamak için yeterince iyi anlaşılana kadar ayrıntılandırın. Bir yineleme için yeterince tahmin edilene kadar durulayın ve tekrarlayın - bu noktada yinelemeyi ve kodlamayı başlatın.
Oded

4

Eksiksiz bir ürün birikimine ve tüm vakaların iyi kullanıcı hikayelerine sahip olduğunuzda. Sonra bunları yinelemelere bölün ve programlamaya başlayın.


2
+1 Paylaştığınız için teşekkürler ve evet, bu zamana bağlı bir proje bağlamında duyduğum bir yaklaşım; sabit teklif danışmanlığı projesini düşünebilir. Bence çevik öğrenme ile ilgilidir ve başlamadan önce her şeyi öğrenmeye çalışırsanız, bu gerçekten çevik bir yaklaşım değildir.
gaflar

1

İki aktivite karşıt değildir.

Hikaye yazma , iş değeri sağlama kısıtlaması altında istenen ihtiyaçları tanımlamakla ilgilidir.

Kodlamaya başlama bir sprint ortasında gerçekleşir. Bir sprint başlatmak için tek ön şart, PO (öykü yazarı) tarafından önceliklendirilen ve ekip tarafından seçilen tanımlanmış bir sprint biriktirme listesidir.

Sen gerektiğini hikayeler yazmaya durdurmak uygulama maliyetine karşı hikayesini uygulanması af marjinal fayda ne zaman, (= projeyi durdurmak) ve tanımlı fonksiyonun hayata işletim maliyeti negatiftir.

Sen gerektiğini kod başlar hikaye anlaşıldığı zaman, bir sürat bağlamında (analiz) ve test ve uygulama (tasarım) tanımlanmıştır - klasik yazılım geliştirme yaklaşımı.


0

hikayeler programlanabilir mantığa dönüşecek kadar ayrıntılı hale geldiğinde ve programcılar sprint zaman çizelgesine uyan belirli sayıda hikaye puanı verebildiklerinde ..

50 saat / öykü noktasında tahmin edilen bir hikaye bir haftadan fazla bir sprint yapmak zor (IMO) olacaktır. paralel olarak geliştirilebilir, bu muhtemelen gidebileceğiniz kadar kısa.


0

Kullanıcı öyküleri yazmayı ne zaman durduracağınızı bilmenin standart bir yolu var mı ve eğer öyleyse, bunun temeli nedir ve gelecekteki sprintler için nasıl geçerlidir?

Ben şahsen standart bir yöntem bilmiyorum. Gerçekten, metodolojinizin ve müşterinizin beklentilerinin bir kombinasyonuna gelir.

Müşterinizden bir başlangıç ​​yapmak için "yeterli" öykülerin olduğu anda kodlamaya başlamanın daha iyi olduğunu gördüm. Diğerlerinin söylediği gibi, bu tek bir yineleme için olabilir, ancak daha fazlası için olabilir. Yeterli ölçünüz, müşterinize çalışma kodunu ne sıklıkla yayınlamayı planladığınıza ve müşterinizin size ve sonsuz öykü listesi vermesine (çoğu muhtemelen hiç yapılmayacak, değişmeyecek veya değişmeyecek) yönlendirilmelidir. büyük çıkış tarihinizi belirtin), müşterinizden ilk 3-5 en önemli ve en yüksek öncelikli özelliği istemeniz daha iyidir. Bunlar yapıldığında ve müşterinize bırakıldığında, bir sonraki en önemli 3-5 özelliği toplarsınız. Yinelemelerinizin ne kadar sürebileceğine bağlı olarak daha fazla veya daha az isteyin.

Müşteriniz veya sözleşmeniz veya son teslim tarihiniz belki de ne zaman hikaye istemeyi bırakacağınız konusunda size rehberlik edebilir, ancak bu arada, yineleme yaptığınız sıklıkta hikayeler sorup duruyorsunuz. Sizinle ve müşterinizin ürünün yeterince eksiksiz olduğunu düşündüklerinde, müşterinin size henüz vermemiş olabileceği kalan hikayelerle ne yapacağınıza karar verebilirsiniz.

Bu yaklaşımın temel avantajı, müşteriye en yüksek değeri en üstte sunmanızdır ve proje büyüdükçe ve zaman geçtikçe, müşteriye verdiğiniz değer miktarı, müşterinin Asla kullanılmayabilecekleri "özelliklerin son% 20'si" hakkında karar. Ayrıca, önemsiz ve düşük öncelikli öğelere harcanan zamanı azaltır, tekrarlamaları müşteriye önceliklendirme ve zamanlama sorumluluğunu (ve stresini) ve yalnızca müşterinin ihtiyaçlarına göre belirler. Ancak bu, müşteriyle konuşurken gereksinimleriniz ortaya çıktıkça ortaya çıkabilecek zor zamanlama darboğazlarından kaçınmak için müşteriye rehberlik etmemeniz gerektiği anlamına gelmez.

Bu yaklaşımın daha geniş bir bağlamda daha ayrıntılı bir tanımını yapmak istiyorsanız , Poppendeicks'in Yalın Yazılım Geliştirme bölümünü okuyun .


0

hikayeler yazmayı asla bırakmazsınız ... Sadece sprint 1 için yeterli hikayeniz olduğunda sprint planlaması yapacaksınız ve takımınız sprint birikimine göre çalışmaya başlayacak ..

Ürün sahibi, ürün biriktirme listesini düzenlemeye, yani daha fazla kullanıcı hikayesi yazmaya, büyük öyküleri, örneğin destanları, daha küçük olanlara ayırmaya, öykü kabul kriterleri hakkında daha fazla ayrıntıya girmeye, önceden ödüllendirmeye devam edecek ...

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.