Bir geliştirici bir kullanıcı hikayesi hakkında ne kadar ayrıntı bekleyebilir?

Yaşadığım çevik gelişimin en büyük dezavantajı, geliştirmeye dahil olmayan kişilerin, bir kullanıcı hikayesinin (3-10 ideal kişi günü) 1-3'den fazla cümle içermemesi gerektiği mantrasına odaklanmasıdır:

Bir müşteri olarak, aradığım ürünleri bulabilmek için serbest metin aramasını kullanabilirim.

Bu cümleyi veren proje yöneticileri, bir geliştirici olarak benden bir tahminde bulunmayı ve hikayeyi geliştirmemizi bekliyor. Çevik gelişimin, bunun gibi cümlelerin geliştiricilere vermesi gereken tek şey olduğu anlamına geldiğini varsayarlar.

Onları suçlamayacağım çünkü çevik gelişim hakkında iyi bilinen literatür bunun gerçekten işe yarayacağı izlenimini yaratıyor. "Planning XP" de hikaye başına doğal dilde 2 sayfa gibi bir şey okudum, ama hepsi bu. "Çalışan yazılım", "kapsamlı belgeler" üzerinde tercih edildiğinden, bu konudan genellikle kaçınılmış gibi görünüyor.

Gerçek şu ki, geliştiriciye bunu yapma şansı verilirse, müşteriyle yapılan bir röportaj, müşterinin hikayeyle ilgili uzun bir gereksinim listesi getirir:

• AND ve OR gibi boole operatörlerine ihtiyacımız var.
• Tüm terimler için bulanık aramaya ihtiyacımız var.
• Tek kelimeyle ve kelime öbeğiyle arama yapmamız gerekiyor.
• X, Y ve Z kriterlerini karşılayan ürünler bulmak istemiyoruz.
• Sonucu sıralamak istiyoruz. Oh, ve bu arada, kullanıcı birleşik giriş kutusunda a, b ve c seçenekleriyle sıralama ölçütlerini seçebilir.

Görüyorsunuz ki teknik detaylardan, yazılım tasarımından, hatta uygulama detaylarından bahsetmiyorum. Saf gereksinimler. Ne kadar uzun konuşursak, müşteri ne istediği hakkında söylenecek çok şey olduğunu fark eder.

Ama çoğu zaman kendimi böyle bir bilginin sağlanmadığı ya da çok çaplı bir şekilde buluyorum. Ne röportaj yapmam mümkün, ne de röportaj yapacak konumda olan kişi bana bunun bir sonucunu vermiyor.

Bazen, yöneticiler "Lucene aramasını istiyoruz" gibi teknik detaylar bile ortaya koyarlar, ancak sadece ürün adları veya ürün açıklamaları bulmak isteyip istemediklerini düşünmek istemezler. Bazen sadece tembel olduklarını düşünüyorum;)

Benim için bu, çalıştığım projelerde en önemli konudur (e-iş web uygulaması, proje başına 500-2000 kişi günü). Bu problemi yeterince sık ele aldım ve yöneticiler çoğu geliştiricinin durumla ilgili bir problemi olduğunun farkındalar. Ancak geliştiricilerin çok fazla "mükemmeliyetçi" olduğuna inanıyorlar. Geliştiricilerin "her zaman her şeyi belirtmek istediklerinden" rahatsız görünüyorlar.

Genel olarak kabul edilen sayıların bulunmaması nedeniyle tartışılması zordur. Herkes ne kadar bir yinelemenin gerektiğini bilir. Ancak hiç kimse bir hikayeyi tahmin etmek ve geliştirmek için ne kadar gereksinimin gerekli olduğunu söyleyemez.

Referansınız var mı?

Çevik noktasını biraz özlüyorsun. Bir kullanıcı hikayesi olarak adlandırdığınız şeyi en az altı olarak görüyorum: bir çıplak kemik araması ve bir mermi noktasınızın her biri için bir tane. Elbette, kendinizi kurtulmak için pahalı olacak bir köşeye boyamaktan kaçınmak için yeterli planlar yapın, ancak tüm fikir, bir miktar değer sunmak için gereken minimum değeri sağlamanız ve hızlı geri bildirim almak için yeterince hızlı bir şekilde yapmanızdır.

Bir hikayeyi bu şekilde böldüğünüzde, tahmin etmeyi kolaylaştırmakla kalmaz, aynı zamanda ürün sahibinin daha hassas bir şekilde öncelik vermesini sağlar. Kesinlikle arama sonuçlarını sıralama yeteneğinden hoşlanırlar, ancak iş yerindeki arama ile tamamen ilgisi olmayan başka bir öğe kadar önemli olmayabilir.

Ayrıca, belirtilen her şeye ihtiyaç duyan programcılar fikri üzerine, müşterinin bakış açısından ona bakmaya çalışın. Çoğu zaman, bir araba satın alacaksınız ve satıcı ön cam silecek düğmesi için ne renk istediğini soruyor. Önemli bulabileceğimiz birçok detay, müşteri açısından tamamen önemsizdir. Gereksinimlerin çok fazla belirtildiği yerlerde çalıştım ve bana güvenin, çok eğlenceli değil. Şikayet ettiğiniz tür enlem, birçok programcıya sahip olmak ister.

İlk sorun, kullanıcı hikayelerine zaman tahminleri uygulamanız gerekmemesidir. Bir hikaye almanız ve 1'den INFINITY'e kadar karmaşıklığın genel bir tahmini olan "hikaye noktaları" nı uygulamanız gerekir. Hikaye noktaları genellikle 1,2,3,5,8,13,20 gibi bir şeyle yönetilir ... (Her kuruluşun kendi kuralları vardır.) Genellikle aşağıdaki gibi bir şey uygularlar:

1 - Uykunuzda yapabilirsiniz ve uygulanmaya değmez. 2 - Bunu anlıyorsunuz ve az taşma riski ile hızlı bir şekilde yapabilirsiniz. 3 - Bunu anlıyorsunuz, ama bir iki sürpriz olabilir. 5 - Bu biraz araştırma yapacak ve az miktarda riski var. 8 - Bu büyük bir görevdir, çok fazla araştırmaya ihtiyaç duyar ve bir sprint'e uymayabilir. 13 - Bu çok büyük ve kesinlikle bir süratle uymuyor. Büyük bir risk var. vb.

Genellikle, 8 veya üstü olan herhangi bir kullanıcı hikayesinin daha küçük hikayelere bölünmesi gerekir.

Bunu yapacak bilgiye sahip değilseniz, kesinlikle proje yöneticisine geri atmanız ve daha fazla bilgiye ihtiyacınız olduğunu söylemelisiniz.

Gerçekten sadece hikayeyi koşuya kabul ettikten sonra zaman tahmin etmelisiniz, ancak o zaman bile, buna daha az vurgu var. Fikir şu ki, takımınız işaretleme sürecine alıştığında, sprint başına kaba çıktısını hikaye noktalarında ölçebilir ve bu şekilde planlayabilirsiniz. Sprint'ten daha kısa bir zaman ölçeğinde plan yapmak istemezsiniz. Buradaki fikir, görevleri birden çok hikayenin bir sprint'e sığması ve 1-5 hikaye noktası aralığında olması için görevleri doğru şekilde parçalara ayırırsanız, bunların yeterince iyi tanımlandığı anlamına gelir.

Ayrıca, şirketinizdeki PM'lerin bir "hikaye" nin ne olduğunu anlamadıkları anlaşılıyor. "Kullanıcı hikayesinin" kritik bir kısmı çıkış ölçütleridir. Çıkış ölçütleri, bu depolama alanının tamamlandığının nasıl net bir şekilde tanımlandığını açıklayan kısa veya iki cümledir. İdeal olarak, bu KG ekibinizin "evet, bunu test edebiliriz" dediği bir şey olmalıdır. Önemli olan, yazılımların "çıkış kriterleri" ni karşıladığında PM'lerin bir kullanıcı hikayesinin tamamlandığını anlamalıdır. "Ama biz bunu istemedik" diye kesmez. Teslim edilenleri istemiyorlardı, ancak çıkış ölçütleriyle eşleşiyorsa, yeni bir hikaye girmek zorundalar.

Burada kesinlikle "PM'lerin eğitimi" unsuru var. Belirsiz öykülerin büyük öykü noktalarına yol açtığını ve öyküyü istediklerini elde etmek için belirsiz bir şekilde tanımladılarsa, tekrar yapmaları gerektiğini öğrenmeleri gerekir.

Açıkçası, paydaşlar yeterli bilgi toplamıyorsa, yapmanız gerekir ve eğer yapmanız gerekiyorsa, bu çok daha fazla iştir, değil mi? Çevik günlerimden çok önce, çok büyük tahminler vererek ve tahminlerin bilgi eksikliğinden kaynaklanan riske izin verecek kadar büyük olduğunu açıkça söyleyerek başarılı oldum. Tüm sorular için en kötü durumu varsaymak zorunda kaldım ve bu en kötü duruma göre tahmin ettim. Yöneticilerin, tahminlerde düşüşle sonuçlandıklarını görünce daha fazla ayrıntı vermeye istekli olduklarını gördüm.

Bu sistemde oyun oynamak değil ... bu tamamen geçerli. Eğer "A" ya da "B" olup olmadığını bilmiyorsanız, hangi kıçınızı kapsayacak en büyük tahmini verir tahmin.

Deneyimlerime göre, üzerinde çalıştığım değişikliklerin veya projelerin çoğu bu şeyle ilgileniyor. Özel X bir şey istiyor ve ne istediklerine dair bir fikirleri var, ancak size sadece küçük bir e-posta gereksinimi veriyorlar. Bunun nedeni çoğunlukla müşterinin ne istediğini 'tam olarak' bilmemesi. Bu nedenle müşteri hizmetleri departmanımızın işlerinin çoğu, bu müşteri taleplerini ortadan kaldırıyor ve gerekli bilgileri filtreliyor ve aynı zamanda müşterinin GERÇEKTEN ne isteyeceğini ya da gerçekten neye ihtiyacı olduğunu tahmin ediyor.

Bir müşterinin (benim için) web uygulamamızın bir bölümünün tüm telefon numaralarının bir listesini döndürmesini istediğini varsayalım. Asla fiziksel olanları, mantıksal olanları, bir kişiye veya bir konuma atananları, vb. Sadece tüm telefon numaralarını istiyorlar. Bir geliştirici olarak, orada oturabilir ve müşteriye sormanız gereken bir düzine veya daha fazla soru düşünebilirim. Ama dediğin gibi bu mümkün değil. Bu yüzden ürünü bilen iyi bir müşteri hizmetleri departmanına sahip olmak paha biçilmezdir.

Müşteri temsilcilerimize bu tür bir çağrı geldiğinde, doğru soruları cevaplamaları için kendilerine ne sormaları gerektiğini bilerek, müşteriyle üzerinde ayrıntıya girebilirler. Ayrıca, müşterinin geçmişte ne istediğini bilmeyi önceden düşünüyorlar ve geliştirdiğimiz sistemler hakkında, istemeden bile sormadan bir şeye evet ya da hayır diyebileceklerini biliyorlar.

Elbette, müşterinin hem sizin hem de müşteri hizmetlerinin kaçırdığı başka bir şeye ihtiyaç duyacağı birçok vakanız olacak, ancak bu her zaman gerçekleşecek. Hedefiniz ve müşteri hizmetlerinin amacı, bir şey geliştirmeniz ve yapılması gereken değişikliklerle istemciden geri almanız arasındaki gecikme süresini en aza indirmelidir. Ve bu sadece müşteri hizmetlerinizle iletişim ve eğitim demektir.

Belki benim için olduğu gibi mümkün değil, ama müşteri temsilcilerinizle iyi bir iletişim ve güven hattına sahip olmak neredeyse her zaman dereceye kadar size yardımcı olacaktır ve hayal kırıklığınızı azaltacak ve müşterinin memnuniyetini artıracaktır. Ayrıca, omuzlarınızı silkmek ve "Projenin tüm kapsamını bilmiyorum, bu yüzden ne kadar süreceğini bilmiyorum" demek yerine, projeleriniz için daha kolay bir zaman çerçevesi verebilirsiniz. Burada aynı sorunu yaşıyoruz ve daha iyi iletişim ve eğitim, makul son tarihler oluşturmamıza ve bunları tutarlı bir şekilde vurmamıza yardımcı olan şeydir.

Müşteri

Ürün aramak istiyorum

Ürün yöneticisi Müşterinin hikayesini analiz ettim ve aşağıdaki gereksinimleri karşıladım. Her gereksinim ayrı bir kullanıcı hikayesi olarak kaydedilmiştir.

• Ürün ara
• Sonucu sırala
• Arama sonuçlarını filtrele

Geliştirici Bir ürün yöneticisinden kullanıcı hikayeleri aldım. Her kullanıcı hikayesini analiz ettim ve her kullanıcı hikayesi için bir görev listesi buldum.

• Ürün ara
  1. Görev 1: Veritabanı değişiklikleri
  2. Görev 2: Sunucu tarafı değişiklikleri
  3. Görev 3: Kullanıcı arabirimi değişiklikleri

Müşteri, ürün yöneticisi ve geliştirici bu süreçte pay sahibi. Çalışma başlamadan önce hepsinin analiz sürecine katkıda bulunmaları gerekir. Bunun çok basitleştirilmiş bir örnek olduğunu lütfen unutmayın.

Kullanıcı hikayelerimiz aşağıdaki sıraya göre analiz edilir ve rafine edilir (elbette bazı varyasyonlarla):

Yardım Masası -> Ürün Sahibi -> Ürün Yöneticisi -> Departman Adayları (kıdemli geliştiriciler, qa adayları, vb.) -> Geliştiriciler

İlgili tüm paydaşlar analiz sürecine katkıda bulunduktan sonra, hikayeyi sunmamızın ne kadar süreceğini tahmin edebiliriz. Takip ettiğimiz tahmin süreci, bireysel geliştiricilerin hızı ve uzmanlığına dayanmaktadır.

Bunun bir şeyler yapmanın doğru bir yolu olduğunu söylemiyorum, ama organizasyonumuzda gerçekten iyi çalışıyor.