Hikâyelerde bireysel yetenek dikkate alınmalı mıdır?

Öykü tahminine ilişkin anlayışım, bir hikayenin boyutunu hayali, ortalama bir geliştirici için olduğu gibi, yani hukuktaki "makul seyirci" kavramı gibi tahmin etmesi gerektiğiydi. Yani, yapmak zorunda olduğunuzu varsayarak hikayenin boyutunu tahmin etmemelisiniz .

Bir örnek vermek gerekirse: Bir önceki işimde, kendime en çok güvendiğim Ruby geliştiricisinin olduğu bir ekibin parçasıydım. Takım arkadaşlarım Ruby ile ilgili hikayeleri rutin olarak tahmin ettiğimden çok daha büyük tahmin ediyorlardı, "Peki X'in Ruby'de nasıl çalıştığını bilmiyorum, bu yüzden bu beni yaşlandırır."

Buna karşı iddiam , sürat planlamasının takımın kapasitesinin devreye girdiği noktadan kaynaklanıyor . Bu , "Bu sprint kapasitemiz normalden biraz daha düşük olacaktır, çünkü görevlerin çoğunluğu Ruby tabanlı ve sadece güçlü bir Ruby geliştiricimiz var. Tahmin sırasında bunu hesaba katmak bu yönü iki katına çıkarır.

Yanıtlardaki yetkili referansları takdir ediyorum, ancak basit görüşler de harika olurdu.

Hikaye noktaları göreceli bir tahmindir. Yani puanın iki katı iki kat daha fazla çaba demektir. Göreceli tahminler, beceri seviyesi değişikliklerine daha az maruz kalmaktadır. Soru, 1 puan için ne kadar zaman alacağınız değil, 2 puanın 2 kat daha fazla çaba gerektirmesi. Bireysel üretkenlik seviyesi olduğunu düşündüğünüz için, hikaye puanı yerine ideal günler alırsanız beceri seviyesi daha önemli olabilir .

Göreceli tahminler daha sağlamdır. Buna ek olarak, hikaye noktası değerlendirmesi bir birey tarafından yapılmamalı, kolektif bir ekip çalışmasından kaynaklanmalıdır . Daha az karmaşık hikayeler için genellikle hızlı bir anlaşma vardır. Daha zorlu hikayeler için ekip, üyelerin çoğunun kabul edeceği bir sonuçla gelecek ve bu nedenle ekibin kolektif beceri düzeyini dolaylı olarak dikkate alacaktır.

Son olarak, hikaye değerlendirmesi, takım içindeki görevlerin kesin olarak kararlaştırılmadığı bir anda yapılır. Bu, bireysel beceri düzeyini dikkate almamak için bir argüman daha. Sprint planlama için, ekibin hikaye puanı kapasitesini alacaksınız, bu da gerçek performans rakamlarına göre gelişecek ve böylece ekibinizin küresel beceri seviyesine göre kendini ayarlayacaktır.

Sonuç olarak, tahmin için bireysel yetenek dikkate alınmamalıdır. Ancak, toplu tahminler ve göreceli yaklaşımın sağlamlığı nedeniyle yapılsa bile, çok fazla önemli olmazdı.

Standart cevap, geliştirici başına tahminleri değiştirmemenizdir. Bu, sprint başına emsallerinizden tonlarca puan kazandığınız anlamına gelir ve bu iyidir, çünkü puanlar geliştiricilerin değil takımın hızını ölçer . İş, ekibin zorlu teslimat beklentileri elde etmek için ne kadar üreteceğini tahmin edebilir ve her şey harika.

Ancak bu pratikte her türlü soruna neden olur. O hafta tatildeysen ne olur? İnceleme zamanı geldiğinde ve ortalama maaşın% 110'u için ortalama hikaye puanlarını% 200 ürettiğinizi fark ederseniz ne olur? İş dünyası, takım hızının insanlara bölünmesinin gerçekten doğru bir yaklaşım olduğunu düşünmeye başladığında ne olur? İşletme, emsallerinizden çok daha fazla hata ürettiğinizi fark ettiğinde (daha fazla işlevsellik ürettiğinizi göz ardı ederken) ne olur? İnsanların bu kadar çeşitli ısırıkları olduğunda "ısırık büyüklüğünde" hikayeler nelerdir?

Kariyerim boyunca bulduğum şey, büyük ölçüde önemli olmadığı. Süreç size hizmet etmek için orada, tam tersi değil. Eğer devs aşırı yüklenmişse kuruluşunuzun ölçmesi gerekiyorsa, dev başına hikaye noktaları iyi bir çözümdür. Kuruluşunuzun ekip hızını ölçmesi gerekiyorsa, dev-agnostik hikaye puanları daha net bir resim sağlayacaktır. Yine de her zaman bir yaklaşımdır ve her zaman istismar edilir ve yanlış yorumlanırlar.

Sonunda, onlar adapte gerektiğini uydurulmuş bir süreç için puan yapılmış konum senin çevre.

TL; DR
Her zaman belirli bir hikayeye yalnızca yetkili geliştiricilerin atanacağını varsaymalıyız .

Yetkinlik (veya eksikliği) bir hakaret değildir. Bu, geride kalmayan veya istisnai olarak deneyimli olmayan bir geliştiricinin becerilerinin makul bir ölçüsüdür.

Bu, belirli bir şirketin yaklaşımı meselesi olabilir. Şirketlerin tahminleri belirli geliştiricilere uyarladığını gördüm. Ayrıca, rastgele seçilen üç geliştiricinin göreve neredeyse rastgele bir geliştirici atamadan önce hikaye tahminleri yaptığı bir sistemi uygulayan şirketler gördüm.

Her sistem çalışabilir, her sistem başarısız olabilir. Soru, hangi sistemin daha iyi olduğu değil , şirketin hangi kusurlarla başa çıkabileceği / istediği konusunda o kadar iyidir .

Prensip olarak, dil / çerçeveye hakim olmak için çalışma süresi dahil edilmemelidir. Küçük teğet: İdeal bir dünyada var olmamakla birlikte, projeye veya hikayeye özgü engeller için çalışma süresi dahil edilmelidir.

Bunu yapmak için birçok gerekçe var, ancak bu yaklaşımın genellikle daha iyi bir seçim olduğuna inanıyorum, çünkü iş yükünü tahmin etme niyetine sadık kalıyor . Bu tarafsızlıktan ziyade sadece benim düşüncemle ilgili bir sorun olabilir. Kesinlikle söyleyemem.

Çalışma süresi kişiseldir . Belirli bir teknoloji üzerinde çalışması gereken belirli bir geliştiricinin kapsamı içindedir. Bir kullanıcı hikayesinin iş yükü değerlendirilirken geçerli değildir, çünkü bir kullanıcı hikayesi yalnızca uygulamanın (ve kullandığı teknolojinin) kapsamı içindedir.

Çalışma süresi genellikle birikmez. Çaylakımızın C # hakkında çok az şey bildiğini ve işi yapmadan önce çevreyi anlaması için üç gün daha gerektiğini tahmin edelim. Çalıştığım birçok şirkette olduğu gibi, şimdi de birkaç kullanıcı hikayesini (bireysel olarak) tahmin etmemiz beklenen bir toplantıdayız. Örnek vermek gerekirse, ele alacağımız üç hikayemiz olduğunu varsayalım.

• Her hikayeye üç gün ekliyor muyuz ? Her üç öykünün de benzer bir teknik odağı varsa, bu, çaylakın aslında ikinci ve üçüncü hikaye için fazladan zamana ihtiyaç duymayacağı anlamına gelir. İşi altı gün fazla tahmin ettik.
• Her hikayeye bir gün ekliyor muyuz? Bu da doğru değil. Eğer çaylakı sadece üç hikayeden birine atarsak, ona ihtiyaç duyulan iki günlük çalışma zamanını değiştirdik; ve diğer geliştiricilere iki gereksiz çalışma günü verdik.
• Bir hikayeye üç gün ekliyor muyuz? Bu hikayenin diğer ikisinden önce ele alınacağını nasıl garanti edebiliriz? Ayrı kullanıcı hikayeleri oluşturmanın amacı, hikayelerin genellikle birbirinden bağımsız olarak ele alınabilmesidir. Bizim tahminin doğruluğu şimdi bizim çaylak işi varsayımına, hem menteşeleri artı o bu görevleri atanan sırayla (Bu konularda, örneğin kombine iş yükü tek sürat aşan varsa).

Not :
Çalışma süresinin biriktiği başka durumlar da vardır , örneğin, üç hikaye çılgınca farklı konularda ise ve farklı beceriler gerektiriyorsa.
Ancak durumun böyle olup olmadığını öğrenmek için, aynı anda üç hikayeye de bakmamız gerekir, bu da yavaş yavaş bağımsız kullanıcı hikayelerine sahip olma ilkesini ihlal etmeye başlar . Bu tahminleri, muhtemelen farklı geliştiricilerle birlikte ayrı toplantılarda ele alsaydık; hikayeler arasındaki örtüşmeyi doğru bir şekilde ölçemeyiz.

Çünkü hangi hikayelerin gerçekte sonuçlanacağını garanti edemediğimiz için (müşteri büyük bir tahminde bulunmayı reddedebilir) ve onlara atanacak, belirli bir geliştiricinin belirli bir hikayeye atanmasını hesaba katmaya çalışmak boşuna olacaktır. Sadece su çamurlanır.

Bunun yerine, çaylakın zaten hızlandırıldığını varsayarak iş yükünü tahmin etmeliyiz (ve bu nedenle iş arkadaşlarına eşit bir geliştirici).
Böyle bir tahmin geliştirici-agnostiktir ve bu nedenle tahminin doğruluğu, hangi geliştiricinin hikayeye atandığına bağlı olarak dalgalanmaz.

Not
Hala belirli bir geliştiricinin belirli bir hikayeyle başa çıkmadan önce çalışmak için fazladan zamana ihtiyacı olabileceğini kabul etmek önemlidir. Bu hala çok ilgili bir konudur. Ancak bu düşünce hikayeye eklenmemeli , daha ziyade bu geliştiricinin bu hikayeye atanması gerekir.

Ancak, başladığım zaman, bu durum şirketten şirkete değişebilir. Bazı şirketler, çalışma süresiyle ilgili o kadar karmaşık olmayabilir (örneğin, geliştiricinin teknolojiyi kaçınılmaz olarak kullanmayı öğrenmesi gerekecekse). Diğerleri, bir müşteriye faturalandırmayı etkilediğinden, bu tahminlerin doğruluğuna büyük ölçüde güvenebilir.

Sonunda, zehirini seçmek meselesi. Bu yaklaşımların hiçbirinin diğerlerinden daha doğru olduğu garanti edilmez.

Bu karmaşık bir konudur ve konuyla ilgili sık sık tartışmalar yapılmaktadır. Bu konuda "kanonik" görüş kavramını sevmiyorum: değeri olan çeşitli görüşler var. Ancak yaklaşıma rehberlik etmesi gereken destekleyici değerler, ilkeler ve uygulamalar vardır.

Aşağıdakiler, 10 yılı aşkın bir süredir scrum ekipleriyle çalışan kendi görüşlerime dayanıyor. Ama bu sadece benim fikrim.

1. Öngörme yöntemi olarak Öykü Noktaları Öykü noktalarının asıl amacı, bir takımın belirli bir süre boyunca neler yapabileceğini tahmin etmek amacıyla çabayı tahmin etmek için hızlı bir yöntem bulmaktı. Bazı "aydınlatma aygıtları" puanların yalnızca uzun vadeli kapsamı (örneğin bir sürüm üzerinden) tahmin etmek için kullanıldığını ve sprint düzeyinde kapasiteyi belirlemek için kullanıldığını belirtir. Ek olarak, konsept, ekiplerin tarihsel değerlere dayalı olarak "göreceli boyutlandırma" uyguluyor olmalarıdır (Çaba X, 3 puan olan Çaba B'ye benzer). Bu, tahmin sürecini hızlandırır, böylece ekipler gelecekteki çalışmaları ayrıntılı çalışma paketlerine ayırmak ve tüm görevlere saat uygulamak zorunda kalmazlar. Yüksek performanslı ekipler, tüm teknik çalışanları benzer beceri düzeylerine sahip çok yetkin üyelere dönüştürmeye çalışır. (Bu kavram 4. maddede daha fazla incelenecektir.) Bu elde edildiğinde, bireysel beceri seviyesi gerçekten boyutlandırmada bir değişken değildir. AMA: Bu hedefe ulaşmak genellikle uzun zaman alır ve birlikte çaba gösterir. Peki ... oraya varmadan önce ne yapacağız?

2. Çalışma saatleri sprint kapasitesini belirler: Noktaların uzun vadeli tahmin için kullanıldığını belirten aynı "armatürlere" göre, Görev Saatlerinin puan yerine sprint kapasitesini belirlemek için kullanılmasını önermektedir. Bence bu iyi, ama diyebilirim ki koç ekipleri "Yüksek Performans" a yardım ettiğimde, seviyeli becerilerinin ortalaması sadece Hikaye Puanlarını kullanarak bir sprint'te neler tamamlayabileceklerini belirleyebilecekleri ortalamanın üzerinde. . Yine, bu, çabaladığımız bir amaç olabilir, ancak yeni takımlar buna hazır değildir. Bu nedenle, tek bir sprint'te 12 görev saati çaba gösteren 2 puanlı ve 25 saatlik çaba ile başka bir sprint bulabilirsiniz. Ee ne yapıyorsun? "Agile-purists" dediğim bazı insanlar Hikaye büyüklüğünün (puan olarak) süre için agnostik olması gerektiğini söyleyeceklerdir. Diğerleri aynı fikirde değil. 3. madde üzerindeki mantığı okuyun ve ne düşündüğünüzü görün.

3. Fikir birliği ile Hikaye Gösterimi: Hacim, Bilinmeyenler, Karmaşıklık, Bilgi Uygulama

Bu yüzden ekipler bir iş parçasına bakarlar ve Çaba Düzeyi için vekalet edecek noktalar üzerinde anlaşmaya varmaları gerekir. Sağ? Tüm becerilerin eşit olduğunu varsayarsak, fikir birliğine ulaşmak kolaydır. Ancak çoğu zaman takımların Java guru, diğeri Java'da çok iyi olmayan bir adam vardır (belki de bir C # veya .Net veya Cobol kişisiydi ve Java öğreniyor). Yani Bob için X görevi çok basit. Jane için daha zor.

Çevik ekipler toplu kod sahipliğini ve büyüyen / genişleten uzmanlığı teşvik etmeye çalışırlar. Bu yüzden, genellikle uzmanlıklarına göre insanlara hikayeler atamıyoruz: ekiplerin toplu olarak hikayeler üzerinde çalışmasını ve birlikte öğrenmesini tercih ediyoruz. Bu, "hızlandırmak için yavaşla" kavramıyla uyumludur: Jane ile Java deneyimi vermek için zaman ayırırsak, bu ilk başta bizi yavaşlatabilir, daha sonra daha yetkin Java geliştiricilerine sahip olacağız. Aslında, yalnızca bir Java uzmanımız varsa ve herkes kendi uzmanlık alanlarında çalışıyorsa, birden fazla potansiyel "başarısızlık noktası" olan bir durum yaratıyoruz. Çalışmanın% 90'ı Java, ancak Bob (Java uzmanımız) hasta veya tatilde olduğunda sprint'te ne olur? Becerileri genişleterek, potansiyel darboğazları ortadan kaldırır ve riski azaltırız. Bunu göz önünde bulundurarak: Takım bir hikayeye baktığında, boyutlandırma sırasında akıllarında birkaç kavram olmalıdır. Bunu hatırlamak için VUCK kısaltmasını düşünebilirsiniz.

Cilt: Bazı çabalar oldukça basittir, ancak çok sayıda tekrarlanan görev gerektirir. (Basit olduğu için 1 puan olduğunu söyleyen 50+ tabloyu kopyalamak ve yeniden biçimlendirmek zorunda kalan bir adamım vardı. Ancak yansıma üzerine ekip kolay olsa da zaman alıcı olduğunu ve büyük miktarda tablo olduğunu fark etti. iş hacmi nedeniyle puanları yeniden ayarlamak zorunda kaldık)

Bilinmeyenler: Bazen ne yapacağımızı bildiğimizi DÜŞÜNÜYORUZ, ancak bazı bilinmeyenleri de belirliyoruz - bunlar RİSKLERİ temsil ediyor . Bu da, çözmemiz, yeniden tasarlamamız veya farklı bir çözüm denememiz gereken beklenmedik sorunlarla karşılaşabileceğimiz anlamına gelir.

Karmaşıklık: Bu oldukça açıktır. Bazı çözümler teknik olarak karmaşıktır. Ne yapacağımızı tam olarak biliyoruz, ancak teknik uzmanlık gerektiriyor. Karmaşıklık da bir miktar risk içeriyor, değil mi? Dolayısıyla, hepimiz eşit becerilere sahip olsak bile, teknik karmaşıklık, öngörülemeyen zorluklarla karşılaşabileceğimizi ima eder. Yani bu hikayeyi daha büyük yapabiliriz.

Bilgi: GERÇEKTEN ne çözdüğümüzü biliyor muyuz? Bazen müşteriler istedikleri çözüm konusunda tamamen net değildirler ve biz de biraz deneme yapıyoruz. Ya da belki de hiç kimse bu çözümü uygulamadı (daha önce hiç kullanılmamış yeni teknoloji) ve bu yüzden ne bilmediğimizi bilmiyoruz.

Kanımca, bu düşüncelerin her biri aslında uzun bir süre için bir vekil. Kolay hikaye, çok fazla hacim? Daha uzun sürecek ya da hikayeyi bölmemiz gerekecek. Bilinmeyenler? Risk, araştırma, deneme ekledi, daha uzun sürebilir veya hikayeyi bölmeliyiz. Kompleks? Daha fazla risk almak, hataları düzeltmek, yeniden tasarlamak vb. Gerekli bilgiye sahip olup olmadığımızı bilmiyor musunuz? Ek riskimiz var, denememiz gerekebilir, bu yüzden daha uzun sürebilir ...

Bunun nereye gittiğini görüyor musunuz? Öykü noktaları kavramı bizi tahmin ederken süreyi düşünmekten caydırırken, diğer yandan 4 saat içinde tamamlayabileceğimiz 1 puanlık bir hikayeye ve basit ama alacak başka bir 1 puanlık hikayeye sahip olmak mantıksız olurdu. 2 hafta.

4. Yüksek performans gösteren takımlar Siloları ve Darboğazları ortadan kaldırır: Takımlar tüm üyeleri düzleştirmeye çalıştıklarından, bazen daha az deneyimli üyeler yeni zorluklarla karşılaşırlar veya takım olarak gelişmek için bilgiyi paylaşmak için kodları eşleştirirler. Daha önce de belirtildiği gibi, ekip gerçek Yüksek Performans seviyelerine ulaşacaksa bu bir zorunluluktur.

Eğer Jane bu Java çabasını üstlenmeye gönüllü olursa ve bu çaba Bob'un yapması için aynı çabayı 2x veya 3x yaparsa, ne yaparsınız? Zaman içinde, ekiplerim, emek üzerinde çalışan insanlar için çaba düzeyine (LOE) / VUCK'a dayalı öyküleri boyutlandırmaya karar verdiler. Jane için kolay olmayacak ve tamamlanması bir hafta sürecek olan Guru ekibi Bob için "bu 1" demek hiç mantıklı değil, ayrıca Bob'un çift kodlama ve kod incelemesi için biraz zamana ihtiyacı var. Bu nedenle, gerçek LOE'yi yansıtmak için bu noktaları artırdık. Bir dahaki sefere benzer bir hikaye geldiğinde, Jane için 8 olan şey daha önce 5 oldu. Sonunda, herkes kolay bir 3 olduğunu kabul etti. Bu noktada, takım olarak büyüdüğümüzü biliyorduk.

TLDR

Hayır, ama belki de düşündüğünüz nedenden dolayı değil.

Uzun versiyon

Diğer cevapların birçoğu, Öykü Puanlarının tamamen diğer çalışmalara göre hesaplanması gerektiğini açıkladı. Bu kesinlikle doğrudur. Hikaye Puanları , tamamlanması için gereken süreden ziyade iş miktarını tahmin ettiğinden, bireye dayalı Hikaye Puanları vermek çok az mantıklıdır.

Örneğin (favorilerimden biri), "Delik aç" görevini düşünün. Bunu, kaldırılacak olan dünya miktarına veya dünyayı kaldırmanız için geçen süreye göre tahmin edebilirsiniz. Arkadaşım saatte 3 metre hızda bir bütün kazıyor, büyük bir mekanik kazıcı var, böylece 100'ü yönetebiliyorum! Tek sabit toprak miktarıdır - bu nedenle tahmin birimimiz olarak kullandığımız şey budur.

Ancak, geliştiricinin kullanıcı hikayelerini tahmin etmek için indirim yapmasının ikinci (ve bence daha önemli) bir nedeni, hemen hemen her kullanıcı hikayesinin birden fazla kişi tarafından üzerinde çalışılmasıdır.

Kullanıcı arayüzünü yapmak için bir mimarınız, geliştiriciniz, test kullanıcısı, belki de ikinci bir geliştiriciniz olabilir. Kullanıcı hikayeniz Bitti olarak işaretlenmeden önce (ideal olarak dağıtıldı ve yapıldı) birçok farklı kişi üzerinde çalışmış olacak. Aniden, söz konusu geliştiriciye dayanarak tahmin etme fikri çok az mantıklıdır, takımdan ne kadar çaba harcanacağını doğru bir şekilde tahmin etmenin tek yolu, takımların hızını ölçmek ve takımın tamamlayacağı işi tahmin etmektir.

Takımda "Ben" ve çevik planlamada kesinlikle ben yok!