Scrum tahminlerine ilişkin pazarlık ve dayak girişimleri sürecin meşru parçaları mıdır?

Scrum toplantılarında, geliştiricilerin genellikle hikayeler hakkında gerçekçi tahminler verdiğini fark ettim. Bununla birlikte, oldukça basit hikayeler bile yapılandırma, üçüncü taraf bileşenleri kurma, test etme ve son oluşturma işlemleri için çok çaba gerektirir ve sistem oldukça teknik bir borç biriktirir, bu nedenle tahminler genellikle ürün sahibi veya yönetimi için çok yüksek görünür.

PO sık sık bu tür tahminleri yenmeye çalışır: "Ne, bu hikaye için 13 hikaye puanı [4 gün] istiyorsun, bu olamaz! Bunu yönetime açıklayamam, birisi bunu kodlayabilmelidir 3 SP [4 saat içinde] ile! " Sonuç olarak, geliştiriciler kollarını bükerek 5 veya 8 hikaye puanı [1.5 ila 2 gün] tahmininde bulunurlar (Scrum tahminleri sadece tahminler olarak değil, taahhütler olarak da alınır).

Tabii ki, beklentileri azaltmak için herhangi bir plan olmaksızın (esas olarak test ve kalite), bu sprintler sıklıkla başarısız olur. Geliştiricilerin tahmini dürüst, gerçekçi bir tahmin ve tahminleri alt etmek, yapılacak gerçek işi yenmez.

Birisi şöyle diyebilir: "İmkansız bir taahhütte bulunmamalısınız, çünkü birileri sizi yapmaya zorlar!" Ama bence, bir geliştiricinin işi, pazarlık ya da baskıya karşı durmak değil, yazılım tasarımı ve kodlamadır! Tüm ticaretlerden krikolar olabilir, tipik olarak doğrudan dış müşterilerle uğraşanlar olabilir, ancak bu ofis geliştiricilerinin çoğunluğu değildir!

Bana göre, bu uygulama sadece programcıların gerizekalı görünmesini sağlar, sürekli sprint hatalarına neden olur ve gerçekçi tahminleri önler ve gerçek iyileştirmeleri arar.

Scrum kılavuzları bu konu hakkında ne söylüyor ya da bir şey söylüyorlar mı?

EDIT: zamanları hikaye puanları ile değiştirildi. Görev ayrıntısı planlaması değil Planlama Poker ve hikaye puanları ile ilk tahmin aşamasından bahsediyordum. Günleri / saatleri oraya koydum, çünkü bazen bu gibi tipik bir diyalogdu, nokta yerine zamanla da. Herhangi bir karışıklık için özür dilerim! Hikaye noktası örnekleri, zaman örneklerinden daha uzun zaman periyotlarını temsil eder.

DÜZENLEME 2 Şu anda özel bir scrum ustası yoktur ve tahmin toplantıları söz konusu olduğunda PO bu rolü üstlenir. Bu yüzden, bu uygunsuz pazarlığı daha da kötüleştiren rol çatışması, çünkü tarafsız veya geliştirici scrum ustası yerine otorite olarak görünüyor. Belki de bu, hiçbiri mevcut olmadığı sürece onu "usta" yerine taraflı bir katılımcı olarak alarak düzeltilebilir.

Açıkladığınız durum zehirlidir. Bu tür bir pazarlık, gerçekliği ve ekibin uzmanlığını göz ardı eder, ekipten ve kuruluştan gelen bilgileri bilinçli olarak gizler ve ekibin zaman içinde gelişmesini engeller.

Eğer şehre istiyorsanız http://www.scrumguides.org/scrum-guide.html ben vurgulamak istiyorum bir otorite olarak:

Sadece Geliştirme Ekibi yaklaşmakta olan Sprint üzerinden neler başarabileceğini değerlendirebilir.

ve

Scrum şeffaflığa dayanır. Değeri optimize etme ve riski kontrol etme kararları, eserlerin algılanan durumuna göre verilir. Şeffaflığın tamamlandığı ölçüde, bu kararların sağlam bir temeli vardır. Artefaktların tamamen şeffaf olmadığı ölçüde, bu kararlar kusurlu olabilir, değer azalabilir ve risk artabilir.

Ürün sahibiniz bir görevin sadece 4 saat içinde mümkün olmasını isteyebilir. Bu makul bir hedef bile olabilir. Sağlıklı bir tepki, ekibin tahminini kabul etmek, doğru olup olmadığını ölçmek ve "bu tür bir işi daha hızlı tamamlamak için neyi değiştirmek zorunda kalacağız?" Göreve dahil olan işin kapsamının müzakere edilmesi de makul olabilir ve geliştiricilerin ve ürün sahibinin bu işi nasıl anladıklarında önemli bir farkı vurgulayabilir. Ekibin tahminlerini yeni bilgi olmadan değiştirmesini istemek, sadece yanlış tahminler yapılmasını sağlar.

Geliştirme ekibinin bu modeli değiştirmek için kullanabileceği birçok strateji vardır, ancak "Bunu yönetime açıklayamıyorum" şeklinde bir örnek verdiğinizde çok gerginim. Ürün sahibinizin yönetim güvenine sahip olmadığı anlaşılıyor (ürettikleri yanlış tahminler muhtemelen yardımcı olmuyor) ve mevcut süreç hataları hakkında şeffaf olmaya istekli olmayabilir.

Kanımca, SCRUM'un en büyük başarılarından biri, burada belirtilen pazarlık sorunlarından kaçınmanın açık niyetiyle, hikaye noktalarının geliştirilmesidir. Hikaye noktalarının tüm amacı, bir görev ile kaç gün süreceği arasında doğrudan bir bağlantıdan kaçınmaktır. Bunun yerine, bu iki kavram hız fikri ile bağlantılıdır.

Eğer bir geliştirici olsaydım ve 13 puanlık bir hikayeyi 8 puanlık bir hikayeye çağırmak için kol bükülmüş olsaydım, mutlu olurdum. Etkilediği tahmin yetenekleri. Sadece tüm zorluklarımı eşleştireceğim. Sonunda, takımın hızı, yönetimin hikaye puanlarını "boşaltma" isteğiyle eşleştirmek için haftada hikaye puanı açısından azalacaktır. Yönetime teslim edilen rakamlar eşleşmelidir: "Kilometre taşını başarmak için gereken öykü iş noktalarının sayısını başarıyla% 50 azalttık. Bununla birlikte, hızda buna karşılık gelen bir düşüşü% 50 oranında gördük, bu yüzden net etki biz tam da ne kadar sürede başaracağımızı tam olarak gerçekleştirecekti. " Üst yönetimin arzulu düşüncesiyle mücadele etmek için hız kavramı vardır.

Şimdi bakmaya değer iki uç var. Biri yönetimin tamamen başarısız olması, diğeri ise aslında yönetimin ilgilenmesi için çok geçerli bir kaygıdır. İlk durum, geliştiricilere "yeterince üretken olmamanız. Daha fazla hikaye puanı üretmeniz gerekiyor" söylendiğinde SCRUM için ölüm cezasıdır. Bu olursa, aslında SCRUM kullanmıyorsunuz, SCRUM'u yuvadan dışarı atmış ve bir sonrakine geri dönen ana kuş tarafından beslenmeye çalışan bir Cookoo'sunuz.

Şimdi yönetimin bilmesi gereken bir durum varbunun gibi kol bükümü yapabilir. Müşterinin istekli olması halinde, "Hızınız haftada 20 puan ise bu görevi tamamlamak için 50 hikaye puanı alamıyorum. 30 hikaye noktasında başarmanızı istiyorum" demesi makul olmalıdır. kapsamlarını% 40 oranında azaltmak için bu hikayelerin içeriğini yeniden tartışmak. SCRUM, geliştiricilerin istediklerini yapmaları için ücretsiz bir yemek bileti değildir, onlara yardımcı olmak için bir iletişim aracıdır ve yönetim, yapılması gerekenler hakkında açıkça konuşur. Ayrıca, bir müşterinin geliştiriciye sıkıştırması ve işin zamanında tamamlanmayacağına dair doğuştan gelen riski kabul etmek istiyorsa "görevi 30 noktada yap" demesi de geçerlidir. Son başvuru tarihi kaçırıldığında, geliştiriciler " ve sonra gerçekten yapılan her şeyi kabul edin. Bir ekibin verimliliğini ölçmenin daha iyi yolları olduğunu düşünüyorum, ancak bunun işe yarayan bir süreç olduğunu itiraf etmeliyim. ve sonra gerçekten yapılan her şeyi kabul edin. Bir ekibin verimliliğini ölçmenin daha iyi yolları olduğunu düşünüyorum, ancak bunun işe yarayan bir süreç olduğunu itiraf etmeliyim.

Birincisi, PO yönetime görev bilgisi vermemelidir. Görev tahminleri kesinlikle ekibin yararına olacaktır. Ekibin dışındaki herkesin bilmesi gereken tek şey hangi hikayeler üzerinde çalıştıkları, puan değerlerinin ne olduğu ve ekibin ortalama hızının ne olduğudur. T

İkincisi, PO, yazılım hakkında derin bilgiye sahip üst düzey bir geliştirici değilse, görev tahminleri hakkındaki görüşleri çok fazla ağırlık taşımamalıdır. Geliştiriciler, sistem bilgisi olan ve işi yapan kişilerdir. Hepsi sıfır tahmin becerisine sahip okul dışında taze olmadıkça, tahminleri hariç tutulmalıdır.

Bu, tahminlerin bazen sorgulanamayacağı anlamına gelmez. Eğer öyleyse, bunun olumlu bir şekilde olması gerekir. Örneğin "zaten" x "için çalışmanın yarısını yaptığımızı düşündünüz mü, yoksa" Y yapmak için zaman eklemeyi hatırladınız mı? "

Alt satır: geliştiriciler, doğru bir şekilde iyi niyetli bir girişimde bulundukları sürece istedikleri tahminleri yapmak için kendilerini güvende hissetmelidirler. Eğer bir şey dört saat sürüyorsa, bunu kabul etmelisiniz.

Scrum kılavuzları bu konu hakkında ne söylüyor ya da bir şey söylüyorlar mı?

Hiçbir şey söylemiyorlar. Görev tahmini scrum'ın bir parçası değildir. Scrum ile tahmin, hikaye noktalarında durur. Görev tahmini sadece ekiplerin bir hikayeyi tamamlamak için gerekli tüm çalışmaları düşündüklerinden emin olarak hikaye puanlarını tahmin etmede daha iyi olmalarına yardımcı olan bir araçtır.

Scrum Master'ın görevi, scrum sürecinin takip edilmesini sağlamaktır. Bu, ekibin bir sprint'te yapabilecekleri iş miktarında (sürekli olarak) fazla taahhütte bulunmamasını da içerir.
Bir yandan, aşırı hevesli bir ekibi yönetmek anlamına gelirken, diğer yandan takıma baskı uygularsa Ürün Sahibine geri itmek anlamına gelir.

Taahhüdü / tahmini gerçekçi tutmanın iyi bir yolu, son birkaç sprintte gerçekten gerçekleşen hikayelere bakmaktır. Ekibin başarabileceğini kanıtladığı şey budur, bu yüzden tamamlanmayacağı için bir sprint'e önemli ölçüde daha fazla iş çekmenin bir anlamı yoktur.

Diğer cevapların da belirttiği gibi, ekip tarafından verilen tahminler üzerinde pazarlık yapmak Scrum sürecinin bir parçası değildir . Ekip, yazılıma en aşina olanıdır, bu yüzden bir şeyin ne kadar işe yaradığını en iyi şekilde bilmelidirler.

Ne olabilir pazarlığa tabi olduğu kapsam bir hikaye. Ürün Sahibi bir hikayenin makul şekilde beklenenden daha büyük veya daha küçük olarak tahmin edildiğini düşünüyorsa, yapılması gereken işin görüşünün taraflar arasında eşleşip eşleşmediğini görmek için ekipten bir açıklama talep edebilirler.
Hikaye gerçekten bu kadar işe yarıyorsa, Ürün Sahibi onu birkaç küçük hikayeye ayırmaya ve işlevselliği bu küçük hikayelere dağıtmaya karar verebilir.

Ekip kaliteyi sağlamaktan sorumludur ve bu asla pazarlığa açılmamalıdır.

Evet ve hayır.

Evet, sprint ekibi sprint'e neler geldiği konusunda ürün sahibiyle görüşmelidir .

Hayır, ürün sahibi olur hiçbir şey ne kadar süreceğini de söz. Siz uzman değilsiniz, onlar değil.

Bak, bu tür çöplerle uğraşmak zorunda kalmamalısın - menajerin ya da takımın lideri seni başarıya hazırlayacak. Bu, PM (veya patronları) ile başa çıkmak anlamına gelir, böylece başarılı olursunuz. Yani, o kadar da zor değil.

"Hayır."

Ne yapacaklar? Kod kendileri yazılsın mı?

Bu davranışa izin vermek Scrum Master'ın başarısız olmasıdır. İşi, her şeyden önce, takımı korumaktır. PO, yukarıda açıklanan nedenlerle, kısa görüşlüdür. Scrum Master tartışmaya bağlamalı ve olumlu bir şekilde yeniden çerçevelemelidir.

Böyle bir baskı elbette hız üzerinde aşağı yönlü bir baskıya yol açacaktır, bu OP'nin zaten belirttiği bir şeydir. Takımlar sürekli olarak sprintlerini bitirmiyorsa, Scrum Master tekrar devreye girmeli ve bunun neden böyle olabileceğini sormalıdır. Gerçekten toksik ortamlarda, ekip üyeleri Retrospektiflerde dürüst olmaktan çekinmeyin. Ancak bu durumda Scrum Master'ın kötü davranışları dile getirme ve takımı koruma sorumluluğu vardır.

Kendinizi Scrum Master'ınızın bunları yapamayacağı veya yapmayacağı bir durumda bulursanız, muhtemelen farklı bir Scrum Master'a ihtiyacınız vardır. PO tipik baskılara tepki veriyor. Mağaracılıktaki ekip de insanlar gibi sık sık tepki veriyor. Scrum Master'ın işi bunu ne olduğunu görmek ve durdurmaktır. OP'nin buradaki sorumluluğu, bunu Retrospektif'te ve gerekirse liderlere ve yöneticilere sunmaktır. Bu yine de çözülmezse, LinkedIn profilinizi güncelleyin ve birlikte çalışabileceğiniz daha iyi kişileri bulun.

Bir ürün geliştirme ekibi (ürün sahibinden, geliştiricilere, test edicilere kadar herkes) çevik süreci takip edebilir ve makul derecede yetkin insanlar ve gerçekçi beklentiler verildiğinde iyi sonuçlar alabilir.

Veya yüzeysel olarak çevik sürece benzeyen bir süreci takip edebilirler.

Bu PO muhtemelen görevler için daha düşük zaman tahminleri almaya çalışarak daha iyi sonuçlar alacağını düşünüyor. Tabii ki işe yaramıyor. Bir şey üç gün sürerse, bana çok para verirsiniz ve bir saat içinde yapabileceğimi tahmin edeceğim. Hala üç gün sürecek. Bana gelip bağırırsan, söz verildiği gibi bir saat içinde bitmediği için beş gün sürecek.

Tüm elde ettiği çevik süreci kırmak ve elde edebileceği tüm olumlu sonuçlardan vazgeçmek. Scrum ustası bunu önlemek için deneyime, güce ve cesarete sahip olmalıdır. Eğer yönetim tecrübesi olmayan birini scrum ustası yapar veya scrum ustasına bunu önleme gücü vermezse, çevik kırılma onların hatasıdır. Scrum ustasının cesareti yoksa, suçu Başbakanla paylaşır.

Burada motivasyona çok bağlı olduğunu söyleyebilirim. Tahminin genel amacı, takımın herhangi bir sprint sırasında ne kadar başarabileceği hakkında bir fikir edinmek, bu da gelecekteki çalışmanın bu hıza dayanarak tahmin edilmesini sağlar. Örneğin, ekip her bir sprintte 30 hikaye puanı tamamlıyorsa ve biriktirme listesinde X Öğesi'nin önünde yaklaşık 60 hikaye puanı varsa, Ürün Sahibi makul bir şekilde X Öğesinin 6 hafta ( standart iki haftalık sprint).

Bu tahminin mümkün olduğunca doğru olması için, belirli bir öğenin kaç hikaye puanı olduğu konusunda anlaşmazlık duymak duyulmamıştır. Scrum aslında onu teşvik ediyor. Bu anlaşmazlık zaman zaman bile ısıtılabilir. Bununla birlikte, nihai nihai hedef, PBI'nin karmaşıklığını doğru bir şekilde tahmin etmeli, çabayı yapay bir şekilde söndürmemelidir, böylece daha fazla PBI'yi belirli bir hıza sıkıştırmaya çalışabilirsiniz.

Prensip olarak aslında poker planlaması böyle çalışır. Herkes tahminlerini ortaya koyar. Scrum Master daha sonra yüksek ve düşük tahminleri alır ve takım üyesinin neden bu kadar yüksek / düşük olması gerektiğini düşündüğünü sorar. Bu, ekibe işin alternatif perspektiflerini duyma ve görevin gerçekte ne kadar karmaşık olduğu hakkında daha iyi bir fikir edinme şansı verir. Tartışmadan sonra herkes tahminlerini tekrar atar. Bu işlem, karmaşıklık konusunda genel bir fikir birliği sağlanana kadar durulanır ve tekrarlanır.

Başka bir deyişle, meydan okuyucunun neden katılmamalarına ilişkin bir gerekçe olduğu düşünüldüğünde, tahmininize meydan okumak yanlış değildir. Öyleyse, ekibinizi hala doğru olduğunu düşünüyorsanız, tahmininizin doğru olduğuna ikna etmek sizin sorumluluğunuzdadır.