Keşif Tahmini için Çevik Elektronik Tabloları Kullanma

Bu makale, Çevik keşif tahminleri geliştirmenize yardımcı olacak önceden biçimlendirilmiş bir elektronik tablo içerir. Ayrıca, öne çıkan örnekle birlikte izlemenize yardımcı olacak bilgileri de içerir. Buradaki şablondan düzenlenebilir bir kopya oluşturabilirsiniz (Dosya>Kopya oluştur veya Dosya>İndir).

Müşteriler genellikle bir ekibim olmadan veya MVP gereksinimlerini bilmeden önce Çevik tahminler sağlamamı ister. Bu erken aşamada, bu tahminleri hesaplamak için hız, sprint sayısı veya takım maliyeti gibi geleneksel metriklere erişimim yok. Ama müşteriler cevap istiyor. Varsayımsal bir ürünü iki veya altı ayda piyasaya sürebilirler mi? (Genellikle düşük) bütçeleri için mümkün olacak mı?

Çevik elektronik tabloya girin.

Elektronik tablolar, Çevik bir zihniyet için uygun ancak çoğu zaman gözden kaçan bir seçimdir. İşbirliğini teşvik eden düşük teknolojili, yüksek temaslı araçlardır. Bununla birlikte, ürün maliyeti ve kalitesi gereksinimlerini karşıladığı sürece, müşteriniz muhtemelen aletlerinizin "Çevik onaylı" olup olmadığını umursamıyor. Elektronik tabloların gerçek değeri, proje yöneticilerine ve tüm deneyim seviyelerindeki paydaşlara erişilebilirliklerinde yatmaktadır.

Birçok özel proje yönetimi aracı, hızlı hareket eden projelerde deneyimsiz kullanıcılar için çok dik olan öğrenme eğrilerine sahiptir. Müşteriler, ürün sahipleri ve geliştiriciler için gereksinimleri ve işçilik maliyetlerini güncellemek ne kadar kolay olursa, gerçekçi bir tahmine o kadar çabuk ulaşırsınız. Proje yöneticileri, önceden biçimlendirilmiş bir elektronik tabloyla, her dalgalanan kaynağın veya değişen zaman çizelgesinin etkilerini göstermek için değerleri ve parametreleri ayarlayabilir.

E-tablolar ayrıca bilginizi iş arkadaşlarınızla paylaşmanın harika bir yoludur. Kullandığım elektronik tablo bir Toptal meslektaşına aitti ve o zamandan beri bir kopyasını çıkardım ve ihtiyaçlarıma uyacak şekilde değiştirdim. Sizi de bunu yapmaya teşvik ediyorum.

Bu makalede, müşterileri ve paydaşları proje hedeflerine uyum sağlamaya ve geliştirmeye devam etmeye yetki veren başarılı keşif tahminlerinin nasıl sunulacağını gösteriyorum. Boşlukları nasıl dolduracağınız ve arkasında durabileceğiniz erken aşamadaki bir tahmini nasıl sunacağınız aşağıda açıklanmıştır.

Önce Ürün Vizyonunu ve Yol Haritasını Ele Alın

Müşterinizin sabit bir bütçeyle bir flört sitesi geliştirmek istediğini, ancak ürünün ayrıntılarının belirsiz olduğunu varsayalım. Ekip maliyetini ve hızını bilmeden, ürün vizyonu başlamak için en iyi yerdir çünkü paydaşların bir tasarım hedefi üzerinde anlaşmasını gerektirir ve ekip genelinde şeffaflığı teşvik eder.

Sezgisel anlatım tarzı için Scrum.org ürün vizyonu formatını seviyorum. İşte nasıl göründüğü:

Ürün vizyonu belirlendikten sonra, müşteriye uzun vadeli proje takvimi hakkında bir fikir vermek için Ürün Yol Haritasını yeni bir elektronik tablo sekmesine ekleyebilirsiniz. Yol haritası, her bir ürün yol haritası sürümü için hedefleri, temel özellikleri ve son tarihleri ​​listelemelidir.

Yol haritası sürümleri, bir ürünün pazar yörüngesine rehberlik eden planlı, tüketiciye veya müşteriye yönelik sürümleridir. İlk yol haritası sürümü, piyasaya sürebileceğiniz üründür. Müteakip yol haritası sürümleri, ürün vizyonuyla uyumlu, ilgi uyandıran yeni özelliklerle pazar sürümlerini temsil eder.

Microsoft'u örnek olarak kullanmak gerekirse: Windows 8 muhtemelen bir yol haritası sürümüydü. Windows 10, birçok yeni ve arzu edilen özellik içeren başka bir yol haritası sürümüydü.

Ürün vizyonu ve yol haritası tamamlandıktan sonra, müşteriden bir MVP'ye karar vermesini isteme zamanıdır.

MVP Özelliklerini Üçlü Kısıtlama Tablosu ile Pazarlık Edin

Bu, Üçlü Kısıtlama tablosunu kullanarak müşterinizin beklentilerini zaman ve masraf açısından şekillendirmenin tam zamanı:

Şelale yaklaşımında, sabit özellikler zaman ve maliyeti belirler ve geliştirme, ayrıntılı bir proje planına göre ilerler. Tersine, Agile'ın sabit maliyetleri ve programı, ürünün özelliklerini belirler ve bu özellikler, daha esnek proje vizyonuna dayalı olarak sürekli olarak yeniden önceliklendirilir.

Üçlü Kısıtlama tablosu, müşteriye, istenen tüm özelliklerin ilk sürümde dahil edilmesinin geliştirme süresini ve balon maliyetlerini artıracağını gösterir. Bunun yerine, bir MVP için yalnızca "olması gereken" özellikleri seçmek için müşteriyle birlikte çalışın ve gelecekteki sürümler için kalan özellikleri tablolayın.

Elektronik tablolar, müşterinin değişen ihtiyaçlarına göre özellikleri gruplamayı ve farklı sürümlere, yayınlara ve önceliklere yeniden atamayı kolaylaştırır ve bu değişikliklerin maliyetlerini anında görüntüler.

MVP özelliklerini belirlerken, üzerinde çalıştıkları benzer projelere dayalı olarak proje adımlarını listelemek için konu uzmanlarınızdan (KOBİ'ler) yardım isteyin. Bu adımları daha sonra destanlar oluşturmak için kullanacaksınız. Bu girdileri hazır hale getirdikten sonra bir tahmin oluşturmaya başlayabilirsiniz.

Tişört Beden Ölçüsüyle Başlayın

İlk biriktirme listesine başlamak için, ürün sahibinden ürünün özelliklerinin ayrıntılı bir açıklamasını isteyin, ardından zorluk düzeyine göre her bir özelliğe bir tişört boyutu atayın.

Tişört boyutlandırma, herhangi bir mutlak değer elde etmeden önce her geliştirme görevinin göreceli karmaşıklığını ve süresini gösterecektir. Proje planlamasında ilerledikçe, bu göreceli boyutları hikaye noktalarına ve çalışma saatlerine dönüştüreceğiz.

Örneğin, müşteriniz flört sitesinde bir dizi açılır pencere geliştirmenizi istiyorsa, bu zaman alıcı ancak basit olacaktır. Bu görev karmaşıklığını “Küçük” olarak nitelendirebilirsiniz, ancak çaba “Orta” olacaktır. Bunu “SM” olarak kısaltabilirsiniz. Öte yandan, yeni bir API için arka uç bağlantısı geliştirmek, gerekli tüm belgeler ve testler nedeniyle daha karmaşık bir görev olacaktır. Bunun için gereken beceri ve dikkat, onu hem çaba hem de beceri düzeyinde “Büyük” yapabilir: “LL”.

Tişört bedenlendirmeyi bitirdikten sonra, gelecekteki her ekip üyesi için göreceli iş yükü ve beceri gereksinimleri hakkında bir fikir edineceksiniz. Geliştirme ekibinden bir teknik uzman, daha sonra tişört beden ölçünüzü saat aralıkları ve hikaye puanlarıyla ilişkilendirmenize yardımcı olabilir.

Parametrelerinizi Ayarlayın

Artık e-tablonuzu çalıştırmaya ve tahmininizi hesaplamaya hazırsınız. Bir Parametreler sekmesi oluşturarak başlayın. Bu, hesaplamalarınız için anahtar görevi görecek ve buraya girdiğiniz değerler, İş Listesi/Kullanıcı Öyküleri ve Sürüme Göre Tahmin Özeti sekmelerinizde kullanılan formülleri besleyecektir.

Parametreler sekmenizde ihtiyacınız olacak her şey:

Para birimi. Para birimi dönüştürmelerini girdiğiniz yer burasıdır. Örneğin, müşterinin bütçesi Brezilya reali ise, dolar veya euro için geçerli dönüşüm oranını girebilirsiniz.

Başlangıç ​​tarihi. Beklenen geliştirme başlangıç ​​tarihi, bir proje zaman çizelgesi oluşturmak için kullanılacaktır. Her örnekte, başlangıç ​​tarihimiz 25 Ekim'dir.

Başlangıç ​​Bütçesi. Bütçe, MVP özelliklerinin tümünün bütçeye sığıp sığmayacağını gösteren kısıtlamalar sağlar.

Tişört Boyutlandırma. Tişört bedenlerinizi tablo olarak girin ve her beden kombinasyonuna hikaye puanları ve saat aralığı atayın. Bu örnekte, bir SS için bir ila iki saat ve bir LL için 33 ila 48 saat kullanıyoruz.

Sprint sürenizin maksimum T-shirt bedeninizin saatlerini sınırlayacağını unutmayın. Sprint sadece bir hafta ise, en büyük boyut 40 saati aşamaz. Bu nedenle, görevlere tişört bedenleri atanırken bir KOBİ'ye danışmak çok önemlidir .

Saat Başına Ücretler. Her rol için ödeme oranlarını belgelemek için bu tabloyu kullanın. Arka uç geliştiricilerinizin farklı oranları varsa, ikisinin ortalamasını kullanın.

havai. Durum toplantıları, geri bildirim oturumları ve proje revizyonları gibi idari görevlere toplam proje çabasının bir yüzdesini ayırın. Yüzde on (veya her katılımcının çalışma haftasının dört saati) başlamak için iyi bir yerdir, ancak daha karmaşık projeler için ek yük daha yüksek olabilir.

Acil durum. Bu, tahmininizdeki potansiyel varyansı gösterir. %0'lık bir olasılık ile başlamak, e-tabloya girdiğiniz değerler göz önüne alındığında size en iyi senaryoyu (yani, olası olmayan) bütçeyi ve zaman çizelgesini gösterecektir. Örneğimizde daha sonra, olası yüksek maliyetleri ve proje süresini göstermek için beklenmedikliği kaba bir büyüklük sırasına (ROM) %50'lik bir varyansa yükselteceğiz. Daha kesin sayılar elde ettikçe beklenmedik durum daralacaktır.

Epics ile Her Sürümü Boyutlandırın

Müşterinin zamanını veya parasını boşa harcamadığımızdan emin olmak için tüm ürünün kaba bir boyutlandırılmasıyla başlıyoruz. Boyutlandırmanın önerilen bütçeye ve son tarihe ne kadar yakın olduğuna bağlı olarak, müşteri projeden vazgeçmeye veya daha ayrıntılı tahminlere yatırım yapmaya karar verebilir. Bu noktada fazla detaya sahip olmadığımız için Backlog/User Stories sekmesinde ana özellikleri destanlar olarak giriyoruz. Ardından, her bir destan için, Parametreler sekmesindeki T-shirt beden tablosuna dayalı olarak KOBİ'lerin ve kalkınma liderlerinin her bir geliştirme yığını için önerdiği saat sayısını giriyoruz.

İlk önce “EPIC?” sütununu seçin. ve yalnızca “Epik” seçili olduğundan emin olun.

Ardından, epik açıklamayı yazın ve geliştirme yığınının her bir sütunu için saat sayısını girin. Örneğin, epik "Güvenli Bağlantı ve Giriş", yaklaşık sekiz saat kullanıcı arayüzü geliştirme, arka uç için 40 saat vb. sürecektir.

Çoğu durumda, "Nokta" sütunundaki hücrelerin "34*" gösterdiğine dikkat edin. Parametreler sekmesine geri dönerseniz, 34 puanın 33 ile 48 saat arasında bir saatlik aralığa karşılık geldiğini göreceksiniz. Sprint süremiz sadece bir hafta ise, bu saat sayısı çok fazla.

Daha fazla ayrıntıya sahip olduğumuzda, bu saatlerin kısaltılması gerekecek veya destanların daha yönetilebilir hikayelere bölünmesi gerekecek. Ancak zaman kazanmak adına Puanlar sütununu görmezden geleceğiz ve kaba tahminle devam edeceğiz.

Şimdi Yayına Göre Özeti Tahmin Et sekmesine gidin. E-tablonun üst kısmında, Parametreler sekmesinde tanımlandığı gibi "Genel Yük" ve "Olağanüstü Durum" değerlerini göreceksiniz. Destanlara veya kullanıcı hikayelerine göre tahminleri göstermek için seçebileceğiniz bir düğme de vardır.

Henüz görüntülenecek kullanıcı hikayemiz olmadığı için “Epik Mod” düğmesini kontrol edin.

Artık MVP'nin kaba maliyetini ve zaman çizelgelerini ve gelecekteki sürümlerde (R3 ve R4) daha az acil olan özellikleri ve güncellemeleri görebilirsiniz. Bu örnekte, müşteri tüm MVP destanlarının ilk sürümde başlatılmasını talep ettiğinden ikinci sürüm (R2) boştur.

Artık en iyimser toplam maliyeti görebilirsiniz: 28.810 dolar. Bu rakam, MVP'den R4'e kadar her sürümün maliyetinin toplamıdır.

Ayrıca, R4 geliştirme yığınındaki en son tamamlanma tarihine karşılık gelen, ürün teslimatı için en kısa zaman çizelgesine ilişkin bir tahminimiz var. Proje yöneticileri, tüm sürümün hızını dikte ettikleri için bu daha yavaş geliştirme yığınlarını "kritik yollar" olarak adlandırır.

Bu durumda kritik yol, tamamlanma tarihi 31 Ocak olan ön uç geliştirmedir.

Şimdi en kötü durum bütçesini ve en uzun zaman çizelgesini simüle etmek için parametreleri ayarlama zamanı.

Acil Durumu %50'ye ayarlayın

Ürün için çaba ve uzmanlık gereksinimleri hakkında hala nispeten az şey biliyoruz, bu nedenle Parametreler sekmesinde %50'lik bir ROM olasılığı ekleyeceğiz. Proje hakkında daha fazla ayrıntı öğrendikçe beklenmedik durum azalacaktır.

Yine, burada %0 beklenmedik durumda toplam proje tahmini var.

Ve burada %50 beklenmedik durumda.

Bu, tüm proje için ROM tahmininin 28.810 dolar ile 41.860 dolar arasında olduğu anlamına gelir. En iyi ve en kötü durumda, müşterinin 20.000$'lık bütçesi, tüm özellikleri istek listelerine eklemek için yeterli olmayacaktır.

%50 beklenmedik durumdaki tam proje tamamlanma tarihi şimdi %0 beklenmedik tamamlama tarihinden altı hafta sonra 14 Mart'a düşüyor.

Bu arada, MVP 10 Ocak'ta hazır olacak.

Müşteri, projeden vazgeçmek yerine, daha kısa bir zaman çizelgesinde hedef bütçesine daha yakın olup olmayacağını görmek için daha ayrıntılı bir tahmin talep eder.

Son Teslim Tarihlerini Karşılamak için Yeniden Önceliklendirin

Müşterinin MVP için 25 Ekim başlangıcından iki ay sonra 25 Aralık olarak bir hedef tarih belirlediğini varsayalım.

Mevcut 10 Ocak MVP tamamlanma tarihini yükseltmek için müşteri, iki MVP destanını bir sonraki sürüme (R2) kadar ertelemeyi kabul etti.

Elektronik tablo, bu ayarlamanın kademeli etkisini hesaplar. Bu durumda, MVP zaman çizelgesi 27 Aralık'a kadar kısalır. Ön ve arka uç geliştirme, bu simülasyondaki kritik yollardır, çünkü bunların tamamlanması en uzun sürer.

Bu bilgilere dayanarak, ön ve arka uç tamamlama tarihlerini diğer geliştirme yığınlarıyla uyumlu hale getirmek için iki geliştirici daha eklemeye karar verebilirsiniz. Bunu yapmak için, MVP “Haftada saat” satırındaki saatleri 40'tan 80'e yükseltin.

Hem ön hem de arka uç geliştirme yığınları artık Kasım'da bitiyor ve QA yeni kritik yol haline geliyor (20 Aralık'ta tamamlanma tarihi ile). Maliyetin değişmediğini unutmayın. Bunun nedeni, her yığındaki toplam çalışma saatlerinin aynı kalmasıdır. Bir geliştirici iki hafta (80 saat) yerine iki geliştirici bir hafta (80 saat) çalışıyor.

Elektronik tablo aynı zamanda tam ve yarı zamanlı çalışma arasındaki farkları da açıklar. UI geliştiricisinin yarı zamanlı çalışacağını varsayalım. Teslimattaki gecikmeyi simüle etmek için "Haftalık Tasarım Saatleri" kullanıcı arayüzünü 20 olarak değiştirebiliriz.

Tam zamanlı bir programda, UX/UI 29 Kasım'da tamamlanacak.

Yarı zamanlı bir programda, UX/UI 27 Aralık'ta tamamlanacak.

Bir kez daha, maliyet değişmez, ancak UX/UI yeni kritik yol haline gelir ve MVP'nin zaman çizelgesini 27 Aralık'a uzatır.

Kaynaklarınız ve müşterinin son teslim tarihi göz önüne alındığında, kabul edilebilir bir kritik yola ulaşana kadar bu deneme yanılma yaklaşımına devam edebilirsiniz. Uygun bir son tarih belirlendiğinde, tahmininizde ince ayar yapmaya başlamanın zamanı geldi.

Kullanıcı Hikayeleri ile Tahmininizi İyileştirin

%50 beklenmedik durum tahmini müşterinin bütçesinin dışında kaldığından, beklenmedik durumu azaltabilmeniz ve daha gerçekçi bir tahmin elde edebilmeniz için değişkenlerinizi iyileştirmeye değer.

Bunu yapmak için, destanlarınızı ayrıntılı kullanıcı hikayelerine bölmek için geliştiricileriniz ve KOBİ'lerinizle birlikte çalışın. Hikayeler destanlardan daha iyi tanımlanır, böylece onları daha doğru bir şekilde boyutlandırabiliriz.

Ardından, yeni bilgilere göre Parametreler sekmenizdeki değerleri ayarlayın. Örneğin, KOBİ'leriniz ve geliştirme ekibiniz her bir rol için daha doğru oranlara sahip olabilir ve ayrıca tişört bedenlerini ve puan atamalarını ayarlamak isteyebilir. Bu yeni parametrelerle, hesaplamalarınıza daha fazla güvenebilir ve beklenmedik durumu %25'e düşürebilirsiniz.

Destanları nasıl daha küçük ve daha ayrıntılı kullanıcı hikayelerine ayırdığımıza bakalım:

Her yığın için tahmini saatlerin manuel olarak girilmesini gerektiren epik tahminden farklı olarak, hikaye tahmini, kısayol olarak T-shirt boyutlandırmasını kullanır. Parametreler sekmesinde girdiğiniz tişört bedenlerinin işe yaradığı yer burasıdır.

İş Listesi/Kullanıcı Hikayeleri sekmesindeki "Tişört Boyutlandırma" altında, geliştiricilerinizin ve KOBİ'lerinizin her hikaye için yığınlarına atadıkları beden kombinasyonunu girin. Buradan, elektronik tablo formülü, Parametreler sekmesinden karşılık gelen saatleri otomatik olarak dolduracaktır. En büyük boyut olan LL'nin, üzerinde anlaşılan sprint süreniz içinde tamamlanabilmesi için 34 puanın altında kalması gerektiğini unutmayın. Hala 34 puan veya daha yüksek puan alan tüm hikayelerin alt bölümlere ayrılması gerekecektir.

Tüm hikayelere 34'ten az puan atandığından emin olduktan sonra, yalnızca “Hikaye”yi görüntülemek için Yayına Göre Özet Tahmini sekmesindeki “Epik Mod” düğmesinin işaretini kaldırın.

Şimdi yeni bir sayı kümesi göreceksiniz:

Tüm görevleri detaylandırdıktan ve yalnızca MVP özelliklerine bağlı kaldıktan sonra, zaman çizelgesi ve maliyet artık müşterinin gereksinimleriyle eşleşiyor. Bakiye bütçeleri dahilinde olduğundan, müşteri MVP ile devam etmeye ve ek sürümler için taahhütte bulunmadan önce test etmeye karar verir.

senin yap

E-tabloların kullanımı kolaydır ve bazı temel formül bilgileriyle (makro gerekmez), bunları hemen hemen her ihtiyaca uyarlayabilirsiniz. Excel bilginiz yetersizse Udemy ve edX'teki çevrimiçi kurslar bu becerileri tazelemenize yardımcı olacaktır.

Bu makale keşif tahminini ele aldı, ancak aynı elektronik tabloyu, biten/burndown çizelgeleri oluşturmak, zaman çizelgelerini ayarlamak ve daha sonraki aşamalar için hız ve sprintlere dayalı tahminleri hesaplamak için kullanabilirsiniz. Jira, Asana ve Trello gibi uygulamaları tamamlamak için özelleştirilmiş elektronik tablolarımı kullanıyorum ve bunların proje yönetimi kitimde güçlü bir araç olduklarını savunuyorum. Umarım sizin için aynı derecede yararlı ve çok yönlü olduklarını kanıtlarlar.

Hazır proje yönetimi araçlarına özel elektronik tabloları mı tercih edersiniz? Yorumlarda neden veya neden olmadığını bize bildirin.