Kullanıcı Hikayesi - Gereksinim


33

Kullanıcı Hikayesi, kullanıcının sistemle ne yapmak istediğini yüksek bir seviyede tutar. Kullanıcı hikayesinin bir takım düşük seviye gereksinimleri daha da ileri götüreceğini biliyorum. Kullanıcı hikayesi sistem için yüksek seviye gereksinimi ile aynı mıdır?


"Kullanıcı Hikayesi, kullanıcının sistemle ne yapmak istediğini üst düzeyde yakalar ". Bunu çekişmeli buluyorum. Sana yerini eğer kendimi kabul bulacağını yüksek düzeyde olan özellik seviyesinde .
8bitjunkie

Yanıtlar:


52

Dürüst olmak gerekirse, Çevik gelişime daldırılmış iki yıla yakın bir zaman harcadıktan sonra, hala "kullanıcı hikayesi" nin "işlevsel gereksinim" için sadece süslü bir terim olduğunu düşünüyorum.

Yüzeysel düzeyde farklıdır , örneğin her zaman belirli bir biçim alır ( "bir X, Y'yi istiyorum, bu yüzden Z ..." ), ancak paydaş ve gerekçeyi tanımlayan temel unsurlar da doğal olarak doğaldır. yazılı işlevsel gereksinimler. Kötü bir gereksinim yazmak kadar kötü bir kullanıcı öyküsü yazmak kadar kolay ( "[şirketimizin adı]] gibi, [belirsiz özellik] istiyorum, böylece [işimin özünde açıkça görünen bir şeyi yapabilirim] 'müşterilere daha fazla satmak'] " ).

Kullanıcı hikayelerinin neredeyse asla yakalayamadığı şey, deneyimime göre, performans ve güvenlik gibi işlevsel olmayan gereksinimlerdir. Bu tür gereksinimlerin doğru yazılması çok zordur ve kullanıcı öyküsünün biçimi yalnızca onları yakalamak için çok iyi değildir, çünkü bunlar belirli bir kullanıcının yerine getirilmesinden ziyade genel ürün kalitesi ve riskleri hafifletmek (ancak ortadan kaldırmak değil) hakkındadır. gerek.

Bu yüzden, kullanıcı hikayelerini gerçekten belirli bir formüle sahip bir gereksinimler alt kümesi olarak düşünüyorum ve hala terimleri birbirlerinin yerine kullanabiliyorum.

Kullanıcı hikayelerinin gereksinimler üzerinde sahip olduğu en büyük avantaj, "gereksinim" kelimesinin genellikle sadece istenildiği bir yerde bir özellik gerektiğini öne sürmesidir . Kullanıcı öyküleri teoride herhangi bir sürüm için önceliklendirilebilir ve seçilebilir, oysa gereksinimler her sürüm için bir ön koşul gibi görünmektedir .

Tabii ki, yukarıda belirtilen ayrımdan dolayı, müşterileriniz ve / veya üst yönetiminiz bunu benimsemelidir; hepsi aynı anda tamamlanması gereken bir "projeye" göre gruplandırılmış 30 kullanıcı hikayeniz varsa, bunun hiçbir faydası olmaz. Bu durumda onlara “gereksinimler” de diyebilirsiniz, çünkü aslında zorunludurlar.


tüm cevaplar anlayışıma yardımcı oldu, hepsini doğru olarak işaretlemek istedi :)
Punter Vicky

5
Kabul etmiyorum: gereksinimler, kullanıcının NASIL ile etkileşime girdiğine, özelliklerin NE YAPMALI olduğuna dair hikayelere odaklanır. Onlar tamamen farklı şeylerdir.
Sklivvz

1
@Sklivvz: Kullanıcının sistemle nasıl etkileşime girdiğiyle ilgili bir şey söylemeyen bir kullanıcı hikayesi okuduğumu sanmıyorum ve dediğim gibi, iyi gerekliliklerin anlaşılması için bir amaç beyanı ile geldiğini düşünüyorum bağlamı. Bazı nedenlerden dolayı, birçok insan otomatik olarak "geleneksel gereksinimler = kötü gereksinimler" ve "kullanıcı öyküleri = iyi gereksinimler" olduğunu varsayıyor gibi görünmektedir. İkisi de mutlaka doğru değil. Örneğin , her gereksinimi sadece bir iş hedefine değil gerçek bir metriğe bağlayan "EVO" yu ele alalım .
Aaron,

1
@ hanzolo: Şimdi sadece saçma. Görevler olan yolu işlevsel gereksinimleri herhangi bir kullanım olamayacak kadar granül. Görevler, "jibbler kütüphanesini kullanarak bir saçak çözümleyici uygulama" bölümünde olduğu gibi oldukça teknik seviyelerde belirtilir. Sen olabilir belki kinda sorta-neredeyse gibi olmak görevler için bir dava haline spesifikasyonları , ancak bu gelir sonra gereklerine. Kullanıcı Öyküleri gelmek gerekiyor Kabul Kriterleri - olanlar çok daha fazla / RUP tipi modeller Şelale kullanılan detaylı fonksiyonel gereksinimleri gibidir.
Aarona

2
@Sklivvz: "Ne" genellikle kullanıcı ile sistem arasındaki etkileşimdir. "Cevaplardaki toplam oyu görmek istiyorum", kullanıcı hikayesinin orta kısmına tipik bir örnektir ve işlevsel bir gereksinime neredeyse aynı şekilde ifade edilir ("Kullanıcı cevaplardaki toplam oyu görebilmelidir") . “Kim” ve “neden” görünüşte farklı olan tek parçadır ve kullanıcı öykülerinden başka birçok gereksinim izleme sistemi / metodolojisi de bunların sağlanmasını beklemektedir.
Aaron

16

Ron Jeffries, uzun zaman önce 3C kullanıcı öyküleri hakkında ( http://xprogramming.com/articles/expcardconversationconfirmation/ ) bir karta vurgu yaparak (kısa bir açıklama), müşteriyle teslimat ekibi arasındaki bir kullanıcı öyküsüne değinerek yazdı. eyleme geçilebilir ve bu konuşmadan sonra bir öykünün onaylanması onaylanır.

aslında, konuşmadan önce, kullanıcı hikayeleri sadece planlanmış bir kapsamdır - ne yapabileceğimiz hakkında kaba fikirler. Görüşme sonrası, hikayenin tamamlandığını doğrulamanın bir yolunu bulmalısın. Öyleyse, bu zaman çizelgesindeki hikayeye baktığınız zamana bağlı olarak, bir hikaye sadece kapsamla ilgili ayrıntılı bir fikir veya ayrıntılı bir gereklilik olabilir.

Bugünlerde “kullanıcı hikayesi” nin anlamı, Jeffries'in 3C'lerinin sadece “kart” kısmına daralmış gibi görünüyor. Bu durumda, bir kullanıcı hikayesi bir gereklilik değil, ihtiyaçlar hakkında konuşacak bir sözdür.

C2 wiki'deki kullanıcı hikayeleri hakkında bir ton altın bilgelik bulabilirsiniz ( http://xp.c2.com/UserStory.html )


7

Kullanıcı hikayeleri ve gereksinimleri çok farklı canavarlardır.

Gereksinimler

Gereksinimler, uygulamanın tasarımının önceden yapıldığını ve geliştirmenin bu tasarımın uygulanması olduğunu varsayar. Gereksinimler bu nedenle bir işlevin nasıl uygulanacağına odaklanır .

Gereksinim örneği:

  • Aşağıdaki alanlardan oluşan bir kullanıcı iletişim formu oluşturun: ad, soyad, e-posta, serbest metin ve gönder düğmesi. Gönder düğmesine basıldığında, destek ekibimize bir e-posta gönderilir.

Kullanıcı hikayeleri

Kullanıcı hikayeleri neyin başarılacağına odaklanır ve ürünün tasarımının son dakikada yapılmasında ve bir ürün insanı ile bir geliştirici insan arasında bir işbirliği olduğu konusunda ısrar eder. Ayrıntılara uygulama sırasında fırsata dayalı karar verilir.

Bir hikaye örneği:

  • Jimmy olarak kullanıcı siteyi gerektiği gibi kullanamadığımda destek ekibinizle bağlantı kurmak istiyorum böylece bana yardımcı olabilirler.

Fark ne?

Görebildiğiniz gibi, verilen ayrıntıların miktarında kesinlikle bir fark var, ancak aynı zamanda yalnızca bu hikayede elde etmeye çalıştığımızın amacı olan hikayede mevcut olan birçok bilgi var .

Amaç nispeten önemsiz gibi görünse de, çevik gelişimde bu yanlış bir varsayımdır. Amacın bilinmesinin çok önemli olduğu tipik olarak iki durum vardır: fırsat maliyetini azaltmak ve çevikliği sağlamak.

Fırsat maliyeti

Gereksinimlerde gizli varsayımlar varsa, elde edilmesi çok zor olabilir. Örneğin: bir posta sunucusu var mı? Aksi takdirde, gereksinimin geliştirilmesi daha uzun sürebilir. Diğer bazı durumlarda, tasarım nedeniyle aynı hedefe ulaşmanın daha basit bir yolu kaçırılabilir.

Buna karşılık, kullanıcı hikayesi destek departmanımızla iletişim kuran bir kullanıcı hakkındadır. Bir posta göndermek mümkün değilse veya çok pahalıysa, yerinde farklı bir çözüm önerebiliriz: örneğin bir veritabanına yazın, ya da Google docs yoluyla bir form kullanın ya da sadece form yerine bir e-posta adresi koyun. Bu bir gereksinimle kolayca yapılamaz, ancak kolayca bir hikaye ve hazır bulunan bir ürün ile yapılır.

Çeviklik

Bu sebeple, gerekliliklerle, genellikle önceden bu gizli varsayımları düşünmeye meyilliyiz ve aksama olmadığından emin oluruz. Bu nedenle, bu durumda elden önce planlanmış ve bir posta sunucusunun var olduğundan emin olan farklı bir gereksinim olabilir.

Bu bizi hiyerarşi olan hikayeler ve gereksinimler arasında başka bir büyük farklılığa götürür . Yukarıda örneklendirdiğim gibi, gereksinimler, kendi doğası gereği, bazı doğal hiyerarşilerde, böylece bağımlılıkların karşılanması için sipariş edilmelidir. Öte yandan, hikayeler bilerek odaklanır ve bu tür kısıtlamaları yoktur.

Bu, tasarım gereği, çevik olduğu gibi, projenin yürütülmesi sırasında ihtiyaç duyulan hikayeleri eklemek, kaldırmak, yeniden planlamak ve değiştirmek için çok önemlidir. Gereksinimler genellikle eklenebilir, bazen değiştirilebilir veya kaldırılabilir, ancak tüm bağımlılıklar nedeniyle onları hareket ettirmek çok acı vericidir. Sadece çok sık yapılmaz. Gereksinimlerle çalışıyorsanız çevik uygulamanız, değişimi benimsemek anlamında acı çekecek veya muhtemelen hiç çevik olmayacaktır.


6
Bunların yanlış yoldan geldiğini söyleyebilirim - gereksinimler "kullanıcının iletişime geçmesine izin ver" dır. Öyleyse, bunun detayı ekleyerek mantıklı olan bir şeyle nasıl tanımlanacağı anlatılmaktadır. Belki de her şey terminolojiye indirgenmiştir ve bu yüzden hiçbir şey yapmamaya başladık.
gbjbaanb

2
Onları yanlış anlamadığımdan eminim.
Sklivvz


15
“Gereksinimler bu nedenle bir işlevin nasıl uygulanacağına odaklanır.” - Bu çok yanlış. Eğer bir şart nasıl yapılacağını söylüyorsa, bu iyi bir şart değildir. Bilinen bir kısıtlama olmadığı sürece, gereksinimler herhangi bir tasarım veya uygulama detayı içermez. Örnek "şartını" görseydim, hemen reddederdim - uygulama detaylarını belirtir.
Thomas Owens

4
Birden fazla (saygın ve sıkça alıntı yapılan) kaynaklar artı gereksinimler mühendisliği konusundaki eğitimim ve deneyimim bana aksi söyler. Bir şeyi nasıl başardığınızla ilgili bir şey söylerseniz, tasarım çalışması yaptınız. Bir mock-up tasarım değil, şarttır. Biçimden bağımsız olarak, bir gereksinim, tasarım seçimlerinin kendisi değil, "tasarım seçimlerini yönlendiren herhangi bir şey" dir. Aaronaught'ın bir kullanıcı öyküsünün işlevsel gereklilikleri yakalamanın sadece bir formatı olduğu cevabına tamamen katılıyorum, bu cevabın çoğunu genel kabul görmüş terimler açısından yanlış yapıyoruz.
Thomas Owens

6

Bana göre, Kullanıcı Hikayesinin kritik bir unsuru, bir kullanıcının sistemi neden ve nasıl kullandığını yakalamasıdır. Özellikle yararlıdır, çünkü sistemin gereken işlevselliği nasıl sağladığını çok fazla belirtmez. Kullanıcı Arabirimi ve Kullanılabilirlik testi gerektiğinde, Kullanıcı Hikayesi en önemli belge olabilir.

Elbette, selenyumun HTML'de belirli düğümlerin bulunduğunu veya ekran görüntülerinin alındığını veya belirli piksellerin bulundukları yerde bulunduğunu doğruladığından emin olabilirsiniz. Ancak yanıltıcı metin varsa veya kullanıcının sistemi nasıl kullanması gerektiği belli değilse veya bir kullanıcının hedeflerine nasıl ulaşacağını bulması zorsa, aniden tam bir sisteminiz olmaz. Şimdi sistemi kullanmak için eğitim gerekiyor. Tamamlanan sistemi kullanıcı senaryolarına göre incelemek, manuel testlerin kritik bir bileşenidir.

Kullanıcı öykülerinde / senaryolarında, uygulama hakkında birçok ayrıntılı tasarım kararını etkilemesi gereken bir zihin kümesi vardır. Geliştiriciler doğrudan kullanıcılarla konuşmadıklarında veya sistemi kullanmalarını izlemedikçe, kullanıcı senaryosu, kullanıcıların ihtiyaçlarını anlamalarına izin veren tek bağlantı olabilir.

Son olarak, iş adamlarının, neye ulaşmaları gerektiğini önermeden ihtiyaç duyduklarını belirtmelerini sağlar. Bir çözümü tanımlamak bir ihtiyaçtan daha kolaydır ve kullanıcı senaryoları, belirli bir çözüm önermeden ihtiyaçları tanımlamak için bir çerçeve sağlar. Duyduğum en yaygın iş gereksinimi, aslında tam olarak ihtiyaç duydukları şey olmadı, "Ben de aynen Excel gibi olmasını istiyorum, ancak web üzerinde".

Bu yüzden, iyi bir hikayenin sistemin nasıl uygulanacağı hakkında herhangi bir özel ayrıntı içermemesi gerektiğini söyleyebilirim. "Ayda bir kez, sistem A'nın sistem B'deki yeni verilerle güncellenmesi gerekir. Bu veriler düzeltmeler gerektirebilir. Müşterinin geçersiz veriler girme ve sorunu haftalarca gerçekleştirmeme geçmişi vardır." "Sistem, latin1 CSV dosyasını en az ayda bir kez kabul etmeli ve sütun 3 bir sayı değilse, bir NumberFormatException atmalıdır" dememelidir. Farkı görüyor musun? Senaryo, belirli bir çözümü değil, ihtiyacı açıklar. Ardından, sınamada, çözümün ihtiyaca uygun olduğundan emin olmak için senaryoya geri dönersiniz. Gereksinimler, bazı ihtiyaçları bazı çözümlerle karıştırabilir, hatta tamamen çözümlere odaklanabilir.


Sağol Glen! Ancak bu konuda gereklilik veya kullanıcı öyküsü sistem / çözüm agnostiği olmamalı mı? Bu, bir kullanıcı hikayesi / gereksinimi yaratırken üzerinde durduğum, ancak bazı durumlarda başarılı bir şekilde başaramadığım bir başka soru
Punter Vicky

Kullanıcıya sistemin çözeceği iş sorununu sorarak başlayabilirsiniz. Şimdi bu problemi nasıl ele alıyorsunuz? Sisteme sahip olduğunuzda aynı şekilde çalışır mısınız? Şimdi bu görevleri kim yapıyor? Nerede yapıyorlar? En sık karşılaşılan zorluklar nelerdir? Gereksinimlerin teoride oldukça sistem agnostik olması gerektiği mantıklı. Ancak uygulama daha dağınıktır. Tüm işlerimi benim için hala hiçbir şey yapmadan para kazanabileceğim şekilde yapan bir sistem istiyorum. Bu sistem agnostik, ama işe yaramaz. Önemsediğimiz şey geliştirme ekibinin inşa edebilecekleri gereksinimlerdir.
GlenPeterson,

3

Google'da arama yaparken bunun üzerine tökezledi ve fikrimi ortaya koyacağımı düşündüm.

Bir gereklilik ile bir kullanıcı hikayesi arasında gerçekten bir fark yoktur. Her ikisi de istenen sonucu veya hedefi kullanıcı bakış açısından belirtir.

Tek fark, bu hedefin veya sonucun bir iş analisti tarafından yakalanma şeklidir. Bu durumda ifadelerdedir.

Örnek:

Takım lideri olarak, hangi takımın ipotek davaları üzerinde çalıştığını görmek istiyorum, böylece performanslarını izleyebiliyorum.

Çözüm ipotek davalarında çalışan ekip üyelerini gösterecektir.

Yukarıdakilerin her ikisi de aynı şekilde yorumlanabilir ancak her ikisi de çok fazla belirsizliğe sahiptir. Buradaki ana nokta, stil açısından bir fark. Bence en çok gördüğümüz mesele, gereklilik dünyasından ve işlevsel tasarım dünyasına geçmeden önce çözümü ne kadar ileri götürdüğümüzdür. İş analisti, "ana uygulama menüsünde ilk ve ikinci isim ile giriş yapan kullanıcıların listesini" veya bu kadar fazla bilgi olduğunu belirtiyor mu? Paydaşlarımızla konuşmaya oturduğumuzda ve hepimiz çözümü biliyoruz ve neye benzeyeceğini yorumlayabiliyoruz, geliştirileceği muhtemel kod dili ve konuşlandırılma şeklini bile gerçekten saf oyun oynamamız gerekiyor. " "Hedefleri tanımlayalım, çözümleri tanımlayalım". Bu, kafamın karıştığını hissettiğim yer.

Gereksinimler sık ​​sık, sadece istenen sonuçların çözümü hakkında hiçbir şey bilmediğimizi varsaymaktadır. Evet, bu herşeyi çözümü agnostik yapar ama bu gerçekten gelişim döngüsünde bize yardımcı oluyor mu? Bir şeyi doğru bir şekilde erken tanımlayabilirsek neden olmasın?

Sonuçta ben kullanıcı hikayeleri ve gereksinimleri farklılıkları hakkında endişelenmeyeceğim. Sonuçta, birisinin bir çözüm geliştirmesi için yeterli bilgiyi tanımlamak istersiniz. Çok yüksek bir kullanıcı hikayesi basitçe geri çevrilecek ve daha küçük kullanıcı hikayelerine bölünmesi istenecek. Aynı şekilde bir "sistem" tarzı olacaktır. Gereklilik yeterli değilse, gereklilik çok belirsiz olduğu için geri alınacaktır.

Sonunda, geliştiricilerinizin ve paydaşlarınızın bu bilgileri görmek ve çalışmaktan hoşlandıkları şeylerle devam edin.


3

Klasik ders kitaplarında bile kelime gereksiniminin ne anlama geldiğiyle ilgili çok fazla tutarsızlık olduğunu düşünüyorum. Aynı tutarsızlık kullanıcı hikayeleri için de geçerlidir. Farklı organizasyonlar ve ders kitapları bu terimleri farklı şekilde ele almaktadır. Örneğin, Roger Pressman'ın klasik Yazılım Mühendisliği ders kitabında gereksinimlerden nasıl bahsettiği Dean Leffingwell'in Çevik Yazılım Gereksinimleri kitabından oldukça farklıdır. İkisine de saygı duyuyorum ve ikisi de geçerli olabilir.

Gereksinimler, kodladığımız şeyler olabilir; Öte yandan, gereksinimlerin işletme sorununun ne olduğunu ve çözümü belirtmediği söylenebilir. Bence bunun daha farklı olduğunu ve cevabının her şirket ve endüstriye özgü bir spektrumda olduğunu düşünüyorum (tüm yazılım geliştirme BT'de gerçekleşmiyor).

İhtiyaçların ortaya çıkarılmasının analize yol açtığını, bunun tasarıma yol açtığını, bunun da ihtiyaçların detaylandırılmasına ya da tanımlanmasına yol açan, kodlanabilecek bir şeye yol açan mimariye yol açtığını öğrendim . Bunun çeviklikle gittiğine inanmıyorum. Bunların ne zaman gerçekleştiği zamanlaması değişiyor ve bu en önemli fark. Şelale modelinde, toplama ve detaylandırma erken gerçekleşir. Yalın ve azar azar, toplama ve detaylandırma, bir sprintte uygulamaya yaklaştıkça daha fazla detaylandırma ile çeşitli aşamalarda gerçekleşir. Ortaya çıkan tasarım çalışmaları gibi.

Organizasyonumuzda, Leffingwell Destanları, Özellikleri ve Öyküleri modeline, gereklilikler olarak değil, iş dağılımı ve önceliklendirme olarak eğiliyoruz. Gereksinimler farklı bir şeydir. Gereksinimler ayrı olarak yönetilir, çünkü düzenleyici kurumlar için yapmamız gerekir. Yine de bazı takımlar program artışı ve sprint planlaması sırasında kesinlikle kullanıcı hikayeleri içinde gereksinimler geliştiriyorlar.


2

İşlevsel gereksinimler genellikle yazılımınızın çalışıp çalışmadığını tam olarak bilmenizi sağlayan resmi bir özelliktir. Kullanıcı hikayesi genellikle kullanıcı hikayenizden birinin ihtiyacını açıklamak için çok daha resmi bir yoldur. Yazılımın "geçerli" veya "geçersiz" olup olmadığını belirlemek için katı bir özellik belirtmez. Bir kısmını test edebilmenize rağmen, bir kullanıcı hikayesinin gerçek tamamlanması (eğer doğru şekilde yaparsanız), kullanıcınız "evet, sorunumu çöz!" Derken. Çevik manifestoyu unutma:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

"Kullanıcı Hikayesi Uygulandı" adlı kitabında, Mike Cohn özellikle bazı şeylerin kullanıcı hikayesiyle eşleşmediğini ve sadece bunu kullanmak zorunda olmadığınızı söylüyor.

Kendi takımımda aşağıdakileri kullanıyoruz:

  • Kullanıcı hikayesi : Bir tür kullanıcının iş gereksinimi. Burada vurgulanan ihtiyaç ve neden buna ihtiyacı var. Diğer söylediğimiz gibi, burada önemli nasıl yapıldığını belirtmek için ve kullanıcının (gerçek ihtiyacı olan derin gitmek için değil örn: o değil ihtiyaç tablodaki verileri görüntülemek, o kesin değerini görmek için ihtiyaç veri ve o sadece bunu yapmak için tablo ile aşinadır).
  • Hata : Yazılımın normal kullanımı engelleyen beklenmeyen bir davranışı. Genellikle, kullanıcının iş akışını ne kadar etkilediğini belirten bir "Önem" ile (geliştirme önceliğinden bağımsız olarak) gelir.
  • Teknik borç. Kullanımı yazılım kullanımını önlemek yok ama bozar şey bize gelecekte, geliştiriciler. Örnek: bazı sınıfların okunması zor, derleme yavaş, bazı kodlar test edilmemiş, IDE garip uyarılar gösteriyor ...
  • İyileştirme : Yeni senaryolara izin vermeyen, ancak daha güzel bir deneyim yaratan yazılım değişikliği. Örnek: yazı tiplerini değiştirme, daha net hale getirmek için bir formun yeniden tasarlanması, uygulamaya makul varsayılanın eklenmesi vb.

İşlevsel gereksinimler, salatalık testimiz başarılı olsa ve her yazılı kelimeyi uyguladığımız halde, uyguladığımız bir özelliğin bir kullanıcının ihtiyacını çözmediğini anlamamıza izin vermeyecektir. Bir hikaye bir tartışma ve gayrı resmidir. Mesele, uygulama elemanlarının problemli olanı anlamalarını sağlamak. Onlar bir sözleşme aracı değil. "Scrum ama ... " yaparsanız ve hikayeniz sadece yazılımın gereksinimlerini yazmanın eğlenceli bir yoludur, o zaman evet, hiçbir fark yoktur .

Mesele kullanıcı hikayesi değil, mesele paradigmadaki yapılacak işte yaklaşma şeklinizdeki büyük değişmedir. Bir sözleşme yapmıyorsunuz, bazı kullanıcılarınıza problem çözmede yardımcı oluyorsunuz. Kullanıcı hikayelerinizi gerçek bir kullanıcıyla tartışma aracı olarak görmüyorsanız, kullanıcı hikayeleri kullanmıyorsanız, korkak bir gereksinim sözdizimi kullanıyorsunuz demektir .

Buradaki geri kalanlar benim görüşüme göre: kullanıcı hikayesi asla tek taraflı olarak başarılı olamaz. Müşterinizle çalışmak için müşteriye ihtiyacınız var. Su döküntüsü garip bir gereklilik ama gereklilik karmaşası olmaya mahkumdur. Belirli gereksinimleri olan sabit bir teklif sözleşmeniz varsa, yinelemeleri ve kullanıcı hikayesini kullanmayın, bunun anlamı yoktur . Çevik araç setinin geri kalanını kullanın: Otomatik ünite / fonksiyon testi, kod incelemesi, sürekli entegrasyon, yeniden düzenleme vb. Müşteriye bitmemiş haliyle ulaşılabilir olmasını sağlayın, böylece mümkün olduğunca geri bildirimde bulunabilir. Bunu yaparsam arkadaşım, "Kullanıcı hikayesi" ve "Scrum" yapmasanız bile, "Çevik" dükkandan daha çevik olacaktınız.


2

Geçmişteki deneyime bağlı olarak herkesin her şeyi farklı şekilde uygulayacağına ve etiketleyeceğine inanıyorum ve işi yapan o şirket için hangi dilde çalışıyorsa tartışmaya değmez.

Bununla birlikte, IMO, Kullanıcı Hikayesi, Agile'nin "binadaki bir müşteri veya müşterinin hemen kullanılabilir olması" yaklaşımına ilişkin yaklaşımını izler; burada, belgelerin gerekli olmadığı, çünkü detaylar müşterilerin başında ve hazır bir şekilde bulunabilir. gerekli değil. Şimdi bir "Kullanıcı hikayesi" nin "Görevi", bir geliştiricinin kullanıcı hikayelerini sindirilebilir olarak nasıl oluşturacağıdır.

Örnek bir kullanıcı hikayesi şunlar olabilir:

Yönetici kullanıcı olarak, bir ızgarada listelenen istemcilerimin verilerini görüntülemek istiyorum

ve bir "görev" olabilir:

  1. Görüntülenecek verileri listeleyen bir Izgara oluşturun

  2. Seçilen sütunu sıralayacak olan ızgarada Sıralamayı Etkinleştir

Şimdi görevlerin her biri kendi süratinde tahmin edilip tamamlandı.

Yazılım Gereksinimi Şartnamesi, "müşterinin ele geçirmenin zor olduğu" geleneksel "bir perspektiften, bunu planlama / kodlamaya başlamadan hemen önce aldığımızı doğrulayabilmemiz için yazmamız gerekir. müşterilerin kafasında olan ve ortaya çıkıp sonra yazılan ve resmileştirilen, sonra temel alınan ve yönetilen fikirler olacak.

Bu durumda, "işlevsel bir gereksinim", SRS'nin nitritli detayı ve daha büyük bir Fikrin bir parçasıdır. Bu yüzden benim görüşüme göre, bir kullanıcı öyküsü resmi (“Gereklilik”) 'in bir kısmı olarak görülebilir ve bu kullanıcı öyküsünün görevi bir (veya çoğunun) işlevsel gereksinimidir.

Örnek kullanıcı hikayesinde, resmi "Gereksinim", akış şemalarına sahip uzun bir belge olacaktır ve genellikle müşteri odaklı olan daha "Çevik" yaklaşımın aksine, dokümantasyon merkezli olacaktır.

Aradaki fark, resmi "Gereksinim", bazı listelerin gerekli olacağını belirten uygulamanın yönetim bölümünü, bazı rollere dayalı güvenlik, vb. İşlevsellikten bazılarını gösteren 10 sayfalık belgenin satırları boyunca olacak. gereklilikleri "listeleme ızgaraları sıralama yapmalı", "kullanıcı bilgileri bir ızgarada listelenmeli", vs. olacaktır.

ve bugünlerde terimlerin karışık ve karışmış olduğuna inanıyorum.


2
"Müşterinin hazır olması ve bu yüzden detaylandırmamıza gerek kalmaması" nosyonu "Kötü Çevik" dediğim şeyin bir parçası. Agile'nin asıl özü, sprintlerde plan yapıp her şeyi "büyük bir patlamada" yapmanın tersine, işlevselliği aşamalı olarak sunmanızdır. Ancak uzun mesafe boyunca gerçekten çevik olmak için testlere ihtiyacınız var ve testleri yazmak ya da gerçekleştirmek için, çevik arazide kabul edilebilecek kriterler biçiminde gelen şartnamelere ihtiyacınız var. sistem veya proje yerine. "İhtiyaçların" büyük, tozlu eski belgeler olduğu fikri sadece FUD.
Aarona

@Aaronaught Katılıyorum. Özellikle sabit bir uygulama bütçesi bulunan durumlarda kapsamın sınırlı olduğu bir nokta olmalıdır. Bütçe sabittir, ancak ürün tasarımı bilinmiyorsa ve projenin hızlı bir şekilde ilerlemesi gerekiyorsa, benim için çevik işler (ve sprintlerde devam eden bir yazılım ürünü geliştirme faaliyetiyse, yani gerçek bir proje değil) ancak kapsamın kullanımı kısıtlanmış olmalıdır. Bir şelale yaklaşımı ile gidecekseniz, gereksinimlerin içine getirilecek kabul kriterleri (bazı anlamsal değişikliklerle)
br3w5

@Aaronaught - kesinlikle haklısın ... ancak Agile, XP metodolojilerinden kaynaklanıyor ve belirttiğiniz işlem, her iki dünyanın da en iyilerinden ödünç aldığınız bir melezdir. Bir yandan, "dokümantasyon ışığına" ve diğer taraftan "ağır belgeler" var. Dengeyi bulmak, kendi süreçlerini tanımlayan şirket tarafından belirlenir ..
hanzolo

@ssbrewster - Ben de sana katılıyorum. Her metodolojinin, şelalenin ve çevikliğin saf formunda, biri yazılı gerekliliklerin belgelendirilmesini ve onaylanmasını gerektirecek, diğeri geliştirme çabalarının belgelendirilmesi ve doğrulanması durumunda çok az şey gerekecektir.
hanzolo

1
@ssbrewster Bu sadece kapsamı kısıtlamakla ilgili değil, bir hikayenin gerçekte ne zaman yapıldığını söyleyebilmekle ilgili. Bu kararı şirketten bir miktar el sallamadan yapamazsanız, o zaman tutarlı kalitedeki ürünleri veya hız gibi şeyleri doğru şekilde ölçmek için hiçbir şansınız olmaz. Kabul testlerinde belgelendirilmesini kabul kriterlerini tercih ediyoruz - fakat hala yazılıyorlar .
Aaron,
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.