developen

Yakın zamanda yazılım üretimi konusunda çeşitli standartların sektörde popülerliğinin arttığını gözlemliyoruz. Özellikle bazı devlet ihaleleri için CMMI L3, kimileri için ISO varyantları talep edildiği için, bir çok firma şu anda harıl harıl denetlemelere hazırlanmaktalar.

Bunun sevindirici bir gelişme olduğu hususunda, okuyucuya katıldığımı belirtmek istiyorum. Lakin uygulamada bazı pratikleri gözlemlemem, temel bazı hataların yapıldığını farketmeme ve akabinde bu çalışmaların kısır kalacağı yönünde bir kaygı geliştirmeme sebep oldu.

Birçok standart, bazı süreçlerin uygulanmasını şiddetle vurgulamakta. Bu vurgunun temeli, bu süreçlerin yazılım geliştirme döngüsünün olmazsa olmaz parçaları olmasından kaynaklanmakta. Yazılım geliştiren firmaların bu vurgulanan süreçlere yaklaşımları, genelde hali hazırdaki geliştirme biçimlerini değiştirmeden ve bu “ek” süreçleri, paralel yürüyen ayrı bir akışa devretmek şeklinde. Örneğin, evet, projenin risk analizi yapılmış durumda. Fakat bu analiz, yazılım geliştirme sürecinden bağımsız olarak, kodlamanın bitimine yakın, paralel bir biçimde ”yapılmış” ve standardın belittiği biçimde dosyalanmış.

Böyle durumlarda başladığım uzun ve sıkıcı konuşmamın bir özetini de buraya bırakmak istiyorum.

Kendinize zaman tanıyın ve en önemli noktadan başlayarak adım adım iyileştirin 

Yazılım geliştirme biçiminizi standartları uygulamak istiyorsanız, devrimlerden kaçının. Tarihte hiçbir devrim kansız olmamıştır. Sizinki niye olsun? Şu anda kullandığınız geliştirme pratikleri, şimdiki ana kadar, şirket kültürünüz içinden süzülerek gelmiş bir yapıyı temsil eder. Bunu bir kerede değiştirmek, ne yazık ki şirket kültürünüzü bir kerede değiştirmeyeceği için birçok çelişkiyi gözlemlemeniz işten değildir. Böylece insanlar bir yandan “işlerini yapmak” ve bir yandan da “standartlara uymak” için çalışmaya başlayacaklar ve aslında uygulama biçiminden dolayı “gereksiz” olan bu “ek işler”, çalışanların standartlara olan güvenini sarsacaktır.

Yazılım üretim sürecinizi inceleyerek, paralel yürüyen süreçleri saptayıp onlardan kurtulun

Eğer bir pratiği yazılım üretim sürecinize paralel olarak ilerletiyorsanız, muhtemelen bu paralel süreç gereksizdir. Ya bir şekilde bu süreci üretim süreciniz içerisine dahil etmelisiniz, yada bu ek süreçten kurtulmalısınız. Yazılım üretim süreçleri incelenirken, her bir iş birimi, belirli girdiler ve belirli çıktılar ile sınırlandırılabilir. Eğer üretim sürecinizde, herhangi bir iş biriminin çıktısını sadece dosyalayarak kullanıyorsanız, muhtemelen o iş birimini boşu boşuna yapmaktasınız. İlk olarak her zaman, çıktıları en fazla kullanılabilir süreç adımlarını eklemelisiniz. Eğer test ekibiniz test stratejileri ile ilgili analiz çalışması yapmıyor ise, çevrimsel karmaşıklık (cyclomatic complexity) ölçümü yapmanın bir anlamı yoktur.

Doküman şablonlarını ve zorlanan iş prosedürlerini rafa kaldırın

Dokümantasyon vakit kaybı mıdır? Beyninizin içindeki o meleğe kötü haberlerim var. Bazen evet. Eğer gereksiz dokümantasyon yapıyorsanız bu kesinlikle bir kayıptır. Bu sebeple ilk etapta, doküman şablonlarından ziyade, doküman şablonlarının yaklaşımlarını benimseyin. Hayır, dokümanın o bölümünü ISO öneriyor olabilir. Eğer kullanılmayacak ise, gene de gereksizdir. Lütfen, izin verin çalışanlarınız önce dokümante ettikleri için fayda sağlasınlar. Yaşanacak evrimin sonucunda, sofistike hale gelen yazılım geliştirme süreçleriniz, emin olun o paçavraların önerdiğinden fazla dokümantasyon üretecektir.

Sürekli evrim, emin olun sizi zaten adı geçen standartlara yakınlaştıracaktır. Zira aklın yolu bir.