KALİTE’nin NERESİNDEYİZ?

Zamansızlık kavramının yaşamımızın her alanındaki etkisini yoğun bir şekilde hissettiğimiz son zamanlarda, buna bağlı olarak kalite ve verimlilik daha da önem kazandı. Zamansızlığa karşı mücadelemiz, iş hayatımızda olduğu gibi sosyal yaşantımızda da, sürekli olarak artan yapılacaklar listemizi ve önceliklerimizi tekrar gözden geçirmemize dikkat çekiyor. Tüm çabamız, iş yığınlarının (mümkünse) tamamını, (mümkünse) en kısa sürede, (mümkünse) minimum maliyette, (mümkünse) en iyi kalitede, (mümkünse) en motive şekilde eritebilmek için. Ancak tüm bu çabalarımıza rağmen, Gartner Inc.’nin hazırlamış olduğu rapora göre, gerçekleştirilen yazılım projelerinin %75’i başarısız oluyor. Bu başarısızlığın sebepleri arasında, tasarımın karmaşık olması ve uzun sürmesi gösteriliyor. Bu süreçte müşteri profillerinin ve ihtiyaçlarının değişmesi de, projenin hedeflediği sonucu başarısız kılıyor ve memnuniyetsizlik ile sonuçlanıyor. Dolayısıyla müşterinin “çıktı” ile ilgili nihai algısı üç başlıkta oluşuyor: “KALİTELİ / KALİTESİZ / İŞ GÖRÜR”. Bu nedenle çalışmalarımızın özüne, “KALİTE”ye odaklanıyoruz.

Değişim liderleri, kaliteyi tüm paydaşların dahil olması gereken bir “dönüşüm anahtarı” olarak görüyor. Ben de bu bakış açısından yola çıkarak, bu anahtarın üç ana parçasının- strateji, uygulama odağı ve sürdürebilirliği- üzerinden geçmek istiyorum.

Strateji

Yazılım kalitesi, farklı perspektiflerden doğan bakış açılarını içerir. Kullanıcı, yönetim, mühendislik bakış açıları gibi. İş süreçleri gerçekleşirken, hangi metodoloji, yöntem veya araçlar kullanılıyor olursa olsun, takımların öncelikle bu bakış açılarının bütünsel halini ortaya koyan bir kalite stratejisi belirlemesi önemlidir, ki bu strateji aslında şirketlerin kaliteyi anlama ve tanımlama şekline bağlıdır. Kaliteyi özetle, müşteri ihtiyacını optimum seviyede karşılayan “çıktının” özellikleri, olarak tarifleyebiliriz. Burada “çıktı”dan (outcome) bahsederken, ürün, hizmet, operasyon, bilgi, süreç, insan ve sistemlerin harmanlanmış bütününü, “Optimum” ifadesi ile de, kabul edilebilir eksiklikleri bünyesinde barındıran çıktının, kullanıma uygunluk seviyesini dile getiriyoruz.

Kalite aslında bir müşteri belirlemesidir, müşterinin ürün veya hizmetle ilgili gerçek deneyimine dayanır. Bu nedenle, eldeki imkanların yetkinliğini en optimal şekilde kullanarak oluşturulan, müşteri isterlerine cevap verecek ürün, en kaliteli üründür.

Takım ile müşteriler ve diğer paydaşlar arasındaki etkileşimin sağlanması, ortak çıkarlarda antant kalınması, kalitenin benimsenmesinde önemli bir kriterdir. Kalite kültürünün oluşması, esneklikle beraber kendini geliştirmesi, değişimi zamanla takımın bütünlüğü sağlayan ve motivasyonunu geliştiren bir zihniyete dönüşecektir. [https://www.researchgate.net/publication/301298539_SOFTWARE_QUALITY_FROM_SYSTEMS_PERSPECTIVE]

Uygulama Odağı

Kalite stratejisinin gerçeklenmesi ve sürdürülebilirliği, çalışma şeklimizden büyük ölçüde etkilenmektedir. Bu nedenle, müşteriler ve geliştiriciler arasındaki engelleri ortadan kaldırmak ve değişime (isteklere) hızlı ve esnek yanıt vermek için uygulama odağımızı çevik yaklaşımlara taşıyoruz. Bu yaklaşımlarla, hedeflediğimiz değerler kümesini oluşturmaya çalışırken, alt yapıdan iş akışlarına, kodlamadan teste, uçtan uca her adımı otomatize ederek, yazılım geliştirme çıktılarını, kuruma, dolayısı ile çalışanlara daha fazla değer katan iş ve ürün faaliyetlerine dönüştürmeye çalışıyoruz. [https://www.linkedin.com/pulse/software-development-framework-methodologies-devops-agile-kromann-b-/]

Ekiplerin büyüklüğüne, çalışma şekline ve ortaya çıkacak ürünün dinamiklerine göre farklı uygulama araçları olan Agile Proje Yönetimi, aslında bir metodoloji değil, Agile şemsiyesi altındaki yönetimsel ve teknik araçlar ile nasıl proje yönetimi yapabileceğimize dair bir yaklaşımdır. Agile uygulama araçlarının ortak noktası olan manifestonun vurguladığı, değerler bütününden ve perspektiflerinden uzaklaştığımız noktada ortaya çıkan her türlü verimsizlik kalitedeki başarısızlığımız olarak etkisini göstermektedir. Dolayısı ile hikayeler oluşturmak ve sprintlerde çalışmak, çevik olduğumuz anlamına gelmiyor.

Sürdürülebilir bir yazılım yaşam döngüsünün tasarlanması ve uygulanması, başarılı, bakımı yapılabilir ve hatasız bir ürün yaratmak için ilk temel adımdır. Bu süreci kurgularken veya iyileştirirken, maksimum etkiyi yaratmak ve optimum (en iyilenen) ürünü ortaya çıkarmak için, süreçte nelere ihtiyaç var, hangi faktörler dikkate alınmalı, ölçme ve izleme noktaları nasıl olmalı, olmazsa olmazlar kriterler neler, belirlemek gerekmektedir. Bu tespitler yıllar içinde büyüme stratejilerine yönelik beklentilere cevap verebilmek adına da önemlidir.

Çeviklik ritüelleri ise yüksek kalitenin elde edilmesi için önemli parçacıklardır. Bu ritüeller, ekibin mevcut durumu değerlendirmesine, geri bildirim almasına, ilerlemelerini gözlemlemelerine ve yaptıklarını müşterinin ihtiyaçları ile uyumlu hale getirmesine yardımcı olur. Ancak ritüellerde verimliliğinin elde edilmesi ve faydalarının görülmesi için, ekipteki herkesin senkronize olması sağlanmalı ve takım ile paydaşlar için önemi ortaya konmalıdır. Çevik ritüeller (kimilerine göre seremoniler), ürün ve süreç kalitesinin iyileştirilmesinde kilit bir rol oynar — herkes buna inanmalı, bağlı kalmalı ve kendi katılımını garanti etmelidir. Aktif katılım, yüksek kaliteli bir çıktı ve sorunsuz bir kalite güvence sürecinin anahtarıdır. [https://www.triad.co.uk/news/agile-ceremonies/]

Takım, yazılım yaşam döngüsünün her adımında ürünle bütünleşerek (ownership), bir gereksinim şartı olarak kaliteyi etkileyen konuları tartışmalı, ortak aklı kullanarak belirledikleri aksiyonları sprint işlerine mutlaka dahil etmelidir. Bu noktada, takımın amacına yönelik, üretime hazır ürün parçacığına ilişkin taahhüdü, “bitti” tanımıdır. Takımın bu adım kapsamında belirledikleri olmazsa olmaz kriterler, ürünü oluşturan parçalar için gerekli kalite ve ölçümleri karşılayan entegre çalışmanın bütünüdür (çıktısıdır).

Tabi ki kaliteli bir yazılım oluşturmak kolay bir iş değil, çok fazla pratik ve deneyim gerektirir. Yazılım kalitesini yönetmeye dair ortaya çıkacak işler zaman zaman birçok takım üyesi tarafından “ekstra” iş olarak görülmektedir ve geliştirme sürecinde ilk vazgeçilen adım olmaktadır. Bu aktiviteleri atlamak size kısa vadede daha hızlı olduğunuz yanılsamasını verebilir, ancak sonunda bedeli uzun vadede ödenir :). Böyle bir durumda yazılım, daha karmaşık hale gelecek veya anlaşılması ve üstesinden gelinmesi zor büyüyen teknik borç ve sık ortaya çıkan kalite problemleri ile karşılaşılacaktır. Otomatik testlerin olmaması nedeniyle yazılımcılar kod tabanında büyük değişiklikler ve yeniden yapılandırmalar yapmaktan korkmaya başlayacaklardır. Böylesine dağınık bir kod tabanında çalışmak, geliştiricileri hayal kırıklığına uğratabilir. Yeni özelliklerin oluşturulması ve yayınlanması gittikçe daha fazla zaman aldığı için ürün sahipleri/müşteriler ve diğer paydaşlar için de hoş karşılanmayacak bir durum oluşturacaktır. Kalite, maalesef daha sonra kolayca ekleyebileceğiniz bir süreç değildir. Ne kadar çok beklerseniz ve teknik borcunuzun artmasına izin verirseniz, yetişmek o kadar zor olacaktır. Dolayısıyla, hiçbir takım üyesi yazmamış olduğu veya eski bir kod için birim testleri yazmak istemez. Ya da hiçbir ürün sahibi, yeni özellikler eklenmeksizin, sadece kodun temizlendiği veya ürünün kalitesinin arttırıldığı çalışmalar için harcanan zamanı kabul etmez. Daha sürdürülebilir ve verimli bir gelişim döngüsüne sahip olmak için, tek bir kod satırını yazmadan önce bile kalite hakkında düşünmeye başlamamızın en önemli nedeni budur. [dev.to/how-to-start-a-software-project-with-a-quality-mindset-3e7i]

Çevik’iz derken?

Agile yaklaşım ve uygulama odağımızı anlamanızda size yardımcı olacak birkaç soru paylaşmak istiyorum. Her bir soru için cevaplarınızı, mevcut durumu ortaya koyup, ulaşmak istediğiniz noktaları adım adım belirleyerek vermenizi tavsiye ediyorum. Noktaların birleşimi, size kalite iyileştirme yol haritasını verecektir, aksiyona geçebilirsiniz :)

· PBI gereksinimleri tanımlanıyor mu?

· Ürün parçası ne zaman “Bitti” kabul edilir?

· Kabul kriterleri belirleniyor mu?

· Engeller / başarısızlıklar konuşuluyor mu?

· Gerçekleşmeyen sprint hedefi takımı nasıl etkiliyor?

· Kodlama standardınızın neresindesiniz?

· Teknik borçlar unutuluyor mu?

· Statik kod analizi sonuçlarına manuel müdahale var mı?

· Hangi testler mutlaka otomatize edilmeli?

· Takımın kapasite tanımı nedir?

· Hatalar ve kök nedenleri inceleniyor mu?

· Takımın kalite tanımı, hedefi nedir?

· Entegrasyon testlerinde sık karşılaşılan problemler neler?

· Hiç sprint iptali gerçekleşti mi?

· Ekip üyeleri çapraz fonksiyonları gerçekleştiriyor mu?

· Müşteri geri bildirimleri takıma nasıl yön veriyor?

· Üründen ödün verme çerçevesi nedir?

· Paydaşlar kalite kültürüne dahil mi?

· Kod incelemelerinin sürdürebilirliğe katkısı nedir?

· Kodun ürüne dahil olmadan önceki son kontrol kriteri nedir?

· Takım agile yaklaşımın katkılarını en çok nerelerde hissediyor?

· Scrum master takıma ve organizasyonuna hizmeti gerçekleştirebiliyor mu?

· Şeffaflık nerede bitiyor?

Sürdürebilirlik

Paydaşlar, kalitenin önemi ve gereklilikleri konusunda takım ile ortak noktaya ulaşmalıdır. Bu bilincin olmadığı durumda kalite için verilen ödün, minimum uygulanabilir üründen ödün vermek anlamına gelecektir. Burada bir diğer önemli nokta, şeffaflığı ve görünürlüğü arttırmaktır. Maalesef, görülmeyen bir çalışma hak ettiği değeri bulamaz. Bu nedenle çalışmalardaki kalitenin görünürlüğünü arttırmanın yolları aranmalı, bunun için tüm paydaşlar işbirliği içerisinde olmalı ve en uygun çözüm bulunmalıdır. Bu süreç içinde takımın güçlendirilmesi ve ürünün bütünsel vizyonunun ortaya koyulmasında ürün sahibi (Product owner) ve scrum master ın birleştirici ve bağları güçlendirici rolleri ön plana çıkmaktadır. [https://techbeacon.com/app-dev-testing/how-i-created-culture-quality]

Sürekli geliştirme, iyileştirme prosesini uygulayabilmeniz için yazılım kalitesini kontrol etmeniz, ölçmeniz ve izlemeniz gerekir. Ölçüm kriterleri takımın ve ürünün dinamiklerine, hedeflerine göre değişebilir ve ölçülmeyen hiçbir çalışma, iyileştirilemez. Ürünün sahibi takım, kalite stratejileri doğrultusunda belirledikleri yol haritasındaki ritüellerine, ölçme değerlendirme kriterlerini yerleştirmelidir. İşleyen döngü içerisinde, deneme — yanılma ile elde edilen deneyimin elde tutulması, deneyi başarılı sonuca götürecektir.

Sürekli gelişim hem ürün hem de takım seviyesinde yürüyen bir prosestir. Gelişim yolculuğunu bir zincir gibi düşündüğümüzde, takım belli bir doyuma ulaştığında zincirin bir halkasını örmüş olur ve yeni bir doyum noktası oluşacaktır. Bir sonraki zincir için takım, her seferinde kalitenin tanımı iyileştirerek değiştirecektir. Hedefin, ürünün iyileşmesi yönündeki değişimi, takımın yetkinlik ve kişisel gelişimini de tetikleyecek ve motivasyonunu olumlu yönde etkileyecektir.

İyileştirme programımızı uygularken, müşterinin kalite gereksinimlerini göz önünde bulundurmalı, bir kalite yaklaşımının işimizi nasıl etkilediğini anlamalı, süreçlerimizi haritalandırmalı, gerçekte neler olduğunu görmemize yardımcı olacak uygun araçları kullanmalı ve kalitemizi en kısa sürede düzeltme noktasında kararlı olmalıyız. Bu düzeni ve kararlılığı yönetirken, sistemin gelişime açık yönleri veya takıma engel oluşturan konularda organizasyonun ilgili rollerini işin içine dahil etmekten ve çözüme katkı sağlamalarını beklemekten imtina etmemeliyiz, bırakınız yapsınlar :)

Son olarak, işe nereden nasıl başlayalım derseniz, uçtan uca kalite yönetimi için olmazsa olmaz 10 temel adım:

· Kalite tanımınızı mutlaka yapın, standartlarınızı belirleyin: sürdürülebilir, kalıcı yazılım kalitesi üretmek, uzun vadeli düşünme ve strateji gerektirir.

· Kalite yönetimini en baştan uygulayın: yazılım döngüsünün en başından, son noktasına kadar her aşamasında takımın kalite farkındalığının olduğundan emin olun. Kalitenin güvence altına alınması, takımın yönetişiminde saklıdır.

· Çıktılarınızın ana hatlarını belirleyin: ekibin kalite çıktılarını belirlemesi, şeffaflığı destekler, güveni perçinler. Kalite hedefleriniz doğrultusunda, neleri ölçüp, iyileştireceğinize karar verin.

· Otomasyon ile erken ve sık sık test edin: Erken testler, herhangi bir kusurun daha büyük, daha karmaşık sorunlara dönüşmemesini sağlayacaktır. Kusur ne kadar büyükse, sorunları çözmek o kadar pahalı hale gelir.

· Yenilikleri teşvik edin: Ekipleri sürekli olarak keşfetmeleri, denemeleri ve araştırmaları için güçlendirin. Önerileri tartışın.

· İş yönetimi yaklaşımınızı optimize edin: uyguladığınız metodoloji ne olursa olsun, hakkını verdiğinizden, maksimum faydayı elde ettiğinizden mutlaka emin olun.

· İletişim kaslarınızı kullanın: Tüm paydaşları iletişim kanalı içinde tutun,

· Değiştirilebilir bir ortam için plan yapın: yazılım sürecini etkileyen dış faktörleri ve değişkenleri izleyin,

· Riskleri ve engelleri görmezden gelmeyin: ortadan kaldıramayacak veya çözemeyecek olsanız bile farkında olun.

· Gözden geçirin, revize edin ve hatırlayın: Kalite tanımınızın neresinde olduğunuzu tartışın, iyileştirme aksiyonlarınızın yazılım kalitenizi daha da öteye taşıyıp taşımayacağını görün ve neyin iyi çalıştığını, neyin işe yaramadığını hatırlayın.

Elif Çoban

Teknoloji Strateji ve Dönüşüm Yöneticisi