Çevik geliştirmede yeniden düzenleme
Bir uygulama geliştirme projesinde, uygulama tasarımında projenin tam kapsamı dikkate alınmamıştır. Bu nedenle, değişikliklere uyum sağlamak için kodların sık sık yeniden düzenlenmesi, bir sprint sırasında gerekli hale gelen proje teslim zaman çizelgesini olumsuz yönde etkiliyor. Paydaşlar taviz vermeye istekli olmadığından, kararlaştırılan proje teslim tarihini aşma riskini en aza indirmek için bu en iyi nasıl kontrol edilebilir?
Yanıtlar
TL; DR
Herhangi bir proje yönetimi çerçevesinin bir parçası, ancak özellikle Scrum gibi çevik çerçeveler, paydaş beklentilerini sürekli olarak yönetmenin gerekliliğidir . İnsanlar istediklerini istedikleri zaman isterler, ancak proje yönetiminin büyük bir kısmı insanlara projeyi etkileyen çeşitli kısıtlamalar dahilinde gerçekte neye sahip olabileceklerini açıklamaktır . Proje geliştikçe, o zaman geçerli olan kısıtlamalar dahilinde şu anda neyin uygulanabilir olduğunun anlaşılması, özellikle de başlangıçta planlanandan farklı olan neyin mümkün olduğu durumlarda.
Yeniden Çalışma Bekleniyor
Yeniden düzenleme, dış davranışı değiştirmeden uygulamayı değiştirir. Büyük olasılıkla, gerçekten yeniden düzenleme yapmıyorsunuz; özünde aynı şeyler olmayan teknik borcunuzu ödüyorsunuz veya yeniden çalışma ve entegrasyon gerçekleştiriyorsunuz.
Scrum gibi çerçeveler, çeşitli çalışma türlerini (yeniden düzenleme ve yeniden çalışma dahil) deneysel kontrol ve tasarım için kabul edilebilir bir değiş tokuş olarak ele alır. Bu, tahmin sürecinde ele alınır ve (doğru bir şekilde), teknoloji borcu, karmaşıklık veya değişimin hızı arttıkça hızda bir engel olarak ortaya çıkar. Bu hem edilir beklenen ve arzu her adapte incelemek ve halka değişim kapsamı, öncelik veya yaklaşımı için bir fırsat sağladığı için, iteratif çerçevede.
Yeniden çalışma, deneysel kontrolün maliyetidir. Yazılım geliştirme gibi karmaşık projelerde bundan gerçekten kaçınamazsınız. Scrum, gerekli veya istenen değişiklikleri yapmanın maliyeti olarak sadece yeniden çalışmayı takım ve paydaşlar için görünür kılar .
Sabit-Her Şey Mümkün Değil
"Demir üçgen", diğer üç kaydırıcı tarafından etkilenen örtük bir dördüncü boyutun kalitesiyle bütçe, kapsam veya zamanlamayı kontrol ederek bir projeyi ayarlayabileceğinizi belirtir. Aşağıdaki grafik bunu göstermektedir.
Scrum gibi çevik çerçeveler, genel olarak kapsamı ve özellikle proje kapsamını ana kaydırıcı olarak ele alır:
Tek bir Sprint'in zaman kutusuna ne kadar kapsam sığdırabiliriz veya çevik sürüm planımıza uyabiliriz ?
Şu anda projeniz hem kapsamı hem de programı düzeltmeye çalışıyor. Bu, yalnızca bütçeyi kullanılabilir kaydırıcınız olarak bırakır. Bunu da kilitlemeye çalışırsanız, ya projeniz başarısız olur ya da kalite zarar görür ya da her ikisi birden. Kaliteyi korurken herhangi bir proje çerçevesinde sabit fiyat, sabit kapsam ve sabit zamanlamayı güvenilir bir şekilde yapamazsınız ; Scrum basitçe bunu daha açık hale getirir ve değiş tokuşları daha görünür hale getirir.
Scrum'ın amacı demir üçgeni sihirli bir şekilde ortadan kaldırmak değildir. Bunun yerine, projeyi (aynı zamanda paydaşları ve sponsorları) doğasında var olan değiş tokuşlarla uzlaşmaya zorlar. Scrum, paydaşların her Sprint'in sonunda bir şeyin "yeterince iyi" olup olmadığını belirlemesini sağlar ve Ürün Sahibi, İş Listesi İyileştirme ve Sprint Planlama sırasında kapsamı ve önceliklendirmeyi ayarlama fırsatı elde eder. Paydaşların, yayın planı dahilinde mümkün olan en yüksek değeri elde etmelerini sağlamak için bu olaylardan yararlanmaları gerekir; öyle asla proje Sprint'ler sabit serisinin sonunda amacıyla ya% 100 tam veya uygun olacağı bir para iade garantisi.
Batık Maliyetleri Azaltın
Çevik geliştirmenin bir başka yönü de "erken başarısız olma" fırsatıdır. Bir projenin herhangi bir nedenle başarısız olma ihtimali olduğunda, Scrum gibi çevik çerçeveler Ürün Sahibine bir Sprint'i iptal ederek ve değişen beklentilere göre yeni bir tane planlayarak veya paydaşların projenin geri kalanını iptal etmesine izin vererek para tasarrufu yapma fırsatı verir. amaçlarına hizmet etmeyecek. İkincisi, projenin başarılı olmasını sağlamayacak, ancak projeyle ilgili batık maliyetleri azaltacaktır.
Kimsenin yaptığı hiçbir şey bir projenin başarılı olacağını garanti edemez. Yapabileceğiniz en iyi şey, onu kontrol etmek ve başarı artık bir seçenek olmadığında, mahkum bir projeyi mümkün olduğunca erken bitirmek.
Şimdi Ne Yapabilirsin
Öncelikle, bir ölüm yürüyüşü yolunda olduğunuzu kabul edin. Bu gerçekle yüzleşmezseniz, yaptığınız hiçbir şeyin önemi kalmaz.
Ardından, sorunun tasarım mı, teknoloji borcu mu, mantıksız beklentiler mi yoksa başka bir şey mi olduğunu belirleyin. Temel neden veya nedenlerin ne olduğu önemli değildir; Ekibin ve paydaşların işbirliği içinde onlara hitap edebilmesi için onları görünür kılmanız yeterlidir .
Son olarak, iletişim açıkça mevcut durumu. Tam özellikli bir sürüm için ilerleme hızındaysanız, başlangıçta öngörülen teslim tarihinden birkaç döngü geçtiyseniz, projenin "zaman" tepe noktasını ayarlayıp ayarlayamayacağını tartışın. Programı ayarlayamazsanız veya ayarlamazsanız, maliyetleri artırarak veya kapsamı azaltarak sabit son teslim tarihine hala uyabilirsiniz. Paydaşlar, biraz zaman alan işlevselliği azaltmak için zamanında teslimatta ticaret yapar mı? Sormazsan bilemezsin.
Proje yukarıdakilerden hiçbirini yapamazsa veya yapmazsa, başarısızlığa hazırlanın. Özgeçmişinizi tazeleyin ve bir sonraki projenizde veya bir sonraki işinizde kullanabileceğiniz değerli dersler aldığınızı umun. Hepsinden önemlisi, varsayımlar, zorluklar, çerçeve gereksinimleri ve değiş tokuşlar hakkında erken ve sıklıkla iletişim kurmayı öğrendiğinizi ve paydaş beklentilerini sürekli yönetmenin önemini içselleştirdiğinizi umuyoruz.
Her sprintte konuşlandırılabilir bir ürün artışı mı üretiyorsunuz? Eğer öyleyse, üzerinde anlaşmaya varılan teslimat tarihleri zaten karşılanmış demektir ve bu, riski en aza indirmenin ve yaptığınız işte müşteriye güven vermenin en iyi yoludur. Paydaşlar (ürün sahibi aracılığıyla) hangi şeyleri ne zaman istediklerine karar vermelidir, bu nedenle en önemlisi, sizi değer verdiğinizi görmeye devam etmeleri ve ürün için gereken iyileştirmeler, değişiklikler ve düzeltmeler hakkında geri bildirimlerini almanızdır. Geri bildirimlerini almak burada çok önemlidir. Müşteriler, zaman çizelgesi yeni bir işlevsel kapsam olmadan genişlerse, anlaşılabilir bir şekilde endişelenebilirler, ancak siz öncelikli olarak gördükleri en son iyileştirmeleri dahil etmeye başladığınız anda esneklik ihtiyacını daha fazla takdir edeceklerdir.