Çevik Bir Proje Nasıl Sabote Edilir?
‘Better Software’ dergisinin Temmuz/Ağustos sayısında yayınlanan Clinton Keith ve Mike Cohn tarafından hazırlanmış ‘How To Fail with Agile’ yazısını incelemenin yararlı olacağına inanıyorum. Yazıda yer alan 20 madde, başarıdan nasıl kaçınabileceğinizin ipuçlarını veriyor. Diğer makalelerden farklı olarak burada amaç ‘başarısızlık’! Tüm maddeler dört farklı kategoriye ayrılmış; yönetim, takım, ürün sahibi ve süreç. Çevik bir proje nasıl sabote edilir?
Yönetici Hamleleri
İlk kural olarak; proje ekibine ve çevik yaklaşım pratiklerine kesinlikle güvenmeyin. Günlük proje toplantılarında ilerlemeyi ve varsa problemleri belirlemeye çalışsanız da, çevreye hissettirdiğiniz güvensizlik ile projenin mevcut durumu hakkında doğrulara ulaşamayacaksınızdır. Sonuçta proje, hedefleri tutturamayacak, kilometre taşlarına zamanında erişemeyecek duruma ister istemez gelecektir. Problemler birikecek ve takımın verimliliği yerlerde sürünen seviyelerde olacaktır. İşte bu noktada ikinci kural devreye girmelidir. Çevik yaklaşımı ve pratiklerini suçlayın!
Çevik ekipler kendi kendilerini kolayca organize edebildikleri için belirli ölçüde kendilerini yönetebilmektedir. Fakat, liderlik ve doğru yönlendirmeler için ‘ürün sahibine’ ihtiyaç duyarlar. Ürün sahibi, ilerleyen süreçte ekibin önünü görmesine yardımcı olur ve hedeflere ulaşabilmek için takım içerisinde gerekli motivasyonun sürekli korunmasını sağlar. Sonucunda ekibin verimliliği ve üretkenliği yükselir. Bu durumun oluşmasına izin verilmemesi gerekmektedir. Hemen üçüncü kural uygulanmalı, yönetim ve liderlik eşdeğer kabul edilerek ekibe kılavuzluk edebilecek unsurlar ortadan kaldırılmalıdır. Ayrıca, projeyi sabote edebilmek için ekibin içerisinde yükseldiğini gözlemlediğiniz çevik pratiklerini bilerek aksatmaya başlamalısınız. Mesela, günlük hedeflerde gün içerisinde değişikliğe gidin, öncelikleri sürekli değiştirin. Çevik pratiklerin ekip içerisinde köklenmesini engellediğinizden tamamen emin olmak için beşinci kuralı da kararlılıkla işletmelisiniz. Ekibin çevik yöntemler hakkındaki inancını önemsemeyin ve bunu belli edin.
Takım Hamleleri
Çevik bir projeyi baltalayabilmek için proje yöneticisi olmanız şart değildir, ekibin bir üyesi olarak içeride de yapabileceğiniz birçok hamle var. Altıncı hamle olarak; planlanan hedefleri tutturamayın ve çıktıları sürümleri zamanında yayınlayamayın. Ama bunu yaparken dikkatli olmanız gerekmekte, son gün çırpınmaları ile kilometre taşlarına bir şekilde ulaşabilmelisiniz. Böylelikle yedinci altın kuralıda uygulamaya kolaylıkla alabilirsiniz. Ürün sahibini her bir safha içerisinde sonuçta nasıl bir ürünün ortaya çıkacağını sürekli tahmin eder duruma getirebilirsiniz. Başarı için olması gereken ise bu durumun tam tersidir. Ürün sahibi her bir safha sonucunda elde edilecek ürünü tanımlamış durumdadır ve bu ürüne ulaşma yolunda takımı sürekli yönlendirmekte ve motive etmektedir. Fakat, yazının başında da yer aldığı üzere bizim amacımız ‘başarısızlık’, bu yüzden tüm hamlelerimiz olumsuz yönde olmalı.
Çevik yöntemlerle geliştirilen bir projeyi baltalamanın belki de en basit yolu; takımları fonksiyonel olarak ayrılmış şekilde oluşturun. Sekizinci kural; tüm test elemanlarını bir takım, tüm programcıları bir başka takım vb. şekilde ekipleri kurun. Bir takım içerisinde testçi ve programcının bir arada bulunmaması gerekmektedir. Bir başka sabotaj yöntemi olarak; 20 kişilik tek bir takım kurulabilir. Bu konuda yapılmış bilimsel çalışmaların tümünü yok sayarak büyük projenin büyük bir takıma ihtiyacı vardır diye düşünmelisiniz. Günlük proje toplantısına ekipte yer alan 50 kişiyi davet etmeli ve toplantıları bu şekilde gerçekleştirmelisiniz.
Bu ay, çevik bir projeyi sabote etme yöntemlerinin yer aldığı dört farklı kategoriden ilk ikisini, yönetim ve takım alanlarını, irdeledik. Önümüzdeki ay ürün sahibi ve süreç alanları ile devam edeceğiz. Bu arada, Eylül ayında yayınlanan CMMI raporuna göre yüksek seviye olgunluk pratiklerine ilgi her ay belirli bir ivme ile artmakta. Aynı raporda, Türkiye’de CMMI belgesine sahip toplam 11 şirket bulunmakta, bunların 9’u 3üncü seviye ve 2’si 5nci seviye olarak belirtilmiş.
Ülkemizde yazılım mühendisliği ve yönetimi alanındaki çalışmaların artması dileğiyle.
Yanıt Bırak