Günlük Scrum - Her geliştiriciye 3 soru sorun veya biletlerle gidin?
Yaklaşık 5 geliştiriciden oluşan küçük bir ekibiz.
Sanal bir Scrumboard'a sahip bir bilet yönetim sistemi kullanıyoruz.
Scrumboard'da birkaç sütun vardır. Sütunlardaki öğeler önceliğe göre sıralanmıştır:
New | Consultation | Working | Waiting | Test & Review | Done
Danışma = Dışarıdan birinden geri bildirime ihtiyacımız var
Waiting = Birini veya bir şeyi bekliyorum
2 haftalık sprint yaparken yaklaşık 40-50 aktif biletimiz var.
Standart bir Scrum'da günlük olarak genellikle her geliştirici 3 soruya cevap verir:
Dün ne yaptım
Bugün ne yapacağım
Engellerim neler?
Bir şekilde sürecimiz farklı:
Sütuna göre ve ardından sütundaki her bilete göre gidiyoruz.
Bunu birkaç nedenden dolayı yapıyoruz:
- bu süreç kendi kendine gelişti, biz planlamadık, sadece oldu
- bazı geliştiriciler, diğerleri konuşup dinlemediğinde "boşluk bırakır". Evet, genellikle günde sadece 15 dakikadır, bu nedenle bu süre boyunca dinlemenin mümkün olması beklenebilir. Ama hepimiz evden çalıştığımız için, birinin dinleyip dinlemediğini fark edemeyiz.
- Bir geliştirici 3 sorusunu bitirdiğinde diğerlerini dinlemeyebilir çünkü odak noktası kaybolur
- geliştirici bilet üzerinde görünür, ancak üzerinde çalıştığınız biletleri bulmak için kendi adınızı aramak biraz zaman alır. Görünümü değiştirmenin yolları vardır, ancak görünümü sürekli değiştirmek herkes için oldukça can sıkıcı hale gelir
- geliştiriciye göre gidersek, sunumunu yaparken bazen önemli bir bileti gözden kaçırırdı.
Sütunlara göre gitmek ve sonra biletler daha "doğal" geliyor, ayrıca herkes dinlemede daha aktif görünüyor, çünkü bir sonraki bilet ona ait olabilir. Ayrıca önemli bir detayı veya bileti de gözden kaçırmıyoruz. Geliştiriciler çoğu zaman dolaylı olarak 3 soruyu da bu şekilde yanıtlar, ancak her zaman değil. Bu süreç hala biraz daha üstün hissettiriyor - en azından çevremizde!
Öyleyse HER ZAMAN 3 soruya mı uymalısınız yoksa biletlerle mi gitmelisiniz?
Yoksa hangi yaklaşımın ne zaman "daha iyi" olduğunu anlamanın bir yolu var mı?
(Belki bu resim sorularımı anlamama yardımcı olabilir)
Yanıtlar
Öyleyse HER ZAMAN 3 soruya mı uymalısınız yoksa biletlerle mi gitmelisiniz? Yoksa hangi yaklaşımın ne zaman "daha iyi" olduğunu anlamanın bir yolu var mı?
Scrum Kılavuzunun 2020 versiyonu üç soruyu kaldırırken , kılavuzun 2017 versiyonu şunu söylüyor:
Toplantının yapısı Geliştirme Ekibi tarafından belirlenir ve Sprint Hedefine doğru ilerlemeye odaklanırsa farklı şekillerde yürütülebilir. Bazı Geliştirme Takımları sorular kullanacak, bazıları ise daha çok tartışmaya dayalı olacaktır.
Öyleyse en iyi olduğunu düşündüğünüz şeyi yapın veya ekibinize neyi tercih ettiklerini ve daha yararlı bulduklarını sorun.
Üç soru, günlük yaşamın nasıl yürütüleceğine dair bir örnektir çünkü tartışmayı hedefe yönelik çabalarınızı koordine etmek için kapsamanız gereken temel şeylere odaklamaktadır. Biletleri tartışmayı daha üstün bir yaklaşım olarak görüyorsanız, o zaman onunla devam edin.
Kendinizi çok fazla ayrıntıda kaybetmediğinizden emin olun (günlükten sonra her zaman daha ayrıntılı tartışabilirsiniz) ve zaman sınırının ötesine geçin, bu da işleri bir toplantıya dönüştürür ve insanlara zihinsel olarak kontrol etmek için daha fazla fırsat verir.
TL; DR
Panoyu geliştiriciye mi yoksa sütuna mı göre yürütmelisiniz? Hiçbiri. Her ikisi de anti-kalıplardır.
Standup'ı takımın bir statüsü olarak görmeyin ve kesinlikle tüm Sprint için planlanan her görevin durumunun bir mini incelemesi olarak kullanmayın. Mevcut işin kapsamını o günkü işin kapsamına alırsanız, "tahtayı en iyi nasıl gezdireceğiniz" sorusu (ipucu: yok, çünkü bunu yapmamalısınız) ortadan kalkar.
Takım Koordinasyonuna Yeniden Odaklanma
Sorunuz temelde kusurlu bir varsayımdan başlıyor: Scrum'da tüm biletler için bir durum raporu yapmak yararlı ve hatta arzu edilir. Ekip, günlük durgunluğun tüm noktasını kaçırdığı için, bu gerçekten bir X / Y sorunu , yani mevcut günün aktiviteleri için tam zamanında planlama ve koordinasyon gerçekleştirme .
"Üç soru" sadece bir amaca yönelik bir araçtır. Daha az olgun ekiplerde, bir yönergeye veya konuşma noktalarına sahip olmak, ekip üyelerinin görevler arasındaki bağımlılıkları belirlemelerine yardımcı olabilir. Yine de amaç bir durum raporu sağlamak değil. Amaç, her zaman ekibin o günkü işi işbirliği içinde planlamasına yardımcı olmaktır. Örneğin:
Sandy: Dün merkezi parçacığı yerleştirmek için çalıştım. Bugün ana çarkı küçültmem gerekiyor, ama bunu yapmak için Susan'dan aldatmaca almalıyım.
Susan: Dün whatchamacallit'i bitirdim, yani Sandy için hazır. Bugün frobnosticator üzerinde çalışmak istedim, ancak MacGuffin hikayesi tamamlanana kadar takılıp kaldım. Henüz bunun üzerinde çalışan var mı?
Başka bir deyişle, "tahtayı dolaşmak" için günlük standup kullanmayın. Ekibin günlük çalışma etrafında kendi kendine organize olmasını sağlamak için kullanın! Sorular takımın bunu yapmasına yardımcı oluyorsa harika. Değilse, fırlatın.
Benzer şekilde, sadece halihazırda devam etmekte olan veya gün için planlanan çalışmalar stand-up'ta tartışılmalıdır. Sprint İş Listesindeki çalışma veya bekleme durumu, yalnızca mevcut bir görevin bağımlılığı, başka bir şey için engelleyici ise veya birisi onu bugün devam etmekte olan çalışma olarak almayı planlıyorsa geçerlidir .
Gerçekten bir Sprint durumu istiyorsanız, Sprint Hedefini karşılama yolunda olup olmadığınızı belirlemek için Bitti sütununuzdan ve yazma grafiğinizden yararlanın. Sprint Hedefinin durumu söz konusuysa, bu muhtemelen günlük standup dışında ayrı bir toplantıyı ve kesinlikle bir sonraki Sprint Retrospektifiniz sırasında tüm Scrum Takımının dikkatini çekmeyi hak ediyor. En iyi ihtimalle, tahtada yürümek, etkisiz iletişimleri veya eksik / geçersiz bilgi yayıcılarını örtmek için bir durak noktasıdır. En kötüsü, ekip üyeleri arasındaki etkileşimler yerine durum raporlamasını tercih ederek ekibin tam zamanında planlama konusunda işbirliği yapmasını aktif olarak engeller .
Üç sorulu yaklaşım bireye odaklanır, ancak yönetim kurulu yaklaşımı takıma ve sprint hedeflerine odaklanır. (Ya da en azından tahtanın sağ tarafındaki amaç.) Tecrübelerime göre, üç sorunun bir tuzağı, bir kişinin çalıştığını kanıtlaması gerektiğini hissettiği zamandır. Ama biletlerle giderseniz, her biriyle konuşmayabilirsiniz bile.
Yukarıda ima ettiğim gibi, hangisi daha iyi hedeflerinize bağlıdır.
Takım uyumluysa ve tahta hedefe giden yolu yansıtıyorsa, o zaman elbette tahtayı kullanın. (Daha ileriye götürmeyi ve panoyu açıkça sağdan sola kullanmayı öneririm: işleri bitirmeye odaklanın.)
Ancak takım yeniyse veya henüz birlikte iyi çalışmıyorsa veya yönetim kurulu hedefi gerçekten temsil etmiyorsa, o zaman üç soru daha iyi bir bahis olabilir. Sprint hedefi aslında "bu yeni takımı harekete geçirme" veya "etkili olabilsin diye yerleşik Frankie" olabilir. Eğer durum buysa, kesinlikle herkesin ne yaptığı ve neyin işe yarayıp neyin yaramadığı hakkında konuşma şansı olduğundan emin olmak istersiniz.
Yoksa hangi yaklaşımın ne zaman "daha iyi" olduğunu anlamanın bir yolu var mı?
Çevik geliştirme ile ilgili bir şey, proje hedefleri ve organizasyonu için esneklik sunmasıdır. Günlüklerinin nasıl yapıldığı konusunda esnek olabileceğiniz bir şey, onu yinelemeli olarak geliştirmektir. Ekibinizden geri bildirim toplayın, sprint retrospektifinizde günlük yapıyı tartışın ve ekibinizin önerilerini denemekten korkmayın.
Şu anda her iki yaklaşıma da sahip olduğumuz bir ekipte çalışıyorum - ikimizin de günlük görev odaklı ve günlük "üç soru" var. İlki, geliştiriciler arasında mevcut panoyu tartışmak ve bazı teknik gözlemler için yer açmak için günde on dakika; ikincisi, daha geniş bir ekiple her gün daha insancıl bir gün geçirme çabası içinde "üç soru" üzerine çok daha fazla odaklanan günlük on beş dakikalık bir günlük.
Geliştiricilerin ve görevlerinin günlük işleyişini yaptık, ancak hem odaklanma konusunda bahsettiğiniz nedenler, zaman kaygıları ve ilgili görevlerin durumu hakkında tutarlı bir anlayış eksikliğinden dolayı süreci bir kenara atmaya karar verdik. Ve evet, sürekli olarak geliştiriciye göre görevleri filtrelemek bizim için de bir güçlüktü.
Yorum yapamam, bu yüzden cevap olarak iki sentimi ekledim.
Önerebilirsem: "üç soru" "göbeğinize bakıyor " olabilir ve siz gerçekten hepsinin "etrafa bakmasını" istiyorsunuz.
Yapacağım ilk şey, görev listenizi, ilgili görevleri "iş açısından yararlı" bir şekilde bir arada değerlendirmenize olanak sağlayacak şekilde gruplandırmanın bir yolunu bulmaktır . (Ayrıca, birden fazla grupla ilgili olabilecek görevleri "etiketlemek" için işlevsel bir yol bulun. Yazılımda, her şey genellikle bir şekilde diğer her şeyle ilişkilidir.)
Sonra, ben takımı isteyeceğini düşünün sizinle birlikte her grubu ve hepiniz yardımcı olmak için tercih (!) Ne - karşılıklı ve bilinçli oy birliği ile - olmalı takımın "gün için üç soru."
Bir yandan, yazılım geliştiricileri günün problemi ne ise ona odaklanma konusunda üstün bir yetenek kazanmayı öğrendiler . Yani, "nasıl derine dalacaklarını ve nasıl aşağıda kalacaklarını çok iyi biliyorlar." Ama - şimdi kişisel deneyimlerinizden bahsedersek - çok geç, yanlış yere yanlış bir nedenle daldığınızı ve bir kasırga tarafından emildiğinizi bilmediğinizi fark etmek çok kötü . "Sen bilseydin ..."
Ve böylece, temel mesele açık: geliştiriciler "derin dalgıçlar" olduğundan ve öyle olması gerektiğine göre, kim sürekli teknede oturuyor, her zaman kuru, her zaman büyük resmi izliyor? Köpekbalıklarını mı izliyorsunuz? Yüzeyde kürek çekerken, sonra nereye ve neden dalacaklarını bilmelerine yardımcı oluyor mu? Bu sen olurdun.
Şimdi - düşünceyi tamamlamak için - bazen bu dalgıçlar sizin bilemeyeceğiniz bazı önemli yeni bulgularla yüzeye geri dönecekler . Her zaman geliştiricilerin karışımınıza "bilet" katkısında bulunmasına izin verin.
Başkalarının da söylediği gibi, Scrum Kılavuzu artık 3 soruyu belirlemiyor. Ve dürüst olmak gerekirse, 3 soruya dayanan çoğu günlük scrumlar, olayın amacıyla çelişir. Bir Scrum Master tarafından düzenlendiğinde ve takım üyeleri,% 0 kendi kendini organize eden son 24 saati rapor etmek zorunda kalır. Bu, Sprint'in durumunu gerçekten incelemek ve günün Sprint Hedefine başarıyla ulaşma ruhuyla planlanmasıyla sonuçlanmayacaktır. Ekip üyelerinin kendi başarılarıyla ilgilendikleri geliştirme ekibinin dahili bir tartışması olmalıdır.