Yazılım Süreçleri Nasıl Olmalı?

İşyerlerindeki prosedürler ilgilendiğim konulardan biridir. Bu aralar yazılım süreçlerinin güncellenmesi çalışmasının içerisindeyim, dolayısı ile çözümün parçası olma şansım var. Yazılım süreçlerimiz yazılım geliştirmede uyulacak kuralları belirliyor. Örneğin yazılım testinden önce yazılım şartnamesinin hazırlanmış olması gerekiyor.

Süreçlerle ilgili sorun kuralların teoride kulağa hoş gelmesi ama uygulamada sıkıntılara (bürokrasi, işgücü ve moral kaybı) yol açmasıdır. Kötü süreçlerin özellikleri şunlardır:

* Detaylıdırlar. Her durumu öngörme gayreti vardır.

* Tekrarlanabilirliği ve izlenebilirliği hedefler. Çalışanları kontrol altında tutmayı amaçlar, adaptasyon yeteneğini kısıtlarlar. Herşeyin hızla değiştiği günümüzde adaptasyon temel hedef olmalıdır oysa. Özellikle yazılım biraz tasarım - biraz kod - biraz tasarım şeklinde ilerler.

* Masa başında, rahat bir ortamda tasarlanırlar. Tecrübeli yazılım geliştiriciler bile başlarına gelenleri unutup fantazilere dalarak süreç yazabiliyorlar. Unutulanlara tipik örnekler:
** İşi layıkıyla yapmak için gerekli sürenin/paranın yarısı bile yoktur.
** İşi yönetecek olanlar tecrübesizdir, işler başta tahmin edilenin iki misli süre alır.
** İşi yapacak olanların teknik birikimi (domain knowledge + software engineering + programming language + IDE) yetersizdir.
** Müşteri tecrübesizdir, istekleri belirsiz ve yanlış olabilir.
** Müşteri tarafındaki yöneticiler değişebilir, yeni yöneticilere herşeyi baştan anlatmak gerekebilir.

Big Macs vs. The Naked Chef:

Beware of Methodologies. They are a great way to bring everyone up to a dismal, but passable, level of performance, but at the same time, they are aggravating to more talented people who chafe at the restrictions that are placed on them. It's pretty obvious to me that a talented chef is not going to be happy making burgers at McDonald's, precisely because of McDonald's rules.

Süreç yazarken benim taraftarı olduğum düşünce kolay adaptasyondur. Ayrıntılar:

* Süreçlerin içeriği minimumda tutulmalı. Başımıza gelebilecek her türlü riske karşı tedbirleri değil, tipik bir geliştirme çalışmasında ihtiyaç duyulacak minimum kuralları söylemeli. Yazılım için minimum kurallar şunlardır:
** Source control kullan
** Kod gözden geçirmelerini yap
** Birim test yaz
** Bug veritabanın olsun
** Test dokümanı hazırla ve testleri bu dokümana göre yap. Bu doküman hem şartname, hem de kullanım kılavuzu işlevi görebilir.
** Geriye kalanlar (şartname, tasarım dokümanı, arayüz kontrol dokümanı...) duruma göre geliştiricilerin ihtiyaç duyması haline yapacakları şeylerdir.

* Genel prensiplerin (kod okuma nasıl yapılır vb.) anlatılması için süreçler değil wiki benzeri ortamlar kullanılmalı. Wikilerde kontrol değil, paylaşım ve güncellik esastır. Süreçler eğitim dokümanları değil, anayasadır.

* Riskten kaçınmak adına çok sayıda madde/sınırlama koymak mütevazi/rutin işlerin yapılmasını zorlaştırır, işgücü kayıplarına neden olur. Değerlendirmeye alınacak riskler gerçekleşmesi olası, gerçekleştiğinde telafisi güç sonuçlara yol açan ve önleme maliyeti düşük olan risklerdir.

* Risk almaktan kaçınarak parlak başarılar elde edilemez. Risklerin gerçekleşmesi halinde çözüm iyi yetişmiş, sorgulamayı bilen esnek insanlar tarafından bulunur.

* Peki yeni yazılım geliştiren bir elemanın işini düzgün yapması, cahilce sorunlar yaratmaması nasıl sağlanacak? Öncelikle yeni elemanlarını iyi seçeceksin. Yenileri deneyimli elemanlar gözetiminde çalıştıracaksın, yazdıkları kodları mutlaka sık sık gözden geçirecek ve doğru pratikleri kazanmalarını sağlayacaksın. Elemanlarını eğitecek, motive olabilecekleri özgürlükleri sağlayacaksın.

Aslolanın araçlar değil insan kalitesi olduğuna dair bir yazı, Weeding out the Weak Developers with J2EE:

So let’s get real. Bad programmers write bad code. Good programmers write good code. RAD lets bad programmers write bad code faster. RAD does NOT cause good programmers to suddenly start writing bad code.

RAD tools can make a good programmer more productive, because they speed up the coding process without compromising the level of quality that a good programmer is going to achieve.

mp3:
* Hayko Cepkin - Melekler
* Hayko Cepkin - Fırtınam