Etiket arşivi: Product Backlog

Poker Planlama

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.

Poker Planlama yazısına devam et

Çevik Yaklaşımlarda Maliyet

Çevik Yaklaşımlarda Maliyet

Çevik Yaklaşımlarda Maliyet 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üşü

Çevik Yaklaşımlarda Maliyet belirleme tekniklerinden biir uzman görüşüdür. Bununla anlatılmak istenen yıllarını ofiste geçirerek elde edilen tecrübeden kaynaklanan sözde uzmanlık değildir. İşi geliştiren kişinin uzmanlığıdır. Yazı serisinin ilk bölümündeki örneği hatırlayın. 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:

– A kullanıcı hikayesi B kullanıcı hikayesinden biraz daha büyüktür.

Çevik Yaklaşımlarda Maliyet yazısına devam et

Yazılımda Maliyet Belirleme

Yazılımda Maliyet Belirleme

Bu yazı dizisinde “Yazılımda Maliyet 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 verme işinin maliyetine, tahmin işinin ne kadar gerekli ya da gereksiz 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ç örnek

Yazılımda Maliyet Belirleme yazısına devam et

Gecikmenin Maliyeti

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 maliyeti nasıl hesaplanır? Farklı senaryolar üzerinden şimdi görelim. Gecikmenin Maliyeti yazısına devam et

Karar Almada Ortamın Önemi

Karar Almada Ortamın Önemi

Bu makalede karar almada ortamın önemini anlatacağım. 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 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 karmaşı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 benzer 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ırabilir. Biraz sonra topu rakipten geri alabilir 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. 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 diyebiliriz. Bir projenin planlamasında ya da ilerlemesinden sorumlu kişilerin aldığı aksiyonlarda benzerdir. Bu adam ne yaptığını bilmiyor dediğiniz olmuştur. Karar Almada Ortamın Önemi yazısına devam et