Çevikliği İş Yerine Getirmenin Etkin Yolları?

Tecrübelerinize (anekdot veya başka türlü), Çevik'i Çevik olmayan bir organizasyon veya şirkete tanıtmanın etkili yolları nelerdir?

GÜNCELLEME: Herhangi biri Agile'yi tanıtmaya çalıştığınız ama "vurulduğunuz" durumlarla konuşabiliyor mu? Ayrıca, artık neden "vurulduğunuzu" geriye dönük anlıyor musunuz?

BT ZOR SÖZLEŞMEZ DEĞİLDİR. Tabii cennette yaşamadıkça. Yapabileceğiniz belirli adımlar için, tüm kalbimle Fearless Change'in bir kopyasını almanızı tavsiye ederim.

• İlk önce yönetim desteğini alın . Eğer hiçbir şey yapmazsanız bunun için telafi edersiniz .. Eğer üst düzey hepsi ise 'Son tarih dün ..', 'Gelecek 3 ay için hafta sonları çalışıyor' kodlama? .. sonra test edebiliriz. ' Dodo sadece uçmayacak.
• Kuruluşunuzun kültürünün çevikliğe uygun olup olmadığını görün . Bu benim özlediğim bir şeydi .. Kitaptan bir çizgi ödünç almak .. Kültür yeni fikirleri destekliyor ve besliyorsa, insanların yeni şeyler öğrenmesi ve yeni şeyler yapması için zaman verirse, yenilikleri destekleyecek kadar sabırlı olursa süreç daha kolay olacaktır. uzun vadeli faydalar ve ölüm cezası olarak kabul edilemez
• Halk : Yenilikçileri belirleme: erken evlat edinenler: erken çoğunluk: geç çoğunluk: gecikme oranı. İlk 3 hedef kitleniz başlangıçta ..% 30-40 civarında olmalı .. bu size yuvarlanma için kritik kütle veriyor. Sorun şu ki Çevik, odadaki filler üzerindeki spot ışığı yakıyor .. eksiklikler ve sorunlar kolayca görülebilir .. "Bozo Patlaması" olan bir yerde yaşıyorsanız (Guy Kawasaki'nin sözünü alıntılamak için) , değişiklik gerçekten olur yavaş ve acı verici .. eğer hiç. Bir fikir iyi olursa kabul edileceğini varsayma eğilimindeyiz. Doğru değil. Pek çok sosyolojik sebep kafalarını kaldırıyor.
• Sonra bir kerede çok fazla şey denemeyin. Yavaş ol .. sakin ol . İşin püf noktası, yeniden düzenleyici-eski-kod-benzeri bir yaklaşım kullanmaktır. Burada ve orada küçük yaralar bulun ve çevik bir bandajla düzeltin. İnsanların uygulamayı ve faydaları anladığından ve zaman içinde benimsemeleri gerektiğinden emin olun. Her şey yapışmayacak, ama yakında her şey daha iyi olacak. Bir süre sonra bazıları sizin kontrolünüz dışında olan bir dizi değişkene bağlıdır.
• Bunun gerçekleşmesi için çok büyük bir kişisel yatırım . Bu görevi yerine getirmeye istekli olup olmadığını ve getirdiği iniş çıkışları gözden geçirip geçirmediğinizi yeniden inceleyin. Ayrıca copu bir başkasına veya daha yükseğe teslim etmek zorunda kalabilirsiniz. Daha büyük bir iyilik için değişim mülkiyetinden vazgeçmeye hazır olun. 'Benim bebeğim' sendromuna girmeyin.
• Çevik, her ekip için farklı, her organizasyon .. Okuduğunuz / önerdiğiniz her şey işe yaramaz. Kabul edilmenize izin verin, senaryo için çalışacak şeyler hakkında sizi yönlendirin. Kök almayan uygulamaları telafi eden diğer yolları bulun.

Umarım bu mantıklı .. Tahmin ettiğiniz gibi bir süredir bu işteyim :)

Ekibi, yönetimi, paydaşları dinle ve ipuçlarını dinle. Agile'nin doğrudan ele aldığı bir çok alanda acı hissediyor olabilirler.

Bu ağrıları doğrudan giderebilecek önerilere bağlı kalın. "Hissedemeyeceğin şeyi iyileştiremezsin" - tabiri caizse.

Bu UZUN bir garip zaman alır, ancak güven inşa etmek çok önemlidir. Geçmişteki başarılar ve hem ekibinizin hem de yöneticinizin güvenini alarak, karar alma zamanı geldiğinde sizi arayacaklar.

İnsanları yazılım teslim etme biçimimizi değiştirmeye zorlamadaki yıllar süren hayal kırıklığından sonra kendi gözlerimle gerçekleştiğini gördüm. Ve şimdi başarılar kazanırken, tam olarak yakın bir yerde değilim. İyileştirme için TONS alan var ve şu anda hissettiğimiz bir ağrı tipine doğrudan yanıt veren küçük değişiklikler getirme konusunda en başarılıyım.

Son olarak, sadece çok empatik olun derdim. "XYZ çevik kitabı" nı okumamış olduğum için onlardan gerçekten bahsetmeden önce çoğu fikri reddetme hatasını yaptım. Ekibinizi dinlemek ve bazı önerilerini uygulamaya çalışmak çok uzun sürecek.

İyi şanslar!

Teknik atlanması, kuruluş içinde Çevik metodolojileri satın alabilecek ve 'test yatağı' sağlayabilecek bir grup bulmanın çok önemli olduğunu bulduk. Şirketimizde farklı Çevik terminolojiyi anlamayan, terimler ve süreçlerle karıştırılan birçok insan vardı ve genel korku vardı.

Araştırma grubum Scrum'un çalışmasını sağlamakla ilgilendi (diğer birçok Çevik tip metodolojisiyle birlikte). İlgi alanımız, çeşitli unsurları denemek için şirket içinde bir test yatağı oluşturmamızı sağladı. İnsanlarla ilk koridorda konuşma, şirket yöneticileri için sunumlar vb. Dersleri verdik. Çok zorlamadık - eğitim aldık. Sonra sadece grubumuzla denemek için izin istedik.

İkili programlama, teste dayalı geliştirme, Scrum, vb. Gibi şeylerin zamandan nasıl tasarruf sağlayabileceğini gösteren empiracally bir çok cevap olacak ama günün sonunda ispatın şirketinizden gelmesi gerektiğini hissediyorum. Test yatağı olarak kullanabileceğiniz bir grup bulun ve bunu gerçekten yapmalarını sağlayın. Hiçbir şey korkuları, grubunuzun bunu gerçekleştirdiğini göstermekten daha fazla iyileştiremez.

Boğazlarından aşağı doğru itin, ancak fark etmeden;)

Son 6 aydır, iş yerime yavaşça çevik prensipler (çoğunlukla scrum) uygulamaya çalışıyordum. Önce herkes için alışması gereken günlük stand up'ları tanıttım, ancak gayet iyi çalışıyor. Hepimiz tek bir sistemin parçası olan farklı programlar üzerinde çalıştığımız için, tanımı gereği azarlamak biraz zor. Bir sonraki adım, bültenlerimizi takip etmek için sprint toplantıları başlatmak. Zaten bir aydır süren bir döngüden geçiyoruz, bu yüzden sürat uzunluğu bir sorun değil. Ayrıca bir sonraki büyük projemizde tam anlamıyla aşağıdaki prensipleri takip etmeyi planlıyorum. Proje için takımdaki iki geliştiriciden biriyim ve sürekli gelişim için çalışıyor. Umarım, yönetim başarmaya çalıştığım şeyin faydalarını görecektir.

Bence anahtar yavaşlatmak. Yıllarca aynı pozisyonda olan insanlar genellikle müdahaleci değişime karşıdır, ancak parça parça gizlice sokabilirseniz, farketmemeleri gerekir. İlk başta küçük sık toplantılarla başlayın. Onları kısa tutarak, yönetim bunu zamanın boşa harcaması olarak görmemelidir.

Test odaklı geliştirme. Birim testlerinin cihazınızı nasıl hızlandıracağını göstermek. eşzamanlı olarak kodu daha kararlı hale getirirken geçen süre çevik Kool-Aid içmeye doğru atılmış büyük bir adımdır.

İlk önce kendini geliştir. Gerçekten mi. Örnek çevik hakkında konuşmanın güçlü yoludur. Üstelik, daha önce söylediği gibi, teknik tanımlardan kaçının ve sadece yöneticilerin ve yönetici kişilerin anlayabileceği terimleri kullanın. Sprint yerine iki hafta; Sprint Planlama veya Planlama Oyunu yerine Planlama; Ürün Sahibi yerine Ürün Müdürü vb. Michele Sliger , Waterfall Şirketinde Agile hakkında harika bir sunum yaptı . Gerçekten bir video görmek gerekir. Çevik evlat edinme ile ilgili başka videolarla da ilginizi çekebilir .

Çalıştığım yerde, Scrum'un çevikliği başlatmak için iyi bir yol olduğunu öğrendim çünkü yönetim bunu hızlı bir şekilde anlıyor. Çok basit ve güzel bir isim. İkincisi, Retrospektifleri yaparken, XP uygulamalarını iyileştirmeler olarak önerebilir ve insanların en azından denemelerini kabul etmesi oldukça kolay olacaktır.

Saygılarımla

2 haftalık sprint olarak 'Bakım' görevlerimize (böcekler, düşük etkili değişiklikler vb.) Dahil ettik. Bu yüzden uzun vadeli projeler üzerinde çalışan geliştiriciler olduğu gibi kaldı, ancak dönen bir Bakım sprintimiz vardı. Böylece herkes büyük projeleri aksatmazken yanma çizelgeleri ve poker tahminlerini kullanmaya başladı.

Sonra her büyük proje sona erdiğinde, bir sonraki projeye çevik 2 haftalık sprint'ler kullanarak başladık. Bütün bu süreç herkesin izlerini sürmesi birkaç ay sürdü, ancak bu daha az aksaklık olduğu anlamına geliyordu ve herkes sürecin içinde 'kolaylaşabilirdi'

Geliştirme ekibi içinde, Agile'yi tanıtmak, üzerinde bir miktar kontrolünüz olan bir şeydir.

Ancak, asıl meselenin, Agile'nin "müşteri" veya müşteri temsilcinizden sürekli geri bildirim talep etmesinin gerekliliği olduğunu görüyorum.

Bu nedenle, doğrudan gelişim ekibinizin dışındakiler için bir şeylerin eğitim yönüne odaklanmanız gerekir, çünkü çalışma biçimlerini bir şekilde değiştirmeleri gerekebilir (örneğin geliştirme ekibiyle daha çok iletişim kurun).

Söylememin en iyi yolu, Çevik bir süreçte yer almanın temel faydalarına odaklanmak ve bunları açıkça müşterinize iletmektir. Elbette şirketinizde bir satış / hesap alanınız varsa, aynısı burada da geçerlidir.

1. Adım: Projenizin bir bekarlığa veda birikmesine sahip olduğundan emin olun ve önceliklendirildiğinden emin olun

Adım 2: SCRUM uygulamalarını tanıtın (yönetilebilir yinelemeler, günlük gösterimler, scrum-master, ürün sahibi, yazma çizelgeleri)

Adım 3: Her bir yinelemede takım sonuçları yakma ile sonuçlanır

o zaman ...
TDD / BDD'yi uygulayın, programlamayı eşleştirin, kod incelemelerini (çok nazikçe) yapın ve yeterince iyi bir ekibiniz varsa herkesi bir araya getirin (mümkünse bir ekip odası).

Her şeyden önce, direnç olacağını anlayın (WILL BE), bu yüzden bunu yönetmeye hazır olun.

Hatırlanması gereken bir başka şey de, bir bütün olarak bu en iyi uygulamaları izlemeyecek bir organizasyonun (büyük veya küçük) bir parçası olmanız durumunda, o zaman ilerleme kaydetmiş gibi hissetmeniz biraz zaman alabilir.

İnsanlar her zaman değişime karşı dirençlidir ve pisliğe geçmek oldukça büyük bir şeydir. Motivasyon ve yön anahtardır.

İlk adım, insanları korkutmak için bir şans vermek için motive etmektir. Ken Schwaber'in Google Tech Talk’unun , insanların iyi bir giriş yaparken, scrum’un yararlarını tanımalarında çok faydalı olduğunu buldum . Geliştiriciler veya yöneticiler olsunlar, değişime açık olacağını düşündüğünüz insanlarla başlayın, böylece bir ivme kazanabilirsiniz. Sizin tarafınızdan yöneticileri almak bir noktada bir zorunluluk olacak, ama bununla nasıl başa çıkacağınız ortamınıza bağlıdır.

Bundan sonra, bir kitap okumak ya da bir konferans dizisine sahip olmak anlamına gelen herkesin eğitilmesi gerekir. İnsanlar bu işin nasıl yürüdüğünü bilmiyorsa, süreci uygulamaya başlayamazsınız.

İnsanlar motive olduklarında ve ne yapmaları gerektiğine dair bir fikir edindikten sonra, ilk planlama toplantınızı yapmanız ve gerekli scrum bölümlerini ayarlamanız gerekir (scrummaster, günlük toplantılar, vs.).

İlk planlama toplantısının sorunsuz geçmeyeceğini ve herkes için bir öğrenme deneyimi olacağını bekliyorum. Ayrıca ilk birkaç sprint çok kayalık olacak ve muhtemelen programın gerisinde kalacak. Şimdi ana bölüm disiplin ve sebat. Günlük toplantıların çok uzun sürmesine izin vermeyin, planlama toplantılarını görevde tutun ve herkesin rollerini doğru bir şekilde yerine getirdiğinden emin olun.

Bence en dirençli olan insanlar uzun süredir yazılım geliştirme yapan insanlar ya da daha önce yanlış bir şey yaptıklarını itiraf ettiklerini düşünen insanlar. Bu üstesinden gelmek için zor bir engel, ancak onlara yavaşça ikna edebileceğiniz faydaları göstererek düşünüyorum. Sadece zaman alıyor. Tecrübelerime göre, ürün yöneticileri gerçekten dirençlidir çünkü onları ihtiyaçları ve istedikleri konusunda daha net olmaya zorlar. Ancak, çevik sürecin onlara nasıl fayda sağladığını gördüklerinde ve hayatlarını kolaylaştırdıklarında gemiye oldukça hızlı bir şekilde girebiliyorlar.

İyi şanslar!

• Başarıyı gösterin - Mark'ın cevabını görün
• Şirkette en yüksek etkiye neden olabilecek ilke / tekniklere özellikle dikkat edin.
• Unutmayın, çevik prensipler ile ilgili bir işlem kontrol listesi değil.

Çevik gelişimi tanıtmayı düşünmeden önce, ilk önce kuruluşunuza / projenize en uygun olanı keşfedin. Mesela, eğer scrum'a bakıyorsanız, onu katı bir şekilde mi kullanacağınızı veya daha gevşek bir scrum şekli veya tamamen bir başka yöntemin daha iyi bir seçim yapabileceğini düşünün. Cevabım o zaman çevik yönteminiz olarak ispiyonlamada.

Scrum, yenilik gerektiren, çok az şey bilinen ve denemenin gerekli olduğu projeler için mükemmeldir. Mevcut ürünleri korumak veya tekrarlayan bakım işlerini yapmak gibi şeyleri yapmak için en uygun yöntem değildir. Neyse ki, scrum gevşek bir çerçeve ve mümkün olan en iyi şekilde kullanabilirsiniz.

Bakım çalışmaları için Kanban sizin için daha iyi olabilir veya sprint'i yönetmek ve günlük standuplar gibi şeyler yapmak için sadece birkaç scrum unsuru deneyebilirsiniz. Ben buna "aldatmaca" diyorum, "evet, şirketimizde aldatmaca yapıyoruz ama ...". Sorun değil, bu konuda kötü hissetme.

Kuruluşunuzda uygun scrum tanıtmak için ürün sahibi ve pay sahibinin katılımı gerekir. Küçük bir şirketseniz, bu adam bir kişi, patron ve daha büyük bir ürün yöneticisi ve bölüm başkanı / patron olabilir. Scrum'u tanıtmak için iki yol önerebilirim:

1) mevcut iş sıralarını hemen yönetmek için scrum'u biraz daha gevşek bir biçimde kullanmaya başlayabilirsiniz. Fakat Kanban'a da bakın.

2) yenilik, erken geri bildirim gerektiren ve bilinmeyen yerlerde yeni projeler üzerinde daha katı bir biçimde scrum kullanmaya başlayın. Patron / ürün sahibine bu yeni proje için scrum'un ideal olacağını önerebilirsiniz.

Ama hatırla! bu sadece kodla ilgili değildir, ürün sahibinin çok önemli bir kısmı vardır ve rolünü anlamak ve yerine getirmek zorundadır. Bu, örneğin tüm özellikleri önceden yazmamak, asgari, hızlı yinelemeden başlamak, geri bildirim almak, tekrar tekrar öğrenmek, öğrenmek ve beslemek anlamına gelir. Sizin gibi ancak ürün sahibi tarafından titizlikle tanışmak isteyen bir ürün müdürü ile çalışmaya çalışın ve ideal olarak yönetim taleplerini karşılayacak ve sprinti koruyacak kadar sert olmalıdır.

Geliştirme ve ürün yönetiminden scrum'a kadar birleşik bir çaba gösterecektir.

Böyle yeni bir projede, yeni ekibin ayrı bir odaya taşınmasını sağlayın ve iş haberi gibi çeşitli eyaletlerde yapılan çalışmaları görselleştirmek için post-it notlarını kullanın. Bu aşamada elektronik araçlara tıkılmayın. , işleri olabildiğince basit tutun. Sen de başlarken kartları ile poker planlama aptal hissetmiyorum, ekibiniz hızlanınca muhtemelen muhtemelen sadece sayıları söylemek olmaz.

Tecrübelerime göre, scrum'u saf bir forma sokmak daha kolaydır, daha sonra daha fazla bakım türü iş sırası için kolaylaştırır. Diğer taraftan daha zordur.

Son yorumum, düşüncesizlikten kaçınmaktır, çünkü gelişme biraz derde deva, öyle değil. Scrum, ürün inovasyonu için kullanışlı ve basit bir çerçevedir, ancak işletmenizin gerektirdiği şekilde birleşen diğer yöntemleri keşfedin ve bu konuda kötü hissetmeyin.

Birkaç yıl önce, birçok büyük kurumsal yazılım projesi yürüten çok büyük bir şirkette (yaklaşık 20.000 çalışan) danışmanlık yaptım. Ben onlardan biriydim. Oldukça kritik olanı.

Pek çok sorunla karşılaştık ve baskı bizi geliştirme ekibine şiddetle bastırdı. Sorunlar sadece yazılım endüstrisinde yaygındı, ancak yönetim daha altyapıya dayalı bir deneyime ve çok az yazılım odaklı deneyime sahipti. Yani her şey bize odaklandı. Yönetime Scrum'u anlatmanın iyi bir fikir olacağını düşündüm.

Güçlü bir isteksizlikle karşı karşıya kaldım, bu yüzden bir süreliğine fikri bıraktım. Ancak takım liderinin sponsoru ile sorunlar artmaya devam etti, sonunda bizzat Scrum yapmaya karar verdik.

Ben de dahil olmak üzere herkes Scrum'la ilgili herhangi bir deneyime sahipti. Böylece çerçeveyi keşfederek keşfettik ...

Bugün, Scrum, sertifikalı bir eğitmen tarafından yönetilen bir program aracılığıyla tüm işletmeye yaygınlaştırılmaktadır. Girişimin tetikleyici olup olmadığını bilmiyorum. Bu, bunun oldukça katı bir şirkette gerçek bir devrim olduğunu biliyorum.

Böyle bir işletmeye bir şey getirmeyi düşünüyorum, aşağıdaki ilkelere saygı göstermelisiniz:

• Değişmesi gerekiyor . Değişimin yapılması için zorunlu bir neden yoksa, yönetim ekiplerinin risk almak için neden bir sebepleri yoktur.

• Biz gereken yönetim sorunlarına odaklanmak onlar yönetim kaygıları parçası olmadıkça geliştiricilerin sorunlarını söz değil. Başka bir deyişle, onlar için bir çözüm bulmalısınız, sizin için değil. Kendini yönetimin yerine koy. Endişeleri neler?

• Tüm organizasyonu bir kerede değiştirmeyi teklif etmemelisiniz . Sorumluluğu üstleneceğiniz bir pilot proje önermelisiniz. Projede ne olup bittiğinin görünürlüğünde gözle görülür artış gibi gerçekçi hedefler vermenizi öneririm. Bu, IMHO, Scrum'un yazılım yönetimine ana katkısıdır. İnsan sağduyularının çalışmasını ve böylece ilerlemesini sağlar.

• Son olarak, deneyimli kişilerin bu girişin kontrolünü elinde bulundurması şarttır . Sadece bir ya da iki kitap okumayın. Eğitime gitmelisin ve deneyimli bir koç kullanmanın oldukça gerekli olduğunu söyleyebilirim. Açıkçası, olmadan yapılabilir, ama acı çekecek :)

Prensipleri izler ve gerçeklerle gelirseniz, işe yarayacaktır. Gerçekler hakkında, 30 Günde Yazılım kitabında birçoğunu bulacaksınız : Çevik Yöneticiler Nasıl Değer Kazanıyor, Müşterilerini Terk Ediyor ve Rakipleri Tozda Bırakıyor . Scrum'ın yaratıcıları Ken Schwaber ve Jeff Sutherland'ın son kitabı .

Ken'in kitapla ilgili bir blog yazısında okuyabilirsiniz:

Jeff Sutherland ve ben yaptık. 1995'te Scrum'un ilk yayınlanmasından bu yana ilk ortak yazımız olan bir kitabı birlikte yazdık. Ne bizi yönlendirdi? Sıkça sorulan soru:

Scrum'ı yönetimimize nasıl satarız?

Ben her zaman bu sorudan şaşırdım. Neden daha fazla öngörülebilirlik, üretkenlik, kalite, değer, risk kontrolü, memnun müşteriler, çalışanlar ve yönetimdeki herkese daha az atık satmak zorunda kalıyorsunuz? Ancak Jeff'le konuştum ve dumanın olduğu yerde yangın olması gerektiğini düşündük.

2011 yılının son yarısını kitabı yazarak geçirdik. Yukarıdan aşağıya herhangi bir yönetici bu kitabı kolayca alabilir ve okuyabilir.

[...]

Her zaman görüyoruz. (tam açıklama: Bir proje yönetimi uygulaması geliştiriyorum). Sorun, çevik metodolojilerin geleneksel olarak yönetilen organizasyonlara doğal bir gerilim getirmesidir. Genellikle, üst yönetimler önceden plan yapabilmek istiyor. 3 yıllık planlar istiyorlar; uygun bir şekilde tahmin edilen projeler istiyorlar; yeni insanları işe almak için bütçe yapabilmek istiyorlar; İş ortakları / müşterileri söz konusu olduğunda önemli kilometre taşlarına bağlı kalabilmek istiyorlar.

Ancak Ar-Ge departmanı çevik olacağına karar verdi. Artık kod yazmadan önce iki ay boyunca planlama yapmak artık mümkün değil. Sprintler kısa sürecek ve sprintlerin ötesinde olacak şekilde, backlog / roadmap'teki öğelerin çok düşük çözünürlüklü tahminlerini alacaksınız. AR-GE, ihtiyaçların klasik şelalenin etkili olması için çok sık değiştiğini fark etse de, ürün yöneticileri ürünün 12 ay içinde nasıl görüneceği konusunda net, düşünülmüş ve iyi bütçeli bir vizyon istiyor.

O zaman sorun, ikisini uzlaştırmaktır. Dediğim gibi, bunu müşterilerimizle birlikte her zaman görüyoruz. Bu nedenle çözümümüz hem sprint hem de uzun vadeli planlama yapmak için kullanılan araçları birleştirmek. Tamam, şimdi burada utanmaz tapanın bir parçası geliyor, bu yüzden onu bir tuz tuzu ile almaktan çekinmeyin. Eşsiz özelliklerimizden biri, görevleri yönetmek için yakınlaştırılabilir bir kullanıcı arayüzü kullanmamızdır. Yani, bazı kullanıcı öykülerini / görevlerini incelemek ve üzerinde çalışmak çok kolaydır. ( Burada nasıl göründüğünü görebilirsiniz ). Aslında sistemimizde “proje” kavramı yoktur. Diğer görevleri içeren, diğer görevlere (fraktal, gerçekten) bağlanan tüm görevler. Bu, kullanıcı hikayeleri, görevler, projeler, destanlar vb. Arasında hoş bir bulanıklık yaratır.

Pratikte, çevik metodolojileri uygulayan kullanıcılarımızın çoğunun yaptığı, kısa vadeli sprintleri (veya yinelemeleri) yöneterek uzun vadeli yol haritasını (veya birikimini) birleştiren teleskopik bir plan oluşturmaktır. Yöneticiler hala eklenmeyi bekleyen ana özelliklerin güzel, tahmini bir yol haritasını görmekte ve geliştiriciler daha derinlemesine yakınlaştırmakta ve gerçek işlerle uğraşmaktadır. Bunun bir avantajı, yöneticiler çalışma planını gözden geçirirken gerçekleşen "pazarlık" miktarını azaltmasıdır. Yalnızca çok kaba tahminler veren geliştirme ekibi (yani “4-6 hafta!”) Yerine, söz konusu her kullanıcı hikayesini büyütme ve daha küçük parçalara ayırma şansı elde ediyorlar. Bunu yaptığınızda pazarlık etmek için aniden daha az yer kalıyor. 10 haftalık bir 5 haftalık kullanıcı hikayesini yaklaşık 1 günlük boyutta parçalara ayırıyorsanız, ve aniden bu argüman "hayır, daha hızlı yapabilirsiniz. hayır yapamayız. evet yapabilirsin." değildir. Fakat "işte ilk tahminin göz önünde bulundurmadığı tüm gizli işler de dahil olmak üzere bu çabaya ne gidiyor? Neyi ortadan kaldırmamızı öneriyorsunuz? Kalite güvencesi mi? Test etmek mi? Yeni adamı eğitmek? Yapı ortamını kurmak?".

Bu yaklaşım, başlangıçta taslak oluşturduğunuz kadar kısa sürede planları değiştirmenize izin veren bir araç kullandığınız sürece çalışır. Bugünlerde insanların şelalenin bozulmasından asıl nedeni budur. Çoğu sistem, mevcut planları tamamen yeniden yapmayı son derece zorlaştırıyor ve insanlar rasyonel olarak bu faaliyet için zaman harcamayı reddediyorlar.

Tamam, bunun bir satış perdesine dönüştüğünü hissediyorum, bu yüzden şimdi duracağım. :)