Agile projelerinin ve dönüşüm girişimlerinin araştırmak için çalışmaya başladığımdan beri, Agile'ın en dindar takipçileri arasında var olan köktencilikle yüz yüze geldim. yüksek başarısızlık oranını Bir inanç şifacısının savunmasız hastaları, sahte bir tedavinin işe yaramaması sonucu bir hastalığa yenik düştüğünde (genellikle hatırı sayılır miktarda para 'bağışlamış'tır), 'şifacı' sıklıkla bunun hastanın hatası olduğunu, çünkü çok fazla dua etmediğini iddia edecektir. yeterli. Bu, Derren Brown'un TV özel ve teatral olarak Netflix özel uzun uzadıya araştırdığı bir konu. Böyle bir yanılgı genellikle " " yanılgısının bir versiyonu veya " " olarak tanımlanır. Miracles for Sale'de Miracle'ında Gerçek İskoçyalı yok saflığa çağrı Agile topluluğundaki köktenciler, Agile projeleri başarısız olduğunda sıklıkla benzer iddiaları kullanacaklardır. Örneğin, “ ”, diye yazıyor Greg Kihlstrom: Agile'da Başarısız mı Olmak? Yanlış Yapıyorsun Örnek olarak, takımınızda mümkün olan en hevesli Scrum Master'ı bulundurabilirsiniz, ancak ürün ekibinizde bazı karşı çıkanlar veya basitçe takip etmeyen veya ne yapılması gerektiğini anlamayan kişiler varsa, zorluklarla karşılaşacaksınız. Bazen bu bir eğitim veya antrenörlük meselesi, bazen de takım dinamiği ve kültürü meselesi. Sebebin ne olduğunu belirleyin ve ona göre müdahale edin. Ancak böyle bir inanışın bilimsel temeli mevcut değildir. ' başlıklı Kasım 2021 tarihli bir makale, bilimsel Çevik çalışmalara ilişkin çok sayıda incelemenin bir meta-analizini gerçekleştirdi ve şunu buldu: "Üçüncül çalışmanın sonucu, aslında, Çevik metodoloji en iyi ihtimalle azdır.” ' Kanıtsız En İyi Uygulama - Örnek Olarak Çevik Yazılım Metodolojisi Ancak konu Agile olduğunda köktenci bir duruş sergileyenlerin benimsediği tek bilişsel önyargı bu değil. Bu yazıda Agile metodolojisini meşrulaştırmak için sıklıkla kullanılan basit yöntemlere odaklanmak istiyorum. Çevik Strawman nedir? LinkedIn'in Çevik topluluğunda aşağıdaki gibi gönderileri görmek alışılmadık bir durum değil; görünüşe göre bir Çevik uygulayıcının zeki görünmesini sağlayan ve onu sorgulamaya cesaret eden bir yazılım mühendisinin karşısında metodolojiyi haklı çıkaran bir konuşma. Kişisel görüşüm bu konuşmaların genel olarak kurgu olduğu yönündedir: Oxford İngilizce Sözlüğü, saman adamın tanımı olarak aşağıdakileri sağlar: Bir tartışmada, münazarada vb.: kasıtlı olarak zayıf veya yanlış sunulan bir öneri, mağlup edilmesi daha kolay olduğu için veya rakibin gerçek argümanından dikkati başka yöne çeken, orijinal suçlamanın çürütüldüğü veya mağlup edildiğine dair yüzeysel bir izlenim veren bir teklif. . Ancak Agile önermesinin tam kalbine giden çok daha köklü sapkınlar var. SecretGeek web sitesindeki bir makale şu soruyu ortaya koyuyor: “ ”. Yazar, ritüellerden doktrine kadar Agile'ın diğer dogmatik unsurlarının gerçekten de yerli yerinde olduğunu iddia ederken, tartıştıkları tek alan Agile'da bir 'mitoloji'nin olup olmadığıydı. 'Çevik' bir din midir? (veya yalnızca bir tarikat) Bu saman adamların temelde Agile mitolojisini oluşturan şey olduğuna inanıyorum. Şelale Efsanesi Şelale tartışılmadan Agile'ın tartışıldığını görmek zordur. Agile'ın zıt olduğu varsayılan bir proje yönetimi metodolojisi. Kesinlikle belgelenmiş adımlar gerektiren ve hiçbir zaman değişiklik yapılmayan bir metodoloji. Ancak bu şu soruyu akla getiriyor: Şelale konferansları veya kullanıcı grupları tarihsel olarak nerede? Belki metodolojinin kökenleri bize bazı ipuçları verecektir. Jon Pearce, San Jose Eyalet Üniversitesi'ndeki şöyle diyor: “ ” ders notlarında Şelale Yaşam Döngüsü Modeli, yaşam döngüsü modellerinin en önemli adamıdır. İlk kez 1970 yılında Wynn Royce tarafından kusurlu bir sürecin örneği olarak tanımlandı… Yazılım geliştiricisi Christian Findlay : . , X'teki bir gönderisinde benzer bir noktaya değinerek şunları ifade etti "Şelale yaklaşımı aslında hiçbir zaman var olmayan bir saman adamdır" Ancak Agile'ın tarihine ilerledikçe durum daha da karanlıklaşıyor. Toyota Efsanesi Toyota Üretim Sistemi (TPS), Çevik metodolojinin manevi doğum yeridir. Dönüşüm girişimlerinin ezici çoğunluğunun başarısız olmasına rağmen, birçoğu Toyota tarafından kullanılan metodolojiye işaret edecek. Ancak Toyota'nın yazılım mühendisliği konusunda ideal olmayan bir geçmişi var. : "Toyota'nın Eylül 2019'da sunduğu bir mahkeme belgesine göre, Toyota 2014'ten bu yana, insanları öldüren veya ciddi şekilde yaralayan kazalarla ilgili ani hızlanmayı suçlayan 537 iddiayı sorumluluk kabul etmeden karara bağladı". Capitol Weekly'de yayınlanan bir raporda şöyle belirtiliyor Bu istenmeyen hızlanma kusurları birçok durumda sadece ölümcül olmakla kalmadı, aynı zamanda Koua Fong Lee vakasında kusur yalnızca hamile karısını ve çocuklarını kiliseden eve götürürken üç kişinin ölümüne ve diğerlerinin yaralanmasına neden olan bir araba kazasına yol açmakla kalmadı, aynı zamanda suçlanarak hapis cezasına çarptırıldı. Mahkeme duruşmalarında Toyota, aracın neden dengesiz davrandığına dair teoriye sağlam test protokolleri iddiasıyla karşı çıkmaya çalışmıştı, ancak duruşmadan kısa bir süre önce Toyota, o mühendisten belirten bir beyanda bulundu. şirketin aslında böyle bir test yapmadığını Lee, kendisini serbest bırakacak ancak suçlu olarak damgalanmasına neden olacak sonra, yeniden yargılama kararı verilmesinin ardından sonunda serbest bırakıldı ve savcılık, davayı tekrar mahkemeye göndermeyi reddetti. bir savunma anlaşmasını yapmayı reddettikten Bookout V. Toyota vakası, ölümlere yol açan başka bir kasıtsız hızlanma hatasının ardından Toyota'nın yazılım mühendisliği uygulamalarına odaklanılmasını sağladı. Nihayetinde yazılım sistemlerinin istenmeyen hızlanmaya neden olabileceğini tespit eden bu işlemler sırasında, Toyota içindeki dahili iletişim de dahil olmak üzere, "gerçekte arıza güvenliği gibi teknolojilerin Toyota Mühendislik bölümünün DNA'sının bir parçası olmadığını" belirten kanıtlar gösterildi: Bu vakanın ardından Toyota'nın, havacılık gibi yüksek güvenilirlikli ortamlarda benimsenen bir yaklaşım olan katı tasarım sözleşmelerinin yazılımın doğruluğunu matematiksel olarak doğrulamaya yardımcı olduğu SPARK Ada dilini kullanarak, yüksek güvenilirliğe sahip projeler için yazılım mühendisliğine yönelik geleneksel bir yaklaşımı benimsediği ve savunma. bildirildi. "Sözleşmeye göre tasarım" olarak bilinen bu yaklaşım, ilk olarak kendisi de " " kitabını yazan Fransız yazılım mühendisi Bertrand Meyer tarafından icat edildi. Meyer'in Agile'a yönelik eleştirileri arasında ön tasarımın reddedilmesi ve genelleştirilebilir spesifikasyonlar yerine kullanıcı hikayelerine odaklanılması yer alıyor. Agile!: The Good, the Hype and the Ugly Bu eleştiriler Edensoft Labs'ın " " adlı videoda daha ayrıntılı olarak anlatılıyor: Çevikliğin Çirkinliği (Dr. Bertrand Meyer ile birlikte) https://youtube.com/watch?v=Xi4WG-FVT6Q Çözüm Agile'daki çeşitli pipetler, etkinliği henüz kanıtlanmamış çözümleri benimsemeden önce hepimizin eleştirel davranmasının önemini bize vurguluyor. Beni yanlış anlamayın, hayattaki her kararı vermek için randomize kontrollü çalışmaların sistematik incelemelerinin meta-analizlerine ihtiyacımız yok, ancak daha düşük kanıtsal temele kıyasla daha yüksek kanıtsal temele sahip kanıtları göz ardı ederken dikkatli olmalıyız ( otorite figürleri tarafından bize dogmatik gerçek olarak sunulanlar gibi). İnsanlar olarak dönüşüm hikayeleri, tüm zorluklara rağmen yüreklerimizi sızlatıyor ve hepimiz bizi iyileştirebilecek süper kahramanların olduğuna inanmak istiyoruz. Ancak körü körüne şüphecilik de sıklıkla kendimizi toplumu ilerleten gelişmelerden uzak tutmamıza yol açabilir. Bu duygusal yönleri kabul etmek yerine görmezden gelmeyi denediğimizde, rasyonel kararlar almaya çalıştığımızda kendimizi daha çok onların insafına kalmış halde buluruz. " " kitabını yazdığımdan beri en dikkat çekici bulduğum şeylerden biri, Çevik görüş ayrılığının her iki tarafındaki en dogmatik kişilerin, projenin büyük kısmını oluşturan duygusal ve psikolojik yönleri nasıl görmezden geldiğidir. Kanıtların bana gösterdiği gibi, kitap ve bunlar gerçekten başarılı dönüşüm girişimlerinin kalbinde yer alıyor. Etki Mühendisliği: Çevik Proje Yönetiminin Ötesinde Dönüşüm Bu, tavşan deliğinin çok derinlerine inmeden önce, bilim ve mühendislik derslerinin, gerçekten dikkate değer keşiflerin kalbinde yer alan ortodoksluğu sorgulamak ve kanıt toplamak olduğunu hatırlamamız gerektiğine dair kesin bir hatırlatma sunuyor.
