Tag Archives: Sprint Planing

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

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

Planning Poker

Ç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 Planning Poker(Planlama Pokeri) konusunu anlatacağım. Planning Poker, Ç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. Planning Poker, 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 sözde ç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 biliyor 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 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

Sprint Planlama Toplantısı Nasıl Yapılır? NASIL Bölümü…

Sprint Planlama Toplantısı Nasıl Yapılır? NASIL Bölümü…

 

Sprint Planlama Toplantısı’nın ikinci bölümü olan NASIL kısmında Geliştirme Takımı işin nasıl yapılacağına dair analiz ve tasarım yaptı mı?

Çevik Koçluk yaptığım Scrum Takımlar’ında üyelerin en çok sıkıntı yaşadığı yer Sprint Planlama Toplantısı’nın NASIL bölümüdür. Bu bölümünde gerçekleştirilmesi gereken analiz ve tasarım aktiviteleridir. NASIL bölümde yapılan analiz ve tasarım aktivitesi Geliştirme Takımı üyeleri tarafından gereksiz olarak görülmektedir. Bunun nedeni ise Geliştirme Takımı üyelerinin bunu daha önce denememiş olmalarıdır. Böyle takımlarla karşılaştığımda ilk önerim bebek adımlarıyla ilerlemeliridir. Bebek adımlarından anlaşılması gereken ise Sprint’e aldıkları İş Listesi Maddeleri’nin sadece yarısı ya da üçte biri için bu aktiviteyi gerçekleştirmeye çalışmalarıdır.

 

Toplantının bu bölümü yeni başlayan Scrum Takımları için gerçekten sıkıcı olabilir. 7 Geliştirme Takımı üyesinin 1 Scrum Master ve 1 Ürün Sahibi’nin bulunduğu toplantıda 9 kişinin basit bir İş Listesi Maddesinin nasıl gerçekleştirileceğine dair konuşması sıkıcı ve zaman kaybı olarak görülebilir. Halbuki burada erişilmek istenen nokta konuşulan maddeler hakkında bilgi paylaşımı, yapılan planlamanın herkes tarafından bilinmesi  ve mümkün olduğunca kusursuza yakın bir planlama yapmaktır. İnsanlara bunu göstermenin en iyi yoluysa fazla sıkılmalarını engelleyerek birkaç tane maddenin analiz ve tasarımını yapıp Sprint içinde bu işlerin nasıl ilerlediğini görmelerini sağlamaktır. Seçilen maddelerle ile ilgili gözlemlerin bir sonraki Sprint Retrospektif Toplantsı’nda konuşulması, analiz ve tasarımı yapılan maddeler ile yapılmayan maddelerin geliştirilmesi arasındaki farkların ortaya çıkarılması insanların daha kolay ikna olmasını sağlayacaktır.

Continue reading Sprint Planlama Toplantısı Nasıl Yapılır? NASIL Bölümü…