Bir sprint sırasında sprint biriktirme listesini değiştirme konusunda karışık


14

Son zamanlarda scrum hakkında çok şey okudum ve bana bir sprint sırasında sprint birikimini değiştirmenin uygun olup olmadığı hakkında çelişkili bilgiler buluyorum. Hüngür üzerinde Wikipedia makalesi tamam değil ve çeşitli diyor diğer haberler de söylüyorum. Ayrıca Yazılım Geliştirme profesörüm scrum'a genel bakış sırasında aynı şeyi öğretti.

Ancak, Scrum ve XP'yi Siperlerden okudum ve bu, görev panosundaki planlanmamış öğeler için bir bölüm açıklıyor. Sonra Scrum Rehberine baktım ve "Sprint Hedefi'ni etkileyecek hiçbir değişiklik yapılmadığını" ve Sprint Hedefi'nin tartışmasında "Çalışmanın beklenenden farklı olduğu ortaya çıkarsa, daha sonra Sprint içinde Sprint İş Listesi'nin kapsamını müzakere etmek için Ürün Sahibi ile işbirliği yaparlar. " Sprint İş Listesi tartışmasında şöyle devam ediyor:

Sprint İş Listesi, devam eden değişikliklerin Günlük Scrum'da anlaşılabileceği kadar ayrıntılı bir plan. Geliştirme Ekibi Sprint İş Listesi'ni Sprint boyunca değiştirir ve Sprint İş Listesi Sprint sırasında ortaya çıkar. Bu ortaya çıkma, Geliştirme Takımı plan üzerinde çalışırken ve Sprint Hedefi'ne ulaşmak için gereken çalışmalar hakkında daha fazla şey öğrenirken ortaya çıkar.

Yeni bir çalışma gerektiğinden, Geliştirme Ekibi Sprint İş Listesine ekler. İş yapılırken veya tamamlanırken, tahmini kalan iş güncellenir. Planın öğeleri gereksiz görüldüğünde kaldırılır. Sprint sırasında sadece Geliştirme Takımı Sprint İş Listesini değiştirebilir. Sprint İş Listesi, Geliştirme Ekibinin Sprint sırasında gerçekleştirmeyi planladığı çalışmanın oldukça görünür, gerçek zamanlı bir resmidir ve yalnızca Geliştirme Ekibine aittir.

Bu noktada tamamen kafam karıştı. Bunu düşünmek, ikinci yaklaşımı benim için daha anlamlı. İş birikimindeki bireysel, belirli öğeler bana en önemli şey gibi görünmüyor, aksine sprint hedefi gibi görünüyor, bu nedenle sprint hedefini değiştirmemek, ancak biriktirme listesini değiştirmek mantıklı. Örneğin, hem ürün sahibi hem de ekip bir hikaye hakkında aynı sayfada olduklarını düşündüler, ancak sprint ilerledikçe bir yanlış anlama olduğunu anladılarsa, bu hikayeyi oluşturan görevleri buna göre değiştirmek mantıklı gibi görünüyor. . Ya da unutulan ancak sprint hedefine ulaşmak için gerekli olan bir hikaye veya görev varsa, sprint sırasında hikayeyi veya görevi biriktirmeye eklemenin en iyi olacağını düşünüyorum.

Ancak, sprint biriktirme listesindeki herhangi bir değişikliğin iyi olmadığı konusunda oldukça kararlı görünen bir çok insan var. Bu durumu bir şekilde yanlış mı anlıyorum? Sprint birikimini tanımlayan insanlar bir şekilde farklı mı? Sprint biriktirme listesi konusundaki anlayışım, hem hikayelerden hem de ayrıldıkları görevlerden oluşması.

Neyse ben bu konuda girdi gerçekten takdir ediyorum. Ben hem sprint sırasında sprint birikimini değiştirmek için idealist scrum yaklaşımının ne olduğunu anlamaya çalışıyorum ve scrum'ı geliştirme için başarıyla kullanan kişilerin sprint sırasında splog birikimini değiştirmeye izin verip vermediğini anlamaya çalışıyorum.

Yanıtlar:


10

Öncelikle bu konuda zor kurallara sahip olmazdım; tüm scrum noktası, duruma uyum sağlamanıza izin vermektir. Bu nedenle, sprint sırasında sprint biriktirme listesini kesinlikle yapmalısınız (kritik bir şeyi unuttuğunuz gibi).

Ancak sprint sırasında sprint birikiminde yapılan bu değişikliğe karşı koyulmalıdır. Sprint'in kısa olması, projenin genel zaman çizelgesini (çoklu sprintler) etkilemeden bir sonraki sprint'e (doğru bir şekilde öncelik verildikten sonra) yeni çalışma eklenebilmesidir.

Ancak bu sprint'teki görevlerden biri için çalışma kritikse iki seçeneğiniz vardır.

  1. Sprint'e yeni bir öğe ekleyin.
    AMA eşdeğer boyutta bir öğeyi süratten çıkarın.
  2. Bu süratten kötü bir şekilde planlanan öğeyi bırakın (böylece bir sonraki süratte düzgün bir şekilde planlayabilirsiniz).
    • Ürün biriktirme listesinin üst kısmından (uygun boyutta) alternatif olarak ekleme (sprint planlama toplantınızdan öncelikli sırada olması gerekir).
    • Veya tüm sprint öğeleri tamamlandığında, geliştiricilerin ürün biriktirme listesinden gevşeklik almasına izin verin.

Bu yüzden kamptayım ve muhtemelen sprint biriktirme listesini değiştirmemelisiniz. Ancak, istisnai bir durum olabileceği durumu dikkate almalısınız. Çoğu durumda seçenek 2 ile gitmek ve devs iş yükü görevleri ile gevşeklik olsun izin.

Ardından bir sonraki planlama toplantısında yeni görev uygun şekilde analiz edilecek ve sprint'e (uygun olduğu şekilde) eklenecektir.

Sprint'in kısa olduğunu ve geliştirme döngüsünün sonunda değil, bir sonraki düşüşün işaretini unutmayın. Ürün sahibinin, bir sonraki sprint'in bitmesini bekleyemeyecekleri bir özellik için çok umutsuz olması gerekirdi.


Basit bir yanlış anlama olsaydı ne yapardınız, örneğin ekip, ürün sahibi başka bir şey ifade ederken, öğelerin kabaca eşdeğer büyüklükte olduğunu varsayarak bir öğenin bir şey anlamına geldiğini düşündü? Bu aslında daha önce işimde oldu, bu yüzden sadece teorik bir soru değil ...
Maltiriel

3
Loki'nin cevapladığı şeye eklemek için; Sprint biriktirme listesindeki herhangi bir değişiklik hakkında Ürün Sahibinizle görüşmelisiniz, çünkü ekip işin teslim edilmesi için PO'ya bir taahhütte bulundu. Ve eğer bir hikaye yanlış anlaşılmışsa, sorun ve iş değerini daha iyi tanımlamak için hikaye değiştirilebilir ve hatta yeterince değiştirilirse yeniden boyutlandırılabilir. Ancak bunu daima Ürün sahibiyle tartışır.
David 'kel zencefil'

10

Karışıklık belirsiz bir dilden kaynaklanıyor.

Sprint İş Listesinin iki ayrıntı düzeyi vardır. İlk olarak, Ekibin teslim etmeyi taahhüt ettiği Kalemlerin (Kullanıcı Hikayeleri) bir listesidir. İkincisi, ekibin bu hikayelerin her birini iletmek için yapmayı amaçladığı tüm GÖREVLER.

İnsanlar Sprint İş Listesi hakkında konuştuklarında, ne anlama geldikleri konusunda gerçekten net olmalılar. Scrum Rehberini okuduğunuzda şunu göreceksiniz: Sprint İş Listesi, Sprint için seçilen Ürün İş Listesi öğeleri kümesinin yanı sıra ürün Artışını ve Sprint Hedefini gerçekleştirme planıdır.

Bu yüzden onları teslim etmek Ürün İş Listesi Öğeleri VE Plan (Görevler) İKİDİR.

Şimdi, birçok takım Sprint'in başlangıcında önerilen tüm görevleri (planı) eklemeyi sever, böylece kalan saatlere dayalı bir burndown şemasını izleyebilirler. Diğer takımlar görevlerin gerektiği gibi ortaya çıkmasına izin verir. Bu, 'Sprint İş Listesi'ne ekleme yapmanın uygun olduğu zamandır, çünkü ekip Öğeleri teslim etmek ve Sprint Hedefine ulaşmak için incelemek ve uyum sağlamak için bunu yapmak zorundadır.

Belirli koşullar altında, bir ekip planlamanın çok ötesinde olabilir ve (Ekibin yeteneklerini artırabilecek diğer tüm yararlı görevleri ortadan kaldırmış), başka bir hikaye seçmek için (zaten önceliklendirilmiş ve boyutlandırılmış olmalıdır) Ürün Sahibi ile çalışmaya karar verebilir. Ürün İş Listesi ... ancak bu Sprint içinde tamamlanacağına ve Sprint Hedefi ile uyumlu olacağına dair güvenleri varsa.

İşte burada; EVET ... ekipler Sprint İş Listesi planına gerektiği şekilde Görevler YAPIR. HAYIR, genellikle Sprint Kapsamını tanımlayan İş Listesi Öğeleri listesine eklemezler.

Umarım bu durum netleşir.


1
Hmm, bu, özellikle insanların hikayeler / öğeler ve görevler hakkında net olmamaları hakkındaki görüşünüze yardımcı olur. Bununla birlikte, sadece yeni görevler eklemekle kalmayıp, aynı zamanda ekip ile ürün sahibi arasında bir yanlış anlaşılma olması gibi, bunların değiştirilmesi / değiştirilmesi hakkında da merak ediyordum. Bunun için "en iyi uygulama" nın ne olduğunu asla söyleyemedim, bu yüzden herhangi bir girdiniz varsa takdir edilecektir.
Maltiriel

2

Bu sizin durumunuza bağlıdır. Planlama sırasında bazı bilgiler gözden kaçırılırsa ve daha sonra birkaç hikayeye bazı noktalar değiştirmeniz veya eklemeniz gerektiğini anlarsanız, o zaman iyi olduğunu düşünüyorum. Ancak, evet, bir özelliğin kapsamı tamamen değişirse, bu aşırı bir durumdur ve farklı şekilde ele alınması gerekir.

Ancak elbette, planlama sırasında, herkesin üzerinde çalışacakları her bir özelliği açıkça bildiği ve tartıştığı varsayılmaktadır. Tartışmalar ve planlama iyi ise, neredeyse tüm durumlarda gerçekten herhangi bir modifikasyona ihtiyacınız yoktur.


“planlama sırasında, herkesin üzerinde çalışacakları özelliklerin her birini açıkça bildiği ve tartıştığı varsayılmaktadır” Elbette ve genellikle her şey işe yarıyor, ancak dahil olan herkes insan, bu yüzden bazen işler çatlaklardan geçiyor. Merak ettiğim durumlar bu, çünkü pek çok insan sprint birikiminin hiçbir koşulda bir sprint sırasında düzenlenemeyeceği kadar kararlı görünüyor.
Maltiriel

:) Evet biz insanız. Ve bazen, bir sprint sırasında değişiklik yapmanız gerekecektir. Ama tekrar tekrar devam ederse, başka bir yerde yanlış bir şey var. Herkesle bu konuda konuşmayı deneyebilir ve daha sonra karşılıklı olarak kararlaştırılmış bir çözüm bulursunuz.
Kumar Bibek

0

Cevaplara katılıyorum, eğer hikaye gelişmeye başlamışsa, o zamana kadar durdurulamayacağını belirtmek isterim.

Topuklarını erken kaz. Değişim isteyenlerin zor yoldan öğrenmesi gerekecek, aksi takdirde insanlar zaten ne istersen yapabilirsin öğrenirse değersiz olmayı planlıyorsun.

Kalitenin odaktan ve hataların bir düşünce trenini düşürmesinden kaynaklandığını belirtin. Bağlam değiştirme maliyetinden bahsedin. Borç takibi ve yarı pişmiş işleri ele almak için bir hikaye yazma ve tartışma ve oynama yönetiminin maliyeti yüksektir. Sadece bu rotadan yola çıkmayın.

Fikir: her üç ayda bir ödün vermek için yönetime 3 anahtar kredi verin.


"Cevaplara katılıyorum, eğer hikaye gelişmeye başlamışsa o zamana kadar durdurulamayacağına dikkat çekerim." - bu doğru değil. Bir ekip bir hikaye öğesini bitirmemeye karar verebilir. Bir sonraki sprint için sprint planlaması başladığında, bu hikayeyi bir sonraki sprint'e çekmelerini gerektiren hiçbir şey yoktur. Yine de bu ifadeyi gerçekten seviyorum: "Kalite odaktan geliyor ve hatalar bir düşünce trenini düşürmekten geliyor"
Bryan Oakley
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.