Scrum: Cara mengerjakan satu cerita pada satu waktu

Saya dinominasikan sebagai master scrum di tim scrum yang baru dibentuk. Kami telah melakukan beberapa sprint. Pada awalnya saya mencoba membuat tim saya mengerjakan satu cerita pada satu waktu. Tapi itu tidak berhasil. Tim saya mengalami kesulitan untuk mendistribusikan tugas-tugas sedemikian rupa sehingga mereka dapat bekerja secara bersamaan pada satu cerita. Mungkin kita melakukan sesuatu yang salah?

Misalnya: kami punya cerita untuk membuat dialog baru. Kami membuat tugas-tugas berikut:

• Buat kelas Model
• Baca data model dari basis data
• Hubungkan kelas model dengan tampilan
• Terapkan penanganan dialog
• Simpan data di dekat
• Dokumentasi Tes
• Deskripsi Solusi

Dapatkah tugas tesis ini dilakukan oleh lebih dari satu orang sekaligus? Tugas - lebih atau kurang - dibangun di atas satu sama lain. Atau apakah kita merancang tugas dengan cara yang salah?

Mengapa semua tim harus mengerjakan satu cerita?

Mengapa tidak membuat cerita yang cukup kecil (dan cukup mandiri) sehingga satu orang (atau lebih baik, satu pasangan melakukan pemrograman pasangan) dapat mengerjakan satu cerita. Proses ini juga membantu mendefinisikan persyaratan dengan lebih baik dan lebih memikirkan masalah dan implementasinya. Perkiraan juga mungkin menjadi lebih akurat, tetapi tidak ada jaminan di sini.

Meskipun hal ini sangat tergantung pada ukuran cerita pengguna, dalam banyak kasus hanya satu pengembang yang ditugaskan untuk sebuah cerita untuk menghindari agar pengembang Anda tidak saling menginjak-injak kaki. Meskipun cerita yang lebih besar atau sangat kompleks mungkin memerlukan lebih banyak pengembang, tetapi ada juga kemungkinan untuk memecah cerita tersebut menjadi banyak cerita yang lebih kecil yang dapat ditugaskan secara individual.

Apa yang biasanya kita lakukan adalah memecah cerita menjadi subtugas dev / infra / analyst.

1. Umumnya apa pun yang lebih dari satu hari kerja adalah sebuah cerita.

2. Setelah tugas dipecah, satu atau maksimal dua pengembang mengerjakan sebuah cerita, tergantung pada no: dari tugas yang ada. Biasanya itu salah satunya.

3. Kami mencatat waktu yang dihabiskan, dan memperbarui estimasi yang tersisa pada akhir hari sebelum kami pergi atau sebelum harian berdiri.

4. Subtugas dibuat untuk masalah baru yang muncul saat bekerja.

5. Sebuah Kisah yang bekerja lebih dari 2 minggu dianggap sebagai Epik.

6. Epik dapat terdiri dari banyak cerita

Apa yang Anda ingin dilakukan oleh tim Anda disebut berkerumun , tetapi tidak setiap item simpanan dapat dikerumuni oleh seluruh tim. Pemikiran umum adalah bahwa berkerumun membutuhkan beberapa pra-kondisi:

• tim lintas fungsional, yang ditempatkan
• cerita yang tidak sepele
• definisi "selesai" yang menyiratkan keterlibatan seluruh tim

Saat memecah cerita menjadi tugas, tim harus sudah dalam mode mengerumuni sehingga tugas yang dihasilkan kompatibel dengan mengerumuni dan dapat melibatkan seluruh tim.

Tapi hati-hati ketika menggunakan swarming terlalu sering atau dengan terlalu banyak orang sekaligus, karena Anda mungkin mengalami masalah overswarming, ketika beberapa konflik mungkin muncul di antara anggota tim karena mereka terlalu banyak mengerjakan item yang sama.

Anda mungkin ingin membaca Mike Cohn's Should a Team Berkeliaran ke One Backlog Item pada suatu Waktu? atau artikel ini saya tulis (kemarin) yang membahas bug lebih khusus: Berkerumun atau tidak berkerumun

Bagian besar dari SCRUM adalah bahwa tim harus membuat keputusan semacam ini. Tunggakan harus memiliki cerita pengguna dengan semoga informasi yang cukup untuk tugas yang dihasilkan.

Meskipun dimungkinkan untuk memaksa cerita pengguna menjadi item yang dapat dikerjakan oleh seluruh tim secara bersamaan, yang lebih penting adalah bahwa tim memilih item untuk dikerjakan, menentukan tugas untuk menyelesaikan cerita pengguna, dan menggunakan stand harian. untuk melihat apakah Anda berada di jalur dengan pekerjaan yang dijanjikan.

Rasa sakit yang Anda rasakan ketika mencoba mengerjakan hanya satu cerita pada satu waktu perlu diakui oleh tim dan dalam sprint, solusi potensial retrospektif perlu diangkat. Cari tahu apa yang Anda lakukan dengan benar dan hal-hal apa yang perlu diperbaiki.

Dengan menggunakan contoh Anda tentang kesulitan dalam mendistribusikan tugas-tugas yang dapat dikerjakan secara bersamaan, salah satu solusi yang mungkin adalah dengan mengambil beberapa cerita dan mengirimkan 3 atau 4 item dalam sprint. Karena tugas untuk kisah pengguna ini dibangun di atas satu sama lain, akan sulit untuk mendistribusikan pekerjaan. Jadi alih-alih pertarungan yang merangkulnya.

Tugas Anda, seperti yang ditunjukkan, tampak 'kecil' cukup untuk didistribusikan, tetapi ada beberapa penggabungan antara tugas-tugas seperti yang memodelkan data dan mengambilnya dari database.

Apa yang mungkin dilakukan adalah membaginya menjadi tiga hal utama yang dapat dikerjakan orang secara bersamaan, dengan beberapa pekerjaan / pengaturan tambahan:

• Back-end (database, model dll)
• Front-end (menggunakan data tiruan)
• Tes (pengaturan harapan, skenario, dll)

Tugas yang tidak dapat dibagi dapat dilakukan berpasangan. Dan tentu saja, tidak ada yang salah secara inheren dengan lebih dari satu cerita sedang berlangsung pada satu titik; selama setiap anggota tim tahu apa yang dilakukan orang lain, dan mereka dapat membantu kapan pun diperlukan (seperti dalam, 'kepemilikan kode bersama').

Anda harus membuat tim Anda fokus, ya, tetapi pada saat yang sama Anda harus membuat semua orang sibuk, dan semua orang terlibat.

Juga, seberapa besar tim Anda? Ini juga merupakan faktor; cukup sulit untuk membuat sepuluh orang mengerjakan satu cerita, dan jika Anda bisa, cerita Anda jauh, terlalu besar dan harus dipisah-pisah (seperti seharusnya tim Anda).