Birçok Scrum kitabı ve makalesi başarısız bir sprintin (takım Sprint İş Listesi'ndeki bazı özellikleri tamamlayamadığında) kötü bir şey olmadığını, zaman zaman bunun gerçekleştiğini ve takımın hatalarından ders çıkarması gerçekten yararlı olabileceğini söylüyor. ve aşağıdaki sprintlerde bir şeyi geliştirir. Ve takım, taahhüt ettiği işi tamamlamadığı için cezalandırılmamalıdır.
Bu tür bir davranışı "cezalandırma" şekliniz, bitirmeyenlerin bir sonraki adımda üstlenebilecekleri iş miktarını sınırlamaktır. Güzel şeyler üzerinde çalışma şansı kayboluyor. İyi iş yapmanın ödülü daha fazla iştir.
Bu, geliştiricinin bakış açısından harika görünüyor, ancak ciddi müşteriler için ("Money-Bags Corporation") bir şeyler geliştiren bir yazılım şirketimiz "Scrum-Addicts LLC" olduğunu varsayalım:
Scrum-Addicts yöneticileri Money-Bags için bir yazılım hazırlamayı öneriyorlar. Özellik listesi üzerinde hemfikirler ve Money-Bags nakliye tarihi vermeyi istiyor Scrum-Addicts yöneticileri kendi scrum ekibine danışıyor ve ekip 3 hafta süreceğini söylüyor Scrum-Addicts yöneticisi tüm özellikleri tamamlamak için uzun süren sprints, güvenli olması için 1 hafta ekler, yazılımı 1 ay içinde göndermeyi vaat eder ve 4 sprintten sonra (gönderim son tarihi) Scrum ekibi sadece% 80 teslim edebilir. özelliklerin (yeni sistemdeki deneyimsizlik nedeniyle, üretim ortamındaki önceki özelliklerde kritik hataların giderilmesi, vb.) Scrum’un önerdiği gibi, bu noktada, ürünün potansiyel olarak nakliyesi mümkün, ancak Money-Bags’in% 100’e ihtiyacı var Sözleşmede belirtildiği gibi özelliklerin. Yani sözleşmeyi çiğniyorlar ve hiçbir şey ödemiyorlar.
Scrum-Addicts, iflasın eşiğinde, çünkü Money-Bags'ten para alamadılar ve yatırımcılar sonuçlardan hayal kırıklığına uğradılar ve şirkete daha fazla yardımcı olmak istemiyorlardı.
Pazartesi günü perşembe günü yağmur yağacağı için 100 dolar yatırırsanız ve cumaya kadar yağmur yağmazsa paramı almaya hak kazanırsınız. Kumar oynamak için bir şans yerine, istediğin bir hava tahmini ise, Salı günü size güncellenmiş bir tahmin vermeme izin veren bir sözleşmeye ihtiyacımız var.
Açıkçası, hiçbir yazılım şirketi Scrum-Addicts'in yerinde olmak istemiyor. Çevik ve Scrum hakkında anlamadığım şey ise, ekiplerin yukarıda açıklanan durumdan kaçınmak için planlama ve son tarihlerle başa çıkmaları gerektiğini nasıl önerdikleridir.
NEDEN MB toplarını alıp eve gitmek istiyor. MB, işin başlangıçta bir ay içinde yapılmasını istemedi. SA, bir ayda kritik özelliklerin% 100'ünü vaat etti ve teslim etmedi. SA, son tarihi MB değil. SA bile keyfi bir şekilde son tarihe bir hafta ekledi. Peki bu neden son tarih?
Ara sıra iş yazılımları için rekabet eden şirketler, ayları gösterme ve vaat etme eğiliminde olurlar. Profesyoneller, ayın gerekli olup olmadığını dikkatlice belirler. MoneyBags için en kritik ihtiyaç hangisi? Bir ay içinde özelliklerin veya çalışan bir ürünün% 100'ü? Neyin kritik olduğunu bile biliyorlar mı? Zor bir tarih belirleyen yaklaşan bir etkinlik var mı?
Scrum-Addicts bu sözleşmeyi müzakere etseydim, Money-Bag iş ihtiyaçları hakkında daha fazla bilgi edinmek ve sözleşmeyi Money-Bags'in rahat olduğu kadar esneklik sağlayacak şekilde yapılandırmak isterdim. Onlara çevik sürecin nasıl çalıştığını öğretirdim, böylece bizden ne bekleyeceklerini bilirler.
Bu şekilde, her şeyin bir ay içinde aniden mükemmel bir şekilde çalışmasını beklemek yerine, 1-2 hafta içinde ilk teslim edilebilir ürünü değerlendirmeyi beklerlerdi.
Özetlemek gerekirse 2 sorum var:
Kimi suçluyor? Yöneticiler, çünkü doğru planlamayı yapmak onların işidir
Ekip, çünkü bir
başkasının yapabileceğinden daha fazla iş yapmaya karar verdiler.
Yoldan bir ay geçmeden herkes bu travestiyi durdurabilirdi.
Sahte olarak bir şelale sürecini açıkça temsil eden bir ekibi işe almak için Money-Bags Corp'u suçlamaya kadar gidebilirim. Sözleşmenin kendisi bunun çevik olmadığını açıkça ortaya koyuyor. Bir ayda yapılması planlanan şey çevik yapmıyor.
Çevik olduğu konusunda ısrar ediyorsanız, bir ay süren tek bir sprint ile çevik. Hangi, evet, tavsiye etmem çünkü bu yine şelale ile aynı şey.
Ne Yapmalı?
Çevik? Her sprint bir şey sunmak? Son başvuru tarihinden önce geri bildirim almak? Hafta boyunca sprint? Son teslim tarihinin saklanmak ve dua etmek yerine tehlikede olduğunu düşündüğünüz andan itibaren draconian sözleşmesini yeniden müzakere etmeye ne dersiniz? En azından bir lanetli projede zaman kaybetmeyi bırakabilir ve daha makul bir müşteri bulabilirsiniz.
Yöneticiler, son tarihi asıl takımın tahmininden 2x (veya 3x) kez daha geçmelidir.
Son tarih çarpanları saatinizi 15 dakika erken ayarlamak kadar faydalıdır, bu nedenle asla geç kalmazsınız. Neyin peşinde olduğunu fark etmeden önce kendini ancak çok kandırabilirsin.
Erken tahminler yanlıştır. Ne kadar yanlış olduğunu yakalamaya çalış. 5 hafta verin veya birkaç hafta alın, tamamlanma tarihinin gerçekte ne kadar belirsiz olduğunu açıklamanızı sağlayan basit bir ifadedir. Doğru tahmin etmeye çalışmak yerine, tahmininizin ne kadar vahşi olduğunu tahmin edersiniz. Bazı gerçek işler yapın ve gerçek veriler elde edin. Sonra daha dar bir aralıkta tahminler yapmaya başlayabilirsiniz. Bir ila iki hafta, bunu yapmak için bolca zaman var.
Ekip üyelerinin, ne olursa olsun (taahhüt edilen sprintler için cezalar vererek), taahhüt ettikleri tüm işleri yapmaya teşvik edilmesi gerekir.
Takım üyeleri teşvik edilmelidir. Başarısız, taahhüt veya başka türlü. Cezalar veya hatta ikramiye (havuç ve çubuk) çalışmaları gibi herhangi bir yapay sonuç oluşturmak yerine, programlama gibi yaratıcı işler yapan insanların üç şey sağlanmışsa en iyi yanıt verdiklerini göstermiştir: Özerklik, Ustalık ve Amaç.
Daniel Pink'in bununla ilgili TED konuşması var. Konuşma, çevik değil motivasyonla ilgili ancak bu noktaları çevik olarak nasıl eşleştireceğimi kolayca gördüm:
Özerklik - Kendi hayatımı idare etmek istiyorum - Biriktirmeden iş seçmeme izin ver.
Ustalık - Önemli olan bir şeyde daha iyi olmak istiyorum - Müşteri geri bildirimi.
Amaç - Kendimden daha büyük bir şeyin parçası olmak istiyorum - İşbirlikçi bir ekip.
Ekip, Scrum'u düşürmeli, çünkü şirketin son tarih politikasına uymuyor Scrum, şelaleden daha doğru bir tarihe varabilir. Bir son tarih verildiğinde bununla karşılaşabilirsin Zamana, özelliğe ve yeteneğe bağlı olarak 47 özellikten yalnızca bir tanesiyle buluşabilir, ancak bunu karşılayabilir.
Çevik bir proje öylesine son derece şık bir şekilde tasarlanabilir ki, ekip eve giderken her gece gemiye hazır olur. Gönderinin müşteriden geri bildirim almasını ve test etmesini istediğini düşünmüyorsanız bu aptalca görünüyor. Ne kadar erken olursa, o kadar çabuk ayarlamalar yapabilirsiniz. Bu her olası son tarihi vurur. Sadece her özellik değil. Ama sizi önemli özelliklere yönlendirir.
Hepimiz yazılım geliştirmeyi bırakmalı ve bir manastıra katılmalıyız.
Doğru, beni gerçek bir odadan uzakta bir odaya kilitlemek gibi, LESS kodu yazmamı sağlayacak.
Bu cevabı boyuta indirdim. Merak ediyorsanız düzenleme geçmişini okuyun.