Yazılım Geliştirici Verimliliğini Artırmak…
Yazılım geliştirme ekiplerinde verimlilik her BT veya yazılım yöneticisinin problemidir. Aslında tüm hizmet sektörlerinin ortak problemi olan bir konu bu. Bir kişinin beyni ile yaptığı işi çalışma saati olarak ölçmeye çalışırlar. Bu arada ellerinde çok fazla done olmadığı için maalesef bu yöntemi kullanıyorlar. Halbuki bir yazılımcının birim zamanda üreteceği işi 1 birimden başlayıp 10 birime kadar çıkarabilirsiniz. Abartmıyorum bu daha fazla bile olabilir.
Motivasyonu düşük bir yazılımcı bütün gününü sosyal medya ve internette gezerek veya konusu dışında işlerle uğraşarak geçirebilir ve çok verimsiz bir gün olmuş olur. Bunu kolay kolay fark edemezsiniz. Bu geçici olursa sorun yok ancak uzun dönem sürmesi zaten kısıtlı insan kaynağı olan yazılım geliştirme sürecini sekteye uğratacaktır. Bunun yanında fazla iş üretmek bir yazılım geliştirme süreci için tek başına verim anlamına gelmiyor. Yapılan işin kalitesiz olması da ekiplere ciddi iş yükü getirebilir. Hatta bence en tehlikeli durum bu. 80-20 kuralında %20’nin yaptığı iş %80 hataya neden olur ama yazılım süreçlerinde %5’in yaptığı hata işin %95’ine mal olabilir.
Nedenleri yazdık peki çözüm önerileri ne olabilir. Yazılım süreçlerindeki verimi artırabileceğiniz birkaç öneri sunabilirim.
Doğru pratikleri uygulamak
Yazılım geliştirme kalitesini artıran Code Review, TDD, Pair Programming, Refactoring gibi pratikleri uygulamak önemli. Bu ilk başta zaman alıyor gibi görünse de bu pratikleri uygulamak kod kalitesini önemli derecede etkiliyor. Bunun yanında yazılım geliştiriciler yaptığı işin kaliteli olmasının verdiği önemli bir motivasyon kaynağı olarak görüyor.
DevOps kültürü oluşturmak
Yazılım geliştirme sürecindeki araçlarının bir üretim bandı şekilde kurgulayan DevOps pipeline oluşturulması yine önemli bir konu. Bu sayede araç ve süreç anlamında doğru bir kültür oluşturulması sağlanabilir. Her yazılım belirli bir ürün bandından çıkıp gerçek ortama doğru yol almış olur.
Gerçek ürün ortamlarının izlenmesi
Bu işlem hem loglama araçları hem de APM’ler ile yapılabilir. Bu tarz araçlar ile gerçek ortamdaki hatalar çok daha kısa sürede adreslenebilir. Özellikle iş birimi veya müşterilerden gelen detaylandırılmamış çağrıları adreslemek için ciddi zaman kazanımı sağlayacaktır. Bir yazılımcının bildirilen bir hatayı çözmek için en çok harcadığı zaman hatayı adreslemek oluyor. Benim genelde gördüğüm birçok yazılımcının profiling gibi işlemler konusunda çok fazla bilgi ve deneyim sahibi olmadı ve hataları hızlı adresleyemediği. Oysaki bu tarz araçlar ile bunu çok daha hızlı yapabilirler.
Yazılım geliştirme analiz araçlarını kullanın
Bir başka önerim yazılım geliştiricilerin kullandıkları koda kalitesini kontrol eden ve Git gibi ortamları analiz edebilen araçları kullanmak olacaktır. Bu hem kalite hem de eforlarla ilgili ciddi bilgiler sağlayabiliyor. Mesela Sonarqube gibi statik kod analiz araçları veya eforları da takip etmenizi sağlayan QA Dashboard gibi araçları kullanmak ciddi fayda sağlayabilir. Bu araçlardan yazılan kodlarda ne gibi hatalar yapıldığını veya QA Dashboard ile hangi yazılımcının ne gibi aktiviteleri olduğunu raporlayabilirsiniz. Örnek metrikler teknik borçlanma, kod satır sayısı, karmaşıklık oranı, kod commit sayıları ve oranları, tamamlanan User Story oranları karşılaştırılabilir hale gelebilir.
Agile ekipler için velocity kullanımı
Agile çalışan ekipler iş performansını velocity’ler ortalama olarak çıkarırlar. Bu aslında işlere verilen puanların her bir sprint için ortalamasını ifade eder. Ekiplerin velocity’lerinde düşüşlerin olup olmadığı takip edilebilir. Bu yine çok somut bir kavram olmasa da ekip kendini bu şekilde izleyip peformansı hakkında yorum yapabilir. Burada yorumum bu metrik ile dışardan bir performans izleme değil ekibin kendi performansına yönelik yorum yapması gerekliliği olacaktır.
Açıkçası gezdiğim şirketlerde kaos ortamları ile karşılaşabiliyorum. Bu bazen legacy sistemlerle üzerine yapılan geliştirmelerden kaynaklı öğrenilmiş çaresizlik bazen de iş baskısından kaynaklanıyor. Ben açıkçası iş baskısı altında geliştirmiş bir projenin kaliteli olduğunu pek görmedim. En basitinden geliştirildiği süre sonunda o kadar çok bakım ile uğraşılmak zorunda kalınıyor ki verilen yıllık bakım eforları neredeyse proje büyüklüğü kadar. Yani kötü yazılmış projenin bakımını yapmaktansa bazen baştan yazmak daha az maliyetli olabiliyor.
