Agile | Bir Proje Devrimi
Yazılım projelerinin yarısından çoğu zaman, maliyet ya da kapsam açısından başarısız olarak görülüyor. Peki, projelerin başarısızlıkla sonuçlanmasına neden olan risk faktörlerinin ortadan kaldırılmasında kullanılan yönetim metodunun önemi var mı?
Bilgi teknolojileri sektöründe yapılan birçok proje, hızlı değişen müşteri gereksinimlerinin doğru ve net olarak belirlenmemesi, proje yönetim metotları uygulanmadan geliştirilmesi, süreçlerin iyi takip edilmemesi gibi farklı sebeplerden dolayı başarısızlığa uğramaktadır. Yanlış mimari seçilerek başlanılan ya da gereksinimlerin yanlış belirlendiği bir projede, proje yönetim biçimi değişiklikleri uygulama konusunda esnek değilse değişiklikler kolay kolay uygulanamadığından bu projenin başarısız olması kaçınılmazdır. Özellikle de proje süresince müşteri ile iletişimden kaçınılmışsa bu gibi yanlışlıklar ya da eksiklikler çok sonra fark edilebilir.
2009 yılında yapılan araştırmalara göre yazılım projelerinin %68'i değişen koşullara ayak uyduramadığından veya maliyet/zaman hedeflerini aştığından başarısızlıkla sonuçlanıyordu. Bu durum, Avrupa ve Amerika'daki büyük şirketleri, daha verimli projeler üretmek üzere çeşitli yöntemleri denemeye yöneltti ve çoğu şirket yönetimde ve uygulamada Agile (çevik) yazılım geliştirme yaklaşımlarını benimsemeye başladı.
Agile yani çevik proje yönetimi adından da anlaşılacağı üzere müşterinin veya piyasanın değişen ihtiyaçlarına hızlı bir biçimde cevap verebilmeyi sağlayan bir süreçler bütünüdür diyebiliriz.
Gelin bunu bir örnekle inceleyelim.
Bir kurumsal web sitesinin yenilenmesinde proje yönetimini yaptığınızı düşünelim. Bu proje temelde 5 adımdan oluşacaktır.
Ön hazırlık yani kapsam belirleme
Analiz
Yazılım geliştirme
Test – onay
Proje kapanış yani canlıya çıkma
Bu proje adımlarını sırasıyla takip eden proje yönetimine Waterfall(Şelale) method deniyor. Bu en klasik ve bilinen proje yönetimi biçimi. Dikkat edilirse waterfall method'unda "Test" aşaması projenin yayına alınıp kapanmasının hemen önünde bulunuyor.
Peki, test aşamasında alınan bir güncelleme talebi projenin üretimini hangi aşamaya çeker? Elbette ki projenin gideceği aşama alınan güncelleme talebi ile doğrudan alakalıdır fakat büyük bir ihtimalle sizi analiz hatta kapsam belirleme adımına kadar geri itecektir.
Aslında agile proje yönetiminde kullanılan adımlar, bu bahsettiğimiz adımlardan farklı değil. Ayrıştırıcı olan kısmı Agile proje yönetiminin temelde "iteration"a (öz yinelemeye) dayanmasıdır. Kabaca, "Yapılmak istenen projeyi, küçük parçalara bölme, bu çalışan küçük parçaları bir araya getirerek tamamlama ve bu yinelemeyi bütün proje bitene kadar tekrar etme işlemidir." diyebiliriz. (Buralarda scrum iterasyon info grafiklerine ihtiyaç var)
Her bir "iterasyon"u farklı mini projeler olarak düşünülebiliriz. Her "iterasyon" için test ve onay aşamaları da ayrıca tamamlanıyor. Böylelikle her "iterasyon" sonunda projenin belli bir kısmı onaylı bir şekilde tamamlanmış oluyor.
Waterfall (Şelale) modelde projenin testi tüm development tamamlandığında yapılırken; Agile (Çevik) süreçte her bir iterasyon sonrasında projenin çalışan parçaları ayrı ayrı test edilir ve müşteri geri bildirimleri sonrasında projenin ilgili kısmına entegre edilir. Böylelikle proje üretim boyunca sürekli teste tabi tutulmuş olacaktır.
Bu şekilde bir Agile (Çevik) Proje Yönetim Modeli ile çalışmanın avantajlarını kabaca şu başlıklar altında toplanabilir.
Esnektir:
İterasyonlar arasındaki zaman kısa olduğundan aniden ortaya çıkan değişiklik ihtiyaçları hızlıca organize edilebilir.
Müşteri projenin üretim sürecine dahildir:
Tamamlanan her iterasyonda çıkan ürün-modül, müşteri tarafından geri bildirimlerle beslenir ve süreç devam eder.
Şeffaftır:
Üretim aşamasında karşılaşılan problemler dikkate alınır ve bir sonraki döngüde daha iyi bir çözüm bulabilmek için referans olarak kullanılır.
Bilgi teknolojileri sektöründe yapılan birçok proje, hızlı değişen müşteri gereksinimlerinin doğru ve net olarak belirlenmemesi, proje yönetim metotları uygulanmadan geliştirilmesi, süreçlerin iyi takip edilmemesi gibi farklı sebeplerden dolayı başarısızlığa uğramaktadır. Yanlış mimari seçilerek başlanılan ya da gereksinimlerin yanlış belirlendiği bir projede, proje yönetim biçimi değişiklikleri uygulama konusunda esnek değilse değişiklikler kolay kolay uygulanamadığından bu projenin başarısız olması kaçınılmazdır. Özellikle de proje süresince müşteri ile iletişimden kaçınılmışsa bu gibi yanlışlıklar ya da eksiklikler çok sonra fark edilebilir.
2009 yılında yapılan araştırmalara göre yazılım projelerinin %68'i değişen koşullara ayak uyduramadığından veya maliyet/zaman hedeflerini aştığından başarısızlıkla sonuçlanıyordu. Bu durum, Avrupa ve Amerika'daki büyük şirketleri, daha verimli projeler üretmek üzere çeşitli yöntemleri denemeye yöneltti ve çoğu şirket yönetimde ve uygulamada Agile (çevik) yazılım geliştirme yaklaşımlarını benimsemeye başladı.
Agile yani çevik proje yönetimi adından da anlaşılacağı üzere müşterinin veya piyasanın değişen ihtiyaçlarına hızlı bir biçimde cevap verebilmeyi sağlayan bir süreçler bütünüdür diyebiliriz.
Gelin bunu bir örnekle inceleyelim.
Bir kurumsal web sitesinin yenilenmesinde proje yönetimini yaptığınızı düşünelim. Bu proje temelde 5 adımdan oluşacaktır.
Ön hazırlık yani kapsam belirleme
Analiz
Yazılım geliştirme
Test – onay
Proje kapanış yani canlıya çıkma
Bu proje adımlarını sırasıyla takip eden proje yönetimine Waterfall(Şelale) method deniyor. Bu en klasik ve bilinen proje yönetimi biçimi. Dikkat edilirse waterfall method'unda "Test" aşaması projenin yayına alınıp kapanmasının hemen önünde bulunuyor.
Peki, test aşamasında alınan bir güncelleme talebi projenin üretimini hangi aşamaya çeker? Elbette ki projenin gideceği aşama alınan güncelleme talebi ile doğrudan alakalıdır fakat büyük bir ihtimalle sizi analiz hatta kapsam belirleme adımına kadar geri itecektir.
Aslında agile proje yönetiminde kullanılan adımlar, bu bahsettiğimiz adımlardan farklı değil. Ayrıştırıcı olan kısmı Agile proje yönetiminin temelde "iteration"a (öz yinelemeye) dayanmasıdır. Kabaca, "Yapılmak istenen projeyi, küçük parçalara bölme, bu çalışan küçük parçaları bir araya getirerek tamamlama ve bu yinelemeyi bütün proje bitene kadar tekrar etme işlemidir." diyebiliriz. (Buralarda scrum iterasyon info grafiklerine ihtiyaç var)
Her bir "iterasyon"u farklı mini projeler olarak düşünülebiliriz. Her "iterasyon" için test ve onay aşamaları da ayrıca tamamlanıyor. Böylelikle her "iterasyon" sonunda projenin belli bir kısmı onaylı bir şekilde tamamlanmış oluyor.
Waterfall (Şelale) modelde projenin testi tüm development tamamlandığında yapılırken; Agile (Çevik) süreçte her bir iterasyon sonrasında projenin çalışan parçaları ayrı ayrı test edilir ve müşteri geri bildirimleri sonrasında projenin ilgili kısmına entegre edilir. Böylelikle proje üretim boyunca sürekli teste tabi tutulmuş olacaktır.
Bu şekilde bir Agile (Çevik) Proje Yönetim Modeli ile çalışmanın avantajlarını kabaca şu başlıklar altında toplanabilir.
Esnektir:
İterasyonlar arasındaki zaman kısa olduğundan aniden ortaya çıkan değişiklik ihtiyaçları hızlıca organize edilebilir.
Müşteri projenin üretim sürecine dahildir:
Tamamlanan her iterasyonda çıkan ürün-modül, müşteri tarafından geri bildirimlerle beslenir ve süreç devam eder.
Şeffaftır:
Üretim aşamasında karşılaşılan problemler dikkate alınır ve bir sonraki döngüde daha iyi bir çözüm bulabilmek için referans olarak kullanılır.
Agile aslında proje yönetimine bir bakış açısıdır. Dolayısıyla bu methodu sadece yazılım projelerinde kullanacaksınız diye bir şey yok. Hayatınızın her alanında çevik olabilirsiniz. Daha fazla bilgi almak için öncelikle Agile manifestoyu okuyabilir, sonrasında temelde aynı prensiplere dayanan fakat farklı tip projeler için geliştirilmiş Scrum, Kanban, Kaizen gibi farklı agile methodlarını inceleyebilirsiniz. Methodlarınız güvenilir, projeleriniz başarılı olsun. Hoşça kalın, Mühendis Kafalar'da kalın.
Yazar hakkında
Gamze AĞCA DÖNMEZ henüz özgeçmişini yazmamış
Yorum