Bagaimana memperkirakan tugas pemrograman jika Anda tidak memiliki pengalaman di dalamnya [tutup]

Saya mengalami kesulitan dengan manajemen untuk meminta perkiraan tugas pemrograman yang menggunakan kontrol pihak ketiga yang belum pernah saya alami sebelumnya.

Saya benar-benar mengerti mengapa mereka menginginkan perkiraan tersebut, tetapi saya merasa seolah-olah perkiraan apa pun yang saya berikan akan menjadi a) terlalu pendek dan membuat saya terlihat buruk atau b) terlalu lama dan membuat saya terlihat buruk.

Perkiraan atau jawaban apa yang bisa saya berikan kepada manajemen untuk melepaskannya dari punggung saya sehingga saya dapat terus melakukan pekerjaan saya!

Jawaban terbaik yang dapat Anda berikan adalah meminta waktu untuk membuat prototipe cepat agar Anda dapat memberikan perkiraan yang lebih akurat. Tanpa beberapa pengalaman dengan alat atau masalah, setiap perkiraan Anda memberikan pada dasarnya berarti.

Selain itu, sangat jarang ada masalah dengan memberikan perkiraan yang terlalu lama. Terjadi masalah yang tidak terduga, prioritas berubah, dan persyaratan "diperbarui". Bahkan jika Anda tidak menggunakan semua waktu yang Anda minta, Anda akan memiliki lebih banyak waktu pengujian, atau dapat merilis "lebih awal".

Saya selalu terlalu optimis dalam perkiraan saya, dan itu bisa membuat hidup Anda stres, terutama ketika Anda adalah seorang programmer muda tanpa pengalaman dan kepercayaan diri untuk memberi tahu bos tentang kebenaran yang tidak menyenangkan.

Aku akan memberitahumu sebuah rahasia. Meskipun Anda seorang ahli dengan teknologi itu, perkiraan Anda kemungkinan besar tidak akurat. Ini adalah sifat binatang ketika melakukan sesuatu yang merupakan tugas R&D yang inheren. Sayangnya manajemen sering mencoba menerapkan model manufaktur dan menuntut perkiraan yang akurat. Untuk mengilustrasikan poin saya, pertimbangkan kesulitan dalam memperkirakan secara akurat dua upaya berikut:

A) Membuat payung 11K lagi yang sama persis dengan 2K yang Anda keluarkan bulan lalu. B) Rancang payung jenis baru dan buat yang pertama.

Pengembangan perangkat lunak adalah B, tetapi mereka meminta perkiraan dengan asumsi A.

Hal terbaik yang dapat Anda lakukan adalah memecah tugas menjadi bagian-bagian terkecil yang mungkin (masing-masing tidak lebih dari 1/2 hari) dan kemudian melipatgandakan jumlah akhir yang Anda hasilkan. (Metode Spolsky)

Bergantian, Steve McConnell memiliki seluruh buku (bisa dibilang beberapa) tentang aspek rekayasa perangkat lunak. http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351

Steve McConnell (dan lainnya) berbicara tentang kerucut ketidakpastian . Pada dasarnya Anda memberikan perkiraan yang terlihat seperti ini:

Pekerjaan akan memakan waktu antara 3 dan 9 minggu dengan kemungkinan 4 minggu.

Saat proyek berlangsung, Anda dapat menyempurnakan perkiraan Anda. Saat Anda melakukan lebih banyak pekerjaan dan memahami upaya yang dibutuhkan dengan lebih baik, Anda dapat mempersempit perkiraan agar lebih akurat.

Ini berhasil untuk saya, tetapi perlu upaya agar pemegang saham lain dalam proyek tersebut memahami prosesnya.

Anda mungkin ingin mempertimbangkan untuk memberikan perkiraan dan tingkat kepercayaan, yaitu, 50/50 yang akan memakan waktu 3-6 bulan atau 6-9 bulan atau 75% kemungkinan untuk selesai dalam 9 bulan dan 90% bahwa Anda akan selesai. selesai dalam satu tahun.

Hal lain yang mungkin ingin Anda pertimbangkan adalah menggunakan pendekatan " kebijaksanaan orang banyak ". Berkelilinglah dan tanyakan 25-50 orang berapa lama menurut mereka hal itu akan memakan waktu dan rata-rata perkiraan mereka. Poker Perencanaan Mike Cohn , menurut saya, sangat mirip dengan ini, meskipun sulit untuk direncanakan hanya dengan satu pengembang.

Pecahkan perkiraan Anda menjadi:

• Yang diketahui ; berapa lama waktu yang dibutuhkan untuk melakukan apa yang Anda tahu caranya. Anda harus dapat memberikan perkiraan ini dengan tingkat keyakinan yang tinggi.
• Tidak diketahui yang diketahui ; menurut Anda berapa lama waktu yang dibutuhkan untuk melakukan apa yang tidak Anda ketahui bagaimana melakukannya. Anda dapat menggunakan metode seperti dacracot untuk memberikan tingkat kepercayaan yang berbeda pada perkiraan ini.
• Tidak diketahui tidak diketahui ; ini adalah lubang hitam waktu nyata. Ini adalah hal-hal yang muncul pada saat-saat yang paling tidak tepat dan menggigit Anda. Berikan kisaran perkiraan dengan justifikasi berdasarkan risiko yang Anda antisipasi.

Tawarkan untuk menyesuaikan perkiraan dan pencapaian tertentu di sepanjang jalan. Semua hal yang tidak diketahui yang tidak diketahui akan menjadi tidak diketahui yang diketahui, yang tidak diketahui yang diketahui harus diketahui saat Anda memperoleh pengalaman, dan perkiraan dari Anda yang diketahui dapat disesuaikan berdasarkan kemajuan hingga saat ini. Anda dapat melakukan estimasi awal, lalu estimasi ulang saat Anda selesai sekitar 25%, kemudian lagi di 50%, kemudian lagi di 85%. Pada setiap pencapaian, perkiraan Anda harus mulai memenuhi waktu sebenarnya yang dibutuhkan untuk tugas.

Saya menggunakan sistem pelabelan pasti untuk perkiraan saya ... kelas A, kelas B, dan kelas C.

Perkiraan kelas C adalah yang pertama mereka dapatkan. Ini secara terbuka dinyatakan sebagai plus atau minus 50% karena hal-hal yang tidak diketahui. Jika mereka ingin saya terus memberi mereka kelas B, maka saya perlu uang untuk penelitian.

Kelas B plus atau minus 25%. Terkadang ini cukup bagus dan mereka memberi saya uang untuk membangun. Jika tidak, lebih sedikit uang dan lebih banyak penelitian.

Kelas A plus atau minus 10%, final dan pergi atau tidak. Jika itu pergi dan saya menyimpang terlalu jauh dari perkiraan saya mengaku sering dan lebih awal.

Saya rasa jika Anda menghapus frasa "yang menggunakan kontrol pihak ketiga yang tidak pernah saya alami sebelumnya", Anda mungkin memiliki deskripsi yang lebih baik tentang masalah Anda yang lebih besar.

Jika "Agile" telah mengajari kami apa pun, itu adalah, jika manajemen mengharapkan Anda, secara berkelanjutan, untuk memperkirakan proyek seperti itu, dan Anda akan "terlihat buruk" jika Anda mengatakan itu tidak dapat diberikan karena Anda tidak memiliki informasi yang cukup, Anda sedang dalam perjalanan menuju GAGAL.

Masalah terbesar adalah masalah yang tidak dapat Anda kendalikan, dan yang bahkan belum Anda identifikasi. Seberapa sering Anda melihat ke belakang dan berkata pada diri sendiri, "Saya menekan perkiraan saya tepat di tombol - pada percobaan ketiga, setelah saya menemukan bahwa ... dan bahwa saya membutuhkan versi ... dan bahwa dba akan aktif liburan selama seminggu dan bahwa Manajer Proyek akan membutuhkan saya selama ... selama seminggu dan bahwa istri saya hamil dan ... ".

Saya akan berusaha keras untuk mengatakan, "Saya dapat mengidentifikasi faktor risiko kritis dan membuat daftar kiriman untuk mengujinya dalam xx hari. Pada saat itu saya akan memberikan perkiraan tambahan lainnya."

Dan alangkah baiknya jika Anda dapat menyarankan bahwa mereka harus "Berkeras agar saya tidak pernah mencoba memberi Anda perkiraan yang dapat dipercaya tentang jenis itu di masa mendatang. Pecat saya jika saya mencobanya."

(Berlebihan, tapi hanya sedikit.)

Jangan coba-coba memperkirakan. Tidak mungkin perkiraan Anda benar. Bagaimanapun, itu hanya perkiraan.

Sebagai gantinya, saya akan merekomendasikan agar Anda membagi fitur menjadi bagian-bagian kecil (tidak lebih dari, katakanlah 1-2 hari) dan mencoba mengirimkan bagian-bagian ini sebagai kode yang berfungsi, lengkap, dapat diuji, dan berharga kepada pelanggan / manajer. Dengan begitu, dia akan melihat sendiri kemajuan Anda setiap hari. Ini juga berarti bahwa dia sebenarnya dapat memutuskan untuk menghentikan pengembangan setelah puas dan menganggapnya selesai, meskipun mungkin tidak mencapai semua tujuan.

Lihat praktik tangkas "Perencanaan Rilis" dan "Perencanaan Iterasi" untuk informasi yang lebih mendalam tentang pendekatan ini.

Perlu diingat jika Anda meminta perkiraan waktu yang lebih besar tetapi membuatnya di bawah waktu, ini terlihat jauh lebih baik daripada di bawah perkiraan dan harus meminta perpanjangan.

Saya akan mencoba mengejek prototipe sehingga Anda memiliki gambaran yang lebih baik tentang waktu yang dibutuhkan. Jujurlah dengan manajemen Anda sehingga mereka dapat menganggarkan untuk penundaan tak terduga dalam kurva pembelajaran.

EDIT: Anda mungkin juga melihat apakah Anda bisa mendapatkan tenggat waktu yang lebih "berulang". Dalam "Pemikiran dan Pembelajaran Pragmatis", Andy Hunt membuat poin yang baik bahwa orang adalah ahli proyek yang mendekati akhir proyek dan paling tidak berpengetahuan di awal. Tidak masuk akal untuk melakukan semua desain dan estimasi waktu Anda di awal ketika semua orang memiliki pengetahuan paling sedikit tentang proyek tersebut. Jika Anda "mengulang" tenggat waktu dan menyelesaikan masalah dalam beberapa bagian, Anda akan lebih sukses.

Banyak estimasi yang akurat adalah pengetahuan diri. Jika Anda telah menulis banyak kode, jika Anda harus mempelajari banyak API, Anda akan mulai merasakan pertanyaan seperti:

• Berapa lama waktu yang saya butuhkan untuk mempelajari API baru?
• Berapa lama waktu yang saya butuhkan untuk belajar bahasa baru?
• Berapa lama waktu yang saya perlukan untuk mempelajari perangkat baru (compiler / linker / IDE)?
• Berapa lama waktu yang saya perlukan untuk menerapkan tugas biasa?
• Berapa lama waktu yang saya butuhkan untuk menguji pekerjaan saya?
• Berapa lama waktu yang saya butuhkan untuk menerapkan pekerjaan saya?

Selama itu, Anda harus memahami hal-hal seperti:

• Berapa banyak bug khas yang Anda buat dan bagaimana mereka dikategorikan (yaitu, mudah, sulit, tidak mungkin)
• Berapa banyak komplikasi yang muncul (misalnya, perlu refactor karena kurangnya API pihak ketiga atau API buggy; perlu mendesain ulang karena kesalahpahaman kemampuan; alat / proses pembuatan non-standar)
• Berapa banyak waktu yang hilang karena gangguan / masalah luar

Berdasarkan semua hal ini, Anda akan dapat mengembangkan perasaan tentang berapa lama sesuatu akan berlangsung dan dapat menyatakan asumsi Anda ("Dengan asumsi API itu waras ...") bahkan dalam menghadapi informasi yang sangat tidak lengkap.

Perkirakan berapa lama Anda perlu belajar cukup untuk membuat perkiraan yang lebih baik, misalnya, "Saya tidak tahu: Saya belum pernah mengerjakan ini sebelumnya. Mungkin saya perlu memasukkan perkiraan Anda di sini untuk mengetahui apa Anda perlu mempelajarinya yang harus saya ketahui sebelum saya dapat memberikan perkiraan yang baik untuk menggunakan ini untuk menyelesaikan proyek Anda . "

Ketika memprogram, saya selalu mengambil apa yang saya pikir akan membutuhkan saya dan mengalikannya dengan 3 untuk memberikan perkiraan. Jika saya pikir saya dapat melakukan pekerjaan dalam 1 minggu, saya memberi tahu klien itu akan memakan waktu 3 - jika saya pikir itu benar-benar akan memakan waktu 3 minggu saya memberi tahu klien 9 minggu.

Dengan melakukan ini, saya menetapkan diri saya untuk "di bawah janji, melebihi pengiriman" - jika Anda berhasil melakukan ini, hidup Anda akan jauh lebih baik dan klien Anda akan sangat bahagia.

Dalam kasus Anda, Anda pasti ingin mendapatkan setidaknya BEBERAPA pemahaman tentang apa yang Anda selami sebelum memberikan perkiraan. Mungkin Anda bahkan perlu memberikan perkiraan tentang berapa lama waktu yang dibutuhkan untuk memberikan perkiraan. Kalikan dengan 3 membuat klien senang.

Bagi menjadi hal-hal yang Anda punya pengalaman dengannya. Tindakan memotongnya akan memberi Anda gagasan yang lebih baik tentang apa yang Anda ketahui dan apa yang tidak Anda ketahui.

Setelah potongan cukup kecil sehingga dapat dilihat sebagai tugas tunggal yang ditentukan, beberapa di antaranya akan sepenuhnya tidak dapat diperkirakan. Untuk itu, buat prototipe dulu, atau tinggalkan waktu yang masuk akal, tergantung pada ukuran potongannya. Jika Anda menemukan bahwa Anda memiliki potongan tak terduga yang lebih besar dari 2-4 minggu kerja, kembalilah untuk memotongnya terlebih dahulu.

Akhirnya Anda akan mendapatkan beberapa solusi teknologi yang sangat aneh (yang menurut Anda akan berhasil, tetapi tidak tahu pasti), dan banyak pekerjaan yang harus dilakukan untuk mendukung hal itu, setelah berhasil. Akan ada beberapa bit desain yang hilang, yang terbaik adalah memilih beberapa pustaka terkenal atau algoritme yang sangat sederhana untuk versi awal.

Jika Anda tidak dapat memecah tugas, maka Anda harus mempekerjakan seseorang dengan pengalaman yang cukup yang bisa (karena kurangnya pengalaman Anda akan menghantui Anda dengan cara lain juga). Jika Anda tidak dapat mempekerjakan seseorang, maka Anda harus menawar untuk jangka waktu yang lama secara acak (6 bulan hingga 2 tahun), dan langsung menuju ke prototipe yang berantakan (sampai Anda berhasil memberi diri Anda cukup pengalaman untuk mengetahui apa yang benar dan apa yang salah). Tetapi, jika Anda akhirnya gagal melakukannya, penting untuk tidak menipu diri sendiri dan berpikir bahwa Anda melakukannya dengan "cara" yang benar. Prototipe dimaksudkan untuk dibuang. Semoga setelah hitungan mundur prototipe selesai, Anda siap untuk membangunnya secara nyata.

Paul.

Anda hanya menebak angka luar dan segera mengevaluasi, beri tahu mereka bahwa informasi di masa mendatang dapat memengaruhi perkiraan Anda, tetapi Anda akan terus memperbaruinya.

Saat Anda mengevaluasi, selalu beri tahu mereka - baik melalui dokumen yang diterbitkan di web atau pembaruan mingguan, tetapi selalu sertakan "perkiraan tanggal akhir" yang diperbarui, dan alasan (jika ada) untuk ekstensi.

Kebanyakan manajer harus memahami bahwa - dengan menanyakan tanggal berakhir, mereka benar-benar mengatakan "beri kami gambaran bagaimana kami dapat merencanakan jadwal kami" dan "jangan hanya mengambil selamanya".

Jika Anda akhirnya memperpanjang lebih dari sekali atau dua kali, evaluasi ulang seluruh jadwal Anda berdasarkan pengetahuan baru yang sulit Anda perkirakan.

Saya akan menambahkan apa yang RB katakan, ketika saya menemukan diri saya dalam situasi ini, saya memperkirakan berapa lama waktu yang dibutuhkan dengan alat yang saya kenal, dan kemudian menggandakan perkiraan itu untuk membangun beberapa kurva pembelajaran.

Bagian penting adalah berkomunikasi dengan manajemen bahwa perkiraan tersebut adalah menebak , jika mereka menekan untuk perkiraan yang lebih akurat atau jika mereka mencoba untuk - Tuhan sayang - menjual Anda batas waktu (pasti hanya akan membawa Anda 2 hari untuk membangun Starship Enterprise, Anda baik Anda) TETAP PADA GUNS ANDA , jangan kompromi perkiraan Anda, atau fakta bahwa itu tidak dapat diandalkan.

Jika manajemen mengesampingkan Anda dan mengatur waktu tugas, misalnya "Yah, ini harus diselesaikan dalam 2 hari", sekali lagi beri tahu mereka bahwa itu perkiraan mereka , yang sama andalnya dengan perkiraan Anda.

Catat semua ini secara tertulis.

Saya menangani estimasi dalam pekerjaan saya dan ini adalah tantangan nyata. Salah satu tantangan terbesar saya adalah memperkirakan berapa lama waktu yang dibutuhkan pengembang yang berbeda untuk menyelesaikan tugas tanpa pengetahuan tentang seberapa terampil pengembang itu nantinya.

Meskipun Anda mungkin melihat beberapa kesuksesan awal dengan metode "di bawah janji, terlalu banyak", Anda akan menemukan bahwa seiring waktu Anda akan kalah bersaing dengan orang lain yang mengikuti aliran pemikiran "di bawah janji, di bawah pengiriman". Kurangnya akurasi akan kembali menggigit Anda. Akurasi sangat terkait dengan pengalaman dan membatasi jumlah hal yang tidak diketahui dengan teknologi.

Satu hal yang saya sarankan adalah untuk mendapatkan gambaran tentang jenis anggaran yang akan digunakan oleh perkiraan Anda. Jika Anda memiliki anggaran kecil, jangan tergila-gila dengan teknologi asing dan tetap berpegang pada apa yang Anda ketahui. Jika anggaran Anda sedikit lebih fleksibel, maka Anda dapat sedikit bereksperimen.

Juga ketahuilah bahwa akan ada beberapa tugas di mana yang dapat Anda berikan hanyalah Tebak Pantat Liar (WAG). Untuk ini, Anda harus menetapkan waktu minimum untuk perkiraan Anda dan menjelaskan bahwa Anda tidak tahu berapa maks. Seringkali perkiraan semacam ini merupakan alasan yang cukup untuk fitur / persyaratan tertentu untuk dipotong oleh manajemen.

Itu adalah keterampilan yang sangat diperlukan yang mungkin dimiliki oleh manajer proyek dan pemrogram (dan tentu saja dapat dikuasai!), Saya menemukan sebuah artikel, Memperkirakan Tugas Pengembangan Perangkat Lunak (sedikit) Lebih Mudah , yang saya harap dapat membantu untuk perkiraan yang lebih baik tentang tugas-tugas proyek.

Semua tanggapan di atas telah mencakup hampir semua hal tentang menghasilkan perkiraan itu sendiri.

Satu hal yang ingin saya tekankan adalah melacak perkiraan Anda (spreadsheet Excel kecil a la Joel, atau bahkan dokumen Notepad jika sangat sederhana), dan pada akhir setiap hari perbarui ini ke angka paling akurat yang sekarang dapat Anda berikan . Bahkan jika Anda tidak perlu menyampaikan ini kembali kepada atasan Anda, terus memperbarui ini memberi Anda gagasan yang lebih baik tentang bagaimana hal-hal berkembang, dan yang lebih penting Anda akan mendapatkan gambaran yang baik mengapa perkiraan Anda berubah seiring kemajuan pekerjaan. .

Melakukan ini akan membuat Anda lebih baik dalam memperkirakan di masa depan, baik untuk teknologi spesifik ini dan lainnya yang belum pernah Anda gunakan sebelumnya, hanya karena Anda pada tingkat tertentu harus memperhatikan ketika ekspektasi Anda berubah secara berkala, dan mencari tahu mengapa hal itu terjadi. .

Memperkirakan berapa lama sesuatu akan berlangsung adalah bagian dari pekerjaan Anda. Selama ini dipahami sebagai perkiraan dan bukan tenggat waktu, Anda tidak perlu khawatir. Tidak ada orang yang lebih baik untuk memberikan perkiraan selain orang yang akan menulis kode. Jika Anda tidak dapat memberikan perkiraan yang baik, maka Anda perlu membuat manajemen sadar akan risiko yang melekat pada perkiraan buruk Anda sehingga mereka dapat mempertimbangkan kembali apakah layak mengambil risiko pada pemrograman melawan kontrol pihak ketiga yang tidak diketahui ini.

Itu adalah situasi yang sangat umum: kebutuhan untuk berurusan dengan yang tidak diketahui. Cara yang berguna untuk mengatasi hal ini adalah menyadari bahwa selain tugas pemrograman yang sebenarnya, Anda memiliki beberapa pembelajaran yang harus dilakukan - dan manajemen harus menyadarinya.

Ketika Anda berada dalam situasi seperti ini, proyek tersebut tiba-tiba menjadi proyek R&D dan waktu yang lebih lama dari biasanya tidak akan membuat Anda terlihat buruk, karena Anda sedang belajar dan memproduksi program. Saya tidak tahu seberapa cepat Anda belajar atau sumber daya apa yang Anda miliki untuk menangani masalah yang mungkin Anda temukan (Stack Overflow adalah salah satu opsi yang Anda miliki).

Saya akan mengatakan bahwa Anda harus memperkirakan seperti biasa dan kemudian mengalikannya dengan 1,5 (jika Anda adalah pelajar yang cepat dan memiliki akses ke sumber daya untuk menyelesaikan pertanyaan Anda) atau dengan 2,5 jika Anda adalah pelajar rata-rata dan hanya mengandalkan diri sendiri.

Saya harap ini membantu!

Berusahalah sekuat tenaga untuk membagi tugas menjadi bagian-bagian yang dapat dikelola. Dengan sedikit keberuntungan, ada tugas khusus yang terkait dengan komponen pihak ketiga yang terlibat dan tugas lainnya yang kurang digabungkan (dan karena itu lebih mudah untuk diperkirakan). Berikan estimasi terpisah kepada manajemen dan tunjukkan di mana estimasi paling tidak pasti berada.

Saya sepenuhnya setuju dengan siapa pun yang menyarankan untuk bermain-main dan membuat prototipe beberapa. Setel kotak waktu tetap untuk aktivitas pembuatan prototipe. ("Saya perlu dua hari pertama untuk membuat bagian dari perkiraan saya ini lebih baik.")

Bisakah Anda memberi kisaran? 40-60 jam, kira-kira seperti itu?

Semakin kecil tugasnya semakin sulit, jika Anda dapat mengelompokkannya, Anda akan memiliki sedikit lebih "slop" karena kesalahan dapat menyeimbangkan di akhir proyek.

Lihatlah area mana saja yang pernah Anda alami dan gunakan sebagai panduan. "Terakhir kali diperlukan untuk membuat fitur yang mengubah database, saya membutuhkan X". Semoga berhasil.