5 Ağustos 2015 Çarşamba

Yazılım projelerinde dikkat edilmesi gereken 5 risk noktası

Tom DeMarco ve Timothy Lister’ın yazdığı Waltzing With Bears: Managing Risk on Software Projects (Ayılarla dans/vals) kitabını okumanızı tavsiye ederim.  Kitap içerisinde  aklımda kalan en önemli sözlerden bir tanesi şöyle  :
Riskini yönetmezsen krizi yönetmek zorunda kalırsın
Bu noktaya katılmamak sanırım mümkün değil. Kitap içerisinde dikkatimi çeken diğer bir nokta ise yazılım projelerinde dikkat edilmesi gereken en önemli 5 risk noktası konusu oldu, bu noktaları özetlersem :
  1. Proje zamanlama hatası (inherent schedule flaw)
  2. Gereksiz fazla gereksinim kabusu (requirement inflation)
  3. Çalışanlar işten ayrılması (employee turnover)
  4. Belirtimlerin analizinde oluşan ölümcül hatalar (Specification breakdown)
  5. Verimsizlik (poor productivity)
İşte detaylar :

Proje zamanama hatası (inherent schedule flaw)

waste-01Proje ne zaman biter ?  Bu cevaplaması en zor sorulardan bir tanesidir.  Eğer bu sorunun cevabı mevsimsel veya müşterinin istediğine göre verilirse proje zamanlama hatası oluşmuş olur.
Mevsimsel proje bitim süreleri vermek ülkemizde çok meşhurdur. Örneğin kış aylarındaysak, ilkbahara doğru proje bitsin diye anlamsız  tahminlemeler ne yazık ki olmaktadır.
Müşteri baskısıyla oluşan proje zamanlama hatasında bir o kadar ölümcüldür. Kitap içinden bir örnek çok çarpıcıdır . Hikaye şöyledir :
Projenin sahibi olan zat gelir ve IT ekibine projeye 2 ay geç başladıkları için çatar ve der ki : Her geçen ay 110.000 dolar kaybediyorum.  Projeye acil başlamanız ve şu zamanda bitirmeniz gerekir diye.
Bunun üzerine Tom DeMarco (kitabın yazarından birisi) şöyle der : Eğer projeyi 1 ay önce teslim etseydik 110.000 dolar kazancın mı olacaktı ? Projenin sahibi olan zat “evet” der.
Peki der  Tom DeMarco ve ekler :  Projeyi 10 ay önce sana teslim etseydik 110.000 dolar x 10 ay = 1.100.000 dolar mı kar edecektin diye sorusunu derinleştirir. Projenin sahibi olan zat biraz afallar ama yine tavrını bozmaz “evet” der.
Tom DeMarco, projenin sahibi olan zata döner ve  son vuruşu yapar : Kusura bakmayın projenin IT yazılım ekibine  gelene kadar zaten epey bir gecikmiş. Eğer proje bize 18 ay önce gelseydi şu an çoktan bitmişti.
Proje tahminleme hatasının üstesinden gelebilmek için Kanban yöntemi ile birlikte öne çıkan Little’s Law, Lead time distribution ve Monte Carlo yöntemleri tercih edilmesinde fayda olduğunu düşünüyorum. Her şeyden önce bilimsel ilerlemek zorundayız. Tahminlerimizi gerçekçi ve bilimsel bir temele oturtmadığımız sürece, proje takımlarının üzerinden zaman baskısını kaldırmamız imkansızdır.
Gereksiz fazla gereksinim kabusu (requirement inflation)

  • waste-01
    Pareto ilkesi  %80 – %20 kuralını söyler. Yani Pareto ilkesini yazılım projeleri üzerine uygularsak, kullanılan özellik oranı %20’dir. Yani %80 kullanılMayan isteklerle dolu olduğunu görürüz.
    Bu riski azalmanın yollarından biri Lean startup yaklaşımını kullanmak olabilir. Kullanılabilir en küçük ürün  –  minimum viable product (MVP)  yaklaşımı bizi bu israftan (muda) kurtarabilir.
    • Çalışanlar işten ayrılması (employee turnover)

    waste-03
    Bu riski sıfıra indirmek imkansızdır. Google için bile çalışanların işten ayrılması en büyük sorunlardan bir tanesidir.  Bu riski azaltmak için bilginin tek kişide toplanmasını olabildiğince azaltmak gerekir.
    Kritik bilgi seviyesinde olan çalışanlar için bilgilerini videoya ders anlatır gibi son derece görsel bir şekilde aktarmaları son derece iyi bir yol olduğunu düşünüyorum. Ayrıca şirket için bilgi havuzları oluşturularak, bu havuzun güncelliği ve senkronizasyonu kontrol edilmesinde fayda vardır.
    • Belirtimlerin analizinde oluşan ölümcül hatalar (Specification breakdown)

    oh-no
    Bu çok enteresan bir risk türüdür.  Belirtimlerin analizinde oluşan ölümcül hatalarda (Specification breakdown) proje bir anda sona erer.  Misketlerini al ve git durumu.   Bu risk eğer şelale (waterfall) türü bir metodoloji ile ilerleniyorsa başınıza gelebilir.
    Örneğin gereksinimleri aldınız ve projeye başladınız. 6 ay sonra proje tamam dediniz ama bir baktınız ki müşterinin sunucuları hep Linux, siz ise uygulamayı .NET ‘de geliştirmiştiniz. Kuralları gereği de Windows sunucusu kullanmak yasak. Buyrun buradan yakın. Çevik süreçlerde bu tür bir riskin gerçekleşmesi çok düşük bir olasılıktır.
    • Verimsizlik (poor productivity)

    productivity
    Verimsizlik (Muda)  üstesinden gelinmesi gereken en önemli risklerden bir tanesidir. Çevik süreçler bu riskin üstesinden gelmek için iyi bir yöntemmiş gibi gözükse de, verimsizliliğin kaynağı çok daha derinlerde olabilir.  Bu derinlikte problemlere salt çevik yöntemlerle uygulayarak başarılı olmak zordur.  Çevik (Agile) yöntemlerin yalın (Lean) düşünceyle uygulanmasında son derece fayda vardır.
    En iyi Agile (çevik) yaklaşımı olan Kanban metoduyla verimi ölçmek için öncelikle müşterinin gözünden bakmak şarttır. Müşteri gözünden en önemli KPI nedir ? Tabii ki ürünün teslim süresi (Lead Time).
    Şöyle düşünün, acil kahve içmeniz gerekiyor, dükkana girdiniz ve siparişi beklemeye başladınız ve kahve bir türlü gelmiyor. Geçen süre artık (Lead Time) artık canınıza tak ettiğinde kasiyere sebebini sorarsınız.
    Yazılım projeleri de çok farklı değil, müşteri siparişi en kısa sürede görmek ister bu yüzden Kanban metodunda dikkate alınan ve takip edilen en önemli gösterge işin teslim süresidir (Lead time) .
    Bu risklere karşı önlem almak ümidiyle, sevgiler.
Share this post
  • Share to Facebook
  • Share to Twitter
  • Share to Google+
  • Share to Stumble Upon
  • Share to Evernote
  • Share to Blogger
  • Share to Email
  • Share to Yahoo Messenger
  • More...

0 yorum

:) :-) :)) =)) :( :-( :(( :d :-d @-) :p :o :>) (o) [-( :-? (p) :-s (m) 8-) :-t :-b b-( :-# =p~ :-$ (b) (f) x-) (k) (h) (c) cheer

 
© 2013 Saygınlık Bilgelikte Gizlidir
Designed by Blog Thiet Ke
Posts RSSComments RSS
Yukarı