Değerli Olanı Yapmak — IV (Agile Yazılım Geliştirme)
Agile yazılım geliştirme yaklaşımları, yüksek kalitede kodun verimli şekilde teslimine odaklanıyor, daha yüksek tahmin edilebilirlik, çıktı ve üretkenlik vaat ediyor.
Bu yazı Değerli Olanı Yapmak — I, Değerli Olanı Yapmak — II (Design Thinking), Değerli Olanı Yapmak — III (Lean Startup), Değerli Olanı Yapmak — IV (Agile Yazılım Geliştirme), Değerli Olanı Yapmak — V (Design Thinking+Lean Startup+Agile Yazılım Geliştirme) başlıklı 5 yazıdan oluşan serinin dördüncü yazısıdır.
Marc Andreessen 2011’de Wall Street Journal’daki “Why Software Is Eating The World” makalesinde yazılımın şirketlerin kalbi olduğu yeni bir döneme vurgu yapıyordu.
Bugün yazılım her yerde…
Bu şirketler için de bir o kadar zorlayıcı. Bir organizasyon kendini rakiplerinden ayrıştırmak için teknolojiye güveniyorsa ya da teknoloji işinin kalbi haline gelmişse yazılım üretim süreniz daha kritik hale geliyor. Bir iş fikrini üretimde çalışan bir yazılım halinde ne kadar hızlı sunabiliyorsa pazarda o kadar hızlı oluyor, o kadar rekabetçi olabiliyor.
Agile yazılım geliştirme yaklaşımları, yazılım geliştirme aşamasındaki belirsizliklerle başa çıkabilmek adına doğdu, verim artışı ve pazara hızlı çıkmamızı sağlıyor. Agile, yüksek kalitede kodun verimli şekilde teslimine odaklanıyor, daha yüksek tahmin edilebilirlik, çıktı ve üretkenlik vaat ediyor.
Bugün Agile yazılım geliştirme yaklaşımlarıyla yazılım geliştirme bandımızdan hızlı çıktılar elde edebiliyoruz.
1990’lardan başlayarak DevOps’a gelen süreçte nasıl bu noktaya geldiğimize bir bakalım.
1990'lar, fazla regüle, planlı ve detayların yönetildiği kapsamlı metodlara karşılık olarak daha sade pek çok alternatif çerçevelerin çıkışına şahit oluyor. Bunlardan bazılarına örnek verirsek;1991'de rapid application development (RAD), 1994'te unified process (UP) ve dynamic systems development method (DSDM), 1995'te Scrum, 1996'da Crystal Clear ve extreme programming (XP), 1997'de de feature-driven development kendini gösteriyor. Her birinin kendi uygulayıcıları ve meraklıları tam olgunlaşmamış olsa da bu yöntem ya da çerçevelerle tek bir şey yapmadıklarının farkındalar: ağır dokümantasyona dayalı, hantal yazılım geliştirme.
11–13 Şubat 2001'de, Snowbird, Utah’ın Wasatch dağlarında bir kayak merkezinde içlerinde Kent Beck, Ward Cunningham, Dave Thomas, Jeff Sutherland, Ken Schwaber, Jim Highsmith, Alistair Cockburn ve Robert C. Martin’in de olduğu 17 yazılım geliştirici konuşmak, kayak yapmak, yemek yemek ve ortak bir anlayış geliştirmek adına bir araya gelirler. Sonunda, yukarıda saydığım ve atladığım, ağır dokümantasyona dayalı kapsamlı geliştirme süreçlerine alternatif metodların temsilcileri birlikte Agile Yazılım Geliştirme Manifestosu’na imzalarlar.
Hem kendi yazılım geliştirme tecrübeleri hem de bu konuda başkalarına yardım ederken öğrendikleriyle, on yedi kişi manifesto ile şöyle dediler;
Bizler daha iyi yazılım geliştirme yollarını, uygulayarak ve başkalarının da uygulamasına yardım ederek ortaya çıkartıyoruz.
Bu çalışmaların sonucunda:
Süreçler ve araçlardan ziyade bireyler ve etkileşimlere
Kapsamlı dökümantasyondan ziyade çalışan yazılıma
Sözleşme pazarlıklarından ziyade müşteri ile işbirliğine
Bir plana bağlı kalmaktan ziyade değişime karşılık vermeye
değer vermeye kanaat getirdik.
Özetle, sol taraftaki maddelerin değerini kabul etmekle birlikte, sağ taraftaki maddeleri daha değerli bulmaktayız.
Zannediyorum uzun olduğundan daha az dolaşımı olan ancak benim çok daha değerli bulduğum “Çevik Bildirinin Temelindeki İlkeler” ise şunlar;
Bizler şu ilkeleri izliyoruz:
En önemli önceliğimiz değerli yazılımın erken ve devamlı teslimini sağlayarak müşterileri memnun etmektir.
Değişen gereksinimler yazılım sürecinin son aşamalarında bile kabul edilmelidir.
Çevik süreçler değişimi müşterinin rekabet avantajı için kullanır.
Çalışan yazılım, tercihen kısa zaman aralıkları belirlenerek birkaç haftada ya da birkaç ayda bir düzenli olarak müşteriye sunulmalıdır.
İş süreçlerinin sahipleri ve yazılımcılar proje boyunca her gün birlikte çalışmalıdırlar.
Projelerin temelinde motive olmuş bireyler yer almalıdır.
Onlara ihtiyaçları olan ortam ve destek sağlanmalı, işi başaracakları konusunda güven duyulmalıdır.
Bir yazılım takımında bilgi alışverişinin en verimli ve etkin yöntemi yüzyüze iletişimdir.
Çalışan yazılım ilerlemenin birincil öçüsüdür.
Çevik süreçler sürdürülebilir geliştirmeyi teşvik etmektedir.
Sponsorlar, yazılımcılar ve kullanıcılar sabit tempoyu sürekli devam ettirebilmelidir.
Teknik mükemmeliyet ve iyi tasarım konusundaki sürekli özen çevikliği artırır.
Sadelik, yapılmasına gerek olmayan işlerin mümkün olduğunca arttırılması sanatı, olmazsa olmazlardandır.
En iyi mimariler, gereksinimler ve tasarımlar kendi kendini örgütleyen takımlardan ortaya çıkar.
Takım, düzenli aralıklarla nasıl daha etkili ve verimli olabileceğinin üzerinde düşünür ve davranışlarını buna göre ayarlar ve düzenler.
Agile’ın kelime olarak popülerleşmesi de Manifesto ile birlikte oluyor. Bu manifestoda yer alan değer ve prensipler Scrum ve Kanban’ın da dahil olduğu yazılım geliştirme çerçevelerinden geliyor.
Manifesto ve dayandığı ilkeler takımları değişime karşılık vermeye, önceliklere göre çalışmaya, kendini iyileştirmeye ve iletişimin arttırılmasına teşvik ediyor.
Kalbinde teknolojinin olduğu organizasyonlar rekabette önde kalabilmek adına bir sonraki adımda neler yapmaları gerektiğini genellikle kesin şekilde bilemiyor. Ürün yöneticilerinin/sahiplerinin sadece doğrulamaları gereken hipotezleri var. Bu durumda, hızlı geri bildirim daha da önemli oluyor.
“A plan is an example of what could happen, not a prediction of what will happen.” – Kent Beck
Agile yazılım geliştirme yaklaşımları buna çözüm olarak işbirliğini destekliyor ve birden çok seviyede kısa geri bildirim döngüleri getiriyor. Yazılımın henüz tamamlanmamış ancak kullanılabilir bir versiyonunu çıkarak gerçek kullanıcı/müşteri geri bildirimi alabiliyorsunuz. Bu geri bildirimlerle geliştirme eforunun yönü değişebiliyor, gereksiz özellikler için anlamsız efor harcanmamış oluyor. Bu hem çıktının artmasına hem de doğru işin daha kısa sürede üretime çıkmasını sağlıyor. Buna yalın yönetimden gelen ifadesiyle “waste’in azaltılması deniyor, aynı fikir manifestoya temel olan ilkelerde (benim en sevdiğim) “maximising things not done” olarak geçiyor.
Üretim sürecinin kendisi hızlı olsa bile bu her zaman pazara hızlı çıkacağını anlamına gelmez, bazı sıkıntılar üretime geçme hızını yavaşlatabilir. İyi test edilmiş, düzenli entegrasyonu yapılmış kod üretime hızlı çıkamıyorsa çevik olamaz.
Farklı ekiplerin farklı odakları ve öncelikleri olabiliyor. Ekiplerin kendi hedefleri konusundaki başarıları ve kendi iyileştirmeleri sistemin tamamı için her zaman anlamlı olmuyor. Bu yazılım geliştirme sürecinde de böyle … Geliştirme ekipleri zamanında ve bütçeye uygun şekilde teslimata odaklanırken, bunu yazılımın kararlılığı ve sürdürülebilirliğinin iatendiği gibi olmaması pahasına yapabilirler, çünkü çoğunlukla bundan sorumlu tutulmayacaklarını düşünürler. Operasyon ekipleri ise kararlılık ve operasyonun maliyetine odaklanır, o yüzden her yeni versiyonunun onlar için bir bilinmezlik olduğunu düşününce versiyon çıkışlarındaki uzun süreçlerin mantığını da anlayabilirsiniz. Diğer yandan bu, daha az işbirliği ve üretim süresinin uzaması anlamına gelir.
Organizasyonların geliştirme ve operasyon ekipleri arasında yakın işbirliğine izin verilmesinin ötesinde, teşvik edildiği bir modele geçmesi bu yüzden değerli.
Bugünün dünyasında, belli büyüklüğün üzerindeki tüm şirketler bir şekilde yazılım geliştirme işiyle ilgili, öyleyse buna göre davranmak zorundalar. Yazılım geliştiriciler üzerinde güvenlik ve güvenilirliği kurban etmeden daha hızlı ve daha çevik olma yönünde hiç olmadığı kadar büyük baskı var. DevOps’un adreslemeye çalıştığı durum da bu: organizasyon içindeki geliştirme, operasyon ve diğer grupları, müşterilere daha hızlı ve daha güvenilir bir yazılım teslim etmek için ortak bir amaç etrafında toplamak.
Yazılım artık statik bir kod değil, daha çok sürekli iyileştirilen, geliştirilen, arttırılan dinamik ve devamlı bir sistem.
Düşünsenize, Amazon her 11.6 saniyede bir geçiş yapıyor. Organizasyon içinde yazılımın uçtan uca sahipliğinden sorumlu tüm ekiplerin birlikte çalışması, DevOps, ile daha çevik oluyoruz.
Peki yazı dizisine başladığımızdaki soruyu tekrar soralım:
Agile Yazılım Geliştirme, yalnız başına tüm problemlerimizi çözecek mi?
Yoksa, sadece sistemden daha hızlı çıktı geçmesini mi sağlayacak?
Bunun cevabını yazı dizisinin son yazısında vermeyi umuyorum.
