Memperkirakan biaya waktu dalam basis kode warisan

Baru-baru ini saya mulai mengerjakan sebuah proyek di mana aplikasi monolitik yang sangat lama sedang dimigrasikan ke dalam arsitektur berbasis layanan-mikro.

Basis kode warisan sangat berantakan ('kode spageti') dan seringkali fungsi yang tampaknya sederhana (misalnya dinamai "multiplyValueByTen") kemudian mengungkapkan dirinya sebagai "ribuan baris kode validasi yang melibatkan 10 tabel di 3 skema berbeda".

Sekarang bos saya (benar) meminta saya untuk memperkirakan berapa lama waktu yang dibutuhkan untuk menulis fitur X dalam arsitektur baru. Tetapi saya mengalami kesulitan menghasilkan estimasi yang realistis; sering saya sangat meremehkan tugas karena alasan yang telah saya sebutkan di atas dan mempermalukan diri sendiri karena saya tidak dapat menyelesaikannya tepat waktu.

Hal yang masuk akal mungkin tampaknya benar-benar masuk ke dalam kode, catat setiap cabang dan panggilan ke fungsi lain dan kemudian perkirakan biaya waktu. Tetapi sebenarnya ada perbedaan yang sangat kecil antara mendokumentasikan kode lama dan benar-benar menuliskan versi baru.

Bagaimana saya harus mendekati skenario seperti ini?

Sementara saya benar-benar mengerti bagaimana refactoring kode lama bekerja, pertanyaan saya bukan tentang "bagaimana melakukan refactor / menulis ulang?" tetapi tentang memberikan jawaban yang realistis untuk "berapa lama waktu yang dibutuhkan untuk refactor / menulis ulang bagian X?"

Baca "Clean Coder" Bob Martin (dan "Clean Code" saat Anda melakukannya). Berikut ini dari memori tetapi saya sangat menyarankan Anda membeli salinan Anda sendiri.

Yang perlu Anda lakukan adalah rata-rata tertimbang tiga poin. Anda melakukan tiga perkiraan untuk setiap karya:

• skenario kasus terbaik - dengan asumsi semuanya berjalan dengan baik (a)
• skenario terburuk - dengan asumsi semuanya salah (b)
• tebakan sebenarnya - apa yang menurut Anda mungkin akan dilakukan (c)

Estimasi Anda adalah (a + b + 2c) / 4

• Tidak, itu tidak akan akurat. Ada cara yang lebih baik untuk memperkirakan tetapi metode ini cepat, mudah dipahami dan mengurangi optimisme dengan membuat Anda mempertimbangkan kasus terburuk.
• Ya, Anda harus menjelaskan kepada manajer Anda bahwa Anda tidak terbiasa dengan kode dan bahwa terlalu tidak dapat diprediksi bagi Anda untuk membuat estimasi yang akurat dan tegas tanpa menghabiskan waktu lama menyelidiki kode setiap kali untuk meningkatkan estimasi (penawaran untuk melakukan ini tetapi katakanlah Anda perlu n hari hanya untuk memberikan perkiraan pasti berapa hari lagi diperlukan). Jika Anda seorang "JuniorDev" ini harus dapat diterima untuk manajer yang masuk akal.
• Anda juga harus menjelaskan kepada manajer Anda bahwa estimasi Anda dirata-rata, berdasarkan pada kasus terbaik, kasus terburuk, dan kemungkinan kasus serta memberi mereka angka Anda yang juga memberi mereka bilah kesalahan.
• JANGAN bernegosiasi berdasarkan perkiraan - jika manajer Anda mencoba menggunakan kasus terbaik untuk setiap perkiraan (mereka bodoh - tapi saya sudah bertemu beberapa seperti itu) dan kemudian menggertak / memotivasi Anda untuk mencoba mencapai batas waktu, well, mereka Terkadang akan kecewa. Terus jelaskan alasan di balik perkiraan, (kasus terbaik, kasus terburuk, dan kemungkinan kasus) dan terus mendekati rata-rata tertimbang paling sering dan Anda harus baik-baik saja. Selain itu, untuk keperluan Anda sendiri, simpan spreadsheet dari taksiran Anda dan tambahkan aktual Anda setelah selesai. Itu seharusnya memberi Anda ide yang lebih baik tentang bagaimana menyesuaikan perkiraan Anda.

Sunting:

Asumsi saya ketika saya menjawab ini:

1. OP adalah Pengembang Junior (berdasarkan nama pengguna yang dipilih). Oleh karena itu, setiap saran yang diberikan tidak dari perspektif Manajer Proyek atau Ketua Tim yang mungkin diharapkan dapat melakukan estimasi yang lebih canggih tergantung pada kematangan lingkungan pengembangan.
2. Manajer Proyek telah membuat rencana Proyek yang terdiri dari sejumlah besar tugas yang direncanakan akan memakan waktu beberapa bulan untuk dilaksanakan.
3. OP diminta untuk memberikan sejumlah perkiraan untuk tugas-tugas yang ditugaskan oleh Manajer Proyek mereka yang menginginkan angka yang cukup akurat (bukan kurva probabilitas :)) untuk dimasukkan ke dalam rencana proyek dan digunakan untuk melacak kemajuan.
4. OP tidak memiliki minggu untuk menghasilkan setiap perkiraan dan telah dibakar sebelumnya dengan memberikan perkiraan yang terlalu optimis dan menginginkan metode yang lebih akurat daripada menempelkan jari di udara dan mengatakan "2 minggu, kecuali jika kode itu sangat misterius dalam hal ini 2 bulan atau lebih".

Rata-rata tertimbang tiga poin berfungsi dengan baik dalam kasus ini. Cepat, dapat dipahami oleh non-teknis dan lebih dari beberapa perkiraan harus rata-rata untuk sesuatu yang mendekati akurasi. Terutama jika OP mengambil saran saya tentang menyimpan catatan estimasi dan aktual. Ketika Anda tahu seperti apa dunia nyata "Kasus terburuk" dan "Kasus terbaik" seperti Anda dapat memasukkan yang sebenarnya ke perkiraan masa depan Anda dan bahkan menyesuaikan perkiraan untuk manajer proyek Anda jika kasus terburuk lebih buruk dari yang Anda duga.

Mari kita lakukan contoh yang berhasil:

• Kasus terbaik, dari pengalaman tercepat yang pernah saya lakukan yang benar-benar mudah adalah satu minggu mulai dari selesai (5 hari)
• Kasus terburuk, dari pengalaman, ada waktu di mana ada tautan di mana-mana dan akhirnya saya butuh waktu 6 minggu (30 hari)
• Perkiraan Aktual, mungkin saya butuh 2 minggu (10 hari)

5 + 30 + 2x10 = 55

55/4 = 13,75 yang Anda katakan kepada PM Anda. Mungkin Anda mengumpulkan hingga 14 hari. Seiring waktu, (mis. Sepuluh tugas), seharusnya rata-rata habis.

Jangan takut untuk menyesuaikan formula. Mungkin setengah dari tugas berakhir dengan mimpi buruk dan hanya sepuluh persen yang mudah; sehingga Anda membuat estmate a / 10 + b / 2 + 2c / 5. Belajarlah dari pengalaman Anda.

Catatan, saya tidak membuat asumsi tentang kualitas PM. PM yang buruk akan memberikan perkiraan singkat kepada dewan proyek untuk mendapatkan persetujuan dan kemudian menggertak tim proyek untuk mencoba dan mencapai batas waktu yang tidak realistis yang telah mereka janjikan. Satu-satunya pertahanan adalah menyimpan catatan sehingga Anda dapat terlihat memberikan perkiraan dan mendekati mereka.

Ini mungkin saat yang tepat untuk memperkenalkan pendekatan semi-agile. Jika alih-alih memperkirakan dalam hitungan jam / hari, Anda mengalokasikan skala tipe fibonacci & memberi nilai pada setiap tugas berdasarkan seberapa besar itu:

• 0 - instan
• 0,5 - kemenangan cepat
• 1 - perubahan sederhana
• 2 - beberapa perubahan sederhana
• 3 - lebih menantang
• 5 - akan membutuhkan pemikiran
• 8 - sejumlah besar pekerjaan
• 13 - sebagian besar pekerjaan yang mungkin perlu dipecah
• 20 - sebagian besar pekerjaan yang pasti perlu dipecah

Kemudian begitu Anda memperkirakan banyak tugas seperti ini, Anda mengerjakannya. Dalam lingkungan yang gesit Anda mengembangkan 'kecepatan' yang merupakan ukuran berapa banyak poin yang Anda capai dalam, katakanlah, seminggu. Setelah Anda melakukan beberapa minggu tes dan belajar (Anda dapat menjual ini kepada manajer Anda sebagai bagian dari proses - "Saya akan memerlukan beberapa minggu tes & belajar untuk memahami proses estimasi"), Anda akan lebih percaya diri dalam berapa banyak poin yang Anda dapat mendorong melalui setiap minggu & karena itu Anda dapat menerjemahkan estimasi poin Anda lebih mudah ke dalam waktu.

https://pm.stackexchange.com/questions/4251/why-would-teams-use-the-fibonacci- berikutnyaence-for-story-points

https://stackoverflow.com/questions/9362286/why-is-the-fibonacci-series-used-in-agile-planning-poker

Ini tidak benar-benar gesit karena tidak akan melibatkan upacara tetapi saya mendapatkan ide dari OP bahwa dia sendirian. Semoga pendekatan ini dapat memberikan beberapa perkiraan yang lebih percaya diri.

Hal pertama yang Anda lakukan adalah mulai mengumpulkan data tentang berapa lama Anda menyelesaikan sesuatu sekarang. Semakin banyak data yang Anda miliki tentang kinerja tim Anda, semakin baik. Ini akan menjadi seluruh papan, tetapi jangan khawatir tentang itu sekarang. Itu kebenaran dan Anda harus menunjukkan realitas bos Anda.

Maka Anda akan pergi membeli beberapa buku.

1. Estimasi Perangkat Lunak: Demistifying the Black Art oleh Steve McConnell
2. Bekerja Efektif dengan Legacy Code oleh Michael Feathers

Buku McConnell akan memberitahu Anda untuk mulai mengumpulkan data dan kemudian menjelaskan bagaimana menggunakannya untuk mendapatkan perkiraan yang lebih akurat. Selalu berikan perkiraan 3 poin! Selalu. Pastikan untuk menyorot bagian-bagian buku yang berbicara tentang bagaimana kualitas kode yang buruk akan menghancurkan perkiraan Anda. Tunjukkan pada atasan Anda.

Jelaskan bahwa jika perkiraan akurat penting bagi perusahaan, Anda harus mulai menerapkan hal-hal yang Anda pelajari dari buku Feather. Jika Anda ingin menjalankan dengan cepat, lancar, dan dapat diprediksi, Anda harus mulai refactoring kode dan membawanya ke dalam test harness. Aku benar di mana kamu berada. Waktu pengembangan benar-benar tidak dapat diprediksi karena Anda tidak tahu apa yang bisa Anda hancurkan, kan? ... Ya. Bawa ke test harness. Server CI untuk menjalankan tes-tes itu juga tidak ada salahnya.

Terakhir, jelaskan kepada atasan Anda bahwa beberapa hal masih akan sedikit tidak dapat diprediksi untuk sementara waktu. Mungkin beberapa tahun, tetapi pengembangan itu akan menjadi lebih mudah setiap hari dan perkiraan akan menjadi lebih akurat karena Anda memiliki lebih banyak data dan kode menjadi lebih baik. Ini adalah investasi jangka panjang bagi perusahaan. Saya telah melalui ini baru-baru ini, butuh hampir 2 tahun untuk menjadi sebagian besar dapat diprediksi.

Saya tahu saya berbicara lebih banyak tentang meningkatkan kode daripada memperkirakan, tetapi kebenarannya adalah bahwa perkiraan Anda akan buruk sampai Anda dapat menjinakkan basis kode lawas. Sementara itu, gunakan kinerja bersejarah untuk mengukur berapa lama. Seiring berlalunya waktu, Anda harus mempertimbangkan apakah Anda sudah mendapatkan kode sesuai dengan perkiraan dalam perkiraan Anda.

Sekarang bos saya dengan tepat bertanya kepada saya perkiraan berapa lama waktu yang dibutuhkan untuk menulis fitur X dalam arsitektur baru. Tetapi saya mengalami kesulitan menghasilkan estimasi yang realistis; sering kali saya meremehkan tugas karena alasan yang telah saya sebutkan di atas dan mempermalukan diri sendiri karena saya tidak dapat menyelesaikan tepat waktu.

Anda mungkin berpikir dalam kotak pengiriman satu estimasi. Saya harus bekerja dalam kode warisan, dan ketika saya membuat perkiraan yang lebih formal, saya biasanya membuat dua atau tiga :

1. Estimasi Primer - dengan asumsi bahwa saya harus meluangkan waktu untuk menggali tetapi arsitektur memungkinkan perubahan yang kita inginkan
2. Angelic Estimate - mengasumsikan bahwa semuanya transparan / mudah ditemukan dan saya hanya perlu melakukan perubahan kecil (ini yang saya tinggalkan kadang-kadang ... terutama jika saya tahu hanya ada setan dalam basis kode tertentu)
3. Perkiraan Abyssal - mengasumsikan bahwa struktur dasar kode warisan tidak sesuai dengan fitur yang diminta dan saya akan melakukan refactoring besar untuk membuat semuanya berfungsi

Ketiga perkiraan memperhitungkan betapa sulitnya fitur itu sendiri, pengalaman apa pun yang saya miliki dengan basis kode umum, dan firasat saya tentang perubahan (yang saya temukan bisa sangat akurat)

Setelah perkiraan ini keluar, saya terus memperbarui informasi tentang manajer mana yang sedang kami hadapi. Jika ternyata kita sedang melihat fitur abyssal, maka kita mungkin harus mengorbankannya - itu terjadi. Jika bos Anda tidak dapat menerima bahwa ada fitur abyssal untuk sepotong kode warisan yang diberikan, maka saya berharap semoga mereka beruntung, karena mereka akan memiliki kehidupan yang sangat sulit dan membuat frustrasi.

Ketika saya menghadapi masalah semacam ini, saya mengandalkan memberikan kisaran pada perkiraan saya. Saya telah pergi dengan memberi tahu atasan saya "sulit untuk melakukan taksiran baik-baik di basis kode ini. Jika Anda memintanya, itu akan menjadi perkiraan yang sangat luas." Saya telah memberikan "3 hari hingga 3 tahun" sebagai perkiraan sekali. Tak perlu dikatakan itu bukan perkiraan populer, tapi itulah yang saya berikan.

Kunci dari ini adalah perjanjian bahwa saya akan memperbarui perkiraan saya saat pekerjaan sedang berlangsung. Jadi jika saya diberi tahu "Terapkan XYZ, berapa lama waktu yang dibutuhkan?" jawaban saya mungkin "di suatu tempat antara satu hari dan 4 bulan. Namun, jika Anda membiarkan saya benar-benar melihat kode selama beberapa jam, saya dapat mengurangi ketidakpastian di jendela itu." Saya kemudian melihat kode dan kembali dengan "2 hingga 4 minggu." Itu masih bukan jendela yang ideal, tapi setidaknya itu adalah sesuatu yang bisa dikelola.

Ada beberapa kunci untuk ini:

• Yakinkan bos bahwa perkiraan ini lebih baik diperlakukan sebagai percakapan karena Anda akan belajar lebih banyak tentang seperti apa tugas itu saat Anda mengerjakannya. Ini adalah kesempatan bagi bos Anda untuk memiliki informasi yang tidak akan mereka miliki jika mereka hanya meminta satu perkiraan saja.
• Menawarkan opsi-opsi tentang bagaimana cara maju yang mana pengembangan kode perdagangan yang mempercepat dan meningkatkan perkiraan. Beri mereka tombol tambahan yang bisa mereka putar. Kadang-kadang bos tahu tugas hanya perlu diselesaikan, dan mereka hanya membutuhkan perkiraan kasar. Di lain waktu mereka menjalankan pro dan kontra dari suatu tugas, dan kemampuan untuk memperbaiki estimasi sangat berharga.
• Jika memungkinkan, saya juga akan menawarkan bonus sinergi. Seringkali ada perbaikan arsitektur yang akan bermanfaat bagi banyak tugas. Jika saya memiliki 10 tugas yang semuanya membutuhkan waktu "1-2 bulan sekarang, tetapi akan memakan waktu 2 minggu dengan upgrade X," lebih mudah untuk menjual 20 minggu yang mungkin diperlukan untuk upgrade X.

Jika saya memiliki bos yang tidak nyaman menerima kisaran yang diperbarui saat saya pergi, saya akan memberi mereka satu nomor dan metodologi saya. Metodologi saya adalah kombinasi dari aturan praktis yang telah saya sampaikan sebagai pengembang muda, dan hukum Hofstader .

Perkirakan berapa lama Anda pikir tugas itu harus dilakukan, kemudian lipat empat angka itu dan berikan itu sebagai perkiraan Anda.

dan

Hukum Hofstadter: "Selalu lebih lama dari yang Anda harapkan, bahkan ketika Anda memperhitungkan Hukum Hofstadter."

Hal yang masuk akal mungkin tampaknya benar-benar masuk ke dalam kode, catat setiap cabang dan panggilan ke fungsi lain dan kemudian perkirakan biaya waktu. Tetapi sebenarnya ada perbedaan yang sangat kecil antara mendokumentasikan kode lama dan benar-benar menuliskan versi baru.

Ini adalah solusi untuk masalah Anda. Anda tidak dapat memperkirakan jika Anda tidak memiliki persyaratan. Beri tahu atasan Anda bahwa Anda perlu melakukan ini sebelum dapat mulai membuat kode. Setelah beberapa fungsi dan modul, Anda mungkin menemukan mereka semua telah dikodekan secara konsisten (dalam hal ini buruk), sehingga Anda memiliki garis dasar untuk menentukan perkiraan di masa mendatang. Pastikan Anda menyesuaikan taksiran Anda jika ternyata kodenya bertambah buruk.

Saya menyadari bahwa atasan Anda menginginkan perkiraan, tetapi tanpa mengetahui bagaimana informasi ini digunakan, kami tidak tahu seberapa tepat perkiraan Anda. Bicara dengannya dan cari tahu. Jika dia hanya membutuhkan nomor untuk memberi atasannya, Anda dapat sedikit menaikkan perkiraan dan memberikan nomor. Untuk klien yang menunggu untuk membayar kode Anda sampai selesai, pastikan Anda mencari tahu apakah tanggal jatuh tempo garis keras akan mendorong pendapatan yang signifikan.

Dalam situasi seperti ini saya tidak percaya mungkin untuk memberikan perkiraan yang baik. Masalah mendasarnya adalah bahwa seringkali bagian besar dari melakukannya adalah mencari tahu apa yang perlu dilakukan.

Saya menangani kasus-kasus seperti ini dengan memberikan perkiraan berdasarkan apa yang tampaknya terjadi tetapi dengan cavet bahwa kejutan mungkin terjadi. Sementara saya tidak harus berurusan dengan banyak cara kode warisan saya memiliki beberapa kejutan yang sangat buruk berurusan dengan input - Saya telah melihat beberapa jam berubah menjadi beberapa minggu dan sekali ini menjadi tidak mungkin (Setelah penggalian yang cukup besar saya tahu saya tidak memiliki cukup data dalam kasus tertentu, kembali ke papan gambar.) Untungnya, bos saya mengerti ketika saya memberikan perkiraan seperti itu.

Nah, estimasi adalah keterampilan yang beberapa orang tidak pernah pelajari dengan baik. Itu tidak membuat Anda tidak berguna sebagai pengembang meskipun bahkan jika Anda tidak dapat menghasilkan estimasi yang bagus. Mungkin rekan setim atau manajemen akan mengisi kekosongan. Saya buruk dalam hal itu, sebagian besar tim masih suka bekerja dengan saya. Tetap tenang, bekerja sama dan terus melakukan refactoring.

Utang teknis memberi Anda sedikit tantangan yang bagus, tetapi ingat bahwa perusahaan / tim yang akhirnya menghasilkan utang akan terus menghasilkan utang kecuali ada perubahan pada semangat tim atau manajemen. Kode ini hanya mencerminkan masalah sosial, jadi fokuslah pada masalah nyata.

Kami menggunakan heuristik untuk memperkirakan fitur dalam proyek brownfield: Kami memperkirakan berapa lama untuk mengimplementasikan fitur itu dalam proyek greenfield tanpa sesuatu pun sudah dilaksanakan. Kemudian kami mengalikan estimasi itu dengan 2 untuk menangani pembersihan puing-puing yang sudah ada.

Faktor ini tergantung pada jumlah kopling dan ukuran kode keseluruhan, tetapi jika Anda melakukan beberapa fitur dengan cara ini, Anda dapat menginterpolasi faktor tersebut berdasarkan bukti aktual.

Saya pikir Anda harus duduk dengan bos Anda, menatap langsung ke matanya dan berkata:

'Dengarkan bos! Kami hanya refactoring di sini. Tidak ada fungsionalitas baru untuk dikirim, dan tidak ada pelanggan yang menunggu fungsionalitas itu; jadi seharusnya tidak ada tenggat waktu. Ini akan memakan waktu selama itu diperlukan, Anda perlu memutuskan apakah kita harus melakukannya atau tidak. '

Gunakan gerakan tegas tegas seperti menunjuk dan duduk di kursi Anda.

Atau Anda bisa membuat beberapa angka untuk membuatnya bahagia. Tapi mari kita hadapi itu, sampai Anda setengah jalan melalui pekerjaan perkiraan Anda akan sangat tidak akurat.