Yazilim Gelistirme Ekibinin Butunselligi
Bir yazılım geliştirme ekibi nasıl olmalıdır sorusuna yazılım projesinin bağlamına, müşterisine, karakterine vs. göre farklı farklı cevaplar verilebilir ancak çoğu zaman gözlemlediğim ve beni rahatsız eden bir yapılanma şekli çok yaygın; rollere göre kurulan ayrı ayrı ekipler. Mimari ekip, altyapı ekibi, tasarım ekibi, geliştirme ekibi, test ekibi, analiz ekibi, kalite ekibi vs. Bu ekiplerin hepsinin başında bir lider ve bu liderler de hiyerarşide bir üstte birine(proje yöneticisi, proğram yöneticisi, çözüm yöneticisi, direktör vs.) bağlılar. Burada beni rahatsız eden temel konu bu ekiplerin bir birlerinden ayrı olarak kendi işlerini yapabilecekleri varsayımı.
Bu yapılanma kültürü sanırım biraz da waterfall yazılım geliştirme mantalitesi kaynaklı. Projenin her aşaması(analiz, tasarım, geliştirme, test) ayrı ve büyük tek aktiviteler olarak yapılır ve bu aktiviteleri de konusunda uzman ayrı ekipler yapar. Etkileşim vardır ancak bürokrasi de vardır, liderler farklıdır, ayrı grup mantığı vardır, çatışma çıkma olasılığı yüksektir.
Bana yazılım geliştirme sürecinin iterativ, üst üste konularak ilerleme şeklinde olması daha anlamlı geldiği için ekibin de bir bütün olması, gerekli olan farklı yeteneklere(analiz, test, dba, programcı, mimar vs.) sahip bir bütün olması daha mantıklı geliyor. Çünkü o kadar da ayrı gayrı işler yapmıyoruz tasarım, geliştirme, test, analiz bunlar aralarında ciddi ve sürekli bir etkileşim olması gereken, bir birlerinin farklı bakış açılarına muhtaç aktiviteler. Hepimiz aynı gemideyiz hepimizin amacı aynı; çalışan, doğru yazılımı doğru şekilde üretmek. Bu amacın ayrı ayrı ekipler ile çok etkin bir şekilde gerçekleştirildiğini veya gerçekleştirilebileceğini çok sanmıyorum.
Bence hangi ekipdesin sorusuna bir çalışan test, analist, geliştirme vs. diye cevap veriyorsa orada bir sorun vardır, ancak x projesi, y projesi diye cevap veriyorsa doğru bir bakış açısı vardır. Burada uzmanlık sağlanması, aynı role sahip insanların bir arada olmasının teknik bilgi beceri acısından faydaları gibi konuları yazılım geliştirmenin dışında tutuyorum. Bunları sağlamak icin illaki yazılım geliştirme ekiplerini bölmek gerekmiyor.
“Tek Takım”, “Tek Lider” gibi konular biraz daha açılabilir, üzerinde düşünülebilir konular. Örnek yapılanmalardan benim hoşuma gidenler Toyotanın şef mühendis mantığı ve spotify yazılım geliştirme ekiplerinin yapılanmaları var.