Tag Archives: Product Backlog

Çevik Yaklaşımlarda İşin Maliyetini Belirleme 3

Çevik Yaklaşımlarda İşin Maliyetini Belirleme 3

Poker Planlama

Çevik yaklaşımlarda işin maliyetini belirleme konulu yazı serisinin üçüncü bölümünde Scrum, eXtreme Programming ve Kanban takımlarında kullanılan Poker Planlama konusunu anlatacağım. Poker Planlama, Çevik Bildiri’ye imza atan 17 kişiden biri olan James Grenning tarafından geliştirilmiştir. Bir eXtreme Programming tekniğidir. Scrum uygulayanlar tarafından faydalı bulunup Sprint ve Release planlamasında kullanılmaktadır. Poker Planlama, uzman görüşünü, benzeşimi –karşılaştırmayı- ve küçük parçalara bölmeyi eğlenceli bir şekilde bir araya getirmiştir.

 

Continue reading Çevik Yaklaşımlarda İşin Maliyetini Belirleme 3

Çevik Yaklaşımlarda İşin Maliyetini Belirleme 2

Çevik Yaklaşımlarda İşin Maliyetini Belirleme

Maliyet Belirleme Teknikleri

Çevik Yaklaşımlarda İşin Maliyetini Belirleme yazı serisinin bu bölümünde farklı maliyet belirleme tekniklerine değineceğim. Bu teknikler, uzman görüşü, benzeşim(karşılaştırma), küçük parçalara bölme teknikleridir. Yapılan araştırmalardan ve araştırmaların sonuçlarından bahsedeceğim.

Uzman Görüşü

Uzman görüşüyle anlatılmak istenen yıllarca çalışarak elde edilen tecrübeden kaynaklanan uzmanlık değildir. İşi geliştiren kişinin uzmanlığıdır. Yazı serisinin ilk bölümündeki örneği hatırlarsanız, evet takım lideri, geliştiriciden çok daha tecrübeli biri fakat geliştirici, geliştirdiği konuyla ilgili yaşanan sıkıntıları, karşılaşılabilecek problemleri, önüne çıkabilecek engelleri en iyi bilen kişidir. Kendi hızını da en iyi geliştirici bilir dolayısıyla doğruya en yakın tahmini yapabilecek uzman kişi işi yapan kişidir.

Benzeşim

Diğer bir yaklaşım ise benzeşim ya da karşılaştırma da diyebileceğimiz tekniktir. Bu teknikte tahmini yapacak kişi kullanıcı hikayelerini karşılaştırarak şunu söyler:

Continue reading Çevik Yaklaşımlarda İşin Maliyetini Belirleme 2

Çevik Yaklaşımlarda İşin Maliyetini Belirleme

Çevik Yaklaşımlarda İşin Maliyetini Belirleme

İki Aziz Nesin Hikayesi

Bu yazı dizisinde Çevik Yaklaşımlarda İşin Maliyetini Belirleme konusunu ele alacağım. Geliştirilecek bir işlevselliğin veya bir projenin maliyetinin belirlenmesi(yapılacak işin büyüklüğünü belirleme) işinin nasıl gerçekleştirilebileceğine, iyi pratiklere, maliyet vermenin maliyetine, tahmin işinin ne kadar gerekli olduğuna değineceğiz. Ayrıca geleneksel proje yönetimini kullanan organizasyonlarda karşılaştığım birkaç örneği paylaşacağım.

İşlevselliklerin ya da projelerin maliyeti belirlenirken birkaç yaklaşım dikkatimi çeker.

  1. Üst yönetim bunun için herhangi bir bitiş tarihi belirledi mi? Sanki üst yönetimdeki kişiler bu projeyi geliştirecek! Tarihi bu kişiler belirlerse işi gerçekleştiren kişiler daha hızlı üretme yetkinliğine kavuşacak gibi-evet, evet…pazara çıkış zamanı vb. şeyleri aklınıza getirdiğinizi biliyorum-… Belki tarih belirlenebilir fakat takımdaki kişilerin görüşleri alındıktan sonra gerçekçi bir tahmin yapılarak.
  2. Teknik lider ya da mimar olan kişilerden işin büyüklüğü bilgisi istenir. Araştırılmadan ve tahmin yapabilecek kadar bilgi sahibi olunmadan bu soruya cevaplar dönülür.

Aziz Nesin hikayesi olabileceğini düşündüğüm birkaç örneği paylaşmak istiyorum.

Continue reading Çevik Yaklaşımlarda İşin Maliyetini Belirleme

Yazılım Projelerinde Gecikmenin Maliyeti

Yazılım Projelerinde Gecikmenin Maliyeti

Üretim ortamında bulunmayan kodlardan değer üretemezsiniz. Bu kadar vurucu bir cümleyle yazıya giriş yapmam okuyanların konunun önemini anlamalarına yardımcı olmak içindir.  İşlerinizi önceliklendirirken pazara çıkış zamanıyla elde edeceğiniz kazanç, yasal zorunluluk, iş değeri gibi kavramlardan yararlanabilirsiniz. Bunların yanında dikkate almanız gereken diğer bir konuysa Gecikmenin Maliyeti’dir. Gecikmenin maliyeti, bir özelliği üretim ortamına almayı geciktirerek kaybedilecek değerdir.

 

Gecikmenin maliyeti işlerin önceliklendirilmesinde nasıl bir öneme sahip? Gecikmenin maliyetini nasıl hesaplayabiliriz? Farklı senaryolar üzerinden şimdi görelim.

Continue reading Yazılım Projelerinde Gecikmenin Maliyeti

Yazılım Projelerinde Karar Almada Ortamın Önemi

Yazılım Projelerinde Karar Almada Ortamın Önemi

Bu yazıma bugün yaşadığım ilginç bir deneyimi anlatarak başlamak istiyorum. Bugün izlediğim bir futbol maçında dikkatimi çeken bir forvet oyuncusu bulunuyordu. Bu oyuncu takımının yakaladığı fırsatları bir bir harcadı. Kale önünde, altı pas içinde topu kaleciye nişanladı, çektiği şutlar defans oyuncularına çarptı, verdiği paslar arkadaşlarına ulaşmadan rakipler tarafından kapıldı. Maçın bir bölümünde rakip takım korner kullandı. Kornerden dönen top, kornerin kullanıldığı köşeye geri dönerken bizim ünlü forvetimiz rakip takımdan birini takip ediyordu. O anda bu topun dönüp gol olacağını düşündüm. Çünkü bu adam tam bir başarısızlık abidesiydi ve ne yapsa takımına negatif bir şekilde geri dönüyordu. Eminim demek istemiyorum ama rakibi takip etmese ve rakip boş bir pozisyonda orta yapsa o top bence gol olmayacaktı. Bu topun gol olması rakibin şansı bizim forvetimizin şanssızlığı değildi. Buna eminim. Bizim forvetimiz dışarıdan bakıldığından elinden geleni yapıyor, çok çalışıyor, canını dişine takmış ve herşeyini veriyor gibi görünüyor. Tek birşey dışında bunları yaparken doğru yolu izlemiyor. Çünkü doğru kararlar veremiyor. Dahil olduğu her pozisyonda işleri daha da karışık hale getiriyor ve bunun sonucu da takımına olumsuz olarak geri dönüyor.

Bunları neden anlattım. Çünkü yazılım projelerinde görev alanlarda bu yaklaşımı sergiliyor. Tabi kişinin sahip olduğu role göre yaptığı etkide ortamda farklı oranda değişikliklere neden oluyor. Örneğin bir futbolcu hata yaptığında bu çok önemli olmayabilir ve hatadan geri dönülebilir. Hatalı bir pas verip topu rakibe kaptırabilirsiniz. Biraz sonra topu rakipten geri alabilirsiniz ve bu çok büyük bir sorun olmayabilir. Bu tıpkı bir yazılımcının test senaryoları üzerinden geçerken birini atlaması gibi geliyor. Fakat teknik direktör maçı kaybederken ve gol atması gerekirken bir forvet çıkarıp bir savunma oyuncusu alıyorsa çok ciddi sıkıntılar var demektir. Bırakın oyunu okumayı bu teknik direktör skor tabelasını bile okuyamıyor diye düşünebiliriz. Aynı şekilde bir projenin planlamasında yada ilerlemesinden sorumlu kişilerin aldığı aksiyonlarda böyledir. Bazen hepimizin içinden geçiyordur. Bu adam ne yaptığını bilmiyor dediğiniz olmuştur. Örneğin beş altı ay sonra geliştirilecek bir proje için gerekli bilgilerin şimdiden toplanması yada bir projede çalışacak kişilerin projenin geliştirilmesi için gerekli olan teknik ve ortam bilgilerinden eksik olması gibi. Continue reading Yazılım Projelerinde Karar Almada Ortamın Önemi