Bişiy Yaparım ki Ben Bunla?

Bir önce ki yazıma göstermiş olduğun ilgi için teşekkür eder bu gazla ikinci yazıyı yazmaya devam etmeye karar verdim.

İlk yazıya ulaşmak için aşağıdaki linke tıklayabilir yorumlarını paylaşabilirsin 🙂

Kim Bu İş Analisti?

Şimdi nereden devam edelim diye düşündüğümde elimizde bir proje olmalı ki analistliğimizi gösterelim. O zaman gel önce proje nedir? projeler nasıl oluşur nasıl yönetilir bu yazıda ondan bahsedelim.

Bir önce ki yazıda bir projenin başarılı olması için 40% sayısal planlama ise 60% insan faktörü demiştik. Peki Proje dediğimiz şey tam olarak neydi?

• Farklı/benzersiz bir ürün veya hizmet oluşturma amacı olan,
• Tekrar etmeyen, ölçülebilir hedefleri olan,
• Sınırlı kaynakları doğru kullanılabildiği
• Başlangıç ve bitiş tarihleri net olan
• Gerçekçi ve smart hedefleri olan

geçici bir süre içinde başarı hedefi olan bir yol haritasıdır diyebiliriz.

Bir projenin başarılı olduğunu;

• Anlaşılan/Planlanılan zamanda bitirilmesi
• Planlanan bütçeyi aşmaması (+-3%)
• Performans kriterlerinin gerçekleşmesi
• Varolan ve proje özelinde yaratılan kaynakların doğru kullanılması projenin başarılı olduğunu bize gösterir.

Bir projenin yaşam çevrimi aşaması ilk olarak Fikir geliştirme ve bu fikri hayata geçirme ile başlar. Bir fikri hayata geçirmek içinde önce;

• Fikrin tanımı
• Fikrin yapılabilirlik durumu
• Olası sorunlar/Risk haritası
• Bu fikir hangi ihtiyaçları karşılamaya yönelik ortaya çıkışı
• Bu fikir hayata geçtiğinde ne tür beklentilerin olduğu tanımlanmalıdır.

Evet bir fikrin var ve bunu hayata geçirmek için projelendirdin. Şimdi sırada bu projenin başına bir lider eklenmeli ki süreçlerin planlanana göre uygun gidip gitmediğini, olası problemli durumlarda destek olabilecek yeterlilikte birinin bulunması gerekmektedir. Her fikrin sahibi proje lideri olmak zorunda değildir. Planda yapılan içeriği en iyi başlatıp bitirebilecek birinin orada konumlandırılması gerekmektedir.

Bir Proje Liderinden beklenen özellikler ise;

• Evet bir fikrin var ve bunu hayata geçirmek için projelendirdin. Şimdi sırada bu projenin başına bir lider eklenmeli ki süreçlerin planlanana göre uygun gidip gitmediğini, olası problemli durumlarda destek olabilecek yeterlilikte birinin bulunması gerekmektedir. Her fikrin sahibi proje lideri olmak zorunda değildir. Planda yapılan içeriği en iyi başlatıp bitirebilecek birinin orada konumlandırılması gerekmektedir.
• Bir Proje Liderinden beklenen özellikler ise;

Gelen projenin ideal planlama yaparak başlangıç noktasını belirlememiz gerekir. Yapılacak tüm faaliyetleri uygun sıralama ile bölerek her bir parçayı doğru kişileri adreslememiz gerekir. Her bir adımı gerekirse bir gant şablonuna (şekil 1) işleyerek takip edilecek adımları görsel bir şablona da yerleştirmiş oluruz.

Bir proje için hedef bir tarih vermeniz istendiğinde ise aşağıdaki Delphi Tekniğini kullanabilirsiniz.

• ti: en iyi süre
• tk:en kötü süre
• ty: yaklaşık(en olası) süre
• to: ortalama (beklenen)süre

Beta Dağılımı: to=ti+4ty+tk/6

Planlama aşamasında en önemli kalemlerden biri de Maliyet ve Kaynek yönetimi. Projenin başarısı bütçenizin de tutturmak verilen tüm sözler gerçekleşecek şekilde.

Ardından yapılan adımların devamı süreci yürütme ve kontrol aşaması olarak ilerler. Sürecin en uzun ve en civcivli kısmı burasıdır. Hedeflenen performans ve ölçütlerinde kontrol edeceği basamak burası. Olası hataları önceden tespit edip engellemek ve canlıya çıkışta ekstra bir maliyet çıkmaması için önemlidir.

Hep teknik konulardan ve yapılacak iş basamaklarından konuştuk. Peki bu ekiptekiler hiç mi bir biri ile iletişim kurmayacak? Bu noktada çıkabilecek olası çatışmalarda nasıl bir iletişim planı kurgulanmalı gelin bir de ona bakalım.

• Proje Ekibi periyodik toplantılar düzenlemeli ve bunları takvimlemeli
• Ekip üyelerinin iletişim bilgileri ortak alanda ulaşılabilir bir yerde açık tutulmalı
• Standart formlar oluşturulmalı ve herkesin bu formatları kullanması konusunda istekli olunmalı
• Raporlama sistemi yapılan her işlemde net ve şeffaf olmalı
• Projelerin içerisindeki süreçlerde diğer adımlara geçerken kimden/kimlerden onay alınacağı netleşmeli

Projelerin bir sonraki basamakları dahil olan kişilerin motivasyon ve görev dağılımlarını iyi yapmak, zaman yönetimini plan gantta gidişata göre düzenli aralıklar ile güncellemek, Risk yönetiminide zaman planının çıktısına göre haftalık/aylık olarak güncelleyerek gerekirse proje planını yeniden revize etmek gerekir.

Proje yönetimi birer satranç turnuvası olarak düşünebilirsiniz. Günün sonunda projeyi sonlandırdığınızda bir kapanış raporunuzun olması sizin yapılan işteki çıkan tüm çıktıların analiz etmeniz konusunda iyi bir veri olacaktır.

Pekiii şimdi proje ile ilgili kısa bir bilgi verdikten sonra hangi model ile projelerde çalışma yapabiliriz onları inceleyelim.

Yazılım projelerinde sıklıkla 2 tür yöntem kullanılıyor. Biri geleneksel diğeri ise yeni nesil bir model.

• Waterfall Modeli (geleneksel model)
• Agaile (yeni nesil)

Waterfall Modeli

Şelale modeli, yazılım projelerinde uygulanan faaliyetlerin ardışık safhalar halinde icra edildiği, yazılım mühendisliğinin en eski ve temel modelidir. Günümüzde hükümetler ve büyük şirketler tarafından her türlü projenin yönetim standardı olarak kabul görmektedir.

Şekil 2 de de görüleceği gibi her adım bir sonrakinin girdisi-çıktısı ilişkisi var. Bir basamak tamamlanmadan diğer adımlara ilerlenemiyor. Waterfall modelinin faydalarını şu şekilde belirtebiliriz:

• Projenin başlangıcında gereksinimlerin açık, anlaşılır ve tam olarak tanımlanması, daha doğru zaman ve maliyet tahmini yapılmasını sağlayarak projedeki belirsizlikleri azaltır.
• Kimin ne zaman ne yapması gerektiği katı bir şekilde tanımlandığı ve takip edildiği için kendi başına iş yapma yeterliliği ve tecrübesi olmayan proje elemanları, proje yöneticileri ve performansı iniş çıkışlı proje ekipleri için idealdir.
• Dokümantasyonun devamlı bir faaliyet olması proje sonunda dokümantasyon maksadıyla geçmişe dönme emeğini engellediği gibi projenin her hangi bir zamanında dokümantasyonun mevcut duruma göre tam olmasını sağlar ve bu dokümantasyon üzerinden projenin mevcut halinin değerlendirilebilmesine imkân verir.
• Şelale modeli disiplinli ve istikrarlı bir modeldir ve proje elemanlarına projenin iyi bir şekilde yönetildiği ve her şeyin kontrol altında olduğu hissiyatını verir.
• Fonksiyonel organizasyonlarda birden fazla projede görev alan proje elemanlarının işlerinin üst üste binmesini engeller. Örneğin analiz çalışması tamamlandıktan sonra başka bir projede görev almaya devam eden bir elemanı geri dönüşü gerekmez.

gibi bir çok madde sıralanabilir. Kısıtlarını incelemek gerekirsede;

• Değişiklik, geliştirme veya düzeltme maksatlı geriye dönüşler şelalede akıntıya karşı yüzmeye benzetilir, zor ve maliyetlidir. Bu yüzden değişikliklere cevap veremez ve süreç içerisinde gelen istekler çoğunlukla kabul edilmez.
• Herhangi bir safhada tespit edilmemiş bir olumsuzluk sonraki bütün safhaları etkiler.
• Gereksinimlerin proje başında tam ve anlaşılır bir şekilde tanımlanmasının beklenmesi çok gerçekçi olmayabilir ve müşterilerin ihtiyaçlarını tam ve doğru ifade edememesi proje sonunda eksik veya yanlış bir ürün elde edilmesine neden olabilir.
• Geliştiricilerin gereksinimleri müşteri veya kullanıcılarla yüz yüze görüşerek anlamaları yerine analiz ve tasarım safhalarında hazırlanan dokümanlardan okumaları, gereksinimlerin anlaşılmasını zorlaştırır, geliştiricilerin girdi yapmasına imkân vermez.
• Yazılı sistem tanımlamalarının kullanıcı veya müşteriler tarafından okunarak tam olarak anlaşılması ve uygulanması zordur.
• Bir safhanın tamamlanmadan sonraki safhanın başlamaması nedeniyle, tüm proje elemanlarını ilgilendirmeyen gecikmeler dahi bütün proje elemanları için zaman israfına neden olabilir.
• Yüksek yönetim giderleri küçük projeler ve küçük takımlar için gereksiz maliyetlerdir.
• Yazılım geliştirme faaliyetleri yaratıcılık gerektiren faaliyetlerdir ve şelale modelinin yüksek disiplinli yaklaşımı yaratıcılığı olumsuz etkiler.

Çevik Metodoloji

Çevik yazılım geliştirme, kendi kendini organize eden takımlar tarafından, son derece işbirlikçi bir anlayışla, “yeteri kadar” resmiyet içeren etkili bir yönetişim çerçevesinde, zamanında, uygun maliyetli ve paydaşların değişen ihtiyaçlarını karşılayan yüksek kalitede çözümler üreten yinelemeli ve artımlı (evrimsel) bir yaklaşımdır.

AgileTurkey tarafından yayınlanan Türkiye Çeviklik Raporuna göre de incelenen organizasyonların %72‟si çevik yöntemleri kullanmaktadır.

Çevik yöntemlerde yazılım geliştirme faaliyetleri yinelemeli safhalar halinde uygulanır. Bu yinelemeler sonucunda kullanılabilir ürün ortaya çıkarılır ve müşteri veya kullanıcıların geri beslemeleri ışığında ve varsa değişen gereksinimler doğrultusunda geliştirme süreçleri tekrarlanır. Bu yinelemeli süreçler müşterinin tam olarak istediği ürün ortaya çıkana kadar sürdürülür. Çevik yöntemlerde uygulanan safhalar Şekil 4’te gösterilmiştir.

Agile Metodolojisinin Faydalarını incelediğimizde;

• Ekip ruhu kazandırır.
• Artan müşteri memnuniyeti
• Çalışanlara değer verir.
• Aktif geri bildirim ile yeniden çalışmayı ortadan kaldırır.
• Değişen gereksinimler için esneklik imkanı

Dezavantajını incelediğimizde;

• Kurumsal bir yapıda uygulamak ciddi anlamda zordur.
• Hedefler kısa süreli olduğu için ekip üzerinde oluşabilecek sonuç baskısı
• Ürün gereksinimleri sürekli değiştiği için maliyetler peşinen tahmin edilemez.
• Kısa süreli geri bildirimden dolayı çalışma sürelerinin artması

Başlıca çevik metodolojilere ait kullanım oranları Şekil 5′ de sunulmuştur. Gerek dünya genelinde gerekse Türkiye‟de en popüler metodoloji Scrum olmakla birlikte XP ve Kanban diğer metodolojilere göre öne çıkmaktadır. Scrum yönteminin Kanban ve XP ile beraber kullanıldığı ve organizasyonların kendi ihtiyaçlarına göre uyarladığı karma metodolojiler de çevik yöntemlerin başlıca kullanım şekillerindendir.

Projelerin başarı oranları uygulanan metodolojiye göre de farklılık göstermektedir. 2011–2015 yılları arasında 10000‟in üzerinde yazılım projesinde, uygulanan metodolojiye göre elde edilen başarı oranları Şekil 6′ da sunulmuştur. Elde edilen veriler ışığında çevik yöntemlerin başarı oranlarının şelale modelinin başarı oranlarının yaklaşık 4 katı, başarısızlık oranlarının ise 3‟te 1‟i olduğu görülmektedir. Buna rağmen çevik yöntemlerin başarı ihtimalinin şelale modeline göre her zaman daha fazla olacağı söylenemez. Proje başarısı için proje şartlarına uygun metodoloji seçilmelidir.

Son olarak bu yazımı bitirmeden önce size ufak bir ödev bırakıcam bir sonraki yazım bu sorunun cevabı ile başlayacak ama öncesinde bana cevabı iletmek isterseniz serapgur169@gmail.com mail adresine yazabilirsiniz. Hazırsanız soruya geçiyorum.

Ödev1: Gıda sektörü için mobil uygulama tasarlayacaksınız ve bu mobil uygulamanın proje basamakları ve hangi metodolojiyi kullanacağınız ile alakalı 300 kelimeyi geçmeyen bir yazı hazırlayabilir misiniz?

Bir sonraki yazıya kadar…

Kaynak: “Yazılım Proje Yönetimi:Şelale Modeli ve Çevik Yöntemlerin Karşılaştırılması” tezinden faydanılmıştır.