Apakah kode refactoring acak diizinkan dalam scrum

Latar Belakang

• Tim saya menggunakan scrum
• Saat ini saya tidak punya tugas
• Tidak ada lagi tugas yang tertunda di backlog
• Hari ini adalah Hari Buruh untuk klien saya.

Tidak memiliki banyak hal yang harus dilakukan hari ini. Saya ingin memulai refactoring beberapa kode yang saya terus lihat dalam proyek yang saya kerjakan, tetapi saat ini saya tidak ditugaskan untuk tugas sprint untuk melakukan refactoring skala besar.

Apakah OK di Scrum jika saya memulai kode refactoring yang saya miliki dan belum menulis yang selalu mengganggu saya tetapi tidak punya waktu hari lain untuk memperbaikinya karena tugas hari lain?

Bagaimana dengan hari-hari lain yang saya punya waktu luang antar sprint.

Saya benar-benar melakukannya dan percaya pada refactoring berkelanjutan. Saya selalu melakukannya pada potongan kode yang saya kerjakan ketika ditugaskan cerita tetapi bagaimana dengan beberapa kode lain yang saya lihat yang saat ini tidak terkait dengan apa yang saya kerjakan pada saat itu?

Saya benar-benar tidak bermaksud menyerang jawaban lain, tetapi tidak ada orang lain yang menulis tes otomatis di sini? Inilah bacaan yang menyenangkan dari Martin Fowler untuk siapa saja yang melakukan Scrum tanpa praktik rekayasa perangkat lunak yang tepat. Robert C. Martin juga mengatakan banyak tentang ini di sini .

Jadi, untuk jawaban saya ... Singkatnya, begini:

Ya, kode refactoring "acak" diizinkan di Scrum , selama tim memutuskan bahwa itu harus dilakukan. (Setelah semua, ini mengatur diri sendiri)

Dan sekarang untuk jawaban panjang:

Jelaslah bahwa meninggalkan lebih banyak hutang teknis setelah setiap Sprint adalah resep untuk bencana. Segera, semua orang akan melambat karena kode bocomes lebih berantakan; setiap perubahan akan lebih sulit dilakukan karena kodenya sangat kusut dan berantakan sehingga butuh waktu lebih lama untuk menemukan tempat untuk berubah daripada membuat perubahan yang sebenarnya. Bahkan menjadi lebih buruk jika Anda harus membuat perubahan dalam modul besar dan berantakan yang tidak Anda ketahui, menjadi tidak mungkin untuk mendapatkan / menjaga produktivitas ketika menambah / mengganti orang dalam proyek, dan sebagainya.

Jika sebuah tim ingin menjaga kecepatannya tetap stabil, mereka harus mampu menjaga basis kode tetap bersih untuk terus meningkatkan perangkat lunak. Refactoring adalah praktik wajib jika Anda ingin menjaga kecepatan Anda sepanjang siklus hidup proyek, dan jika Anda ingin mengurangi risiko menambah / mengalihkan orang pada proyek, dan jika Anda ingin dapat membuat perubahan dalam modul Anda tidak tahu apa-apa tentang, dan sebagainya.

Namun, refactoring adalah kegiatan yang sangat berbahaya. Saya ulangi - ini adalah aktivitas yang sangat berbahaya . Yaitu, kecuali Anda memiliki cakupan tes yang cukup untuk dapat dengan aman dan bebas mengubah basis kode. Jika Anda bisa menekan tombol untuk memeriksa apakah tidak ada yang rusak, refactoring menjadi kegiatan yang sangat aman; sangat aman, pada kenyataannya, itu adalah bagian dari siklus TDD , yang merupakan praktik yang memungkinkan Anda untuk membuat test suite di tempat pertama.

Tetapi, karena tim-tim di Scrum mengatur diri sendiri, pada akhirnya tim Anda harus memutuskan apa yang benar untuk dilakukan. Saya berharap telah memberi Anda beberapa argumen jika Anda harus meyakinkan siapa pun. (Berikan perhatian khusus pada tautan di paragraf pertama, dan setiap artikel lainnya yang mereka tunjukkan)

Scrum tidak mengatakan apa-apa tentang refactoring.

Apa yang dikatakan Scrum adalah bahwa jika Anda tidak memiliki tugas dalam sprint untuk dikerjakan, Anda harus mendukung seluruh tim Anda untuk mencapai tujuan sprint. Bahkan jika itu berarti mengambilkan kopi untuk mereka.
Jika tim Anda setuju bahwa refactoring kode adalah cara terbaik Anda dapat mendukung mereka (dan itu termasuk memiliki infrastruktur untuk memastikan refactoring tidak memperkenalkan terlalu banyak bug baru), maka tentu saja lakukanlah.

Saya katakan tidak, tidak. Ini terlepas dari jenis pekerjaan (refactoring, dll).

Minimal, tugas harus dibuat dan didorong ke sprint Anda saat ini. Tujuan pelacakan waktu adalah untuk menangkap kecepatan Anda agar dapat secara efektif merencanakan sprint di masa depan. Jika Anda mengerjakan sesuatu tanpa melacaknya, Anda akan memengaruhi kecepatan dan itu tidak akan menjadi lebih baik dari waktu ke waktu seperti yang dimaksudkan dengan pelacakan yang tepat (Anda mungkin akan secara teratur tidak memiliki cukup kerja karena kecepatan yang Anda proyeksikan kurang dari kecepatan Anda yang sebenarnya ).

Adapun pekerjaan refactoring itu sendiri, saya bisa mengoceh tentang itu, tapi saya tidak akan melakukannya karena saya tidak berpikir itu adalah pertanyaan inti yang Anda coba jawab.

Saya akan mengatakan tidak juga. Re-factoring sering mengarah ke bug yang tidak diinginkan jika tidak dikelola dengan cara yang benar.

Sebagai GM, secara berkala saya akan menempatkan semua orang di proyek lain dan menghabiskan satu minggu melakukan tinjauan kode / re-factoring / mengubah nama dan menegakkan konvensi pada proyek. Sprint re-factoring ini hampir selalu bersifat kosmetik. Setiap anjak piutang fungsional akan direncanakan sebelumnya dan melibatkan pengembang asli.

Pemfaktoran ulang fungsional harus selalu direncanakan dan dikoordinasikan sebagai bagian dari proses scrum sehingga waktu dapat dilacak dan semua anggota tim yang diperlukan tersedia untuk memvalidasi proses. Satu pengembang tidak boleh mengubah kode yang ditulis oleh orang lain karena kemungkinan besar itu hanya akan mengacaukan sprint saat ini untuk semua orang. Terutama ketika menyangkut penggabungan kode waktu.

Jika itu adalah proyek di mana Anda adalah satu-satunya pemelihara dan ini adalah waktu luang Anda sendiri maka itu bisa berbeda dengan asumsi Anda mengambil langkah-langkah untuk memastikan bahwa Anda tidak menyebabkan keterlambatan yang tidak perlu dalam sprint Anda saat ini.

Jika ragu, tanyakan manajer Anda.

EDIT: Saya juga ingin menyebutkan bahwa sepotong kode tertentu yang tidak Anda sukai mungkin memiliki target kinerja tertentu yang terkait dengannya. Anda mungkin tidak menyukainya tetapi mungkin lebih cepat dari apa pun yang Anda bisa buat yang sesuai dengan keinginan Anda untuk menggunakannya. Hanya alasan lain mengapa re-factoring fungsional harus selalu menjadi proses yang dikelola.

Scrum tidak mengatakan apa-apa tentang refactoring (lihat ceramah Robert C. Martin, "Tanah yang scrum lupa").

Dalam tugas Scrum adalah fitur penargetan dari perangkat lunak Anda yang ditentukan oleh pelanggan, bukan utang teknis untuk dibayar dengan refactoring. Ini adalah level abstraksi yang sangat berbeda. Pelanggan sebagian besar tidak dapat mengevaluasi kebutuhan.

Scrum adalah manajemen proyek statistik. Untuk mendapatkan ukuran yang berarti dari "berapa lama waktu yang dibutuhkan" Anda harus mengetahui kinerjanya (output per sprint). Anda membandingkan estimasi dan durasi nyata untuk fitur setidaknya untuk lebih dari 1 sprint untuk masuk ke statistik. Saya merekomendasikan 5 sprint. Tetapi itu tergantung pada tim Anda.

Hal utama adalah menjaga ukuran tetap bermakna dan dapat diperbandingkan untuk memungkinkan perkiraan apa pun. Itu tidak akan terjadi jika kinerja menurun karena utang teknis.

Jika sekarang Anda masih memikirkan tugas refactoring Anda memiliki dua masalah: 1. Seorang pelanggan, yang tidak mengerti, mengapa dia harus menerima tugas yang tidak akan menghasilkan fitur baru 2. Anda benar-benar mengubah statistik Anda dan karenanya kemampuan Anda untuk memperkirakan saat Anda tiba-tiba mengubah variabel berbeda yang tidak dipertimbangkan dalam sprint sebelumnya

Dalam kedua kasus Anda kompromi gagasan scrum karena Anda ingin berbicara tentang fitur dengan pelanggan DAN membuat perkiraan yang andal untuk "Berapa lama waktu yang dibutuhkan?" secara statistik. Agar aman, Anda harus menjaga basis kode Anda dalam kualitas yang konstan (mungkin tinggi).

Refactoring seringkali merupakan tugas bawah tanah. Refactoring "Hebat" berarti refactoring "kecil" belum pernah diproses sebelumnya.

Satu catatan terakhir: Jika Anda melakukan refactoring pastikan Anda memiliki komponen yang diuji Anda refactoring. Ohh, kamu tidak punya tes? Buat tugas untuk menulis tes. Pelanggan Anda akan senang mengetahui bahwa perangkat lunak yang ia gunakan saat ini tidak memiliki cakupan pengujian yang cukup ...

Jauhkan barang-barang teknis dari pelanggan dan lakukan pekerjaan Anda sebagai pengembang profesional.

Inilah satu pendekatan: lakukan keduanya!

Refactoring seringkali rawan kesalahan atau lebih memakan waktu yang awalnya diperkirakan sebagai @misterbiscuit.

Jadi pertimbangkan upaya untuk melakukannya sebagai draf atau lonjakan. Anda tidak perlu meminta persetujuan atau beriklan jika pada tahap ini.

Lalu, coba sertakan melalui salah satu dari dua saluran:

• tiket yang ada yang menyentuh kode / fungsi yang sama di mana Anda dapat dengan wajar memasukkan ini. Cukup sesuai kesepakatan dengan sesama anggota tim.
• seluruh tiket untuk ditinjau di perawatan tiket berikutnya (atau pertemuan mingguan, dll. jika air terjun). Pada saat itu Anda dapat membuat kasing untuk itu.

Setelah Anda menerima pembelian aktual, Anda bisa menerapkan atau mengulang lonjakan Anda dan membuat kode aktual digabungkan ke cabang jalur utama (master, dll.).

Ini akan memiliki beberapa keunggulan:

• Semua kode kode Anda melalui proses yang sama, diuji, QA, dalam saluran rilis, dll.
• Anda mendapatkan persetujuan formal, termasuk dari manajer produk, bahwa refactoring adalah bagian dari kerajinan dan bukan sesuatu yang perlu 'diselinapkan' pada hari libur. Tanyakan kepada diri sendiri mengapa Anda tidak 'menyelinap masuk' fitur yang sebenarnya dapat membantu untuk perspektif.
• Anda dapat meminta pasangan, ulasan kode, qa, devops dan semua dukungan lain yang mungkin diperlukan untuk perubahan kode anjak piutang. Semuanya akan resmi, sesuai dengan Kebijakan dan Prosedur dan di atas papan.
• Jika Anda adalah perusahaan publik dengan kepatuhan SOX Anda mungkin ingin / perlu melakukan semacam proses formal (yaitu mendokumentasikannya dan kemudian mengikutinya).
• Anda mendapatkan reputasi yang lebih baik dengan manajer produk (perubahan dilakukan dengan cepat) dan tim pengembangan (basis kode ditingkatkan).
• Organisasi berusaha untuk memperhatikan kualitas kode yang baik untuk produktivitas, moral, retensi karyawan dan banyak alasan lainnya.
• Efeknya pada kecepatan proyek dapat lebih mudah dilacak ketika semua pekerjaan dimasukkan. Bisa saja tidak menunjuk titik apa pun karena kehadiran itu sendiri dapat digunakan untuk mempengaruhi kecepatan.
• Pengembang cenderung melihat alat yang mendorong ulasan kode yang lebih mudah seperti Fisheye, Github, dll.
• Pengembang lebih cenderung melihat beberapa standar dasar (kadang-kadang didokumentasikan, kadang tidak) yang membuat kode berbagi dan karenanya refactoring lebih mudah. Kadang-kadang sebagian besar refactoring memilih gaya dan kemudian menerapkannya secara luas (mengganti campuran pendekatan dengan satu).

Komentar terakhir: Hindari manajer produk yang mendengar kata 'acak'. Mereka mungkin merespons lebih baik dengan peningkatan kode yang 'ditargetkan, strategis, dan meningkatkan kinerja'. Atau paket layanan aplikasi. Atau bahasa apa pun yang memberi Anda liputan.

Refactoring acak tidak masuk akal. Yang masuk akal adalah refactoring kode yang akan memberikan manfaat paling besar. Itu berarti :

• memperbaiki masalah desain atau arsitektur
• meningkatkan implementasi

Apakah OK di Scrum jika saya memulai kode refactoring yang saya miliki dan belum menulis yang selalu mengganggu saya tetapi tidak punya waktu hari lain untuk memperbaikinya karena tugas hari lain?

Dari jawaban ini :

Menjaga kode yang bisa dikelola perlu menjadi item dalam daftar burn-down Anda (jika Anda menggunakan Scrum). Ini sama pentingnya dengan perkembangan baru. Meskipun mungkin tidak tampak seperti sesuatu yang "terlihat oleh pengguna", mengabaikannya meningkatkan hutang teknis Anda. Di ujung jalan ketika utang teknis menumpuk cukup sehingga kurangnya pemeliharaan kode Anda memperlambat pengembangan, penundaan dalam pengembangan fitur baru akan terlihat oleh pelanggan.

Dalam pekerjaan saya sebelumnya, kami memiliki semacam scrum, dengan sprint yang lebih besar (2-3 bulan). Karena kami memiliki beberapa penundaan antara sprint (1 bulan), kami menggunakan waktu ini untuk menganalisis perangkat lunak, dan memperbaiki kode.