Bir Scrum ekibi Sprint taahhüdünü ne sıklıkta yerine getirmelidir? [kapalı]

10

Bağlılık bir vaattir ve hepimize vaatlerinizi yerine getirmeniz gerektiği öğretilmiştir. Ancak her Sprint için taahhüdü korumak gerçekçi midir? Bazen insanlar hastalanır, bazen teknik yaklaşımın yanlış olduğu kanıtlanır ve bazen ürün sahibiyle veya özelliğin orijinal olarak düşünülenden çok farklı olması gerektiğini anladığınız kullanıcılarla daha fazla tartışma sırasında her şeyi yeniden düşünmeniz gerekir.

Resmi Scrum Rehberinin artık muhtemelen bu sorunları ele almak için taahhüt yerine "tahmin" kelimesini kullandığını biliyorum.

Dolayısıyla sorum, kuruluşlarınızdaki ekiplerin ne sıklıkta bağlılıklarını sürdürdükleri ve bu yaklaşımı beğenip beğenmediğinizi veya değiştirmek isteyip istemediğinizdir.

Teşekkür ederim.

scrum

— Eugene
kaynak

meta.programmers.stackexchange.com/questions/6483/…

— gnat

1

Sıklıkla merak ettiğim bir soru ve iki iyi cevap

— matt freake

1

Her zaman taahhüdünüzü yerine getirirseniz, muhtemelen yeterince agresif olmuyorsunuzdur . Scrum'ın amacının bir kısmı, herkesin belirli bir görevin Gerçek Dünyada ne kadar süreceğini tahmin etme becerilerini geliştirmek olduğundan, zaman geçtikçe doğruluğunuz umarız iyileşir.

— keshlam

1

@keshlam bu mutlaka doğru değildir. Çevik harekette, potansiyel olarak zehirli doğasını tanıyarak geleneksel tahminleri geçmeye çalışan bir düşünce okulu var.

— Stefan Billiet

1

Verildi, @StefanBilliet ... ama Scrum, dış dünya söz konusu olduğunda tahminleri aynı anda vurgulamaktan vazgeçerken, bir ekibin ne zaman ne kadar fazla iş yapabileceklerine dair içsel algısını geliştiriyor.

— keshlam

21

Bu, bir takımın ne sıklıkta "vaatlerini yerine getirmesi" gerektiği sorusu değildir.
Bu daha çok, bir takımın taahhütlerini yerine getirmede neden sorun yaşayacağını araştırmakla ilgilidir.

Eğer tanrısal bir müdahale varsa, bu gerçekten önemli değil. Ancak sık sık çizim tahtasına geri dönmeniz gerektiğini fark ederseniz, çünkü teknik yaklaşımınız yanlıştır veya PO'nun fikrini değiştirmeye devam ettiğini veya hikayelerin bir sprint başlangıcında yeterince net olmadığını varsa, nedenini araştırmalıyız.

Sprint taahhüdünü yerine getirmemek bir semptomdur; temel sebeple ilgilenmeniz gerekir.

— Stefan Billiet
kaynak

Peki, vakaların% 99.99'unda taahhüdü yerine getirmeye çalışmalıyız? Taahhüdün yerine getirileceğine dair gerekli güvence düzeyi ise, genellikle üretebileceğimiz ortalama işin sadece yarısını taahhüt ederiz. Yani% 99.99 değil sanırım. Öyleyse nedir? 50-70%? % 80-90?

— Eugene

@Eugene Neden bir numaraya ihtiyacınız var ve kimin güvence altına alınması gerekiyor? Organizasyonunuzda sprint hedeflerinize

— ulaşmazsanız

Bir şey değil. Aslında benim organizasyonumda hiç kimse bir taahhüdün yerine getirilip getirilmediğini umursamıyor. Bunu değiştirmeye çalışıyorum, çünkü şu anda hatalar düzeltiliyor ve testler yazılıyor, çünkü onlar için zaman yok. Ekiplere, taahhütlerini düzenli olarak yerine getirebilmeleri için daha az taahhütte bulunmalarını tavsiye etmek istiyorum. Ama ne kadar az? Taahhüdün yerine getirilmesi bir ölüm kalım meselesi ise, dışsal olarak hiç kimsenin dayanmadığı bir tahmin olsa bile kesinlikle daha azını taahhüt edersiniz.

— Eugene

2

Sesleriyle, daha temel problemleriniz var. 'Tamamlanmış' olan hikaye sayısındaki performansı ölçebilmeniz için önce bir takımın 'tamamlandı' anlayışına sahip olmanız gerekir

— Michael Shaw

13

Her şey yolundaysa, ekiplerin scrum taahhütlerini yerine getirmeleri normal olacaktır. Gün boyu hastalık, çocuk bakımı acil durumları, vb. Gibi küçük ölçekli, makul ve olası aksaklıklar ile başa çıkmak için yeterince serin olmalılar. O zaman benim görüşüme göre sprint fazla taahhüt ve takım olarak uzun vadeli iyi için çok sıcak çalışıyor.

Sprintler sürekli olarak teslim edilemiyorsa, scrum 'problemleri' görünür kılmak için sözünü yerine getirdi. Sorunlar, uygun şekilde tanımlanmış görevlere sahip olmamayı, ekipte yetersiz tecrübeyi veya sürekli olarak fazla teslim etmeye teşebbüs eden bir yönetim kültürünü ve böylece sürekli olarak yetersiz kalmayı içerebilir.

Her iki durumda da, çözüm geliştiricileri daha zor kırmak yerine, temel nedeni tanımlamak ve düzeltmektir.

Taahhütlerini yerine getirmeye her zaman 'yakın' olan takımlar daha ciddi bir şekilde başarısız olmaktadır. Yeterli test yapmadığından emin olabilirsiniz.

— Michael Shaw
kaynak

4

Şahsen inanıyorum ki kuruluştaki hiç kimse taahhüdünüzü yerine getirmekle ilgilenmezse, bir taahhütten bahsetmemenizdir. Bir anlaşma yapmak ve bir taahhüt oluşturmak için iki ortağa ihtiyacınız var.

Sprint taahhüdü, tüm "normal varyasyonları" dikkate alarak saklayabilmeniz gereken bir şeydir. Temel varyasyon ile ne demek istediğim hakkında daha fazla bilgi edinmek istiyorsanız , çevik planlamanın temelleri hakkındaki blog yayınımı okuyabilirsiniz . Ve Stefan belirtildiği gibi , taahhüdünüzü karşılamayan bir belirtisi değildir hastalıktır.

Her süratten sonra, bu süratin gerçek hızını incelemek ve "ortalama hızınızı" buna ( yukarıda belirtilen yayında açıklandığı gibi) uyarlamak için bir anınız olur . Hızınız azalmaya devam ederse, süratten sonra koşun, bunun asıl nedenini tespit etmenize yardımcı olabilecek kalıpları görmeye başlarsınız. Bu çok planlanmamış bir iş olabilir (örneğin, küçük acil görevler geliyor, üzerinde çalıştığınız koddaki hatalar, sprint sırasında kabul kriterlerinde değişiklikler, ...). Tüm bu verilerin, muhtemelen hangi kalıpların orada olduğunu bulmasına yardımcı olmak için scrum master tarafından izlenmesi gerekir. Bu, ekibin retrospektif sırasında eylemler geliştirmesine yardımcı olacaktır.

— talboomerik
kaynak

2

Benim bakış açım, takımların bir taahhütte bulunmamaları. Muhtemelen, tahmin bile etmiyorlar. Tahmin, sprint planlanmadan önce yapılır - tahmin, ortalama olarak hızlarını karşılayacaklarıdır. Bu, bazen hızlarından birkaç puan daha, bazen biraz daha az yapacakları anlamına gelir.

Eğer düzenli olarak hızınızdan daha azını yapıyorsanız, hızınız bunu yansıtmak için düşer. Böylece tahmin de düşer. Tarihsel hızınızın sprint'ten sonra sprint yapabileceğinizden daha fazla hikaye çekmeye devam ederseniz, bu bir yürütme başarısızlığı değil, planlamada bir başarısızlıktır. Hızınızı biliyorsunuz, bu yüzden tarihin başarabileceğinizden daha fazla puan getirmemelisiniz.

Scrum kullandığım üç kuruluşun özel sorunuzu yanıtlamak için yalnızca bir tanesi zaman içinde "taahhüdü özledim" metriklerini izledi. Bu şirket için, takımlar tahminlerini genellikle% 85 civarında buldu.

— Bryan Oakley
kaynak

Katılıyorum. Her sprint planlamasının sonunda menajerin sprint için tüm hikayeleri tamamlama taahhüdünü talep ettiği bir ekipteydim. "Evet" deme alışkanlığına düştüm ve çevik olmaya devam ettim. Muhtemelen onu bu şekilde daha iyi hissettirdiğini düşündüm.

— Rob

1

@RobY: Bence olgun takımlarda taahhüt için yer var. Deneyimlerime göre, çevik takımların çoğu özellikle olgun değil ve taahhüt isteyen herhangi bir PO iyi bir PO değil. Hızıyla oldukça sağlam bir takımdaydım ve gerektiğinde gerçek taahhütlerde bulunmaktan oldukça rahat olduk, ama bulunduğum diğer takımlar o kadar olgun değildi.

— Bryan Oakley

Biraz yanak oluyordum. Kabul ediyorum, genellikle taahhüt edebileceğiniz temel bir hikaye seti var, ancak hıza yaklaştıkça biraz daha az kesin. Hız bir ortalama olduğu için, tanım gereği bazen üstünüzde bazen de altında olursunuz. BTW aynı müdür 2x ile bizi yüklemek veya hız her zaman 3x ve sonra bir taahhüt talep edeceğini ... yani ...;) (çoğunlukla I) gerçekten iyi devletlere bunu düşünmek ilk paragrafında, tepki olarak geldi

— Rob

2

Eğer taahhüdünüzü yerine getirmiyorsanız, hızınızı azaltmalısınız. Her zaman buluşuyorsanız, bazen başarısız olana kadar artmalısınız.

Sorun ne kadar başarısız olursunuz? Her zaman yakın olmalı. Ya biraz gevşeklikle ya da sadece başarısızlıkla sonuçlanırsınız. Bu, herhangi bir disiplin, çalışma süreleri, ağırlık kaldırma vb. İçin sağlıklı bir hedeftir .

Daha da önemlisi, hızınızdaki uzun vadeli eğilim. Her hafta hızınıza 15 hikaye puanı eklerseniz, ancak bir hafta öncesine göre sadece 10 puan kazanırsanız, bu gerçekten kötü bir şey mi? Bazı yerlerde bu “esnek hedefleri” düşünüyorlar.

— Kızak
kaynak

Bu cevaba gerçekten katılmıyorum. İnsan doğası teslim etmeye çalışmaktır ve alt dolarına bahse girebilirsiniz, takımların hikayeyi düşürmek yerine 'test etmeyi' keser. Her zaman çizgiye bu kadar yakınsanız, yeterince iyi test yapmayacaksınız ve ısırmaya geri dönecektir.

— Michael Shaw

@ Disiplin, profesyonel gurur ve sağlam bir "tamamlanma tanımı " gereken yerdir . Bunlar bok göndermenizi engellemelidir. Ayrıca, köşeleri keserseniz, bir şeyleri saymıyor olmalısınız.

— Kızak

Bu geliştirici kısmında scrum'un test kısmında olduğundan çok daha net. Bilinen hiçbir kusura sahip olamazsınız çünkü test cihazı temel işlevselliği test etmeye odaklanmıştı ve hatayı ortaya çıkaracak 'rastgele bir olay' için zaman yoktu.

— Michael Shaw

2

@Ptolemy: Testler hikayenin bir parçası olduğu için ekipler teknik olarak "testi kesemez". Eğer keserlerse, kodlamanın bir kısmını kesmekten farklı değildir. Kodlanmış özelliğin bir bölümünü atlarsanız, bir hikaye mi dolduruyorsunuz? Aynı şekilde, eğer testi keserseniz, hikayeyi tamamlamıyorsunuzdur.

— Bryan Oakley

Scrum'ı hiç kullanmadım ama taahhütlerde bulundum ve işlerin yapılıp yapılmadığına karar verdim. Yapılan tanımın tamamen objektif olması güzel olurdu , yani grubun tanımı yerine getirme taahhüdünü yerine getirmek için yapılması gerekip gerekmediği ışığında yorumlaması için yer yoktur. Doğal dil olduğu gibi, bu gerçekçi görünmüyor. Bağlılık konusunda oldukça rahat ve nesnel bir tanımlamaya oldukça yakınsanız, bu bir sorun olmaz. Ptolemy "insan doğası teslim etmeye çalışmaktır" derken, şemamda "insanlar taahhüt konusunda yeterince rahat değiller" anlamına gelir.

— Steve Jessop