Refactoring dalam pengembangan Agile
Dalam proyek pengembangan aplikasi, cakupan penuh proyek tidak dipertimbangkan dalam desain aplikasi. Jadi, seringnya refactoring kode untuk mengakomodasi perubahan berdampak negatif pada timeline pengiriman proyek, yang menjadi penting selama sprint. Seberapa baik hal ini dapat dikontrol untuk meminimalkan risiko melampaui tanggal penyerahan proyek yang disepakati, karena pemangku kepentingan tidak bersedia berkompromi?
Jawaban
TL; DR
Bagian dari kerangka kerja manajemen proyek, terutama kerangka kerja tangkas seperti Scrum, adalah kebutuhan untuk terus mengelola harapan pemangku kepentingan. Orang-orang menginginkan apa yang mereka inginkan ketika mereka menginginkannya, tetapi sebagian besar dari manajemen proyek menjelaskan kepada orang-orang apa yang sebenarnya dapat mereka miliki dalam berbagai kendala yang berdampak pada proyek. Seiring dengan berkembangnya proyek, demikian juga pemahaman tentang apa yang saat ini layak dilakukan dalam batasan saat itu, terutama ketika apa yang layak menyimpang dari apa yang semula direncanakan.
Pengerjaan ulang diharapkan
Merefaktor implementasi perubahan tanpa mengubah perilaku eksternal. Kemungkinan besar, Anda tidak benar-benar melakukan refactoring; Anda membayar hutang teknis, atau melakukan pengerjaan ulang dan integrasi, yang secara intrinsik bukanlah hal yang sama.
Kerangka kerja seperti Scrum memperlakukan berbagai jenis pekerjaan (termasuk pemfaktoran ulang dan pengerjaan ulang) sebagai trade-off yang dapat diterima untuk kontrol dan desain empiris. Ini ditangani dalam proses estimasi, dan (dengan benar) muncul sebagai hambatan pada kecepatan saat utang teknologi, kompleksitas, atau laju perubahan meningkat. Ini diharapkan dan diinginkan dalam kerangka kerja berulang, karena setiap putaran inspeksi-dan-adaptasi memberikan kesempatan untuk mengubah cakupan, prioritas, atau pendekatan.
Pengerjaan ulang adalah biaya pengendalian empiris. Anda tidak dapat menghindarinya dalam proyek kompleks seperti pengembangan perangkat lunak. Scrum hanya membuat pengerjaan ulang terlihat oleh tim dan pemangku kepentingan sebagai biaya untuk membuat perubahan yang diperlukan atau diinginkan.
Tetap-Segalanya Tidak Mungkin
"Segitiga besi" menyatakan bahwa Anda dapat menyesuaikan proyek dengan mengontrol anggaran, ruang lingkup, atau jadwal, dengan kualitas dimensi keempat implisit dipengaruhi oleh tiga slider lainnya. Grafik berikut menggambarkan hal ini.
Kerangka kerja tangkas seperti Scrum umumnya memperlakukan cakupan, dan terutama cakupan proyek , sebagai penggeser utama dengan menanyakan:
Berapa banyak ruang lingkup yang bisa kita muat ke dalam kotak waktu satu Sprint, atau sesuai dengan rencana rilis tangkas kita ?
Saat ini, project Anda sedang mencoba untuk memperbaiki cakupan dan jadwal. Itu hanya menyisakan anggaran sebagai slider yang tersedia. Jika Anda mencoba untuk menguncinya juga, maka proyek Anda akan gagal, atau kualitas akan menurun, atau keduanya. Anda tidak bisa dengan mudah melakukan harga tetap, ruang lingkup tetap, dan jadwal tetap dalam kerangka kerja proyek apa pun sambil mempertahankan kualitas; Scrum membuatnya lebih jelas, dan membuat trade-off lebih terlihat.
Inti dari Scrum bukanlah untuk secara ajaib menghilangkan segitiga besi tersebut. Sebaliknya, hal itu memaksa proyek (serta pemangku kepentingan dan sponsor) untuk menerima trade-off yang melekat. Scrum memungkinkan para pemangku kepentingan untuk menentukan apakah sesuatu "cukup baik" untuk dikirim di akhir setiap Sprint, dan Pemilik Produk mendapat kesempatan untuk menyesuaikan ruang lingkup dan prioritas selama Perbaikan Backlog dan Perencanaan Sprint. Para pemangku kepentingan perlu memanfaatkan acara ini sebagai cara untuk memastikan mereka mendapatkan nilai paling layak dalam rencana rilis; tidak pernah ada jaminan uang kembali bahwa proyek tersebut akan 100% selesai atau sesuai untuk tujuan di akhir seri tetap Sprint.
Kurangi Biaya Sunk
Aspek lain dari perkembangan tangkas adalah peluang untuk "gagal lebih awal". Ketika sebuah proyek kemungkinan besar gagal karena alasan apa pun, kerangka kerja yang gesit seperti Scrum memberi Pemilik Produk kesempatan untuk menghemat uang dengan membatalkan Sprint dan merencanakan yang baru berdasarkan ekspektasi yang berubah, atau mengizinkan pemangku kepentingan untuk membatalkan sisa proyek jika itu tidak akan memenuhi tujuan mereka. Yang terakhir tidak akan membuat proyek berhasil, tetapi akan mengurangi biaya hangus yang terkait dengan proyek.
Tidak ada yang bisa menjamin bahwa proyek akan berhasil. Hal terbaik yang dapat Anda lakukan adalah mengontrolnya, dan menghentikan proyek yang hancur sedini mungkin saat kesuksesan tidak lagi menjadi pilihan.
Yang Dapat Anda Lakukan Sekarang
Pertama, akui bahwa Anda sedang berada di jalan menuju mars kematian. Jika Anda tidak mau menghadapi kebenaran itu, tidak ada hal lain yang Anda lakukan yang penting.
Selanjutnya, cari tahu apakah masalahnya adalah desain, utang teknologi, ekspektasi yang tidak masuk akal, atau hal lain. Tidak peduli apa akar penyebab atau penyebabnya; Anda hanya perlu membuatnya terlihat sehingga tim dan pemangku kepentingan dapat secara kolaboratif mengatasinya.
Terakhir, komunikasikan status saat ini dengan jelas. Jika Anda sedang dalam kecepatan untuk rilis fitur lengkap beberapa siklus setelah tanggal pengiriman yang semula diproyeksikan, diskusikan apakah proyek dapat menyesuaikan titik "waktu". Jika Anda tidak dapat atau tidak mau menyesuaikan jadwal, maka Anda masih dapat memenuhi tenggat waktu tetap dengan meningkatkan biaya atau mengurangi cakupan. Akankah pemangku kepentingan memperdagangkan pengiriman tepat waktu untuk memotong beberapa fungsionalitas yang memakan waktu? Anda tidak akan tahu kecuali Anda bertanya.
Jika proyek tidak dapat atau tidak akan melakukan hal-hal di atas, maka bersiaplah untuk kegagalan. Perbaiki resume Anda, dan berharap Anda telah mempelajari pelajaran berharga yang dapat Anda gunakan pada proyek atau pekerjaan berikutnya. Yang terpenting, berharap bahwa Anda telah belajar berkomunikasi lebih awal dan sering tentang asumsi, tantangan, persyaratan kerangka kerja dan pertukaran, dan menginternalisasi pentingnya mengelola harapan pemangku kepentingan secara terus-menerus.
Apakah Anda menghasilkan peningkatan produk yang dapat diterapkan di setiap sprint? Jika demikian, maka tanggal pengiriman yang disepakati sudah terpenuhi dan itu adalah cara terbaik untuk meminimalkan risiko dan memberikan kepercayaan pelanggan pada apa yang Anda lakukan. Pemangku kepentingan (melalui pemilik produk) harus memutuskan hal-hal yang mereka inginkan dan kapan, jadi yang paling penting adalah mereka terus melihat Anda memberikan nilai dan bahwa Anda mendapatkan umpan balik mereka tentang peningkatan, perubahan, dan perbaikan yang diperlukan untuk produk. Mendapatkan tanggapan mereka adalah kuncinya di sini. Dapat dipahami bahwa pelanggan akan khawatir jika garis waktu diperpanjang tanpa cakupan fungsional baru, tetapi segera setelah Anda mulai memasukkan peningkatan terbaru yang mereka anggap sebagai prioritas, mereka akan lebih menghargai kebutuhan akan fleksibilitas.