Ben büyük bir arka uç bileşeni ile Android ve iOS için yeni bir mobil uygulama üzerinde çalışan bir geliştiriciyim. Bu projenin üç alanında bulunduk ve Scrum'u tüm törenleriyle (arıtma, planlama, günlükler, retrospektifler, vb.) Kullanıyoruz.

Sprintlerin ikisinde ekibin fazla mesai ve hafta sonları çalışması gerekiyordu, çünkü yönetim çok endişe duyuyordu çünkü sprint taahhüdünü zamanında tamamlayamadık. Herkes çok çalıştı, ama bazı dış bağımlılıklar ve iyimser tahminler bizi tüm sprint hikayelerini başarmak için mücadele etti.

Tecrübelerime göre, bazı sprintler sırasında tamamlanmamış küçük bir hikaye yüzdesine sahip olmak biraz normaldir ve bir sonraki bölümde ele alınabilir. Ancak proje yöneticimiz, tahminde kendimizi yaptığımızın bizim hatamız olduğunu söylüyor, bu yüzden süratteki tüm maddeleri tamamlamalıyız.

1. Farkında olmadığım Scrum'un kabul edilebilir / yaygın bir varyasyonu var mı?

2. Bu konuda hareket etmemi nasıl önerirsin?

Birkaç şey öne çıkıyor.

Yönetimin ekibin bir dizi çalışmayı taahhüt ettiği fikri, Scrum Kılavuzunun en son sürümleriyle tutarsız. “Taahhüt” veya “Taahhüt” kelimesi, Scrum Kılavuzunun en son (Kasım 2017) versiyonunda sadece iki kez - Scrum Değerlerini listelerken bir kez ve bir kez de “insanlar Scrum Takımı hedeflerine ulaşmayı taahhüt eder” ".

Gol fikri Scrum için önemlidir. Sadece organizasyonların ve takımların geniş hedefleri yoktur, aynı zamanda Scrum'da, her Sprint'in Sprint Planlama'da Ürün Sahibi ile Geliştirme Ekibi arasında bir işbirliği olarak tanımlanan bir Sprint Hedefi vardır. Sprint Hedefi, Ürün İş Listesindeki öğeleri uygulayarak gerçekleştirilir, ancak bu yalnızca "işin bu işini bitirmek" değildir ve genellikle Sprint İş Listesinin tamamını temsil etmez. Yani, Sprint Hedefine Sprint için seçilen her Ürün İş Listesini veya Sprint İş Listesi'ndeki her bir öğeyi tamamlamadan ulaşabilmelisiniz. Şu andaki düşüncem, Sprint Hedefini gerçekleştirmek için gereken çalışmanın ekibinizin kapasitesinin% 60-70'i civarında olması gerektiği, ancak sizler kapasiteyi hesaba katarsınız. Farklı organizasyonlar farklı olacak ama

Fazla mesai ve hafta sonları çalışmak da bir Çevik Yazılım Geliştirme uygulamasıdır. Temel prensiplerden biri, bir çabanın tüm paydaşlarının sürdürülebilir bir hızda çalışabilmeleridir. Uzun günler ve hafta sonları, ödenmiş olsalar bile, bir ekip için sürdürülebilir değildir.

Bu noktada, sonraki birkaç adım var. Takımın Scrum Master'ı, Scrum ve Çevik Yazılım Geliştirme'nin ("taahhüt" ve "sürdürülebilir hız" gibi) değerleri ve ilkeleri konusunda yönetimi eğitiyor olmalıdır. Ekip, işi öngörme ve Ürün Sahibiyle kapsam müzakere etme yeteneği üzerinde çalışmalıdır. Ekip ayrıca, bu duruma yol açan engelleri (dış bağımlılıkların etkisini ortadan kaldırarak veya azaltarak) tespit etmek veya önlemek için çalışmalıdır.

Planladığınız durum, yönetimin ekibin planlanan tüm hikayeleri tamamlamak için fazla mesai yapmasını gerektirdiği durumlarda, Scrum edebiyatının “taahhüt” terimini kullanmayı bırakmasının nedenlerinden biri. Gerçek bir taahhüt ancak 3. taraf bağımlılıkları konusundaki belirsizlikler, her bir maddenin ne kadar çalıştığı, herkesin hastalığı hesaba katarak ne kadar süre kalabileceği vs.

Scrum'un temel fikirlerinden biri, ekibin, normalde fazla mesai olmadan (ücretli veya ücretsiz) normal saatlerde çalışmak anlamına gelen sürdürülebilir bir hızda çalıştığıdır. Bu doğrudan anlamına gelir değil Scrum'un kabul edilebilir bir varyasyonunu yaşandığı.

Bu konuda yapabilecekleriniz rolünüze bağlı.

Eğer geliştiriciyseniz, yapabileceğiniz en iyi şey

• (geliştirme ekibi olarak topluca), bir sprint içinde verebileceğinizden kesinlikle daha fazla çalışmaya "taahhüt vermeyi" reddetti. Bu muhtemelen yönetimin yapmasını istediğinden çok daha az olacaktır.
• yeni görevlere başlamak yerine, işi bitirmeye odaklanın. Bazı çalışmaların tamamlanamadığını görürseniz, planların düzeltilebilmesi için bunu mümkün olduğunca erken belirtin.

Eğer bir Scrum ustasıysanız, Scrum hakkındaki yönetimi eğiterek gerçekten değerinizi kanıtlayabilirsiniz. Bana dikkat çeken bazı noktalar:

• İlk paragrafta belirtildiği gibi, takım sprint planlaması sırasında bir taahhüt vermez, ancak bitirmeyi umdukları işi tahmin eder.
• Takımın bir sprint sonunda bitmemiş bir işi yapmaktan kaçınması gerekmesine rağmen, bu durum bir projenin başlangıcında (veya takımın kompozisyonundaki değişiklikten sonra) neredeyse kaçınılmazdır. Bir sprintte takımın ne kadar gerçekçi bir şekilde başarabildiği ancak bu kompozisyondaki takımın son birkaç sprintinin tarihi rakamlarına dayanarak belirlenebilir. Projenin başlarında, bu tür tarihi figürler henüz mevcut değil, bu nedenle ilk 3'te yer alan bir ekip, her bir sprint için planlananın tam olarak iyi planlamaya göre daha fazla kaza geçirdiğini gösteriyor. Sürdürülebilir bir hızla yaklaşık 5 sprintin ardından, ekibin bir sprint içinde gerçekçi olarak ne kadar iş bitirebileceği konusunda makul bir fikir edinmek için yeterli veri var.

PM’nizin işine karışmış işi yok.

Başbakanınızın ödenmemiş fazla mesai yapmasını isteyen bir işi yok.

Yapılacak en bariz şey, tüm görevleri zamanında biteceklerini garanti edebileceğiniz şekilde tahmin etmektir. O zaman bara ikinci yoldan gidebilmelisiniz, çünkü bir görevi küçümsemek açıkça ücretsiz bitireceğiniz anlamına gelir, daha sonra abartmak işsiz vaktiniz olduğu anlamına gelir.

Bunun bir çok yönü vardır, ancak yüksek düzeyde, evet - Başbakan, planlanan çalışmanın neden tamamlanmadığını açıkça bilmek isteyecektir. Bununla birlikte, bunun geriye dönük olarak ortaya konması (ve çözülmesi) gerekir. Gelişim açısından, sprint başarısızlığına katkıda bulunabilecek birçok faktör var.

Düşünmek isteyebileceğiniz bazı şeyler:

Sprint içinde çok fazla

Düzenli olarak çok fazla iş yapmaya çalışıyorsanız, sprint başarısız olur. Sprint hızı, optimum nokta sayısının (veya günlerin) ne olduğunu bulmak için zaman içerisinde izlenmelidir.

Kaynak tahsisi

Sprint planlamasının, törenler, tatiller, eğitim, yönetici, destek ve diğer projeler vb. Gibi gelişim dışı etkinlikleri yeterince dikkate aldığından emin olun. seni başından beri arka ayağına koydum.

Tahmini varyasyon

Hassaslaştırma yapıyorsunuz, ancak her zaman istila eden belirli görevler var mı? Genellikle bunlar eksik veya belirsiz şartlara bağlıdır. Gereksinimler yünlü ise, yeterince rafine edilmemiş veya bir başak planlanmadıkça, hikaye onu sprint içine bile sokmamalıdır.

hız

Hız doğru izleniyorsa, gerçek hikaye sayısı netleşmelidir. Bu her zaman zamanında yapılacaklarını söylemek değil, işleri daha kolay hale getirmesi gerektiğidir.

İyi niyet

Herhangi bir projede, iyi niyet sınırlıdır. Teslim etmek için saatlerce sürekli çalışıyorsanız, moraliniz acı çekecek ve devler tükenecek - bu bir proje yönetimi hatası . Daha önce de belirtildiği gibi, sprint planlamanın yalnızca size yardımcı olmak için hız ve sivri uçları kullanarak gerçekçi sayıda öykü programladığından emin olun.

Dikenler

Eğer bir ürün kötü bir şekilde rafine edilmişse veya sadece düz yünlü ise, daha sonraki sprintler için daha iyi bir tahmin sağlamak üzere bir başak koymaktan korkmayın. Evet, bazı insanlar kestirimlerde sadece kötüdürler, ancak çoğu zaman, gerçekler tam olarak bilinmemektedir. İdeal olarak, bunun arıtma ile kaplanmış olması veya PO tarafından erken toplanmış olması gerekirdi, ancak bazen bir sprint içine kayabilirler. Geliştiriciler bu zorlanmaya karşı koymalılar, çünkü bunlar aksi takdirde iyi giden bir sprinti kolayca torpido edebilir.

Hayır, bu bilinen bir Çevik form değildir , çok önemli bir nedenden ötürü: her şeyi sunmayı taahhüt ediyorsanız , Çevik değil Muhtemelen şelalesini kötü yapıyorsun . Eminim eski testereyi "iyi, hızlı, ucuz, iki tanesini seç" duydunuz, değil mi? Yazılım geliştirme ile, "zamanında, bütçeyle birlikte sunulan tüm özellikler ilk veya diğer ikisini seçmeli" gibi. Şelale ilk alır ve Çevik ikinci iki seçer.

Çevik olacaksanız , zamanında tamamlayamadığınız Sprint'ten Hikayeler bırakma esnekliğine ihtiyacınız var . Bunu yapmanın olası bir yolu, Ürün Sahibinden MoSCoW önceliklendirmesini kullanarak hikayeleri değerlendirmesini istemek. Bu, Tamamlanacak Havayolları olarak% 60'tan fazla hikayenin (toplam Öykü Puanına göre), Tamamlanacak Havada% 20, Projenin tamamlanması için Tamamlanması gereken Havada% 20, Asgari Uygulanabilir Ürünün% 20'sinin çıkarılmasını ve Vaktiniz varsa ve geçerli sürüm kapsamı dışında Won't Haves olarak herhangi bir zamanınız varsa, tamamlanmış olabilecek Haves olabilir. Ayrıca, bir araya getirildiğinde, Must Haves'in, diğer kategorilerden herhangi bir öğeyi dahil etmeye gerek kalmadan Minimum Uygun Ürünü oluşturmak için kemiklerine yetecek kadar ete sahip olmaları gerektiğine dikkat etmek önemlidir.

Ürünlerin Sprint İş Listesinden düşülüp düşülmeyeceğini belirlemek, Ekip tarafından talep edildikten sonra ve Ürün Sprint İş Listesinden düşülen tüm ürünler Ürün Sahibi tarafından değerlendirildikten sonra Ürün Sahibinin sorumluluğundadır. Projeden tamamen vazgeçildi veya Proje İş Listesinde uygun şekilde sıralanan bir pozisyona getirildi.

Bu durumda, Ürün Sahibinin Proje Yöneticiniz olduğunu tahmin ediyorum, değil mi? Hangi görevlerin bırakılacağını belirlemek onun işi olacaktır, bu yüzden fazla ödün verdiğiniz için sizi suçlamamalıdır, çünkü bunun için telafi etmek için görevleri bırakmak onun işi olacaktır ve öyle yapmıyor gibi görünüyor.

O haklı, sprintler arasında bir devir olmamalıdır. Sprumlar arasında geçiş yapan Scrum takımları bir anti-paterndir ve kanonik Scrum'ın geçerli bir sonuç olarak kabul ettiği bir şey değildir.

Ancak yaklaşımı iyi değil.

Bir sprint sırasında, takım sürekli yapılan çalışmaları izlemeli ve seçili hikayeleri bitirmekle ilgili sprint planlaması taahhütlerini sürdürebiliyorlarsa. Eğer ekip bütün hikayeleri bitiremediğini tespit ederse, PO ile buluşmalı ve sprint'ten kaldırılacak bir hikaye seçmelidir. Bunu yaparak, herkes HİKAYE ÜZERİNE ÇALIŞIYOR ve kalan hikayeleri bitirmeye odaklanıyor. Unutmayın: Bir hikayeyi tamamen bitirmek her zaman iki hikayeyi yarı bitmiş olmaktan iyidir.

Dış bağımlılıkların sorunları ve kesin olmayan tahminler, Retrospektiflerin var olmasının nedenidir. Retro sırasında, takım bu sorunları yansıtmalı ve tanımlamalıdır. Ekip daha sonra bu sorunlara çözümler bulmalı ve uygulamalıdır. Tahminler, sistemi ve sade deneyimi daha iyi tanıyarak daha kesin yapılabilir. Dış bağımlılıklar daha zor, ancak düzeltilmesi imkansız değil.

Başbakanınızın ( PM'in Scrum ekibinde ne işi var? ), Scrum Master'ın sizi tüm hikayeleri bitirmeye zorlamasına izin verilmemelidir. Bunun yerine, şikayet ederse, onları Retrospektif için saklamalıdır. Daha da iyisi, hikayelerin zamanında bitmesini engelleyen problemleri çözmenin bir parçası olmalıdır.

Farkında olmadığım Scrum'un kabul edilebilir / yaygın bir varyasyonu var mı?

Hayır . Tamamen yanlış. Ben olabilir belki sempati ödenen PO sürat bitmeden gerçekler olarak tahminler vermekten hata yaptıysanız, mesai, ama ödenmemiş fazla mesai tamamen saçma ve beni en kısa sürede başka bir iş aramak olur.

Bu konuda hareket etmemi nasıl önerirsin?

Tecrübelerime göre, demiryolunun o kadar fazlası olan insanlar mantıksal argümanları dinlemeyecekler. Ne kadar kırıldığını görmelerinin tek yolu şov değil. Bu yüzden bir dahaki sefere tahmin ve taahhüt, mümkün olan en küçük miktarı taahhüt . Sprint sonuna kadar küçük bir bilet bitirmeyi taahhüt edin. Bir günde yapabileceğin biri. Başbakanınızın nasıl tepki verdiğini görün. Ardından, sistemin ne için kullanıldığı ve sistemin ne için kullanılması gerektiği konusunda bir tartışma başlatınız .

Genel olarak, projenin başlangıcında, takımın hızına karar verdiğimizde, yeni bir takım olduğu gerçeğini göz önüne alarak muhafazakar (normalden daha düşük) bir sayı alırız, takımın yerleşmesi biraz zaman alır. , birbirlerini anlayın, fonksiyonel ve NFR gereksinimlerini anlayın, vb. Temel olarak, ilk birkaç sprint'in ardından takım hızını optimize ederiz ve bariz ki hız ancak o noktadan itibaren gelişir.

Başlangıçta daha yüksek bir hıza ulaşmanın ve takımı başarabilmenin bir anlamı yoktur.

Bir başka şey, kaçırılmayacak bir teslimat taahhüdünün olduğu bir kerelik senaryoda, proje yöneticilerinin takıma esneme, geç saatlere kadar çalışma ve hafta sonları çalışabilmesi için takıma baskı yapmasıdır. Ancak o zaman bu çalışma normu olarak değil bir istisna olarak değerlendirilmelidir. Bu şekilde çalışmak, kısa vadede hızı artırabilir, ancak uzun vadede kod kalitesi sorunları, takım tükenmişliği sorunları, düşük motivasyonlu mutsuz takımlar, vb.

Taahhüt SSS

Bu davranış normal mi?

Emin değilim.

Şaşırtıcı mı?

Hayır. Bazı insanlar, taahhütteki her şeyin tamamlanması gerektiği anlamına gelen "taahhüdü" her zaman anlayacaktır .

İyi bir fikir mi?

Hayır. Çevik gelişme, sürdürülebilir bir ana başlık olarak sürdürülebilirliğe sahiptir : Sadece süresiz olarak yapabildiğiniz kadar uzun / çok çalışın. Bu çoğu zaman mantıklı bir fikir. (Yönetiminiz bunu kabul etmiyorsa, örgütlerini çevik olarak çağırmamalıdır.)

Ne yapmalıyız?

• Sprint içeriğinin bir tahmine dayandığını açıklayın . "Tahmini", yalnızca bazen doğru olacağı ve genellikle yanlış olacağı anlamına gelir. Yanlış olduğunda, bazen çok düşük ve bazen çok yüksek.
• Tahmin davranışını değiştirmenin iş hızından çok daha kolay olduğunu açıklayın.
• Ekip, çok yüksek tahminler için cezalandırıldığında, sadece daha düşük tahmin edeceğini ve yönetimin içeriğin bir kısmını bir sprintden diğerine zorlamaktan çok daha fazla ilerleme kaydedeceğini açıklayın.

Güzel olan şudur: Proje yöneticiniz tüm bunları zaten bilecek ve doğru olarak tanıyacaktır. Sadece kısa vadede bir kişi onları görmezden gelmeyi tercih edebilir.

Yönetim ekibinize katılmıyorum. Sprint'i bitirmek için fazla mesai yapmamalılardı.

Ancak, taahhütlerin mümkün olmadığı fikri yazılım geliştirmenin yanlış anlaşılmasından kaynaklanmaktadır. Birçok takımın, bir sprintte tamamlayabilecekleri hikayeleri, önceki sprintlerde tamamladıkları hikaye puanlarının sayısına göre tahmin etmeye çalıştıklarını gördüm. Bu mümkün olsaydı, yazılım geliştirmenin doğrusal olduğunu söylerdi, yani iki saat çalışırsam bir saatten iki kat daha fazla çalışırım.

Yazılım geliştirme yaratıcıdır ve bu nedenle doğrusal değildir. Ekibin yönetime sprint içinde neler yapabileceğini anlatması ve daha sonra bu hikayeleri sunması daha iyi bir uygulamadır. Taahhütlerinizi sürekli olarak kaçırıyorsanız, başlayacağınız hikayenin kapsamı hakkında hiçbir fikriniz yoktu veya ürün sahibiniz tarafından daha fazla şey yapması için baskı altındasınız.

Eski durumda, anlatmaya devam etmeden önce hikayenin kapsamını anladığınızdan emin olmalısınız. İkincisi ise, bir kültür sorununuz var ve yapılabilecek çok az şey var.