Saya berada di tim proyek dengan 4 devs, termasuk saya sendiri. Kami telah melakukan diskusi panjang tentang bagaimana menangani pekerjaan tambahan yang muncul dalam satu item pekerjaan.
Pekerjaan ekstra ini biasanya hal-hal yang sedikit terkait dengan tugas, tetapi tidak selalu diperlukan untuk mencapai tujuan item (yang mungkin merupakan pendapat). Contohnya termasuk tetapi tidak terbatas pada:
- refactoring kode yang diubah oleh item pekerjaan
- kode refactoring yang berdekatan kode diubah oleh item
- merancang ulang area kode yang lebih besar di sekitar tiket. Sebagai contoh jika suatu item membuat Anda mengubah fungsi tunggal, Anda menyadari bahwa seluruh kelas sekarang dapat diulang untuk mengakomodasi perubahan ini dengan lebih baik.
- meningkatkan UI pada formulir yang baru saja Anda modifikasi
Ketika pekerjaan ekstra ini kecil, kami tidak keberatan. Masalahnya adalah ketika kerja ekstra ini menyebabkan ekstensi substansial item di luar estimasi titik fitur asli. Terkadang item 5 poin justru membutuhkan waktu 13 poin. Dalam satu kasus kami memiliki item 13 poin yang dalam retrospeksi bisa 80 poin atau lebih.
Ada dua opsi yang ada dalam diskusi kita untuk bagaimana menangani hal ini.
Kami dapat menerima pekerjaan tambahan dalam item pekerjaan yang sama, dan menghapusnya sebagai salah estimasi. Argumen untuk ini sudah termasuk:
- Kami berencana untuk "mengisi" di akhir sprint untuk menjelaskan hal semacam ini.
- Selalu biarkan kode dalam kondisi yang lebih baik daripada yang Anda temukan. Jangan mengecek pekerjaan setengah-setengah.
- Jika kita meninggalkan refactoring untuk nanti, sulit untuk menjadwalkan dan mungkin tidak pernah selesai.
- Anda berada dalam "konteks" mental terbaik untuk menangani pekerjaan ini sekarang, karena Anda sudah berada jauh di dalam kode. Lebih baik menyingkirkannya sekarang dan lebih efisien daripada kehilangan konteks itu ketika Anda kembali lagi nanti.
Kami menarik garis untuk item pekerjaan saat ini, dan mengatakan bahwa pekerjaan tambahan masuk ke tiket terpisah. Argumen meliputi:
- Memiliki tiket terpisah memungkinkan untuk estimasi baru, jadi kami tidak membohongi diri sendiri tentang berapa banyak poin sebenarnya, atau harus mengakui bahwa semua estimasi kami mengerikan.
- Sprint "padding" dimaksudkan untuk tantangan teknis yang tidak terduga yang merupakan hambatan langsung untuk menyelesaikan persyaratan tiket. Ini tidak dimaksudkan untuk item sampingan yang hanya "baik untuk dimiliki".
- Jika Anda ingin menjadwalkan refactoring, cukup letakkan di bagian atas tumpukan.
- Tidak ada cara bagi kami untuk memperhitungkan hal ini dengan benar dalam estimasi, karena tampaknya agak sewenang-wenang ketika muncul. Peninjau kode mungkin mengatakan "kontrol UI (yang sebenarnya tidak Anda modifikasi dalam item pekerjaan ini) agak membingungkan, dapatkah Anda memperbaikinya juga?" yang seperti satu jam, tetapi mereka mungkin mengatakan "Ya, jika kontrol ini sekarang mewarisi dari kelas dasar yang sama dengan yang lain, mengapa Anda tidak memindahkan semua ini (ratusan baris) kode ke basis dan rewire semua hal ini , perubahan cascading, dll? " Dan itu membutuhkan waktu seminggu.
- Ini "mencemari TKP" dengan menambahkan pekerjaan yang tidak terkait ke dalam tiket, membuat estimasi titik fitur asli kami menjadi tidak berarti.
- Dalam beberapa kasus, pekerjaan tambahan menunda check-in, menyebabkan pemblokiran antara devs.
Beberapa dari kita sekarang mengatakan bahwa kita harus memutuskan beberapa cut off, seperti jika barang tambahan kurang dari 2 FP, itu masuk dalam tiket yang sama, jika lebih, buatlah itu menjadi tiket baru.
Karena kita hanya beberapa bulan menggunakan Agile, apa pendapat semua veteran Agile yang lebih berpengalaman di sekitar sini tentang cara menangani ini?