Zaman tahminine kimler katılmalı?

Bir BT projesinde:

1. Zaman tahminine kimler katılmalı ? Geliştirici, takım lideri, scrum ustası vb.
2. En çok kimin oyu sayılmalıdır?

Bu, dahil olan insanlar hakkında mevcut olması gereken beceriler kadar değil:

• Sorunlu alanın iyi anlaşılması - bu, gereksinimler belirsiz veya yüksek düzeyde olduğunda özellikle önemlidir. Uçakta bilet sınıflarıyla ilgili işi tahmin etmek için daha önce hiç seyahat etmeyen bir programcı olarak ve 3 veya 4 (ekonomi, iş, önce vb.) onlarca var. Bu, bir İş Analisti veya uzman kullanıcının dahil olduğu anlamına gelebilir, ancak zamanla geliştiricilerin kendileri bu tür bilgileri oluşturacaktır.

• Teknolojiyi ve dahil edilecek işi anlamak - genellikle ekibin güvenine sahip son deneyime sahip bir yönetici olsa da bir işveren genellikle işi yapabilir. İdeal olarak, işi gerçekten bu şekilde yapacak olan kişiyi tahmine alınıyor olsanız da.

• Tahmin sürecinin anlaşılması - bu anahtardır. İyi bir tahminin nasıl yapılacağını, doğru olmasını nasıl sağlayacağınızı, uygun acil durum seviyelerini kontrol etmeyi, çift saymayı veya çok fazla dolguyu kontrol etmeyi anlamalıdır. Genellikle bir PM, geliştirme yöneticisi veya kıdemli geliştirici bunu getirecektir, ancak bazı süreçlerde sağlam bir tahmin şablonu gerekli rehberliği sağlayabilir.

Bu beceriler bir kişide olabilir, ancak bazen üç veya daha fazlasına ihtiyaç duyabilirler, ancak kilit nokta, bu becerilerin mevcut olduğundan emin olmaktır, belirli insanların mevcut olmadığından emin olmaktır.

Bununla birlikte, genellikle iki veya daha fazla insanın birbirlerini kontrol etmesini sağlayan ek bir güvence istediğinden, ikiden fazla insanı arayacağım.

Oyları en çok sayılanlar açısından böyle çalışmaz. Bu bir tartışma ve bir müzakere. Bir yönetici, geliştiricilerin tahmininin çok yüksek olduğunu düşünüyorsa, geliştiriciyi gerekçelendirmek için neden baskı yapması gerektiğini (baskı değil) ve bir fikir birliğine varmaları gerektiğini açıklamalıdır. Bu anlaşmaya varamazsanız deneyimden iki şey söyleyebilirim:

(a) "İstediğin" sayı ile gitme, sadece sorun istiyor ve ne istediğin işin ne kadar çabuk yapılabileceği üzerinde önemli bir etkisi yok.

(b) Bir geliştiricinin bir tahminde aşırı yönetildiği yerlerde gördüğüm hemen hemen her durumda, son sayı, geliştiricinin onları yöneten herkesten daha fazla düşündüğüne yaklaştı - büyük ölçüde (a) noktasını göz ardı ettikleri için yukarıda.

(Agile inanıyorum ki ve kesinlikle XP'de kural, geliştiricilerin tahminleri kontrol etmesi ve bu nihai. Kullanıcılar tahminleri düşürmek isterse daha basit bir şey için gereksinimi değiştirmek zorundalar.)

Bu soruya herkese uyan tek bir cevap olup olmadığını bilmiyorum. Çalıştığım yerde, genellikle bir tahmin sağlayan özelliği / düzeltmeyi uygulayacak ekipten iki mühendis var. Yani iki mühendis bir "min", "max" ve "beklenen" tahmin sağlar. Genellikle her iki tahminin de makul düzeyde tutarlı olmasını bekleriz, bu yüzden çılgınca farklıysa, daha fazla tartışma gerekebilir (belki bir mühendis diğerinin yapmadığı varsayımlarını yapmıştı, vb.).

Bizim durumumuzda, hiç kimsenin “oyu” sayılmaz. Tipik olarak iki tahminin ortalamasını alıyoruz (eğer zaten aynı balo parkında değilse, ikisini de reddediyoruz ve tartışmalara tekrar başlıyoruz, bu yüzden ortalamayı almak büyük bir sıçrama değil). Tahminler yalnızca tahminlerdir, bu yüzden kesin olmaları gerekmez .

Deneyimlerime göre, tahminler, görevi büyük olasılıkla yapacak kişi tarafından yapılma eğilimindedir. SCRUM ekipleri çapraz fonksiyonel olmak için çaba göstermelidir, ancak bir süre sonra belirli görevler genellikle aynı kişiler tarafından yapılır.

Hayati öneme sahip olan, tüm tahminlerde takımdan kabul görmek. Bir geliştirici bir tahmine sahip olduğunu düşünüyorsa, bunu karşılamak için çalışacaktır. Geliştiriciler, kendilerinin yapmadıklarını ve üzerinde herhangi bir girdi veya etkiye sahip olmadıklarını belirlerse, aynı sorumluluk düzeyini hissetmeyecekler ve kredili mevduat hesapları "Sana daha uzun süreceğini söyledim" ile açıklanacaktır.

Bir projenin yukarıdan aşağıya doğru iş gereksinimleri ve süreleri vardır. Bunlar ilk iterasyon için "tahminler" dir.

Bu gereksinimler,% 100 bilinen maliyeti olan en büyük görevlere bölünmelidir ("günlüğe kaydetmeyi etkinleştir" = 2 saat = " log4j / SLF4J'yi indir ve tak" gibi).

Tahmin, zaten yeterli teknik uzmanlığa sahip olan mümkün olan en yüksek seviyede yapılmalıdır.

Düzeltilmiş tahminler, işletme sahibine uygun bir seviyede ulaşana, gereksinimleri düşürebilen / değiştirebilen veya son başvuru tarihlerini gevşetene kadar "iş görünür özelliği" = "bu süre" şeklinde geri gitmelidir. Sonra geri çekilin. Nihai yakınsamaya kadar. Pratikte, insanlar bu aşamayı görmezden gelme veya basitleştirme eğilimindedir, bu da kaçırılan son tarihler ve fırsatlarla ilişkili riskler oluşturabilir.

Zaman tahminine kimler veya kim katılmalıdır? Geliştirici, takım lideri, scrum ustası vb.

Zaman tahmininde hepsinin orada olmasını tercih ederim ve burada da aynısını yapıyoruz

En çok kim veya kimin oyu sayılmalıdır?

Geliştirici ama yine de yine takım çalışmasıyla ilgili

GELİŞTİRİCİLER PROJEYİ UYGULAMAK İÇİN ÜCRETLİDİR! HİÇ KİMSE!

İş üzerinde gerçek eller yapan geliştiriciler ve geliştirme ekibi liderleri, gerçekten ne kadar zaman alacağını doğru bir şekilde tahmin edebilen tek kişilerdir. Yalnızca gerçek kod tabanına aşina olan programcılar, geliştirme sürecinde karşılaşılabilecek olası zorlukları ve tuzakları anlayabilir. Diğer herkes bir 'seyirci'.

Buna ek olarak, geliştiricilere doğru tahminler vermek için güvenilebilecek tek yol, iş adamlarının kendilerine güvenmesi ve uzmanların, tahminleri işletmenin beklentilerini karşılamadığı takdirde cezalandırılmayacaklarını bilmeleri için uzmanlıklarına güvenmeleri.

Temel kural: Herhangi bir proje yöneticisinin veya iş insanının, ellerin geliştirme konusundaki zorluklarına ve söz konusu kod tabanına aşina olmadığı en az 3 kat sürecektir.

Yaklaşık 20 yıldır hem geliştirmede hem de büyük şirketlerde çalışan olarak çalışan biri olarak, bunu son derece kesin bir şekilde ve çok acı bir deneyimin yararı ile söylüyorum.