Her ne kadar yazılım geliştirme yöntemlerinin isimlerini projeye başlamadan önce sık sık kullanarak plan yapılsa da işler bir noktaya geldiğinde artık yöntemler sorgulanamaz hale gelmektedir. Amaç günü kurtarmak olduysa da artık yazılımın kalitesini sorgulamak kimsenin bir derdi olmaz. Müşteriden gelen negatif feeback'ler giderildiğinde ekip görevini yapmış sayılmaya başlar.
Elbette böyle bir durumu asla istemiyoruz. Hedefimiz daima tercih ettiğimiz geliştirme yöntemlerine bağlı kalmak, ve her aşamada projenin sağlıklı şekilde ilerlemesini sağlamaktır. Ama gerçek dünya tüm işleri planladığınız şekilde gitmesi için çok uygun değil, sürekli değişim içinde. Buna adapte olmaya çalışan yazılım ekiplerinin işleri gerçekten zor ve bu nedenle yazılım geliştirme yöntemleri konusunda standartlaşmaya ihtiyaç duyulmuştur.
Extreme programing şeklinde bir yöntem çıkmadan önce yazılımcıların kullanmaya başladığı ve fayda gördüğü metotlar gelişmişti. Bu metotların birbiriyle birlikte kullanımı ile daha büyük başarı elde edilmesi sonucu da bu yöntemlerin tümüne bir isim belirlendi ve Extreme Programing doğmuş oldu.
Bu metotta birçok yöntem var ancak en önemlileri üzerinde biraz durmak istiyorum.
- Kod Kontrolü
Ekipte birçok bilgi seviyesinde yazılım uzmanı görev almaktadır. Bu durumda da her ekip üyesinin yazdığı kod aynı kalitede olması imkansızdır. Aynı olmasa bile ortalama bir kaliteyi sağlamak gerekir. Bunun amacı okunabilirliği yüksek ve esnekliğini kaybetmeyen bir yazılıma ulaşmaktır. Bu nedenle daima her yazılan kodu ikinci bir göz kontrol etmesi ileride işleri kilitlenir noktaya getirmemek için çok değerlidir.
- Bilgi Akışı
Ekipte herkes aynı bilgi düzeyinde olmaması kabul edilebilir bir durum elbette. Ancak bu durum daha iyi seviyedeki uzmanların bir alt seviyedeki ekip üyelerini bilgi düzeyini arttırıcı iletişim ağı olmalı. Bu aynı zamanda işten ayrılmak zorunda kalan bir ekip üyesi olması halinde de hayat kurtaracak bir gerekliliktir.
- Açık ve Korkusuz Ekip Ruhu
Açık sözlü bir ekip daima en iyisidir. Eğer işler kötü gidiyorsa kimsenin rol yapmasına gerek yoktur. Çünkü en nihayetinde olacak olan olacaktır. Bu nedenle öz düşüncelerin rahatça söylenebileceği ve makul değerlendirmeler sonucu kurtarıcı rol oynayacak kararlar alınmasını sağlayabilir. Ekip üzerinde korku ve endişe yerine takım ruhu kazandırılmalıdır.
- Kısa Süreli Versiyonlama
Geliştirilmekte olan yazılım iyi analiz edilmiş olmalı ve küçük parçalara ayrılarak çözümler geliştirilmelidir. Her küçük çözüm uygulandığında uygulama subversion üzerinde commit edilmelidir. Bu sayede uzun süren geliştirmeler sonrası büyük bir update sonucu oluşabilecek sorunlara karşın küçük geliştirmeler sonucu çıkan problemleri gidermek çok daha kolay olacaktır.
- Farkındalık
Projelerde hedeflenen uygulamayı her ekip üyesi net olarak bilmelidir. Bu farkındalığı oluşturmak için proje başlamadan önce ekiple görsel öğelerle hedef uygulamayı izah eden etkileşimli bir sunum yapılmalıdır. Soru cevap bölümü ile oluşan soru işaretleri giderilmelidir. Bunun en büyük faydası planlama aşamasında atanan bir görevin daha etkili ve verimli bir yönü varsa programcı bunu hedef uygulamayı bildiği için bunu tercih edebilme özgürlüğüne sahip olacaktır. Kaliteli bir yazılım olması için bu gerçekten yadsınamaz bir gerekliliktir. Ekibe yeni katılan kişiler de aynı şekilde detaylıca bilgi verilmesi gereken kişilerdir. Ve mümkünse yeni katılan kişi her ne kadar işinde iyi olsa bile en az 2 hafta kod yazımına başlamaması ve bu süre içinde ekibin uyduğu geliştirme standartlarına uyabilmesi için eğitim alabilmesi gerekir.
Benim en önem verdiğim yöntemleri ifade etmeye çalıştım. Tabi ki daha birçok faydalı yöntem var ancak bu yöntemler en çok ihmal edilen veya yapılmadığında en büyük zarara sebep olanlardır. Her ne kadar harfiyen uymanın imkansızlığını biliyor olsak bile ekip olarak bu yöntemlere bağlı kalma mücadelesi verilmelidir.
Günü kurtaran değil, değerli kod yazan programcılar olmamız dileğiyle.
Felsefem;
Basit Düşün, Çözüm Üret,
Yazılıma Değil, Çözüme Odaklan...