Extreme Programming ve Scrum gibi çevik süreçlerin popüler olmasının sebebi, müşteri gereksinimlerini tatmin edebilen yazılım sistemlerinin oluşturulma sürecini kolaylastırmalarında yatmaktadır. Bu böyle olunca, yazılım firmaları, yıllarca şelala (Waterfall) metodundan çektikleri sıkıntılardan kurtulmak amacıyla çevik süreçlerin adaptasyonuna yönelmektedirler. Doğal olarak burada firmaların çevik sürecin adaptasyonu esnasında kafalarında oluşan bazı sorular var. Bunlardan en önemli iki soru şöyle:
- Çevik sürece hemen ve tüm neticelerine katlanarak mı geçilmeli?
- Çevik süreç adım adım mı yerleştirilmeli?
Bu soruların cevaplandırılabilmesi, firma ve sahip olduğu çalışanlarının çalışma kültürü ile doğrudan orantılıdır. Genelde çevik sürecin uygulanmasının önündeki en büyük engellerden birisi, çalışanların sahip oldukları alışkanları ve çalışma yöntemleridir. Çalışanlar yeniliklere ve değişikliklere içgüdüsel olarak karşı koyarlar. Bu yüzden çevik sürece geciş gibi çok yan etkileri olabilecek bir girişimin başarısı, çalışanların değişimle yaşayabilme özellikleriyle doğrudan orantılıdır.
Çevik süreci adapte etmiş bir çok takım, yazılım esnasında içinden çıkılamaz problemlerle karşılaşmakta ve doğal olarak suçu çevik süreçte bulmaktadırlar. Acaba suç gerçekten çevik süreçte mi?
Eğer bir takım “çevik süreci adapte ettik, lakin karşılaştığımız sorunlar günden güne artıyor, işin içinden çıkamıyoruz” şeklinde kendini savunuyorsa, o zaman o takımın, çevik süreci nasıl adapte ettiğinin incelenmesinde fayda vardır. İzlenimlerime göre, böyle takımlar tarafından çevik süreç ya yanlış ya da eksik olarak adapte edilmektedir. Örneğin birçok takım sadece Scrum kullanarak çevik olabileceklerini düşünüyorlar. Scrum hiçbir yazılım mühendisliği metodu ihtiva etmez! Eğer çevik olmak istiyorsanız, yazılım metotlarınızın çevik olması gerekmektedir. Bunu da en iyi sağlayayan Extreme Programming‘dir. Extreme Programming eşli programlama (pair programming – PP), sürekli entegrasyon (continuous integration – CI), test güdümlü yazılım (test driven development – TDD), müşteri ile beraber çalışma (on site customer) gibi birçok metoda sahiptir. Bu metotlar uygulandığı taktirde çevik çalışma ortamı oluşturulabilir ve oluşan sorunlar ortadan kaldırılabilir. Bu Scrum’ın gereksiz olduğu anlamına gelmez. Scrum proje planlama ve yönetme alanında kendine has yöntemleri ile çevik sürece katkıda bulunur. Scrum Extreme Programming ile birleştiği anda çevik süreç, gerçek ve oluşan sorunları aşabilen bir çevik süreç haline gelir, çünkü sorunları aşabilmek için ekibin elinde bir çok yeni teknik metot (PP, CI, TDD) bulunmaktadır. İşte çevik olmak isteyipte, olamayan takımların ana sorunu, PP, CI ve TDD gibi metotları tanımamaları ve bu yüzden dolayı uygulayamamaların da yatmaktadır. Atalarımızın da dediği gibi “alet çalışır, el övünür”. Eğer çekiciniz yoksa, çiviyi çakamassınız. Eğer sürekli entegrasyon yapmıyorsanız, o zaman müşteriye kısa aralıklarla, çalışan entegre bir prototip sunamazsınız. Test güdümlü çalışmıyorsanız, kodu yeniden yapılandırmanız (refactoring) hemen hemen imkansız hale gelir. Eğer kodu yeniden yapılandırmanız mümkün değilse, müşterinin yeni gereksinimlerini ya da istediği değişiklikleri implemente etmeniz imkansız hale gelir. Eğer eşli programlamıyorsanız, programcılar aynı seviyede koda hakım olamaz ve kod sahiplenmeleri başlar!
Şelale modelinden XP gibi bir çevik sürece geciç, hiç unit test yazmamış bir programcının, birden bire TDD tarzı programlama ile yüzyüze gelmesi gibi birşeydir. Daha öncede belirttiğim gibi takımın bu gibi radikal değişikliklerle yaşayabilmesi ve kabullenmesi çok önemlidir. Şimdi çevik sürece geçişin nasıl olması gerektiğini, yazının başında yer alan iki soruya doğrudan cevap vererek inceleyelim.
Çevik süreç adım adım mı yerleştirilmeli?
Çoğu takım çevik sürece adım adım geçmeyi tercih etmektedir. Genelde takımın içinde bulunduğu ortam bu tür bir kararın verilmesini zorunlu kılmaktadır. Çevik sürece adım adım geçiş çogu zaman çok uzun sürebileceği için başarılı olmayacaktır. Buradaki başarısızlığın en önemli faktörü yine takım elemanlarının kendileridir. Takım elemanları sahip oldukları çalışma alışkanlıklarını bırakmakta çok zorlanacak ve dolaylı olarak istemeyerekte olsa yeni yerleştirilmeye çalışılan çevik süreci sabote edeceklerdir. Burada yeni çevik metotlar adapte edilerek, yazılımcı bir nevi soğuk suyun içine atılmalı ve yeni metotlarla yüzmeyi yani çalışmayı ögrenmesi sağlanmalıdır. Ancak bu şekilde sahış, değişikligi şok terapisi ile kabullenme eğiliminde olacaktır. Bu eski kuramların ve çalışma metotlarının tekneden atılmasını kolaylaştırır.
Çevik sürece hemen ve tüm neticelerine katlanarak mı geçilmeli?
Bu sorunun cevabı nettir: evet! Tamamen çevik bir yazılım modeline geçmek istiyorsanız, o zaman şimdiye kadar yaptıklarınızı unutmanız gerekiyor. Bu, şimdiye kadar çevik çalışmadığınız anlamına gelmez. Ama doğal olarak her çalışma ekibinin kendine has yöntemleri var ve bunları değiştirmeleri çok zor. Bu yüzden bir celsede çevik sürece geçip, uygulamaya başlanması gerekiyor, aksi taktirde çevik süreç işlemeyecektir.
XP nin temel prensiplerinden birisi de cesaret. Ekibin ve firmanın yeni bir başlangıç için tüm gücünü kullanıp, tam anlamıyla çevik sürece geçmesi lazım, yarı gönülle bu iş ne yazık ki yürümez!
Kısaca özetleyecek olursak:
- Çevik sürece geciş hemen olmalı. TDD, CI, PP gibi teknikler hemen öğrenilmeli, zamana bırakılmamalı.
- Sadece Scrum ile çevik olunması imkansız. Scrum’ın yanında XP ya da FDD gibi teknik metotlar içeren bir çevik sürecin kullanılması gerekli. Gerekli teknik araçlar olmadan bir ev inşa etmeniz imkansız!
Merhaba;
Yakın zamanda web sitenizi keşfettim.
Çevik süreçle ilgili yazılarınız gerçekten çok güzel.
Makale bölümündeki tüm yazılarınızı okudum.
Teşekkür ederim.