Makalemde , " İşi Tahmin Etmek Güvenilir Olmak Gerekiyorsa Neden Zaman Yerine Hikaye Puanları Kullanmalı? Ürün İş Listesi Kalem büyüklüğünün tahmin edilmesi için hikaye puanlarının kullanılmasını savunmak için tercihimin nedenlerini tartışıyorum. Tercihim bu amaçla zamanı kullanmaktan kaçınmak olsa da, takımdaki iş akışını optimize ederken zaman hala önemli bir husustur.
Bir günde sadece çok fazla saat vardır. Aynısı geliştirici günü için de geçerli, özellikle de sürdürülebilir hız kavramını benimsediğimiz için. Haftada tipik kırk saat çalışan erkekler için, bunu beş günlük bir çalışma haftası için sekiz saatlik günlere bölebiliriz. Bu yaygın bir varsayım ama gerçekten doğru mu?
Hikaye puanlarını kullananlar için, bir Sprint / Yinelemenin kapasitesini takımın ortalama hızı cinsinden değerlendiriyoruz. Planlamamız gereken, maksimum zaman sınırlarına sahip sprint etkinliklerimiz var ve bu olayların her biri için harcanan sürenin ortalama takım hızına göre hesaplanıyor. Ancak zaman tüketirler.
İdeal bir dünyada, sprint sırasında düzenlenen tek toplantı onlar olurdu, ancak gerçeklik her zaman idealde değildir. Scrum etkinliklerine ek olarak toplantıların yapılacağını kabul ederek, bu toplantılara katılmanın faydasını en üst düzeye çıkarmak için bir yaklaşıma sahip olmalıyız. Bunun anahtarı, hedefleri belirlemektir.
Bu ilke, önceliklerin belirlenmesinde faydalı bir karar verme aracıdır. İlke, neyin önemli ve neyin acil olduğunu tartışır. İki faydalı öncül şudur:
Bir toplantıya katılıp katılmamaya karar verirken, toplantının amaçlarını değerlendirmeli ve aynı zamanda sprint hedef (ler) ine ulaşma açısından birey veya takım için önemi değerlendirmeye çalışmalıyız. Katılımın siz veya ekip için önemli olmadığına karar verirseniz, toplantı kaydedilebilir mi? Alternatif olarak, toplantıdan sonra belki de toplantı notları verilebilir.
Scrum değerlerinden ikisi, saygı ve odak özellikle toplantıların yürütülmesi ile ilgilidir. Öncelikle herkesin toplantı için vazgeçtiği zamana saygı gösterin ve zamanında katılın.
Parkinson yasası, "çalışmanın tamamlanması için mevcut olan zamanı dolduracak şekilde genişlediğini" belirtir.
Parkinson yasasına, ayrılan toplantı süresini dolduran teğet tartışmaların yapılabileceği toplantılarda da tanık olunabilir. Bu, odaklanmanın yardımcı olabileceği yerdir. Toplantının hedeflerini belirleyin ve bunlara ulaşmaya odaklanın. Bir kez elde edildiğinde, toplantıyı sonlandırın ve kalan süreyi katılımcılara geri verin. Bunun nedenini görmeye devam edebiliriz.
Toplantı süresi hakkında söylediklerimiz aynı zamanda scrum etkinlikleri için de geçerlidir. Maksimum zaman sınırlarına sahipler ama gerçekten tüm bu zamanı almanız gerekiyor mu? Bu bir yargılama çağrısıdır. Olayların her biri için hedefleri belirleme noktasına geri dönüyorum. Ekibin bu olayların her birinin ekibe sağladığı faydaları fark etmesi önemlidir, ancak bu ayrı bir tartışma.
Bir sprint sırasında kod geliştirmeyi / test etmeyi içermeyen olay ne olursa olsun, mevcut geliştirme süresini tüketir. Etkili olarak, ortalama geliştirici gününü azaltıyor. Buna biraz daha detaylı bakalım. Bu örnekte, örnek olarak, iki haftalık bir sprint'i ele alacağız.
Scrum olayları için zaman kutuları aşağıdaki gibidir:
Alman atasözü " das Kind mit dem Bade ausschütten" den türetilmiştir.
Birçok takımın, bu olaylarda başarmaya çalışacakları şeyi takdir etmedikleri için scrum olaylarını yapay olarak kısalttığını gördüm. Parkinson yasasındaki ihtiyatı göz önünde bulundurarak, tam zamanlı kutuları bunun uğruna kullanmamalıyız. Bu olayların her birinde hedeflerimizi net bir şekilde belirlemeli ve bunları gerçekleştirdiğimizde toplantıları sonlandırmalıyız. Scrum ekibinin tamamı, scrum olaylarının ekibine sağladığı faydalar konusunda net olmalıdır. Gereken gerçek süre, scrum ekibi üyelerinin deneyimine bağlı olacaktır. S crum Kılavuzları , olayların her birine tam bir açıklama verir.
Tüm bunların sayılarla ne anlama geldiğine bir bakalım. İki haftalık sprint, sekiz saatlik güne göre. Yalnızca resmi Scrum etkinliklerinin tam zamanlı kutularını kullanarak kalan, ortalama günlük, kullanılabilir üretim süremiz yedi saattir.
Şimdiye kadar fena değil. Ayrıntılandırma oturumları için maksimum% 10'u ekleyelim; Kalan sürenin% 10'u yani yaklaşık yedi saat. Bu örnekte, bu 3,5 saatlik iki oturuma bölünmüştür. Biliyorum! Tüm bu zamana ihtiyacınız olmayabilir; bana katlan.
Yani, şu anda sahip olduğumuz şey - sekiz saatlik bir gün için - her gün ortalama olarak mevcut üretim süresinde neredeyse% 25'lik bir azalma. Bu etkiyi artıran bir şey de, neredeyse her zaman geliştirici katılımını davet eden çeşitli başka toplantıların olmasıdır. Bu makalenin amacına ulaşmaya yardımcı olması için örnek olarak birkaç tane ekleyebiliriz.
Bunun kapsamlı bir liste olması amaçlanmamıştır, ancak umarım sıklık ve sürenin karşılanmasının ortalama mevcut üretim süresi üzerindeki potansiyel etkisini göstermeye hizmet eder. Bu resimde şu anda üretime uygun ortalama günün% 75'inin altındayız.
Scrum Master kesinlikle takımı ve kurumu bu konuda koçluk edebilir, ancak konuyu anlamak insanların ortaya konulan noktaya daha açık olmalarına yardımcı olabilir.
Öğrenci hazır olduğunda öğretmen görünecek. Öğrenci gerçekten hazır olduğunda… Öğretmen ortadan kaybolacak. "
- Tao Te Ching
Bu, üretim zamanı bulmacasının bir parçasıdır. Geliştiricilerin bu uygun zamanda yaptıkları başka bir koçluk noktasıdır. Yedi yazılım geliştirme israfının etkisini azaltmaya yönelik yalın ve çevik bir yaklaşım , verimliliği daha da ileriye götürecektir. Toplantıların zamanlaması, daha önce tartıştığımız şeyleri daha da kötüleştirebilir. Toplantılardan önce kaçınılmaz bir kapanma ve toplantıdan sonra geri dönüşe odaklanma var. Yedi atığın tam açıklaması bu makalenin kapsamı dışındadır, ancak umarım içinde bulundukları bağlamın bir resmini vermeyi başardım.
Burada iletmek istediğim şey, toplantılara dikkat etme ve onlardan maksimum fayda sağlama ihtiyacıdır. Belki de geliştiricilerin davet edildiği toplantılara bakmalı ve ekiple sohbet etmeliyiz. Bu toplantılardan ne elde ediyoruz? Kimin orada olması gerekiyor? Bir süre geri dönmeyi reddedebileceğimiz herhangi bir toplantı var mı? Scrum etkinliklerimizde ne kadar verimliyiz? Hedeflerimizi anlıyor muyuz ve bunları nasıl daha verimli şekilde yürütebiliriz?
Ciddi Scrum için yazmak mı yoksa Scrum'ı ciddi şekilde tartışmak mı istiyorsunuz?
Pomodoro Tekniği. Terimi ilk kez duyduğumu hatırlıyorum.
Yeni yıla girerken, yıl boyunca okuduğumuz kitaplar üzerine düşünmenin tam zamanı. Benim için bu yıl, her zamanki gibi, ağırlıklı olarak iş dünyasından ama aynı zamanda ebeveynlik üzerine birkaç kitaptan harika kitaplarla doluydu.
Amaç, algıya çok daha fazla netlik getiren bir şeye nasıl baktığınızı çerçevelemenin bir yoludur. “Amaç” dediğimde, bir kişinin başarmaya çalıştığı şeyi kastediyorum, ekibinizin bilmek istediği şeyi veya kuruluşunuzun yıl içinde neyi başarmayı umduğunu değil.
Fiyat, bir dolar rakamından çok daha fazlasıdır - bir değerin temsilidir ve bir ürünün para kazanıp kazanmayacağını belirlemede en kritik faktördür. Yine de, genellikle sonradan düşünülür, bir ürün geliştirildikten sonra son dakikada değerlendirilir.
Ürün yönetimi o kadar çok farklı beceri gerektirir ki büyük ihtimalle çalışanlarınız en azından bazılarında sizden daha tecrübelidir. Bu beceriler, ekibinizin başarmaya ihtiyaç duyduğu şeyin temelini oluşturduğunda kafa karıştırıcı hale gelebilir.
Onlarla mücadele etmenin ve projelerinizi ve akıl sağlığınızı yolda tutmanın 3 yolu Ellerinizi indirin, Ürün Yönetiminin en zor kısmı, sizden güneşi ve ayı bakımlı parmaklarının çırpışıyla teslim etmenizi bekleyen mantıksız yöneticilerle uğraşmaktır. Benim zamanımda her türden yaşadım.