Agile Nedir? Bir Yazılım Geliştirme modeli olarak Agile
Agile modelleri bir tür yazılım geliştirme modelidir. Geleneksel waterfall modelleri ile karışlaştırıldığında, Geleneksel waterfall modelleri daha net çizgilere sahip olduğu söylenebilir. İşlemler arası geçişler daha net çizgilerle belirlenmiştir yani bir process tamamlandığında diğer process’e geçilir. Analiz safhası bitmeden design safhasına geçilmez gibi.
Waterfall yaklaşımında işlemler aşağıdaki görselde olduğu gibi tek tek ilerliyordu ve ilerki safhalarda bir sorun yaşandığında bunu düzeltmenin maliyeti ilk safhadaki düzeltmelere göre kat kat fazlaydı. Hatta bununla ilgili cost of changes eğrileri çokça karşınıza çıkmıştır. Bütün safhalar bir önceki safhanın tamamlanmasını bekliyordu. Başlangıçtan projenin sonuna kadar geçen süre uzun olabiliyordu ve bu süreçte kullanıcı ihtiyaçları yanlış anlaşılabiliyor veya doğru çalışmalar yapılamayabiliyordu. Diğer bir problem de projenin sonuna kadar geçen süre arttıkça bulunan piyasaya göre ihtiyaçların değişmesiydi. Bunlar waterfall modeli kullanan şirketler için büyük kayıplar yaratıyordu. Önüne geçmek ve bu süreçleri daha iyi değerlendirmek için Agile modelleri geliştirilmiştir. Agile Modellerinde gereksinimlerin zamanla değişmesine izin verilir. Yani başlangıçta düşünülen şeyin tam olarak aynısını inşa etmeyebiliriz, zamanla değişebilir, ancak sonunda ne inşa edersek edelim kullanıcının tam olarak ihtiyaç duyduğu şey olmalıdır. Feedback ve zaman içindeki gereksinimlerin, değişimlere neden olmasına izin verilir.
İçlerinde Jon Kern, Kent Beck, Ward Cunningham, Arie van Bennekum, and Alistair Cockburn’unda bulunduğu 17 kişiden oluşan bir grup, “düşünce liderleri”, önce 2000 yılında Oregon’da bir otelde daha sonra da 2001 yılında Utah’da bir kayak merkezinde buluşarak yazılım geliştirme sürecinde daha üretken ve verimli işler sunabilmek adına beyin fırtınası yaptılar. Toplantılarının sonucunda fikir birliğine vararak Agile Manifesto’yu ve Agile Yazılım’ın 12 Prensibini yazıya geçirdiler.
Agile Manifestosunda yer alan başlıklara göz atıp, prensipleri inceleyeceğim.
Agile yaparak ve başkalarının yapmasına yardımcı olarak yazılım geliştirmenin daha iyi yollarını keşfediyoruz. Daha ileri gitmeden önce, şu ana kadar ilginç birkaç kelimeyi inceleyelim. İlki “keşfetmek”(uncovering). Öyleyse keşfetmekle kastettikleri, henüz tamamlanmamış olmalarıdır yani hala öğreniyorlar. Ve sonra ilginç bulduğum başka bir şey “yapmak”(doing it). Yani uygulayıcılar, bu değerleri tanımladıklarında, aslında yaptıkları işin bu olduğu ortaya çıktı. Yani aslında bu şekilde yazılım geliştiriyorlardı ve deneyimlerine dayanarak değerleri yaratıyorlardı. Ve üçüncüsü, “başkalarına yapmasını söylemek değil, başkalarının yapmasına yardım etmektir”(helping others to do it). Bu yüzden bu çalışma sayesinde bireylere ve etkileşimlere süreç ve araçlardan, çalışan yazılımlara da kapsamlı dokümantasyondan çok değer verilir. Sözleşme kontratları yerine müşteri işbirliği ve bir planı takip ederek değişime yanıt verme; Şimdi, insanlar bu manifestoyu veya bu değerleri okur okumaz “Peki, bu dokümantasyonun bir değeri olmadığı anlamına mı geliyor yoksa bir planımız olmaması mı gerekiyor?” diyebilir. Kesinlikle hayır. Açık olmak için manifestoyu okumaya devam edelim. Yani sağdaki öğelerde değer varken soldaki öğelere daha çok değer veriyoruz. Yani dokümantasyonda değer var, planda değer var ama çalışan yazılıma dokümantasyondan daha çok değer veriyoruz. Bu durumlarda doğru yolu bulmak adına aşağıdaki 4 agile değerini açıklamaya çalışmak istiyorum.
-süreçler ve araçlar yerine bireysel etkileşimler
-Kapsamlı dokümantasyon’a odaklanmak yerine Çalışan Yazılıma odaklanmak
-Sözleşme Pazarlığı’ndan ziyade Müşteri İşbirliği’ne odaklanmak
-bir planı takip etmek yerine değişime cevap vermek
İlk olarak “süreçler ve araçlar yerine bireysel etkileşimler.” Bunun anlamı, çoğu zaman bir sorun olduğunda veya süreçlerimizi iyileştirmek istediğimizde sık sık çıkmaza girebiliriz ve genel olarak bize yardımcı olabilecek ek bir süreç var mı? Bize yardımcı olabilecek başka bir araç var mı? diye düşünürüz, yani bireylere ve onların etkileşimlerine odaklanamayız. Çoğu zaman, bireylere ve etkileşimlere yeterince önem vermiyoruz. Bireylerin birbirleriyle olan etkileşimleri arttırılıp birimler arası organizasyonu daha iyi hale getirebiliriz. Günlük face-to-face toplantılar bunu sağlayabilir.
İkincisi “kapsamlı dokümantasyona odaklanmak yerine çalışan yazılımlara odaklanmak”, bu dokümantasyon yapmadığınız anlamına gelmez. Kritik olan her yerde, ne gerekiyorsa dokümantasyonu yaparsınız ancak müşterinin gözünden bakılırsa, müşterilerin gerçekten önemsediği şey çalışan yazılımdır. Onlar için dokümantasyonun pek bir değeri olmayacaktır. Sizin için önemlidir ama kullanıcı için anlam ifade etmez.
Üçüncüsü ise “sözleşme pazarlığı yerine müşteri işbirliği.”, sözleşme önemlidir çünkü çalışmanız gereken sınırları tanımlar ancak uygun müşteri-geliştirici işbirliği ile kullanıcının ihtiyaçlarını anlayabilir ve daha iyi bir yazılım oluşturabilirsiniz.
Ve sonuncusu “bir planı takip etmek yerine değişime cevap vermek”. Bir plana ihtiyaç vardır çünkü bu doğru yolda kalmanıza yardımcı olur. Ancak değişime hayır dememeli ve nihayetinde kullanıcının ihtiyaç duymayacağı bir şey inşa edilmemelidir. Plan bizi kör etmemeli. Değişime çabuk adapte olunmalı ve ihtiyaçlar kaçırılmamalıdır.
Agile modellerini kullanmak için bazı ön koşullar vardır diyebiliriz. Bunların ilki, gereksinimler önceden net tanımlanmadığı için iş dünyası ve kullanıcılarla yakın işbirliğine ihtiyaç duyulur. İş insanları ve geliştiriciler arasında sürekli bir görüşme veya müzakere gerçekleşmelidir, bu nedenle işbirliğine ihtiyaç vardır. Ve ikincisi, değişimi benimsediğiniz için, takımın değişime hazır olması gerektiğidir; bu, değişiklikleri hızlı ve güvenli bir şekilde yapmalarına yardımcı olmak için mühendislik uygulamalarını takip etmeleri gerektiği anlamına gelir.
Agile İlkeleri
En yüksek önceliğimiz, faydalı yazılımların erken ve sürekli teslimi ile müşterileri memnun etmektir. (Müşterinin en çok neye değer verdiğine, yani çalışan yazılıma odaklanmak istiyoruz.)
Geliştirmenin sonlarında bile değişen gereksinimleri karşılayın. Agile süreçler, müşterinin rekabet avantajı için değişimden yararlanır.(bunun anlamı değişimi kucaklamaktır)
Çalışan yazılımı birkaç haftadan birkaç aya kadar daha kısa bir zaman dilimi tercih ederek(örn; waterfall metoda göre daha kısa) sık sık teslim edin. (fikir sürekli öğrenmektir. Yani, bir şeyler inşa edin, müşteriye gösterin ve sonra öğrenin.)
İş insanları ve geliştiriciler proje boyunca sık sık birlikte çalışmalıdır. (Bu bireyler arasındaki işbirliği ile ilgilidir, böylece etkili bir şekilde paylaşılan anlayış inşa edilebilir.)
Motive olmuş bireyler etrafında projeler oluşturun. Onlara ihtiyaç duydukları ortamı ve desteği verin ve işi bitireceklerine güvenin.
Geliştirme ekibine bilgi aktarmanın en verimli ve etkili yöntemi yüz yüze görüşmedir.
Çalışan yazılım, ilerlemenin birincil ölçüsüdür. (planlama belgesini oluşturabilirsin, gereksinimler belgesini oluşturabilirsin, ancak ilerlemeyi ölçmenin birincil ölçüsü çalışan yazılım olacaktır. Yani burdan yola çıkarak sadece Gereksinimleri ve tasarımı yapmış olsaydık bu şartlarda sıfır ilerleme kaydetmiş olurduk.)
Agile süreçler, sürdürülebilir gelişimi destekler. Sponsorlar, geliştiriciler ve kullanıcılar süresiz olarak sürekli bir hızı koruyabilmelidir.
Teknik mükemmelliğe ve iyi tasarıma sürekli dikkat çevikliği artırır. (Teknik mükemmelliğe sahipseniz ve tasarımınıza dikkat ederseniz muhtemelen kolayca değiştirilebilecek bir sistem inşa edeceksiniz ve değişimi kolayca kucaklayabileceksiniz)
Basitlik, yapılmayan(yapılması gerekmeyen) iş miktarını maksimize etme sanatıdır.
En iyi mimariler, gereksinimler ve tasarımlar kendi kendini organize eden ekiplerden ortaya çıkar. (yatırım yapmaya çalışmak, ekip üyelerini yazılım üzerinde çalışmaya teşvik etmek ve olabildiğince kendi hallerine bırakmak)
Ekip düzenli aralıklarla nasıl daha etkili olacağına kafa yorar, ardından davranışını buna göre ayarlar ve uyarlar. (Sürekli iyileştirme)
Agile Framework’leri
Bildiğimiz gibi, Agile bir düşünce yapısı, zihniyettir. Öyleyse soru şu, bu zihniyeti bir yazılım geliştirme sürecine nasıl uygulayabilirsiniz? Agile zihniyetini ekibinize veya projenize uygulamak için kullanabileceğiniz birçok Framework mevcuttur. Ama herhangi bir yapı için Silver Bullet mevcuttur diyemeyiz. Yani şu framework bu iş yapısı için net iyidir diyemeyiz. Şirket içi durum ve spesifik konulara göre işleyiş farklılık gösterir. Bu nedenle, ekibinizin, projenizin veya organizasyonunuzun ihtiyaçlarını karşılamak için bu çerçeveyi özelleştirmeniz gerekir. Öyleyse, çevremizde bulunan bu çerçevelerden bazılarına kendimizi alıştıralım. En yaygın olanlardan biri Scrum’dır.
Scrum, parçası olunan bir projenin tanımı, geliştirilmesi, tasarımı ve yazılımının test edildiği ve böylece ürünün aşamalı olarak geliştirildiği 1-4 haftalık(aralıklar sabit uzunlukta olur ve projeye göre ayarlanır) döngüye(sprint’ler) dayanmaktadır.
Bir diğer popüler olanı, temel olarak mevcut yazılım geliştirme sürecinizi optimize etmeye çalıştığınız sürekli akış modeline dayanan Kanban’dır.
Elbette, Scrum’ı birincil framework olarak kullandığınız Scrumban, bu ikisinin bir kombinasyonudur. Ve sonra sprintinizdeki akışınızı optimize etmek için Kanban’ı kullanırsınız.
Scrum’a benzeyen bir diğer popüler program ise XP’dir. XP, Scrum uygulamalarının çoğuna sahiptir, ancak aynı zamanda bir Agile takımı için çok önemli olan bazı mühendislik uygulamalarını da tanımlar.
Sonra elbette Scrum ve XP’nin karması var. Son zamanlarda oldukça popüler hale gelen bir diğeri ise, öngörülemeyen çok sayıda pazarınız veya endüstriniz varsa ve çözümünüzü uygulamadan önce gerçekten kanıtlamak istiyorsanız size yardımcı olacak olan framework Lean Startup’tır.
Ve çok daha fazlası sayılabilir. Çoğu zaman, organizasyonlar aslında ekiplerinin, projelerinin veya organizasyonlarının ihtiyaçlarını karşılamak için bu çerçevelerden bazılarını özelleştirirler. Agile ilkeleri ve uygulamaları ile belirli bir framework’un ritüelleri, uygulamalarına takılıp kalınmamalı. Popülerlik açısından Scrum açık ara en popüler olanıdır. Agile takımlarının yaklaşık %70'i Scrum’ı veya onun türevlerinden birini kullanıyor. Bazen insanlar Agile ile Scrum’ı aynı şeymiş gibi düşünürler, bunun doğru olmadığını göstermeye çalıştık. Agile uygulamanız için kullanabileceğiniz çok sayıda framework vardır.
