Çeviklik %268 daha fazla başarısızlığa yol açar: bu mümkün mü?
Bir çalışma, çevik yazılım geliştirmenin sözde %268 daha yüksek başarısızlık şansına sahip olduğunu gösteriyor. Böylesine büyük bir dezavantaj aslında herkesin herhangi bir çevik projeyi takip etmeyi derhal bırakmasına yol açmalıdır.
Duyuru
(Resim:
Eberhard Wolff
)
Eberhard Wolff, SWAGLab'ın mimarlık bölümünün başkanıdır ve yirmi yıldan fazla bir süre boyunca genellikle iş ve teknoloji arasındaki arayüzde mimar ve danışman olarak çalışmıştır. Mikro hizmetler de dahil olmak üzere çok sayıda makale ve kitabın yazarıdır ve uluslararası konferanslarda düzenli olarak konuşmacı olarak yer almaktadır. Teknoloji odağı, bulut, etki alanı odaklı tasarım ve mikro hizmetler gibi modern mimari ve geliştirme yaklaşımlarıdır.
Sayılar nasıl doğar? Çalışmada ilk olarak aşağıdaki faktörlerin yazılım geliştirme projelerinin başarısını arttırdığı tespit edilmiştir:
- Proje başlamadan önce gereksinimler açıktır (%97 daha başarılı projeler).
- Olasılık Sorunlar hızlı bir şekilde tartışılabilir ve çözülebilir (%87).
- Proje gereksinimleri gerçek sorunlara dayanmaktadır (%54).
- Projenin uygulama başlamadan önce eksiksiz bir spesifikasyon veya gereksinimler belgesi vardır (%50).
- Daha sonraki geliştirme sürecinde (%7) gereksinimlerde önemli bir değişiklik yapılmadı.
Çalışma çevik geliştirmeyi şu projeler olarak tanımlıyor:
- Gereksinimler netleşmeden geliştirme başlar,
- tam bir spesifikasyon yoktur ve
- Projenin son aşamasında önemli değişiklikler var.
“Başarı” nedir?
Çalışmanın ilk sorunu “başarısızlık” tanımının olmayışıdır. Olası bir kriter, projelerin bütçe dahilinde teslim edilmemesi olabilir. Ancak bu tek bir yazılım projesi için garip bir hedef. Yazılımın mümkün olduğunca ucuz olmasını istiyorsanız, onu kendiniz geliştirmemeli, standart yazılımı satın almalısınız. Bu, uygulamanızın esnekliğine ihtiyaç duymadığınız alanlar için anlamlıdır. Örneğin, birinin neden finansal muhasebeyi kendi başına uygulayacağı benim için açık değil.
Belki daha yüksek maliyetler daha yüksek değerle ilişkilidir çünkü daha fazla özellik uygulanır ve belki daha fazla satış ve kar elde edilir? Bu nedenle proje başarısız mı?
“Başarısızlığı” tanımlamanın bir başka yolu da müşterinin projenin sonundaki sonuçtan dolayı hayal kırıklığına uğraması olabilir. Bu mantıklı olabilir ama rasyonel bir kriter değildir. Müşteriler çeşitli nedenlerden dolayı hayal kırıklığına uğrayabilirler. Farklı paydaşların sonuçtan farklı düzeyde memnuniyetleri olabilir.
“Başarısızlığın” tanımı pratik sonuçları olmayan bir soru değildir. Resmi olarak başarılı olan ancak öznel olarak önemli sorunları olan veya önceden tanımlanmış proje hedeflerini karşılamayan projeler üzerinde çalıştım. Durum daha da kötüleşiyor: Bazı projelerin gerçek bir proje hedefi yok; bunların başarısız mı yoksa başarılı mı olduğuna nasıl karar vereceksiniz?
Artık çalışmaya daha detaylı bakmayı bırakabilirsiniz. Ancak çalışmanın başka birçok sorunu var.
Büyük sürprizler!
Çalışma, gereksinimlerin proje başlamadan önce bilinmesinin, spesifikasyonların tamamlanmasının ve projenin son aşamalarında önemli değişikliklerden kaçınılmasının faydalı olduğunu savunmaktadır. İtiraf etmeliyim ki, araştırmanın diğer sonuçları gibi bunda da şaşkınlığım sınırlı. Başlangıçta daha fazla bilgi ve proje boyunca daha az değişiklik kesinlikle projelerin hayatını kolaylaştırıyor. Böyle bir projeyi sıkıcı olarak tanımlayabilirsiniz. Uygulayıcıların bakış açısından bu harika çünkü projenin başarılı olma olasılığı daha yüksek. Ancak müşterinin bakış açısından böyle bir projenin yüksek değere sahip olması pek mümkün görünmüyor. Örneğin, yeni bir dijital ürünle yeni bir pazara rekabetten daha hızlı girmek istiyorsanız, gereksinimler muhtemelen net değildir, spesifikasyonlar eksiktir ve projede daha sonra değişiklikler olacaktır çünkü neyin ne olduğu net değildir. müşterilerin tam olarak istediği ve pazarın nasıl göründüğü. Kimse bilemez. Müşteriler ancak projeyi beğendikleri takdirde harekete geçerler.
Çevikliğin güçlü yönlerini tam olarak gösterebileceği yer burasıdır. Bu tür projelerin çoğu zaman orijinal plandan saptığına ve bunun başarısızlık olarak adlandırılabileceğine hemen inanıyorum. Peki sonuç nedir? Bu tür projeleri üstlenmemek ve böyle bir pazar fırsatından yararlanmamak mı? İstikrarlı görünmek için önlemler alıp sonra projeyi engellemek mi?
Başka bir deyişle: araştırmaya göre en sık başarısız olan projeler, özellikle yüksek değer üreten projeler olabilir.
Çevik nedir?
Görünüşe göre çalışmanın çeviklik tanımı çevik manifestoya dayanıyor. Dolayısıyla Çevik Manifesto şöyle bir şey içermelidir: “Projenin başlangıcında gereksinimler açıksa ve eksiksiz bir spesifikasyon mevcutsa, bu belgeyi silin ve kimsenin gereksinimleri ve spesifikasyonu hatırlamadığından emin olun – aksi takdirde proje bu manifesto olmayacaktır. yeterlidir.” Ayrıca bir yerlerde “Projede sonradan önemli bir değişiklik olmazsa icat edin, aksi halde proje bu manifestoyu karşılamıyor” demeli. Araştırdım: Agile manifestosunda bu yok ve bu şekilde yorumlanabilecek bir paragraf da yok. Aksine: Çevik manifesto, bir planı takip etme ve değişikliklere tepki verme gibi seçenekleri değerlendirir ve diğer seçeneği önemsiz, yani daha az önemli olarak değerlendirmeden, örnekte değişikliklere tepki verme gibi tek bir şeye odaklanır. Bir değişikliğe tepki vermek, aslında değişikliği henüz dikkate almamış olan belirlenmiş plana bağlı kalmaktan daha mantıklı görünüyor.
Daha da fazla sorun
Çalışma, diğer şeylerin yanı sıra, 600 yazılım mühendisinin katılımıyla yapılan bir ankete dayanıyor. Anketler her zaman yalnızca görüşülen kişinin, bu durumda yazılım mühendislerinin öznel imajını yansıtabilir. Yazılım geliştirme ekonomik bir yatırım olduğundan, diğer grupları, özellikle de farklı paydaşları da araştırmak mantıklı olacaktır. Son olarak projeleri devreye alıyorlar. Peki projenin gerçekten başarısız olup olmadığını kim daha iyi değerlendirebilir?
Ve çalışma başka bir soruyu cevapsız bırakıyor: Kaç projenin net gereksinimleri var? yüzde 10? Yüzde 25 mi? yüzde 90? Çalışmadan görülebilecek tek şey, istatistiksel olarak anlamlı açıklamalar yapabilmek için yeterince büyük bir sayının olması gerektiğidir. Birçok projenin net olmayan gereksinimleri varsa, bu büyük bir soruna işaret eder. Bunun çözülüp çözülmeyeceği ve nasıl çözüleceği bir sonraki sorudur ve cevaplanması o kadar kolay değildir. Gereksinimler sadece arzu edilmeyebilir, aynı zamanda belirtildiği gibi ilkeleri nedeniyle belirsiz de olabilir.
Ve şimdi?
Araştırma gerçekten bir blog yazısına değmez. Bu, çevik yazılım geliştirmeyi itibarsızlaştırmaya ve farklı bir yaklaşımı teşvik etmeye yönelik şeffaf bir hiledir. Ancak çalışma hala etkili: Çalışmaya iki farklı bağlamda atıfta bulundum. Bu anlaşılabilir bir durumdur: %268 yüksek bir rakamdır ve sonuç şaşırtıcıdır çünkü çeviklik aslında daha fazla başarı elde etmelidir. Sadece içeriye bakmanız yeterli! Gerçekten yaparsanız ne saçmalık olduğu hemen anlaşılır. Bir YouTube videosu bu sayıyı, çalışmanın açıkladığı gereksinim sorunlarını değil, çevikliğin diğer yönlerini eleştirmek için kullandı. Eleştirinin haklı olup olmadığına bakılmaksızın: video, dikkat çekmek için stüdyonun absürt figürünü kullanıyor.
Eğer endüstrimizde bunu yaparsak, gerçekten neyin işe yaradığını öğrenmezsek ve dolayısıyla hiçbir ilerleme kaydedilmezse şaşırmamalıyız. Kaynaklarla eleştirel çalışma okulda öğretilir.
Çalışmayla çevikliğin “iyi” mi yoksa “kötü” mü olduğuna cevap veremiyoruz. Ancak yinelemeler halinde yazılım oluşturmamız gerektiği gerçeği, pratikte çok erken bir zamanda, prensipte insanların ekipler halinde yazılım geliştirmeye başlamasıyla netleşti. Çevik projelerden farklı olarak gereksinimler nispeten istikrarlıdır. Prof. Christiane Floyd gibi öncüleri dinlediğinizde bu daha da netleşiyor. Hatta bu konuyla ilgili bir konuşma bile yaptım. Ayrıca iyi işleyen projelerin olduğu da açık olmalıdır; örneğin bir planı takip etmek yerine değişikliklere tepki vermek. Belki de asıl sorun, çeviklik teriminin artık tükenmiş olmasıdır, çünkü gerçekte orijinal fikirlere uymayan ve özellikle yararlı olmayan “çevik” süreçler tanıtılmaktadır.
tl; Dr.
Sektörümüz taraflı çalışmalara açıktır. Bu bir utanç. Açıkça yapılan açıklamalar dikkat çekiyor.
(kendim)