Scrum: Bir seferde bir hikaye üzerinde nasıl çalışılır

Yeni kurulan bir scrum takımında scrum ustası olarak aday gösterildim. Zaten bazı sprintler yaptık. Başlangıçta ekibimi her seferinde bir hikaye üzerinde yapmaya çalıştım. Ama işe yaramadı. Ekibim, görevleri bir hikayede aynı anda çalışabilecek şekilde dağıtmakta zorlandı. Belki yanlış bir şey yapıyoruz?

Örneğin: yeni bir iletişim kutusu oluşturmak için bir hikayemiz var. Aşağıdaki görevleri yaratıyoruz:

• Model sınıfları oluşturma
• Model verilerini veritabanından okuma
• Model sınıflarını görünüme bağlayın
• İletişim kutusunu kullanma
• Verileri kapatıldığında kaydet
• Test Dokümanları
• Çözüm Tanımı

Bu görevler aynı anda birden fazla kişi tarafından yapılabilir mi? Görevler - az çok - birbirleri üzerine kurulur. Yoksa görevleri yanlış bir şekilde mi tasarlıyoruz?

Neden tüm ekip tek bir hikaye üzerinde çalışsın?

Neden bir kişinin (veya daha iyisi, çift programlama yapan bir çiftin) tek bir hikaye üzerinde çalışabilmesi için hikayeleri yeterince küçük (ve yeterince bağımsız) yapmıyorsunuz? Bu süreç aynı zamanda gereksinimleri daha iyi tanımlamaya ve hem sorun hem de uygulama hakkında daha fazla düşünmeye yardımcı olur. Tahminler daha doğru olabilir, ancak burada garanti verilmez.

Bu, büyük ölçüde kullanıcı hikayesinin boyutuna bağlı olsa da, çoğu durumda geliştiricilerinizin birbirlerinin ayak parmaklarına basmasını önlemek için bir hikayeye yalnızca bir geliştirici atanmalıdır. Daha büyük veya çok karmaşık hikayeler daha fazla geliştirici gerektirse de, bu hikayeleri ayrı ayrı atanabilecek birçok küçük hikayeye ayırmak da mümkün olabilir.

Genel olarak yaptığımız öyküleri dev / infra / analist alt görevlerine bölmek.

1. Genellikle bir günden fazla çalışılan her şey bir hikaye.

2. Görevler bozulduktan sonra, eldeki görevlerin sayısına bağlı olarak bir veya en fazla iki geliştirici bir hikaye üzerinde çalışır. Genellikle bir tanesidir.

3. Harcanan zamanı kaydederiz ve kalan tahmini ayrılmadan önceki günün sonunda veya günlük ayağa kalkmadan güncelleriz.

4. Çalışırken ortaya çıkan yeni sorunlar için alt görevler oluşturulur.

5. 2 haftadan fazla çalışılan bir Hikaye Epik olarak kabul edilir.

6. Bir Destan birçok hikayeden oluşabilir

Ekibinizin yapmasını istediğiniz şey, sürü olarak adlandırılır , ancak her birikmiş madde tüm ekip tarafından çevrilemez. Ortak düşünce, sürünün bazı ön koşullar gerektirmesidir:

• çapraz fonksiyonel, birlikte konumlandırılmış bir ekip
• önemsiz olmayan bir hikaye
• tüm ekibin katılımını ima eden "tamamlanmış" tanımı

Bir hikayeyi görevlere böldüğünde, ekip, oluşturulan görevlerin sürü ile uyumlu olması ve tüm ekibi içerebilmesi için zaten sürü modunda olmalıdır.

Ancak aynı anda çok fazla çalıştıkları için ekip üyeleri arasında bazı çatışmalar ortaya çıkabileceğinden, aşırı sıkma sorunuyla karşılaşabileceğiniz için, çok sık veya çok sayıda insanla aynı anda swarming kullanırken dikkatli olun.

Mike Cohn'un Bir Takımın Aynı Anda Bir İş Listesi Öğesine Sürmesi Gerekiyor mu? ya da bu yazıyı (dün) daha spesifik olarak hatalarla ilgili yazdım: Sürü veya sürmem

SCRUM'un büyük bir kısmı ekibin bu tür kararlar alması gerektiğidir. Birikmiş iş listesi, kullanıcıların görevlerin oluşturulması için yeterli bilgi içeren hikayeleri içermelidir.

Bir kullanıcı hikayesini, tüm ekibin aynı anda üzerinde çalışabileceği bir öğeye zorlamak mümkün olsa da, daha da önemlisi, ekibin üzerinde çalışmak için öğeleri seçmesi, kullanıcı hikayesini bitirmek için görevleri tanımlaması ve günlük standı kullanmasıdır. vaat edilen iş ile yolda olup olmadığını görmek için.

Her seferinde sadece bir hikaye üzerinde çalışmaya çalışırken hissettiğiniz acıların ekip tarafından kabul edilmesi ve sprint retrospektif potansiyel çözümlerinin ortaya çıkarılması gerekir. Ne yaptığınızı ve nelerin iyileştirilmesi gerektiğini öğrenin.

Eşzamanlı olarak üzerinde çalışılabilecek görevleri dağıtmadaki zorluk örneğinizi kullanarak, olası bir çözüm birden fazla hikaye almak ve bir sprint'te 3 veya 4 öğe sunmaktır. Bu kullanıcı hikayesinin görevleri birbirinin üzerine kurulduğundan, işi dağıtmak zor olacaktır. Yani onu kucaklamak yerine kavga etmek yerine.

Belirtildiği gibi görevleriniz dağıtılacak kadar 'küçük' gibi görünüyor, ancak verilerin modellenmesi ve veritabanından alınması gibi görevler arasında bazı eşleşmeler var.

Mümkün olan şey, insanların bazı ekstra iş / kurulumlarla eşzamanlı olarak üzerinde çalışabileceği üç ana şeye bölünmesidir:

• Arka uç (veritabanı, model vb.)
• Ön uç (sahte veriler kullanılarak)
• Testler (beklentileri ayarlama, senaryo vb.)

Bölünemeyen görevler çiftler tarafından yapılabilir. Ve elbette, herhangi bir noktada birden fazla hikayenin devam etmesiyle doğal olarak yanlış bir şey yoktur; ekibin her üyesi diğerlerinin ne yaptığını bildiği sürece ve gerektiğinde ('paylaşılan kod sahipliği' gibi) yardımcı olabilirler.

Ekibinizi odaklanmış tutmalısınız, evet, ama aynı zamanda herkesi meşgul etmeli ve herkesi dahil etmelisiniz.

Ayrıca ekibiniz ne kadar büyük? Bu aynı zamanda bir faktördür; on kişinin bir hikaye üzerinde çalışmasını sağlamak oldukça zordur ve eğer yapabiliyorsanız, hikayeniz çok büyük, çok büyüktür ve bölünmelidir (ekibiniz gibi).