Scrum sprintleri mümkün olan en hızlı şekilde çalışmak anlamına mı geliyor?

21

Son zamanlarda Çevik, Scrum yapan ve daha hassas olan bazı firmalarla röportaj yaptım ve bana çok çevik görünmeyen bazı şeyler var. Şu an özellikle beni ilgilendiren, Scrum sprintleriyle ilgili bir dava ele alacağım.

Konuştuğum belirli bir proje yöneticisi (evet, proje yöneticisi demiştim) gururla ekibindeki kişilerin çalışma saatleri bittiğinde eve gitmediğinizi (bağlamdan aldıklarım söylendi) anladığını belirtti. ne kadar sürdüğü önemli değil, iş bittiğinde eve gidersiniz. Satır aralarında okuduğum, mümkün olduğu kadar çok özelliği bir sprint içine topladığımız ve fazla mesai yapmasıdır.

Şimdiye kadar Agile'yi yapmadım (hala şelaleyi tercih eden mali ve devlet kurumlarıyla çalıştım), ancak anladığım şudur:

Scrum'daki sprint, Agile'deki genel yinelemenin adıdır;
Ekip sürdürülebilir bir hızda çalışmalı ve uzun vadede fazla mesaiden kaçınmaya çalışmalıdır, çünkü bunlar sadece kısa sürede etki eder ve etkileri uzun zaman içinde yaşadıkları problemlerden etkilenir.

İfadelerim doğru mu? Ve yöneticinin sunumunu kırmızı bayrak olarak almalı mıyım?

agile scrum development-methodologies

— JohnDoDo
kaynak

Agile ile ilgili gerçek bir deneyim de yok, ancak anladığım kadarıyla, sprint iş yükünüz, sprintinizin süresiyle dengelenmeli, bu nedenle geliştiriciler iş yükünü küçümsüyor ya da yönetici sadece iş yükü hakkında geri bildirim istemeden çalışmalarını yapıyor. . Bu durumda muhtemelen ikinci. - Yine de yanlışsam düzelt

— Andreas

4

@gnat Ben sorular çok farklı olduğunu düşünüyorum

— Andreas

27

“... çalışma saatleri bittiğinde eve gitmiyorsunuz, iş bitince eve gidiyorsunuz, ne kadar sürdüğü önemli değil…”. Rüzgar gibi koş. O bir aptal.

— JᴀʏMᴇᴇ

Bu soruyu yeniden açmak için oy kullandım. Önerilen yinelenen sorunun konusu çeviktir-yeni-mikro yönetim bu soru ile ortaktır, yöneticinin bir "aldatmaca" diye bir şey çağırması ve askerin bunun gerçekten aldatıcı olup olmadığını bilmek istemesidir. Bu soru, "diğer geliştiricilerle konuşmasına izin verilmiyor" hakkında önerilen "fazla mesai" ile ilgilidir.

— k3b

"... mesai saatleri bittiğinde eve gitmediğiniz, iş bitince eve gideceğiniz, ne kadar sürdüğü önemli değil" gibi görünüyor - sürdürülebilir adımın anahtar kavramı ile doğrudan bir çatışma gibi görünüyor - Ben masaya yemek koymak zorunda kalsaydım orada çalışıyorum. HST, bu zaman zaman meydana gelirse, onunla bir sorunum yok. Bazen, her çabasına rağmen, bir kriz var ve müşteri önce gelir. Ama bunun normal bir olay olduğu ve takdire şayan bir ses olduğunu söyler. Bunun anlamı, neden meydana gelmediğini anlamak ve bunun altında yatan problemi çözmek için kök neden olmadıklarıdır .

— Don Branson

27

Bu uygulamaların Çevik'in ilkelerine aykırı olduğunu görmek için çok fazla araştırma yapmanız gerekmez. Çevik Manifesto'nun arkasındaki ilkelerden biri :

Çevik süreçler sürdürülebilir kalkınmayı teşvik eder. Sponsorlar, geliştiriciler ve kullanıcılar süresiz olarak sabit bir hızda kalabilmelidir.

Birkaç yıl önce, Scrum ince ama önemli bir değişiklik yaptı . Bunun yerine ekiplerinin işlemekle elde edilebilir işe onlar tahmin onlar yapabilirler ne düşündüğünü.

Değişim, tarif ettiğiniz işe dönüşme davranışına çok benzeyen kötüye kullanımdan kaynaklanıyor. Geliştirme aşamasında, ekiplerin kontrol edemedikleri bir şey yapamayacaklarını kontrol ediyorlar - hava durumu benzetmesini kullanmak için yarın yağmurlu olacağını "taahhüt edemezsiniz".

Sorularınıza doğrudan cevap vermek için:

evet, Sprint, Scrum'daki bir yinelemenin adıdır ve aradaki farkı görmek için bu cevabı görün .
evet, ekipler sürdürülebilir bir hızla çalışmalıdır. Mesai Kesin olan tek şey tam o olacak ekipleri verimlilik uzun vadeli azaltır.
evet, kırmızı bayrak!

— Dave Hillier
kaynak

23

Evet haklısınız ve size söylenenleri söyleseydim mümkün olduğunca hızlı bir şekilde oradan kaçardım. Sadece bir bahane olarak çevik kullanıyorlar. Klasik ölüm yürüyüşüne benziyor.

— Miki Watt
kaynak

3

Bir ölüm yürüyüşünün tipik olarak bir sonu olmaz mıydı? Sprint sonrası sprint gibi çalışırlarsa, bu proje sonsuz bir cehennem gibi ses çıkarır.

— DXM

5

Hayır, bir ölüm yürüyüşünde her zaman var "sadece bir sonraki sürüme geçmemiz gerekir, sonra hataları düzeltip giderebiliriz! Ayy, müşteriye bir sonraki sürüme iki ay içinde söz verdik, sadece bir sonraki öğeye geçmemiz gerekiyor versiyonu!" ve benzeri şeyler hakkında fikir edinebilirsiniz.

— Miki Watts

2

@DXM, herkesin işi bıraktığı ya da işten çıkarıldığı zaman sona erer. Ölüm Mart projeleri yıllar alabilir.

— Dogweather

3

@DXM'in ölüm marşları öldüğünde bitiyor.

— Dave Hillier,

hmm, sanırım kendi deneyimimi orada yansıtıyordum. Her nasılsa aklımda yanlış yönetilen projeler, sonradan nereye gideceğine aylarca kararsızlığın geldiği ölüm yürüyüşünün bir birleşimi. Ekibimiz en uzun süre boş tiryakiyle baş parmaklarına oturdu ve neredeyse 8 aydı. Daha sonra "yıllık bir yayın döngüsündeyiz" ifadesiyle bir sürüm için 4-6 ay verilirdi

— DXM

11

Bunu kabullenebilecek önemli bir şey var: takım sprintin kapsamını kabul ediyor.

Scrum'da ekipler sadece işe atanmaz. Ürün sahibi, ürün çalışmasını ve teknik (borç) çalışmasını öncelik sırasına koymak için ekiple görüşür. Proje yöneticisi, ürün sahibi ve ekibi daha sonra müzakere sürat ve ne o işin kapsamı içine çekip alır ne.

Bu dünyada, ekip aslında “X çalışmasını yapabiliriz, test ettik ve bu yinelemeyi gönderdik” diyor. Bu yüzden bir ekibin zaman zaman bu taahhütleri yerine getirmek için fazla mesai yapmasını beklerdim.

Bununla birlikte, pek çok yer çevik bastardize - ve çok az takım lideri genellikle patronları olan insanlarla etkili bir şekilde pazarlık yapabilir ... Bunu büyük bir kırmızı bayrak olarak kabul ediyorum.

— Telastyn
kaynak

8

"zaman zaman bu ( yanlış tahmin edilen ) taahhütleri yerine getirmek için fazla mesai yapınız " => yanlış tahminler yapmayı alışkanlık haline getirin

— gnat

1

@gnat - pssh. Tahminler bazen yüksektir. Tahminler bazen düşüktür. Eğer küçümseme eğilim haline gelirse, kesinlikle bir problemdir. Ancak bu, büyük ölçüde yinelemelerin var olmasının nedenidir: tahminin iyileştirilmesine yardımcı olmak.

— Telastyn

8

Programlama terlikleri genellikle işçiler tarafından yapılan müzakereleri kabul etmemektedir.

— maple_shaft

1

@gnat: Eğer bir ekip olarak, çalışmayı alışkanlıkla küçümsemediğinizi fark ederseniz, bir sonraki sprintte daha az çalışmanız gerekir.

— Bart van Ingen Schenau

Yönetim hedefleri, çalışma saatleri sınırlarına bakılmaksızın (ve deneyim, bunun vakaların çoğunda doğru olduğunu gösterir) göz önüne alındığında, mümkün olduğu kadar fazla iş yapıldığında ve çalışanların hedefleri, ücretli çalışmayı aşmadan en fazla işi yapmaktır. saatler (bazı yöneticilerin bunun iyimser olduğunu iddia edebileceğini itiraf ediyorum), o zaman tahmindeki doğal hatadan bağımsız olarak, zamanlama her zaman> = çalışma saatlerine yönelir. Mantıksal uzantı, çalışanların hedeflerinin hafife alması gerektiğidir. @BartvanIngenSchenau bu alışkanlığın doğal olarak nasıl geliştiğidir.

— Steven Evers

1

Scrum, o sprint süresince tamamlanması gereken bir takım görevleri tahmin ettiğiniz sprintlere bölünür (tipik olarak 2 hafta, ancak 1 gün ile 4 hafta arasında bir yer gördüm). Bence bu yanlış işlerin yanlış yapılması için bir teşvik oluşturuyor. PO'lar (ürün sahibi), düşük tahminlerin sprint başına büyük bir taahhüt almasını isteyecektir. Ekip, Başbakanların görmesi için güzel bir yakma çizelgesi oluşturmak için büyük tahminlerde bulunacak. Bunlar elbette berbat bir organizasyonun göstergesi. Gerçekten doğru tahminler almak istiyor, kısa düşmekten ve hikayeleri bir sonraki koşuya taşımaktan ya da erken bitirmekten ve birikmiş işlerden fazladan görevler almaktan korkmuyorsun. Ben "sprint" teriminin daha hızlı çalışan insanların bu imajını yarattığını düşünüyorum.

— jiggy
kaynak

1

Bunun dışında PO'nun tahmin sürecinde bir parçası olmamalıdır. Çevik olmaları halinde, takımlar tahminleri ortaya koymaktan ve takımın PO'nun yalnızca öncelikli öncelikleri değiştirebileceğini tahmin etmesine dayanarak tahminler hazırlamaktan sorumlu olacaktır .

— DXM

2

“Ekip, Başbakanların görmesi için güzel bir yakma çizelgesi oluşturmak için büyük tahminlerde bulunacak.”: Bu, tüm mekanizmanın kusurlu olduğunu düşünmemin bir nedeni bu. Bir yöneticinin, bir ekibi çizelgelere aktarılması konusunda tahminler vermeye zorlayarak, güvendikleri bir ekipten çok daha iyi performans alabileceğini düşünüyorum.

— Giorgio

Takımın yapması gereken, ancak dediğim gibi, tahminleri yürütmek için bir teşvikleri var. PO ödeyen ise, daha agresif bir tahmin yapmak için baskı uygulayabilirler. Arkaplan için danışmanlık yapıyorum, bu yüzden scrum takımı iş arkadaşlarım, PO ise genellikle dış ve şişirilmiş fatura oranımızı ödüyor :)

— jiggy

@Giorgio güvenilmez bir ekip her zaman tahminleri destekleyebilir ve işleri daha da kötüleştirebilir. Ancak güvenilir bir ekip, hatta uzmanlardan daha iyi tahmin etmeyi öğrenebilir. Bu yüzden tahminler yapılmakta ve daha sonra, tahmin kabiliyetlerini geliştirmeye çalışmak için fiili çalışma ile karşılaştırılmaktadır. Mekanizma kusurlu değil, bir sistemden yararlanan bir takıma sahip olmak sorun ve yönetim sisteminden bağımsız olarak sorun olacak.

— Chris

1

Hayır: scrum sprintleri bir zaman kutusu, daha fazlası değil, daha az değil. Sprint / yinelemenin başlangıcında, ekip , önceki performans, uygunluk, yaklaşan olaylar, açık engeller vb. Gibi şeylere dayanarak elde edebildiklerini düşündükleri hikaye puanlarının bir miktarını verir. Daha sonra ürün sahibi ile pazarlık eder. hangi kullanıcı hikayelerinin sprint'e girdiği hakkında. Bu, ekibin ürün sahibine vermiş olduğu taahhüttür (veya? Diğer cevabı görüyordu) .

Geliştirme sırasında, işler gerçekten öngörüldüğü gibi değilse (sonuçta yazılım geliştirmedir) ve ekibin taahhüdünü yerine getirmemesi riski varsa, ürün sahibine bir veya daha fazla hikayenin ortaya çıkması riski olduğunu bildirir. tamamlanmadı.

Ve bu iyi. Elbette, kendini kötü hisseder, sprintin sonunda sprintin başarısız olduğunu kabul etmek zorunda kalır, ancak yenilgi değildir, gelişme için bir fırsattır. Çünkü yeninin süratinin / başlangıcının sonunda geriye dönük bir sürat koşusu elde edersiniz ve birilerinin soracağı ilk şey 'Neden bu süratten başarısız olduk ve tekrar başarısızlığa uğramamak için ne yapmamız gerekiyor?' ?'. Bir seçenek daha az bağlılık bırakmaktır (= daha az hikaye puanı almak).

tl; dr: Sürdürülebilir Hız. Scrum kadansla ilgilidir, ekibin sprint-sprint esasına göre süresiz olarak tutabileceği bir şey. Fazla mesai yapmak değildir; Takım çok çalışacak, iş özensizleşecek, üyeler hasta arayacak veya tamamen istifa edecek ve sonra başarısız bir sprintten daha büyük bir probleminiz olacak.

— Cthulhu
kaynak

0

Çevik süreçler sürdürülebilir kalkınmayı teşvik eder. Sponsorlar, geliştiriciler ve kullanıcılar süresiz olarak sabit bir hızda kalabilmelidir.

Çevik Manifesto milletinden

Her zaman fazla mesai yapmak bana sürdürülebilir gelmiyor.

Bununla birlikte, bir bahar taahhüdünün güçlü bir sorun olduğuna değinmedim (ekibin çalışmak istediği şekilde ise) ve fazla mesai yaptığınız veya tahminleri mahvettiğinizde fazla mesai yapmanız gerekmiyor, tahmin etme veya iletişim kurma konusunda daha iyi bir teşviktir. PO'ya beklentileri.

— ptyx
kaynak

0

Konuştuğum belirli bir proje yöneticisi (evet, proje yöneticisi demiştim) gururla ekibindeki kişilerin çalışma saatleri bittiğinde eve gitmediğinizi (bağlamdan aldıklarım söylendi) anladığını belirtti. ne kadar sürdüğü önemli değil, iş bittiğinde eve gidersiniz. Satır aralarında okuduğum, mümkün olduğu kadar çok özelliği bir sprint içine topladığımız ve fazla mesai yapmasıdır.

Bu Scrum değil. Bir zaman çizelgesi için önerilen iş yükü yöneticinin istek listesine değil , takım hızına dayanmaktadır . Onlar sadece sizi, sonsuz mesai çalışmalarının "Çevik" olduğuna inanmaya zorluyorlar. Rahatsız ve odaklanmış bir şekilde çalışırken ekip daha verimli olacak, ancak Scrum, sonsuz verimlilik kazançları için sihirli bir değnek değildir .

Yönetici ya hafif bir Çevik anlayışa sahiptir, ya da (daha büyük olasılıkla) geliştiricilerin bu kadar aptal olduğunu düşünüyor. Öte yandan, ekip tekrar tekrar sprinti kabul ettiğinde, fazla mesai yapmaları gerekeceğini bilerek, belki de aptallar ve daha iyisini hak etmiyorlar mı?

Sanırım cevabı biliyorsunuz ... ;-)

— JensG
kaynak