Bir sürat ne kadar rahat olmalı (ya da olmamalı)?

Bir sprint'e atanan hikayelerin yapılmasına yönelik tutum ne olmalıdır? Açıkçası onları sprint'te gerçekleştirmeye öncelik vermek istiyorsunuz, ama bana göre çevikliğin tüm noktası dinamik olmaktır: Bir sprint'te biten kullanıcı hikayelerini kaçırmayı kasten ertelemek veya "tamam" yapmak istemezsiniz, ancak aynı zamanda beklenmedik şeyler ortaya çıktığında ve bu hikayeler tamamlanmadığında ve bir sonraki sprint'e itildiğinde, yanlış bir şey yaptığınızı hissetmek istemezsiniz. Bu korkutucu ya da olumsuz bir deneyim olmamalı, değil mi?

Olumsuz / korkutucu deneyimler kaçırılan sprint taahhütleri için kabul edilebilir mi? Geliştirilmesi gereken beklenmedik görevler ortaya çıktığında geliştiriciler kaçırılan sürat taahhütlerinden sorumlu tutulmalı mıdır (ör. Üretim desteği)?

Sen gerektiğini kesinlikle bir sprint içinde yapılan ürün almak için amaçlıyoruz.

SCRUM'un ana faydalarından biri, projeye bir 'kalp atışı' vermesidir.

Bir listeden öğeleri önceliklendirirsiniz, listeden çıkarırsınız, teslim edersiniz, demo yaparsınız, nasıl gittiğini yansıtırsınız, daha sonra tekrarlanabilir döngülerde tekrar yaparsınız.

Tüm planlama, tahminler ve önceliklendirme bu konsepte dayanmaktadır. Sprint içinde X puanları yapabileceğimizi ve taahhüt edeceğimizi ve zaman içinde daha iyi planlama için kullanabileceğimiz bir hız belirleyebileceğimizi ve taahhüt edeceğimizi.

Sprintlerinizin içeriği ve taahhütleri konusunda çok rahatsanız, SCRUM sadece benim görüşüme göre ayrılıyor ve çok şey kaybediyorsunuz.

Tabii ki gerçek dünya bazen bu konuda söyleyecek bir şeyler olacak, ama bu kuraldan ziyade istisna olmalı ...

Anahtar, hikayelerin tamamlanamaması konusunda hesap verebilirliğin olması gerektiğidir .

Bu, bir hikayenin tamamlanmamasının sağlam bir nedeni olması gerektiği ve bu nedenin ileride devam edecek olan proje planında açıklandığı için tekrarlanmaması gerektiği anlamına gelir.

Bu nedenin belirsiz bir "şeyler geldi" den fazla olması gerekiyor.

Örneğin, bir ekip üyesinin bir üretim sorunu üzerinde çalışması gerektiğinden bir hikaye tamamlanmadıysa, bu olasılığın, bu ekip üyesinden daha az saat planlayarak veya başka bir kapsam ayarlayarak gelecekteki yinelemelerde ele alınması gerekir.

Sebep daha fazla titizlikle veya daha önce sıkı çalışma ile önlenebilirse, evet, bu hesap verebilirlik biraz acı verici olabilir. Umarım, acı "İşinizi yapmıyorsunuz" çeşidinden ziyade "Bir dahaki sefere daha iyisini yapmamız gereken şey" çeşididir.

Bu korkutucu ya da olumsuz bir deneyim olmamalı, değil mi?

Bir veya iki kez olursa, hayır, o zaman olumsuz bir deneyim olmamalıdır. Düzenli olarak gerçekleşirse, bir sorununuz var demektir. Ekip daha sonra her zaman aşırıya kaçar. Tahminde daha iyi olun ve bir sprint için ne taahhüt ettiğiniz hakkında iki kez düşünün, ancak endişelenmeyin.

Rahat sprintler, bir taahhüdünüz olduğu anlamına gelir.

Kayıtsız sprintler, fazla bağlılığınız olduğu anlamına gelir.

Sadece taahhüt ettiğimi teslim ediyorum ve taahhütte daha iyi olmaya çalışıyorum. Sadece özel koşullar altında bir hikayeyi bir sonraki sprint'e taşırdım. Her gün, son teslim tarihlerinden kısa bir süre önce çok fazla bir baskıya maruz kalmayı tercih ederim.

Deneyimlerime dayanarak - Agile'daki her şey gibi, tahmin de dahil olmak üzere sürekli bir geri bildirim sistemine uyum sağlıyoruz.

İlk sprint (projenin başlangıcı) için bir son tarihi kaçırmak sorun değil, ancak yanlış giden şeyden ÖĞRENİN (eksik tahmin, takımın güçlü yanlarını bilmemek vb.). Sonra geri bildirimi alıp bir sonraki sprint'e beslersiniz ve daha iyi bir tahmin elde edersiniz.

Deneyimlerime göre, yeni çevik projemde 11 ay geçti , son gün nadiren kaçırırsak . Ancak ilk sprint için son tarihi kaçırdık çünkü ekip üyelerimizin hızını ve gücünü bilmiyorduk.

Bazı insanlar ilk sprint probleminin ilk sprint probleminin üstesinden gelmek için daha fazla zaman ayırdıklarını iddia ediyorlar.

Cevapları / yorumları burada görmek ilginç. Üzerinde çalıştığım her çevik (tip) projede birincil avantaj, son tarih baskısını bir projenin sonundaki bir ölüm yürüyüşü yerine birçok mini son teslim tarihine yaymaktı. IMO, sprintler ciddiye alınmalı. Son teslim tarihinden veya teslim edilen işlevsellikten kaçışlar, proje yönetiminde veya geliştirmede potansiyel sorunlar olarak görülmelidir.

Çevik süreçler sürdürülebilir kalkınmayı teşvik eder. Sponsorlar, geliştiriciler ve kullanıcılar süresiz olarak sabit bir hızda kalmalıdır. - Çevik Manifesto'nun Arkasındaki İlkeler

Korkunç veya olumsuz bir deneyimse ve her zaman olursa, bir sorununuz var demektir. Yazılım geliştirme eğlenceli olmalıdır. Olumsuz ya da korkutucu değil.

Bununla birlikte, takım bir sprint içinde bazı hikayeleri bitirmeyi taahhüt edip sürekli olarak teslim etmiyorsa, bir sorununuz da vardır. Bu sorun, takımın hikayeleri tamamlaması için daha fazla baskı uygulayarak neredeyse kesinlikle çözülmeyecek. Sorun dış faktörlerden kaynaklanıyorsa, bunların yönetilmesi gerekir. Eğer takım ScrumMaster'ı fazla işliyorsa, takımı daha az hikaye puanı edinmeye yönlendirebilir. Bunun birçok nedeni olabilir ve her birinin farklı şekilde ele alınması gerekebilir. Enerjik ve motive olmuş bir takım ilerlemek için bolca motivasyona sahip olmalıdır.

İdeal olarak sorun ne olursa olsun, geriye dönük olarak ortaya çıkar ve sabitlenir.

Takımın sprint'in nispeten kısa döneminde neler başarabileceklerini anlaması ve sonra başarması o kadar karmaşık olmamalıdır (bir sonraki sprint'e zorlanan ara sıra bir hikaye tamamdır, hız dalgalanabilir, işler değişebilir vb. .). Birkaç sprintten sonra bunu sorunsuz bir şekilde devam ettiremezseniz, yanlış bir şey yapıyorsunuz.

Gerçekten zaman çizelgenize bağlıdır.

Bazen tüm hikayeleri veya zaten çoğunu halletmeniz gerekir. Agile biraz esneklik sağlarken, muhtemelen sıkı bir zaman çizelgesinde de projeyi halletmeniz gerekecek. Bu nedenle, hikayelerin çoğuna sahip olmak projenizi zamanında bitirmenizi sağlayacaktır.

Bununla birlikte, her hikayeyi, her sprint'i yapmanızı engelleyen şeyler ortaya çıkacak.

Ürün bir zaman çizelgesindeyse ve önemli hikayeler kaçırılırsa, bu coudl ürünü geç yapar. Bazı durumlarda ürünün geç kalması bir şirketin rekabetçi pozisyonuna zarar verebilir. Bu durumda, hikayelerin eksik olmasının olumsuz bir deneyim olmasını İSTEMEK isteyebilirsiniz - bir dahaki sefere hepsini halletmenizi sağlayabilir.

Doğru doz verildiğinde stres iyidir. Tüm stresi ortadan kaldırmak istemiyorsunuz, sadece zaman içinde daha eşit bir şekilde yaymak istiyorsunuz. En sevdiğiniz oyunu oynarken bile, bir miktar stres ve olumsuz duygularınız olacaktır. Aslında bundan daha fazla enerji alıyorsunuz.

Bir takım kaçırılan hikayeler konusunda gerçekten kötü hissetmelidir. Bir dahaki sefere bir şeyi değiştirmeleri için enerji verecektir (farklı çalışın veya daha az hikaye planlayın, ikisi de iyidir). Tabii ki hikayelerini hazırlarken gurur duymalıdırlar.

Ayrıca beklenmedik görevlerden de söz ediyorsunuz (üretim desteği). Bu benimle bir kırmızı bayrak yükseltir. Öykülerle ilgisi olmayan tüm konular için kararlaştırılmış bir zaman kutusu olmalıdır. Aksi takdirde oyun adil olmaz, takım çaresiz hisseder ve olumsuz duygular iyileşmek için kullanılmaz.

Taahhütlerinizi başarısız kılan faktörlere bakmalı ve bunları düzeltmeye çalışmalısınız. Büyük miktarlardaki rastgele olaylar süratlerinizi karıştırmaya devam edecek ve hızınızı tahmin edilemez hale getirecektir. Ya bunun nedenlerini düzeltin ya da sprintlerinize bolluk koyun. Düzeltmeyi tercih ederim.

Her iki durumda da, işlerinin dış faktörlerden rahatsız olması durumunda takım sorumlu tutulamaz. Bunu incelemek için geriye dönükleri kullanın.