Yazılım Projelerinde Rol Dağılımı

Yazılım Projelerinde Rol Dağılımı

Bu yazımda küçük-orta ölçekli bir proje ekibindeki rollere ve bu rollerin sorumluluk alanlarına değinmeye çalışacağım.
Rolleri aşağıdaki şekilde kısaca özetleyebiliriz.
1) Proje yöneticisi
2) Analist/Çözümleyici
3) Mimar- teknik lider
4) Yazılım geliştirici
5) Test/Kalite Kontrol

1) Proje yöneticisi
Proje yöneticisinin görevi projenin önüne çıkan engelleri ortadan kaldırmak ve ekibin verimli çalışması, projenin zamanında teslimi için gerekli ortamı sağlamak, önlemleri almaktır. Örneğin teknik bir konuda ekibe dışardan yardım gerekiyorsa bu yardımı sağlamak, bir danışman tutmak proje yöneticisinin işidir. Ekibin kullandığı bilgisayar, yazılım geliştirme ortamındaki sorunların hızlı şekilde çözülmesini saglamak gene proje yöneticisinin işlevine örnek gösterilebilir. Proje yöneticisi aynı zamanda kritik kararları almakta da öncu rol oynar. Yazılımda kritik bir hata varsa yayım(release) tarihinin ertelenmesi buna örnek gösterilebilir. Bu örneklerden anlaşılabileceği üzere herşeyin yolunda gittiği bir projede proje yöneticisinin işlevi çok görünür değildir.
Proje yöneticisinin görevi yapılacak işleri küçük parçalara ayırıp daha sonra bunların zamanında bitirildiğini takip etmek değildir(Micromanagement). Bu tür yönetim tarzının günümüzde artık yeri yoktur. Yönetici ekibine güvenmeli, ekipe kararlar alabilmesi ve durumlara adapte olabilmesi için gerekli yetkiyi tanımalıdır (Empowerement of the team).
2) Analist/Çözümleyici
Çözümleyicinin görevi kullanıcı/müşteri grubuyla görüşerek iş gereksinimlerini (business requirements) i almaktır. Çözümleyiciler kullanıcı/müşteri ile ekibin diğer rolleri arasında(proxy) görev yapar. Ekip içinde müşteriyi çözümleyiciler temsil eder. Çözümleyici müşteri ile iletişim içindedir yazılım geliştiricilerin gereksinimler hakkında sordukları soruları en hızlı şekilde cevaplamaya çalışır. Cevaplayamadığı soruların cevabını müşteriye giderek bulur. Müşteriden aldığı bilgileri yazılım geliştiricilerin anlayabileceği formata çevirmek gene çözümleyicinin işidir. Çözümleyicinin kullandığı format kullanılan sürece bağlı olarak değişebilir. Örneğin XP de bu format hikaye kartları, RUP gibi bir süreçte kullanım senaryosu(use case dokümani) , Şelale gibi bir süreçte ise uzun bir doküman şeklinde olabilir.
Günümüzde Çözümleyici/ tasarımcı (Analist/Tasarımcı) gibi tanımlamalara rastlamak mümkün. Böyle bir rol tanımı bence çok büyük bir hata olur. Çözümleyiciler yapılan işin alan(domain) bilgisine sahip olmalidir ve yapılan projeyi kullanıcı/müşteri bakış açısından görebilen bir kafa yapısı ve yetenek gerektirir. Tasarım ise uygulamaya , yazılan koda yakın olmayı ve yuksek teknik bilgi seviyesi gerektirir. Uygulamanın tasarımından çözümleyici rolü sorumlu olmamalıdır.

Çözümleyici grubu proje ekibi küçükse QA/Test, Proje yöneticisi gibi rolleri de üstüne alabilir fakat Tasarım,Teknik liderlik, Yazılım geliştirici gibi roller başka ekip uyeleri tarafından yerine getirilmelidir.
3) Mimar- teknik lider
Yazılım mimarisi kısaca yazılımı oluşturan önemli/büyük bileşenler ve bunların organizasyonu, birbirleri ile iletişimleri ile ilgilidir. Bu mimari üzerine yazılım iş gereksinimleri tatmin edecek şekilde bina edilir. Mimarı aynı zamanda operasyonel performans gibi gereksinimleri de tatmin etmelidir. Mimar/teknik lider tıpkı diğer yazılım geliştiriciler gibi kod yazar fakat ayni zamanda genel mimarı ile ilgili kararları almaktan, tasarım çalışmalarında liderlik yapmaktan sorumludur. Mimar/teknik lider teknik işlerin zamanında ilerlemesinden proje yöneticisine karşı sorumludur. Bu açılardan değerlendirildiğinde mimar/teknik lideri diğer yazılım geliştiriclere göre yüksek teknik bilgiye sahip ve bu işlerden yöneticiye karşı sorumlu bir rol olarak görmek mümkündür.
4)Yazılım geliştirici
Yazılım geliştirici kodun tasarlanması ve yazılmasından sorumludur. Burada dikkat edileceği üzere tasarım ve kodun yazılmasını birbirinden ayırıp ayrı rollere yüklemedim. Bunun nedeni kodun tasarımı hazırlayan insan tarafından yazılması gerektiğine inanmamdan kaynaklanıyor. Günümüzde her ne kadar modelleme dilleri geçerlilik kazanmış olursa olsun, kodun yazımı sırasında her zaman tasarımda öngörülemeyen noktalar ortaya çıkacaktir. Diğer bir deyişle kodlama tasarımı etkileyecektir. Tasarım yazılım geliştiricilerin ve mimarın içinde bulunduğu bir ekip aktivitesi haline getirilebilir fakat tasarımcı , programcı gibi bir ayrıma gidilmemelidir.
Bu tür ayrımlara gidilmesinin kaynağında programcılığı ucuz bir kaynak haline getirme çabaları olduğunu düşünüyorum. Tasarımcı ile programcının ayrı rollere bölündüğü durumlarda iyi bir tasarım olduktan sonra düşük seviyede bir programcıda olsa bu tasarımı koda çevirmek kolay gibi çok ama çok yanlış bir mantığa rastlamak mümkün Diğer bir nokta tasarımcılarla ilgili. Tasarım yapılırken yüksek teknik bilgiye sahip olmak gerekli fakat tasarımcı ile programcı rolleri birbirinden ayrılırsa tasarımcı zamanla teknik bilgi seviyesini kaybedecek ve kaliteli tasarımlar üretmekten uzaklaşacaktir.
Projenin gereksinimlerine bağlı olarak yazılım geliştiriciler UI, Veritabani, Uygulama,Rapor geliştiricisi gibi rollere ayrılabilir.
5)Test/Kalite Kontrol
Test/Kalite Kontrol rolü kullanıcının bakış açısıyla yazılımı test etmekten sorumludur. Küçük projelerde bu rolü Analistler üstlenebilir fakat Test/Kalite Kontrol rolü hiçbir şekilde yazılımı geliştiren insanlara yaptırılmamalıdır. Kodun o kodu yazan insan tarafından test edilmemesi ve kullanıcı bakış açısıyla test edilmesi çok önemlidir. Yazılım geliştirici
yazılımı bu bakış açısından görmekte zorlanacaktir. Test/Kalite Kontrol test senaryolarını hazırlar gerekirse Rational Robot, Fit gibi programlar yardımıyla bizzat kod yazarak otomatik fonksiyonel testleri gerçekleştirir. Kullanici kabul testlerini koordine eder.

Türkiye de çoğu projede QA/Test rolünün es geçildiğini söylemek yalan olmaz. Bu testleri son kullanıcıya yaptırmak sanırım en çok rastlanılan durumlardan biri. Bir diğer problemde zaman darlığına giren projelerin çoğunun test aşamalarından zaman kısmaları. Sonuç olarak hatalarla dolu yazılımlarla karşılaşıyoruz.
Test/Kalite Kontrol rolünü kısmen teknik bilgi gerektiren(programcının yapabileceği hataları tahmin etmek açısından faydalı olacaktir) ve iş gereksinimleri anlayan, kullanıcı/müşteri gibi düşünebilen bir rol olarak görüyorum ve en az yazılım geliştiriciler kadar önemli olduğunu düşünüyorum. Umarım verilen iş ilanlarında gelecekte Test/Kalite Kontrol gibi ayrımları daha fazla görebiliriz.
Bu yazımda küçük/orta ölçekli bir projede çekirdek rol tanımları nasıl olmalı açıklamaya çalıştım. Proje büyüdükçe roller özelleşecektir ve yeni rol tanımları gerekecektir. Bunlara örnek vermek gerekirse
Kullanıcı arayüzü(UI) tasarımcısı ,
Kullanılabilirlik (usability) testcisi
Teknik yazar (dokümantasyon, yardım dosyaları),
Kurulum/Yayım mühendisı( kurulum işlemleri, konfigürasyon/versiyon yönetimi)
Rapor tasarımcısı
Sistem mimarı (hardware mimarisi)
gibi yeni roller eklenebilir.
Yorum ve eleştirilerinizi lütfen bana iletiniz.

Cenk Civici
Yazılım mühendisı

Başarılı Projelerin Ortak Özellikleri

BAŞARILI PROJELERİN ORTAK ÖZELLİKLERİ

Harvard Business School tarafından yapılan ve yaklaşık 2 yıl süren bir araştırma [MacCormack01] sonucu başarılı yazılım projelerinin aşağıdaki 4 özelliğe sahip oldukları görülmüştür.

1)Başarılı projeler yinelemeli (iterative) şekilde yazılım geliştirirler. Yazılımın müşteri için anlamlı bir parçası erken bir yayımla(release) teslim edilir ve yazılım teslimi diğer yinelemeler(iterations) ile devam eder. Müşteriden yayımlar(release) sonrası sürekli geri beslenim alınır. Yazılım bir evrim süreci sonucunda oluşur.

2)Yapılan değişiklikler sonrası günlük tümleştirme (daily integration) yapılır. Tümleştirme sonucu yazılımın durumu hakkında bağlanım(regression) testleri sayesinde hızlı bir şekilde geri beslenim alınır.

3)Yazılım geliştirme ekibi deneyimlidir.

4)Projenin başından itibaren yazılım mimarisine ve sistemin birbirinden bağımsız bileşenlerden oluşturulmasına dikkat edilir.

Buna benzer bir araştırmada Bell Labs tarafından yapılmış ve aşağıdaki özellikler saptanmıştır.

1)Yinelemeli(iterative) yazılım geliştirme ve yinelemelerin sonunda müşterinin geri beslenimi.
2)Basit organizasyon yapısı, rol tanımlarının gereksizce çoğaltılmaması.
3)Ekip içi iletişim.

Gördüğünüz gibi bu özellikler yinelemeli (iterative) yazılım süreçlerinin özelliklerine uyuyor. Özellikle çevik yazım süreçlerinin prensipleri ile birebir uygunluk sözkonuşu.

İlk araştırma sonuçlarının birinci maddesinde yinelemeli(iterative) şekilde yazılım geliştirmeden ve yazılımın çalışan bir parçasını erken teslim etmenin(early release) yararından bahsediliyor. Yazılımda çıkan hatalara hangi faktörlerin etki ettiği konusunda yapılan başka bir araştırmada birinci maddeyi doğrular nitelikte. Sonuçlara göre yazılımın %20 lik bölümünü erken teslim eden projenin ,yazılımın %40 'lık bölümünü daha geç teslim eden projeye oranla 10 faktör az hata içerdiği ortaya çıkıyor.

İkinci maddede günlük tümleştirme(daily integration) ve bağlanım(regression) testlerinden bahsediliyor. Hata faktörleri için yapılan araştırma bu pratiğin hataları 13 faktör azalttığını gösteriyor. 1 ve 2 numaralı özelliklerin projelere yüzde 50 ye yakın verimlilik kazandırdığı aynı araştırmada belirtiliyor.

Üçüncü madde ise insan kaynağının önemini vurguluyor. Çevik yazılım süreçleri bireyler ve ekip hayatına verdiği önemle bu özelliğe sahip durumda...

Dördüncü madde ise XP deki yüksek kalite hedefini ve tekrar tasarım(refactoring) ile yazılım tasarımının sürekli iyileştirilmesi pratiğini akla getiririyor

Burada yinelemeli(iteratıve) yazılım süreçlerinin başarılı olmasının nedenlerini kısaca bakalım.

1)Yinelemeli(iterative ) yazılım geliştirme süreçlerini kullanmak daha az risklidir.
2)Riskler önceden tespit edilebilir ve çözülebilir.
3)Proje süresince meydana gelebilecek değişikliklere çabuk tepki verebilir.
4)Projenin durumu hakkında daha fazla bilgi sağlar ve tekrarlar arttıkça tahminler
daha sağlıklı, kesin hale gelir.
5)Hatalar daha çabuk bulunur, kalite seviyesi yüksektir.
6)Sonuçta üretilen yazılım müşteri isteklerini daha iyi şekilde karşılar.
7)Erken ve sürekli süreç iyileştirmesine olanak verir.
8)İletişim ve koordinasyonu zorunlu kılar.
9)“Gördüğüm zaman anlarım” anlayışına ters düşmez.
Müşteriler ne istediklerini anlamak için bazen yazılımı görmeleri gerekir.
10)Tekrar kullanılabilirlik (reuse) için elverişli ortam yaratır.
11)Proje yöneticileri yerinde taktik kararlar alabilirler, insan kaynağı daha yerinde kullanılır.
12)Ekip üyeleri tekrarlar boyunca hatalarından dersler alır ve kendilerini geliştirir.

Standish grubunun 1998 de 23000 projeyi kapsayan yaptığı bir araştırmada [Standish98] projelerin başarısının en çok aşağıdaki 5 faktöre bağlı olduğu sonucuna varıyor. Faktörlerin ne kadar etkili olduğu yanlarında verilmiştir.

Kullanıcı/müşteri katılımı 20
Üst Yönetici desteği 15
Açık iş hedefleri(business objectives) 15
Deneyimli proje yöneticisi 15
Kısa aralıklı kilometre taşları 15

Bu faktörlerle çevik yazılım süreçleri arasında paralellik kurmak gene mümkün. Çevik yazılım süreçlerinde kullanıcı/müşteri yazılım geliştirme ekibinin aktif bir üyesi olarak çalışıyor ve sürekli geri beslenim sağlıyor. Yapılan kısa aralıklı teslimler ve demolar sayesinde üst yönetici desteği yüksek seviyede tutuluyor. Her yineleme plani(iteration plan) ve değişen öncelikler projenin gidişatının iş hedefleri doğrultusunda ilerlemesini sağlıyor. Son olarak kısa aralıklı yayımlar(release) ve sabit süreli yinelemeler(timeboxed iteration) kısa aralıklı kilometre taşları hedefini gerçekleştiriyor.

Yazar : Cenk Çivici
Kaynaklar :
Craig Larman, Agile and Iterative Development : A Manager's guide , ISBN: 0-131-1115-8
Jim Johnson et al. 1998. Chaos: A recipe for success, 1998. Published Report . The Standish Group
MacCormack, A. 2001. "Product-Developmen t Practices that work." MIT Sloan Management Review 42(2)