Takım sürekli sprint hedeflerine ulaşmak için başarısız

Tek bir ürüne sahip küçük bir yazılım şirketiyiz.

Scrum kullanıyoruz ve geliştiricilerimiz her sprint içine dahil etmek istedikleri özellikleri seçiyor. Maalesef geçen 18 aylık süreçte, ekip bir zamanlar sprint için taahhüt ettiği özellikleri sunmadı.

"İşler bitince yazılım yapılır, er ya da geç olmaz ... takımın üzerinde baskı yapmak, daha fazla insan koymak için yardımcı olmaz" ... "Sorumlu Sprint'lerin başarı oranını nasıl artırabileceğimize dair sorumu geliştiricilerden birinden benzer geri bildirimler aldım. Ve evet, retrospektifleri kullanıyoruz .

Sorum temelde:

Geliştiricinin kalitesinde problemi aramak ne zaman adil olur?

Kendi çalışmanızı / özelliklerinizi seçip yine de her sprintte başarısız olursa: - Kendi kodunuzun karmaşıklığını denetleyemezsiniz; - ya da kod o kadar karmaşıktır ki hiç kimse karmaşıklığı denetleyemez.

Bir şey mi eksik?

İlk önce 'kimin umrunda' diye sormalısın.

Sprint'leri tamamlamak iyi hissettiriyor ve bazı şirketlerde scrum ebeveyninin çerezleri var. Ancak nihai test, şirketin hedeflerine ulaşıp ulaşmadığıdır.

Yukarıdakiler çok yönlü. Eğer bir sprintin planlanan içeriğini asla tamamlamazken, şirket başarılı olursa, bunun yerine Kanban'ı da kullanabilirsiniz: birikintileri sıralarsınız, en önemlisi üzerinde çalışırsınız ve tanımlanmış yinelemeler için çok endişelenmezsiniz.

Tanımlanan yinelemelerin değerlerinden biri, süreç iyileştirmeyi sağlamak (veya bazı zihniyetlerde düşük performans gösterenleri atmaktır). Bunu şimdi anlamıyorsun. Böylece, süreci iyileştiren sürecin geri kalanını benimseyebilir (ve sonunda sprint'leri tamamlayabilirsiniz) veya sahip olduğunuzdan hoşlandığınıza karar verebilirsiniz.

Bir şey mi eksik?

EVET!

Sen gitti 18 ay - ya da bir yere Retrospectives ile 36 sprint mahallede, ama bir şekilde bunu düzeltmek olamazdı? Yönetim ekibi hesapverebilirliğini vermedi, sonra onların yönetim tutun vermedi onları ekip sorumlu tutmakta değil sorumlu?

Şirketinizin yaygın olarak beceriksiz olduğunu kaçırıyorsunuz .

Peki, nasıl düzeltilir. Siz (dev) bu kadar çok çalışmaya kararlısınız. Eğer öyküler öyle yapamayacak kadar büyükse, öyküleri daha küçük parçalara bölmeniz gerekir. Ve sonra yapacaklarını söyleyeceklerini yaptıkları için insanları sorumlu tutmaya başlarsın. Eğer ortaya çıkarlarsa, her bir sprintte sadece küçük bir özellik elde edebilirler, sonra nedenini çözebilirler ve daha iyi hale getirebilirler (ki bu geliştiriciyi değiştirmeyi içerebilir). Ortaya çıkarsa, makul miktarda iş yapmayı nasıl çözeceklerini çözemezlerse, onları kovarsınız .

Ama bundan önce, işler o kadar uzun gitmesine izin yönetim bakmak ve onlar yapmıyoruz neden anlamaya olurdu onların işini.

Küçük bir değişiklik yapmanızı ve Scrum yerine birkaç hafta Kanban'ı denemenizi öneririm . Takımınız için daha iyi işe yarayabilir.

Scrum, bir sprintte mevcut çalışma süresini sınırlandırarak üretkenliği artırırken, Kanban aktif, eşzamanlı sorunları sayısını sınırlandırarak üretkenliği ve hızı artırır. Zaman tahmini artık sürecin bir parçası değil. ( kaynak )

Kısaca, Kanban nedir?

Kanban ayrıca verimlilik uğruna iş düzenlemek için kullanılan bir araçtır. Scrum gibi, Kanban da çalışmayı yönetilebilir parçalara bölmeye teşvik eder ve bu işi iş akışı boyunca ilerledikçe görselleştirmek için Kanban Kurulu (Scrum Kuruluna çok benzer) kullanır. Scrum, belirli bir miktarda çalışmayı (sprintlerle) başarmak için izin verilen süreyi sınırlarsa, Kanban herhangi bir koşulda izin verilen çalışmayı sınırlar (yalnızca çok sayıda iş devam edebilir, yalnızca çok fazla kişi olabilir) -yapılacaklar listesi.)

SCRUM ve Kanban nasıl aynıdır?

Hem Scrum hem de Kanban, büyük ve karmaşık görevlerin parçalanıp verimli bir şekilde tamamlanmasını sağlar. Her ikisi de sürekli iyileştirme, işin optimizasyonu ve sürecin üzerinde büyük bir değer yaratmaktadır. Her ikisi de, tüm ekip üyelerini WIP'deki döngüde ve gelecek olanları tutan son derece görünür bir iş akışına benzer odağı paylaşıyor.

Bu linkten kalan detayları görün

Benim sorum temelde: Sorunu geliştiricilerin kalitesinde aramak ne zaman adildir

Gönderinizde bu soruyu cevaplayacak kadar bilgi yok. Başarısız olup olmadıklarını bilmenin bir yolu yoktur, çünkü yetersizdirler ya da başarısız olduklarından, başarısız olduklarından daha fazla iş yapmayı taahhüt ederler.

Eğer inanılmaz yetenekli bir geliştiriciysem, yetenekli yetenekli geliştiricilerden oluşan bir ekibim ve X hikayesini iki sprintteki (veya 36!) Bitiremiyoruz, beceriksiz miyiz? Yoksa, sadece tahminde emmek mi? Bu, hikayelerin "giriş ekranı oluştur" veya "Mars'a güvenle bir adam yolla" olup olmamasına bağlı.

Sorun, kötü hikayelerle ve / veya kötü tahminlerle başlar

Tahmin zor. Gerçekten zor. İnsanlar bunu emiyorlar, bu yüzden Scrum bize bir veya iki günden fazla sürmemesi gereken bloklar halinde çalışmamızı ve kısa sürede tamamlayabileceğimizden emin olduğumuz blokların küçük gruplarını birleştirmemizi sağlıyor. . Bloklar büyüdükçe ve süre ne kadar uzun olursa, tahminlerimiz o kadar doğru olmaz.

Mağazalarınız nasıl? İyi kabul kriterleri ile iyi yazılmışlar mı? Her biri birkaç gün içinde yapacak kadar küçük mü? İyi yazılmış öyküler olmadan (ürün sahibi de dahil olmak üzere tüm geliştirme ekibinin hatası), ekibin iyi bir tahmin yapması beklenemez.

Sorun kötü retrospektifler ile daha da artmaktadır.

Yanlış yaptığınız, görünüşe göre, retrospektiflerden faydalanmadığınızdır. Bu sorunu çözmeden 18 ay geçtiniz, bu yüzden takım sorunu fark etmiyor veya retrospektiflerinde ele almıyor.

Her retrospektif, bir sonraki sprintte daha iyisini yapabilmek için ekibin yapması gereken en az bir eylem öğesiyle bitiyor mu? Her retrospektif, yapılıp yapılmadıklarını ve etkili olup olmadıklarını görmek için önceki süratten gelen eylem öğeleri hakkında konuşmayı içeriyor mu?

Çözüm suçu yerleştirmek değil, öğrenmektir

İlk adım, suçu aramayı bırakmak ve bunun yerine takımı geliştirmek için çalışmaya başlamak olmalıdır. Takımınız muhtemelen beceriksiz değil, sadece tahmin ve planlamada kötü. Takımı bir sprint bitirmeye zorlayın, bu tek bir hikaye seçtikleri ve bir hafta erken bitirdikleri anlamına gelse bile. Bunu yapamıyorlarsa, o zaman ya yetersizler ya da hikayeler çok karmaşık. Bu sorunun cevabı açık olmalıdır.

Bir hikayeyi bitirebildiklerinde, bir sprint içinde X miktarında hikaye puanı yapabileceklerini kesin olarak bilecekler. Basit matematik, daha fazla hikaye yapıp yapamayacakları sorusuna cevap verecektir.

Sürekli iyileştirme çözümdür

Bir hikayeyi bir sprint içinde bitirdikten sonra, iki yapıp yapamayacaklarını görme zamanı geldi. Köpürtün, durulayın, tekrarlayın. Sprint hedeflerini başarısızlığa başladıklarında, tahmin kabiliyetlerinin sınırlarını buldunuz. Önceki hikayenin hikayesi noktalarının sayısına geri dönün ve bir süre buna devam edin.

Her zaman, retrospektifleri ciddiye alın. Bir sprint bitirmedilerse, nedenini anlayın ve üzerinde hareket edin. Çok fazla bilinmeyenleri var mıydı? Yanlış becerilere sahipler mi? Tahminleri ne kadar iyiydi? Eğer bir hikayeyi X puan olarak tahmin ettilerse, X puanına değer priory hikayeleri olarak göreceli olarak eşit miktarda çalışma gerektiriyor mu? Değilse, ileriye dönük hikayelerin noktalarını ayarlamak için bunu kullanın.

"Retrospektif kullan" diyorsun. Peki ekip bu retrospektiflerde aslında ne yapıyor? Sürecin bir aşamasına değinmeden 18 ay geçtiğinden, cevabın şu olduğunu düşünüyorum: Çok yararlı bir şey değil.

Bana göre, retrospektif, sürecin en önemli parçasıdır. İstediğiniz her şeyden vazgeçmekle ilgili herhangi bir şey atmak veya değiştirmek (geçmişe bakıldığında ekibin karşılıklı anlaşmasıyla), ancak sürecin herkes için nasıl çalıştığını, neyin işe yaradığını ve ne yaptığını paylaşmak için düzenli olarak zaman ayırmayı taahhüt edin. Çalışmak ve geliştirmek için fikir önermek. Her sprint sürecinizi yavaş yavaş geliştirmeye çalışın ve er ya da geç, oldukça iyi çalışan bir şeye sahip olabilirsiniz.

Senin durumunda, bu işlem çalışmıyor gibi görünüyor. Sprint hedeflerine ulaşılmadığından, bunun neden böyle olduğuna odaklanmanın temkinli olduğu kesin. Açıkçası, takım sprint için çok fazla iş aldı. Ama bunu neden yaptılar?

• Çalışmanın karmaşıklığını hafife aldılar mı?
• Yönetim, ekibin başa çıkabileceğini düşündüğünden daha fazla iş üstlenmeleri için baskı yaptı mı?
• Planlanan çalışmayı tamamlamaktan kaynakları alan çok fazla kesinti / acil durum var mıydı?
• Çalışmanın tamamlanmasını geciktiren darboğazlar yaşadılar mı (örneğin, harici bir tasarım ekibinden varlık beklemek)?
• Ve hatta: Bir ya da daha fazla ekip üyesi bu işi hiç yapamayacak mıydı?

Bunlar, son 18 aydır takımın her sprint serisine kendilerine sorması gereken sorular. Ardından, cevaplarla donanmış olarak, bir sonraki sürat denemesi için önerilen süreç iyileştirmeleri önerebilirler. Bunlar şunları içerebilir:

• Bir sonraki sprintte daha az çalışın (hah!)
• Tahminlerde daha muhafazakar olun
• Bize kim atmak için daha fazla iş yapmak için baskı yaptığını söyleyin, çünkü şu anda başarabileceğimizden daha fazlasını üstleniyoruz.
• Kaçınılmaz acil durumlara uyum sağlamak için kesintileri daha iyi yönetin ve bir sonraki sprint'teki iş miktarını ayarlayın
• Darboğazları düzeltin veya kaçınamayacağınız şeyleri planlayın
• Onları başaramayan ekip üyelerine hikayeler atamayın (ve ayrıca, düşük performans gösteren bir ekip üyesi ile bir durumdan eğitim ve mentorluktan işten çıkarmaya kadar olan bir durumu ele almak için yönetimin verdiği cevabı bulmayın)

Geçtiğimiz 18 ay boyunca her sprintte gerçekleşmesi gereken konuşma türü bu. Bu, takıma baskı yapmak veya daha fazla kaynak eklemekle ilgili değil, retrospektiflerinizi prosesinizi sürekli olarak geliştirmek için kullanmakla ilgili. Bu açıkça burada gerçekleşmiyor.

Kaçırılmış golleri olan 15. sprint ile takımın bunu geriye dönük olarak pek çok kez tartıştığını düşünürdünüz, sadece bir tane tamamlama uğruna mümkün olan en düşük sprint hedeflerini almaya karar verdikleri noktaya kadar. 25. tamamlanmamış sprint ile, sadece tek bir dize değişikliği ve başka hiçbir şey ile bir sprint yaparım. Eğer takım bunu bir sprintte başaramazsa, sorunlar beklediğinizden daha da kötüdür.

Açıkçası, buradaki birkaç kişinin daha önce belirttiği gibi, sprint hedefleri, demir taahhütleri değil tahminlerdir ve eksik hedefler, yanlış tahminlerde bulunmaktan başka bir şeyin göstergesi değildir. Harika bir takım tonlarca golü kaçırabilir, çünkü kötü tahmincilerdir, korkunç bir takım her birini karşılayabilir ve gerçek bir değer sunmaz. Ancak tahminleriniz arka arkaya 18 ay boyunca aynı yönde yanlışsa, işleminizin bu kısmı çalışmaz. İşlemi düzeltmek için geçmişe dönük görüşlerinizi kullanın, böylece tahminleriniz, ekibin her bir sprintin ne verebileceğinin gerçek gerçeğine oldukça yakın.

"yazılım bittiğinde yapılır, daha erken değil, daha sonra."

Bu doğrudur, ancak geliştiricilerin üzerinde çalışmaya başladığı her görev için, kuruluşunuzdaki herkes her iş için Tamamlanan Tanımını anlıyor mu?

En büyük sorunlarınızdan birinin Tahmin olduğu anlaşılıyor , ancak geliştiriciler yalnızca açık ve net bir şekilde belirlenmiş bir “tanım tanımı” yaptıklarında gerçekçi bir tahmin sağlayabilirler. (Bu, şirket işlem sorunlarını içerir - örneğin kullanıcı belgeleri, resmi sürümdeki çalışma paketleri vb.)

Çoğu geliştiricinin bir görevi tamamlamak için gereken süreyi tahmin etmenin, sorulmasının en zor olduğunu düşündüğü göz önüne alındığında, aşırı tahminin soruna neden olması şaşırtıcı değildir.

Bununla birlikte, çoğu geliştirici, belirli bir süre boyunca harcayabilecekleri çaba konusunda makul ( iyimser de olsa ) bir işlem yapma eğilimindedir .

Sorun genellikle, geliştiricilerin bir görev ile eksik bilgilerle uğraşırken gereken toplam çaba miktarı arasında bir ilişki oluşturmakta zorlanıyor olmalarıdır - özellikle de gerçekten çok büyük bir görevin önündeki tüm cevapları bulmaya zorlanırlarsa .

Bu, doğal olarak zaman tahminlerinin gerçeklikle bağlantısının kopmasına neden oluyor ve yapım süreci ve kullanıcı dokümantasyonu gibi şeyleri gözden kaçırıyorlar.

Bağlantı kesme, görev tanımlandığında en baştan başlama eğilimindedir; ve genellikle gerekli çaba miktarına dair hiçbir ipucu olmadan bir ihtiyaç listesi oluşturan teknik olmayan bir kişi tarafından birleştirilir.

Bazen üst yönetimdeki insanlar görevleri belirler ve şirketin süreç sorunlarını tamamen görmezden gelir; Üst düzey yönetimin, testleri tanımlamak, resmi yayınlanmış bir yapı oluşturmak veya bir kullanıcı belgesini güncellemek için zaman veya çaba harcamadan sihirli bir şekilde gerçekleştiğini düşünmesi nadir değildir. gereklidir.

Bazen bir geliştirici kod satırı yazmadan önce projeler başarısız olur, çünkü birileri bir yerde işlerini doğru yapmıyor.

Geliştirme ekibi şartları kabul etme veya kabul kriterlerini yakalamada yer almıyorsa, bu yönetimin bir başarısızlığıdır - çünkü bu, kodu ve teknik sorunları tam olarak anlamayan birinin işi tamamlanmamış bir gereklilikler dizisine adadığı anlamına gelir; ve projeyi yanlış yorumlamaya, kapsam sürünmesine, altın kaplamaya vb. açık bıraktı.

Geliştirme ekibi yakalama ve gereksinimleri kabul katılan, o zaman ayrıntıları (ve kabul kriterlerini netleştirilmesi sorumludur ekibin, bir başarısız olabilir - "? Dağıtılabilir görünüm gibi olan neyi yani yapılır ?" ). Geliştirme ekibi aynı zamanda başka engelleyici sorunların olduğu durumlarda veya bir gereklilik gerçekçi olmadığı takdirde HAYIR demekten de sorumludur .

Yani geliştiriciler gereksinimleri yakalamada yer alıyorsa:

• Ekip, yapılan gereksinimleri / tanımları netleştirmek için ürün yöneticisiyle görüşme şansına sahip mi?
• Ekip, ima edilen / üstlenilen gereksinimleri netleştirmek için yeterli sorular soruyor mu? Bu sorular ne sıklıkla tatmin edici bir şekilde cevaplanmaktadır?
• Ekip , bir tahminde bulunmadan önce Kabul kriterlerini (yapılan tanımı) talep ediyor mu?
• Kabul kriterleri genellikle her görev için ne kadar iyi ele geçirilir? Çok az ayrıntı içeren belirsiz bir belge mi yoksa somut işlevselliği ve geliştiricinin açıkça testten geçebileceğini ifade eden somut ifadeler mi?

Şansınız, ekibinizin verimliliğinin bir sorun olmaması; Ekibiniz büyük olasılıkla , gelişim konusunda harcayabilecekleri her türlü çabayı gösteriyor. Gerçek sorunlarınız aşağıdakilerden biri veya birkaçı olabilir:

• Eksik ve belirsiz şartlar.
• Öncelikle çok büyük olan ihtiyaçlar / görevler.
• Geliştirme ekibi ve üst yönetim arasında zayıf iletişim.
• Görevler takıma verilmeden önce açıkça tanımlanmış bir kabul kriterleri eksikliği.
• Kabul testlerinin eksik veya belirsiz / belirsiz şartnamesi. (yani Bittiğin Tanımı)
• Kabul kriterlerini tanımlamak / kabul etmek için ayrılan zaman yetersiz.
• Geliştiriciler, mevcut temel kodu test etmek veya mevcut hataları düzeltmek için zaman düşünmediler
• Geliştiriciler mevcut temel kodu sınamış , ancak gereksinimler hakkında tahminlerde bulunmadan önce hataları Engelleme Sorunları olarak gündeme getirmemişlerdir.
• Yönetim sorunları / hataları gördü ve yeni kod yazmadan önce hataların düzeltilmesi gerekmediğine karar verdi.
• Geliştiriciler zamanlarının% 100'ünü hesaba katma baskısı altındadır, ancak zamanlarının% 20'sini (veya bazı benzer sayılarını) muhtemelen toplantılar, dikkat dağıtıcılar, e-postalar, vb.
• Tahminler gerçek değerde kabul edilir ve hiç kimse hata veya beklenmedik durum için odayı ayarlamaz (örn. "Bunun 5 gün sürmesi gerektiğine karar verdik, bu yüzden 8'de yapılmasını bekleyeceğiz").
• Tahminler herkes tarafından (geliştiriciler ve yönetim) gerçekçi bir "aralık" sayıları yerine tek sayılar olarak ele alınır - yani
  • En iyi durum tahmini
  • Gerçekçi tahmin
  • En kötü durum tahmini

... liste bundan daha uzun sürebilir.

Bazı "gerçekleri bulma" yapmanız ve tahminlerin tam olarak neden gerçekçilikten kopuk olduğunu anlamanız gerekiyor. Mevcut temel yazılım kötü mü? Birim test kapsamı yok mu? Geliştiricileriniz yönetim ile iletişimden kaçınıyor mu? Yönetim, geliştiricilerle iletişimden kaçınıyor mu? “Bitti'nin Tanımı” söz konusu olduğunda, yönetim beklentileri ile geliştirici beklentileri arasında bir kopukluk var mı ?

Takımı yeniden başlatmak için tavsiyem, takım başına, sprint başına mümkün olan en küçük hikayeyi seçmek ve bir hikayeyi ve sadece bir hikayeyi tamamlamak!

Diğer afişlerle aynı fikirdeyim, ya takım yetersiz ya da çok fazla şey yapmaya çalışıyorlar.

En küçük şeylerle, en aşağılık hikayeleriyle başlayın ve tek bir koşuyu tamamlayın. Takımın bir sprint bitirmesini ve başarılı olmasını sağlayın; zamanlarını ve iş taahhütlerini nasıl önceliklendirdiklerini görmelerine yardımcı olacaktır. Zamanla, ekip en yüksek üretkenliklerini elde edene kadar daha fazla iş üstlenebilecek.

Veri toplamalı ve geçmiş performansa dayalı güven düzeyleri oluşturmalısınız.

http://www.leadingagile.com/2013/07/agile-health-metrics-for-predictability/

En basit örnek, her iki haftada bir olduğu gibi sürekli zaman sprintleridir. Takımın iki hafta içinde ne kadar hikaye puanı bitireceğini tahmin edin. Sonra iki hafta sprint bittikten sonra, gerçekte kaç tane hikaye puanının tamamlandığını görün. Zamanla, 15 puan tahmin edebileceğinizi görebilirsiniz, ancak sadece 10 bitirdiniz. Bu basit durumda, sürat başına yalnızca 10 puan planlamanız için bir hız ayarıyla ilerlemeye başlayabilirsiniz. Ya da tahmini işlerin% 66'sını bitirmeyi planladığınızı.

Standart sapmalarla güven seviyeleri oluşturarak yönetime söyleyebilirsiniz: mevcut proje hedeflerine göre 3 haftada bitirebileceğimiz% 50 güven, 5 haftada bitirebileceğimiz% 95 güven.

Çevik ve Scrum'un ardındaki fikir, işleminizi ölçebilmeniz için sıkı bir geribildirim döngüsü oluşturmaktır. "Bu nerede bozuldu?" Diye sormalısınız, çünkü tamamen parçalanmış gibi görünüyor.

1. Ne yapacağınızı planlayın ve listesini yapın
   • Bu, tamamlanması gereken maddelerden oluşan bir birikimden öğe seçmekten ibaret olmalıdır. Sprint için yapılacaklar listesine bir şey girmeden önce, ekibin tam olarak anladıklarını ve kabaca bir sprintin tamamlanmasından daha az zaman alacağını tahmin etmeleri gerektiğini kabul etmeleri gerekir.
   • İdeal olarak, birikim öncelik sırasına göre (işletmeye göre) sıralanır ve öncelik sırasına göre sıralayabilirsiniz.
   • Biriktirme listesindeki öğeler çok büyükse, bunları daha küçük parçalara bölün. Ardından, parçaları bir veya daha az günde tamamlanabilecek bireysel görevlere bölün.
   • Bu planlamanın kolay veya hızlı olmasını beklemeyin.
2. Listedeki öğelerde belirli bir süre boyunca yürütme (bir sprint)
3. Başardıklarını gözden geçir
   • Hangi hikayeler bitti?
   • Hiçbir hikaye bitmediyse, öyküleri oluşturan görevleri tamamladı mı?
   • Eğer hiçbir iş bitmediyse, geçen pazartesi herkes tam olarak ne yaptı? Geçen salı ?, vb. - bu noktada, şiddetli iç gözlem yapma zamanı ...

4. Sorunları giderin (geri bildirimleri analiz edin ve uyarlayın)

   • Tamamlanan işler ne kadar sürdü?
   • Hangi görevlerin tamamlanmasını engelledi?
   • Ekip üyeleri hikayeleri (özellikleri) 1 gün veya daha kısa sürede tamamlanabilecek görevlere ayırıyor mu? Değilse, bunu yapın ve yapılacaklar listesinin bir parçası yapın.
   • Sprint sırasında görev listesinde veya görev listesindeki öğelerde hangi değişiklikler yapıldı? Bu bitmemenin bir nedeni miydi? Öyleyse, listeyi veya özellikleri değiştirmeyin. İstenilen özelliği kararlı olana kadar biriktirin.
   • Birkaç öğenin boyutunu ve kapsamını sprint içinde bitebilecek bir şeye nasıl azaltabilirsiniz? Günlük iyileştirme, basit bir hata düzeltme, yazım hatası gibi minik bir şey seçin, sadece ekibin yapabileceklerini ölçmesini sağlamak için bazı şeyleri bitirin. Bunu yapamıyorsanız, sprint yapmayı bırakın ve yeniden planlayın .

5. Birinci adıma geri dönün ve bırakılana kadar tekrarlayın ...

Belgelendirme engelleri var mı, birleşme problemleri bağımlılık yaratıyor mu, iletişim sorunları mı, gereksinimlerde yeterince bilgi yok mu? ... Ne? Geliştiriciler zamanlarını yeni teknolojiler öğrenmek için harcadılar mı? Tasarımda çok fazla zaman harcadılar mı? Öğrenme gibi şeyler sprint görev listesinde sayılıyor muydu?

Takımınızın sorunlarını her retrospektif olarak izole ettiklerini düşünüyor musunuz? Takım sorunları düzeltmek için harekete geçti. Ekip yanıt vermedi ve yönetim basitçe çözümleri ve eylem planını dikte etti mi?

Uzun zaman dilimi göz önüne alındığında, bir şey sadece geliştiriciler ile değil, sistematik olarak yanlış. (Saldırı ustası dahil) takımında birisi (yılda kadar önce) Bir noktada sormalıydın, ne kadar küçük, ne, olabilir biz başarmak?

Senin durumunda retrospektifler çok geç.
Günlük stand-up toplantıları düzenliyor musunuz ve önceki 24 saat içinde yaptıkları hakkında insanlardan gerçekten durum alıyor musunuz?
Scrum ustası bu toplantıları her geliştiricinin hedeflerine göre ilerlemesini ölçmek için kullanıyor mu?
İlerlemenizi ilerleyişini izlemek için bu Scrum metodolojisinin bir parçasını kullanmanız gerekir. İnsanların yaptıkları hakkında size iyi bir fikir vermelidir.
Dikkatleri dağılmış mı? Kahveye veya SE / SO’daki diğer insanlara yardım etmek, haber okumak veya muhasebeleştirilmemiş teftişler yapmak için çok fazla zaman harcamak? Yoksa gerçekten baş aşağı, tam buhar ileri ve tamamen aşırı kararlı mı? Günlük görüş size iyi bir fikir vermeli. Aynı zamanda devlerin görevdeki görevlerini sürdürmelerine yardımcı olacak, bu yüzden dün hiçbir şey yapmadıklarını kabul etmek zorunda kalmayacaklar.
Ve elbette, sprint boyunca istikrarlı bir ilerleme kaydettikleri ve hala teslim etmedikleri takdirde, yalan söylüyorlardı ve yeni bir geliştirici için zaman olabilir.

Programlama kodu gibi karmaşık bir görevi tamamlamak için gereken çabayı ve zamanı tahmin etmek zordur. As Joel Spolsky koyar:

Yazılım geliştiriciler zamanlamayı yapmaktan hoşlanmazlar. Genellikle, bir olmadan kaçmaya çalışırlar. “Bu yapıldığında yapılacak!” Diyorlar ki, böyle cesur, komik bir zencinin patronlarını kıkırdayarak azaltacağını ve bundan sonraki neşelilikte programın unutulacağını umuyorlar.

Ancak, şirketlerin faaliyet gösterebilmeleri için son tarihlere ihtiyaçları var. Joel'in önerdiği gibi, yönetimin herhangi bir risk türü ile ilgili olabileceği muhtemel olasılıkla zaman tahminleri verecek Kanıta Dayalı Planlama'yı kullanmayı deneyin .

Scrum birkaç şey yapar.

İlk olarak, önceliklendirmeyi teşvik eder. İşin tedarikçisi ilk önce ne yapmak istediklerini söylemek zorundadır ve “her şey eşit derecede önemlidir” dememelidir.

İkincisi, her şey bitmediyse bile biraz kullanışlı ürün üretir. Her yinelemenin sonunda "potansiyel olarak satılabilir bir ürüne" sahip olmanın anlamı budur.

Üçüncüsü, daha sıkı bir geri besleme döngüsü veriyor. Bir sprint sonunda işlerin "yapılması" konusunda ısrar ederek, "% 90 özellik tamamlandı, ancak yarı yol yapıldı" probleminden kaçınıyorsunuz; son teslim tarihlerini zorlarken, bir kenara yapılması gerekenleri kestirebilirsiniz, böylece son teslim tarihine neredeyse yaklaşıyormuş gibi görünüyorsunuz ya da sahte olabilirsiniz. Bir tanımı tanımlayarak ve yapılan işlerde ısrar ederek, bir şeyin daha sonra göründüğünden daha zor olup olmadığını bilirsiniz.

Dahası, ayrıntılı planlama işini yapmak için yakınlaştırarak stoktan kaçınır. Uzaktaki şeyleri planlamak bir envanter şeklidir: müşterilerin satışına ya da derhal kullanması mümkün olmayan kaynaklara harcanan sermaye. Bu tür envanter çürümeye başlayabilir (planlar ayaktayken değişebilir, yeni bilgiler kullanılmaz hale gelir), ihtiyaçlarla yanlış hizalama (ne olursa olsun dağıtılmış bir ağa ihtiyacımız yok, çünkü onu kullanan şey buna değmez) ve gönderilen malların değerini düşürebilir (son bir yılda, zamanınızın yarısı gelecek yıl ve ötesi için planlamaya harcandıysa, şu anda hazır olmak için bir şeyler yapmaya çalıştıysanız, iki kat daha fazla sevk almış olabilirsiniz). Kayıpsız (zor!) Planlamayı uygulamaya daha yakına götürebilirseniz, envanteri azaltabilirsiniz.

Bu sorunları çözmenin tek yolu bu değil. Geliştiricilerin her bir süre boyunca üzerinde çalışacakları bir çalışma akışı sağladığı, periyodik olarak yapılacak yeni işler ekleyerek ve ilerlemenin kontrol edildiği scrum kullanıyor gibi görünüyorsunuz.

Bu, scrum-esque desenlerini kullanmanın faydalı bir yoludur. İş akışını sürdürür, üretime yakın planlama yapmayı sürdürür, bazı geri besleme döngüleri vb. Sağlar. Sistemin eşleşmesi için geliştirme ve test işlemlerinin çözülmemesi gibi avantajları vardır (testin en iyi şekilde yapılması en iyi şekilde yapılırsa iş biter) , aynı sprint içinde işlerin bitip test edilmesini sağlamak, sprintin arka ucunu yeni gelişmeyi içermemeye zorlar!)

Tam olarak ne yapacaklarını bir sprint içine koyamamak, geliştiricilerinizin iyi bir iş yapmadığının kanıtı değildir. Bu, SCRUM'u en üst seviyeden takip etmedikleri, bunun yerine çerçevenin parçalarını kullandıkları anlamına gelir.

Her bir sprint için ne kadar taahhüt ettiklerini yarıya indirdilerse (veya çeyrekleştirdilerse), ama her şeyi aynı tuttularsa, o zaman her sprint için yaptıklarından daha fazlasını bitirmiş olacaklardı! Aynı miktarda kod ürettiniz. Açıkçası "sprint başarısızlıkları" önemli bir parça değil, çünkü bu sadece bir iç süreç detayı. Şirketin amacı, işleri halletmek ve bu işleri iyi yapmak; Belirli bir süreci takip etmemek, amacınız belli bir ISO süreç belgelendirmesi değilse.

Süreç, yapılan işlerin amacına bağlı olarak mevcuttur.

Onlar Scrum'un kurala uymayan, çünkü Öte yandan, aynı almıyorsanız tür geribildirim. Üretilen hataların, SCRUM'un başa çıkmak için tasarlandığı kusurlar olup olmadığını görmek için ortaya çıkan hususları incelemelisiniz; Sonsuza dek zombiler gibi yaşayan ve sadece geç saatlerde öldürülen hikayeler var mı? Kolay görünen hikayeler var mı, patlıyorlar ve geçmişe bakıldığında toplam çalışmaya değmez mi? Ürün, ihtiyaç duyduğunuz / sevk etmek istediğiniz zamanlarda gerçekten gönderilebilir mi?

"Yazılım bittiğinde yapılır, daha sonra, daha sonra olmaz" ifadesi, "yapılan" ifadenin neye benzediğini tanımlamazsanız, başarısızlık için bir reçetedir.

Mühendislerin çoğu mümkün olan en iyi çözümü üretmeye çalışacak, ancak bu, özellikle daha az deneyimli mühendislerle kolayca altın kaplanmasına yol açabilir. Sadece yönetimin sorumlulukları hedeftir tam olarak nerede tanımlamak ve bu yönde ilerliyor Mühendislerinize tutmak için vardır. Mühendisler, özellikleri geliştirmek için sık sık yan dönüşler yapmaya çalışacaklar ve bu yan dönüşün işleri uzun vadede hızlandırıp hızlandırmayacağına ya da sadece iyileştirme için iyileştirip iyileştirmeyeceğine karar vermek yönetimin sorumluluğunda.

Çevik gelişimin amacı, her yeni iş parçasının o sprint ile buluşmak için gerektiği kadar iyi olması gerektiği ve DAHA İYİ OLMAMASI !!!!!! Evet, StackOverflow'a ekleyebileceğim en fazla vurgu ile ilgili - ve hala yeterli vurgu yok. İnsanların tam bu anda gerekli olmayan şeyleri eklediğini tespit ederseniz , çevik gelişimi nasıl doğru yapacakları konusunda eğitime ihtiyaçları vardır.

Ve evet, retrospektifleri kullanıyoruz.

Güzel, peki takımının neden başarısız olduğunu biliyorsun ? Neyin işe yarayıp yaramadığı hakkında konuşmak için 36 fırsatınız oldu, bu yüzden scrum ustaları sorunları nasıl çözeceklerini tam olarak anlamalı, değil mi?

Verdiğiniz açıklama ile şirketinizin "SCRUM bizi üretken kılan" zihniyetine girdiğine dair bir fikrim var. Gerçek şu ki, SCRUM üretken yapmaz. Daha ziyade, akıllı hale getirebilmemiz için bir araçtır kendinizi sık sık hem yönetim ve geliştiriciler tarafından göz ardı edilir gelişim gerçekleri tanımlayan bir şekilde üretken.

Scrum ustası ekiple ilgili potansiyel sorunlar olarak neyi tanımladı? Devamlı olarak iki kat daha fazla iş mi veriyorlar? Eğer öyleyse, scrum ustası nazikçe daha az çalışmayı öneriyor olmalı, çünkü scrum ustası takımın hızına bakabiliyor.

Geliştiricinin kalitesinde problemi aramak ne zaman adil olur?

Geliştiricilerin niteliğinde bir problemi aramanın zamanı, sorunun ne olduğundan emin olduğunuz andır. Bu, SCRUM tarafından oluşturulan yeni bir konu değil. Bu işin gerçeğidir. SCRUM , ekip üyelerinizin yetenekleri hakkında geleneksel yaklaşımlardan çok daha fazla bilgi vermelidir . Sorunun "yazılım geliştiriciler yeterince iyi değil" değil "yönetim beklentilerinin gerçekçi olmadığını" bilmelisiniz, geleneksel bir yaklaşımla anlayacağınızdan çok daha iyi. Bu, yönetimin en iyi yaptığı şeyi yapma zamanıdır: iş için doğru kişileri belirleyin, böylece şirket para kazanabilir. Sorunun nerede olduğunu söyleyemiyorsanız, tüm bu retrospektifler olmadan anlatmanın ne kadar zor olduğunu hayal edin!

İnsanların yeterince iyi olabileceğini düşünüyorsanız (işe alımlarını göstermek yönetimin tarafında bir hata değildir), tavsiyem kutunun dışında düşünmeye başlamak olacaktır. İş yapılmıyorsa, geliştiricilere yönelik çalışmanın şeklini değiştirmeyi düşünün. Sprint tamamlama tarihlerini sonlandırmamın en kolay yollarından biri DONE kriterlerini ayarlamaktır, böylece ne olursa olsun sonuçtan memnun kalacaksınız. Böylece tamamlanmak bir totoloji haline gelir.

Bu, yönetimi, özellikle SCRUM master'ı yönetir. İşin püf noktası, eğer tamamlanmışsa, çok değerli olan işler yazmaktır, ancak eksik bırakılırsa, maaşlarını almaya değecek kadar şirkete katma değer sağlamaya devam eder. 18 ay sonra retrospektiflerinin size bir şey öğretmesini beklerdim. Olmamışsa, belki de şirketinizde yanlış olan bir şeyi açığa vurarak ve onu aydınlatacak şekilde başarısız hikayelerin açıkça niyeti olan hikayeleri yazmalısınız. Bu, şirkete geliştirme ekibinde ne kadar sıkıntı yarattığı göz önüne alındığında, şirkete çok büyük miktarda değerli veriler sağlayacaktır. İstediğiniz gibi sorun gerçekten geliştiriciler olabilir. Veya sorun, şu ana kadar hakkında hiçbir fikrinizin olmadığı şirketin zihniyetinde bir patoloji olabilir!

Sorun gerçekten şirkete aitse, geliştiricilere değil, bu eksik hikayelerden topladığınız bilgiler gerçekten de başarılı olanlardan topladığınız üründen daha değerli olabilir! Tüm şirketinizi kurtaran bilgi olabilir! Bu bana gerçekten değerli bir bilgi gibi görünüyor ve SCRUM'u toplamanıza yardımcı olacak bir araç olarak kullanabilirsiniz.

“Geliştiricilerin kalitesine bakmak ne zaman adil olur?”

Her zaman. Açıkçası, bazı insanlar diğerlerinden daha üretken, performanslarını ölçmek için işverenleri olarak bir bahaneye ihtiyacınız yok.

İşin en zor yanı bunu nasıl yaptığındır. Benim tavsiyem, izinli personelinizin yanına çalışmak için bazı tecrübeli müteahhitleri işe almaktır.

Bu, sizi uzun vadeli bir işe almaya zorlamadan mevcut pazarla iyi bir karşılaştırma yapmanıza yardımcı olacaktır.

Ayrıca perma adamları biraz kıç tekmeleyebilir.

Ek olarak, müteahhitlerin hız kazanmak için kaliteden vb. Geçmediklerinden şikayet ediyorlarsa, bu işletme değerinin nerede olduğu hakkında bir konuşma yapacaktır. Uzun vadeli bakım veya kısa vadeli ürünler sevk edilir.

Eğer uzun vadeli şeyler ise, o zaman sizi nicelemelisiniz ve koşullandırmaya istekli olarak koyun!

Zaten birkaç mükemmel cevap var. Özellikle, kötü tahmin, fazla bağlılık ve / veya programlanmamış iş, kaymanın sık nedenleridir.

Ancak neden "[]] geliştiricilerinizin her bir sprint içine eklemek istedikleri özellikleri seçtiklerini" merak ediyorum. Geliştiriciler tipik olarak ilk önce en yüksek önceliğe sahip özellikler üzerinde çalışmalıdır - ve öncelik bir iş kararıdır, yani işletme paydaşları için bir vekil olarak hareket eden ürün sahibinden gelmelidir.
(Bunun istisnaları vardır. Özellikle yüksek riskli özellikler genellikle daha önce işe yarar. Bazı durumlarda kullanıcının karşılaştığı bir özellik diğer işlevlere bağlı olabilir, örneğin "X'i uygulamaya koymadan önce gerçekten bir veritabanı eklememiz gerekir". )

Diğer yandan, tahminler teknik kararlardır ve iş adamları tarafından yapılmamalıdır (ya da ikinci tahmin). Bununla ilgili hiçbir şey söylemiyorsunuz - Ben sadece şunu anlıyorum: çünkü deneyimlerime göre, geliştiriciler neyin üzerinde çalışacağını seçerken, iş adamlarının ne kadar sürmesi gerektiğini belirlemeye çalışmaları oldukça yaygın.

Oldukça işlevsiz bir sürecin var gibi gözüküyor. En azından şu an için geliştirici danışmanları getirmemeyi tavsiye ederim, çünkü bu muhtemelen moral üzerinde olumsuz bir etki yaratacaktır. Ancak, kuruluşunuzun proje yönetimi tarafında bazı yardımlar kullanabileceği anlaşılıyor. Deneyimli çevik bir koçu getirerek başlayacağım yer burası - orta veya uzun vadeli bir ilişki olmasa bile en azından bir değerlendirme veya "sağlık kontrolü" için. İyi bir antrenör, düşük performans gösteren geliştiricilere sahipseniz size söyleyecektir, ama en azından bu şekilde, inceleme altındaki tüm ekip (sadece geliştiriciler değil).

Bir diğer gözlem: Tecrübelerime göre, eğer iyi gelişim süreçlerini takip etmiyorsanız, proje yönetimi metodolojisi olarak başarıya ulaşmak çok zor. Otomatik birim testi yapıyor musunuz? veya daha da iyisi, otomatik kabul testi? Cihazınız eşleşiyor mu, yoksa en azından sıklıkla kod incelemeleri ve / veya izlenecek adımlar atıyor musunuz? Bir çeşit sürekli entegrasyon mu yapıyorsunuz?