Bir tahminde değiştirilmiş veya unutulmuş görevleri nasıl açıklarım?


10

Görev düzeyinde tahminleri ve zaman raporlamayı ele almak için Steve McConnell'in Yazılım Tahmininin 10. Bölümünde açıkladığı tekniği (kabaca) kullanıyorum. Özellikle, görev düzeyinde tahminler oluşturmanın zamanı geldiğinde (kodlama bir projede başlamadan hemen önce), görevleri oldukça ayrıntılı bir düzeyde belirlerim, böylece mümkün olduğunda, tek noktalı, % - güven tahmini dört saatten fazla. Bu şekilde, görev tahmin süreci, tahmin sırasında görevleri unutmamama yardımcı olurken yazılımın oluşturulmasına yardımcı olur. Her görev için de bir dizi saat buluyorum ve McConnell'in tarihsel doğruluk verilerimle birlikte açıkladığı istatistiksel hesaplamaları kullanarak, istendiğinde diğer güven düzeylerinde tahminler oluşturabilirim. Bu yöntemin benim için oldukça iyi çalıştığını hissediyorum. Görevleri ve tahminlerini izleme için TFS'ye koymamız gerekiyor, bu yüzden tahminleri kullanmam gereken güven yüzdesi olarak kullanıyorum.

Bununla birlikte, bir görevi unuttuğumda ne yapacağımdan emin değilim veya sonunda tahmin ettiğim görevlerden birine uygun olmayan bir iş yapmam gerekiyor. Tabii ki, bu durumdan kaçınmaya çalışmak en iyisidir, ancak unutulmuş / değiştirilmiş görevleri nasıl açıklayabilirim? Gelecekteki tahminlerde bana yardımcı olmak için yapabileceğim en iyi geçmiş verisine sahip olmak istiyorum, ancak şu anda, temel olarak sadece% 50 güven tahminini yapıp yapmadığımı ve aralıklı tahmin içinde yapıp yapmadığımı hesaplıyorum.

Gerekirse ne istediğimi açıklığa kavuşturmaktan mutluluk duyarım - neyin belirsiz olduğunu bana bildirin.



Sanırım bu hesaplamaları nasıl yaptığımın yanı sıra çözmeye çalıştığım soruna bir örnek vermem gerekecek. Şu anda vaktim yok, ama elimden geldiği kadar çabuk ulaşacağım.
Andrew

Scrum'da zaman tahminleri vermezsiniz; başkalarına bir fikir veren hikaye noktaları verirsiniz. Ayrıca aşağıdan yukarıya boyutlandırmazsınız. Gerek yok - hız belirsiz bir şey.
İş

@ İş Şu anda bir scrum dükkanı değiliz. Ayrıca, başka bir cevaplayıcının önerdiğinden farklı olarak, şimdiye kadar aşağıdan yukarıya tahminlerin tahmin seviyemi büyük ölçüde, görev düzeyinde tahmin sırasında unutulmuş görevlerin sayısını büyük ölçüde azaltarak geliştirdiğini gördüm.
Andrew

@blueberryfields - en azından birçok hiyerarşik seviyeye sahip bir şirkette, sadece% 50 ile çarpmak yeterli olmalı, her biri kendi fazla tahmin faktörünü ekler.
mouviciel

Yanıtlar:


6

Kitap Waltzing ile Ayılar: Yazılım Projelerinde yönetme Riski (DeMarco ve Lister, Peopleware yazarları tarafından) bu için müthiş bir yaklaşımı vardır. İşte benim yorumum:

"Her şey mükemmel gider" tahmini yapın. Tabii ki, her şey nadiren mükemmel gidiyor, bu yüzden düşük bir olma olasılığı var, yüzde 0.1 diyor. Diğer bir deyişle, binde sadece bir proje mükemmel bir şekilde planlamaya gidecektir. Çoğu insanın "tahmin" olarak kullandıkları şey budur, ki bu deliliktir.

Bunun yerine tahminleri olasılık dağılımları olarak düşünmeliyiz. Bu "mükemmel dünya" tahmini, tahmini olasılık dağılımında en soldaki noktadır.

Daha sonra "böyle şeyler için böyle şeyler yapıldıysa böyle bir şey olursa" tahminini yapın. Bu tahmin , planlama yanlışlığından ( http://wiki.lesswrong.com/wiki/Planning_fallacy ) kaçarak "dış görünümü" ( http://wiki.lesswrong.com/wiki/Outside_view ) almanıza yardımcı olur .

Sonra "X tarafından yapılacak% 90 eminim" tahminini yapın. % 90 emin olduğunuzdan çok, çok emin olun. Diğer bir deyişle, yaptığınız her on proje için bu tahminden yalnızca bir kez daha uzun süre beklersiniz.

Şimdi ilk tahmininizi% 0,1 olasılık tahmini olarak, ikincinizi de% 50 olasılık tahmini (mevsim tadına göre) ve üçüncü tahmininizi% 90 tahmininiz olarak kullanabiliriz, bu da size güzel bir eğri verecektir.

% 0,% 50 ve% 90 tahminlerinizin 1 Mayıs, 1 Haziran ve 1 Ağustos olduğunu varsayalım, o zaman tahmin eğriniz şöyle görünür:

     100 |                                  ......
         |                        ..........
% chance |                ........
of being |          ......
  done   |      ....
         |   ...
         |...
       0 +-----------------------------------------
          \           \           \           \
           May 1st     June 1st    July 1st    August 1st

Olasılıkın büyümesinin zaman içinde nasıl yavaşladığına dikkat edin. Birisi sizden bu senaryoda% 99,9 oranında bir tahmin isterse, gelecek yılın 1 Ocak'ı olabilir.


Cevap için teşekkürler. Kullandığım yöntem zaten teklif ettiğiniz şeyi yapmama izin veriyor, ancak aynı zamanda (dolaylı olarak, tarihsel doğruluk yüzdesini kullanarak) geçmiş başarımı, yüzde- emin tahminler. Bununla birlikte, sorduğum şey, doğruluk temel olarak orijinal tahminim için kullandığım aralık içinde bir görevi bitirip bitirmememe göre hesaplandığında, kaçırılan görevleri bu tarihsel doğruluğa nasıl dahil edeceğidir.
Andrew

@Andrew, sizi doğru anlıyorsam, "kaçırılan görevler" belirli bir zamanda% 100'den daha az bir olasılıkla açıklanır. Mevcut proje gibi çok sayıda proje yaptıysanız, eğriniz hızla% 0'dan (örneğin)% 90'a doğru eğim yapar. Bunun nedeni, az sayıda kaçırılan görev olduğuna dair yüksek bir güvene sahip olmanızdır. Eğer güveniniz düşükse, eğim çok daha kademeli olacaktır. Bu sadece unutulmuş görevler için değil, diğer risk faktörleri için de geçerlidir.
Benji York

Evet, kaçırılan görevler, verdiğim güven düzeylerini belirleyen görev düzeyi aralıklarıyla toplamda ele alınır. Bu seviyeleri McConnell'in daha önce söylediğim gibi Yazılım Tahmini Bölüm 10'da önerdiği bir yöntemi kullanarak hesaplıyorum. Öncelikle TFS saat raporlamasında bu eksik veya değiştirilmiş görevleri nasıl açıkladığımı ve tarihsel doğruluğumu hesaplarken bu saatleri nasıl ekleyeceğimi merak ediyorum.
Andrew

5

Tek kelimeyle - olumsallık.

Beklenmedik durum, "diğer şeyler" için eklediğiniz tutardır - tahmininizde başka bir yerde hesaplayamayacağınız şeyler. SMc bunu Yazılım Tahmininde kapsıyor mu? Hatırlayamıyorum ve kopyam işte (Tatile cevap veriyorum - ne kadar üzüldüm) ...

Her neyse, genel olarak konuşursak, üç tür beklenmedik durum vardır:

1) Riske özgü beklenmedik durum - belirli bir riski tanımladığınız ve bununla ilişkili potansiyel aşımı karşılamak için belirli bir süre eklediğiniz yerdir. Burada anlaşılacak ilk şey, riskin ne olduğudur - bu, kontrolünüz dışında olan projeyi olumsuz yönde etkileyecek, geçebilecek bir şeydir .

Bu son bölüm kritik öneme sahip - sadece "düşündüğümden biraz daha uzun süren şeyler" değil, "bize bir şirket standardı olarak işe koyulmayabileceği için kullanmamız gerektiği söylenen 3. taraf planlama modülü". Eklenecek risk olasılığını ne kadar hesapladığınız, riskin ondalık olarak ifade edilme olasılığının yüzdesidir (yani% 50 = 0,5), bu riskin etkisini katlar (örnekte CRON'u elle yazmanız gerektiğini söyler) zamanlayıcı kullanmak yerine iş ve bu 10 gün sürecek, bu sayı 10 gündür).

Bu nedenle, riskinizin% 50'si geçme şansı varsa ve eğer varsa, tur atmak 10 gün sürecekse, 5 gün eklersiniz. Proje üzerindeki tüm tanımlanmış riskler için tüm değerleri toplayın ve toplamına ekleyin.

2) Kahretsin Durum Olur - Zarif olmasa bile, şimdiye kadar duyduğum en iyi açıklama. Bu bir BT projesi, bok oluyor. Asla nasıl olacağını düşündüğünüz gibi gitmez, işler daha uzun sürer, kaçırılır ve böyle devam eder. Genel olarak SH Beklenmedikliği% 10 (mutlak minimum) ile% 25 (daha yüksek olabilir) arasında olacaktır ve% 15 tipiktir, kesin seviye belirsizlik seviyesine ve genel riske (hareketli kale direkleri, belirsiz gereksinimler vb. ).

PM'niz SH Acil Durumunu kabul etmezse (ve mümkünse, BT projeleri konusunda deneyimi olmayabilir veya kör bir iyimser olabilir), o zaman sadece tüm bireysel tutarlara ekleyin. Ne yaptığını biliyorsa, kendi risk günlüğüne sahip olacak ve sizi bu şeyleri düşündüğünüz için seveceksiniz. Kesinlikle herhangi bir PM kalifikasyonu varsa (PRINCE2 gibi) bunu bilecektir.

3) Değişen Durum - Bu, müşterinin değişiklikleri artıracağından emin olduğunuz yerdir, ancak bunun bir çekişme noktası olmasını istemezsiniz. X gün veya% X ekleyin ve müşterinin yükselttiği değişiklikler için bir pota girer. Bununla başa çıkmanın iki yolu vardır: ya onlara bundan bahsedersiniz ve bu onların harcanmasıdır ya da onlara söylemezsiniz.

İlk yol en iyisidir, ancak oldukça eğitimli ve adil fikirli bir müşteriye ihtiyaç duyar - işler değişiklik olarak sınıflandırılır ve potunu uygun gördüğü gibi harcayabilir (bir şeyi ortaya çıktıkça tahmin etmenize dayanarak).

Bunun bir değişikliğinden bahsetmenizin ikinci yolu, ancak ekstra ücret talep etmeyin. Eğer harcadığınız noktaya ulaşırsa ve müşteriye geri dönüp daha fazla zaman ya da para istemeniz gerekiyorsa "bekle, ben" derler. Blah falan filan ödüyorum "tamamen değiştirmediklerinizin bir işareti olarak ücretlendirmediklerinizi zaten değiştirmiş olduğunuz her şeye işaret edebilirsiniz. Her zaman işe yaramaz, ancak tartışmalarda neredeyse her zaman elinizi güçlendirir.

Bu üçünün hiçbiri özellikle unuttuğunuz şeyleri kapsamaz, ancak aralarında çok fazla boşluk bırakacağınızı düşünüyorum.


Cevabınız için teşekkür ederim. İlginç noktalar ortaya çıkarıyorsunuz. Bu üç öğeyi tahminlerime zaten çeşitli şekillerde dahil ediyorum. Bulduğum ilk tipiniz tipik olarak bir veya daha fazla görevle ilişkilendirilebilir ve ilişkilendirilebilir. İkinci tür sadece görev düzeyi aralığı tahminlerime dahil edildi: Bunun için fazladan bir öğeye sahip olmama izin verilmiyor (tartıştık ve şimdilik bu, ekibimizdeki politika). Üçüncü olarak, dahili müşteriler değişikliklerin tahminimizi artıracağını kabul ederler ve harici müşteriler bunu yazılı olarak yapar, bu nedenle değişiklikleri dikkate almamız gerekmez.
Andrew

McConnell'in beklenmedik durumları kapsayıp kapsamadığına gelince, kopyam da işte, bu yüzden kontrol etmeliyim. Sorduğum şey, bir sonraki tahmini bilgilendirmek için geçmiş verilerini hesaplarken eksik / değiştirilmiş görevleri nasıl hesaplayacağımı ve TFS'de saatlerin nereye atanacağını düşünüyorum, çünkü grubumuzda normal olarak beklenmedik bir göreve izin verilmiyor.
Andrew

0

Bir görev için tahmin istendiğinde, ekibe tahmin verin ve kendiniz için düşük tahmin yapın, böylece görev tamamlandıktan sonra söz etmeyi unutmuş olabileceğiniz bir şey üzerinde çalışmak için her zaman zamanınız olacaktır.


Cevap için teşekkürler. Geldiğim aralıklar, bir bütün olarak, tüm proje için tahminleri kaçırmadan unutulmuş görevleri eklemem için bana yeterince zaman tanıyor. Sorum McConnell kitabından kullandığım hesaplama prosedüründe bu bilgiyi kullanmaktan daha çok bahsediyor.
Andrew

0

Ekstra görevler ekleyerek tarihsel doğruluğunuzu saptıracağınızdan endişe duyuyor musunuz? Yoksa ekstra görevlerin dahil edilmemesinin doğruluğu çarpıtacağını mı düşünüyorsunuz?

Projenin en iyisi için görevlerin izleme sistemine girilmesi gerektiğini düşünüyorum. Eminim proje yöneticisi tutarsızlıklar için yönetime uygun bir açıklama sunacaktır ...


Yarına kadar bekleyebilirim ve bunu bizzat söyleyebilirim. :) Fazladan görevler bir şekilde dahil edilmezse tarihin yanlışlığından daha fazla endişe duyuyorum. Açıkçası, görev tahmini sırasında bir görevi kaçırmak doğrulukla ilgili bir "özledim" dir - ama hangi doğruluk rakamı? Aslında nicel anlamda kullandığım, her görev için gerçek görev performansımın öngörülen aralık içinde olup olmadığıdır. Diğer, daha kalitatif önlem,% 50 kendinden emin tek nokta tahminlerimi ne sıklıkta karşıladığımdır. % 50'nin çok üstünde veya altında ve gelecekteki% 50 tahminler için "uzman kararı" ayarlamalıyım.
Andrew
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.