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

12

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.

project-management productivity testing

— Nelstaar
sumber

7

Apa artinya "menerima" suatu "perkiraan"? Jika Anda memperkirakan akan butuh waktu 30 hari untuk melakukan sesuatu, apa yang terjadi jika saya "menerimanya"? Apa yang saya peduli berapa lama Anda memperkirakan akan butuh saya untuk melakukan sesuatu? Anda dapat memperkirakan saya akan melakukannya dalam satu menit untuk semua yang saya pedulikan, Anda akan salah, bukan saya.

— David Schwartz

2

@David Menerima estimasi biasanya mengacu pada peninjauan estimasi dan memastikan konsensus. Misalnya, jika alat estimasi parametrik digunakan, meminta insinyur proyek meninjau data tersebut untuk memastikan konsistensi, mungkin menggunakan metodologi kedua seperti Wideband Delphi.

— Thomas Owens

12

Kedengarannya seperti sesuatu yang harus dikirim ke Scott Adams untuk kartun Dilbert.

— MetalMikester

1

Selama ada review. Saya contoh khusus ini tidak ada.

— Nelstaar

5

Ingat: perkiraan, komitmen, target, dan rencana untuk memenuhi target adalah empat hal yang berbeda. Pastikan bahwa semua orang jelas tentang hal-hal itu, dan mana dari keempat hal itu adalah output Excel.

— nlawalker

14

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.

— Péter Török
sumber

7

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.

— Steve
sumber

Tes diiris dalam sub-bagian (hampir atom) dan satu mendapat estimasi kecil.

— Nelstaar

Saya pikir menggunakan metode ini, penguji akhir tidak melihat / menguji gambaran besarnya.

— Nelstaar

1

"Agaknya makro beroperasi pada beberapa jenis input data, itu bukan hanya generator bilangan acak" Mungkin juga acak karena mereka tidak ada cara untuk menangkap setiap variabel yang akan membuat algoritma seperti itu akurat.

— maple_shaft

1

@maple_shaft: Itu sebabnya mereka menyebutnya perkiraan - itu tidak (atau seharusnya tidak) diharapkan akurat. Apakah Anda memperkirakan menggunakan beberapa perhitungan di Excel, atau dengan pensil dan kertas, tidak ada bedanya. Menggunakan Excel untuk estimasi jauh lebih masuk akal daripada beberapa 'teknik' lain yang saya lihat digunakan ...

— Treb

@Treb Perkiraan harus seakurat data yang disediakan dan status proyek saat ini memungkinkan, mengingat Kerucut Ketidakpastian.

— Thomas Owens

5

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.

— Bruce Ediger
sumber

1

Saya belum membaca makalah tersebut secara penuh (belum), tetapi metode parametrik telah banyak digunakan untuk memperkirakan proyek perangkat lunak dalam 15% selama lebih dari 20 tahun, dengan asumsi bahwa data input valid. Selain itu, metode kolaboratif seperti Wideband Delphi dapat (dan telah digunakan) untuk mengkonfirmasi keakuratan model parametrik. Lihat Ekonomi Rekayasa Perangkat Lunak (Boehm) untuk diskusi tentang metode parametrik dan menerapkan Wideband Delphi pada proyek perangkat lunak (baik dengan dan tanpa model paremetrik juga).

— Thomas Owens

Saya setuju dengan Thomas. Meskipun Anda tidak dapat secara akurat memprediksi setiap tugas untuk seluruh proyek, selama proyek dan menggunakan data historis untuk organisasi tertentu yang bisa Anda dapatkan di stadion baseball. Beberapa tugas akan memakan waktu lebih lama dan beberapa lebih pendek tetapi pada akhirnya rata-rata habis. Terutama jika proyeknya mirip dengan yang sudah dilakukan oleh organisasi. Dengan demikian, perkiraan tidak dapat menjelaskan hal-hal tak terduga yang benar-benar buruk, seperti perangkat keras / lunak tidak berfungsi seperti yang diiklankan, teknologi baru jauh lebih sulit daripada yang diantisipasi, kekurangan pengembang, kepemimpinan dan manajemen yang buruk.

— Dunk

1

Kalian harus membaca dan memahami makalah ini. Makro spreadsheet sederhana tidak memiliki peluang untuk memperkirakan dengan benar. Perangkat lunak adalah matematika, dan sistem matematika terkadang mengalami sedikit masalah yang dikenal sebagai ketidaklengkapan. Saya menjamin Anda bahwa manajer yang dimaksud menipu dirinya sendiri, dan bahwa hasil makro tidak berkorelasi dengan kenyataan.

— Bruce Ediger

1

@ Bruce: Setelah menggunakan rumus (termasuk lembar kerja Excel) untuk estimasi proyek dengan sukses, saya dapat mengklaim bahwa baik Thomas, Manajer atau saya sendiri tidak bisa membodohi diri sendiri. Seperti yang saya nyatakan, setiap tugas individu akan bervariasi, tetapi selama proyek mereka cenderung meratakan. Saya telah menemukan bahwa menggunakan rumus (dikembangkan dan dimodifikasi dari waktu ke waktu) jauh lebih akurat daripada perkiraan pengembang individu. Secara umum, pengembang terlalu optimis atau terlalu pesimis. Tentu saja, formula hanya berfungsi ketika diberikan data yang masuk akal, keterampilan tentu merupakan faktor.

— Dunk

Saya membaca surat-surat itu tadi malam. Mereka menentang lebih dari 40 tahun bukti dalam manajemen proyek dan lebih dari 30 tahun bukti dalam manajemen proyek perangkat lunak. Lihat iiasa.ac.at/Admin/PUB/Documents/RM-75-071.pdf dan sunset.usc.edu/csse/research/COCOMOII/cocomo_main.html

— Thomas Owens

4

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?

— ozz
sumber

1

99% pengembang bahkan tidak dapat menghasilkan estimasi buruk berdasarkan pada tujuan apa pun apalagi perkiraan akurat. Jadi saya tidak melihat apa pun yang mengindikasikan "bau pekerjaan" karena orang lain datang dengan perkiraan. Terutama jika mereka menggunakan data aktual untuk membenarkan jumlah mereka. Jika orang bertanggung jawab untuk memenuhi taksiran setiap tugas maka itu adalah masalah bau pekerjaan. Namun, jika alat ini sangat meremehkan semua tugas, maka semua pengembang akan kehilangan perkiraan. OTOH, jika semua orang tampaknya memenuhi hampir semua perkiraan dan pengembang lain tidak pernah melakukannya maka itu adalah masalah bau pengembang.

— Dunk

@Dunk - maksud saya, manajemen mikro hingga tingkat ini dalam mengembangkan perangkat lunak adalah "bau pekerjaan" dan saya tidak ingin bekerja di sana.

— ozz

1

apa yang Anda sebut manajemen mikro adalah satu-satunya cara untuk melakukan bisnis di banyak industri. Jika Anda tidak dapat menghasilkan estimasi biaya dan jadwal yang masuk akal untuk proyek-proyek besar maka perusahaan Anda akan memiliki pekerjaan yang sangat sulit untuk mendapatkan kontrak. Berlawanan dengan ideal yang lincah, pelanggan di banyak industri tidak akan berkomitmen untuk puluhan juta dolar kontrak jika mereka tidak tahu apa yang akan mereka dapatkan pada akhirnya. Mereka tidak akan senang dengan gagasan bahwa uang mereka hilang, mereka memiliki produk yang berfungsi, tetapi hanya 50% dari apa yang mereka butuhkan atau inginkan.

— Dunk

@dunk - Jika Anda senang dengan manajemen yang menghasilkan taksiran untuk Anda, silakan saja. Saya lebih suka meminta tim pengembang membuat perkiraan. Perkiraan manajemen yang konyol (bersama dengan kebutuhan yang terus berubah, seluruh diskusi lainnya) adalah mengapa banyak proyek perangkat lunak gagal memberikan tepat waktu dan sesuai anggaran yang dijadwalkan. Saya lebih suka mempercayai orang yang melakukan pekerjaan.

— ozz

Ini bukan masalah manajemen melakukan estimasi atau orang-orang yang melakukan pekerjaan datang dengan estimasi. Ini adalah pertanyaan untuk menarik taksiran dari pantat Anda atau mencoba mendasarkan perkiraan Anda pada beberapa data objektif. Sudah pengalaman saya bahwa dalam membandingkan estimasi manajemen dengan estimasi pengembang Anda akan menemukan bahwa estimasi manajemen cenderung menghasilkan waktu yang lebih lama untuk diselesaikan. Pengembang cenderung optimis .....

— Dunk

3

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.

— maple_shaft
sumber

1

Eh, hanya karena manajer menghasilkan perkiraan untuk pengembang tidak berarti bahwa mereka tidak akurat dan kami benar-benar tidak dapat menarik kesimpulan itu tanpa informasi lebih lanjut. Jika manajer kompeten mereka harus mengenali hal-hal yang realistis dan tidak realistis dengan cukup mudah.

— rjzii

1

@Rob, Anda lupa titik kunci yang dibuat OP, bahwa mereka ditahan untuk perkiraan ini (diasumsikan secara ketat karena pengembang sebelumnya di tim menyebutkan "tidak ingin ditahan dengan perkiraan" dan ditugaskan kembali). Tidak ada yang salah dengan model estimasi tetapi mereka harus menjadi pedoman kasar dan tidak ada untuk "menahan pengembang", yang sayangnya saya lihat manajemen lakukan untuk BANYAK orang.

— maple_shaft

2

Di sini masalahnya adalah estimasi ini langsung bergerak dalam faktur pelanggan. Mengapa beberapa manajer terus menyebutnya perkiraan?

— Nelstaar

@maple_shaft - Tanpa mengetahui apa perkiraannya, sulit untuk mengatakan apakah mereka tidak masuk akal dan oleh karena itu keberatan untuk dipegangi oleh mereka adalah valid. Jika mereka adalah perkiraan yang adil (yaitu "Delapan jam untuk menulis Hello World") maka tidak ada masalah dengan ditahan di luar filsafat.

— rjzii

3

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.

— Thomas Owens
sumber

3

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.

— rjzii
sumber

Saya setuju metode ini dapat / bisa digunakan selama ada dialog antara para aktor proyek.

— Nelstaar

1

@Nelstaar - Hampir semua yang pernah saya baca tentang manajemen dan estimasi proyek melibatkan dialog yang berjalan dan mengatur hal-hal seiring berjalannya waktu. Biasanya estimasi yang paling dapat diandalkan memiliki probabilitas yang terkait dengan mereka dalam hal peluang untuk mencapai target yang ditunjukkan (yaitu kemungkinan 90% dari tugas yang memakan waktu 8 jam).

— rjzii

2

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.

— JeffO
sumber

+1 untuk memberi umpan balik saat mengerjakan tugas sehubungan dengan perkiraan.

— rjzii

1

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.

— Clement Herreman
sumber

1

Anda harus peduli dari mana perkiraan itu berasal. Model parametrik dengan input yang valid dan masuk akal, generator angka acak, mahasiswa ilmu komputer tahun pertama, insinyur perangkat lunak dengan pengalaman 5 tahun dengan domain kurang dari 6 bulan, dan insinyur perangkat lunak mengubah manajer proyek dengan pengalaman 25 tahun dalam domain semua memiliki kapasitas yang berbeda untuk menghasilkan estimasi yang efektif. Ini juga kembali ke komentar yang saya buat pada jawaban sebelumnya tentang tanggung jawab etis / profesional seorang insinyur perangkat lunak untuk mewakili, membela, dan menantang estimasi secara tepat.

— Thomas Owens

Tepat: yang paling penting adalah membahas estimasi. Saya dengan senang hati menyetujui menggunakan makro Excel jika estimasi yang dibuatnya lebih sering benar daripada 25 tahun pengalaman insinyur. Yang penting adalah estimasi, dan penjelasan yang mengarah padanya (beban kerja, sumber daya yang tersedia, kesulitan), bukan oleh siapa atau apa yang diumumkan.

— Clement Herreman

Anda setuju dengan saya mengatakan bahwa jawaban Anda salah? Dengan input yang sama (seperti beban kerja, sumber daya, kesulitan, dll.), Siapa yang sama pentingnya dengan apa dan mengapa. Itu datang ke faktor kepercayaan. Saya mempercayai COCOMO (dibuat dan dikelola oleh beberapa orang terkemuka dalam estimasi biaya perangkat lunak) lebih dari sekadar makro Excel (dibuat oleh seseorang dengan pengalaman dan pengetahuan terbatas dalam estimasi biaya, apalagi domain aplikasi). Ini semua tentang gambaran besar untuk menetapkan seberapa dapat dipercaya perkiraan ini.

— Thomas Owens

Tidak tidak, saya kira saya tidak cukup jelas. Benar-benar tidak penting siapa yang melakukan estimasi. Yang penting adalah keakuratan estimasi. Setiap kali saya mendapatkan estimasi, saya membandingkannya dengan perkiraan saya, kemudian mendiskusikannya dengan manajer proyek saya apakah saya setuju atau tidak. Jika argumen mereka cukup baik, maka saya setuju dengan mereka, dan menerima estimasi. Lihat? Saya tidak pernah berbicara atau memikirkan siapa yang memperkirakan.

— Clement Herreman

Bagaimana Anda menentukan akurasi jika Anda tidak tahu siapa yang memperkirakan dan metode apa yang mereka gunakan? Saya bisa memberikan data yang sama kepada dua orang - satu adalah mahasiswa teknik perangkat lunak tahun pertama mengambil kursus ilmu komputer pertamanya dan yang lainnya adalah insinyur perangkat lunak senior dengan pengalaman 15 tahun dan 5 di domain. Keduanya menggunakan metode estimasi yang sama (jangan lupa - sering kali, input juga merupakan estimasi). Siswa dapat mengatakan itu akan memakan waktu 6 bulan dengan kepercayaan 95%. Insinyur senior dapat mengatakan akan memakan waktu 15 bulan dengan kepercayaan 80%. Saya akan lebih mempercayai insinyur senior.

— Thomas Owens

1

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.

— PeterAllenWebb
sumber

-1

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:

Manajer non-pengembang tidak dapat memperkirakan waktu yang dibutuhkan untuk melakukan pekerjaan
Memperkirakan waktu yang dibutuhkan untuk melakukan pekerjaan apa pun membutuhkan kecerdasan manusia, yang tidak dimiliki Excel
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.

— Saeed Neamati
sumber

5

OP tidak menyebutkan tim temannya menggunakan metode gesit. Saya tidak berpikir aturan gesit memiliki relevansi untuk tim yang menggunakan metode lain (atau tidak ada metode sama sekali). Meskipun demikian, akal sehat seharusnya :-) Selain itu, jelas bahwa bukan Excel yang memutuskan estimasi, tetapi hanya menjalankan beberapa perhitungan berdasarkan pada beberapa asumsi (tidak diketahui oleh kami) dan data (masing-masing mungkin benar atau salah) . Jika saya memasukkan taksiran untuk tugas yang diberikan oleh masing-masing anggota tim kami, lalu mengatur Excel untuk menghitung rata-rata dari ini, apakah Excel membuat estimasi?

— Péter Török

3

1 dan 2 secara terang-terangan salah. Model estimasi parametrik diterima secara luas dalam manajemen proyek perangkat lunak dan telah berlangsung lebih dari 20 tahun, dan siapa pun yang memiliki pelatihan manajemen proyek (insinyur perangkat lunak atau tidak) dapat dilatih untuk menggunakan alat-alat ini, dengan asumsi bahwa mereka (atau, lebih disukai, insinyur proyek) ) dapat memberikan estimasi input yang akurat.

— Thomas Owens

3

-1 - Ini tidak menjawab pertanyaan, memiliki kesalahan yang jelas ("... metodologi pengembangan perangkat lunak terbaru gesit"), dan tampaknya tidak menambah relevansi apa pun. Saya tidak yakin untuk apa upvotes atau jawaban yang diterima.

— Morgan Herlocker

1

kami tentu saja tidak tahu dari pertanyaan apakah estimasi parametrik adalah norma di perusahaan ini dan / atau apakah didasarkan pada sejarah yang baik untuk bisnis mereka; jika itu masalahnya daripada sebanyak yang saya benci untuk mengatakannya, penolakan untuk melakukan pekerjaan seseorang sesuai dengan prosedur operasi yang diterima organisasi (tanpa mengikuti jalur pertanyaan yang masuk akal) tidak bijaksana.

— StevenV

2

@ Thomas Saya setuju, saya hanya berpikir ada terlalu banyak yang kita tidak tahu tentang situasi untuk menjawab ya atau tidak. Dalam kasus apa pun, penolakan tanpa penjelasan yang baik untuk memastikan situasi dan alasan dipahami jarang langkah karier yang bagus.

— StevenV