Agile (çevik) yöntem, yazılım geliştirmede kullanılan proje yönetimine özel bir yaklaşımdır. Bu yöntem ekiplerin yazılım geliştirme süreçlerinin öngörülemezliğine cevap vermesine yardımcı olur. Genellikle sprint olarak bilinen artımlı, yinelemeli iş dizilerini kullanır.
Agile sürecine ve yöntemine genel bakış:
Aşağıda, yazılım tasarımı ve geliştirmeye başlayanlar veya başlamak isteyenler için agile yönteme genel bir bakış ve bunun yanı sıra agile yöntem hakkında basit bir tanım bulacaksınız. Metodolojiyi kendi kurumsal ajansınıza veya web tasarım şirketinize entegre edebilirsiniz.
Agile metodunun tanımı:
Sprint, bir projenin belirli bir aşaması için ayrılan süredir. Sprintlerin süresi dolduğunda proje tamamlanmış sayılır. Ekip üyeleri arasında, gelişimin tatmin edici olup olmadığı konusunda anlaşmazlıklar olabilir; ancak, projenin belirli bir aşamasında bu konuda daha fazla çalışma yapılmayacaktır. Projenin kalan aşamaları, kendi zaman dilimleri içinde geliştirilmeye devam edecektir. Agile metodunun genel prensipleri: • Müşteriyi memnun etmek ve sürekli yazılım geliştirmek önemlidir. • Müşterinin rekabet avantajı için değişen gereksinimler benimsenmelidir. • Sık sık çalışan yazılımlar sunmaya odaklanılmalıdır. Teslimat, mümkün olan en kısa sürede yapılmalıdır. • Geliştiriciler ve iş adamları tüm proje boyunca birlikte çalışmalıdır. • Projeler motive olmuş insanlarla devam etmelidir. Onlara uygun ortam ve ihtiyaç duydukları destek sağlanmalıdır. İşlerini yapmak için güvende olmalıdırlar. • Yüz yüze iletişim, bir takıma bilgi aktarmanın en iyi yoludur. • Çalışan yazılım, ilerlemenin birincil ölçümüdür. • Çevik süreçler sürdürülebilir kalkınmayı teşvik ederler. Sponsorlar, geliştiriciler ve kullanıcılar belirsiz ve sürekli bir tempoyu koruyabilmelidir. • Teknik mükemmellik ve iyi tasarıma sürekli dikkat etmek çevikliği artıracaktır. • Sadelik, yapılmayan işi en üst düzeye çıkarma sanatı olarak kabul edilir ve esastır. • Kendi kendine organize ekipler genellikle en iyi tasarımları oluşturur. • Düzenli aralıklarla, takımın nasıl daha etkili olacağına dair düşünülmeli ve davranışlar buna göre düzenlemelidir.
Agile Manifesto — 4 Temel Değer:
İş süreçleri ve araçlardan ziyade bireyler ve bireyler arasındaki etkileşim değerlidir.
Kapsamlı bir dokümantasyon sürecinden ziyade, çalışan bir yazılım ortaya koymak daha önemlidir.
Müşteri ile işbirliği yapmak, sözleşme görüşmelerinden daha önemlidir.
Değişime cevap vermek, mevcut planı izlemekten daha önemlidir.
Agile metodolojinin kavramlarını, popüler ve trend haline gelmiş sözcükleri ve aktivitelerini ezberlemek yerine daha derinini keşfetmek! Tam düşünürken zihnim Richard Feynman’ın şu çok sevdiğim sözünü kulaklarıma fısıldıyor: ‘’Bir şeyin sadece adını bilmek, -bilmek- değildir’’. Hadi gelin bugün hep birlikte çok fazla irdelenmeyen “Agile”ın ne olmadığına birlikte bakalım.
En temel yapı içinden başlayacak olursak, bir organizasyonda “Agile” sadece IT ekiplerinin uygulayıp, kullanacağı bir metot, bir iş yapış şekli değildir! XP, kanban, scrum gibi yaklaşımları sadece IT ekiplerine uyarlamak dönüşüm zincirinin parçalarını eksik bırakacaktır.
Hızlı ürün çıkabilme, pazardaki fırsatları yakalayabilme, daha yalın, daha az maliyetle daha çok üretebilme için Agile yapmak değil, Agile olmak gerekir! Agile olmak ise; yakalanmak istenen fırsat ya da çözülecek bir problem için talebin doğması ile üretilen her bir parçasının kod taşımasına kadar uzanan tüm döngüsünde “Business Agility” kavramının anlaşılmasıyla gerçeğe ulaşır.
Başarılı bir Agile metodolojisi kültür dönüşümü ile desteklenmiş olmasının yanı sıra, akışta olma halinden yapma haline geçmesiyle gerçek çevikliğe ulaşılabileceğini mümkün kılar. Bu çevik yaklaşımın tarihçesine bakıldığında IT’nin çok ötesinde olduğu, bugün birçok firmanın inovasyon süreçlerini iyileştirmede uçtan uca entegre kullandığı yadsınamaz.
Agile bir işi sadece hızlı yapmak değildir! Organizasyonlarda algılanan bir diğer büyük yanlış ise agile’ın acele iş yapma üzerine kurulu bir kavram olduğu. Çeviklik, yalınlık gibi kavramlar sadece hız ile ölçümlenebilecek değerler değillerdir. Dökümantasyonun daha sade hale gelmesi, planlamanın daha sık ve kısa süreli sprintler halinde yapılıyor olması hızı artırırken, kaliteli iş üretmekten vazgeçmiyor olmak gerekir.
Aksi halde metodoloji bugün yaptığını yarın bozan, yarın yapacağınızı da nasıl olsa tekrar bozarım mantığıyla, birçok ihtiyaca kısıtlı ve geçici çözüm üreten bir döngüyü doğurur. Bu yanlış algı belki de büyük resmi gözden kaçırmanızı, fırsatın büyük dilimi yerine ufacık bi ısırığıyla yetinmenizi, ya da problemlere ancak geçici çözümler ile tampon yapmanızı sağlar. Agile bundan çok daha ötesini ifade etmenin yanı sıra aynı hedefe hep birlikte koşan takımların doğru işlere çeviklikle adapte olup, hızlı üretme kabiliyetini geliştirmesiyle evrilir.
Agile iş analiz aktivitesinin yapılmadığı bir yaklaşım değildir! Belki de bu nokta bu metodoloji için yanlış yorumlanabilecek diğer bir parçadır. Yazılım yaşam döngüsünde artık çeyreklik, 6 aylık, yıllık planların çok da fazla işe yaramadığı; çıkarılan tasarım ve kapsamların proje süresince bile hızla değiştiği eskilerde kalmış söylemler oldular bile. Bunlardan vazgeçiyor olmak iş analiz aktivitelerinden vazgeçilmesini kesinlikle doğurmaz. Şirketleri vizyonlarına ulaştıracak işlerin minimum zamanda üretilmesi için organizasyonda iş kollarından gelecek PBI (Product Backlog Item)’ların hazırlanması, önceliklendirilmesi, önemli iş analizi aktiviteleridir.
Projelerin “Epic – Feature – PBI (User Story)” formatında kırılması, kabul kriterleri noktasında sağlanacak mutabakatlar, yapılan tasarımlar, tamamlanacak her bir user story’nin tüm sisteme etkilerinin detaylandırılması, en temel iş analizi aktiviteleri olmaya devam edecektir. Bu yapılardan uzaklaşıldığı takdirde; sadece çalışan kod parçacığı üzerinden ürün/süreç detaylarına ulaşmak, kurumsal hafızanın yok olması ve denetimsel birçok sıkıntıyı beraberinde getireceği gerçeğinden kaçılamaz.
Agile yaklaşımda “işleri kırmak” sadece küçük parçalara ayırmak demek değildir! Çoğumuz okuduğumuz her kaynakta, incelediğimiz her uygulamada agile oluş şeklinde en fazla değişikliğin büyük, detaylı, kompleks kapsamlardan vazgeçmek ve uzun soluklu geliştirme süreçleri yerine çok kısa sürede parça parça üretime geçebilmek olduğunu anlıyoruz. Burada yanlışa düşülmemesi gereken en kritik nokta sprintler içerisinde ufak waterfall SDLC döngüleriyle proje yapmaya devam etmek olacaktır. Sprint içerisine alınan her item’ın müşteriler/kullanıcılar için anlam ifade eden, tamamlandığı noktada mutlaka + değer sağlayacak olması kaçınılmaz gerçekliktir.
Burada da en büyük sorumluluk Product Owner rolüne düşmektedir. Sprint’e alınacak her bir PBI, MVP dediğimiz kavramı desteklemek zorundadır. Yani PBI’lar, müşterilerin zihinlerinde canlandırdığı ürün/hizmetler için şirket stratejileri ile aynı doğrultuda olacak şekilde çalışabilir en temel özellikleri içeren minimum parçalar olmalıdır.
Burada işi ufaltmak derken sadece belirli zamanda bir kısmını tamamlamak değil, anlamlı küçük parçalarını sprint içerisine alabilecek kadar kırmak gerçek çevikliktir. Böylece organizasyonları doğru işi üretmede bir adım daha öne çıkaracaktır. Her ne kadar karmaşık, birbirine bağımlı birçok paydaştan oluşan, regülasyonu yüksek, maliyeti fazla yazılım projelerinde bu iş parçalama güç olsa da, gerçek bir agile oluşumunda bu aktivite için gereken eforu harcamak boşa geçen bir zaman olarak ifade edilemez.
Agile yaklaşımda aktiviteleri bireysel bakış açısıyla yürütmek mümkün değildir! Agile tarihine de bakıldığında bu çerçevedeki scrum, kanban, lean gibi metotların tamamı kendi içlerinde takımsal oyunu barındırır. Örneğin Scrum’ı örnek alacak olursak, yapılan daily toplantılarında o gün hangi işlerle uğraşıldığının telaffuz edilmesinin yanı sıra bakış açısı sprint’e bütünsel yaklaşabilmek, takımca o günü en faydalı planlayıp akışa geçmek gerekliliğidir.
Yani takım bakış açısı korunur. Sprint planlamada verilen commitment çerçevesinde; sprint sonunda ortaya çıkan “velocity”, “innovation rate” gibi elde edilen çıktılar tüm takım tarafından değerlendirilir. “Retrospective” süreçleri bireysel tartışmalara dönmemeli, takımca sprintin başarısı / başarısızlığı değerlendirilmelidir. En nihayetinde de Agile oluşta tüm aktiviteler her zaman takım çalışmasına dayanır. Hedefe birlikte koşabilen, yetkin kişilerden kurulmuş takımlar çevikliği çok daha yüksek noktalara taşıyabilenler olacaklardır.
Tüm bu “… ne değildir” penceresinden derinlere baktığımizda gördüklerimizi içselleştirebilirsek belki de bu sade, daha yalın, daha değerli işi kısa sürede üretme oluşunu yani AGILE’ı daha iyi anlayabiliriz. Metodolojinin önerdiği rolleri öylesine dağıtmak, aktivitelerin hakkını vermeden gerçekleştirmek, iş kırmayı tek cümle ile tarif etmek olarak algılarsak; çevikliğin yanı sıra üretim kalitesinde azalış, verimsiz süreçler, motivasyonu düşük çalışanlar ve mutsuz müşteriler elde ettiğimiz insightlar olacaktır.
Yazılım dünyasının içinde bulunduğu dönüşümün hakkını vermek, yalınlık ve sadelik çatısı altında üretim hızını arttırmak, değer yaratmak için Agile’ın altında yatan felsefe anlaşılmalı ve sürekli öğrenme yöntemiyle organizasyonların kendi kültürleriyle uyumlu evrilmiş takımları oluşturması faydalıdır. Transformasyon sürecinde şirketler kendilerini Agile rüzgarına bırakmamalı, aksine rüzgarı tam arkalarına alarak (Agile oluş) ilerlemeleri gerçekliğinde yaşamalıdırlar.
Agile metodunu kullanmanın yararları:
Agile metodu, önde gelen yazılım uzmanlarının gerçek yaşam projelerindeki deneyimlerinden ortaya çıkmıştır. Bu nedenle, geleneksel kalkınmanın zorlukları ve sınırlamaları ortadan kaldırılmıştır. Daha sonra agile metodu, endüstri tarafından proje geliştirmeye daha iyi bir çözüm olarak kabul edilmiştir. Hemen hemen her yazılım geliştirici, agile metodunu bir biçimde kullanmıştır. Bu yöntem yardımcı ekipler için hafif bir çerçeve sunar. Hızlı teslimat üzerinde çalışmalarına ve odaklanmalarına yardımcı olur. Bu odaklanma yetenekli kuruluşlara yazılım geliştirme ile ilgili genel riskleri azaltma konusunda yardım sağlar.
Proje üretkenliğini arttırmayı amaçlayan Agile yöntemi ile geliştirilen projeler pazara çok daha hızlı çıkar. Agile nasıl uygulanır, diye baktığımızda proje geliştirme sürecinin aşamalarının her biri için sprint adı verilen belli bir süre ayrıldığını görürüz. Proje sprintlerin süresi dolduğunda bitmiş olur. Agile yöntemi yazılım geliştirmede karşılaşılabilecek genel risklerin azaltılmasını da sağlar. Bu yöntemle yazılım projesi öngörülebilir olur.
Agile metodu, bu değerin geliştirme süreci boyunca optimize edilmesini sağlar. Yinelemeli planlama ve geri bildirim kullanımı, bir müşterinin istenen ihtiyaçlarını yansıtan bir ürünü sürekli olarak düzenleyebilen ekiplerde sonuçlanır. Bir projenin durumunu ölçerek ve değerlendirerek süreç boyunca değişen gereksinimlere kolayca adapte olur. Ölçme ve değerlendirme, her projenin gelişimine doğru ve erken görünürlük sağlar.
Agile metodunun şirketlerin doğru ürünü oluşturmalarına yardımcı olduğu söylenebilir. Yazılı olmadan önce yazılımı pazarlamaya çalışmak yerine, agile metodu, geliştirme sırasında sürümleri optimize etmek için ekipleri yetkilendirir. Bu, ürünün pazarda mümkün olduğunca rekabetçi olmasını sağlar. Kritik pazarın düzeyini korur ve bir ekibin çalışmasının geride kalmamasını sağlar. Bu nedenle agile metodu hem kullanıcılar hem de geliştiriciler için cazip bir seçenektir. Agile metodunun birçok eleştirisi vardır; ancak, bu yöntem müşterilerin memnun olacakları sonuçlar verir.
Bir proje tam olarak müşterinin öngördüğü şekilde ortaya çıkmasa da, üretilmesi gereken sürede teslim edilecektir. Süreç boyunca müşteri ve ekip, müşterinin ihtiyaç duyduğu kaliteyi üretmek için gereksinimleri değiştirir. Müşteriler sonuçlardan memnun kalırlar ve ekip müşterinin ihtiyaçlarını karşılar. Devam eden değişim bazen hem müşteriye hem de takıma, ürün için öngördüğünden daha fazlasını verebilir. Agile Metodu, gerçekten yazılım geliştirmeye katılan herkes için kazandıran bir çözümdür.
Agile metodu ile ilgili eleştiriler:
• Kullanıcı merkezli yerine geliştirici merkezlidir.
• Agile, gereksinim alma ve kod geliştirme süreçlerine odaklanır ve ürün tasarımına odaklanmaz.
• Agile metodolojiler büyük kuruluşlarda ve belirli türdeki projelerde yetersiz olabilir.
Scrum nedir?
Scrum yaklaşımı en popüler Agile yöntemidir. Büyük ve karışık yazılım süreçlerinin yönetilmesinde tercih edilen Scrum bütünü parçalamaya ve tekrara dayalı bir yöntemdir.
Peki bu Scrum yönteminin faydaları nelerdir, şu şekilde sıralayabiliriz:
Projenin açık ve net olması hem zaman kazandırır hem de projenin başarılı sonuçlanmasını sağlar.
Projenin anlaşılabilir ve yönetilebilir parçalara ayrılması olası sorunları hızlı bir şekilde tespit etmekte ve düzeltmekte zaman kazandırır.
Bütün ekibin, projenin tüm akışından haberdar olması takım içindeki iletişimi artırır.
Müşteri ile geliştiriciler arasında güven oluşur ve böylelikle projenin başarılı sonuçlanması beklenir.
Scrum yönteminin doğru ve anlaşılır bir şekilde uygulanmasını sağlayan kişiye Scrum Master denir. Bu kişi sorumluklarını takımın Scrum yöntemine ve pratiğine uyulmasına sağlayarak gerçekleştirir.
Ayrıca takımdaki kişilerin karşılaştıkları sorunların giderilmesine yardımcı ve destek olan kişidir.
Eğer sizler de projelerinizin sorunsuz ve hızlı bir şekilde teslimatının olmasını istiyorsanız; değişime açık ve müşteri ile birlikte çalışmayı benimseyerek Agile kültürünü şirketinize kazandırmaya başlayabilirsiniz.
İçerik: Wikipedia, mshowto, webtures, toptalent, ba-works sitelerinden derlenmiştir.