Son başvuru tarihleri ​​çevik mi?

Netlik için son tarih:

Bir zaman sınırı veya son tarih, bir amaç veya görevin yerine getirilmesi gereken dar bir zaman alanı veya belirli bir zaman noktasıdır.

^{Gönderen wikipedia}

Bütün yazılım geliştirme kariyerim, her yerde en azından aşağıdaki uygulamalara uyulduğu anlamına gelen "Çevik" yapıyorum:

• Haftalık veya İki Haftalık sprintler
• Retrospektifler Sprint planlaması
• Bir ürün sahibi
• Saldırı, itişip kakışma, itip kakma, çarpışma, hamle
• Kullanıcı hikayeleri

Ancak, şimdiye kadar yürüttüğüm her proje bir son tarih belirleme konusunda ısrar etti. Çevik'in uyarlanabilir planlama, esneklik ve değişime odaklanma girişimleri göz önüne alındığında; Son başvuru tarihleri ​​nedir?

Kendi görüşüme göre, esneklik ve kalite eksikliğine yol açan son başvuru tarihlerini gördüğüm gibi olmadıkları. Bunun yerine, Sprint'lere ve erken teslimatlara odaklanmanın daha fazla değer sağlayacağını düşünüyorum. Bununla birlikte, içinde bulunduğum her dairede, durum böyle değil ve son başvuruların Çevik gelişim ile el ele gittiği görülüyor.

Son teslim tarihleri ​​bir gerçektir. Çoğu zaman belli bir tarihe göre bir şeye sahip olmalısınız . Kaçınılmaz. Son tarihler olmadan, çevik projeler bile Parkinson Yasasına katılabilir :

İş, tamamlanması için gereken zamanı dolduracak şekilde genişler.

Diğer bir deyişle, proje eğer olabilir sonsuza kadar devam, olacak.

Süreler ile ilgili olarak, Agile birkaç şey yapmaya çalışır:

• Son başvuru tarihine kadar ne kadar çalışacağını herkesin daima görebildiğinden emin olun
• İlk önce en önemli özelliklerin tamamlandığından emin olun
• Tamamlanan özelliklerin, henüz tamamlanmamış özelliklere bağlı olmadıklarından, kullanılabilir olduklarından emin olun.
• Kalkınmanın sürdürülebilir bir hızla devam etmesini sağlamak

Bu şekilde, kaçınılmaz bir gün geldiğinde, işe yaramaz bir kod desteniz yoktur, ancak umarım, tamamlanmamış, sadece en az önemli şeylerle çalışan, test edilmiş bir ürününüz olur. Ve bitmiş üründen kimse şaşırmaz.

Yani evet. "Çevik" ve "son tarihler" tamamen uyumlu olabilir.

Son tarihler yaşamın bir gerçeğidir. Çok kesin bir tarihi olan şeyler var.

Comdex tarafından yazılıma ihtiyacımız var

veya

Oyunlar, Kara Cuma'ya kadar mağaza raflarında olmalı

ve benzerleri. Kişi Comdex veya Black Friday ertelemez - dünyanın geri kalanı bu şekilde çalışmaz.

Agile'nin hedefi, son tarihi karşılamayan şeylerin daha hızlı başarısız olması (ve bu iyi bir şey) veya kapsamın daha sonra tekrar incelenebilmesi, böylece kaynakların doğru yatırım getirisine odaklanabilmesidir. daha zamanında

Son tarih kesin olarak belirlenmiş zor bir tarih. Çevik, yazılımın, umduğu gibi gelişmesi için iki kat daha uzun sürdüğü bir döngüde daha erken fark edilmesini sağlayan bir araçtır. Proje yöneticilerinin bu sorunları daha sonra başarabilmesi için daha fazla kaynak eklenmesi, kapsamın değiştirilmesi, son tarihin ayarlanması (son derece sağlam bir son tarih yerine firma gibi bir durumda olması durumunda) veya proje için önemlidir. iptal edildi.

Agile'nin aradığı şeffaflık sorunları daha önce gösterme ve döngünün ilerleyişinde. Klasik şelale teslimat hatası, kapalı kapılar ardında aylar geçirdiğiniz ve ürünü son teslim tarihinden bir hafta önce teslim ettiğiniz ve yanlış yaptığınız ve ayları boşa harcadığınız (ve şimdi son teslim tarihini tamamen boşa harcadığınız) . Diğer klasik şelale başarısızlığı, son birkaç ayın geçmesi gereken süreden bir hafta önce ortaya çıkıyor. Çevik, bu sorunları sürecin başlarında duyurmaya çalışır.

Agile'nin son tarih bağlamında yapmak istediği bir diğer kısmı, üzerinde anlaşılan özelliklerin sadece bir kısmı tamamlanmış olsa bile (ne nedenle olursa olsun), yazılımın mevcut sürümünün kullanışlı ve konuşlandırılabilir olmasıdır.

Tamam, 15 Nisan’da vergi yazılımının konuşlandırılması için istediğimiz her şeyi kaçırdık, ancak geçen ayın başından beri% 75’e sahibiz ve yaptıklarımız çalışıyor ve çalışıyor. Aralık ortasından bu yana ayarlanan özelliklerin tamamını kullanamayacağımızı biliyorduk ve çabalarımızı müşteri tabanının% 80'i üzerine odakladık.

Bazı tarihler karşılanmalıdır. Sözleşme yükümlülükleri, sözleşmeler, yasal gereklilikler. Bazıları, yazılım geliştirmeyi elektronik tablolarındaki üretim çizelgesine yerleştirmek isteyen yöneticiler tarafından empoze edilir. Sebep ne olursa olsun, çoğu insan onlardan uzak kalamaz.

İşleyen bir ekipte çalışıyorsanız, geliştiriciler ve yönetim / paydaşlar arasındaki iletişim, bir karar vermesi gereken kişilerin, son tarihin eksik veya gelişime devam edip etmemesi gerektiğine karar vermek için iyi bilgilendirilmesi anlamına gelir.

Tamamlanmış kullanıcı öykülerini haftada bir veya ayda iki kez yayınlıyor olsanız bile, muhtemelen son teslim tarihlerine sahip olacaksınız. Biri yaklaşırken, paydaşlarınızın son teslim tarihine ne kadar uyacağını düşündüğünüzden emin olun ve beklentileri belirleyin.

Sürekli olarak her aşamada sahip olduğunuz gereksinimlerle yapabileceğiniz en iyi yazılımı oluşturuyorsanız, sprintin sonunda bir son tarih teorik olarak bir sorun olmamalıdır. Pratik olarak, bu normal bir durum değildir, ancak o zaman ne de ince havadan çıkan tarihler değildir. Şimdiye kadar verdiğim en önemli son tarihler çoktan önce bana iletildi, kalitenin beklentisi ve sorun olan özelliklerdi.

Kaçırılmaması durumunda hiçbir sonucu olmayan rastgele son tarihler çok çevik değildir, ancak geliştirme ekibinin dışındaki kontrol nedenlerinin son tarihlerinin belirlenmesi ve saklanması gereken durumlar vardır. Neyse ki, son tarihler makul ise denklemi ters çevirmenin ve son süreleri Çevik bir şekilde ele almanın birçok yolu vardır.

Son teslim tarihleri ​​her zaman yanlış değildir. Hepimizin Obi-Wan'dan öğrendiği gibi:

"Sadece Sith mutlak işlerle uğraşıyor"

Çoğu durumda son başvuru tarihlerinin aptal, gereksiz ve kesinlikle Çevik olmadığını söylemek doğru olur, ancak bunun her zaman böyle olduğunu söylemek aptalca olur. Architypal davası, seçim takip yazılımı gibi zamana duyarlı bir kullanım için gerekli bir yazılımdır. Yazılım seçim için zamanında hazır olmazsa, seçimi ertelemek mantıklı veya pratik olmazdı ve sadece 'Üzgünüz, çok uzun sürdüğümüze benziyor gibi görünmek için müşteri odaklı görünmüyor. Bize ödediğiniz bu yazılımın tamamen değersiz olduğunu biliyorum, ancak son tarihler Çevik değil, onlarla tanışmadığımız için bize karşı gerçekten nasıl tutarsınız?

Müşterilerinize zamana duyarlı bir şey istemek için itirazlarını söylemek çok çevik değildir ve günün sonunda birileri bu şeyleri inşa etmek zorunda kalacak. Öyleyse müşterileri nasıl mutlu edebiliriz ve zamana duyarlı şeylere görünüşte makul görünen çözümler sunabiliriz? Peki, yazılım geliştirmek belirsiz bir zaman alıyorsa ve son tarih değişken değilse, başka bir şeyin belirsizliği çözmesi için değişken olması gerekir ...

Teslim tarihi sabit tutulursa, başka bir yönü değişken olur.Hepimizin bildiği gibi, yazılım projelerinde büyük miktarda belirsizlik olabilir. Projenizde başarılı olmak istiyorsanız ve genellikle bu teslim tarihi ise, bu belirsizliğe cevaben bir şeyler değişken yapılmalıdır. Zaten yeterince doğal görünüyor. Ama bu senin tek seçeneğin değil. Zor bir son teslim tarihine bağlı kalmanız durumunda, bunu yapmanın yolu, sunulan özellikleri değişken hale getirmektir. Bir özellik listesine öncelik verin, o tarihe kadar sunulabilecek özelliklerin miktarında belirsizlik olduğunu açıkça belirtin. Bu özellikleri öncelik sırasına koymak için müşteri ile birlikte çalışın, böylece en önemlileri daha yüksek nakliye olasılığına sahip olur. Öyleyse, her zamanki gibi iş var, ancak son teslim süresi etrafınızda yuvarlandığında gönderilmeye hazır olanı gönderir. Bu modelde

Birisi bir son tarih belirlemek istiyorsa, bu iyi bir şeydir ve son tarih sabitlenebilir, ancak anlamaları gereken son tarih sabitse, kapsamın esnek kalması gerektiğidir.

tl; Dr.

İdeal bir dünyada son teslim tarihlerine sahip değiliz ve hazır olduklarında sadece bir şeyler teslim ederdik. Gerçek şu ki, insanların parasını ödedikleri insanlar genellikle ne zaman yapıldığını bilmek istiyorlar. Çevik metodolojiler bunu tanır ancak aynı zamanda her şeyin bağlanamayacağını da kabul eder.

Bu, teslimat kalitesini ürün için uygun seviyede tutabilmenizi sağlar. Son teslim tarihini ve kapsamını (ve bütçeyi) belirlerseniz işler daha da artar ve proje sonunda çılgınca bir çığır açan eski şelale dünyasına geri dönersiniz. Bütçeyi artırmak genellikle bir cevap değil çünkü daha fazla geliştirici ve testçi eklemek bir sorunu daha hızlı çözemiyor. Bu bir var tanınmış görünüm (ve deneyimlerinden ona katılmam) daha fazla kişi (kendi foibles ile her) Tek gereken daha fazla zaman ekleyin.

Şimdi, genellikle (gerçekten Çevik yöntemleri anlamadıkları sürece) yazılıma para ödeyen kişiye söylenmekten hoşlanmıyoruz, son tarihinizi karşılayabiliriz, ancak istediğiniz her şeyi yapamayız. Bu, yazılımı oluşturan özelliklere öncelik verilerek yönetilebilir. Önceliklendirme tartışmanız şöyle olabilir:

Dev Team (D): "Lütfen en önemlisi önce teslim edilmesini istediğiniz özelliklere öncelik verebilir misiniz?"

Müşteri (C): "Her şey öncelikli 1 - Gelecek ayın sonuna kadar hepsini yapmalarını istiyorum."

D : "Bu mümkün olabilir, ancak gereksinimler değişirse ya da geliştirme sürecinde beklediğimiz sorunları keşfedersek mümkün olmayabilir."

C: "Peki ya size daha fazla para verirsem?"

D: " iç çek ... daha fazla kaynak olsa bile, gerçekten gitmeleri bir ay sürecek; bu yüzden özelliklerin nasıl önceliklendirileceğinden emin değilseniz, sadece hangisini ilk önce yapmak istediğinizi bize söyleyin."

C: "Tamam, büyük düğmeyi istiyorum ama gerçekten büyük kıldım ve sonra ... etc"

Artık özellikler arasında öncelik sırasına göre çalışmaya başlayabilirsiniz. Daha fazla bilgiye sahip olduğunuzda gelişmeye başladığınızda bunları değiştirebileceğinizi bilerek, ekibinizle birlikte öncelik sırasına göre daha düşük olan maddelere göz atmanıza ve erken tahminlerde bulunmanıza yardımcı olur. Bu, henüz bir tane yoksa yol haritanızı yeniden tanımlamak veya oluşturmak için kullanılabilir. Bu, serbest bırakma planınızın temelini oluşturur. Yol haritası, müşterinin bu kapsamın değişebileceğini kabul etmesiyle tartışılabilir, ancak teslim edilecek bir siparişiniz var.

Agile'nin en büyük avantajlarından biri, gelişimden geçtikçe işlerin değiştiğini ve sizin de yaptığınız gibi uyum sağladığını kabul etmesidir. Daha geleneksel yaklaşımların aksine, bu ilke, düzenli sprint teslimatları ve müşteri ile devam eden iletişim ile birlikte, doğal olarak ilerleme konusunda daha şeffaf olmaya zorlandığınız anlamına gelir; bu iyi bir şeydir.

Bazen müşteri belirli bir tarihe göre istediklerini elde etmekten hoşlanmaz, ancak neden ve ne elde ettiklerini iyi kalitede anlarlar. Özellikler gönderildikten 6 ay sonra, müşteri belirli bir tarihe kadar teslim ettiğinizi umursamaz veya hatırlamaz, hala kullandıkları ürünün kalitesini hatırlar.

Son teslim tarihleri ​​geleneksel olarak iş yaşam döngüsüne dayanmaktadır. Vergi yazılımının 15 Nisan’da olması gerekiyor. Gelecek mali yıla ilişkin raporlamanın Temmuz ayına kadar yapılması gerekebilir.

Çevik manifesto durumları:

Prosesler ve araçlar üzerinde bireyler ve etkileşimler

Kapsamlı dokümantasyon üzerinden çalışan yazılım

Sözleşme müzakere konusunda müşteri işbirliği

Değişime Cevap Vermek Bir planı takip etmek

Son teslim tarihleri ​​bir sözleşmedir. Onlar bir plan. Takımının hızına cevap vermiyorlar. En iyi üç geliştiricinizi kaybederseniz değişmezler.

Son tarihler Çevik değildir, ancak Çevik son tarihler hakkında bize geri bildirim verebilir. Çevik, bir özelliğimiz kesilmeden hızımızın son tarih belirlememize izin vermeyeceğini bize bildirin. Ayrıca, son tarih vermek için işe alım yapmamız gerekip gerekmediğini de bize bildirir. Ve bazı durumlarda, kesilecek özellik kalmadığında son teslim tarihinin imkansız olduğunu bize bildiririz.

Bir Çevik ekibin yapabileceği en iyi şey, hızlarının ve öncelikli işlerin son başvuru tarihlerini yönlendirmesine izin vermesidir. Bu tahmini teslim tarihleri ​​verecektir. Son başvuru tarihinin dışında kalanlar, müşteri ile ciddi bir konuşma yapmanın ve son tarihin yapılıp yapılamayacağını belirler.

Her sprint teslimatının pazarlığa açık olmadığını söyleyebilirim. Çalışmayı değerlendiriyorsunuz, üzerine kart büyüklükleri koyuyorsunuz ve sprint sona erene kadar ekibinizi meşgul edecek kadar yüklüyorsunuz (ve sprint küçük olmalı - haftadan bir aya kadar her şey). "Teslim süreleri", beklenen işe karşı tamamlanmış işin tarihsel eğilimine dayanmalıdır. Çevik, eski "maliyet / zaman / kapsam" kısıtı fikrinden hiçbir şey eklemez / kaldırmaz, kapsamı daha iyi para veya zaman harcamak için genellikle daha iyi önceliklendirme yapılması tercih edildiğinden, kapsamı tercih etmeden kaymayı yönetme yöntemi olarak kullanır.

Bazı insanlar “vahşi batı” için çevikliği karıştırıyor gibi görünüyor. Çevik hiçbir şeyin geçeceği anlamına gelmez. Çevik, makul bir kişinin ne kadar iyi tahmin edebileceği konusunda kendimize yalan söylemekten vazgeçtiğimiz anlamına gelir. Temelde yazılım geliştirmeyi yaklaşık 2 - 4 hafta sonra geleceğe tahmin edebiliriz. Bunun ötesinde, hepsi farklı derecelerde yağma ve tahminde bulunur. Daha da kötüsü, geleceklere daha da ileri şeyler için tahminler sağlamanın maliyeti sadece işi yapmanın maliyetine yaklaşıyor. Sebep ne olursa olsun, Proje Yöneticileri tarihsel olarak bu mutlak gerçekleri müşterilere kabul etmek konusunda isteksiz davrandılar. Agile, yazılım mühendisliğinde geleceği ne kadar iyi tahmin edebileceğimizin bir sınırı olduğunu iddia ederek bu düşünceyi ayarlar ve uzun vadeli tahminler için "kanıta dayalı tahminde" ince bir geçiş yapar.Hangi tahmin edebilen ve biz şimdiye kadar teslim oldum dayalı uzun vadeli gelecek teslimat oldukça makul tahminleri sağlayabilir.

TL; DR

Son tarihler [a] gile midir? ... [D] eadyline'ların [a] gile gelişimi ile el ele gittiği görülmüştür.

Buradaki birçok cevap, sorunun mühendislik yönlerine odaklanma eğilimindedir. Bunun yerine, bunu proje yönetimi perspektifinden ele alacağım.

Son tarih, çevik ilkelere uygun olmayan çok fazla ön planlama anlamına gelir. Bunun yerine, yinelemeli geliştirme modelleri , tam zamanında planlama içeren, ancak genellikle geleneksel proje yönetimi süreleriyle ilişkilendirilen "büyük, ön planlama" değil, zaman kutularına, kadansa ve serbest bırakma döngülerine dayanır .

Çevik yöntemlerle serbest bırakma planlaması yapmak hala mümkündür, ancak planlar genellikle fiat tarafından belirlenen yönetim hedeflerinden ziyade bir hedefe ulaşmak için gereken yineleme sayısını tahmin etmeye dayanmaktadır. Yani nakliye tarihleri ayarlanamaz anlamına gelmez, ya da hedefleri yerine edilemez, fakat yolu tanımlandıkları ve karşılanması geleneksel proje yönetim metodolojileri göre oldukça farklıdır.

Zaman Kutularını Düşünün, Son Teslim Değil

Ancak, şimdiye kadar yürüttüğüm her proje bir son tarih belirleme konusunda ısrar etti. Çevik'in uyarlanabilir planlama, esneklik ve değişime odaklanma girişimleri göz önüne alındığında; Son başvuru tarihleri ​​nedir?

Bu çevik ilkelerin ortak bir yanlış anlaşılmasıdır. Scrum ve Kanban gibi çevik çerçeveler son teslim tarihlerine değil, zaman kutucuğuna ve sürdürülebilir bir teslimat temposuna odaklanmıştır.

Örneğin Scrum'da Sprint bir "son tarih" değildir. Takımın, zaman aşımına uğramadan zaman çizelgesine sığacağını tahmin ettiği iş miktarıyla dolu bir zaman kutusudur ve zaman aşımı süresi dolduğunda ya "bitmiştir" ya da "yapılmamıştır". Bir kez gitti, zaman kutusu sonsuza dek gider; Yapılmayan herhangi bir çalışma, projenin o zamanki (tarihi değil) ihtiyaçlarına göre yeni, eşit derecede geçici bir zaman dilimi içinde yeniden planlanmalı ve yeniden tahmin edilmelidir.

Zaman kutusunun önemi, hem paydaşların ilerleyişini gözden geçirmesi için öngörülebilir bir temele, hem de potansiyel olarak kaydırılabilir değer artışları sağlama ekibine sürdürülebilir bir hız kazandırmasıdır . Çalışma artımlı ve kadansı takip ediyor; Bu nedenle, büyük, ön bir son tarih kavramı çevik ilkelerle uyumlu değildir.

Zaman Kutularına Göre Yayın Planlaması

Belki de çevik süreçleri geleneksel çerçevelerle eşleştirmede insanların en çok zorlandığı alan, serbest bırakma planlamasıdır. Yayın planlaması genellikle sabit kapsamlı veya sabit tarihli teslimatları içerir. Çevik çerçevelerde, serbest bırakma planlama genellikle kapsamın açıkça değişken bir değişken olarak tanımlandığı bir tahmin süreci ile yapılırken, serbest bırakma tarihleri ​​yinelemelerde tahmin edilir.

Örneğin, bir proje, 20 tekrarlamanın sonunda bir projenin v1.0'ını yayınlamaya karar verebilir; Salıverilenlerin kapsamı projenin ömrü boyunca değişebilir (kapsam, özellikler ve öncelikler her Sprint'in başlangıcında değişebilir), ancak her sürüm için hedef tarihleri ​​proje planında belirlenir. Ekip, her Sprint'te potansiyel olarak sevk edilebilir bir artış sağlamak için çaba sarf eder ve Bitti tanımı, projenin her Sprint'in sonunda serbest bırakılabilir bir durumda olmasını sağlamak için sürekli entegrasyon gibi kalite kontrolleri içerir.

Zaman zaman, kapsamın sabit olduğu çevik projeler göreceksiniz, ancak kapsam çevik projelerdeki değişken değişken olduğundan, her yinelemenin kapsamı projenin değişen gereksinimlerine uyum sağladığında, değiştiğinde veya uyum sağladığından, zaman içinde değişebilir . Çevik ekiplere, özellikle deneyimsiz ekiplere sabit kapsamlı yaklaşımı kesinlikle önermiyorum, ancak doğru yaklaşımın olduğu zamanlar vardır.

Ayrıca bakınız

• Çevik Salınım Planlaması Nasıl Gerçekleştirilir

Son teslim tarihi bir taahhüt olarak düşünün. Projenin çevik olması, belirli bir tarih için belirli özellikleri sunmayı taahhüt etmemeniz gerektiği anlamına gelmez.

Çevikliğin getirdiği şey, arada olanlar. Belirli bir tarih için B, C, D ve E alt özelliklerinden oluşan A özelliği sunmanız gerektiğini belirten katı bir yazılım gereksinimleri belirtme belgesine sahip olmak yerine, A özelliğini belirli bir tarihte verilen tarih için vermeyi taahhüt etmiş olursunuz. erken aşamada, ne siz ne de müşteriniz özelliğin neye benzeyeceğini bilmiyor, ya da alt özellikleri B, C, D ve E ya da belki B ve C ya da bir düzine başka alt özelliğe sahip olabilir.

Daha önce yalnızca küçük şirketlere mal teslim eden ve büyük bir şirketle bir sözleşme imzalamış olan bir şirket düşünün. Bu büyük şirket EDIFACT kullanıyor ve şirketiniz tarafından kullanılan cari muhasebe yazılımının EDIFACT ile başa çıkmadığı anlaşılıyor. Sen sözleşme, şirket 15 Nisan hazır olması gerektiğini göz önüne alındığında, bunu yapmaz bir eklenti oluşturmak için istenen konum ^th .

Çeviklik, ara adımların aşamalı olarak gerçekleştirileceği ve düzenli geri bildirime dayanacağı anlamına gelir. Temel olarak, ilerlemenizi muhasebecilere göstereceksiniz ve size bunun hakkında ne düşündüklerini, olası meseleleri, vb. esasen kullanıcı deneyimi. Üç hafta sonra, sadece onu bu kadar iyileştirmekle kalmadı, aynı zamanda bir aylık ek gelişme ile sonuçlanacağı ortaya çıktı. Agile sayesinde çabalarınızı bu özellikten başka bir şeye yönlendirebilir, zamanında teslim edilmesini sağlayarak emin olabilirsiniz.

Ayrıca müşterinin bakış açısını da anlamalısınız:

• Genellikle işletmeler belirli bir teslimat tarihine ihtiyaç duyar. Örneğin, Olimpiyat oyunlarının bitiminden sonra Olimpiyat oyunları çevrimiçi akış hizmetini veremezsiniz . Business-akıllı olarak, bu büyük olumsuz sonuçları ile, sadece bir başarısızlıktır.

• Taahhüdü olmadan, bir geliştiricinin veya taşeronun mükemmeliyetçi olması ya da projeyi düşük öncelikli yapması caziptir. Sprintlerin düzenliliği yardımcı olsa da, bu riski tamamen önlemez.

  Bunun için son tarihlere düşkün değilim, özellikle son tarih fişleri çok kolay bir şekilde gerçekleştiğinden, ancak neden pek çok şirketin bunu yaptığını anlıyorum. Projenin sadece sprintlere bakarak programın arkasında olduğunu görmek her zaman kolay değildir: bu bağlamda kaçırılmış bir son tarih, bir şeyin kontrolden çıktığını ve şu anda ele alınması gerektiğini açık bir hatırlatma olabilir.

eXtreme Programlama sürüm planlamasını şöyle ifade eder:

Tahliye planlamasının temel felsefesi, bir projenin dört değişkenle ölçülebilmesidir: kapsam, kaynaklar, zaman ve kalite.

Bu adil görünüyor. Aynı zamanda

Hiç kimse 4 değişkeni de kontrol edemez. Birini değiştirdiğinizde, istemeden bir başkasının cevaben değişmesine neden olursunuz. Kaliteyi mükemmel olanın altına düşürmenin diğer 3 değişken üzerinde öngörülemeyen bir etkisi olduğunu unutmayın.

Ve zaten br3w5 tarafından belirtildiği gibi , artan kaynaklar sınırlı bir çözümdür. Muhtemelen başka bir şeye gönderildiyse, zaten ekibin bir parçası olan birkaç kişi ekleyebilirsiniz. Ancak takım boyutunu hızlı ve süresiz bir şekilde basitçe artıramazsınız, en azından çoğu zaman takım organizasyonu olmadan.

Bu nedenle, indirgenemez kalite ve sabit kaynaklar: zaman kısıtı olan bir son tarih, kapsamı uyarlamanız gerektiği anlamına gelir. Ve çevikliği kullanmak size mümkün olan en üretken kapsamla son teslim tarihini karşılama şansını verir. Ancak, genellikle kapsamın bir kısmının zamanında gerçekleştirileceğini garanti edebilirsiniz. Bu, son teslim tarihinin altına sınırlanma zamanını güvenle tahmin edebileceğiniz bölümdür. Tipik olarak, birkaç kez yaptığınız şeye gerçekten yakın olan ve bilinmeyen bir şey.

Yazılım geliştirme yöntemlerinin amacı, doğru anlaşıldığında, düşüncelerimize odaklanarak bizi daha üretken kılmak ve tipik durumlar için ortak bir dil sağlamaktır. Bu, zihin kontrolü ve suçluluk hakkında değil, ilham ve olanak sağlamakla ilgilidir.

Bir yazılım geliştirme yönteminin tam anlamıyla ödün vermeden, başka bağlamlarda radikalizm veya köktendincilik denilen şeyle uyuşmaz. Bu sapmaların saf şekli uygulamada nadiren görülür çünkü tipik olarak piyasada hızlı bir şekilde başarısızlığa yol açar. Ancak elbette, geliştiriciler belirli bir yöntemi uygulamakta zorlandığında, işareti aşmak doğal bir durumdur.

Sorun, misyonerlerin ve misyonerlerin öncelikle yöntemi kullanmak için hala ikna etmeye ihtiyacı olanları hedef almasıyla daha da belirginleşiyor; ve vaazda ılımlılık yapsalar bile, insan doğası daha az dikkat edilmesini sağlar.

Son teslim tarihleri ​​çevik değil, bunlar:

1) Şelale ve 2) Yanlış.

Yazılım ve son tarihler birlikte iyi çalışmaz ve asla sahip olmadı. Çevik yöntemler, birçok yönden, cevapsız teslim tarihlerinin veya yazılımın son teslim tarihinin karşılanamayacağının netleştiği zaman terk edilen (ya da bütçe konularının yanı sıra) ortaya çıkmadığı sorununa bir tepkidir.

Çevik, “Son tarihi biliyorsunuz veya özellikler değişecek ve / veya değişecek, bunu biliyoruz, hadi sağ ayaktan inelim ve taklit bile edemeyiz” diyerek gerçeği duruma sokmaya çalışıyor.

Anahtar, son tarihin, yazılımın ilk sürümü için basit bir sürüm tarihi haline gelmesidir. Bu hala taşla yazılabilir - örneğin, yazılım akademik kullanım içindir ve dönem başında kullanılabilir olması GEREKİR - ama sunacağınız şey değildir. O zamana kadar herkesin teslim edilebileceğinden emin olabileceğiniz asgari düzeyde geçerli bir ürününüz var ve bir miktar "can atmak istiyorsunuz". Bütün listenin "son başvuru tarihi" tarafından teslim edilmeyeceği ortaya çıktığında herkes ellerini fırlatıp atmak yerine, MVP'yi kapıdan çıkardığınızdan ve çoğu kişinin "ne yapmak istediğini" istediğinizden emin olun mümkün ve daha sonra bu noktada kalanın maliyetini / faydasını değerlendirin.

Herhangi bir süre bilgisayar oyunu oynayan herkes bunun nasıl yürüdüğünü bilir! İlk sürüm beta standartlarına uyuyorsa, birçok oyuncu mutludur, bu yüzden düşük, "kesin, gerçek tarihler" in gerçek hayatta ne anlama geldiği beklentileridir.

Bu yüzden son tarihler çevik değildir, insanlara yazılımın donanım ve çelik mühendisliği gibi davranılabileceğini düşündükleri günlerin sahipleridir. Bunun mümkün olmadığını ve arzu edilmediğini öğrendik, çünkü donanımın sahip olabileceği en büyük avantajı çöpe atıyor: yumuşak.

Çevik, bu yumuşaklıktan, hedeflerin proje boyunca asla bir köprü tasarımının asla yapamayacağı şekilde gelişmesine ve değişmesine izin vererek yararlanmaya çalışır.

Cevap "Muhtemelen hayır"

Project_management_triangle , maliyet, zaman ve kapsamı (ve aynı zamanda kalite) birbirine bağlıdır belirtmektedir. ("iki tane seç ve 3. sırayı al")

Bir scrum sprint sabit zamanı (yani 7 gün = sprint uzunluğu) ve maliyeti (yani 7 takım üyesinin bütçesi) seçer ve kapsamı (sprint'te yapılacak öykülerin sayısı) tahmin eder

Eğer yönetim veya satış departmanı üçünü de (maliyet, zaman ve kapsam) tanımlamaya çalışırsa, o zaman scrum anlamında çevik değildir, çünkü takım hedefe ulaşmak için söz veremez (kaliteyi ihlal etmeden = işin tanımı =)

Profesyonel yönetim, karşılanması gereken belirli bir tarih varsa, maliyet ve zamanı tanımlamaya ve gerekirse kapsamı azaltmaya çalışır.

Bu basit ve doğrudan cevaplanamaz mı?

Hiçbir son tarih çevik değildir.

Bütün mesele, ilerledikçe öğrenebildiğiniz ve adapte olabileceğiniz yinelemeli bir şekilde yapabileceklerinizi inşa etmektir.

Son tarih, önceden belirlenmiş bir zaman çizelgesinde sabit bir teslimat vaat ettiğinizde her iki sayımda başarısız olan "x x y vermelisiniz" dir (burada çevik ne vermeye çalıştığımızdan emin olmadığımızı söyler) ve çevikten öğrenme bize, zaman ölçekleri konusunda kesin bir kesinliğe sahip olmanın çok zor olduğunu bilmemize rağmen - ya da çözülmüş bir problem olduğunu ve bunu zaten yapmamamız gerektiğini) öğretir.

Sorunun cevabını "Hayır, son tarihler çevik değildir" olarak belirledikten sonra, "çevik bağlamda son başvuru tarihlerini nasıl ele alıyoruz" sorusuna hitap eden ilginç bir sohbete başlayabiliriz. diğer cevaplarda da bunu düşünüyorum.

Aklıma göre, ikincisine makul bir cevap, erken ve sıklıkla değer artışları yapacağımız ve zaman içinde nerede olduğumuzu göreceğimizdir - ancak herkese uyan tek bir beden yoktur.

Birinin çalışmasında gerekli olan çeviklik derecesi, organizasyon şemasındaki konumlarının ne kadar yüksek olduğuna orantılıdır.

"Çevik", ne olduğu için iyidir. "Çevik" sorta "açık fikirli ve yeterli yetkinliğe sahip" anlamına gelir. En çevik olması gereken en alt kısımdaki homurdanıyor.

Eğer yönetim seviyelerinde sivri saçlı patron, haftada bir son teslim tarihinin daha iyi bir ürün getireceğini ya da daha temiz, daha hatasız ve daha fazla kaldıraçlı kod üreteceğini anlayacak kadar çevikti. veya bölünme) gelecekte iki hafta kazandırır, bu çok çevik bir son tarih.

Ancak aydınlanmış kişisel çıkar gibi, gerçekten de mevcut değildir.