Ürün Geliştirmede Agile Yaklaşımlar

Tolga Demirli
5 min readNov 8, 2023

--

Başarılı bir ürün elde etmek için proje yönetimi geliştirme aşamasının kendisi kadar kritik öneme sahiptir. Başarılı sonuçlar elde etmek için projelerin doğru planlanması ve yönetilmesi gerekmektedir.

Ürün fikrinin oluşmasından, geliştirme, test ve dağıtım aşamasına kadar tüm süreçlerin mevcut kaynaklar ve kısıtlar göz önüne alınarak değerlendirilmesi gerekmektedir.

Microsoft Bing — DALL-E 3 kullanılarak oluşturulmuştur.

Geleneksel Proje Yönetim Anlayışı

Proje yönetiminde geleneksel anlayış olarak da bilinen Waterfall yaklaşımı yazılım geliştirme alanında uzun zamandır yaygın olarak kullanılmaktadır. Bu yaklaşım aslında ilk defa inşaat ve mimari alanda kullanılmıştır. Fiziki ürünlerin geliştirilmesinde başarılı sonuçlar veren bu süreç mühendisliği 1970’lerde Dr. Winston W. Royce tarafından yazılan “Managing the Development of Large Software Systems” makalesi ile yazılım geliştirme alanına uyarlanmış ve kullanılmaya başlanmıştır.

Projenin sıralı belli aşamalara bölündüğü, bir aşamanın tamamlanmadan diğer aşamaya geçilmeyen bu yaklaşım öngörü temellidir. Kapsam, zaman ve bütçe projenin başında belirlenmekte ve mümkün mertebe değişiklik yapılmamaktadır.

Her bir detayın önceden belirlendiği bu yaklaşım ile gereksinimler ve proje kapsamı çok net bir şekilde tanımlanmaktadır. Her aşamada yapılacak iş ve sorumlu kişiler belli olduğu için projeler sorunsuz ilerlemektedir. Aynı şekilde proje takibi de kolay bir şekilde yapılabilmektedir.

Bu yaklaşımın olumlu yanları olduğu kadar dezavantajları da vardır. Proje ilerledikçe değişim ihtiyacı ortaya çıktığı zaman bunu yönetmek çok kolay değildir. Bir önceki aşamaya geri dönmek ve değişiklik yapmak süreç ilerledikçe daha maliyetli olmaktadır. Bu yüzden değişimler bir sonraki fazlara, projelere bırakılmaktadır. İhtiyaçların, gereksinimlerin sonraki aşamalara bırakılması beraberinde tamamlanamayan, bitmeyen projeleri de ortaya çıkarmaktadır. Ayrıca bu yaklaşımda kullanıcı gereksinimleri alındıktan sonra proje ekibinin görünürlüğünün azalması, analiz, geliştirme, test aşamaları için kendi kabuğuna çekilmesi müşteri tarafında kendileri ile ilgilenilmediği yönünde bir düşünce uyandırmaktadır. Buna ek olarak sonuçların, çıktıların da uzun süre görünür olmaması müşteri memnuniyetsizliğini beraberinde getirmektedir.

Değişime gerek olmayan, sınırların belli olduğu, öngörülebilir projelerde Waterfall yaklaşımı ile başarılı sonuçlar elde etmek mümkündür.

Günümüzün karmaşık ve hızla değişen iş dünyasında bu yaklaşım maalesef her zaman başarılı sonuçlar vermemektedir. Teknolojinin de hızla gelişmesi ile birlikte ihtiyaçların çok hızlı değişebildiği bu günlerde değişim yaratabilmek ve değişimlere ayak uydurabilmek çok önemli hale gelmiştir. VUCA dönemi olarak da ifade edilen, değişkenliğin, belirsizliğin, karmaşıklığın bu kadar ön planda olduğu günümüzde öngörülebilir yerine adapte olabilen anlayışlar, yaklaşımlar daha değerlidir.

Bu süreçte hızlı olabilen, piyasaya ilk çıkarak ihtiyacı ilk karşılayan yapılar rakiplerinin önüne geçmektedir.

Geçmişte ihtiyaç olan, gereklilik olarak belirlenen konular bugün ihtiyaç olmaktan çıkabilmekte veya önceliğini kaybedebilmektedir. Bu sorunlar özellikle yazılım geliştirme alanında çok daha fazla hissedilmektedir.

Agile Proje Yönetim Anlayışı

Yazılım sektörü başta olmak üzere 1980’lerden sonra oyun değişmeye ve daha esnek, müşteri memnuniyetine daha çok önem veren pratikler, uygulamalar şirketler tarafından kullanılmaya başlamıştır. Özellikle Japonya ve Amerika’da faaliyet yürüten bazı önemli şirketlerin gerçekleştirdiği pratikler “The New New Product Game” makalesinde paylaşılmıştır. Birbirinden habersiz, benzer anlayış çerçevesinde pratikler uygulayan bu kişiler yazılım geliştirme alanında yaşanan sorunları çözmek ve süreçleri iyileştirmek için 2001 yılında Utah Snowbird’te bir araya gelmiştir. Yapılan uzun toplantılar ve değerlendirmeler sonucunda yazılım geliştirme süreçlerinde geleneksel yaklaşım yerine daha adapte olabilen bir anlayışın benimsenmesi noktasında fikir birliğine varılmış ve “Agile Manifesto” hazırlanmıştır. Hazırlanan bu bildiride yazılım geliştirme süreçlerinde ön plana çıkması gereken 4 değer ve bu değerler altında benimsenmesi gereken 12 temel ilke belirlenmiştir. Agile manifestoda bu durum aşağıdaki gibi ifade edilmiştir.

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ı Dokümantasyondan ziyade Çalışan Yazılıma

Sözleşme Pazarlıklarından ziyade Müşteri ile İş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.

Agile bir metodoloji veya sınırları belirlenmiş bir çerçeve değildir. Belli değer ve ilkeleri ön planda tutan bir yaklaşımdır. Bu yaklaşım altında Scrum, Kanban, XP gibi birçok farklı teknik, çerçeve kullanılmaktadır. Agile yaklaşımı, tüm bu uygulamaları koruyan bir şemsiye veya tüm bu uygulamalara yol gösteren bir deniz feneri olarak düşünülebilir. Ahmed Sidky tarafından hazırlanan aşağıdaki görsel durumu çok güzel özetlemektedir.

Görsel Ahmed Sidky, ICAgile ve Riot Games tarafından hazırlanmıştır.

Bu noktada her bir Agile değerinin anlaşılması, benimsenmesi önemlidir.

Bireyler ve Etkileşimler

Ürün geliştirme alanında insan faktörü her zaman ön planda olmalıdır. Geliştirilen ürünü bireylerin kullanacağı, bireylerin ihtiyaçlarının karşılanması gerektiği unutulmamalıdır. Belli araçları veya süreçleri takip etmek yerine kullanıcılar ile direkt etkileşime geçmek, sorunun, fırsatın çok daha rahat anlaşılmasını ve hızlı bir şekilde çözülmesini sağlayacaktır.

Çalışan Yazılım

Tüm projede yapılacak işlerin detaylıca aktarıldığı uzun dokümanlardan ziyade çalışan ürün parçacığı çok daha fazla kıymetlidir. Agile yaklaşımda dokümantasyon yine olacaktır. Fakat gerektiği zaman gerektiği kadar dokümantasyon hazırlanmalıdır. Asıl önemli noktanın kullanıcıların ihtiyaçlarını karşılayacak ve değer katacak çözümün, çalışan yazılımın, olduğu unutulmamalıdır.

Müşteri ile İşbirliği

Müşteri ile işbirliği, başarılı ürün geliştirmenin en önemli kriterlerinden biridir. İmzalanan sözleşmeler, karşılıklı görüşmelerden ziyade müşteriler ile ortak gayede olduğumuz anlaşılmalıdır. Ürün geliştirme ekibinin en temel motivasyonunun müşterilerin ihtiyaçlarını en hızlı şekilde karşılamak olduğu müşterilere hissettirilmeli ve ürün geliştirme süreçlerine olabildiğince dahil edilmelidir. Her bir iterasyon sonunda tamamlanan işlerin müşteri ile paylaşıldığı, bir sonraki iterasyonlar için geri bildirim alındığı bu anlayış ürünün arzu edilen noktaya çok daha hızlı ve sağlıklı ulaşmasını sağlayacaktır.

Değişime Karşılık Vermek

Agile yaklaşımın en önemli değerlerden birisi değişimlere karşılık verebilmektir. İhtiyaçların, gerekliliklerin değişebileceğini kabullenmek ve değişimi kucaklamak önemlidir. İhtiyaçların taşa yazılmadığını kabullenmek, gerektiği noktada çevik bir şekilde yeniden konumlanmak gerekmektedir. Yapılacak işlerin küçük, anlamlı alt parçalara bölünerek geliştirilmesi olası değişimlerin maliyetini azaltacaktır.

Bilinmeyenlerin çok olduğu, değişikliklere açık, öngörülemez projelerde Agile yaklaşım ile başarılı sonuçlar elde etmek mümkündür.

Projelerde Doğru Yaklaşımı Seçmek

Son dönemde yaygınlaşan, popüler hale gelen Agile yaklaşımları doğru anlamak önemlidir. Bu süreci Agile > Waterfall olarak yorumlamak hata olacaktır. Öngörülebilir ve adaptif yaklaşımlar, ürün geliştirme alanında çalışan profesyonellere yardımcı olacak, ihtiyaca göre kullanılabilecek yaklaşımlardır. İki yaklaşımın da doğru zamanda doğru projede kullanılması önemlidir. Öngörülebilir bir projede adaptif bir yaklaşım ile ilerlemek her zaman doğru sonucu vermeyecektir. Aynı şekilde adaptif olunması gereken bir projede öngörülebilir yaklaşımlar ile ilerlemek de başarılı bir sonuç vermeyecektir. Bu iki yaklaşımın da bizim için aynı derecede önemli olduğunu görmek, doğru projede doğru yaklaşımı seçmek başarıya ulaşmak için önemli noktalardan birisidir.

Bu noktada projelere başlarken doğru yaklaşımı seçmek adına “Stacey Matrix” olarak adlandırılan teknik kullanılabilir. Temelde “NE” ve “NASIL” sorularına odaklanılan bu sistemde bilinmeyenlerin artması, çoğalması durumunda daha çevik yaklaşımlara gitmek doğru olacaktır. Bilinen noktaların yoğun olduğu durumlarda geleneksel, öngörülebilir yaklaşım seçilmelidir.

Yazarın Defterinden Notlar

Ürün geliştirme alanında çalışan profesyoneller olarak bir projeye başlarken doğru yaklaşımı seçme şansımız olmayabilir. Kurumların benimsediği, tüm projelerde uygulanması gereken yaklaşımlar, süreçler bunu engelleyebilir.

Kurumların bu noktada ya hep ya hiç anlayışı ile ilerlediğini görüyoruz. Değişimlere yanıt vermeyen, geleneksel kurumlar öngörülebilir yaklaşımlar ile ilerlemeye devam etmektedir. Bilinmeyenlerin çok olduğu projelerin tamamlanması ürün ekipleri, müşteriler ve şirketler için stresli ve zor geçmektedir. Yeniliklere açık bazı kurumlar ise dönüşüm çalışmalarına başlamıştır. Fakat Agile > Waterfall yanılgısı ile her isterin belirgin, kapsamın net olduğu, bilinmeyenlerin olmadığı bir projede bile Agile ritüelleri uygulamaya çalışmaktadır. Bu süreçte iki yaklaşımı da kabul eden ve değer veren kurumlar daha başarılı sonuçlar elde edecektir.

Profesyoneller olarak çalıştığımız kurumlardan bağımsız bizler de bu iki yaklaşımı anlamalı ve sahiplenmeliyiz. Çevik olabilmek, değişim yaratabilmek için çalıştığımız kurumun Agile değerleri benimsemesi veya proje yönetiminde bu pratikleri uygulaması gerekmemektedir. Agile dönüşüm sürecinde bulunmayan kurumlarda da içinde bulunduğumuz projelerde, aldığımız görevlerde bu pratikleri hayata geçirebiliriz.

Agile Yapmak ve Agile Olmak arasındaki farkı anlamak bu süreçteki ilk adımımız olacaktır.

Yararlanılan Kaynaklar

  1. Dr. Winston W. Royce, Managing the Development of Large Software Systems
  2. Hirotaka Takeuchi — Ikujiro Nonaka, The New New Product Development Game
  3. Agile Manifesto
  4. Ahmed Sidky, Agile Mindset
  5. Michael Maretzke, When to use waterfall, when agile?

--

--