Tersine Bakış – Yazılım Proje Yönetimi ve Yazılım Geliştirme

Tersine Bakış – Yazılım Proje Yönetimi ve Yazılım Geliştirme

Gelin Yazılım Proje Yönetimi ve Yazlım Geliştirme Süreçlerine dair bir serüvene çıkalım. Bu serüvenden kim suçlu kim tukaka’nın peşinden koşmak yerine kaliteli yazılımın peşinden koşalım.

Yazılım Geliştirme Süreçlerini ekip bazında kabaca gruplayalım ve bu grupların görevleri üzerinden serüvene çıkalım.

1. Software Development Managers, Yazılım Birim Müdürleri
2. Project Managers, Proje Yöneticileri kısaca PM

• Business Analysts, İş Analistleri
• Team Leads, Yazılım Takım Liderleri
• Software Developers, Yazılım Geliştiriciler
• Testers, Testçiler

İlk gruptakiler iş/yönetim katmanın temsil ederken ikinci gruptakiler teknik/geliştirme katmanını temsil etmektedirler.

Genel kabuller çerçevesinde geliştirilen yazılım projelerini incelediğimizde iş analistleri yapılacak işi tanımlar, yazılım geliştiriciler işe süre verir, yöneticiler ise bu süreyi ne kadar kırpacaklarını ya da kaç tane adam eksilteceklerini bildirirler. Kimi durumlarda proje içeriğinin bile incelenmeden böylesine kısıtlamalara gidildiği görülmektedir. Bu satırları okuyan herkesin bu döngüye defalarca girdiğini ya da gireceğini söyleyebiliriz.

Bu döngüde ortaya çıkan bir yazılımın / projenin fail olması durumunda sorumlulukları şöyle oranlayabiliriz.

• %50 Proje Yönetimi
• %20 İş Analizi
• %20 Yazılım Geliştirme
• %10 Test Mekanizması

Başarıya ulaşmasını hiç düşünmedim bile çünkü bana göre “çalışsın yeter mantığı, nefes alsın yeter mantığı” kadar sapıkça bir düşüncedir. Ki mevcutta birçok proje bu mantıkla yapıldığından, ne o imrenerek baktığımız projeler ne de firmalar buralarda yetişmemektedir. Ya toprağımız çok verimsiz ya çiftçimiz çok cahil olmalı ki bir türlü ürün yetiştiremiyoruz.

Neyse bu fail olma durumunu açalım.

Bu durumda geliştiriciye yeterli imkanlar verilmemiştir. Yani geliştiricinin yüksek seviyeli tasarımlar altında kaliteli kod yazmasına imkan sağlanmamıştır. Zaman baskısı ile çalışsın yeter kıvamında bir ürün beklenmektedir. Çünkü bu ürün prodta çalıştığı anda yöneticiler kendilerinden daha üst kademede olanlara ya da şirket sahiplerine öylesine büyük bir projeyi böylesine kısa bir zamanda yapmış olmanın heyecanını anlatacaklar ve/veya gururunu yaşayacaklardır. Gelsin tebrikler, primler zamlar.

Bu durum belirli kesim için güzel fırsatlar yaratıyorken firma ve geliştirici ekibi perişan edebilir. Yazılım projesinin ‘fail’ olmaması yani çalışabilir olması ile ‘kaliteli’ yani yüksek performans değerlerine sahip olması farklı şeylerdir. Evet ekip olarak nefes alan bir proje yaptık. Ama nefesi kim alıyor belli değil. Bu proje prod ortamına alındığında gelecek hatalarla geliştirici ekip uğraşacağından zamanının çoğunu bu projenin sürdürülebilir olması için harcayacaktır. Nispeten büyük firmalarda geliştirici ekipler üzerinde birden çok proje sorumluluğu olduğundan bu projelerin sürdürülebilir olması yani desteklerinin verilmesi zamanla o ekibe başka bir iş yapma imkanı tanımamaktadır. Hal böyle olunca firma elindeki kaynakları boşa harcayarak para kaybetmektedir. Aslında kaş yaparken iki gözümüzü bile çıkardığımız zamanlar olduğuna şahit olmuşluğum vardır. Ama olsundu proje çalışıyor diyebilmek güzeldi.

Kaliteli / beklenen kabuller çerçevesinde geliştirilen yazılım projelerini incelediğimizde iş analistleri yapılacak işi tanımlar, yazılım geliştiriciler işe süre verir, yöneticiler ise kaliteli bir proje için tüm parametrelerin yerli yerinde belirlendiğini kontrol eder ve ona göre karar bildirirler. Bu karar süre kısaltma/uzatma, analiz yeniden düzenleme ve yazılım tasarımında değişikliğe gitme şeklinde ortaya çıkabilir. Aslında bu senaryo için yöneticilerin kendi tecrübelerini ekiplerine aktardıkları senaryo diyebiliriz. Burada al gülüm ver gülümden ziyade hep birlikte kaliteli bir proje ortaya koyma çabası vardır.

Bu döngüden çıkan yazılımların büyük oranla başarıya ulaşacaklarını söyleyebiliriz. Yine de bakış açımızı değiştirmeden bu döngüde ortaya çıkan bir yazılımın / projenin fail olması durumunda sorumlulukları şöyle oranlayabiliriz.

• %15 Proje Yönetimi
• %15 İş Analizi
• %40 Yazılım Geliştirme
• %30 Test Mekanizması

Yöneticiler yanlış ekip seçerek ya da zamanında denetleme yapmayarak projenin patlamasına neden olabilirler.

Analistler ise gereksinimlerde hata yaparak projenin baştan patlamasına neden olabilirler. Herşeye rağmen proje sonuna çıkan ürün beğenilmeyebilir. Bu da ihtimal dahilindedir ve başka bir tartışma konusudur. Biz düzgün tasarlanmış yüksek performanslı bir ürünü tartışıyoruz. Müşterinin beğenmemesi başka bir değerlendirme.

Yöneticiler her türlü imkanı yerli yerinde sağladılar ve hala proje patlamışsa esasında sorumlu olan iki atomik birim vardır.

1. Yazılım Geliştirme Ekibi
2. Test Ekibi

• Dikkat edilirse yazılım ve test ekiplerinin sorumlulukları neredeyse birbirlerine eşit derecededir.

Yazılım ekipleri kendilerine verilen imkanları iyi kullanamamışlardır. Burada iki neden yatıyor olabilir. İlki geliştiriciler işi umursamamış kaliteye özen göstermemişlerdir. İkincisi bu projeyi yapabilecek yetkinliğe sahip insanlar değillerdir.

• İlk durumdaki şahısların ne kendilerine ne işlerine saygıları olmadığından kovun gitsin. İnanın düşünmeye bile değmezler.
• İkinci gruptakiler biraz irdelenmelidir. Herşey yerli yerindeyken beklenen kalite ve performans değerlerinde kodlar üretemeyen geliştiricilere taşıyabileceklerinden fazla yük verilip verilmediği derinlemesine incelenmelidir. Ancak bu inceleme işin sonunda değil belirli aralıklarda yapılmalıdır. Böylece projede belirli aşamalarda bu soruna çözüm üretilebilir. Kaldı ki bu senaryodaki gibi projeye doğru yaklaşan yöneticiler projeyi aşama aşama izleyeceğinden bunu erkenden farkedecekler ve çözüm üreteceklerdir. Zamanında çözüm üretilmezse bu durum yöneticilerden kaynaklı fail durumudur.
• Bunların dışında mucbir sebepleri de çıkarsak ilk grup geliştiricilerden başka bir seçenek kalmayacaktır.

Test ekiplerine neden bu kadar sorumluluk yükledik? Herşeyin güzel gittiği senaryoda bile herkes kendi işine yoğunlaştığından projedeki hataları ve eksikleri yakalamak test ekibinin işidir. Tester hatayı ya da yanlış bir değerlendirmeyi (analize ters bir geliştirme) yakalamazsa ürün prod’ta bizzat müşteri tarafından patlatılır. Yani yazılımı geliştiren ekip ne kadar yüksek seviye tasarım kalıpları ve yazılım metodolojileri kullanırsa kullansın proje test edilerek olgunlaştırılmamışsa patlamaya hazır bomba kıvamındadır. Malesef ülkemizde en az önem verilen konu testtir. Çalıştığım kurumların neredeyse tamamında, ya testleri kendim yaptım ya test ekiplerine bizzat yardım ederek %50’sinin yapımına dahil oldum desem az söylemiş olurum. Test demek projenin kalitesinin, performansının oturması demektir.

Makalede dikkat çekmeye çalıştığım iki nokta bulunmaktadır.

1. Herkes kendi işini / kendi payına düşeni; en iyi, en kalitileli şekilde yapmalıdır.
2. Yazılım bir ekip işidir. Ekiplerden biri çökerse tüm sistem çöker.

Nedir bu ekip? Ekip çalışması nasıl olmalıdır. İş ilanlarında da sıkça gördüğümüz ekip çalışmasına yatkın arkadaş nasıl olmalıdır? Bir sonraki makalemizde tersine yazalım.