İçeriğe geçinAnemo
TR
İletişim

Yazılım Projesi Gerçekten Geride mi?

· 4 dk okuma

Durum raporu proje hakkında bir iddiadır. Dağıtım sıklığı, döngü süresi, yeniden yazım ve kalan listenin biçimi ise proje hakkında kanıttır. İkisi çeliştiğinde haklı olan kanıttır. Bunların hiçbirine bakmak için kod okumanız gerekmez.

Cevaplanmaya değer soru "geciktik mi" değildir, çünkü neredeyse her yazılım projesi ilk tahminine göre gecikir. Asıl soru, bunun üzerinde istikrarla çalışılan zor bir problem mi, yoksa sessizce durmuş bir proje mi olduğudur. Bu ikisi toplantıda birbirinin aynısı, kayıtta tamamen farklı görünür.

Önemli noktalar

Sinyal 1: Üretime ne sıklıkla bir şey çıkıyor

Son dört haftada kaç kez dağıtım yapıldığını sorun. Her ekip bunu bir dakikada cevaplayabilir; sayı kendi araçlarından çıkar.

Evrensel bir doğru rakam yoktur ve erken yapım aşamasındaki bir proje seyrek dağıtım yapabilir. Önemli olan yöndür. Haftada birkaç kez dağıtım yapan bir ekibin bir ay boyunca hiç yapmaması, bir şeye çarptıklarını gösterir. Aylar geçmiş ve hiç dağıtım yapmamış bir ekibin ise teslim tarihine yakın çok tatsız bir sürpriz olarak ortaya çıkacak bir yayına alma sorunu vardır.

Sinyal 2: Bir madde başlamaktan yayına kadar ne kadar sürüyor

Buna döngü süresi denir ve bir yazılım projesindeki en faydalı tek sayıdır. Yakın zamanda biten beş madde seçin. Her biri için, birinin başlamasıyla kullanılabilir hâle gelmesi arasında kaç gün geçti?

Maddelerin çoğu birkaç gün sürüyorsa ekip işi bitirebileceği parçalara bölmüş demektir ki bu, bir projenin teslim edileceğinin başlıca göstergesidir. Maddeler düzenli olarak üç dört hafta sürüyorsa iş parçalara bölünmüyordur ve böyle bir projedeki tahminlere hiçbir yönde güvenilemez.

Sinyal 3: Aynı alanlar tekrar tekrar geliyor mu

Sistemin hangi kısımlarının birden fazla kez yeniden yazıldığını ve nedenini sorun. İki farklı hikâye dinliyorsunuz.

"Fiyatlandırma mantığını üç kez değiştirdik çünkü iş kuralları üç kez değişti" bir kapsam sorunudur ve genelde düzeltmesi size düşer. "Sipariş modülünü yeniden yazdık çünkü ilk sürüm dayanmadı" bir kalite ya da yetkinlik sorunudur. İkisini de bilmek gerekir. Tekrarlayan yeniden yazım, bir projenin görünür ilerleme olmadan bütçe tüketmesinin en sık sebebidir.

Sinyal 4: Kalan liste büyüyor mu, küçülüyor mu

Kalan işin listesini, her madde tek satır olacak şekilde yazılı isteyin. İki hafta sonra tekrar isteyin.

Küçülen liste kapanmakta olan bir projedir. İş yapılırken büyüyen liste, hâlâ ne olduğunu keşfetmekte olan bir projedir; bu erken dönemde normal, geç dönemde endişe vericidir. Maddeler kapanırken uzunluğu aynı kalan liste, yeni işin bitenle aynı hızda geldiğini gösterir ki bu, bir karar verilmeden asla bitmeyecek bir projenin tanımıdır.

Durmuş bir projeyi en sık ortaya çıkaran sinyal budur, çünkü liste sessizce iki katına çıkarken tarih yerinde durabilir.

Dördünü birlikte okumak

Gördüğünüz Genelde anlamı Yapılacak
Düzenli dağıtım, kısa döngü, küçülen liste Yolunda; kötü bir tahmine göre gecikmiş olabilir Kapsamı iş sonucuna indirin
Düzenli dağıtım, büyüyen liste Kapsam kontrol edilmiyor Listeyi dondurun, ne çıkacağına karar verin
Dağıtım yok, uzun döngü Tıkanmış ya da boğulmuş, genelde altyapıda Engeli bulun, destek düşünün
Raporlar iyi, yukarıdakilerin hiçbiri görünmüyor Raporlar işi anlatmıyor Teknik birinin bakması gerekir

Rahatsız edici olan son satırdır. Anlatı sağlıklıysa ve dört sinyalden hiçbiri bunu desteklemiyorsa, bulgu tam olarak bu açıklıktır.

Öğrendikten sonra ne yapmalı

Proje zor ama ilerliyorsa cevap neredeyse her zaman kişi ya da baskı eklemek değil kapsam kısmaktır. Başlangıçta istediğiniz iş sonucunu getiren en küçük sürümü belirleyin ve onu çıkarın. Kalan her şey ikinci sürüm olur ki bu, kaçırılmış bir lansmandan çok daha kolay bir konuşmadır.

Proje durmuşsa hiçbir raporlama onu yeniden başlatmaz. Teknik birinin işin kendisini okuyup neyin doğru olduğunu söylemesi gerekir; bu bir durum toplantısından farklı bir çalışmadır. Neleri içerdiğini teknik denetim yazısında anlattık.

Sık sorulan sorular

Ekibim bu ölçütlerin bizim işimiz için anlamlı olmadığını söylüyor. Haklılar mı?

Bazen haklıdırlar ve gerekçeyi dinlemeye değer. Örneğin mağaza onayı bekleyen bir uygulamada dağıtım sıklığı pek bir şey ifade etmez. Ama dört sinyalin dördüne birden alternatif sunmadan itiraz eden bir ekip, bu ölçütlere değil ölçülmeye itiraz ediyordur ve bu da başlı başına bilgidir.

Ne kadar gecikme normaldir?

Özel yazılımda ilk tahminler çoğu zaman geniş bir farkla iyimserdir ve bu tek başına sorun işareti değildir. Normal bir sapmayı başarısız bir projeden ayıran şey, tahminin yakınsayıp yakınsamadığıdır. Tarihi iki kez öteleyip üçüncüsünden emin olan ekip genelde iyidir; beşinci tarihindeki ekip tahmin etmiyor, umuyordur.

Bu sayıları doğrudan istemek düşmanca görünür mü?

Kötü habere tepki olarak değil, rutinin parçası olarak isteyin. Sakin bir haftada bir kez tanıtılıp her ay tekrarlanırsa sıradanlaşır. İlk kez kriz anında istenirse suçlama gibi okunur ve gerçek sayılar yerine savunulmuş sayılar alırsınız.

Sayıları alsam da yorumlayamıyorsam?

Bu normal sonuçtur ve sayıları toplamak yine de değerlidir, çünkü işi eğilim yapar. Kendi projeniz için ne anlama geldiklerine dair bir görüş isterseniz bize gönderin, gördüğümüzü söyleyelim.

Bu işte nasıl çalışırız

İlgili yazılar

Uçtan uca ürün ortağınız

Yeniden yazılması gereken üç ürün yerine, ayakta kalan tek bir ürün teslim etmeyi tercih ederiz. Bu ölçü, büyüklüğü ne olursa olsun her projede aynıdır.

Ali Boran GazelCEO

Bize ulaşın