Menangani pekerjaan "terkait" dalam satu item kerja gesit

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.

1. 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.

2. 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?

Perencanaan lincah dan kisah pengguna difokuskan pada memberikan nilai dan transparansi kepada pemangku kepentingan proyek dan pengguna perangkat lunak. Ini adalah hal yang baik, tetapi itu tidak dan tidak seharusnya menggantikan, termasuk atau menurunkan pentingnya pedoman arsitektur yang baik, desain pelayanan, praktik pengembangan yang baik dan menjaga utang teknis.

Agile tidak melakukan yang terakhir dengan baik karena itu tidak dimaksudkan sebagai jawaban untuk sebagian besar masalah teknis dan masalah ini.

Mengetahui bahwa saya sangat tidak setuju bahwa tugas refactoring, penanganan utang teknis, dan pekerjaan desain harus menjelaskan kisah pengguna yang terpisah dalam sprint yang diberikan. Ini hanyalah tugas yang mungkin dilakukan pengembang untuk membantu memenuhi kisah pengguna untuk sprint itu.

Ingatlah bahwa Tugas adalah setiap unit pekerjaan yang ditugaskan yang membantu memindahkan cerita pengguna yang diberikan ke penyelesaian dalam pedoman arsitektur dan mempertahankan desain yang baik dan praktik devlopment dari perangkat lunak secara keseluruhan.

Inilah sebabnya mengapa estimasi jam harus pada tugas dan bukan pada cerita pengguna. Ini juga mengapa beberapa tugas sangat penting untuk penyelesaian banyak cerita pengguna.

Merah, Hijau, Refactor. Itu adalah ruang lingkup item pekerjaan tunggal. Tulis suite pengujian yang gagal yang mencakup ruang lingkup perubahan, kode jumlah minimum yang diperlukan untuk lulus tes Anda, kemudian refactor untuk memenuhi standar pengkodean sementara masih melewati tes. Ketiga langkah ini diperlukan; Anda tidak dapat membuat kode solusi hingga Anda telah menentukan masalahnya, jika Anda refactor saat Anda menulis baris kode Anda akan selalu melanggar YAGNI, tetapi jika Anda tidak datang di belakang diri Anda sendiri dan refactor setelah melewati tes, dengan definisi Anda menanggung hutang teknis Anda akhirnya harus membayar.

Dengan definisi ini, dan diikuti, 5-pointer yang ternyata 13-pointer adalah salah estimasi. Apa yang Anda anggap sebagai pekerjaan refactoring mungkin lebih seperti restrukturisasi; Anda harus mengatur ulang area basis kode yang cukup signifikan agar fungsionalitas baru dimasukkan dalam cara yang dapat dimengerti dan dipelihara. Itu biasanya menunjukkan kegagalan tim untuk memahami jalur umum pengembangan di masa depan, yang mengarah ke sesuatu yang diimplementasikan dengan sangat sederhana dalam iterasi sebelumnya ketika pada akhirnya akan diperlukan untuk menjadi sangat SOLID. Komunikasi yang lebih baik antara BA dan PM, yang tahu apa yang terjadi lebih jauh di dalam tumpukan, dan tim pengembangan yang umumnya berfokus pada sprint saat ini, dapat mengurangi ini. Bergantian, cerita ini memaparkan sejumlah besar hutang teknis yang timbul dalam pengembangan masa lalu, dan itu hanya berhasil menyusul tim. Proses peninjauan kode yang lebih baik, selain pengetahuan konseptual yang lebih baik tentang pola desain dan jalur umum proyek di masa depan, dapat membantu mengurangi kejadian semacam itu.

Satu hal yang perlu diingat adalah bahwa refactoring adalah pekerjaan "tidak ideal". Dalam Agile SCRUM, tugas diperkirakan dalam "jam ideal"; yaitu, jumlah jam yang dihabiskan untuk menulis kode baru yang tidak pernah ada dan mengembangkan basis fitur proyek. Hari pengembang 8 jam secara realistis mungkin hanya memiliki 5 jam ideal; kadang-kadang Anda dapat mengandalkan 6, terutama dalam "rentang" proyek di mana tim benar-benar bersenandung Refactoring, atau kembali dan membuat perubahan yang tidak mempengaruhi fungsi proyek tetapi yang meningkatkan basis kode dengan cara lain, adalah pekerjaan yang tidak ideal, seperti perencanaan, desain, komunikasi, peninjauan, istirahat, atau downtime teknis. Selain downtime teknis, pekerjaan yang tidak ideal itu penting, tetapi tidak membuat kemajuan di mata pemilik produk.

Jadi, asalkan refactoring tidak menggandakan jam aktual yang dihabiskan, sejumlah pekerjaan refactoring diharapkan saat Anda memperkirakan dalam jam ideal. Katakanlah, karena saya tidak tahu persis bagaimana skala poin tim Anda dikalibrasi, bahwa 5-pointer setara dengan satu minggu pengembang ideal, atau sekitar 25 jam ideal. Angka 5 itu, yang berubah menjadi 13 (lebih dari dua minggu pengembang dengan skala yang sama), menyebabkan beberapa retrospeksi tentang apa yang menyebabkan kerumitan itu membengkak. Mungkin basis kode tidak perlu sebanyak refactoring seperti yang sebenarnya dilakukan, mungkin sejumlah besar utang teknis telah menumpuk tanpa sepengetahuan tim yang harus diselesaikan untuk membuat fitur baru berfungsi,

Dalam alam semesta alternatif, mari kita bayangkan bahwa 5 seperti yang diperkirakan dalam jam ideal menjadi 7 (~ 35 jam) berdasarkan jam aktual, karena Anda memerlukan 10 jam refactoring tambahan untuk memasukkan kode baru dan beberapa bit sebelumnya ke dalam pola yang benar arsitektur desain. Dalam hal itu, ekstra berada dalam "jeda" antara jam ideal dan total selama jumlah hari pengembang yang seharusnya diambil. Jadi, sebagai manajer proyek, saya akan memanggil 5 yang menjadi 7 perkiraan yang masuk akal dan melanjutkan.

Poin cerita adalah perkiraan kompleksitas relatif dari cerita pengguna yang diberikan. Sepertinya Anda menggunakan poin cerita untuk mengatakan ini akan memakan waktu X man hari / jam. Sebaliknya, usahakan untuk dua tujuan

1. Hancurkan cerita hingga berada dalam kisaran yang konsisten (3, 5, atau 8 poin)
2. Asumsikan bahwa cerita tersebut mencakup setiap refactoring yang diperlukan

Seiring waktu, ini akan memberi Anda dasar untuk kecepatan. Setiap 5 poin cerita tidak akan mengambil jumlah waktu yang sama seperti yang lain tetapi kecepatan rata-rata per sprint (berapa banyak poin cerita yang dapat diselesaikan tim) akan konsisten.

Khawatir tentang berapa banyak waktu yang dibutuhkan sebuah cerita spesifik akan menjadi kontra produktif. Perkiraan hanya rata-rata di atas ukuran cerita yang konsisten dalam volume (IE one 5 pointer mungkin butuh waktu lebih lama karena refactoring tetapi Anda mengambil manfaat dari upaya itu pada yang terkait).

Seharusnya ada batas relatif dari berapa banyak dalam item pekerjaan asli dan berapa banyak yang lain. Cerita pengguna adalah titik awal untuk diskusi dan dengan demikian mungkin ada semua jenis elemen ruang lingkup untuk dipecahkan selama sprint saat mengerjakan sebuah cerita.

Mungkin ada saat di mana dalam perencanaan sprint sebuah cerita mungkin mendapatkan kriteria tambahan yang ditambahkan padanya dalam upaya untuk menghindari "scope creep" yang dapat terjadi di mana pengguna menginginkan formulir baru dan kemudian 101 perubahan ke bentuk yang tidak realistis untuk kadang-kadang dilakukan dalam sprint 2 minggu.

Sisi lain yang perlu diingat adalah berapa banyak nilai yang diperoleh dari kerja ekstra ini. Mungkin ada banyak kemungkinan refactoring yang bisa dilakukan tetapi berapa banyak manfaat yang ada bagi siapa pun untuk semua pekerjaan itu? Di sinilah harus ada beberapa pedoman untuk membantu menjaga tim bekerja dengan baik tetapi tidak tersesat dalam mencoba membuat kode yang sempurna.