Ortalama bir yazılım geliştirme projesi, başlangıçta planlanan veya tahmin edilenden iki kat daha uzun sürer. Yazılımda yerleşik olarak bulunan işlevlerin yüzde 60’ından fazlası, yazılım teslim edildikten sonra bir kez bile müşteri tarafından neredeyse hiç kullanılmıyor veya hiç kullanılmıyor. Tüm yazılım geliştirme projelerinin neredeyse yüzde 70’i büyük ölçüde bütçenin dışında yürütülüyor. Yazılım geliştirme projelerinin tahmini, geleneksel olarak, yazılım geliştirmenin fiili başlangıcından önce projenin başlangıcında yapılır. İlk olarak, işlevsel ve işlevsel olmayan gereksinimler toplanır. Çaba ve maliyetler tahmin edilir ve müşteriye bir fiyat teklifi gönderilir. Sonunda bir sözleşme imzalayın. Yazılım geliştirme projelerini tahmin etmenin bu yerleşik yolu genellikle tatmin edici değildir.
Proje başladığında, müşteri projeye yeni gereksinimler getirme eğilimindedir, bu da zamanında teslim etmeyi ve sözleşmeyi yerine getirmeyi zorlaştırır. Müşteri geliştirme aşamasında bir noktada bir prototip görürse, yeni özellikler önerecek, değişiklik talep edecek ve hatta işlevselliği kaldırabilir. Devam eden yeni içgörüler veya değişen pazar koşulları, proje önceden kararlaştırılan ve sözleşmede teslim edilebilir olarak beyan edilen gereksinimlere bağlı kalırsa sorun yaratır. Değişikliklerle başa çıkmanın bir yolu, bir değişiklik yönetimi prosedürü eklemektir. Alternatif olarak, projeleri çevik hale getirmek, daha esnek ve tatmin edici bir yazılım teslim modeli sağlayabilir. Bununla birlikte, proje maliyetlerinin ve teslim tarihlerinin makul bir doğruluk derecesi ile nasıl tahmin edileceği sorusu ortaya çıkar ve yeni özelliklerin sürekli akışı talep edilir ve hatta diğer işlevler kaldırılabilir. Bir müşteriye bir Agile projesinden nasıl alıntı yapılır ve değişikliklerle nasıl yüzleşilir? Çeviklik sunarken proje bütçesinin kontrolü nasıl korunur?
Çeviklik, proje başarısızlığını azaltmaya yardımcı olur
2001’de Çevik İttifak kuruldu ve Çevik Manifesto yayınlandı. Bu manifesto, bireylerin ve etkileşimlerin süreçlerin ve araçların üstüne çıktığını, iş yazılımının eksiksiz dokümantasyonla birlikte geldiğini, müşteri ile işbirliğinin sözleşme görüşmelerinden daha önemli olduğunu ve değişime yanıtın daha fazla vurgulanması gerektiğini belirtir. önceden tanımlanmış bir planı takip etmek. Bugün var olan çevik yazılım geliştirme yöntemlerinden bazıları SCRUM, DSDM Atern, Özellik Odaklı Geliştirme (FDD) ve Extreme Programming (XP) ‘dir. Tüm bu çevik yöntemlerin ortak noktası, bir yazılım geliştirme projesindeki tüm değişkenlerin sıfırdan kolayca düzeltilemeyeceği fikridir. Buradaki fikir, projenin maliyetlerini ve zamanını sabitlemek, ancak esneklik sağlamak için işlevlerin sayısını bırakmaktır. Çoğu zaman, yeni içgörüler veya yeni fikirler, yalnızca proje halihazırda devam ederken ve ilk iş gösterildiğinde bulunur. Proje devam ederken piyasa da sürekli hareket eder, bu da genellikle senkronize kalmak için ilk planlarda ve fikirlerde gerekli ayarlamaları yapmak gerektiği anlamına gelir. Proje kapsamını en baştan belirlemek, müşterinin ihtiyaçlarına en uygun yazılım çözümünü sağlamaz. Resmi bir değişim yönetimi stratejisi uygulamak, günümüzün zorlukları için her zaman en iyi çözüm olmayabilir.
En yaygın Agile uygulamalarından biri, yineleme olarak adlandırdıkları, zaman sınırlamaları veya sprintler olarak da adlandırılan şeylerde çalışmaktır. İdeal olarak, bu yinelemeler iki ila dört haftalık sabit zaman aralıklarında ayarlanır. Diğer bir çevik uygulama, yalnızca bir gereksinimler aşamasında değil, her yinelemenin sonunda gereksinimleri sürekli olarak yeniden önceliklendirmektir. Henüz geliştirilemeyen tüm özellikler, bir özellik portföyünde saklanır, müşteri değerine göre sıralanır ve bir sonraki yinelemede geliştirilen özellikler, en yüksek müşteri değerine sahip sipariş defterinde hala bulunan özelliklerdir. Her yinelemenin sonunda, tam olarak geliştirilmiş ve test edilmiş iş işlevleri veya işlevleri sunulur. Müşteri veya ürün sahibi en baştan dahil olur, her yinelemeden elde edilen sonuçları görür ve iyileştirmeler önermeye ve hatta ekibe yeni özellik istekleri sunmaya motive olur. Test, yinelemelerin kendisinde yapılır ve sonraki yineleme, daha önce üzerinde çalışılmamış veya önceki dönemde tamamlanıp tam olarak test edilmemiş yeni özellikler sunar. Proje planlama, bir görev listesini tamamlamaktan çok, her zaman periyodunun sonunda iş yazılımı ve özellikleri sunmaya odaklanır. Sonuçta, görevleri tamamlamak, çalışan bir yazılımınız olduğu anlamına gelmeyebilir.
Bu çevik uygulamaların avantajları çoktur. Ekip, sipariş defterinde en yüksek önceliğe sahip işlevler üzerinde ilk önce çalışmaya devam ettiğinden, sürekli içgörü ve yeni fikirleri kabul etmek daha kolaydır. Her yinelemenin sonunda tamamlanan özellikler aracılığıyla proje ilerlemesi müşteriye görünür hale getirilir. Çeviklik böylelikle başlangıçta üzerinde anlaşılan ancak artık gerekli olmayan işlevselliği sunmaya çok fazla odaklanma riskini azaltmaya yardımcı olur. Bununla birlikte, müşterilerin proje devam ederken yeni özellikler eklemesine izin verilirse, proje maliyetlerinin kontrolünün nasıl sağlanacağıyla ilgili sorular devam etmektedir. Bir geliştirme projesi nasıl bütçede kalabilir ve yine de doğru işlevselliği zamanında ve maliyet dahilinde sunabilir?
Çevik yazılım geliştirme proje tahmini
Çevik yazılım geliştirme projelerini yönetmenin pratik ama etkili bir yolu, iş birikimindeki bilinen tüm özelliklerin veya kullanıcı öykülerinin boyutlarının birbirlerine göre hikaye noktalarını kullanarak tahmin edilmesidir. Kullanıcı öyküleri, basit bir metin biçiminde yazılan basitleştirilmiş kullanım örnekleridir ve teknik olmayan proje katılımcıları tarafından anlaşılması da kolaydır. Oluşturulacak işlevi “As [role] yaparım [action] Böylece [results]. “Hikaye puanları, rolü yaratma boyutunu veya çabasını belirtmek için her role veya kullanıcı hikayesine atanan sayılardır. Örneğin, bir rol oluşturmanın başka bir role göre iki kat daha fazla zaman ve çaba gerektirdiğini tahmin ediyorsanız İlk özellik, ikinci özelliğe göre iki kat daha fazla hikaye puanı kazanır. Bu noktada, çabayı doğrudan kullanıcı hikayelerine bağlamak istemezsiniz. Kullanıcı hikayelerine hikaye noktaları atarken en iyisi 1, 2, 3, 5 veya 8 hikaye puanı gibi olası değerlerin basit bir listesi. En küçük kullanıcı hikayesiyle başlayın veya orta ölçekli bir kullanıcı hikayesiyle başlayın ve oradan çalışın. Nasıl bir ilişki kuracağınızı tahmin edin kullanıcı öyküsünün boyutu ve çabası ile diğeriyle birlikte çalışın ve her bir özelliğe öykü noktalarının göreceli sayısını atayın İlk iki haftalık yineleme sırasında, bir işlevde birkaç kullanıcı öyküsünün geliştirildiğini varsayalım. Özellikleri özellik listesinin en başında yer alan ve müşteri tarafından o sırada en yüksek değere sahip olarak vurgulanan fonksiyonel yazılım kalitesi. 2 hafta sonra, üç kullanıcı hikayesi tamamen geliştirildi ve test edildi. Bu üç kullanıcı hikayesinin her biri önceden 5 hikaye puanı olarak tahmin ediliyordu. Bu, mevcut ilerleme hızına, üretkenlik oranına veya aynı zamanda geliştirme ekibinin hızı olarak da adlandırılır. Bu projede ekip hızı, yineleme başına 15 hikaye puanı olan 15’tir.
Hız, proje bütçesi içinde nasıl kalacağınızı gösterir
Tahmini teslim süresi ve ekip geliştirme hızı, projede uygulanacak bilinen tüm özellikler tahmin edilerek, tüm özelliklere hikaye puanları atanarak ve bu tahmini değerleri ekibin içinde bulunduğu hikaye puanı sayısı ile ilişkilendirilerek hesaplanır. ortalama, bir yineleme süresince gelişebilir. Özellik birikimine yeni özellikler eklendiğinde ve diğer özellikler aynı listeden çıkarıldıkça, halihazırda geliştirilmiş olan ve henüz geliştirilecek olan toplam hikaye puanı, projenin nereye ve ne zaman ilerlediğine dair bir ipucu verir. projeyi bekleyin. Tamamlamak. Daha fazla özellik ilerledikçe ve iş yazılımında tamamen geliştirilip test edildikçe, hız, sonraki her yinelemenin sonunda ayarlanarak otomatik olarak ayarlanır. Lütfen projenin sonunda sunulan işlevselliğin sabit olmadığını unutmayın. Bununla birlikte, proje çalışma süresi sırasında geliştirilen yazılım, muhtemelen müşterinin projenin başlangıcında dahil olduğu ve tam olarak test edilen özelliklerin başlangıçta zaten teslim edildiği pratik müşteri kullanımı yazılımıdır. Büyük olasılıkla, temel yazılım proje süresi içinde teslim edildi. Belki de bazı özellikler dahil edilmedi veya sonraki bir sürüm için ertelendi.
Evet, çevik projeler tahmin edilebilir. Hız, geliştirme hızı az ya da çok değişmeden ve birikimde bilinen bir dizi tahmini özellik ile devam ederse, devam eden projenin ne zaman teslim edilebileceği konusunda net bir fikir verir. Hız, projenin zamanında teslim edilemeyeceğini gösteriyorsa, projeye daha fazla kaynak ve insan eklemek veya belirli işlevleri kaldırmak için adımlar atılabilir. Proje yöneticisi, önceden tamamlanmış benzer geliştirme projelerinin üretkenlik oranını kullanarak, yeni projeleri tahmin etmek için kullanabileceği değerli bilgilere sahiptir, hatta müşterilere bir miktar üretilebilecek işlevsellik miktarı hakkında geçerli bir fikir vermesine izin verir. sabit zaman.