Proje yönetimi, geleneksel olarak yüksek beklentiler, sınırlı kaynaklar ve maalesef düşük başarı oranları ile zorlu bir uygulama olmuştur. Bu yazımda proje yönetiminin neden modernleşmesi gerektiğini anlatacağım. Proje yönetiminde tarihsel yaklaşımların neler olduğunu ve onların kusurlarını ve zayıflıklarını açıklayacağım. Çevik Manifesto ve 12 Çevik İlkeler: Çevik proje yönetimi temeli için bir giriş sağlayacağım. Son olarak, ürünlerinizin, projenizin, ekibinizin, müşterilerinizin ve organizasyonunuzun çevik proje yönetimini benimseyerek kazanabileceği avantajları size anlatacağım.
Çevik proje yönetimi, işin erken teslimine, projenin ürün ve süreçlerinin sürekli iyileştirilmesine, kapsam esnekliğine, ekip girdisine ve müşteri ihtiyaçlarını yansıtan iyi test edilmiş ürünlerin sunulmasına odaklanan bir proje yönetimi stilidir. Bir proje, kesin bir zaman, çaba ve tamamlanması planlanan, planlı bir iş programıdır. Projelerin hedefleri ve amaçları vardır ve çoğu zaman belirli bir süre içinde ve belirli bir bütçe dahilinde tamamlanmalıdır. Çevik yaklaşımlar proje yönetimini modernize etme ihtiyacına bir cevaptır. Çevik yaklaşımların projelerde nasıl devrim yarattığını anlamak için, proje yönetiminin tarihçesi ve amacı ile projenin günümüzde karşılaştığı sorunlar hakkında biraz bilgi sahibi olmakta fayda vardır.
Modern proje yönetiminin kökenleri
Projeler eski çağlardan beri bizimle beraberler. Çin’in Büyük Duvar’ından, Tikal’deki Maya piramitlerine, matbaanın icadından İnternet’in bulunuşuna kadar insanlar projelerde büyük ve küçük deneyimler kazandılar. Ancak Proje Yönetimi resmi bir disiplin olarak hayatımıza 20. yüzyılın ortalarında giriş yapmıştır. II. Dünya Savaşı zamanında çoğunluğu ABD ordusu için çalışan dünyanın dört bir yanındaki araştırmacılar, bilgisayar yapma ve programlama konusunda büyük ilerlemeler kaydettiler. Bu projeleri tamamlamak için resmi proje yönetimi süreçleri oluşturmaya başladılar. İlk süreçler, ABD ordusunun İkinci Dünya Savaşı sırasında kullandığı adım adım üretim modellerine dayanıyordu. Bilgisayar alanındaki insanlar, bu adım tabanlı üretim süreçlerini benimsedi, çünkü bilgisayar ile ilgili projeler, donanımları büyük ölçüde kullanan ve tüm odaları dolduran bilgisayarlara dayanıyordu. Yazılım, bilgisayar projelerinin daha küçük bir parçasıydı. 1940’larda ve ‘50’lerde bilgisayarların binlerce fiziksel vakum tüpü olabilir, ancak 30’dan az programlama kodu olabilirdi. İlk bilgisayarlarda kullanılan bu üretim süreci, “şelale model” olarak bilinen proje yönetimi metodolojisinin temelidir. 1970 yılında, Winston Royce adlı bir bilgisayar bilimcisi, “Büyük Yazılım Sistemlerinin Geliştirilmesini Yönetmek” başlıklı yazıda, IEEE’nin şelale metodolojisindeki aşamaları tanımlayan bir makale yazdı. Şelale terimi daha sonra ortaya çıkmıştır, ancak aşamalar, bazen farklı bir şekilde adlandırılmış olsalar bile, esasen Royce tarafından tanımlandığı gibidir:
1. Gereksinimler
2. Tasarım
3. Geliştirme
4. Entegrasyon
5. Test
6. Dağıtım
2008 yılında çevik tekniklere dayanan geliştirilmiş yaklaşımlara geçene kadar şelale metodolojisi yazılım geliştirmede en yaygın proje yönetimi yaklaşımıydı.
Bilgisayar teknolojisi, elbette, geçen yüzyıldan beri büyük bir değişim geçirdi. Aynı zamanda, bilgisayar kullanan insanlar da değişti. Birçok ülkede, hemen hemen herkes, her gün doğrudan veya dolaylı olarak bir bilgisayar kullanıyor. Yazılım otomobillerimizi çalıştırıyor; günlük bilgilerimizi ve günlük eğlencemizi sağlıyor. Her geçen gün daha yeni ve iyi yazılım ürünlerine talep sürekli artıyordu. Bir şekilde, tüm bu teknoloji büyümesi sırasında süreçler geride kaldı.
Yazılım geliştiricileri hala 1950’li yıllardan beri proje yönetim metodolojilerini kullanıyor ve bu yaklaşımların tümü yirminci yüzyılın ortalarına değin donanım-ağırlıklı bilgisayarlara yönelik üretim süreçlerinden kaynaklanıyordu. Geçtiğimiz yirmi yıl içinde, projeler üzerinde çalışan insanlar geleneksel proje yönetimi ile ilgili sorunların farkına vardılar ve daha iyi bir model oluşturmak için çevik proje yönetimi üzerine çalışmaya başladılar.
Agile(Çevik) Proje Yönetimine Giriş
1986 yılında Hirotaka Takeuchi ve Ikujiro Nonaka, Harvard Business Review’da “Yeni Ürün Geliştirme Oyunu(New Product Development Game)” başlıklı bir makale yayınladı. Takeuchi ve Nonaka’nın makalesinde, hızlı ürün taleplerini karşılamak için hızlı ve esnek bir geliştirme stratejisi açıklandı. Bu makale ilk olarak ürün geliştirme ile birlikte ürün geliştirmeyi bir Rugby oyununa benzeterek “SCRUM” terimini ortaya koydu. Daha sonra Scrum en popüler çevik proje yönetimi yaklaşımlarından biri oldu. 2001 yılında, bir grup yazılım ve proje uzmanı, başarılı projelerinin ortak noktalarını konuşmak için bir araya geldi. Grup, başarılı yazılım geliştirme için Agile Manifesto’sunu ortaya çıkardı. Bu uzmanlar aynı zamanda Agile Manifesto’sundaki değerlerin desteklenmesine yardımcı olan 12 İlke olan Çevik İlkeyi de oluşturdular. (Agile Manifestosu’na ve ilkelerin neler olduğuna buradan ulaşabilirsiniz.)
Çevik projeler nasıl çalışır?
Çevik yaklaşımlar, deneysel bir kontrol yöntemine dayanır. Yazılım geliştirme metodolojileri bağlamında, deneysel bir yaklaşım hem yeni ürün geliştirme hem de geliştirme ve yükseltme projelerinde çok etkili olabilir. Deneysel kontrol şunları gerektirir;
Şeffaflık: Çevik bir projeye dahil olan herkes, neler olduğunu ve projenin nasıl ilerlediğini bilir.
Sıklıkla denetleme: Ürüne yatırım yapan ve en çok işleyen insanlar düzenli olarak ürünü ve süreci değerlendirmelidir.
Adaptasyon: Sorunları en aza indirmek için hızlı bir şekilde ayarlamalar yapılmalıdır.
Sık sık denetlenmeye ve adaptasyona uyum sağlamak için çevik projeler iterasyonlarla çalışır. Çevik projelerde, geleneksel bir şelale projesinde yer alan aynı türden çalışmaya sahip olursunuz. Gereksinimlerinizi ve tasarımlarınızı yaratmanız, ürününüzü geliştirmeniz ve gerekirse ürününüzü diğer ürünlerle entegre etmeniz gerekir. Ancak, tüm ürün özellikleriniz için bu adımları bir defada tamamlamak yerine, projeyi “SPRINT”olarak da adlandırılan yinelemelere ayırmalısınız.
NOT: Geleneksel proje yönetim yöntemlerini çevik yaklaşımlarla harmanlamak şu örneğe benzetilebilir: “Porsche 911 Turbo’m var. Ancak, ön sol ve sağ arka tarafta bir yük arabası tekerleği kullanıyorum. Arabamı diğer Porsch’lar kadar hızlı nasıl yapabilirim? ”Cevap, elbette, yapamazsın. Çevik bir yaklaşıma tamamen bağlıysanız, proje başarısında daha iyi bir şansınız olduğunu göreceksiniz.
Yukarıdaki görselde Geleneksel Şelale modeli ve Agile modelin karşılaştırması yapıldı. Başlangıçta ikisi de aynı risk seviyesindeyken ilerleyen proje dönemlerinde Geleneksel Şelale modelinde risk birikimi fazlalaşıyor. Selale modelinde bir işlem basamağında geri gidilemez ve ileri gitmek için o basamaktaki görevin tamamlanması gerekir. Son işlem basamağına kadar ürün ortaya çıkmaz. Agile modelde ise işlemler her sprintte tekrarlanır. Her sprintte bir Demo ürün ortaya çıkar.
Bir yanıt yazın