Şu anda geliştirme çalışmalarımızı takip etmek için JIRA kullanıyoruz. Yönetimim, yazılım geliştirme ile ilgili olmayan görevler de dahil olmak üzere her şeyi "Kullanıcı Hikayeleri" olarak biçimlendirmek ve kategorilere ayırmak istiyor. Örneğin:

"Bir test yöneticisi olarak, uygulamayı mümkün olduğunca verimli bir şekilde test edebilmem için yalnızca otomatik testler kullanarak ve manuel test olmadan uygulamayı test edebilir miyim?

Kabul Kriterleri: 1. Mevcut 50 manuel testi tam otomatik testlere dönüştür 2. Testler 1 saatten daha kısa sürede yapılmalıdır "

Yazılım geliştirme sürecini destekleyen, programcılar tarafından yapılmayan ve doğrudan teslim edilebilir kodla sonuçlanmayan işler için "kullanıcı hikayelerini" kullanmanın mantıklı olması durumunda topluluktan bir anlam almak istiyorum. Yoksa bu farklı şekilde ele alınmalı / sınıflandırılmalıdır (örneğin, JIRA'da)?

Updated 6/7/2011 - "Kullanıcı hikayesi" terimine odaklanmak için yeniden soru soruldu.

Evet

herhangi bir paydaş, sistemi geliştiren herhangi bir özellik

[sade inişler başlasın!]

"Yönetimim Agile yazılım geliştirme ile ilgili olmayan görevler de dahil olmak üzere her şey için kullanmak istiyor."

Bu mu değil her özellik için kullanıcı hikayelerini yazmak demek.

Her özellik için kullanıcı hikayeleri yazmak istiyorsanız, Agile olmanız gerekmez . Her özellik için sadece kullanıcı hikayeleri yazıyorsunuz.

Kullanıcı Hikayeleri! = Çevik.

Kullanıcı Öyküleri, gereksinimleri toplamanın ve anlamanın bir yoludur. İsterseniz, mükemmel bir şelale şekilde kullanılabilirler. Bazı insanlar bunu yapar.

Çevik, projeleri yönetmenin bir yoludur. Agile projesinde Kullanıcı Öyküleri'ni kullanabilir veya kullanamazsınız.

Teknik borcu ve dahili görevleri yönetmek için Kullanıcı Öyküleri - yine - Çevik olmakla hiçbir ilgisi yoktur.

Birçok kişi, tamamen dahili, sınırlı katma değerli, paydaş olmayan kullanıcılar için sahte bir "kullanıcı hikayesi" yazmak için zaman kaybetmeden "teknik" veya "destek" özelliklerini bir sprint'e eklemekten mutluluk duyar.

KG hikayelerini anlamazsa, ne kadar gerçek iş kaybı olur?

Gerçek paydaşlar hikayelerini almazlarsa, iş gerçekten acı çeker.

Bu benim için bir anlam ifade etmiyor. Bir 'Kullanıcı Hikayesi' aslında sadece bir kullanıcı hikayesi, bir Proje Yöneticisi hikayesi değil, bir Geliştirici Hikayesi değil, bir Kalite Güvence Mühendisi hikayesi değil.

Bu notta yazılım:

1. tanımlanabilir
2. Test edilebilir

Süreç iyileştirmeleri açık uçludur ve tipik olarak özneldir.

Kabul Kriterleri: 1. Test 1'de iyileştirme (x / y ile)

Test Geliştirmesini nasıl ölçersiniz? Bunun için kesin bir sözleşme yoktur.

Ve ilgisiz bir notta, yukarıda verilen örneğin,

Bir test yöneticisi olarak, uygulamayı mümkün olduğunca verimli bir şekilde test edebilmem için yalnızca otomatik testler kullanarak ve manuel test olmadan uygulamayı test edebilir miyim?

... sadece bir örnek, çünkü bununla ilgili o kadar çok yanlış var ki açıklamaya bile başlayamıyorum.

Teknik Borç , bir kullanıcı hikayesine benzer şekilde ele alınabilir, ancak bu bazen çirkinleşebilir. Örneğin, "Bir geliştirici olarak, çalışma birimi testlerine sahip olmak istiyorum, böylece diğer değişikliklerin bir şeyi bozduğunu doğrulamak için testlere güvenebiliyorum" gibi bir hikayeye sahip olmak, ürün sahibine çok değer vermiyor ancak takımın bir sprint'teki çalışmanın bir parçası olan kendi yeniden düzenleme sürecinin bir parçası olarak yapması iyi bir fikir olabilir.

Görevler bir sistemin son kullanıcısına göstereceğiniz bir şey olmayacağından, ancak bakım ve bu sürenin uzamasına yardımcı olacak bir şey olabileceğinden, kullanıcı hikayelerinden ayrı görevlere sahip olma fikrini seviyorum. bazı yeni özellikler geliştirmek. Kaç tane göreve bağlı olarak, toplam puan toplamı açısından bazı görevler 2 dakika ve diğerleri 2 hafta olabilir, ekibin bir sprint alıp yeni özellikler koyup koymadığını ancak işe yarayıp yaramadığını belirleyen bu olabilir çalıştığım yerde birkaç kez gördüğüm şeyleri temizlemek için

Benim düşünceme göre, evet, yalnızca süreç geliştirme görevlerini değil, yazılım dışı geliştirme projeleri için de kullanıcı hikayelerini kullanabilirsiniz. Örneğin, 3 yıl önce arkadaşımın düğününde en iyi adamdım ve düğünü planlamak için Agile metodolojisini ve kullanıcı hikayelerini kullandım. Tamamlamamız gereken tüm görevler, her bir kullanıcı hikayesi için kişisel, niyet, gerekçe ve başarı kriterlerine sahip kullanıcı hikayeleri olarak yazılmıştır. İlgili tüm taraflar, önceki gün ne yaptığımızı ve o gün ne yapacağımızı tartışmak için günlük scrumumuza katıldı. Herkes coğrafi olarak dağılmıştı, bu yüzden günlük scrum toplantılarımız, sprint planlama, retrospektifler, hikaye yazma ve tahmin oturumları için konferans görüşmeleri yaptık .... siz söyleyin, biz yaptık. Toplam 6 sprint (3 ay) vardı ve düğün hiç taş kalmamış şaşırtıcı bir başarı oldu.

Dahili "kullanıcı öyküleri" ni gerçek kullanıcı öyküleriyle karışıma koyduğunuzda büyük bir sorun var.

Lütfen bulabildiğiniz kadar "paydaş" tanımını tekrar okuyun.

http://en.wikipedia.org/wiki/Scrum_(development )

http://wiki.openbravo.com/wiki/Scrum/Pigs_and_Chicken

http://www.testertroubles.com/2009/04/scrum-pigs-and-chickens.html

Tavuklar ve Domuzlar arasındaki farkı görebilmek için onları çok, çok dikkatli bir şekilde okuyun.

Dahili "kullanıcı hikayeleri" tavuklar tarafından yazılmıştır.

Gerçek kullanıcı hikayeleri domuzlar tarafından yazılmıştır.

"Tavuk odaklı" kullanıcı hikayeleriniz çok önemli değil. Yönetimin onları gerçek değere sahip gerçek kullanıcı hikayeleri gibi izlemek istediği ne olursa olsun, gerçek kullanıcı hikayeleri değildir ve aynı şekilde değer yaratmazlar.

Argümanın bulanık kenarında KG sorunu var. KG önemlidir ve onsuz hiçbir şey işe yaramaz.

Bu sihirli bir şekilde KG'yi aniden bir domuz yapmaz. Onları hala paydaş yapmıyor. İşin geri kalanı için destek, altyapı ve temel bir temel sağlarlar. Ancak bunlar "kullanıcı hikayeleri" dir, gerçek kullanıcının gerçek kullanıcı hikayelerinden farklıdır.

KG testte testte bir gelişme göstermezse, hiç kimse işten çıkmaz. Para kaybolmaz.

Eğer kullanıcı ilk etapta iş yapamazsa, işiniz bitmiştir. Para kayboldu. Tüm işlem toplam bir hatadır.

İç ("tavuk") ve gerçek ("domuz") paydaşlarını karıştırmayın.

"Tavuk ve domuz" yorumu özlüyor. İç paydaşlar, geliştirilmekte olan ürün söz konusu olduğunda tavuklardır (onlar için geliştirilmediği sürece), ancak geliştirme süreci söz konusu olduğunda domuzlardır.

Sorduğunuz soru şu cümle formülü olup olmadığını: , Yapabilmek istiyorum _ , böylece ben __ "iyileştirmeler yeni yazılım kodu yazma gerektirmeyen iş süreçlerini tanımlamak ve geliştirmek için yararlı olacaktır. Ben aynı şeyi yapmayı düşünüyorum ve en iyi uygulama arıyorum, ama bu konuya geldi benim güçlü sezgim, sorunuzun cevabının "evet" olduğudur. Cümle yapısının amacı, yazarı gerçekten aklında olabilecek çözümleri soyutlamaya ve kullanıcının neye odaklanacağına zorlamaktır. Bu durumda, kullanıcı - işlem yapabilmek istemektedir.Kullanıcı hikayesinin işleme uygulandığında neden yararlı olmayacağına dair hiçbir neden göremiyorum.

Kabul kriterleri ile ilgili nokta iyi bir konudur, ancak bu konuda dogmatik olması gerekmez (yine de Agile). Herhangi bir iş süreci tasarlarken, "Süreçteki değişimin hedefime ulaşıp ulaşmadığını nasıl anlayacağım?" Diye sormak iyi bir uygulamadır. Bu soruyu cevaplamak için her zaman otomatik bir test uygulayamayacağınız doğrudur, ancak bu kullanıcı hikayesini bir araç olarak diskalifiye etmenin bir nedeni değildir.