Özet. Ana faaliyet alanı yazılım geliştirme olan şirket/organizasyonların, zamanında, kaliteli ve düşük maliyetli bir yazılım ürünü geliştirmesinin en önemli adımlardan biri şirketin yaptığı işe en uygun yazılım sürecinin belirlenmesidir. Belirlenen süreçteki her adım sürekli ölçülerek iyileşme sağlanmalıdır. Yazılım geliştirme kavramının soyut olması, ölçülmesini de zorlaştırmaktadır. Bu yüzden ölçülecek kriterlerin çok iyi belirlenmesi ve amaca yönelik olması gerekmektedir.
1 Logo Yazılım, Kocaeli, Tukey tugrul.tekbulut@logo.com.tr,nurdan.canbaz@logo.com.tr, ersin.gulacti@logo.com.tr,tugba.ozturkkaya@logo.com.tr 1
Modern dünyada bilgisayar yazılımlarının insan hayatına her geçen gün daha çok girmesi ile birlikte yüksek kaliteli yazılım geliştirmek firmalar açısından önemli hale gelmiştir. Herhangi bir metodolojiye dayanmadan geliştirilen yazılımlar, zamanında teslim edilememekte hem yazılım şirketlerine hem de müşterilere vakit kaybı yaşatmaktadır. Bu nedenle yazılım kalitesi farklı açılardan değerlendirilmelidir. Bunlar, geliştirici ekip, ürün yönetimi ve yazılım ürününü satın alacak müşteri vb. paydaşlardır.
Müşteri açısından incelendiğinde, kaliteli bir yazılımın temel özellikleri işlevsellik,
gereksinimlere uygunluk, kullanım kolaylığı, güvenilirlik (hata sıklığının az olması) ve
güncelleme kolaylığıdır. Geliştirici ve ürün yönetimi açısından bakıldığında ise kalite
kriterleri, çıkabilecek hataları veya ilerde sorun yaratabilecek bileşenleri önceden tespit
edebilmek, maliyeti azaltmak, daha başarılı bir projeye imza atabilmek vb. olarak
sıralanabilir [
Bakış açısı ve role göre değişen bu kalite bileşenlerine sahip ürünler geliştirebilmek
için arkada sağlam bir süreç disiplini olmalıdır, ancak bu disiplin oluşturulurken
yazılım sektörünün insan temelli olduğu gerçeğinin getirdiği zorluklar
unutulmamalıdır. Logo Yazılımın yalın üretim felsefesinden esinlenerek geliştirdiği,
iyileşme odaklı çevik ürün geliştirme süreci olan LAPIS (Logo Agile Process
Improvement System) [
Yazılım geliştirme süreçlerinin temel sorunlarından biri, soyut kavramlara dayandığı
için beklenen faydaların ölçülmesinin zor olmasıdır. Tom de Marco’nun “Ölçülemeyen
bir şeyin kontrol edilebilmesi oldukça zordur” [
İlgili Çalışmalar
Çevik metodolojiler, günümüzde oldukça tercih edilen yazılım pratikleri olarak
karşımıza çıkmaktadır. Büyük ve orta ölçekli firmalarda değişen müşteri
gereksinimlerine hızlı yanıt verebilmek ve değişen önceliklere hızlı adapte olabilmek için çevik
yazılım geliştirme yöntemlerinin kullanımı dünyada ve ülkemizde her geçen yıl
yaygınlaşmaktadır [
Çevik yazılım süreçlerinin dayandığı çevik manifesto [
LAPIS, farklı metodolojilere dayanan ürün geliştirme yönetim modellerinden ve yalın
üretim felsefesinden etkilenmiş bir ürün geliştirme modelidir [
Şekil 1. LAPIS (Logo Agile Process Improvement System)
Ana felsefesini yalın üretim felsefesinden alan LAPIS, çevik yöntemlerden olan
Scrum’dan [
Her ürün için ürünün piyasadaki konumu ve ihtiyaca göre sprint süreleri sene başında belirlenir. Sprint sürelerinin minimum %20'lik zamanı entegrasyon testlerinin yapıldığı test haftalarına ayrılır. Sprint başlamadan önce Ürün Sahibi, ürün iş listesinde (Product Backlog) bulunan maddeleri önceliklendirir. Mutabakat toplantısında (Sprint Planlama Toplantısı) Ürün Sahibi ve geliştirme ekibi önceliklendirilmiş maddelerden hangilerinin izleyen sürüm içeriğine dahil edileceğini, geliştirme ve test ekibinin kapasitesine uygun olarak, belirler.
Yapılmasına karar verilen maddeler Sürüm İş Listesi (Sprint Backlog) olarak ilan edilir. Bu maddeler Logo'da kullanılan destek sistemi üzerinden otomatik olarak iş ortaklarına da duyurulur. Entegrasyon testlerinin yapıldığı hafta geliştirme takımları test ekibinden gelen hata düzeltme (bug-fix) taleplerini yapmakla beraber bir sonraki sürümün geliştirmesine başlar. Aynı hafta içinde, tamamlanan sürüm içeriğini Ürün Sahibi, destek ve proje ekipleri ile paylaşır. (Sprint Review) Sprint sonunda sprintte yapılanların değerlendirilmesi ve iyileşme noktalarının tespit edilmesi için süreç yöneticisi tarafından retrospektif toplantısı düzenlenir.
Şekil 2. LAPIS İş Akışı
LAPIS sürecindeki her bir adım Atlassian firmasına ait olan Jira [
Ölçüm Modeli Yapılan araştırmalar, yazılım süreçlerinin tanımlanması ve ölçülmesi konusunda çalışmaların halen devam ettiğini göstermektedir. Bu nedenle, şirket stratejisine, geliştirilen ürünlere ve ekip dağılımlarına göre tasarlanan LAPIS sürecinin, ölçülmesinin de benzer şekilde olması için uygun ölçüm metodu üzerine çalışmalar yapılmıştır.
Şekil 3. LAPIS Değerlendirme Yöntemi
Ölçüm metodu oluşturulurken ISO 15939 Yazılım Ölçme Standardından
yararlanılmıştır [
Ölçüm Metodunun Belirlenmesi Ölçme sürecinin oluşturulması ile ilgili adımlar Şekil 4’te verilmiştir. Detaylar Bölüm 5 ve 6’da anlatılmaktadır.
Şekil 4. LAPIS Ölçüm Metodu Belirlenmesi Ölçüm Hedefinin Belirlenmesi . Hedef olmadan süreçteki adımlar ölçülmeye başlandığında sadece amaçsız sayı kümeleri oluşmaktadır. Bu sebeple model hazırlanırken Hedef-Soru-Metrik yaklaşımı benimsenerek hedefe uygun ölçüm metodu belirlenmesi amaçlanmıştır. Ölçüm hedefinin belirlenmesinin detayları Bölüm 5’te, hedefler ve belirlenen metrikler Tablo 1’de verilmiştir.
Bilgi İhtiyacının Belirlenmesi ve Akışın Otomatize Edilmesi. Hedef-Soru-Metrik yaklaşımı ile belirlenen soruların cevaplarını alabilmek için süreç akışının otomatize edilmesi ihtiyacı ortaya çıkmıştır. Bu ihtiyacın giderilmesi için süreçteki tüm adımların bir araç ile takip edilmesine karar verildi ve LAPIS süreci Jira’da gerekli uyarlamalar yapılarak tamamen bu sistem üzerinden takip edilmeye başlandı. Böylelikle hem süreçteki tanımlamaların daha eksiksiz yapılması hem de insan müdahalesi ile oluşabilecek aksaklıkların önüne geçilmesi sağlandı. Ölçüm Metriklerinin Belirlenmesi. Hedef-Soru-Metrik yaklaşımı ile oluşturulan metrikler ve bu metriklerin etki katsayıları belirlendi. Metriklerin otomatik şekilde süreçten beslenmesi ve oluşturulan veri havuzunda toplanması sağlandı. Ölçüm Metodunun Oluşturulması ve Rollere Dağıtılması. Ölçüm metodunu oluşturulup, bu ölçümlerin takip edileceği ortama karar verilmiştir. Farklı departmanların da kullandığı Confluence [16] aracı üzerinde gerekli uyarlamalar yapılarak, ölçümler için kurumsal hafızayı oluşturacak platform hazırlanmıştır. Burada amaçlanan hem maliyeti düşürmek hem de ölçüm sonuçlarının şirketteki herkesin erişebildiği bir ortamda yayınlanması ile kişiler tarafından sahiplenilmesini sağlamaktır. Ölçüm sonuçlarının rollere göre detaylandırılması Bölüm 6’da verilmiştir.
Ölçme Metodu
ISO 15939 [
Hedefler ve metrikler belirlenirken hem yönetimin belirlediği genel yaklaşım hem de şirket içinde farklı bölümlerdeki kişilerle yapılan çalışmalar sonucunda belirlenen ihtiyaçlar göz önünde bulundurulmuştur.
Tablo 1. Ölçüm Hedefleri ve Metrikleri HEDEF Müşteri Odaklılık Kaliteli Ürün Geliştirmek Verimlilik
SORU Sürümler zamanında çıkıyor mu? Müşterilere verilen sözler zamanında yerine getiriliyor mu? Müşteri isteklerine yazılım ekiplerimizin cevap süresi nedir? Hatalara yazılım ekiplerimizin cevap süresi nedir? Müşterilerden önce hataları tespit edebiliyor mu? Düzenli test haftalarına uyum sağlayabiliyor mu? Kapasite planlamasına uyum sağlanabiliyor mu? Kapasite planlaması verimli yapılabiliyor mu? Ürünlerdeki stratejik hedeflere uyum sağlayabiliyor muyuz?
Her metrik için kartlar oluşturulmuş, hangi rollerin hangi zamanlarda bu metrikleri nereden takip edeceğine karar verilmiştir. Hata tespit oranı ve Logo’ya özgü OTEQ raporuna ait örnek metrik kartları Tablo 2 ve Tablo 3’te verilmiştir.
METRİK Amacı Hesaplama Yöntemi Yıl içinde test ekibi tarafından tespit edilen hataların tüm hatalara oranı Her Çeyrekte Confluence Sistemi
METRİK Amacı Hesaplama Yöntemi Ne zaman kontrol edilmeli Nereden kontrol edilmeli Takip eden paydaşlar Hedef Rapor
Tablo 3. OTEQ
OTEQ (Overall Team Efficiency, Quality) [
Uygunluk Durumu x Performans x Kalite (Uygunluk durumu, yönetim kararı ile 1 alınmıştır) Performans: Toplam tüketilen Story Point Kalite: 1/ ∑ (Müşteriden gelen hata * Zarar Puanı) Zarar Puanı: Gelen hatanın önemine uygun olarak (1-13 arası katsayı) OTEQ = (1) (∑Story Point /(∑ #Yazılımcı)(# Gün))(1/∑Hata Zarar Puanı) Her Çeyrekte Confluence Sistemi LAPIS Paydaşları (Product Owner, Test Ekibi, Yazılım Ekibi) Artan eğilimde olması
Sürüm bazlı örnek OTEQ raporu
Belirlenen metriklerin detaylarının oluşturulmasının ardından tüm metriklerin bir arada görüntülenebileceği bir çalışma yapıldı. Burada amaçlanan hem metriklerin daha okunabilir olması hem de oyunlaştırılarak ekipler tarafından benimsenmesinin sağlanmasıdır. Rol bazında görüntülenebilecek raporlara ait örnekler Şekil 6 ve Şekil 7’de verilmiştir. Çalışmada öncelikle takip edilen metrikler iki gruba ayrıldı. Bunlardan ilki planlamaya ve cevap süresine hizmet ederken, diğeri yazılım süreçleri tarafından takip edilen ürün iş listesi durumuna yöneliktir. Bu nedenle, iki grup için ayrı ayrı radar grafikler hazırlanmıştır. Radar grafikler arabaların tekerlerine benzetilebilir, eğer bir kriterdeki değer, diğerlerine oranla farklı ise teker daire şeklini kaybedecek ve aynı arabanın ilerlemesinde olduğu gibi sürecin gidişatında da aksaklıklar olacaktır. Örnek radar grafikler Şekil 5’te verilmiştir.
Şekil. 5. Ürün – Planlama Radar Grafiği
LAPIS ölçüm metodunu oyunlaştırmak için her sürüm sonunda alınabilecek rozetler oluşturulmuştur. Tablo 1’de verilen metrikler için bir katsayı belirlendikten sonra her metrik değeri kendi katsayısı ile çarpılır. Oluşan değerler toplanarak her sürüm için Sürüm Puanı elde edilir. Sürüm puanına göre Tablo 4’te belirtilen aralıklara uygun olarak ekibe rozet verilir. Oyunlaştırma tekniklerinin kullanılmasının ve Sürüm Puanını ekipler ile paylaşmak yerine rozet verilmesinin amacı, olumsuz motivasyon yaratılmadan sürece dahil olduklarını hissettirmek ve daha yüksek rozet hedeflerine yönelik çalışılması yönünde teşvik etmektir. Yapılan çalışma kapsamında, seçilen bir ürüne ait sürüm bazlı planlama puanları ve rozetleri Tablo 5’te verilmiştir. Ürüne ait yıl bazında Planlama ve Ürün kapsamındaki değerlendirme sonuçları Tablo 6’da verilmiştir.
Tablo 4. LAPIS Ölçüm Tablosu LAPIS ölçümlerinin genel sonuçları Bölüm 5’te verilmiştir. Tablo 1’de belirlenen hedef ve metriklerin rol bazlı olarak detaylı analiz edilebilmesi, belirlenen hedeflere daha kısa çevrimler ile ulaşılabilmesi, sürüm devam ederken fark edilen sorunlara proaktif olarak çözüm üretilebilmesi için çeşitli detay ölçümler hazırlanmıştır. Bu ölçümlere ait örnek raporlar aşağıda anlatılmıştır. Ekiplerin çevik yazılım geliştirme metotlarına uyum sağlayabilmesi için süreçte kendilerine özgü takip edebileceği [17] ve ekipçe iyileştirme fırsatı bulacağı raporlar oluşturulmuştur. Bu raporlar ile ekip yöneticileri sürümleri ve ekibi detaylı olarak analiz edebilmektedir. Şekil 6’da verilen raporda ürün bazlı olarak sürümlerdeki iş listesinin durumları, öncelikleri vb. değerler gösterilmektedir.
Şekil 6. Ekip Bazlı Raporlar
Yetkisi dahilinde ekip üyelerinin kendine ait bilgilerini görebildiği raporlar Şekil 7’de verilmiştir. (Örnek: Story Point Tüketimi, Ekip Ortalamasına göre kendi durumu gibi)
Şekil 7. Kişi Bazlı Raporlar 6.2
Ürün ve Süreç Raporları Şirket içinde çevik yazılım süreçlerinin farkındalığını arttırmak ve ekipleri sürece dahil etmek için sürümün ilerleme durumunu gösteren raporlar tüm ekip tarafından izleyebileceği alanlarda bulunan ekranlarda paylaşılmaktadır.
Şekil 8’de örnek ekran görüntüsü verilmiştir.
Şekil 8. Sürüm Takip Raporu 7
Ölçümler süreçteki tüm paydaşlara dikkat edilmesi gereken noktaları gösterir. Burada asıl önemli olan şirkete ve ürüne uygun doğru sürecin tanımlanması, ölçümlerin de bunun paralelinde yapılıp, iyileştirme için hızlı aksiyon alınmasıdır.
LAPIS ile birlikte, ölçülebilir ve geliştirilebilir bir sistem kurularak, kaynak yönetiminin kolaylaştığı, ihtiyaçların ve toplam faydanın hızlı bir şekilde belirlenebildiği bir süreç oluşturulmuştur. Bu sürecin değerlendirilmesi için ISO 15939 standartı temel alınarak, Hedef Soru Metrik yaklaşımı ile oluşturulan değerlendirme yöntemi kullanılmış ve uçtan uca izlenebilirlik sağlanmıştır. Bu yaklaşımda hem görselleştirmenin hem de oyunlaştırmanın olumlu etkileri gözlenmeye başlanmıştır. Planlaması iyi giden bir ürünün iş listesinde (Product Backlog) bekleyen maddelerin ortalama bekleme süresinin hedef süreden farklı olduğu tespit edilerek, ekip tarafından önlem alınmıştır. Kapasite planlamasının daha verimli yapılabileceği tespit edilmiş ve bu konuda iyileştirme çalışmaları yapılmaya başlanmıştır. Örneğin, bu kapsama alınan ürünlerde verimli planlama oranı için 2017 ve 2018 Mart-Mayıs dönemleri karşılaştırıldığında %32 oranında artış gösterdiği gözlenmiştir.
Şeffaflığın ve öngörülebilirliğin arttırılması sayesinde, paydaşlar arasındaki uyum ve buna bağlı verimlilik artışı sağlanmış, tüm bunların sonucunda da farklı bakış açılarına sahip paydaşların ortak kalite amacına ulaşması için adım atılmıştır.
İlerleyen aşamalarda, yazılım iç kalite metriklerinin de ölçüm metoduna dahil edilmesi planlamaktadır. Sürecin kod kalitesi ile birleşmesi sayesinde hedeflerde oluşabilecek sapmaların daha erken belirlenebilmesi ve iyileşme noktalarının daha net şekilde tespit edilmesi amaçlanmaktadır.
16. CONFLUENCE. The leading product for Document Collaboration, https:// www.atlassian.com/software/confluence/(2003) 17. Software Development Metrics, 1st Edition by Dave Nicolette (Author)