Bu planladığımdan daha uzun olduğu ortaya çıktı (bir yorum olarak başlamıştı), ancak umarım eklenen uzunluk / ayrıntılar yardımcı olur ve bunları haklı bulursunuz.
Çevik CRUD uygulamalarına özgü değildir
Çevik ile ilgili literatürün çoğu, kullanıcının sahne arkasında neler olduğunun oldukça farkında olduğu CRUD tipi iş uygulamalarına karşı önyargılı görünüyor. (Bu iyi çünkü yazılan kodun çoğu muhtemelen bu sınıfa ait.)
Bence bunun nedeni, bu tür sistemlere yönelik bu tür sistemlere yönelik olması değil, bu türden izlenmesi kolay örnekler oluşturmak daha kolay olmasıdır. İzlemesi kolay olmayan bir örnek oluşturursanız, okuyucunuzun çevik kavramlar hakkında bilgi vermesi gerektiğinde örneği anlamaya çalışırken okuyucunun takılma riskini alırsınız.
Kullanıcı Hikayeleri! = Gereksinimler
Bu tür bir uygulama için kullanıcı hikayeleri (gereksinimler) ve geliştirme görevleri arasındaki ilişki çoğunlukla basittir: Kullanıcı hikayesini birkaç göreve ayırın.
Bir kullanıcı hikayesi bir gereklilik ile aynı değildir . Doğru, gereksinimin ne kadar 'yüksek seviyeli' olduğuna bağlı olarak bazı çakışmalar olabilir, ancak genellikle aynı değildir. Eski yöneticilerimin birçoğunun düştüğü aynı tuzağa düştüğünüz izlenimini edindim: kullanıcı hikayelerini sadece "gereksinimler" ile eşanlamlı olarak düşünmek, SVN kullanıcılarının Git'e geçmeye çalıştıklarına benzer, ancak SVN açısından düşünme. (Daha sonra kötü başlangıç varsayımlarından dolayı sorunla karşılaşırlar.)
Gereksinimler ve kullanıcı hikayeleri arasındaki önemli bir fark olan IMHO, gereksinimlerin belirli sistem bileşenlerinin nasıl davranması gerektiğini ayrıntılı olarak belirtmesidir; onlar ediyoruz özellikler girişler, çıkışlar, varsayımlar / pre-şartları arasında, olası istisnalar Onlar ne odaklanmak vb kaldırdı sistem yok.
OTOH, kullanıcı hikayeleri, sistem bileşenleri için ayrıntılı bir davranışsal özellik oluşturmaya çalışmadan son kullanıcı için beklenen sonuca odaklanır. Beklenen kullanıcı deneyimine odaklanırlar .
Eskiden yaptığım şey, bu da ekibimin benimsediği bir uygulamadır, kullanıcı hikayelerini görevlere ayırmaktı. Görevleriniz, istediğiniz / ihtiyaç duyduğunuz kadar belirgin veya belirsiz olabilir, ancak hikayeyi tamamlanmış bir duruma getirmeye yönelik yapılan gerçek çalışmalar için ilerleme göstergeleriniz olması gerekiyordu.
Misal
Yıllar önce, kullanıcıların test senaryolarını kendileri atamaları gerektiğinde, ekipteki herkesin yinelenen çabalardan kaçınmak için hangi TC'lerin üzerinde çalıştıklarının farkında olması için kabaca çalıştığım bir ABD'yi hatırlıyorum; kullanıcı arayüzü (n dahili) bir web uygulamasıydı. Kullanıcı sadece bir düğme gördü, ancak hikaye bazı teknik uygulama ayrıntılarını vb. İçeren birkaç göreve ayrıldı.
Kullanıcı Görünürlüğü
Ancak, kodun çoğunun doğrudan kullanıcı tarafından görülemeyen karmaşık işlemlerle uğraşması gereken başka bir uygulama türü vardır.
Kullanıcıya bir şekilde görünür kılmak mümkün mü?
Bir GPS düşünün. Sıranızı kaçırdığınızda, gerçek rota yeniden hesaplama işlemini görmezsiniz, ancak kullanıcı bazı faydalı geri bildirimler alır (örn. "Yeniden hesaplama ...").
Derleyiciler, uyarılar veya hatalar görüntüleyebilir veya kullanıcıların yeni bir şey eklendiğini görmeleri için GUI'ye yeni ayarlar / seçenekler ekleyebilir. Derleyicilerin kullanıcılarının programcı olacağını düşünüyorum, değil mi? Yeni bir standart için destek görmediler mi?
Yeni bir standardı desteklemek muhtemelen özellik düzeyinde olsa ve kullanıcı hikayelerine ayrılmanız gerekecek olsa da, en azından bazı durumlarda, özellikleri kullanmanız gerektiğinde hikayeleri kullanmaya çalışmadığınızdan emin oldunuz mu? ?
Bir arabadaki görüntü analizi, kullanıcının bir araba kazasında sonuçlanma şansının azaldığını bildirecek şekilde ifade edilebilir. Örneğin:
Kendi kendini süren bir arabada yolcu olarak, daha güvenli seyahat edebilmek için tanınmayan bir nesneye çarparak sıfıra yol açarak aracın kaza yapma olasılığına ihtiyacım var.
ABD, normalde belirtmeniz gereken şeyleri, güvenlik, emniyet vb. Dahil olmak üzere işlevsel ve işlevsel olmayan gereksinimlerin bir kombinasyonunu kullanarak yakalar.
Ancak, sistemle ilgili bir gereklilik daha fazla olabilir; Örneğin:
abcBileşen içindeki işlev , Ayavaş hareket eden nesneleri daha iyi algılamak için görüntü karşılaştırma algoritmasında tolerans eşik değerinin azaltılmalıdır.
Bana göre, bu, yukarıda bahsettiğim kullanıcı hikayesi altında, şu şekilde bir şey başlıklı bir görev olacaktır : İşlevdeki toleransı azaltınA.abc ve daha sonra ilgili diğer ayrıntıları ekleyin.
Sıvı simülasyon sistemi için, eğer mantıklıysa, sistemin gerçekleştirdiği arka plan görevleri hakkında geri bildirim sağlayan bir ilerleme çubuğuna bile sahip olabilirsiniz. (Her zaman kullanıcıyı bir şey hakkında bilgilendirmenin bir yolu vardır, ancak spam yapmaktan kaçınmak isteyebilirsiniz.)
Daha iyi ve / veya daha gerçekçi örnekler bulmak için bahsettiğiniz belirli alanlar hakkında yeterince bilgim yok, ancak burada bir paket varsa, daha az görünür bir şey hakkında kullanıcı geri bildirimi sağlamak için farklı yollar kullanabilirsiniz. sistem yapıyor olabilir, yani görünmez şeyleri biraz daha görünür hale getirmenin yolları olabilir. (Sistemin performansının şimdi ne kadar çabanızdan kaynaklandığını vb. Belgeleyen bir dizi sürüm notu yazarken kaybolsa bile)
Hikayeler ve Görevler Arasındaki İlişki
Burada görevleri ve kullanıcı hikayelerini ilişkilendirmek gerçekten zor olabilir.
Yaklaşımımız kullanıcı hikayelerini talebin ne olduğuna, neden yapıldığına ve ABD'nin "bittiğini" düşünmek için neyin doğru olması gerektiğine odaklanmaktı . Nasıl her zaman ABD'nin dışında kalan ve geliştirici (ler) bırakıldı.
Geliştirici (ler) bu görevlerin bir kümesi haline ABD'de açıklanan sorunu yıkmak istiyorum onlar üzerinde çalışacak.
Bunu, çoğunlukla, son kullanıcı için alabileceğiniz kadar "görünmez" olan arka uç sunucu tarafı programlama yapan biri olarak söylüyorum.
Ne yapmam gerektiğine bağlı olarak, bazen basit bir "yükleniyor ..." animasyonu / gif göstermek için AJAX'ı kullanırım, böylece kullanıcı yanlış bir izlenim olmadan başka bir şeyin tamamlanması için biraz beklemeleri gerektiğini biliyordu. Bazen bu kadar basitti. Bunun için bir görev uygun olacaktır.
Farklı Paradigma, Uygulama ve Deneyim
Bu sorunun üstesinden gelmek için teknikler var mı, yoksa sadece kabul etmek ve en iyisini yapmak zorunda olduğumuz bir şey mi?
Paradigma kaymasını kabul etmenin ötesinde, pratik yapmak ve deneyim kazanmak, muhtemelen söyleyecek çok şey yok. Sık sık insanların süreç boyunca kısayollar almaya çalıştıklarını gördüm. Buna karşı tavsiyede bulunacağım, özellikle de başlarsanız. Daha fazla deneyim kazandıkça, biraz esnekliğe izin verebilirsiniz, ancak kendinizi baltalamaktan kaçının.
Önceki ifadeleriniz göz önüne alındığında, hikayeleri hala "yeniden adlandırılmış gereksinimler" gibi düşünürsünüz, ki bu yanlış bir varsayımdır. Bence bu Çevik ve Çevik olmayan yaklaşımlar arasındaki temel farklarla ilgili daha derin bir sorunun belirtisi .
İkincisi, bence çevikliğin şelaleyle karşılaştırıldığında bir paradigma kayması olduğunu kabul etmelisiniz , yani süreç benzer hedeflere sahipken, çok farklı şekillerde ilerliyorlar. (Bu yardımcı olursa SVN'yi Git'e karşı düşünün.)
Gereksinimler ve kullanıcı hikayeleri arasındaki kavramsal farklar hakkındaki mevcut anlayışınızı geliştirmeye çalışın ve aynı şey olmadığını kabul edin.
Sprint'lerinizden Öğrenme - Retrospektifler
Yeterince vurgulayamadığım şey, her sprint sonunda Scrum Master ve Geliştiriciler arasındaki retrospektiftir . Dürüst / şeffaf bir şekilde "iyi giden" veya "iyi gitmeyen" şeyleri tartıştıkları ve "iyi gitmedi" noktalarını ele almak için bir sonraki sprint için hangi yapılabilir değişikliklerin uygulanacağı yer burası. .
Bu, birbirimizin deneyimlerine uyum sağlamamıza ve hatta öğrenmemize izin verdi ve bunu bilmeden önce, ekibimizin hızının genel tutarlılığı ile ölçülen önemli ölçüde iyileştik.