Çevik sürümümüz çalışmıyor. İpuçları?


12

4 geliştiriciden oluşan küçük bir ekip üzerinde çalışıyorum. Her hafta bize sürekli olarak aynı zorlukları sağlayan bir Agile sürümünü uyguluyoruz ve sürecimizi geliştirmemize yardımcı olacak öneriler arıyorum.

Arkaplan:

Genellikle 2 haftalık sprintler yapıyoruz ve her sprint çalışmamızı hafife alıyoruz ve programımızın arkasında olduğumuz için yöneticimizle sorun yaşıyoruz.

Her sprint'e yöneticimizin bizim için yarattığı hikayeleri anlatarak başlıyoruz. Bazen görevlere de girer ve onları tahmin ederiz. Hikaye puanı kullanmıyoruz. Urban Turtle yazılımını, esasen sadece hikayeler ve görevler olan “sprintlerimizi yönetmek” için kullanıyoruz ve bunlarla ilgili yanıklar. Sprint sonunda serbest bırakmayı planlamıyoruz.

Ortaya çıkan en yaygın sorun, bir sprint başlangıcında bir görev için sadece kapsamının çok daha büyük olduğunu, ancak yine de önceliğin yüksek olduğunu keşfetmek için plan yapmamızdır, bu yüzden üzerinde daha fazla çalışma yapmamız gerekiyor. İkinci en yaygın sorun, birimizin yakılan saatleri yavaşlatan ve birlikte gösterime neden olan teknik bir sorunla karşılaşmasıdır.

Bize sunulan tek öneri, tahminlerimizi ayarlama ve sabah standupları sırasında güncelleme sağlama konusunda daha proaktif olmaktır, böylece ihtiyaç duyulan ekstra süreyi ayarlayabiliriz.

Ancak, bir şeyleri yapma şeklimizde temelde yanlış bir şey var gibi görünüyor. Belki de proje düzeyindeki yöneticinin beklentileri ile sprint düzeyindeki beklentiler arasında bir kopukluk vardır. Çünkü bu sprint tekrarlarını bir proje planına göre yapıyoruz ve bu nedenle bir sprint'i genişletmek veya öğeleri ertelemek proje planını bozuyor. Geliştiriciler olarak, gerektiğinde tahminleri uzatarak Agile gerçekleştirmeye teşvik ediyoruz, ancak aynı zamanda sprint'i zamanında tamamlıyoruz, bu da kafa karıştırıcı.

Bu alışılmadık bir sorun olamaz, bu yüzden bu sprint her sprint aynı sorunla çalışmayı nasıl durdurabilirim hakkında bir veya iki öneri var daha akıllı umuyorum. Sinir bozucu.


8
hikayelere ve görevlere% 100 zaman ayırmayın, belki sadece% 80 zaman? Ve her şeyi bitirirseniz (olası olmayan sesler) biriktirme listesinden başka bir hikaye getirin mi? Veya tahminleriniz için bir çarpan mı oluşturuyorsunuz (sayınız * 2)?
Kevin

1
Teşekkürler, çarpanın daha az kapsamla birlikte iyi bir fikir olduğunu düşünüyorum.

Kevin ile aynı fikirdeyim. Bir tahmin vermek zorunda olduğunuz ve hiçbir fikriniz olmadığı bir senaryo için bir tane yapın ve sonra iki katına çıkın ve iyi bir ölçüm için biraz daha ekleyin. 8 saat derseniz, 16'ya iki katına çıkacağım ve muhtemelen 20'ye
yuvarlayacağım

3
Şelaleye geçin. Şelale, yanlış tahminler ve aşırı sıkı programlar ile çok daha iyi çalışır. (Bu cevap verilemez çünkü kaçınılmaz downvotes bana yaklaşık 0.025 itibar puan mal olacak)
user281377

1
Bir sprint'te kaç hikaye yapılacağını nasıl seçiyorsun?
jk.

Yanıtlar:


20

çünkü programın gerisindeyiz

Bu tür düşünme sizin probleminizdir. Programın gerisinde değilsin, program çok sıkı. Hikayeleri saatlerin aksine soyut noktalarda tahmin etmeye başlamalı ve 2-3 iterasyon boyunca hızınızı anlamanız gerekir. Hızınız, yöneticinizin kaç puan koymak istediğini değil, her yinelemeyi genellikle kaç puan yaptığınızdır.

Bundan sonra, görevleri sürekli olarak hafife almanız önemli değildir - hızınız zaten bunu hesaba katar.

Açıkçası, nokta yerine saat kullanırsanız bu imkansızdır.


+1 proje hızı anahtardır, ancak ham saatleri bir hız faktörü
jk

1
Bu, tahminlerinizin her zaman aynı faktörden kaynaklandığını varsayar. Deneyimlerime göre, bu nadiren olur. Deneyimsiz geliştiriciler bile bazı görevleri çok doğru bir şekilde tahmin eder. Ve oldukça deneyimli geliştiriciler bazen belirli görevler için son derece düşük tahminler üretir. Kutsal kâse hangi görevlerin doğru tahmin edileceğini ve hangilerinin kötü olduğunu bilmektir. Bazı battaniye fudge faktörü uygulamak bu konuda yardımcı olmaz.
Dawood ibn Kareem

4
@DavidWallace Tabii, görev başına doğru tahminler üretmeyecek , ancak hedef tüm bir sprint için daha doğru bir tahmin. Teorilerde teori, göreve göre çeşitliliğin, hızın hesaplandığı 3+ iterasyon üzerinden ortalanmasıdır.
Chris Pitman

12

Sorunlar, ekibinizin doğru tahminler yapamaması ve kaçınılmazlığın ortaya çıkardığı sorunları görememesidir.

Küçük görevlerin doğru tahmin edilmesi büyük görevlerden çok daha kolaydır, bu nedenle görevlerinizi çok daha küçük parçalara ayırmaya çalışın.

Tam olarak nasıl yapacaklarını bilmedikçe kimsenin herhangi bir görev için tahmin yapmasına izin vermeyin. Geliştiricinin neyi tamamlayacağını bilmediği herhangi bir görev için, geliştiricinin biraz araştırma ve tasarım yapması için BU sprint programına biraz zaman ayırın ve doğru bir tahmin yapın. Asla yarım günden az. Ancak görevi SONRAKİ sprint'e taşıyın. Ardından, bir sonraki sprint planlamasına geldiğinizde, iyi bir tahminde bulunacaksınız. Bu ekstra sürenin boşa gitmediğini unutmayın, çünkü geliştiricinin her durumda harcama yapması zamanıdır.

Ve proje yöneticisine geri dönmekten ve ona görevler listesinden geçmek için daha fazla sprint'e ihtiyacınız olacağını söylemekten korkmayın. Bunu yapmak, imkansız hedeflere bağlı kalmaktan daha iyidir.


Zor sorunları araştırmak ve uygulamayı bir sonraki sprint'e ertelemek için +1. Buna yaygın olarak "başak çözeltisi" (veya sadece "başak") denir; extremeprogramming.org/rules/spike.html .
sleske

Erken inceleme için +1. Şahsen, kütüphane veya programlama prensibi ile kafam karıştığında, zihnimin arkasında bir iki hafta boyunca mull yaparsam, konuya döndüğümde, çok daha mantıklı olur.
Buttons840

6

Zamanınızın% 100'ünü ayırmaya mı çalışıyorsunuz? Eğer öyleyse, yapmayı kes. Sprint sırasında ekibinizin katkıda bulunması gereken tüm saatleri toplayarak başlayın. Bunu, her bir işçinin projeye en iyi günde 6 saat koyacağını varsayarak yapın . Bu "ideal bir gün" olarak kabul edilir. Diğer iki saat mi? Toplantılar, aralar, idari görevler, e-posta okurken ve gününüzü planlarken, vb.

İkinci olarak, bu 6 saat / günü % 80 ile çarpın . Neden? Çünkü insanlar olarak bir görevin ne kadar zaman alacağını tahmin ediyoruz. Bu, kararımızdaki hataları açıklar. Yine, kum torbası değil, gerçekçi.

Şimdi, doğrudan görevlerinize uygulamayı beklediğiniz gerçekçi bir saati temsil eden bir numaranız var. Tahmin ederken, bir sonraki öykünün sizi ele geçireceği hikayeler eklemeyi bırakın.

Son olarak, ürün sahibinin görev eklemesine izin vermeyin. Scrum planlama ekip içindir , PO işi yapan ekibin bir parçası değildir. Tabii ki, gerçek dünyada PO takımdaki herkesten daha bilgili ise, girdisi çok yararlı olabilir. Yine de, ekip geride kalmak için ısıyı alıyorsa, ekibin tam olarak hangi görevleri yapacaklarını sahiplenmesi gerekir. Amacınız kabul kriterlerini karşılayabilmektir; eğer bir görev doğrudan buna yol açmazsa, yapma.

Unutmayın, Scrum daha üretken olmakla ilgili değildir. Daha açık ve iletişimsel olmakla ilgilidir. İş, yapılması için ne gerekiyorsa alacaktır. Scrum tahmin etmeyi, paydaşlarla iletişim kurmayı ve ekibinizin taahhütte bulunmasını kolaylaştırmak için var.


5

Sprint başlangıcında kabul kriterleri kötü tanımlanmış mı?

Başlangıç ​​tahminleri genellikle çok düşüktür, çünkü hikaye kartları tahmin edildiğinde (varsa) zayıf kabul kriterlerine sahiptir. Ekibin kartın ne olduğunu gerçekten netleştirmesine yardımcı olmak için Kabul-Test Odaklı Geliştirme'ye (ATDD) aka hikaye testi yapmaya geçmeye ne dersiniz ?

Hikayeler çok mu büyük?

Sprint ortasında hikayelerinizin beklenenden daha uzun sürdüğünü öğrenmenin bir başka nedeni de çok büyük olmaları olabilir. Eğer gördünüzmü bir Flash Çevik flaş kart güverte? Onlar "Fit için XL hikayeleri Shrink" adlı bir flashcard var. Son olayları erteleme, yan etkiler, işlevsel olmayan yönler veya sonraki hikayelere hata işleme gibi hikayeleri ayırmak için stratejiler verir.

Yeterli bilginiz olmadığı için tahmin edemiyor musunuz?

@sleske sivri uçlar hakkında iyi bir öneri yapar . Tahmin süresinde teknik bilinmeyenleri belirlemeye çalışın. Varsa, hikayeyi daha sonraki bir sprint'e erteleyip erteleyemeyeceğinize bakın ve bunun yerine , tahmin edebilmek için ne gerektiğini öğrenmeye çalışmak için bu sprint'i zamanla araştırın (başak) yapın. Taşınmayın ve orijinal hikayeyi çözmeyin - ani, hikayeyi tahmin etmek için yeterli bildiğiniz zaman yapılır.

Daha hızlı başarısız olun

@Patrick Hughes ile hemfikirim - sorunları daha hızlı görebilmeniz için 1 haftalık sprintlere geçmeyi düşünün.


3

@Kevin ve @Patrick'in iyi önerilerine ek olarak ...

Çevik yaklaşımlar "tek beden herkese uyar" değildir ama bu yorum dikkatimi çekti:

Bize sürekli aynı zorlukları sağlayan bir Agile sürümü uyguluyoruz

"Kitap tarafından" bir metodoloji ile başlamak daha iyidir (Scrum bugünlerde baskın görünüyor) - ve diğer bazı başarılı takımların yaptıkları TAMAMEN yapın ... Bunu birkaç sprint için yapın ... Ve ancak o zaman dikkate almaya başlayın yerel koşullara göre optimize etmek için gerekli değişiklikler.

Deneyimli bir Scrum antrenörü kiralamak (birkaç iterasyon için) gerçek bir fark yaratabilir. Çevik doğru olma konusunda incelik vardır.


3

İlk önce scrum-xp-from-the-siper adlı kitabı takip etmenizi tavsiye ederim . Hız hesapları için 26. sayfaya bakınız. Fikir bir odak faktörü tanımlamak ve bir sonraki Sprint için şunu söylemek:

kullanılabilir adam-gün * odak faktörü = tahmini hız

tahmini hız, bir sonraki Sprint sırasında uygulamayı planladığınız hikayelerin tahminlerinin toplamıdır.

Ve bir Sprint'ten sonra en son Sprint odak faktörünü şu şekilde hesaplarsınız:

odak faktörü = gerçek hız / mevcut işgünü

burada gerçek hız, sprint sırasında uyguladığınız hikayelerin tahminlerinin toplamıdır.

Sonra bir sonraki Sprint için bu gerçek odak faktörünü tekrar kullanıyorsunuz ve birkaç Sprint'ten sonra bir Sprint sırasında gerçekten ne kadar başarabileceğiniz konusunda daha hassas olabileceksiniz ...


Siperlerden gelen scrumdan bahsettiği için +1. Soru ve cevaplar bana bu kitabı düşündürdü.
Buttons840

1

Sprintlerinizi bir haftaya kısaltmak için tahminlerinizi alana kadar, bu şekilde fazlalığı daha hızlı tanıyacak ve daha küçük artışlarla tepki verebileceksiniz.

Muhtemelen kapsamın her yerde kanamasına neden olan yan etkileri tanımak için nefes odası almak için görevler tasarlarken daha fazla zaman harcayın. Ayrıca, görevlerin kendilerinin uygun bir çevik tahmin için çok uzun olması da olabilir, görevlerin yutulması daha kolay olacak daha kısa adımlara bölünüp bölünemeyeceğine bakın.

Birkaç saat boyunca bir probleme takılmak yerine bir pürüzle çarptığında herkesi kırmızı bir bayrak göndermekten rahatsız edin. Ego ve suçlamayı bu süreçten ayırmaya çalışın, bazıları için diğerlerinden daha kolay =)

@Kevin'in getirdiği gibi, asla görevlere doğrudan% 100'ü gerçekten zamanlamıyorsunuz çünkü her zaman toplantılar gibi ek yükler var ve böylece zaman yiyenler olarak tanıyamayabilirsiniz.

Programlama cephesinde her şey güzel olduğunda, iki haftaya geri dönün, daha az toplantıdan sihirli bir şekilde biraz zaman alacaksınız.

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.