Uygulama geliştirme süreçlerinin içine girdiğinizde ve bunu daha iyi nasıl yaparım gibi sorular sormaya başladığınızda karşınıza bir çok süreç ve pratik çıkmaktadır.
Şirketin tamamını içine alan CMMI’dan tutunda Agile pratiklerine kadar bir çok yaklaşımla baş başa kalırsınız. Tüm bu pratik ve süreçleri incelediğinizde kendi içlerinde çok tutarlı olduklarını görürsünüz. Ama iş bu süreçleri firmanıza ve ekibinize uygulamaya geldiği zaman işler gerçekten değişmeye başlar. Başlarda yeni bir sevgilinin verdiği heyecan zaman içinde kaybolur. Bir bakmışsınız derin uçurumlarla bir birinden ayrılmış iki insan olmuşsunuz. Sonuçta suçlanan sürecin kendi veya “ekip buna uygun değil” tarzı yaklaşımlardır. Uzun süreli olan gözlemler ve düşünceler sonucunda bunun sebeplerini derledim. Herkesin bu kargaşanın aslında aykırı (anti pattern) geliştirme süreci olduğunu anlamasını istedim. Bundan nasıl kurtulabileceğimizi ortaya koymak ve kendimizi geliştirmek için bu makale serine başladım. Ben yaşadığımız bu aykırı uygulama geliştirme sürecine Boss Driven Development (Patron Güdümlü Geliştirme) adını koydum.
Boss Driven Development
Aslında BDD kaotik ortamlarda oluşan ve bireylerin bu kaosu aşmak için oluşturdukları geliştirme sürecinin adıdır. Popüler geliştirme süreçleri üzerinden bu konuyu daha iyi anlamanızı sağlamak adına Scrum sürecini kullanacağım. Dediğimiz gibi bir karmaşıklık durumumuz var. Bu karmaşıklığı gidermek için Scrum şu başlıkları ele alıyor.
- Şeffaflık: Projedeki ilerlemeler ve sorunlar günlük olarak tutulur ve herkes tarafından izlenebilir olması sağlanır.
- Denetleme : Ürünün parçaları ya da fonksiyonları düzenli aralıklarla teslim edilir ve değerlendirilir.
- Uyarlama: Ürün için gereksinimler en baştan bir defalığına belirlenmez, bilakis her teslimat tekrar değerlendirilir ve duruma göre uyarlamalar yapılır.
Şimdi Manifestoya bir kulak verirsek
Çevik Yazılım Geliştirme Manifestosu’na göre;
- 1) Süreçler ve araçlardan ziyade, bireyler ve etkileşimler
- 2) Kapsamlı dökümantasyondan ziyade, çalışan yazılım
- 3) Sözleşme pazarlıklarından ziyade, müşteri ile işbirliği
- 4) Bir plana bağlı kalmaktan ziyade, değişime cevap vermek
daha değerlidir…
Şimdi bu başlıkları baz alarak BDD genel yapısına bakalım. BDD her süreçte olduğu gibi kendine has rolleri üzerinde barındırır. Bu rolleri şu şekilde ele alabiliriz.
PATRON (BOSS)
Patron(BS) kelimesinden çoğunuz firma sahibi olarak anlamış olabilirsiniz. Aslında burada bahsedilen değimsel olarak patronluk taslayan kişi veya gruptur. Otoriter bir kişilik olarak düşünülebilir. Lakin bir startup baz alınırsa BS firma sahibi olabileceği gibi sürekli olarak işleri yönlendiren , kendi baskısıyla ve fikirleriyle işi yaptırtan veya işe sürekli karışan kişidir. Kendisi ekipteki yazılımcı, analist, yönetici hatta müşterinin ta kendisi olabilir. Burada ki ana durum işi kendi isteğine göre yönlendirmesidir. Daha doğrusu her noktaya yön verme isteğidir. Yazılım sürecinin akışını hepinizin bildiğini varsayıyorum. Bu akışlar içindeki döngüleri bilirsiniz. Yukarıdaki resimde bu döngüleri ve tekrarları görmüşsünüzdür. Bu tekrarlardan çıkış scrum için Tamamlandı (Done) kriteridir. Fakat BDD bunlardan çıkabilmek için BS’nin tamam demesi gerekir. BS tamam demedikçe siz bu akıştan çıkamazsınız. Şeklen göstermek gerekirse durum aşağıdaki gibidir.
Bu durumu vardıktan sonra patronun kendisi dahil olmak üzere herkesten şunu duymaya başlarsınız. İş bitmiyor. Ne yaparsak yapalım bitiremiyoruz. Sürekli olarak toplantılar yeniden planlamalar ve kaynak aktarımları yaparak bu işi düzeltmeye çalışıyoruz. Sonuç olarak sonsuz bir döngünün içinde dönmeye başlıyoruz.
Geliştirici Her Şey Dahil (Everything On board)
Bizim zamanımızda pcler pahalı olduğu için üzerinde her şeyi barındıran anakartları alırdık. Para oldukça ekran kartını ,modemini vs. sonradan alırdınız. Böylece zaman içinde güzel bir makinanız olurdu. Sözün kısası her şeyi yapması beklenen kişidir. Her şeyi bilmesi beklenir. Gerektiğinde test , analiz hatta kurulum ve eğitim vermesi de beklenir. Gerektiğinde kelimesinden dolayı yanlış anlaşılma olmasın gereksiz olduğu bir durum aslında hiç bir zaman yoktur. Bu zamana dönecek olursak havalı olan ilanlarda full stack developer olarak geçen şahsına münhasır kişidir.Tabii ki full stack olabilirsiniz. Ama ilanlar aslında bunu kastetmiyordur.
Scrum baz alındığında takım içerisinde yeteneksel dağılımlar ile bir atmosfer elde edilmesi sağlanır. Her şeyi bilmeniz değil ama konu hakkında en azından fikir sahibi olmanız beklenir. Zaman içindeki yeteneksel gelişimle takım birbirini destekler hale gelir. BDD ise imkansız olsa da uzman seviyesinde bilgi sahibi olduğunuz düşünülür. Aralarındaki büyük farkta budur.
Takım
Takım Analizci,Testçi ve Geliştirici üçlüsünden oluşur. Lakin çoğu zaman bu üç başlığı da geliştirici üstlenir. Takım bir birine bağlıdır. Hatta takım bu bağlılığı sürdürülebilirlik olarak görür. Takımı korumak çok önemlidir. Bu yüzden her şeyin üstü örtülür. Kısacası şeffaflık çok düşük düzeydedir. Takımın bu şekilde davranmasının en büyük sebebi ise BSdir.
Müşteri
Müşteriyi ele aldığımız zaman aslında müşteriyi beklentileri olan bir kişi gibi düşünebiliriz. Bu beklentiler az veya çok olabilir. İmkanlı veya imkansız istekleri de içerebilir. Bütün bunlar ele alındığında ekip olarak yapılması gereken bu beklentileri düzgün bir tabana oturtmaktır. BDD tarafındaki müşteriyi ele aldığımızda her müşteri gibi oda beklenti içerisindedir. Ama sürecin getirdikleri sonunda beklentisinin ne olduğunun bile farkında değildir. işte buda o sonsuz döngülerin ateşleyicisi ve başlangıcı olmuştur.
Scrum ise bu beklenti ve isterlerin yönetilebilir olması için müşteriyi de içimize almıştır. Böylece hem müşterinin bizi hem de bizim müşteriyi anlamamızın önü açılmıştır. Bu yakın çalışma sayesinde bir çok engel açılabilir olmuştur.
Planlama
Hangi sistemi kullanırsanız kullanın hatta sistemsizliği bile mutlaka bir planınız vardır. Planlamada bilişim teknolojilerini ele alacak olursak gerçekten de çokta başarılı tahminler üretemediğimiz tartışmasız bir gerçektir. Agile tekniklerine baktığımızda ise planın günlük veya döngüsel olarak yenilendiğini görürsünüz. Agile yaklaşımlarında amaç ortaya bir ürün koymaktır.
BDD ortamına girdiğinizde bir proje 3 ay bile sürecek olsa 1 ocakta lazımsa bitiş zamanı 1 ocaktır. Bunun için savaşılır. Peki BDD buna nasıl bir çözüm üretmiştir. Bu zaman aralığında ürünün teslim edilemeyeceği bellidir. Onun için BS ile sizin işinizi ne kadarıyla görebiliriz pazarlığı yapılır. Bu Scrum daki MVP ile benzerlik gösterir. Ama ne şefaftır ne de kalitelidir. Zaman verilirken testler buna katılmaz. Ürün yapılır ama testler sanki başkasının sorumluluğu gibi davranılır. Aslına bakarsanız bir çeşit oyun oynanır. Bu bir zaman kazanma yarışıdır. Tabii ki planlamada testin ve ürün kabulünün planda eksik veya hatalı hesaplanması günümüzün en büyük sorunları arasındadır. Fakat burada kabül yokmuş varsayılır.
Genel çizgileriyle BDD bu şekilde ele alınabilir. Bundan sonraki makalemizde bu paydaşların detayına giriyor olacağız.
Kaynaklar
Scrum.org
Vikipedia