Çeviklik yüzde 268 daha fazla hata getiriyor: olabilir mi?
Bir çalışma, çevik yazılım gelişiminin hataların yüzde 268'inin olasılığına sahip olduğu söyleniyor. Böyle muazzam bir dezavantaj aslında herkesin çevik projeleri gerçekleştirmeyi hemen durdurmasına yol açmalıdır.
(Resim:
Eberhard Wolff
)))
Eberhard Wolff, Swaglab'ın mimarisinin başkanıdır ve yirmi yıldan fazla bir süredir, genellikle iş ve teknoloji arasındaki arayüze mimar ve danışman olarak çalışmaktadır. Mikro hizmetler de dahil olmak üzere çok sayıda makale ve kitabın yazarıdır ve uluslararası konferanslarda konuşmacı olarak düzenli olarak performans gösterir. Teknolojik odağı, bulut, alan adı ve mikro hizmetler tarafından yönetilen tasarım gibi modern mimari ve geliştirme yaklaşımlarıdır.
Sayılar nasıl oluşur? Çalışma başlangıçta aşağıdaki faktörlerin yazılım geliştirme projelerinin başarısını artırdığını belirtmektedir:
- Gereksinimler projenin başlamasından önce açıktır (daha başarılı projelerin yüzde 97'si).
- Sorun olasılığı hızlı bir şekilde tartışılabilir ve karşılaşılabilir (yüzde 87).
- Proje gereksinimleri gerçek sorunlara dayanmaktadır (yüzde 54).
- Proje, uygulamanın başlamasından önce (yüzde 50) tam bir spesifikasyon veya tam gereksinimler belgesine sahiptir.
- Geliştirme sürecinde daha sonraki gereksinimlerde önemli bir değişiklik olmamıştır (yüzde 7).
Çalışma, çevik gelişimi aşağıdakilerin uygulandığı projeler olarak tanımlamaktadır:
- Geliştirme, gereksinimler net olmadan başlar
- Tam özellik yok e
- Projenin sonlarında önemli değişiklikler var.
“Başarı” nedir?
Çalışmanın ilk sorunu “iflas” tanımının olmamasıdır. Olası bir kriter, projelerin bütçede teslim edilmemesidir. Ancak bu, tek bir yazılım projesi için tuhaf bir hedeftir. Mümkün olduğunca ucuz yazılıma sahip olmak istiyorsanız, bunları tek başına geliştirmemelisiniz, ancak standart yazılım satın almalısınız. Bu, kişinin uygulanmasının esnekliğine ihtiyaç duymadığınız alanlar için mantıklıdır. Örneğin, bir finansal hesabın neden kendi başına uygulanacağı bana açık olmaz.
Belki de daha yüksek maliyetlerle ilişkilidir, çünkü daha fazla özellik uygulanır ve belki de daha fazla satış ve kar elde edilir? Proje bir başarısızlık mı?
Müşteri projenin sonundaki sonuçtan hayal kırıklığına uğrarsa “iflas” tanımlamanın başka bir yolu. Bu mantıklı olabilir, ancak rasyonel bir kriter yapamaz. Müşteriler bir dizi nedenden dolayı hayal kırıklığına uğrayabilir. İlgilenen birkaç taraf sonuçtan memnun olabilir.
“Başarısızlık” tanımı pratik bir etki olmadan bir soru değildir. Yalnızca projelerde resmi olarak başarılı oldukları için çalıştım, ancak öznel olarak önemli sorunlar yaşadım ya da -definiti proje hedeflerine ulaşmadım. Daha kötüsü: Bazı projelerin projenin gerçek hedefleri yok: Bir başarısızlığa veya başarıya nasıl karar vermelisiniz?
Aslında, çalışmayı daha yakından almayı bırakabilirsiniz. Ancak çalışmanın daha birçok sorunu var.
Açık sürprizler!
Çalışma, projeye başlamadan önce bilinen gereksinimlerin yararlı olduğunu, spesifikasyonun tamamlandığını ve projenin sonlarında önemli bir değişiklik olmadığını belirtmektedir. İtiraf etmeliyim: Bu konudaki şaşkınlığım ve çalışmanın diğer sonuçları kısıtlı sınırlar dahilinde. Başlangıçta daha fazla bilgi ve proje sırasında daha az değişiklik projeleri basitleştiriyor. Böyle bir proje sıkıcı olarak tanımlanabilir. Aktüatörler açısından, bu harika çünkü projenin başarılı olma olasılığı daha yüksek. Bununla birlikte, müşterinin bakış açısından, böyle bir projenin yüksek bir değere sahip olması muhtemel görünmüyor. Yeni bir pazarı rekabetten daha hızlı yeni bir dijital ürünle doldurmak istiyorsanız, gereksinimler muhtemelen net değildir, özellikler eksiktir ve değişiklikler bile projenin sonlarında ortaya çıkacaktır, çünkü müşterilerin ne istediği ve pazar görünümü açıktır. Kimse bilemez. Müşteriler yalnızca projeyi sevdiklerinde erişirler.
Tam olarak bu durumda, çeviklik güçlü yönlerini yerine getirebilir. Bu projelerin orijinal planlamadan daha sık farklı olduğuna ve bu bir başarısızlık olarak tanımlanabileceğine hemen inanıyorum. Ama sonuç nedir? Bu projeler sadece karşılaşmıyor ve böyle bir pazar olasılığı yok mu? İstikrarı taklit etmek için önlemler benimseyin, ancak projeyi engelliyorlar mı?
Başka bir deyişle, çalışmaya göre sıklıkla başarısız olan projeler belki de özellikle yüksek bir değer yaratan projelerdir.
Çeviklik nedir?
Çevik manifesto üzerinde yapılan çalışmadan çeviklik tanımının olduğu varsayılmaktadır. Dolayısıyla Çevik Manifesto anlamda bir yer içermelidir: “Projenin başında gereksinimler açıksa ve tam bir spesifikasyon varsa, bu belgeyi ortadan kaldırın ve kimsenin gereksinimleri ve özellikleri hatırlamadığından emin olun, aksi takdirde proje yeterli değildir”. Ayrıca “daha sonra projede önemli bir değişiklik yoksa, aksi takdirde projenin bu tezahür için yeterli olmadığını” icat eder. Kontrol ettim: Bu çevik manifestoda değil ve yorumlanabilecek bir paragraf yok. Aksine: Çevik manifesto, bir plana uymak ve değişikliklere tepki vermek gibi seçenekleri tartır – ve diğer seçenek değerlendirilmeden değişikliklere tepki verme örneğinde, sadece daha az önemlidir. Gerçeklikteki bir değişikliğe tepki vermek, sabit plana bağlı kalmaktan daha mantıklı görünüyor, değişikliğin henüz görünmeyebileceği.
Daha da fazla sorun
Bu arada, çalışma 600 yazılım mühendisi üzerine bir ankete dayanmaktadır. Anketler sadece görüşülen kişinin, bu durumda yazılım mühendislerinin öznel görüntüsünü temsil edebilir. Yazılımın geliştirilmesi ekonomik bir yatırım olduğundan, diğer gruplara, özellikle ilgili farklı taraflara sormak mantıklı olacaktır. Sonunda projeleri görevlendiriyorlar. Yani projenin gerçekten bir başarısızlık olup olmadığını daha iyi değerlendirebilenler.
Ve çalışma başka bir soruyu cevapsız bırakıyor: Kaç proje net gereksinimleri var? Yüzde 10? Yüzde 25? Yüzde 90? Çalışma sadece istatistiksel olarak önemli ifadeler yapmanın yeterince büyük bir sayı olması gerektiği görülebilir. Birçok projenin belirsiz gereksinimleri varsa, bu önemli bir sorunun göstergesi olacaktır. Bir sonraki soru, onu çözüp çözemeyeceği ve nasıl çözeceğidir – ve cevaplaması o kadar kolay değildir. Gereksinimler sadece istenemez, ancak gerekirse, prensip nedeniyle belirtildiği gibi net değildir.
Ve şimdi?
Çalışma aslında blog yayınını uygulamıyor. Çevik yazılımın gelişimini itibarsızlaştırmak ve farklı bir yaklaşımı teşvik etmek şeffaf bir manevra. Ancak çalışmanın hala bir etkisi var: Çalışmaya iki farklı bağlamda atıfta bulunmak konusunda isteksiz oldum. Bu anlaşılabilir: yüzde 268 net bir sayıdır ve sonuç şaşırtıcıdır, çünkü çeviklik aslında daha fazla başarı elde etmelidir. Sadece içine bakmalısın! Gerçekten yaparsanız, hangi saçmalıkların orada olduğu hızlı bir şekilde netleşir. Bir YouTube videosu, çalışmanın açıkladığı gereksinimlerle ilgili sorunları değil, çevikliğin diğer yönlerini eleştirmek için kullandı. Eleştirinin haklı olduğu gerçeğine bakılmaksızın: video, dikkat çekmek için çalışmanın saçma sayısını kullanıyor.
Eğer sektörümüzde yaparsak, gerçekten neye yardımcı olduğunu öğrenmezsek ve hiçbir ilerleme yapılmadığı takdirde şaşırmamalıyız. Kaynaklarla eleştirel çalışmalar zaten okulda öğretilmektedir.
Çevikliğin “iyi” veya “kötü” olup olmadığını cevaplayamayız. Ancak: Uygulamada, yinelemelerde yazılım oluşturmamız gerektiği gerçeği tarihsel olarak çok erken olmuştur – prensip olarak insanlar ekiplerde yazılım geliştirmeye başlarken. Her ne kadar çevik projelerin aksine, nispeten istikrarlı gereksinimlere sahipsiniz. Prof. Christiane Floyd gibi öncüleri ve öncüleri dinlediğinizde bu netleşir. Ayrıca konuyla ilgili bir ders tuttum. Ayrıca, örneğin bir planı takip etmek yerine değişikliklere tepki vermenin iyi olan projeler olduğu da açık olmalıdır. Asıl sorun, çevikliğin bir terim olarak yakılması olabilir, çünkü gerçekte orijinal fikirleri karşılamayan ve özellikle yararlı olmayan “çevik” süreçler sunulur.
TL; Dr.
Sektörümüz eğilime karşı hassastır. Bu bir utanç. Belirgin ifadeler dikkat çekiyor.
(RME)