Bir geminin rotası sefer öncesi kaptanı tarafından planlanır. Bu planda geminin demir atacağı limanlar ve seyahatin son noktası olan hedef liman yer alır. Böyle bir planın oluşturulması görevlerin dağıtımı ve hedefin tayini açısından önem taşımaktadır. Yolculuk esnasında dış etkilerden dolayı rotada değişiklikler meydana gelebilir. Kaptan ulaşmak istediği hedefi bildiği için gerekli değişiklikleri yaparak rotayı hedefe uyumlu hale getirir. Bir projenin gidişatını bir geminin rotasıyla kıyaslayabiliriz. Projeninde bir rotası olmasi gerekir, aksi taktirde hedefe ulaşmak için gerekli çalışmaların nasıl ve hangi zaman biriminde yapılması gerektiği konuşunda yanlış anlaşılmalar oluşur. Projenin rotası proje planında yer alır. Bu makalede
- proje planının ne olduğunu,
- sürüm ve iterasyon planlamasının nasıl yapıldığını,
- sürüm ve iterasyon planlarının online ve offline ortamlarda nasıl tutulduğunu
yakından inceleyeceğiz.
Planlama pokeri oynayan programcılar
Bu yazıyı PDF olarak edinebilirsiniz.
Extreme Programming Bünyesinde Proje Planlaması (691,2 KiB, 7.920 yükleme)
Konuyla İlgili Kitaplar
Merhaba,
Hikaye kartlarındaki Disposition bilgisinin ne işimize yarayacağını biraz daha açabilir misiniz?
Bir diğer sorum da sürüm ve iterasyon planını içeren panodaki tüm hikaye kartları, proje sözleşmesindeki tüm misyonu mu ihtiva ediyor? Şunun için soruyorum; müşterinin katıldığı toplantılarda kendilerinden bu misyon dışında hikayeler geldiğinde bu durum nasıl handle ediliyor? Yoksa yapılan anlaşmalar harcanan saat olarak mı fatura ediliyor?
Teşekkürler
Kolay gelsin.
Disposition XPlanner’e has bir gösterge. Normal kagit üzerinde yazilan kullanici hikaye kartlarinda böyle birsey yer almak zorunda degil. Bu gösterge ile kullanici hikayesinin nereden gelip iterasyona dahil oldugunu belirtilir. Örnegin bazi sartlar altinda bir iterasyonda tüm kullanici hikayeleri implemente edilemeyebilir. Bu durumda implemente edilmeyen kullanici hikayesi bir sonraki iterasyona dahil edilir. Bunu göstermek icin Disposition=Carried Over seklinde tanimlanir.
>Bir diğer sorum da sürüm ve iterasyon planını içeren panodaki tüm hikaye kartları, proje sözleşmesindeki tüm misyonu mu ihtiva ediyor? Şunun için soruyorum; müşterinin katıldığı toplantılarda kendilerinden bu misyon dışında hikayeler geldiğinde bu durum nasıl handle ediliyor?
Proje start aldiginda müsteri tarafindan tanimlanmis tüm kullanici hikayeleri, o projenin vizyonunun %100 tanimladigi anlamina gelmez. Müsteri her iterasyon sonunda olusan sürümü test ederek, yeni gereksinimleri oldugunu kesfedebilir. Bu durumda müsteri yeni kullanici hikayeleri olusturacaktir.
>Yoksa yapılan anlaşmalar harcanan saat olarak mı fatura ediliyor?
Müsteri genelde bir iterasyonda yapilan implementasyon icin ödeme yapar. Örnegin bu iki hafta ise, bu iki hafta icinde yapilan calismalarin bedelidir. Müsterinin yeni gereksinimleri olustukca ve kullanici hikayeleri tanimlandikca iterasyon adedi artacak ve projenin maliyeti de yükselecektir. Bu müsterinin verecegi bir karar. Müsteri ne kadar para ödemek istiyor, bu onun bilecegi birseydir. Müsteri her yeni kullanici hikayesiyle proje süresini uzattigini bildigi icin ya zamanla yeni kullanici hikayeleri olusturmayacaktir ya da bunun bedeline katlanip, her iterasyonun ücretini sirtlanacaktir.
Bu belirli bir bütceye sahip projeler icin tehlikeli bir durum olabilir. Bütcesi belli projelerde, müsterinin proje baslangicinda mümkün mertebe tüm kullanici hikayelerini olusturmasi istenir. Ilerleyen iterasyonlarda müsterinin yeni kullanici hikayeleri olusturmasi, proje maliyet kalkülasyonunu dogrudan etkiler. Bu durumda ya bütce sabit olmamali, ya da müsteri tüm kullanici hikayelerini proje basinda tanimlamali ve her iterasyon sonunda olusan sürümü test ettikten sonra yeni kullanici hikayeleri üretmemeli.
>Yoksa yapılan anlaşmalar harcanan saat olarak mı fatura ediliyor?
Müsteri genelde bir iterasyonda yapilan implementasyon icin ödeme yapar. Örnegin bu iki hafta ise, bu iki hafta icinde yapilan calismalarin bedelidir. Müsterinin yeni gereksinimleri olustukca ve kullanici hikayeleri tanimlandikca iterasyon adedi artacak ve projenin maliyeti de yükselecektir. Bu müsterinin verecegi bir karar. Müsteri ne kadar para ödemek istiyor, bu onun bilecegi birseydir. Müsteri her yeni kullanici hikayesiyle proje süresini uzattigini bildigi icin ya zamanla yeni kullanici hikayeleri olusturmayacaktir ya da bunun bedeline katlanip, her iterasyonun ücretini sirtlanacaktir.
Bu faturalama sekli Agile icin genel bir uygulama mi?
>Bu faturalama sekli Agile icin genel bir uygulama mi?
Iterasyon bazli süreclerde bu sekilde bir faturalandirma modeli uygulanabilir. Ama bu sadece cevik sürecler icin gecerli bir yöntem demek yanlis olur.