Haruskah pengembang menerima estimasi beban kerja yang dilakukan oleh makro Excel?

Dalam proyek baru, seorang teman harus menulis tes di mana waktu yang dibutuhkan untuk menulisnya dihitung oleh makro Excel yang ditulis oleh manajer non-pengembangnya.

Dalam keadaan seperti itu, haruskah pengembang menerima tanggung jawab untuk menulis dan menjalankan tes dalam waktu yang dihitung? Apakah hasil tes ini dapat dipercaya?

Sebagai informasi, teman saya menolak untuk bertanggung jawab atas estimasi yang tidak ia buat, minta berhasil bekerja pada proyek lain, dan telah digantikan oleh seorang pria yang tidak berpengalaman di luar sekolah.

Itu tergantung pada seberapa masuk akal mereka melihat ke pengembang, dan apa data / logika mereka didasarkan. (mereka mungkin didasarkan pada data statistik yang dikumpulkan selama beberapa tahun tentang berapa banyak waktu yang dibutuhkan - oleh pengembang ini sendiri, dan / atau oleh orang lain - untuk menyelesaikan tugas serupa di masa lalu ... atau mereka mungkin didasarkan sepenuhnya pada manajernya - benar atau salah - asumsi.)

Idealnya, ia harus berdiskusi dengan manajernya bahwa seseorang tidak dapat secara wajar diharapkan untuk berkomitmen dan bertanggung jawab atas tugas yang diperkirakan oleh orang lain.

Menolak dengan jelas untuk berkomitmen pada perkiraan memang dapat mengakibatkan penggantian yang cepat, jadi lebih baik untuk memiliki pendekatan yang lebih lembut dan menghindari konfrontasi langsung jika memungkinkan.

Agaknya makro beroperasi pada semacam input data, bukan hanya generator bilangan acak? Jadi, untuk menjawab pertanyaan Anda, kami perlu tahu apa input data dan apa yang makro lakukan. Tanpa ini jawaban apa pun tidak ada artinya.

Atau, apakah pertanyaan Anda benar-benar tentang menerima taksiran yang dihasilkan oleh manajer yang tidak memiliki pengalaman yang relevan? Dalam hal ini jawabannya tidak, Anda (atau teman Anda) harus membuat estimasi sendiri dan menyerahkannya kepada manajer. Jika 2 angka tidak cocok maka mereka perlu bekerja sama untuk mencari jalan keluar terbaik - mungkin setuju untuk menulis lebih sedikit tes atau mungkin lebih lama untuk menulis semuanya.

Penolakan kosong tidak akan membantu siapa pun, dan bekerja pada skala waktu yang tidak dapat Anda temui juga tidak menyenangkan, solusinya terletak pada mengambil pendekatan profesional dan mencapai kompromi yang memungkinkan pekerjaan untuk dilanjutkan.

Jelas TIDAK.

Program kecil, bahkan program besar, rumit, tidak mungkin memperkirakan berapa lama pekerjaan pemrograman akan berlangsung. Lihat Batas Matematika untuk Estimasi Perangkat Lunak untuk alasan mengapa. Makalah yang lebih panjang, ditinjau sejawat, Estimasi Batas Besar untuk Perangkat Lunak juga tersedia.

Saya juga akan mempertimbangkan kembali pendapat saya tentang manajer yang bersangkutan: mengapa dia percaya bahwa makro spreadsheet belum pernah dicoba di masa lalu, mengingat segala sesuatu yang lain telah dicoba untuk memperkirakan durasi tugas perangkat lunak di masa lalu.

Ugh!

Ini adalah "bau pekerjaan" raksasa. Itu adalah manajemen mikro yang luar biasa.

Jika mereka tidak bisa mempercayai karyawan mereka untuk memberikan perkiraan, apalagi yang mereka tidak percayai dengan Anda?

Benar-benar tidak.

Saya berjanji kepada Anda bahwa manajer tidak begitu tertipu untuk berpikir bahwa makro Excel-nya dapat secara akurat memprediksi estimasi. Saya bahkan tidak memperdebatkan apa yang seharusnya menjadi fakta terkenal bahwa ada terlalu banyak variabel yang terlibat untuk secara akurat memprediksi sesuatu seperti ini dalam suatu algoritma. Jika dia menemukan algoritma seperti itu, dia harus mematenkannya dan menghasilkan jutaan dolar menurut pendapat saya.

Apa yang sebenarnya terjadi di sini adalah manajer menggunakan makro Excel yang seharusnya sebagai penyamaran terselubung untuk menyembunyikan fakta bahwa ia memaksakan ekspektasi yang tidak realistis dan tekanan yang tidak semestinya pada pengembangnya.

Dia tahu itu adalah BS dan tidak peduli, itu adalah alasan untuk mem-overbook sumber daya dan mencoba menyelesaikan sesuatu lebih cepat dengan membuat semua pengembang "tidak berharga" -nya terus-menerus "LATE".

Manajer ini terdengar seperti orang brengsek yang eksploitatif.

Dalam proyek baru, seorang teman harus menulis tes di mana waktu yang dibutuhkan untuk menulisnya dihitung oleh makro Excel yang ditulis oleh manajer non-pengembangnya.

Ada model estimasi parametrik untuk memperkirakan waktu penyelesaian proyek, termasuk proyek perangkat lunak. Biasanya, perkiraan adalah untuk kode produksi, tetapi saya tidak melihat mengapa tidak dapat diekstrapolasi untuk memperkirakan berapa lama waktu yang dibutuhkan untuk menulis kode pengujian. Perkiraan ini hanya sebaik data yang dimasukkan ke dalamnya.

Dengan asumsi bahwa metode yang digunakan adalah model estimasi yang valid dan datanya akurat dan valid, tidak ada alasan mengapa estimasi yang baik tidak dapat berasal dari makro Excel yang ditulis oleh manajer non-pengembang.

Dalam keadaan seperti itu, haruskah pengembang menerima tanggung jawab untuk menulis dan menjalankan tes dalam waktu yang dihitung?

Tidak ada perkiraan yang dapat diterima secara membabi buta, dalam kondisi apa pun. Tidak ada perkiraan yang sempurna, terlepas dari bagaimana itu dihasilkan. Terserah insinyur untuk meninjau perkiraan apa pun, mengidentifikasi potensi masalah, menilai dampaknya, dan mendiskusikan serta memperbaiki estimasi yang diperlukan.

Apakah hasil tes ini dapat dipercaya?

Tes hanya sebaik usaha yang dihabiskan dalam merancang dan mengimplementasikannya. Jika seorang penguji menghasilkan tes berkualitas rendah, cacat akan lolos uji dan membuatnya ke tahap selanjutnya dari proyek. Masuk akal bahwa tekanan jadwal akan mengarah pada tes berkualitas rendah, jadi jika waktu tidak cukup untuk merancang kasus uji yang sesuai dan kemudian menerapkan kasus-kasus itu, maka tes tidak akan berguna.

Sepertinya Anda mengajukan dua pertanyaan berbeda:

Apakah hasil tes ini dapat dipercaya?

Excel adalah alat seperti yang lainnya yang bekerja dengan kami dan perhitungan apa yang ditulis seharusnya tidak benar-benar berdampak pada hasil algoritma itu sendiri. Fakta bahwa estimasi berasal dari makro Excel tidak relevan dengan apakah hasil perhitungan (yaitu validitas estimasi) valid atau tidak. Jika Anda memiliki asumsi buruk dalam model yang mendasarinya, tidak masalah apa yang Anda gunakan untuk melakukan perhitungan karena asumsi yang mendasarinya salah.

Dalam keadaan seperti itu, haruskah pengembang menerima tanggung jawab untuk menulis dan menjalankan tes dalam waktu yang dihitung?

Jika persyaratan bahwa pengembang melakukan pekerjaan dalam waktu yang ditunjukkan ada dalam kontak mereka maka tidak banyak yang dapat mereka lakukan untuk membantahnya selama perkiraan tersebut masuk akal. Yang mengarah ke poin berikutnya: jika perhitungan memberikan jumlah waktu yang masuk akal dan mereka mirip dengan perkiraan pengembang akan memberikan sendiri maka tidak ada alasan untuk tidak keberatan dengan jadwal yang diberikan. Bahkan, itu mungkin bekerja untuk keuntungan pengembang karena mereka mungkin dapat mempengaruhi asumsi yang digunakan dalam modul sebagai lawan jika mereka diberi garis waktu yang sewenang-wenang.

Jika garis waktu tampak tidak mungkin untuk jumlah pekerjaan yang diperlukan maka jelas mereka harus menyampaikan kekhawatiran ini dan mencoba dan bekerja dengan manajer untuk mendapatkan garis waktu yang lebih realistis, tetapi jika garis waktu itu layak maka mereka akan mengalami kesulitan untuk menolaknya.

Dalam hal manajemen proyek dan memperkirakan jadwal, ya, itu bisa dilakukan tetapi sangat tergantung pada sifat pekerjaan yang dilakukan. Anda mungkin akan melihat perkiraan yang lebih akurat diberikan untuk waktu yang diperlukan untuk menulis kode pengujian unit (dengan asumsi pengembang memahami kerangka kerja dan telah menulisnya sebelumnya) daripada Anda akan menulis kode baru terhadap kasus penggunaan kode pengujian sedang ditulis untuk.

Saya tidak ingin bermain-main tes menulis, tetapi proyek mungkin memiliki beberapa pengembang menulisnya sebelumnya. Jika perkiraan didasarkan pada data ini, mereka mungkin lebih akurat daripada asumsi teman Anda. Karena teman Anda meninggalkan proyek, tidak berusaha membuat perkiraan yang berlawanan atau melihat apakah perkiraan itu dapat diselesaikan sesuai prediksi, kita tidak akan pernah tahu.

Yang harus dia lakukan hanyalah menyelesaikan satu atau dua tes untuk melihat seberapa akurat perkiraan itu, dan kembali ke manajer dengan argumen yang sah. Mungkin ada anggota tim lain yang bisa memberikan umpan balik pada keandalan estimasi atau konsekuensi dari ketinggalan. Terkadang seorang manajer harus memberikan 'sesuatu' kepada bosnya untuk membuat semua orang senang. Pengembang melihat ini sebagai rasa aman palsu. Mungkin jika ada gerakan bagi pengembang untuk memberikan perkiraan dan menunjukkan keinginan untuk menyelesaikan sesuatu, manajemen dapat mengembangkan lebih banyak kepercayaan.

Yang saya duga adalah, jika dia bisa menyelesaikan tes dalam waktu kurang, dia tidak akan mengatakan apa-apa tentang itu. Kemudian lagi, memaafkan dirinya dari praktik yang tidak ia yakini, mungkin mengindikasikan tingkat integritas yang tinggi.

Jawaban mudah dan singkat:

Anda tidak peduli dari mana perkiraan itu berasal.

Apa yang sebenarnya Anda pedulikan adalah estimasi itu sendiri. Setuju dengan itu atau tidak setuju dan jelaskan mengapa dan berapa banyak yang akan Anda perkirakan. Itu yang paling penting.

Secara teori, pengembang seharusnya tidak pernah menerima estimasi yang dibuat oleh orang lain, tidak peduli bagaimana itu dibuat. Salah satu alasannya adalah memberikan estimasi yang lebih lama daripada yang nyaman dilakukan manajer Anda dengan segera memaparkan masalah jadwal potensial atau mungkin kesalahpahaman tentang ruang lingkup pekerjaan yang harus dilakukan.

Orang biasanya menemukan estimasi pemrograman waktu bahkan lebih sulit daripada pemrograman itu sendiri, jadi jika manajer Anda dapat menulis makro Excel dapat memecahkan bahwa masalah, ia mungkin dapat membuat makro untuk menulis kode (mungkin).

Sekarang, dalam praktiknya , jika Anda memahami pekerjaan dan perkiraan terlihat masuk akal, masuk akal untuk hanya mengungkapkan beberapa kekhawatiran tentang metodologi secara sepintas tetapi kemudian setuju untuk melihat apakah Anda dapat memenuhinya. Kemudian, jika pekerjaan itu membuat Anda lebih lama dari perkiraan, Anda harus membawa ini ke perhatian manajer Anda sedini mungkin. Bersiaplah untuk membahas alasan yang tepat berdasarkan pengalaman implementasi aktual Anda. Mudah-mudahan pada saat itu manajer Anda tidak akan tidak masuk akal dan terus bersikeras bahwa Anda bekerja untuk perkiraan yang dihasilkan secara mekanis.

Salah satu metodologi pengembangan perangkat lunak terbaru adalah gesit , dan salah satu kerangka kerja tangkas yang terkenal adalah scrum . Namun dalam metodologi ini, pengembang (tim scrum) bertanggung jawab untuk menghitung waktu yang dibutuhkan untuk melakukan tugas atau mengimplementasikan cerita pengguna.

Saya pasti mengatakan TIDAK . Karena:

1. Manajer non-pengembang tidak dapat memperkirakan waktu yang dibutuhkan untuk melakukan pekerjaan
2. Memperkirakan waktu yang dibutuhkan untuk melakukan pekerjaan apa pun membutuhkan kecerdasan manusia, yang tidak dimiliki Excel
3. Dengan menerima praktik kerja seperti itu, manajer semakin terbiasa untuk mengganti pengembang dalam memperkirakan waktu. Ini bisa mengakibatkan bencana. Pertimbangkan skenario ini di mana manajer Anda mengatakan:

Saya ingin memulai proyek baru untuk menjual sepeda secara online dan saya tahu bahwa Anda dan John memerlukan waktu 3 minggu untuk mencapainya.