Agile Manifesto Nedir? 4 Değer, 12 İlke ve Çevik Yazılım Geliştirme

Agile Manifesto, yazılım geliştirmede değişime daha hızlı yanıt vermeyi, çalışan ürün üzerinden değer üretmeyi, insanlar arasındaki etkileşimi ve müşteriyle iş birliğini öne çıkaran 4 değer ve 12 ilkeden oluşan bir çerçevedir. 2001 yılında 17 yazılım profesyoneli tarafından kaleme alınan manifesto, bugün Agile olarak adlandırdığımız çevik yaklaşımın temel referanslarından biridir.

Ancak Agile Manifesto bir proje yönetimi yöntemi, süreç tarifi veya Scrum kullanım kılavuzu değildir. Takımlara hangi toplantıyı ne zaman yapacaklarını söylemez. Bunun yerine karar verirken neyi daha değerli görmemiz gerektiğine ilişkin bir düşünme biçimi sunar.

Bu ayrım önemli.

Çünkü bir takım bütün Scrum etkinliklerini eksiksiz yapıp yine de çevik davranmayabilir. Başka bir takım ise Scrum kullanmadan Agile Manifesto'nun değerlerine oldukça yakın çalışabilir. Orijinal Çevik Manifesto'yu incelemek için agilemanifesto.org adresini ziyaret edebilirsiniz.

Agile Manifesto Nedir?

Agile Manifesto'nun resmi adı Manifesto for Agile Software Development, yani Çevik Yazılım Geliştirme Manifestosu'dur. 11–13 Şubat 2001'de Utah'taki Snowbird kayak merkezinde bir araya gelen 17 yazılım profesyoneli; Extreme Programming, Scrum, DSDM, Crystal, Feature-Driven Development ve benzeri farklı yaklaşımlardan geliyordu. Ortak problemleri ise ağır süreçlere ve kapsamlı ön planlamaya dayanan yazılım geliştirme yöntemlerinin değişken ve belirsiz ortamlarda yarattığı zorluklardı. Bu buluşmanın sonucunda bugün Agile Manifesto olarak bildiğimiz 4 değer ortaya çıktı.

Manifestonun temel düşüncesi oldukça yalındır: Bir taraftaki unsurların değersiz olduğu söylenmez; ancak belirli durumlarda diğer taraftaki unsurlara daha fazla değer verilmesi gerektiği vurgulanır.

Bu nedenle Agile'ı “plan yapmamak”, “dokümantasyon yazmamak” veya “süreçleri ortadan kaldırmak” şeklinde yorumlamak manifestonun özünü kaçırır.

Agile Manifesto Neden Ortaya Çıktı?

Yazılım geliştirme doğası gereği yüksek belirsizlik içerir. Bir ürün geliştirmeye başladığınızda müşterinin gerçekten neye ihtiyaç duyduğunu, pazarın nasıl değişeceğini veya teknik çözümün hangi noktalarında sorun çıkacağını her zaman baştan bilemezsiniz.

Buna rağmen bütün gereksinimleri baştan kesinleştirmeye, uzun süre geliştirme yapıp ürünü en sonunda müşteriye göstermeye dayanan yaklaşımlar önemli bir risk yaratır:

Plan doğru uygulanabilir ama ortaya çıkan ürün yanlış olabilir.

Agile yaklaşımın temel farkı burada ortaya çıkar.

Amaç değişimi engellemek değil, değişime cevap verebilecek bir çalışma sistemi kurmaktır. Büyük kararları mümkün olduğunca erken kilitlemek yerine küçük parçalar halinde değer üretmek, geri bildirim almak ve yeni bilgi geldikçe yön değiştirebilmek hedeflenir. Bu nedenle Agile Manifesto yalnızca daha hızlı yazılım geliştirmekle ilgili değildir. Asıl mesele belirsizlik altında daha iyi karar verebilmek ve öğrenme süresini kısaltmaktır.

Agile Manifesto’nun 4 Değeri

Manifesto dört temel değer karşılaştırması üzerine kuruludur. Bu değerlerin en sık yanlış anlaşılan tarafı, sağ taraftaki unsurların gereksiz olduğunun düşünülmesidir.

Manifesto aslında tam tersini söyler: Her iki taraf da değerlidir ancak soldaki unsurlara daha fazla önem verilir.

1. Süreçler ve araçlardan önce bireyler ve etkileşimler

Süreçler ve araçlar çalışma biçimimizi destekleyebilir. Ancak hiçbir süreç insanların sağlıklı iletişim kuramadığı bir organizasyonu tek başına düzeltemez.

Bir takımda Jira kusursuz yapılandırılmış olabilir, bütün süreçler dokümante edilmiş olabilir ve herkes hangi adımı izlemesi gerektiğini biliyor olabilir. Fakat ürün, teknoloji ve iş ekipleri birbirleriyle gerçek bir diyalog kuramıyorsa sistem yine de yavaş çalışabilir.

Agile'ın burada söylediği şey “süreç kullanmayın” değildir.

Süreci insanların daha iyi birlikte çalışmasını sağlamak için kullanın; insanların sürece hizmet etmesini beklemeyin.

2. Kapsamlı dokümantasyondan önce çalışan yazılım

Dokümantasyon değerlidir. Özellikle karmaşık sistemlerde mimari kararların, API'lerin, kritik süreçlerin veya operasyonel bilgilerin kayıt altına alınması gerekir. Sorun dokümantasyonun kendisi değil, dokümanın ilerlemenin kanıtı haline gelmesidir. Aylarca analiz dokümanları hazırlanmış olabilir. Çok ayrıntılı proje planları ve sunumlar oluşturulabilir.

Fakat müşterinin kullanabildiği çalışan bir ürün yoksa henüz varsayımlarımızın doğru olup olmadığını öğrenemeyiz.

Bu değer bu nedenle odağı:

“Ne kadar şey tarif ettik?”

sorusundan:

“Gerçekte ne çalışıyor ve kullanıcıya ne değer sağlıyor?”

sorusuna taşır.

3. Sözleşme pazarlığından önce müşteriyle iş birliği

Sözleşmelerin olmadığı bir iş dünyası gerçekçi değildir. Agile Manifesto'nun söylediği de bu değildir. Sorun, müşteri ile ilişkinin yalnızca başlangıçta üzerinde anlaşılmış gereksinimlerin teslim edilmesine indirgenmesidir.

Ürün geliştirme sırasında yeni bilgiler ortaya çıkar. Müşterinin ihtiyaçları değişebilir. Başlangıçta önemli görülen bir özellik değerini kaybedebilir veya ekip beklenmedik bir fırsat keşfedebilir. Bu durumda “sözleşmede ne yazıyorsa onu teslim etmek” ile “müşterinin gerçekten ihtiyaç duyduğu değeri üretmek” birbirinden ayrılabilir.

Çevik yaklaşım müşteriyi sürecin sonunda ürünü kabul eden kişi olarak değil, ürünün doğru yönde gelişmesine yardımcı olan aktif bir paydaş olarak görür.

4. Bir plana bağlı kalmaktan önce değişime yanıt vermek

Planlama Agile'ın düşmanı değildir. Aksine iyi çevik takımlar sürekli planlama yapar. Fark şudur: Planı gerçekle karıştırmazlar. Bir plan, elimizdeki mevcut bilgiye göre oluşturduğumuz en iyi tahmindir. Yeni bilgi geldiğinde planın da değişebilmesi gerekir.

Bu yüzden çevik organizasyonlarda planlama bir defalık faaliyet değil, sürekli bir süreçtir. Hedef mümkün olduğunca eksiksiz bir plan hazırlamak değil, yönü kaybetmeden yeni bilgiye adapte olabilmektir.

Agile Manifesto’nun 12 İlkesi

Dört değer manifestonun yönünü gösterirken 12 ilke bu değerlerin çalışma hayatına nasıl yansıyabileceğini daha somut hale getirir.

Orijinal 12 ilkeyi günümüz çalışma hayatındaki karşılığıyla şöyle düşünebiliriz:

İlke	Pratikte ne anlama gelir?
1. Erken ve sürekli değer teslimi	Müşterinin aylarca sonuç beklemesi yerine küçük ama değerli parçaları erkenden sunmak
2. Değişen gereksinimleri karşılamak	Yeni bilgiyi problem olarak değil, daha iyi ürün geliştirmek için fırsat olarak görmek
3. Çalışan ürünü sık teslim etmek	Büyük ve riskli sürümler yerine daha küçük geri bildirim döngüleri oluşturmak
4. İş ve teknoloji ekiplerinin birlikte çalışması	Gereksinimlerin bir ekipten diğerine aktarılması yerine ortak problem çözmek
5. Motive bireyler etrafında takım kurmak	Mikro yönetim yerine gerekli ortamı sağlayıp takıma güvenmek
6. Doğrudan iletişimi önemsemek	Karmaşık konularda iletişim kaybını azaltacak zengin etkileşim yolları kullanmak
7. Çalışan ürünle ilerlemeyi görmek	Aktiviteyi değil, gerçekten ortaya çıkan değeri esas almak
8. Sürdürülebilir çalışma temposu	Kısa süreli kahramanlıklar yerine uzun vadede sürdürülebilecek sistemler kurmak
9. Teknik mükemmelliğe önem vermek	Kaliteyi çevikliğin karşıtı değil, değişebilmenin ön koşulu olarak görmek
10. Basitlik	Gereksiz işi azaltmak ve yapılmayan iş miktarını artırmak
11. Kendi kendini yöneten takımlar	Çözümü işi yapan insanların şekillendirebilmesine alan açmak
12. Düzenli olarak düşünmek ve uyarlamak	Çalışma biçimini periyodik olarak sorgulamak ve iyileştirmek

Bu ilkelerin ortak noktası aslında oldukça nettir:

Kısa geri bildirim döngüleri oluştur, gerçek sonuçlardan öğren ve yeni bilgi geldiğinde adapte ol.

Agile ve Waterfall Arasındaki Fark

Agile ile Waterfall karşılaştırması zaman zaman “biri iyi, diğeri kötü” gibi sunuluyor. Bu oldukça yüzeysel bir ayrım. Temel fark, belirsizliğin nasıl yönetildiğidir.

Waterfall / Tahmine Dayalı Yaklaşım	Agile / Adaptif Yaklaşım
Gereksinimleri mümkün olduğunca baştan netleştirmeye çalışır	Gereksinimlerin zaman içinde değişebileceğini kabul eder
Planın uygulanmasına daha fazla odaklanır	Öğrenme sonucunda planın değişebilmesini destekler
Teslimatlar daha büyük aşamalarda gerçekleşebilir	Küçük ve sık teslimatlar tercih edilir
Değişiklik maliyet olarak görülebilir	Değişiklik yeni bilginin doğal sonucu olarak değerlendirilir
Başarı plana uyumla ilişkilendirilebilir	Başarı ortaya çıkan değer ve sonuçlarla ilişkilendirilir

Bu durum Waterfall yaklaşımının hiçbir zaman kullanılamayacağı anlamına gelmez.

Belirsizliğin düşük, yapılacak işin iyi anlaşıldığı ve değişim ihtiyacının sınırlı olduğu problemlerde daha öngörülebilir yaklaşımlar anlamlı olabilir. Belirsizlik ve değişim arttıkça ise kısa öğrenme döngülerinin değeri artar.

Bu nedenle doğru soru çoğu zaman:

“Agile mı Waterfall mı daha iyi?”

değil,

“Karşı karşıya olduğumuz problem ne kadar belirsiz ve ne kadar hızlı öğrenmemiz gerekiyor?”

olmalıdır.

Agile ile Scrum aynı şey midir?

Hayır.

Agile ve Scrum günlük kullanımda sık sık birbirinin yerine kullanılsa da aynı kavram değildir.

Agile, belirli değerler ve prensipler etrafında şekillenen daha geniş bir çalışma ve düşünme yaklaşımıdır.

Scrum ise karmaşık problemlerde değer üretmeye yardımcı olmak için tasarlanmış belirli bir framework'tür. Güncel resmi Scrum Guide da Scrum'ı “hafif bir framework” olarak tanımlar.

Bu nedenle:

Agile → daha geniş değer ve prensipler

Scrum → bu ortamda kullanılabilecek framework'lerden biri

şeklinde düşünmek daha doğru olur.

Scrum kullanmak bir organizasyonu otomatik olarak Agile yapmaz. Sprint yapmak, Daily Scrum düzenlemek, Product Owner ve Scrum Master ünvanlarını kullanmak mümkündür; ancak kararların tamamı hâlâ yukarıdan veriliyor, müşteri geri bildirimi aylar sonra alınıyor ve değişiklik her seferinde sorun olarak görülüyorsa organizasyon çevik değerlerden oldukça uzak olabilir.

Aynı şekilde Agile olmak için mutlaka Scrum kullanmak gerekmez. Kanban, Extreme Programming veya farklı çalışma modelleri de çevik prensiplerle uyumlu olabilir.

Agile Manifesto Günümüzde Hâlâ Geçerli Mi?

Agile Manifesto 2001 yılında yazıldı. O tarihten bu yana yazılım geliştirme araçları, organizasyon yapıları ve teknoloji dünyası büyük ölçüde değişti. Cloud, DevOps, platform engineering ve yapay zekâ destekli yazılım geliştirme gibi yaklaşımlar ekiplerin çalışma biçimini dönüştürdü.

Buna rağmen manifestonun çözmeye çalıştığı temel problem ortadan kalkmış değil:

Belirsizlik altında nasıl daha doğru ürünler geliştirir, daha hızlı öğrenir ve değişime daha iyi yanıt veririz?

Bugün kodun bir bölümü yapay zekâ tarafından üretilebilir, dokümantasyon çok daha hızlı hazırlanabilir ve prototipler geçmişe kıyasla çok daha kısa sürede geliştirilebilir. Ancak teknoloji hızlandıkça doğru problemi seçmenin önemi azalmaz; tam tersine artar.

Bir ekip yanlış ihtiyacı çok hızlı biçimde geliştirebilir. Çok sayıda özellik teslim edip müşteriye gerçek bir değer yaratmayabilir. Yeni araçlar üretim hızını artırırken, hangi işi neden yaptığımızı sorgulama ihtiyacını ortadan kaldırmaz.

Bu nedenle Agile Manifesto'nun müşteriyle iş birliği, çalışan ürün üzerinden öğrenme, değişime yanıt verme, teknik kalite, basitlik ve sürekli iyileştirme gibi temel prensipleri günümüz ürün ve yazılım geliştirme ortamında hâlâ güçlü bir karşılık buluyor.

Asıl değişen, bu prensipleri hayata geçirmek için kullandığımız araçlar ve pratiklerdir.

Scrum, Kanban, DevOps, sürekli teslimat veya yapay zekâ destekli geliştirme zaman içinde değişebilir. Ancak temel soru aynı kalır:

Doğru şeyi yapıyor muyuz ve yeni bir şey öğrendiğimizde yön değiştirebiliyor muyuz?

Agile Manifesto'nun kalıcı değeri de burada yatıyor.

Agile ritüellerden ibaret değildir

Kurumsal çevik dönüşümlerde karşılaştığımız en önemli sorunlardan biri, Agile'ın zaman içinde prensiplerden çok ritüeller üzerinden tarif edilmeye başlamasıdır.

• Takımlar Sprint yapar.

• Daily Scrum düzenler.

• Backlog tutar.

• Retrospective gerçekleştirir.

• Jira kullanır.

Ancak bunların hiçbiri tek başına organizasyonun daha çevik hale geldiğini göstermez.

Bir takım iki haftalık Sprintlerle çalışıyor fakat üretime üç ayda bir çıkıyorsa geri bildirim döngüsü gerçekten kısalmış mıdır?

Product Owner varsa ancak bütün ürün kararları yönetim tarafından veriliyorsa takım gerçekten yetkilendirilmiş midir? Retrospective her Sprint sonunda yapılıyor ancak aynı problemler aylar boyunca devam ediyorsa gerçekten adaptasyon gerçekleşiyor mudur?

Bu yüzden Sharpware olarak çevik dönüşümde yalnızca framework uygulamalarına değil; organizasyonel karar mekanizmalarına, mühendislik pratiklerine, teknik kaliteye, liderlik yaklaşımına ve değer üretme sisteminin bütününe bakıyoruz.

Agile Manifesto'yu bugün hâlâ değerli yapan şey de burada yatıyor. Manifesto bize hangi toplantıyı yapacağımızı söylemez. Bize karar verirken neyi daha değerli görmemiz gerektiğini hatırlatır.

Çevikliği ritüellerle değil, sonuçlarla ölçmek gerekir

Bir organizasyonun Daily Scrum yapması, iki haftalık Sprintlerle çalışması veya Jira kullanması tek başına ne kadar çevik olduğunu göstermez. Daha anlamlı olan, çalışma biçiminin müşteriye sunulan değer, yazılım kalitesi, teslimat hızı ve takım sağlığı üzerinde nasıl bir sonuç yarattığıdır.

Örneğin bir yazılım ekibine yalnızca “Scrum kullanıyor musunuz?” diye sormak yerine şu sorular çok daha fazla şey anlatabilir:

• Bir fikrin müşteriye ulaşması ne kadar sürüyor?

• Yapılan değişikliklerin ne kadarı probleme veya geri dönüşe neden oluyor?

• Takım sürdürülebilir bir tempoda çalışabiliyor mu?

• Teknik borç ürün geliştirme hızını ne ölçüde etkiliyor?

• Üretilen yazılım gerçekten müşteri için değer yaratıyor mu?

  
  

Bu nedenle çeviklik değerlendirmesinin yalnızca süreç uyumuna değil, somut sonuçlara ve ölçülebilir göstergelere dayanması gerekir.

Sharpware olarak yıllar içinde farklı yazılım ekipleriyle yaptığımız çalışmalarda benzer bir tabloyla sık karşılaştık: Takımlar “Agile çalışıyoruz” veya “Scrum yapıyoruz” diyebiliyor, ancak teslimat performansı, kalite, takım sağlığı ve müşteri değeri gibi alanlarda ne durumda olduklarını somut verilerle göstermek zorlaşıyor.

Bu ihtiyacı sistematik hale getirmek için SAMF – Sharpware Agility Maturity Framework yaklaşımını geliştirdik.

SAMF, DORA ve SPACE gibi modern yazılım geliştirme ölçüm yaklaşımlarından yararlanarak ekipleri beş temel boyutta değerlendirir:

• Doğru ürünü geliştirme

• Teknik kalite ve teknik borç

• Teslimat performansı

• Takım sağlığı ve akış

• Müşteriye ulaştırılan değer

  
  

Buradaki amaç takıma yalnızca tek bir “Agile skoru” vermek değil; hangi alanlarda güçlü olduğunu, nerelerde darboğaz yaşadığını ve gelişim için hangi aksiyonların öncelikli olduğunu görünür hale getirmektir.

Çeviklik, yapılan ritüellerin sayısıyla değil; takımın ne kadar hızlı öğrenebildiği, ne kadar sağlıklı teslimat yapabildiği ve müşteriye ne ölçüde değer ulaştırabildiğiyle anlaşılır.

Takımınızın çeviklik seviyesini ölçmek için ücretsiz SAMF değerlendirmesini deneyebilirsiniz: https://samf.sharpware.co/

Agile Bir Süreç Değil, Karar Verme Biçimidir

Agile Manifesto'nun üzerinden 25 yıl geçti.

Bu sürede yazılım geliştirme araçları, organizasyon yapıları ve teknoloji dünyası önemli ölçüde değişti. Cloud, DevOps, platform engineering ve bugün üretken yapay zekâ yazılım geliştirme biçimini dönüştürdü.

Ancak temel problem aynı kaldı:

Geleceği tam olarak bilemediğimiz bir ortamda doğru ürünü nasıl geliştiririz? Agile Manifesto'nun 4 değeri ve 12 ilkesi bu soruya hazır bir süreç tarifi vermiyor.

Bunun yerine bize bir yön gösteriyor:

• İnsanların birlikte çalışmasını güçlendir.

• Çalışan ürün üzerinden öğren.

• Müşteriyi sürecin içine dahil et.

• Yeni bilgi geldiğinde değişebil.

• Teknik kaliteyi koru.

• Gereksiz işi azalt.

• Düzenli olarak dur, düşün ve çalışma biçimini iyileştir.

Bu nedenle Agile olmanın en önemli göstergesi kullandığınız framework veya yaptığınız toplantı sayısı değil, organizasyonunuzun ne kadar hızlı öğrenip adapte olabildiğidir.

Sharpware olarak Agile dönüşüm çalışmalarımızda Scrum, Kanban veya başka bir framework'ü amaç olarak değil, organizasyonun daha hızlı öğrenmesine ve sürekli değer üretmesine yardımcı olabilecek araçlar olarak ele alıyoruz.

Sık Sorulan Sorular

Agile Manifesto kimler tarafından yazıldı?

Agile Manifesto, 2001 yılında farklı yazılım geliştirme yaklaşımlarından gelen 17 yazılım profesyoneli tarafından oluşturuldu. Katılımcılar arasında Scrum, Extreme Programming, Crystal ve benzeri çevik yaklaşımların öncülerinden isimler yer alıyordu.

Agile Manifesto'nun 12 ilkesi zorunlu kurallar mıdır?

Hayır. Agile Manifesto'nun 12 ilkesi uygulanması gereken katı prosedürler veya bir denetim listesi değildir. Takımların karar verirken değer üretme, geri bildirim, iş birliği, teknik kalite ve değişime uyum gibi konularda nasıl düşünmeleri gerektiğine ilişkin yol gösterici prensiplerdir.

Agile Manifesto yalnızca yazılım ekipleri için mi kullanılabilir?

Manifesto başlangıçta yazılım geliştirme için hazırlanmıştır. Bununla birlikte müşteriyle iş birliği, kısa geri bildirim döngüleri, değişime uyum ve sürekli iyileştirme gibi prensipler ürün geliştirme ve farklı karmaşık çalışma ortamlarında da uygulanabilir. Ancak başka alanlara taşınırken yalnızca Scrum etkinliklerini veya Agile araçlarını kopyalamak yerine prensiplerin arkasındaki ihtiyacı anlamak önemlidir.

Bir şirketin Agile Manifesto'ya uygun çalıştığı nasıl anlaşılır?

Bunun için kullanılan framework'ten çok çalışma biçimine bakmak gerekir. Ekiplerin müşteriden ne kadar hızlı geri bildirim alabildiği, yeni bilgi geldiğinde planlarını değiştirebilip değiştiremediği, çalışan ürünün ne sıklıkla ortaya çıktığı ve teknik kalite ile sürekli iyileştirmenin gerçekten desteklenip desteklenmediği daha anlamlı göstergelerdir.