İdeal şartlar altında bir programcının savaş verdiği tek bir cephe vardır, o da müşteri gereksinimlerini önemlilik sırasına göre kodlamak.
Çevik süreçlerde müşteriye 2-4 hafta süren çalışmalar ardından çalışır bir uygulama prototipi sunulur. Bu prototip müşteriye uygulamanın hangi seviyeye geldiğini, isteklerinin doğru uygulanıp, uygulanmadığını ve hangi değişikliklerin gerekli olduğunu anlama fırsatı verir. Buradan change request olarak bilinen ve müşteri gereksinimlerine daha yerinde cevap verebilmek için atılması gereken adımları tanımlayan değişiklikler doğabilir. Bu değişiklikler bir sonraki 2-4 haftalık çalışma sürecinde kullanıcı hikayesi (user story) olarak programcıya yansır. Bu değişikliklere rağmen programcının savaşı hala bir cephede devam etmektedir.
Eğer proje bünyesinde kodun kalitesine dikkat edilmiyorsa, programcı için ikinci bir savaş cephesi
daha açılır: oluşan hataları gidermeye çalışma cephesi. Bu çok kısır bir döngünün oluşmasına sebep verebilir, çünkü müşteriye verilen prototiplerde hata sayısı çok yüksek olduğunda, programcı zamanının büyük bir bölümünü açılan ikinci cephede savaşarak harcar. İkinci cephe birim ve entegrasyon testleri yazılarak kapatılabilir ya da açılması engellenebilir.
Buraya kadar tanımladığım yazılım geliştirme süreci başın, ayakların ve kolların nerede olduğunu belli olan bir süreçtir. Ekip neyin, ne zaman yapılması gerektiğini bilir ve çalışmalarını ona göre yönlendirir. Başın, ayakların ve kolların nerede olduğu bilinmeyen ve en kötü ihtimalle bu uzuvların yerlerinin devamlı değiştiği projelere de rastlamak mümkündür. Bu tür projelerde programcı birçok cephede savaş verir. Programcının kendisini en çaresiz hissettiği ve cephanesinin ve motivasyonunun en çabuk azaldığı projeler bu tür projelerdir.
Bu tür projelerde change request çok başka bir kimliğe bürünerek programcılara musallat olur: acil iş!
Proje yönetimi acil iş olarak gelen talepleri hemen ekibe delege ederek, sonuç almak ister. Hadi gelin birlikte acil iş olarak gelen bir işin programcı için nelere sebep verdiğine bir göz atalım.
Acil işi öncelikle olağan üstü hal olarak tanımlayabiliriz. Normal proje akışı yanı sıra programcı bu olağan üstü hali normale dönüştürebilmek için birçok adım atmak zorundadır. Genel olarak acil değişiklik isteklerinin trunk olarak isimlendirilen ana kod dalında yapılması mümkün değildir. Bu yüzden programcı yan dal, yani branch oluşturmak zorundadır. Acil iş için gerekli kod değişikliği bu yan kod dalında yapılır ve değişiklikler daha sonra ana kod dalı ile birleştirilir. Bu işleme merge ismi verilmektedir. Her geçen gün ile merge işlemi daha komplike bir hal alır. İki hafta branch üzerinde çalıştıktan sonra muazzam emek ve dikkat sarf etmeden kodun ana dal ile birleştirilebildiğini hiçbir projede görmedim. Branch ve merge işlemleri başlı başına ağır işler olup, programcıyı çok yorarlar.
Bunun yanı sıra yapılan değişikliklerin staging olarak isimlendirilen değişik türdeki test sunucularında test edilmesi gerekmektedir. Bu da tüm ekibi rehin alabilecek türde bir işlemdir. Test sürecinden sonra yeni bir sürüm oluşturulup, bu sürümün müşteri için çalışır hale getirilmesi gerekir.
Şimdi çok acil iş, çok acil iş diye devamlı ekibin çalışma sepetine dökülen bu incilerin, programcıları ruhen ve bedenen ne kadar çok tıkadıklarını anlayabiliyoruz sanırım.
Ben programcıları 500 beygir gücünde yarış arabaları ile kıyaslıyorum. Verin kullanıcı hikayelerini programcının eline ve bir zamanlar Formel 1 yarışlarının olduğu İstanbul Parka salın. Nasıl son speed turladığını göreceksiniz.
Temcit pilavı gibi programcının devamlı acil iş, acil iş diye başına ekşirseniz, o zaman 500 beygirlik bu gücü birinci viteste parkurda koşturuyorsunuz demektir. Bu programcı bir gün ikinci vitese takar ve İstanbul Park’ın arka çıkış kapısından kaçar gider.
Programcılar sahip oldukları potansiyeli kullanarak, işlerini düzenli bir gidişat çerçevesinde en iyi şekilde yapmak isterler. Rahatsız edildikleri bir ortamda tam randımanlı çalışamazlar. Doğrusunu söylemek gerekirse, canları çok sıkıldığında çekip giderler.
Bunun önüne geçmek için şu acil iş ismi altında deklare edilmiş kime ne faydası olduğu belli olmayan anormal durumların bir son bulması gerekiyor. Aksi taktirde 500 beygir gücündeki spor arabalar Edirme-Kars arasında birinci viteste gidip, gelmeye devam ederler. İstediğinizin bu olduğunu zannetmiyorum.
EOF (End Of Fun)
Özcan Acar
Özcan Hocam kaleme aldığınız bu konu için teşekkür ederim.
Bulunduğum kurumda kanayan yara haline gelmiş bir durum. Yazılım sektöründe çalışan biri olarak en sevmediğim iş, acil sıfatıyla gelenler. Çünkü acil olarak araya alınan işler planlı olmadığı için bug olarak geri dönme ihtimali çok yüksek. Yazılım döngüsünün içerisine bir de bug-fix giriyor.
Düşünün önünüze en sevdiğiniz yemek gelmiş. Tam yiyeceksiniz tepeden birisi önünüzdeki yemeği alıp kapuska koyuyor. (Kapuskayı sevenlere itirazım yok :) )
Hocam gerçekten çok önemli bir konuya değişmişsiniz. Bu beni gün içerisinde en çok buhran ettiren bir konu, zaten Sinan arkadaşımız kapuska örneği çok yerinde olmuş. Şu an bu postu gerekli yerlere gönderip , bizi anlamalarını umut edeceğim :)