Agile Çevik Proje Yönetimi Yaklaşımı |Agile Manifesto | Scrum

Agile Çevik Proje Yönetimi Yaklaşımı Nereden Geliyor?

Proje Yöneticileri için, sürekli değişen ve gelişen günümüz iş ortamında çevik kalmak bir ihtiyaç haline gelmiştir. Teknolojinin göz açıp kapanıncaya kadar değişmesi ve piyasaya her geçen gün yeni rakiplerin katılması, firmaların değişime daha hızlı adapte olması zorunluluğunu da beraberinde getirmiştir. Yazılım projelerinden doğan agile çevik proje yönetimi uygulamaları da zamanla evrilerek, günümüzde birçok iş alanında kullanılmaya başlanılmıştır.

PMI tarafından yayınlanan, 2018- Pulse of the Profession raporuna göre; son 5 yıl süresinde organizasyonların %71’i çok daha çevik olduklarını raporlamıştır. Bu çeviklik sayesinde, firmalar  değişime olan ihtiyacı fark edip; gün geçtikçe bu değişime daha hızlı adapte olabilme gücünü de elde ederler. Çeviklik, rekabet için olmazsa olmazdır.

Agile çevik proje yönetimi yaklaşımının çıkış hikayesine gelecek olursak; 2001 Şubat Ayında, Amerika’nın Utah eyaletinde 17 bağımsız Yazılım Lideri beyin fırtınası yapmak için bir araya geldi. Amaç; farklı bilgi ve yaklaşımlardan yararlanarak daha iyi nasıl yazılım geliştirileceğini bulmaktı. 2 günlük beyin fırtınası sonrası Agile Manifestosunu yayınladılar. Agile manifesto, 4 temel değer üzerine odaklanmaktadır:

Agile Manifesto – 4 Temel Değer:

  1. İş süreçleri ve araçlardan ziyade bireyler ve bireyler arasındaki etkileşim değerlidir.
  2. Kapsamlı bir dokümantasyon sürecinden ziyade, çalışan bir yazılım ortaya koymak daha önemlidir.
  3.  Müşteri ile işbirliği yapmak, sözleşme görüşmelerinden daha önemlidir.
  4.  Değişime cevap vermek, mevcut planı izlemekten daha önemlidir.

Bu toplantıda, Agile Manifesto’ya ek olarak 12 Çevik Yazılım Prensibi belirlendi:

Agile Çevik Proje Yönetimi uygulamasının temelinde yatan 12 Prensip:

  1. Değerli yazılımın erken ve devamlı teslimi yaparak müşteriyi memnun et.
  2. Değişime açık ol şöyleki; yazılımın son aşamasında bile değişen gereksinimleri kabul et.
  3. Çalışan yazılım sık ve tercihen kısa aralıklarla müşteriye sunulmalıdır.
  4. İşin sahibi ve yazılımcılar birlikte çalışmalıdır.
  5. Bireyleri motive et, ihtiyacı olan ortam ve desteği sağla ve işin başarıya ulaşacağı konusunda şüphelerin olmadığından emin ol.
  6. Yüz yüze iletişim, bilgi alışverisinde en etkin yöntemdir.
  7. Çalışan yazılım = (eşittir) ilerlemek.
  8. Agile süreçleri, sürdürülebilir geliştirmeyi destekler. Sponsorlar, kullanıcılar ve geliştirmeciler proje boyunca sabit tempoda bir çalışma düzeni kurmalılar.
  9. Teknik mükemmeliyet ve iyi tasarım olmazsa olmazdır.
  10. Sadelik ya da gereksiz işten kaçınma sanatı agile bir parçasıdır.
  11. Takımlar, kendi kendini organize edebilmelidir.
  12. Son aşama derinlemesine düşünmedir. Takım, düzenli aralıklarla nasıl daha etkili ve verimli olacağının üzerine düşünmeli ve davranışlarını buna göre düzenlemedir.

Neden Agile?

Agile Çevik Proje Yönetimi yaklaşımında her bir proje, iterasyon adı verilen proje fazlarına ayrılmıştır ve her bir faz sonunda çalışan bir ürün ortaya çıkar. İlk iterasyon fazında; minumum özellikte fakat olmazsa olmaz gereksinimlerin yer aldığı bir ürün çıkarmak hedeflenir. İlk olarak müşterinin en önemli gereksinimlerine odaklanılır. Her bir iterasyonda diğer gerekli özellikler eklenerek; proje sonucunda nihai ürüne ulaşırsınız. Agile çevik yaklaşımın en güzel yanlarından biri de, her bir iterasyon sonrasında test yapıldığı için; hataları erkenden tespit edip önlemler alabilirsiniz. Hata ne kadar erken tespit edilirse, bu hatanın projeye olan maliyeti o kadar az olacaktır. Waterfall modelinde test, ürünün tamamlanmasını takiben projenin sonunda yapılır.

waterfall-agile-cevik-yaklasımı-iteratif-scrum

Agile çevik proje yönetimi, waterfall şelale modeli, iterasyon ve aşamalı gelişim modeli

Agile metodolojisinin diğer güzel yanlarından birisi her iterasyon sonrasında, kullanıcılardan geri dönüşler alırsınız ve bu müşteri ihtiyaçları doğrultusunda bir sonraki iterasyonda bu geliştirmeleri uygularsınız. Değişiklikleri uygulamak, waterfall (şelale) modeline göre çok daha kolaydır. Değişim, Agile için olmazsa olmazdır. Agile çevil proje yönetim yaklaşımı değişime açıktır. Waterfall modelinde, değişiklik talepleri detaylı olarak değelendirilir; değişime direnç şelale modelinde daha fazladır. Çünkü müşterinin ürün ile etkileşime; ürünün geliştirmesi tamamlandıktan sonra geçer. Bu aşamada gerçekleşecek değişikliklerin maliyeti, ilk fazlara oranla daha yüksektir. Bu durum değişime direnci arttırır.

“Çeviklik, değişime adapte olma ve cevap verebilme yeteneğidir. Çevik organizasyonlar, değişimi fırsat olarak görürler, tehdit olarak değil…” Jim HighsmithTweetle

Agile yazılım geliştirme projelerindeki ihtiyaçlar nedeniyle doğdu. Fakat değişime kolay adapte olabilmesi ve müşteri istekleri ile uyumlu ürünleri en hızlı şekilde sunma avatajlarından dolayı yazılım haricinde; planlama, portfolyo yönetimi gibi diğer iş alanlarında kullanılmaya başlanıldı. Günümüz rekabet ortamında başarılı olmak için, teknolojinin getirdiği yeni gereksinimlere hızla adapte olmak ve bunun da ötesinde bu gereksinimlere ilk çözüm üreten olmayı gerektiriyor. Agile Çevik proje yönetimi başarısı da buradan geliyor.

Agile proje yönetimi yaklaşımı, geleneksel Proje Yönetim metodolojilerinin yerini alabilir mi?

Agile Çevik proje yönetimi yaklaşımı, diğer geleneksel Proje Yönetimi metodolojilerinin yerini alıyor söylemleri doğru değil. Agile yaklaşımı genellikle projenin başında son ürününe ait yeterli fikir ve bilginin yer almadığı ve uzun vadeli olmayan projelerde tercih ediliyor. Firmaların yaptığı, kendi şirket kültürlerine ve projelerinin yapısına uygun olarak; temel proje methodojilerini de göz ardı etmeden, çevik yaklaşımı kullanmayı tercih ediyorlar. Agile, projelerdeki çevikliği arttırmak için geleneksel yöntemlere ilave olarak uygulanması gereken modern bir yaklaşımdır.

Agile (Çevik) metodolojileri:

Agile çevik proje yönetimi yaklaşımında, kullanılan metodolojilerden en bilinirleri XP (Extreme Programlama), Yalın Prensipleri ve araçları (Lean Principles and tools), Kanban Prensipleri, Kristal Metodojileri, FDD (Feature-driven Development) , DSDM (Dynamis Systems Development Method), MDD (Model-driven Development), DAD (Disciplined Agile Delivery), TDD (Test-driven development), BDD (Behaviour-driven Development) ’dir.

Scrum nedir?

Scrum yönteminin, methodoloji olarak adlandırılmamasının sebebi; raporlama, kaynak kontrolu, kodlama ile ilgili temel konuların nasıl uygulanması gerektiğini tarif etmez. Bunun aksine, iteratif (tekrarlayan) ve aşamalı artan modelleri kullanarak, daha iyi bir öngörülebilirlik ve risk yönetimi yapmaya olanak sağlar. Scrum’da iterasyonlar “sprint” olarak adlandırılır ve her bir sprint uzunluğu 1-4 Hafta arasında değişiklik gösterir. Çoğunlukla, 2 haftalık sprint uzunluğu tercih edilmektedir. Her sprint öncesinde, ekip bir araya gelerek bu sprint’de hangi işlerin yapılacağına karar verirler. Bu sprint sonunda ise ortaya çıkan ürün test edilir. İlaveten kullanıcı ve diğer proje paydaslarının bu ürün ile ilgili geri bildirimi alınır. En başta high-level plan hazırlanmış olsada, her sprint arasında planlar yeniden değerlendirilir. Bir önceki sprintdeki kullanıcı geribildirimleri de dikkate alınarak sonraki sprintde ne tür değişiklikler ve adaptasyonlar yapılacağına karar verilir.

Sprint planlama toplantısı, ekibin bir araya gelerek o sprintde teslim edilecek ürünlere dair karar aldıkları birincil toplantıdır. Bu toplantıda ürün sahibi, ürüne dair geribildirim verir. Bu toplantıda gereksinimler yeniden önceliklendirilir ve önem seviyesine göre sırası değiştirilebilir.
Günlük scrum toplantıları ya da diğer adıyla günlük stand up toplantıları, yaklaşık 15 dk sürer ve tamamlanan işler, sıradaki işler ve işi aksatabilecek engeller üzerine konuşulur. Takımdaki her kişi şu soruları kendine sormalıdır:
• Son scrumdan bu yana hangi işleleri tamamladım ve neden?
• Sonraki scruma kadar hangi işleri bitirmem gerekiyor?
• Ekibin çözüm üretmede yardımcı olacağı sorun ve engeller ile karşılaştım mı?

Sprint gözden geçirme toplantısı, ortaya çıkan ürünün, ürün sahibine ve diğer proje paydaşlarına demosunun yapıldığı toplantıdır.

Sprint Retrospektif toplantısında; ekip bireylerinin bir araya gelerek neyin iyi gittiğini, neyin yolunda gitmediğini ve ekip olarak daha iyisini yapabilmek için hangi aksiyonların alınması gerektiği üzerine konuşulur.

Agile çevik proje yönetimi modelinin dezavantajları nelerdir?

Projenin maliyet ve bitiş zamanı öngörülemeyebilir: Projenin kapsamı en başından net olmadığı ve müşteri gereksinimleri projenin ilerlemesi ile olgunlaştığı için; projenin maliyeti ve proje zaman planı zaman içinde değişiklik gösterebilir.

Müşterinin aktif katılımı gereklidir: Müşterinin yeterli katılım göstermemesi ürünün kalite ve başarısını direkt olarak etiler.

Yetersiz dokümantasyon, yanlış anlaşılmalara yol açabilir: Waterfall modeline göre daha az detayda dokümantasyon hazırlanır; çünkü agile yaklaşımında önemli olan çalışan ve müşteri gereksinimlerine cevap veren bir ürün ortaya çıkarmaktır. Fakat yeni takım oyunucuları ekibe katıldığında, daha önce yapılan geliştirmelere yönelik dokümantasyonlardan yeterli bilgi alamayabilirler. Bu durumda karışıklıklara ve yanlış anlaşılmalara yol açabilir.

Peki siz Agile Çevik proje yönetimi yaklaşımını projelerinizde uyguluyor musunuz? Agile sonrası, proje yönetimi anlamında ne tür faydalar elde ettiniz ve ne tür zorluklar ile karşılaştınız? Yorumlarınızı bekliyorum.

 

Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir