Başlarken Güncel

Agile Proje Yönetimi (Çevik Yönetim) Nedir ?

Çevik (Agile) proje yönetimi, sürekli sürümlere odaklanan ve her yinelemede müşteri geri bildirimlerini birleştiren yazılım geliştirme projelerini yönetmeye yönelik yinelemeli bir yaklaşımdır.

Bu yaklaşımı bir örnekleme ile anlatacak olursak, bir futbol maçını ele alalım. Maçlarda genellikle iki taraf yer alır ve amaç gol atarak galip gelmektir. Tabii ki hakemlerin de onaylaması gerekir golü. Eğer ofsayt, faul gibi futbolun kurallarına uymuşsak golümüz sayılacaktır. Agile ile proje geliştirirken ekip olarak her bir proje adımını futboldaki ataklara benzetecek olursak, ekip olarak projemize gol atmak için devamlı olarak ataklar yapıyoruz ama burada hakemimiz müşterilerimiz. Eğer ki faul yaparsak müşterilerimiz hemen uyarıyor ve hemen atak tazeliyoruz. Sonrasında tabii ki dostluk kazanıyor. Bu yaklaşımda dikkat edilmesi gerek şey her bir adımın müşteri onayına sunulması ve geri dönüşler ile hareket edilmesidir. Diğer yaklaşımların aksine daha fazla müşteri taraflı ve aslında daha kolay proje yönetimi sağlamaktadır. Bunların haricinde de müşteriye devamlı olarak çalışan bir projeyi gösteriyor ve geliştirme yapıyor olmanız müşteri tarafından hoş karşılanan bir durum. Kısaca şöyle bir diğer proje yönetim modeli olan Şelale (Waterfall) Modelini düşünürsek, Bu modelde;

Şelale , yazılım geliştirmeye doğrusal bir yaklaşımdır. Bu metodolojide, olayların sırası şuna benzer:

  1. Gereksinim Analizi
  2. Tasarım
  3. Kodlama
  4. Test
  5. Gerçekleştirim
  6. Bakım ve Onarım
  7. Teslim

Bu modelde ilk adımdan müşteriden istekleri toplanır ve tasarım, kodlama, test aşamaları sırasıyla gelir. Ama bu aşamalarda müşteriye herhangi bir soru sorulmaz çünkü baştan istenenler konuşulmuştur. Peki ya teslim adımında müşterinin gereksinimleri eksik alınmışsa ve gereksinimler değişmişse ? Proje yeniden mi yazılacak ?

Şimdi Şelale modelinin ve Çevik modelinin kullanım alanları farklı aslına bakacak olursanız. Ama şunu kolayca söylemek mümkün ki Çevik Modelinin müşteriye devamlı olarak çalışan bir sistemi gösteriyor olmanız, devamlı olarak müşterinin isteklerine göre geliştirme yapmamız hem müşterinin isteklerine tam uyumlu bir sistem olur hem de geliştirme tarafında hangi adımda sorun olsa o adımda çözülerek ekip olarak devamlı koordine bir şekilde projenin gerçekleştirimi sağlanmış oluyor. Burada şelalenin iyi tarafı yok mu? tabii ki var önceden müşteri gereksinimlerinin toplanması proje süresinin belirlenmesinde kararlı bir sonuç vermesi de proje gerçekleştirimi açısından önemli bir adım.

 

Çevik Manifesto

İlk olarak Şubat 2001’de 17 yazılım geliştiricisi tarafından yazılan Çevik Manifesto şunları belirtir:

Bunu yaparak ve başkalarının yapmasına yardımcı olarak yazılım geliştirmenin daha iyi yollarını ortaya çıkarıyoruz. Bu çalışma sayesinde değer kazandık:

  • Süreçler ve araçlardan ziyade bireyler ve etkileşimler
  • Kapsamlı dokümantasyon yerine çalışan yazılım
  • Sözleşme pazarlığı üzerinden müşteri işbirliği
  • Bir planı takip etmek yerine değişime yanıt vermek

 

Çevik Yaklaşım

Çevik metodolojilerin birçok uygulaması olsa da, bir Çevik yazılım geliştirme yaklaşımındaki en yaygın adımlar şunlardır:

1. Keşif

Yeni bir projeye başlarken müşterinin vizyonunu ve geçmişini anlamak önemlidir. Çevik yazılım geliştirme projeleri bir dizi Keşif Oturumu ile başlar ve bir müşterinin hedeflerini, zorluklarını, iş ortamını ve müşterileri ve kullanıcıları anlamak için araştırma yapar. Bu oturumlar, tüm ekip genelinde ortak bir anlayış sağlamak için müşteri, proje yöneticisi, tasarımcı, geliştirici ve ürün sahibi dahil olmak üzere proje ekibinin kilit üyelerini içerir.

2. Ürün İş Listesi

Keşif sırasında ekip , müşteri ve kullanıcıları için yararlı olabilecek tüm özelliklerin bir istek listesi olan üst düzey bir Ürün İş Listesi oluşturmak için birlikte çalışır . Ürün sahibi, bu özelliklere öncelik vermek için müşteri ile birlikte çalışır, özelliklerin hangi sırayla geliştirildiğini, geliştirildiğini, test edildiğini ve teslim edildiğini belirler. Müşterinin önceliği belirlemesine izin vererek, ekip daha düşük değerli özelliklere geçmeden önce en yüksek değerli özellikleri sunmaya odaklanır.

3. Yinelemeler

Ekibin müşterinin vizyonunu anladığından ve üst düzey bir özellik biriktirme listesi oluşturduğundan emin olduktan sonra ekip, Sprint adı verilen bir dizi zaman kutulu yinelemeyle özellikler sunar  Bunlar 1-4 haftalık sabit sürelerdir (proje boyutuna ve süresine bağlı olarak) ve her biri genel ürün birikiminin bir alt kümesini sunar.

4. Döngüye Devam Etmek

Ek özellikler sunmak ve önceki yinelemelerden, incelemelerden ve kullanıcı beta testlerinden gelen geri bildirimleri dahil etmek için gerektiğinde ek Sprintler gerçekleştirilir. Her bir ardışık Sprint, hem Yinelemelidir, hem de önceki sprintlerde tamamlanan iş için iyileştirmeler sağlar; ve artan, sisteme yeni özellikler ekleyerek.

Çevik metodolojileri yazılım geliştirme sürecinize dahil etmek, programınızın genel başarısının yanı sıra geliştirme ve yatırımınızın geçici faydası üzerinde büyük bir etkiye sahip olabilir. Geri bildirim ve düzeltme, küçük hataları büyük sorunlara dönüşmeden önce düzeltmek için hızlı bir şekilde gerçekleştirilebilir. Süreç boyunca iletişim, proje yönetimine Agile yaklaşımıyla da geliştirilir. Genel olarak, Çevik, yazılımın başarılı bir şekilde geliştirilmesi için yalın ve etkili bir model sağlar.

Çevik Avantajları

Paydaş Katılımı

Çevik, her Sprint öncesinde, sırasında ve sonrasında paydaş ve ekip katılımı için birden fazla fırsat sunar. Müşteriyi projenin her adımına dahil ederek , müşteri ve proje ekibi arasında yüksek derecede bir işbirliği vardır ve bu, ekibin müşterinin vizyonunu gerçekten anlaması için daha fazla fırsat sağlar. Çalışan yazılımı erken ve sık sık sunmak, paydaşların ekibin yüksek kaliteli çalışan yazılım sağlama becerisine olan güvenini artırır ve onları projeye daha derinlemesine katılmaya teşvik eder.

Şeffaflık

Çevik bir yaklaşım, müşterilere özelliklerin önceliklendirilmesinden yineleme planlamasına ve gözden geçirme oturumlarına ve yeni özellikler içeren sık yazılım derlemelerine kadar proje boyunca dahil olmaları için benzersiz bir fırsat sağlar. Bununla birlikte, bu aynı zamanda müşterilerin, şeffaflığın bu ek faydası karşılığında devam eden bir çalışma gördüklerini anlamalarını gerektirir.

Erken ve Öngörülebilir Teslimat

1-4 haftalık zaman kutulu, sabit programlı Sprintleri kullanarak, yeni özellikler yüksek düzeyde öngörülebilirlikle hızlı ve sık bir şekilde sunulur. Bu ayrıca, yeterli iş değeri varsa, yazılımı planlanandan daha önce yayınlama veya beta testi yapma fırsatı sağlar.

Öngörülebilir Maliyetler ve Zamanlama

Her Sprint sabit bir süre olduğundan, maliyet tahmin edilebilirdir ve sabit programlı zaman kutusunda takım tarafından gerçekleştirilebilecek iş miktarı ile sınırlıdır. Her Sprint öncesinde müşteriye sağlanan tahminlerle birleştirildiğinde, müşteri her bir özelliğin yaklaşık maliyetini daha kolay anlayabilir, bu da özelliklerin önceliği ve ek yineleme ihtiyacı hakkında karar vermeyi geliştirir.

Değişime İzin Verir

Ekibin her yineleme sırasında ürün özelliklerinin üzerinde anlaşılan bir alt kümesini sunmaya odaklanması gerekirken, genel ürün birikimini sürekli olarak iyileştirme ve yeniden önceliklendirme fırsatı vardır. Bir sonraki yineleme için yeni veya değiştirilmiş biriktirme listesi öğeleri planlanabilir ve bu da birkaç hafta içinde değişiklik yapma fırsatı sunar.

İşletme Değerine Odaklanır

Ekip, müşterinin özelliklerin önceliğini belirlemesine izin vererek, müşterinin işi için neyin en önemli olduğunu anlar ve en fazla iş değerini sağlayan özellikleri sunabilir.

Kullanıcı Odaklı

Agile(Çevik) , ürün özelliklerini tanımlamak için genellikle iş odaklı kabul kriterlerine sahip kullanıcı hikayelerini kullanır . Özellikleri gerçek kullanıcıların ihtiyaçlarına odaklayarak, her bir özellik yalnızca bir BT bileşeni değil, aşamalı olarak değer sunar. Bu aynı zamanda, her Sprintten sonra yazılımın beta testini yapma fırsatı sunarak, projenin erken aşamalarında değerli geri bildirimler elde etme ve gerektiğinde değişiklik yapma becerisi sağlar.

Kaliteyi Artırır

Proje ekibi, projeyi yönetilebilir birimlere ayırarak, yüksek kaliteli geliştirme, test ve işbirliğine odaklanabilir. Ayrıca, her yineleme sırasında sık derlemeler üreterek ve testler ve incelemeler gerçekleştirerek, kusurları hızlı bir şekilde bularak ve giderilerek ve beklenti uyuşmazlıkları erken tespit edilerek kalite iyileştirilir.

Çevik yazılım geliştirme için güçlü bir araçtır, yalnızca geliştirme ekibine fayda sağlamakla kalmaz, aynı zamanda müşteriye bir dizi önemli ticari fayda sağlar. Çevik, proje ekiplerinin en yaygın proje tuzaklarının (maliyet, program öngörülebilirliği ve kapsam kayması gibi) daha kontrollü bir şekilde ele almasına yardımcı olur. Agile, özel yazılım geliştirmeye dahil olan etkinlikleri yeniden düzenleyerek ve yeniden tasarlayarak, aynı hedeflere daha yalın ve daha iş odaklı bir şekilde ulaşır.

Çevik Yazılım Metotları

  • Uç Değer Programlama (Extreme Programing — XP)
  •  Scrum
  • Çevik Tümleşik Süreç(Agile Unified Process -AUP)
  • Özellik Güdümlü Geliştirme (Feature-Driven Development — FDD)

 

SCRUM

 Scrum, kelime olarak rugby oyununda oluşturulan küçük ekiplere verilen isimdir. Günümüzde çokça tercih edilen bir metottur. Eski yöntemlerdeki gibi projede izlenmesi gereken adımlar belirtilmemekte, bunun yerine basit ama önemli birkaç kuralı sayesinde esnek ama üretken bir işleyiş sunmaktadır. Scrum’ın sağladığı faydalardan biri de, işleyiş sürecini şeffaf hale getirerek aksaklıkları ortaya çıkarır. Böylelikle proje ekibinin hataları fark ederek sürekli olarak iyileştirme yapmalarına olanak sağlar.

Scrum’ın genel olarak çalışmasına gelecek olursak, yapılacak olan iş (Product Backlog) parçalara bölünür. Daha sonra işin belirli bir parçası (Sprint Backlog) ele alınır ve 2–4 hafta süreyle bu işin tamamlanması planlanır. Genelde 4 hafta olan bu süreye “Sprint” denir.

Scrum’ da 3 temel kavram vardır. Bunlar “Roller” , “Toplantılar” ve “Araçlar” dır.

Rollere gelirsek ilk olarak bir ürün Sahibi (Product Owner) olmalıdır. Bu kişi illa müşterinin kendisi olmak zorunda değildir. Bir müşteri temsilcisi veya Scrum ekibinin bir parçası da olabilir. Önemli olan bu kişinin müşteriyle iletişim kurabilmesi, müşterinin ne istediğini bilmesidir. Bu kişi ekiple birlikte hareket eder ve projede bizzat yer alır.

Scrum Yöneticisi’ nin (Scrum Master) görevi takıma emirler verip yönetmek değildir. Scrum master: takıma yardımcı olan, bir problem olduğunda onu çözen, takımlar ve ürün sahibiyle olan iletişime yardımcı olan, takımın ve organizasyonun Scrum’a adapte olmasını sağlayarak üretkenliğin artmasına katkıda bulunan kişidir.

Scrum Takımı (Scrum Team) , birbirleriyle iletişim halinde olan ve programlama işini yapan gruptur. Kendi içlerinde farklı görevleri olabilir ama hedefleri ortaktır. Genellikle 5 ila 10 kişiden oluşur.

Toplantılar:

Sprint Planning de sprintlerde neler yapılacağı, gereksinimlerin listesi, takımların belirlenmesi, risk analizleri ve maliyet hesaplamaları yapılır.

Tüm sprint boyunca her gün takım üyeleri bir araya gelerek 15 dakika boyunca ayaküstü toplantılar yaparlar. Bu toplantılara “Daily Scrum Meeting” denir. Bu toplantılarda önceki gün neler yapıldığı, ne gibi sorunlarla karşılaşıldığı, o gün neler yapılacağı ve nasıl yapılacağı hakkında özet şeklinde konuşmalar yapılır. Ayaküstü toplantı denmesinin sebebi, toplantı denilince akılda şekillenen karşılıklı oturup slaytlar üzerine konuşmalar değil, herhangi bir grup üyesinin masasının başında bile olsa toplanarak takım içi iletişimi kaybetmemek ve birbirine yardımcı olmak için görüş alışverişi yapılmasıdır.

Her sprint ardından bir Sprint Gözden Geçirme (Sprint Review) yapılır. Buraya herkes davet edilebilir ve yapılanlar gözden geçirilir. Bu toplantılar uzun sürebilir. Ardından bir sonraki sprinte hazırlık yapılır.

Üçüncü temel değer olan Araçlar ’ın (Artifacts) başında Ürün Gereksinim Dokümanı(Product Backlog) gelir. Proje boyunca tamamlanması gereken işlerin listesidir. Listeyi product owner yönetir. Bu liste genelde kullanıcı hikayelerinden (user story) oluşur. Yani kullanıcının isteğine göre yeni gereksinimler eklenir veya çıkarılır.

Sprint Listesi (Sprint Backlog), bir sprint turunda takımın yapması gereken işlerin listesidir. Product Backlog ’ın bir alt kümesi olarak düşünülebilir. Bir sprint döngü için seçilen gereksinimler, görevlere bölünerek takımda bulunan üyelere dağıtılır.

Sprint Kalan Zaman Grafiği (Burndown Chart), bir sprint turunda görevler yerine getirildikçe yapılan iş ile kalan iş arasındaki bağıntıyı ortaya çıkaran grafiktir. Belirlen sürenin yeterli olup olamadığı, işin gidişatında bir sorun olup olamadığı ve işin zamanında bitip bitmeyeceği hakkında takıma ve yöneticilere bilgi sağlar.

Scrum, uzmanlık gerektiren ve maliyeti yüksek bir modeldir. Ancak kısa sürmesi, kolay uygulanması ve başarı garantisinin yüksek olması nedeniyle günümüzde kullanımı oldukça artmaktadır. Google, Microsoft, IBM ve Yahoo gibi büyük şirketler tarafından tercih edilmektedir.

Sizlerde yazılım projelerinin geliştirilmesinde Agile (Çevik) Proje Yönetimini kullanabilirsiniz.

 



Yazar hakkında

Furkan Toptaş

Manisa Celal Bayar Üniversitesinde Yazılım Mühendisliği 4. Sınıf öğrencisiyim. Teknovol şirketinde Front-end üzerine kendimi geliştiriyorum. Bilgi sahibi olduğum konuları sizlerle paylaşıyorum. Geri dönüşleriniz benim için önemlidir. Yorum, düşünce ve görüşlerinizi bekliyorum.

Yorumlar

Bir yorum yaz