Biletler için zaman tahminleri oluştururken, test kullanıcıları (QA) için geçen süre bir bilet tahmininin içine dahil edilmelidir mi? Daha önce testçilerin zamanı olmadan her zaman tahmin etmiştik, ancak her zaman bunu dahil etmekten bahsediyoruz. Yayınlanmadan önceki son sprint için mantıklıdır, çünkü biletlerin toplam süresinin bir hafta süreceğini bilmemiz gerekir.

Tahminlerin sadece geliştirici zamanı için olduğunu anladım, çünkü bu takımlardaki sınırlayıcı kaynak olma eğilimindedir. Bir meslektaşım, test zamanından önce çalıştıkları her yere de dahil edildiğini söylüyor.

Açıkçası, bu, geliştiricilerin iyi bir kapsama alanı ile birim, entegrasyon ve UI testleri yazdığı bir süreç içindir.

Tavsiyem: Bilete test süresini dahil ediyor veya test görevinin kendisini temsil etmek için bir bilet ekliyorsunuz. Başka herhangi bir yaklaşım, gereken gerçek işi hafife almanıza neden olur.

Geliştirici zamanı genellikle bir darboğaz olsa da, deneyimlerime göre, testte kısıtlanan birçok takım var. Sınırlayıcı kaynağın kanıt olmadan bir veya diğeri olduğunu varsayarsak, sizi ısırır.

İş arkadaşınız olarak, test süresini dikkate almayan başarılı bir organizasyon görmedim.

Açıklamanıza göre zeyilname: Devs otomatik testler, özellikle birim testler (entegrasyon testleri daha iyi sonuç verir) yazsa bile, uygun şekilde test etmek için yetersizdir.

İlgili KG çalışanları varsa, zamanlarının şu ya da bu şekilde tahmin edilmesi gerekir. Yalnızca KG çalışanlarını bordrodan çıkarmaya karar verirseniz, çalışma süreleri etkili bir şekilde ortadan kalktı ve tahmini olarak kaldırabilirsiniz. Ancak bunun göz ardı edilmesi kolay yan etkileri olacaktır. Yine de performans, stres, güvenlik ve kabul testlerini kaçırıyor olabilirsiniz.

Kesinlikle, Evet

Test geliştirme sürecinin bir parçasıdır. Ekibiniz yazılımı test etmek için gerçekten zaman harcıyorsa, test için harcanan zamanın tahminin bir parçası olması gerekir.

Bu çevikse, test çalışmasını toplam hikaye noktalarının bir parçası olarak dahil edeceğim. Örneğin, dev çaba belki 1 gün ve 1 gün test böylece 2 puanlık bir hikaye olacaktır.

Yapılan tanımınızın ne olduğuna bağlıdır, ancak genellikle geliştirmesi tamamlanır, iş kabulü ve test yinelemede çıkar. DoD sadece iş kabulü ise, test çabalarının hikaye noktalarına dahil edilmesi gerekmez, ancak yine de izlenmelidir.

Tahmin, biletin tamamlanması için gereken tüm çalışmaları dikkate almalıdır. Test, biletin gerekli bir parçasıysa, tahmine dahil edilmelidir. Test ayrı bir bilet ise, o zaman olmamalıdır.

Tabii ki, hikaye noktalarını kullanmaya başladığınızda tüm bulanıklaşabilir, çünkü sadece dev-5 ve dev-8 arasındaki fark, bir dev-ve-QA 8 ile bir dev-ve-QA 5 ile oldukça orantılı olacaktır.

Test cihazı zaman işlerini de dahil gördüm. Ayrı hikayelerin işe yaradığını gördüm. Her biri onları çalıştıran grup tarafından tahmin edilen ayrı görevler gördüm. Sizin için mantıklı olanı yapın, sonuçta süreç size hizmet etmek için orada, tersi değil.

Buna güçlü bir şekilde cevap verememeniz, tahminleri neden yazdığınızı bilmediğinizi gösterir (veya en azından meslektaşınıza neden tahminler yazdığınıza katılmıyorsunuz). Bu, tahminlerin testi içermesi gerekip gerekmediğinden daha büyük bir sorundur.

Tahminleri neden yazdığınızı öğrenin veya anlaşmaya varın. Belirli bir takımın belirli bir zamanda ne başaracağını tahmin etmek gerekirse, cevap basitçe tahmin ettiğiniz takımın testi yapıp yapmamasına bağlıdır. KG ekibiniz ayrıysa ve kendi planlamasına sahipse, belirli bir bilet üzerinde kendilerinden (geliştiriciler) ne kadar test süresi gerektiğini düşündüğünüzü bilmek isteyebilirler. Sayılarınızı görmezden gelebilir ve kendi numaralarını girebilirler. Her iki şekilde de bunu dev zaman tahminlerinden ayrı olarak izleyebilirler.

Diğer taraftan, eğer bir takım tüm geliştiricileri, testleri ve KG'yi yapıyorsa ve zaman tahminlerinin amacı, ekibin belirli bir zaman diliminde ne yaptığını tahmin etmek ve planlamaksa , elbette zaman tahminleri şunları içermelidir KG, belirtilen hedefe ulaşmak için bu ekibin yapması gereken diğer görevlerle birlikte. Bu nedenle, her bilet için bir başlangıç ​​toplantısı yapmanız veya tamamlandığında bir miktar evrak doldurmanız gerekiyorsa, yöneticinin zamanının orada bir yerde olması gerekir . Sadece görmezden gelemezsin.

Eğer hepsi bir takım ama ayrı rolleri olan "geliştiriciler" ve "testçiler" ise, bu, bölmenin yalnızca bir tarafının üzerinde çalışabileceği çok sayıda biletiniz olduğu ve (belki de tamamen varsayımsal) Gantt grafiğinizin göründüğü anlamına gelebilir tıpkı iki ayrı takımın tablosu gibi görünecekti. Bu gerçek, bazı metodolojileri diğerlerinden daha fazla üzecek ve bu nedenle planlamayı bölmekten daha iyi olabilirsiniz, ancak bölmezseniz, ekibin yapması gereken her şeyi biletlemeniz ve tahmin etmeniz gerekir veya tahminleriniz umutsuz olacaktır .

Tahminlerin amacı tahmin ve planlamadan başka bir şeyse, örneğin "çünkü onları içeren boş bir ritüeli akılsızca takip ediyoruz" veya "yönetim onları fazla mesai yapmak için bizi bir sopa olarak kullandığından", veya "sabit fiyatlı bir teklif yapmak zorunda olduğumuz ve rakamlar muazzam bir formüle girdiğinden" (teşekkürler John Wu), o zaman ne içermeleri gerektiğini anlamak daha zor olabilir ;-)

Bir kullanıcı hikayesi / özellik / biletin gerçekten yapılması için yapılması gereken tüm işleri daima tahmin edin. Biz buna DoneDone diyoruz .

Üretime hazır olduğumuzda işimiz bitti .

Bu, manuel ve keşif testlerini, hatta kullanıcı kabul testlerini de içerir.

Bir Agile ekibi her an bitmiş işin yeni bir bölümünü serbest bırakabilmelidir. Gibi:

Çalışan yazılım ilerlemenin birincil ölçüsüdür.

Test etmediyseniz, işe yarayıp yaramadığını nasıl anlarsınız? Şimdi geliştirme zamanının zamanınızın darboğazı olduğunu yazıyorsunuz. KG mühendisi olarak çoğu takımın test kapasitesinde darboğazları olduğunu ya da sadece kısa yollar aldıklarını düşünüyorum.

Uzun bir hikaye kısaltmak için, test çabalarını da tahmin edin. Bu akılda Keep your etkileyebilecek hızı . Hikaye puanlarında göreli tahminler yapıyorsanız, test zaten ortalama hızınıza dahil edilmiş olabilir.

İşte çok önemli bir şey: Tüm tahminlere varsayımlar ve istisnalar eşlik etmelidir .

Bu, nelerin dahil edildiğini belirtmeyi içerir: yalnızca geliştirme, tasarım ve geliştirme, geliştirici ve birim testi, kabul testinin kapsamı, altyapının oluşturulması vb.

Bir proje yöneticisine bir tahmin belgesi sağlıyorsanız, bu belgeyi bir müşteri veya PMO için bir iş emri veya iş beyanına dönüştüreceklerdir . Onlar olabilir havai eklemek için deneyim sözleşme veya kümesi tarafından belirlenir (örneğin, bazı projeler daha sonra kapak yönetim ve proje yönetimi Y% ekleyin QA kapsayacak şekilde% X ekleyebilirsiniz) set formülleri var. Ve çift saymak istemiyorsun. Öte yandan, bunları otomatik olarak eklemeyebilirler.

Uygulamalar farklıdır. Bu sayıları kullananların sayıların ne anlama geldiğini bilmesi gerekir ve test süresini dahil edip etmediğiniz konusunda açık olmalısınız.

Zaman tahminine dahil edilmelidir ama sen bunun yerine, test zamanı tahmin olmamalı test zamanlarını tahmin etmelidir .

Test süresini dahil etmemek, alacağı toplam sürenin yanlış bir tahmindir, ancak geliştirici süresi ve test cihazı süresi birbirinin yerine kullanılamaz (en azından test cihazlarıyla paralel olarak çalıştığınız için, arkasında bir yineleme olduğu için) ayrı ayrı tahmin etmelisiniz. Dahası, test uzmanlarının herhangi bir değişikliği test etmeleri gereken zamanı tahmin edebilecek durumda değilsiniz, sadece test ekibinin kendisi bunu yapmalıdır.

kapsülleme

Buna yazılım geliştirme açısından ve dilden yaklaşacağım.

• Büyük bir makinede küçük bir dişli vardır.
• Ekibinizin dışından, biletleme sisteminiz ekibinize bir arayüz / API işlevi görür
• Biletleme sistemini kullanan işletme kullanıcıları geliştirici değildir

İyi yazılım tasarımından, mümkün olduğunca basitleştirmeli ve kapsüllemelisiniz.

Sürece İş Kullanıcıları açısından bakmak gerekirse, gerçekten sadece 2 şeyi önemsiyorlar.

1. Kaça mal olacak?
2. Hala bitirmedik mi?

İş Kullanıcısına ekibinizin dahili süreci hakkında bilgi vermek kötü yönetimdir; publiciçsel duruma erişmeye benzer .

Ekibinizin dahili durumunu korumamanız, diğer ekipleri kaynaklarınızı yönetmeye ve dahili durumunuzla uğraşmaya davet ediyor.