Mengapa jadwal perangkat lunak begitu sulit untuk didefinisikan?


39

Tampaknya, dalam pengalaman saya, membuat kami insinyur memperkirakan dan menentukan tugas yang harus diselesaikan secara akurat seperti mencabut gigi. Daripada hanya memberikan perkiraan barang curian 2-3 minggu atau 3-6 bulan ... apa cara paling sederhana untuk menentukan jadwal perangkat lunak sehingga mereka tidak begitu sulit untuk didefinisikan? Misalnya, pelanggan A menginginkan fitur sebelum 02/01/2011. Bagaimana Anda menjadwalkan waktu untuk mengimplementasikan fitur ini mengetahui bahwa perbaikan bug lain mungkin diperlukan di sepanjang jalan dan membutuhkan waktu rekayasa tambahan?


33
Saya telah menemukan bukti yang benar-benar luar biasa bahwa tidak mungkin untuk memperkirakan semua tugas pengembangan yang kompleks secara akurat, atau menjadwalkan tugas-tugas ini dengan sempurna, atau secara umum, jadwal apa pun yang didasarkan pada perkiraan. Kotak komentar ini terlalu kecil untuk menampungnya.
Dan McGrath

2
@Dan McGrath: Mengapa Anda tidak memposting tautan yang berisi bukti? Tunggu, apakah Anda mencoba menjadi seperti Fermat dan bukti teorema terakhirnya, yang tidak pernah ditemukan: |
Shamim Hafiz

9
Untuk alasan yang sama sehingga sulit untuk merencanakan perjalanan ketika navigator tidak yakin tujuan, pengemudi tidak tahu jalan, dan semua penumpang menginginkan es krim.
Steven A. Lowe

1
Sesuatu yang mungkin menarik bagi Anda adalah Penjadwalan Berbasis Bukti.
Craige

2
Mereka tidak sulit untuk didefinisikan. Tidak mungkin untuk terus melakukannya.
Tony Hopkinson

Jawaban:


57

Jika Anda membuat proyek yang hampir identik dengan proyek lain yang telah Anda lakukan, menggunakan alat yang sudah dikenal dan tim yang akrab, dan Anda diberi persyaratan tertulis yang tegas, maka harus mungkin untuk membuat perkiraan yang baik.

Ini adalah kondisi yang sering dialami oleh pelukis, pemasang karpet, penata taman, dll. Tetapi ini tidak cocok untuk banyak (atau sebagian besar) proyek perangkat lunak.

Kami sering diminta untuk memperkirakan proyek yang menggunakan alat baru, teknologi, di mana persyaratan berubah, dll. Ini lebih merupakan ekstrapolasi ke dalam yang tidak diketahui daripada interpolasi atas pengalaman masa lalu kita. Jadi wajar jika estimasi akan lebih sulit.


20
Poin luar biasa. Ini seperti menanyakan berapa lama Anda akan mengemudi di tempat yang belum pernah Anda datangi. Anda dapat memberikan perkiraan berdasarkan jarak, tetapi Anda tidak dapat memperhitungkan jumlah lalu lintas selama jam sibuk.
JeffO

2
@ Jeffff Itu perbandingan yang sangat bagus. Saya harus ingat yang itu
Dave McClelland

1
@ Jeff, tapi Anda bisa tahu ini jam sibuk dan menambahkan fakta itu ke perkiraan Anda ... Anda mungkin masih libur, tetapi tidak sebanyak
Pemdas

2
@Pemdas: Sebenarnya, Anda tidak bisa cukup tahu untuk menambahkan semua fakta ke perkiraan Anda. Anda tidak dapat mengetahui apakah pemadam kebakaran merespons panggilan. Anda tidak dapat mengetahui apakah kabel listrik telah jatuh dan menghalangi jalan. Ada banyak hal yang tidak dapat Anda ketahui tentang masa depan. Ini masa depan. Sulit untuk diprediksi - menurut definisi.
S.Lott

1
@Pemdas - semakin kompleks tugasnya, semakin banyak dewa kekacauan ikut campur. Tentu saja itu mungkin lebih cocok dengan poin Anda daripada beberapa komentar - dengan tugas-tugas yang sudah lazim, Anda tahu betapa tertariknya para dewa sial itu.
Steve314

35

Menurut pengalaman pribadi saya, itu persis kebalikan dari apa yang dikatakan Pemdas : dengan latihan, saya baru mengerti bahwa sama sekali tidak mungkin untuk memperkirakan berapa banyak waktu yang dibutuhkan suatu tugas. Pada awal karir saya dalam pengembangan perangkat lunak, saya sering memberikan perkiraan seperti "45 hari", "lima minggu", dll., Kemudian berusaha sangat keras untuk menyelesaikannya tepat waktu. Beberapa tahun kemudian, saya mulai memberikan perkiraan yang kurang tepat seperti "sekitar satu bulan", "lima hingga tujuh minggu", dll. Sebenarnya, saya mencoba untuk tidak memberikan perkiraan apa pun, atau meminta pelanggan untuk memberikan perkiraannya sendiri atau tenggat waktu atau saya memberikan perkiraan sekasar mungkin.

Mengapa begitu sulit untuk memiliki perkiraan? Karena hampir mustahil untuk mengetahui bagaimana seluruh kode sumber akan ditulis sebelum benar-benar menulisnya, dan karena pekerjaan Anda bergantung pada hal-hal acak ketika orang lain bekerja, motivasi Anda, dll. Berikut adalah daftar yang lebih rinci dari alasan yang mungkin:

  1. Tidak mudah untuk mengetahui apa sebenarnya yang diperlukan untuk melakukan suatu produk, dan terutama bagaimana melakukannya . Sangat sering saya memulai beberapa bagian aplikasi, daripada, setelah berhari-hari bekerja, mengerti bahwa pendekatan pertama saya salah, dan bahwa ada cara yang lebih baik dan lebih cerdas untuk melakukan sesuatu.

  2. Beberapa masalah mungkin timbul . Misalnya, jika, untuk memulai pekerjaan Anda, Anda harus menginstal pada server Anda SQL Server yang mewah dan instalasi gagal dan dukungannya tidak ada, Anda mungkin menghabiskan waktu berminggu-minggu untuk menyelesaikan masalah ini.

  3. Persyaratan seringkali tidak cukup jelas , tetapi setelah membacanya di awal, Anda mengira begitu. Kadang-kadang Anda dapat memahami bahwa berarti 'A', dan, setelah mulai menerapkannya, Anda akan melihat bahwa mereka mungkin berarti 'B'.

  4. Pelanggan suka mengubah persyaratan mereka tepat ketika Anda baru saja menyelesaikan bagian yang bersangkutan , dan mereka benar-benar tidak mengerti mengapa Anda meminta dua minggu lagi dan $ 2000 untuk melakukan perubahan kecil , karena mereka tidak melihat bahwa perubahan kecil ini mengharuskan untuk mengubah hal-hal lain, yang perlu mengubah orang lain, dll.

  5. Anda tidak dapat memperkirakan motivasi Anda . Ada hari-hari ketika Anda dapat bekerja berjam-jam dan berhasil dengan baik. Ada beberapa minggu ketika, setelah menulis sepuluh baris kode, Anda beralih ke Programmer StackExchange, dan menghabiskan berjam-jam membaca dan menjawab pertanyaan.

  6. Keadaan menjadi sangat buruk ketika perkiraan Anda bergantung pada orang lain . Misalnya, dalam satu proyek 2 bulan saya harus menunggu seorang desainer untuk melakukan pekerjaannya untuk menyelesaikan sendiri. Perancang ini membutuhkan waktu 3 bulan sebelum memberikan sepotong omong kosong yang tidak dapat digunakan. Tentu saja proyeknya terlambat.

  7. Perkiraan Anda juga tergantung pada pelanggan Anda . Saya memiliki pelanggan yang menghabiskan waktu berminggu-minggu sebelum menjawab surat mereka. Ini benar-benar dapat mempengaruhi jadwal Anda ketika Anda harus menunggu jawaban mereka (misalnya jika Anda meminta mereka untuk memenuhi persyaratan).

Apa yang bisa kau lakukan?

  1. Berikan jadwal yang lebih besar . Jika Anda pikir Anda bisa melakukan pekerjaan itu dalam dua minggu, katakan Anda akan mengirimkannya dalam satu bulan.

  2. Menjadi jelas . Jika Anda mengandalkan perancang, pengembang lain, dll., Katakan itu. Alih-alih mengatakan "Saya akan mengirimkan produk dalam tiga bulan", katakan "Saya akan mengirimkan produk dalam dua bulan setelah perancang akan memberi saya file PSD."

  3. Jelaskan bahwa jika persyaratan berubah setiap hari, proyek tersebut tidak akan dikirimkan tepat waktu.

  4. Iris jadwal Anda . Memberikan bagian dari proyek besar tepat waktu lebih mudah.

  5. Jangan pernah memberikan perkiraan saat Anda menggunakan produk yang tidak Anda kenal dengan baik atau, terutama, ketika Anda akan mengerjakan kode sumber orang lain: Anda tidak akan pernah bisa memprediksi seberapa buruknya kode sumber dan berapa banyak waktu yang akan Anda habiskan memahami dan menyalin-menempelkannya ke The Daily WTF.


1
@ Jeff O: Saya tidak tahu. Bagi saya, tanggal pengiriman berarti tenggat waktu. Dan tenggat waktu berarti bahwa proyek tidak dapat diberikan setelahnya. Selain itu, secara psikologis, pelanggan mungkin tidak terlalu marah ketika Anda mengatakan Anda akan mengirimkan sesuatu dalam sebulan dan Anda mengirimkannya empat hari kemudian, daripada jika, pada 8 Januari 2011, Anda mengatakan Anda akan mengirimkannya pada 8 Februari 2011, dan Anda kirimkan 12 Februari.
Arseni Mourzenko

10
@Pemdas: ini bukan masalah kemalasan. Anda bisa saja depresi, atau mengalami kesulitan sementara untuk berkonsentrasi, atau memiliki masalah pribadi / keluarga, atau terlalu stres oleh pelanggan lain atau apa pun.
Arseni Mourzenko

2
Menambah poin MainMa, jika Anda bekerja dalam tim, ada situasi di mana seseorang harus cuti, untuk kesenangan atau penyakit.
Shamim Hafiz

5
@Pemdas Mereka sampai batas tertentu terjadi pada setiap programmer. Hanya saja itu memanifestasikan dirinya dengan cara yang tidak selalu jelas. Satu minggu bekerja melalui masalah yang diberikan mungkin memakan waktu 3 jam karena Anda sangat tajam dan "di zona," sedangkan minggu berikutnya dibutuhkan 3 hari.
Matthew Frederick

7
@ 0A0D Jika Anda memecah proyek menjadi subtugas yang paling terperinci dan mencari tahu bagaimana masing-masing dari mereka akan berfungsi, maka bekerja melalui segala sesuatu untuk memastikan bahwa Anda memahami implikasi dari penggabungan potongan-potongan itu, dan teliti semua yang baru atau tidak-baru- melibatkan teknologi dalam benak Anda, dan menyingkirkan setiap hal yang tidak dikenal, maka Anda benar-benar dapat memberikan perkiraan akurat yang sangat terkutuk. Tentu saja, Anda juga telah melakukan hampir semua pemrograman, hanya menyisakan bagian pengkodean, dan Anda tidak bisa tahu sebelumnya berapa lama semua estimasi itu akan berlangsung. ;)
Matthew Frederick

15

Pertanyaan yang sangat mirip adalah "Berapa lama waktu yang dibutuhkan untuk menyelesaikan teka-teki silang ini?"

Anda tidak dapat menjawabnya sampai Anda melihatnya untuk melihat banyak hal seperti:

  • Apakah itu dalam bahasa yang akrab? (Bahasa Spanyol lawan Bahasa Inggris lawan Bahasa Cina)
  • Apakah itu salah satu tipe yang sudah kita pecahkan sebelumnya? (Satu dalam seri berjalan di majalah misalnya)
  • Apakah ada petunjuk yang membutuhkan pengetahuan tambahan sebelum kita dapat memahaminya?
  • Apakah ada di mana pun dalam hal-hal teka-teki yang, sepengetahuan Anda, akan membutuhkan pekerjaan tambahan?

Karena biasanya ada beberapa hal baru dalam suatu proyek (jika tidak itu bukan proyek), Anda tidak dapat mengatakan berapa lama waktu yang dibutuhkan untuk menyelesaikannya sampai Anda telah melihatnya dengan sangat cermat. Mungkin bahkan menyelesaikan lebih atau kurang dari mereka, dan kemudian Anda masih tidak yakin bahwa tidak ada satu atau dua kejutan di mana Anda tidak memikirkan mereka.

Juga ada tekanan kuat untuk melakukannya semurah mungkin, karenanya secepat mungkin dan kesalahan untuk perkiraan yang terlalu rendah tidak terjadi pada tekanan manajer proyek tetapi pengembang memberikan perkiraan tersebut. Tidak perlu banyak iterasi bagi pengembang untuk menangkap ini, dan belajar untuk menjadi SANGAT lelah memberikan angka absolut.


11

Alasan paling jelas mengapa insinyur Anda tidak dapat memberikan perkiraan yang akurat adalah bahwa itu tidak mungkin .

Tentu saja Anda dapat memperkirakan berapa banyak waktu + -2 menit dari rumah Anda untuk bekerja. Anda tahu cara mengendarai mobil, Anda dapat mengevaluasi lalu lintas, dan beberapa faktor eksternal lainnya.

Katakan berapa lama waktu yang Anda perlukan untuk berkendara dari London ke Barcelona. Tanpa alat perencanaan GPS canggih tentu saja. Menggunakan metode lama yang baik seperti yang masih kita lakukan dalam estimasi perangkat lunak. Estimasi dan prediksi empiris .

Dalam perangkat lunak, ini lebih buruk:

  1. Perkiraan sering menjadi komitmen , sehingga penilaian kami diubah.
  2. Mungkin ada perbedaan besar antara estimasi Bob dan Karl untuk tugas yang sama.
  3. Ketidakpastian sangat umum, berapa banyak dari kita yang terjebak pada bug bodoh atau kerusakan hard drive menghancurkan estimasi yang baik.
  4. Kami biasanya melupakan semua tugas selain pemrograman termasuk rapat, panggilan telepon, membantu rekan kami, dll.
  5. Otak manusia terbatas . Belum dirancang untuk memperkirakan tugas yang berjalan lama.

Itu sebabnya tidak mungkin memberi tahu pelanggan Anda apa yang dapat Anda kirim untuk 02/01/2011 dengan akurasi yang baik, dan lupakan tentang 03/01/2011.

Untuk mengatasi semua masalah itu, saya sarankan Anda teknik estimasi lanjutan seperti Poker Perencanaan (penafian: ini adalah salah satu situs web saya) dan Pengembangan Iteratif dengan perhitungan Velocity .

  • Dua masalah pertama dibahas menggunakan Poker Perencanaan. Estimasi bersifat kolektif dan tim memilikinya bukan individu.
  • Masalah ketiga terakhir diatasi menggunakan Velocity dan Iterative Development. Dengan mengetahui kecepatan Anda (faktor yang diterapkan pada estimasi Anda berdasarkan riwayat), Anda dapat merencanakan rilis dengan lebih percaya diri. Pengembangan berulang, bila dilakukan dengan baik, membawa fitur paling penting ke atas dan membantu Anda memberikan nilai lebih awal kepada pengguna Anda.

Jadi, jika seseorang meminta tanggal pengiriman 02/01/2011 untuk fitur, taruhan terbaik adalah mengatakan "segera setelah saya mengerjakannya, saya akan memberi tahu Anda berapa lama waktu yang dibutuhkan"? Saya yakin itu akan berjalan dengan baik seperti balon timah;)
Brian

0A0D: tergantung situasinya. Dengan tim yang tidak saling kenal, saya tidak akan bertaruh pada tenggat waktu APAPUN. Namun jika Anda mengetahui kecepatan rata-rata Anda, gunakan estimasi kolektif dan praktikkan pengembangan berulang, Anda dapat menetapkan tenggat waktu dengan lebih percaya diri.

@ 0A0D, di Eropa 02/01/2011 berarti 2 Januari. Setidaknya itu membuat jawabannya lebih mudah ketika ditanya pada 8 Januari: D

6

Pengembangan perangkat lunak - menurut definisi - tindakan penemuan dan penemuan. Itu harus selalu melibatkan sesuatu yang tidak diketahui.

Satu-satunya saat semua yang berhubungan dengan pengembangan perangkat lunak diketahui adalah ketika perangkat lunak selesai.

Satu-satunya saat tidak ada teknologi atau fitur bisnis yang tidak dikenal adalah ketika itu adalah solusi lengkap dan siap untuk diunduh.

Alasan kami menulis perangkat lunak baru adalah karena kami memiliki fitur baru atau teknologi baru atau keduanya. Baru berarti baru - tidak dikenal - tidak dapat diprediksi.

Karena pengembangan perangkat lunak harus melibatkan hal-hal baru, upaya pengembangan tidak dapat diprediksi.


3

Jujur, saya pikir itu hanya butuh latihan. Jika Anda menulis kode yang cukup pada akhirnya Anda harus "cukup" akurat. Bos pertama saya percaya bahwa keterampilan ini cukup penting sehingga ia meminta agar saya mempraktikkannya secara informal pada setiap fitur / proyek yang saya laksanakan. Setelah setiap proyek, kami meninjau taksiran dan berupaya mencari tahu di mana kesalahan saya. Akhirnya, Anda bisa menguasainya.


Setuju dengan ulasan, tapi saya benar-benar penasaran: @Pemdas, apakah Anda cenderung bekerja pada jenis masalah yang sama untuk setiap proyek, dengan hanya perubahan kecil? Apakah Anda mengacu pada hal-hal yang cukup sederhana, mungkin satu lagi layanan tenang yang pada dasarnya hanya mengembalikan baris tabel database atau sesuatu? Setelah bekerja dengan banyak programmer dan juga mempekerjakan puluhan, saya belum menemukan seseorang yang bisa memberikan perkiraan akurat untuk masalah yang penuh dengan yang tidak diketahui.
Matthew Frederick

Saya bekerja pada produk yang sama, tetapi masalah membuat perubahan dengan yang pernah dirilis. Saya akan mengakui bahwa saya tidak pernah harus memperkirakan sesuatu yang membutuhkan lebih dari 6-8 bulan untuk menyelesaikannya.
Pemdas

Perndas, hanya untuk bersenang-senang: Berapa lama untuk menulis ulang produk Anda di C # atau Java? Untuk berjalan di Google cloud? Untuk memvisualisasikan data secara langsung di OpenGL? Agar klien pengguna akhir berjalan di Wii?

Mungkin definisi estimasi kita salah. Pasti ada periode penelitian yang diperlukan sebelum Anda dapat memberikan perkiraan yang masuk akal, yang biasanya saya tidak menyertakan perkiraan waktu pengiriman saya. Saya tidak dapat menjawab pertanyaan-pertanyaan itu dengan wajar tanpa terlebih dahulu melakukan riset. Saya tidak akan pernah berasumsi bisa memberikan estimasi tanpa memahami teknologinya.
Pemdas

2

Tidak pernah mudah. Anda hanya mencoba untuk menjadi lebih baik.

Salah satu keuntungan dari memecah kode yang Anda kirim menjadi potongan-potongan kecil, adalah agar klien mendapatkan pemahaman tentang apa yang diharapkan dan kapan harus mengharapkannya. Sekarang Anda memiliki semacam garis dasar untuk digunakan sebagai referensi.

Jika mereka memiliki definisi ketat dari fitur yang mereka butuhkan pada waktu yang ditentukan, mereka perlu tahu bahwa sumber daya tambahan harus dialokasikan untuk permintaan ini. Mereka mengambil risiko dalam tingkat keparahan bug yang terjadi dan berapa lama mereka bisa pergi tanpa mereka diperbaiki. Ketika sesuatu yang besar muncul, Anda kembali ke klien dan memaksa mereka mengambil keputusan. Apakah saya memperbaiki bug atau membuat tenggat waktu pada fitur baru? Beri mereka informasi yang cukup untuk membuat keputusan.

Semoga Anda memiliki sejarah yang cukup untuk bekerja bersama dan telah memantapkan diri Anda untuk dipercaya. Anda tidak dapat mengharapkan mereka untuk sepenuhnya memahami proses pengembangan, tetapi Anda dapat membuat mereka merasa Anda melakukan upaya yang jujur ​​dan tidak mengambil keuntungan dari kurangnya pengetahuan mereka.


Saya bahkan tidak berpikir tentang rilis tambahan. Itu adalah alat yang hebat untuk memberi pelanggan beberapa kemajuan yang masuk akal. Meskipun, saya tidak bekerja dengan klien "eksternal", dengan melakukan praktik ini di rumah, itu adalah cara yang bagus untuk pengujian pipa dengan pengembangan.
Pemdas

2

Karena kami melakukan jadwal terlalu dini. Lihat artikel Construx tentang melakukan kasar awal, kemudian lebih baik nanti. Juga jika Anda tidak melacak apa yang Anda lakukan pada perkiraan sebelumnya, sulit untuk menjadi lebih baik. FogBugz melakukan itu [pelanggan yang gratis, tidak ada konflik kepentingan lain].


2

Saya telah belajar banyak dari buku ini:

Estimasi Perangkat Lunak: Demistifikasi Seni Hitam

Singkatnya untuk mendapatkan hasil estimasi yang lebih baik, kami melakukan ini:

  1. semuanya kecuali tugas-tugas sepele diperkirakan oleh lebih dari satu orang (dua dalam kasus kami)
  2. kami membagi tugas menjadi tugas yang lebih kecil. Semakin banyak tugas yang Anda miliki, semakin besar kemungkinan estimasi Anda akan baik - hukum sejumlah besar jika saya ingat dengan benar dari boo
  3. kami memperkirakan skenario terburuk, terbaik, dan kemungkinan besar. Kadang-kadang kita masing-masing memperkirakan skenario pohon yang sama sekali berbeda. Itu artinya kita harus bicara dan biasanya ternyata salah satu dari kita tidak mengerti tugasnya. Seandainya satu orang memperkirakan tugas itu sendiri maka akan diperkirakan salah.
  4. kami memasukkan 3 angka dari titik di atas ke dalam persamaan dan menerima estimasi (excell) k

Setelah pekerjaan selesai dan perkiraan kami salah, kami mencoba mencari alasannya. Dan kami menggabungkan pengetahuan ini ke dalam proses estimasi selanjutnya. Sejauh ini ini adalah proses terbaik yang saya gunakan untuk memperkirakan tugas yang lebih besar. Ketika saya mengatakan tugas, saya maksudkan pekerjaan yang membutuhkan waktu sekitar 50-500 jam.


1

Catatan: Ini benar-benar hanya berlaku untuk proyek-proyek di mana Anda menagih per jam versus tarif tetap / flat

Saya biasanya mencoba untuk merencanakan jadwal saya sehingga pada dasarnya terdiri dari sekelompok Sprint SCRUM (apakah menggunakan SCRUM atau tidak). Di depan saat membuat jadwal, saya menentukan berapa panjang masing-masing sprint dan apa saja fitur untuk proyek tersebut. Biasanya ada beberapa fitur yang harus dilakukan terlebih dahulu jadi saya mencoba memberikan perkiraan terbaik (jangan bingung dengan optimis) untuk itu dan semua fitur yang akan menuju akhir proyek akan memiliki perkiraan umum. Setelah memetakan fitur untuk sprint, saya mencoba menambahkan 1 hingga 2 sprint di bagian akhir proyek untuk memperhitungkan fitur yang meluncur ke kanan dan untuk fitur yang diabaikan dalam pengumpulan persyaratan asli.

Kunci untuk ini adalah bahwa saya membuat semua ini transparan untuk klien di muka sehingga mereka mengerti mengapa dua sprint terakhir kosong atau jarang penduduknya. Setidaknya sampai titik ini klien saya telah bekerja dengan menyukai ini karena mereka tahu bahwa ada beberapa bantal dalam jadwal / keuangan karena sebagian besar dari mereka sadar bahwa estimasi SW cenderung kurang konkret. Mereka juga sadar bahwa jika kita tidak membutuhkan sprint terakhir atau lebih, maka itu adalah jam-jam yang tidak kita tagih. Dengan transparansi dalam bagaimana jadwal dibuat dan umpan balik teratur tentang bagaimana kemajuan berlangsung selama pelaksanaan proyek, setiap klien yang saya lakukan dengan ini sangat puas.


1

Selain semua hal yang disebutkan, saya melihat dua hal ini sebagai beberapa masalah terbesar. Pertama, Anda memperkirakan tanggal akhir berdasarkan pada setiap devloper yang tersedia selama 8 jam sehari penuh 5 hari seminggu. Ini tidak benar dan hampir akan menjamin 100% bahwa tanggal berakhirnya proyek tidak sepele. Orang-orang mengambil cuti, menghadiri pertemuan perusahaan (atau non-proyek), berkelahi dengan SDM atas klaim asuransi kesehatan, beristirahat, dll. Jangan pernah menganggap lebih dari ketersediaan 6 jam per pengembang per hari.

Para penyembah berikutnya terkenal lupa untuk memperkirakan semua tugas non-pengembangan seperti pertemuan dan email tentang proyek, penyebaran, dukungan QA, dukungan UAT, tes unit penulisan, penelitian, dokumentasi dll. Setelah kami menambahkan jenis tugas ini ke spreadsheet estimasi kami, kami Perkiraan jauh lebih baik.


Saya tidak akan menyebut tes unit menulis tugas non-pengembangan;) Dan bos kami menghitung kami selama 6 jam sehari. Jika saya katakan 60 jam, mereka mengatakan 10 hari.
Piotr Perak

@Peri, Memang saya tidak akan benar-benar baik, tetapi banyak orang lupa untuk menambahkan waktu untuk menulis tes dan hanya memikirkan masalah utama yang dihadapi. Baik untuk atasan Anda, saya heran betapa banyak yang tidak.
HLGEM

1

Ketika sampai pada estimasi waktu untuk tugas-tugas yang bisa memakan waktu lebih lama maka beberapa jam saya mencoba yang terbaik untuk menggunakan aturan ini:

  1. Jangan pernah mencoba untuk memprediksi kapan orang lain akan menyelesaikan pekerjaan mereka jika Anda bergantung padanya. Bicara hanya untuk dirimu sendiri.
  2. Pertama menganalisis tugas, lalu memperkirakan. Dengan menganalisis maksud saya setidaknya menulis (dan tidak mencoba untuk menjaga semuanya di kepala Anda!) Daftar subtugas dengan estimasi untuk masing-masing dari mereka.
  3. Jika suatu tugas cukup kompleks, perkirakan waktu untuk analisis itu sendiri. Biarkan estimasi menjadi proses terpisah. Anda juga dapat memastikan atasan Anda tahu tentang itu.
  4. Jangan memperkirakan di bawah tekanan. Jelaskan bahwa dibutuhkan waktu untuk membuat estimasi yang masuk akal dan katakan saja sesuatu kepada mereka seperti "Saya akan menyebutkan tanggal besok jam 11:00 ketika saya akan selesai menganalisis tugas". Saya tahu beberapa pelanggan / manajer dapat menekan dengan keras, tetapi mereka tidak akan lulus. Kenakan wajah sibuk Anda dan klaim waktu Anda!
  5. Tanyakan sedikit lebih banyak waktu daripada yang Anda pikir akan Anda perlukan karena Anda mungkin lupa menambahkan waktu rehat kopi (dan juga gangguan lainnya) dalam perkiraan Anda.
  6. Untuk tugas besar tanyakan lebih banyak - mungkin akan ada lebih dari satu rehat kopi.
  7. Jika Anda benar-benar tidak dapat memperkirakan (tugasnya terlalu sulit / asing) atau benar-benar tidak yakin - tanyakan kepada seseorang yang mampu membantu analisis Anda.

Mungkin ada lebih banyak aturan dari itu, tapi saya sebenarnya tidak punya poster dengan aturan ini di dinding saya. Saya baru saja merumuskannya, tetapi itu berasal dari pengalaman saya (jadi mungkin tidak berhasil untuk Anda).

Satu-satunya cara yang dapat diandalkan untuk menjadwalkan pengembangan perangkat lunak yang dapat saya pikirkan (tapi saya belum benar-benar mencobanya) adalah Penjadwalan Berbasis Bukti yang pada dasarnya adalah metode Monte Carlo yang digunakan untuk menghitung probabilitas tanggal pengiriman berdasarkan catatan historis tentang tugas yang Anda lakukan. Saya telah menyelesaikan sebelumnya. Rasanya menyenangkan karena tidak mencoba menggunakan metrik apa pun selain perkiraan dan waktu sebenarnya. Namun, itu membutuhkan banyak pengalaman untuk membagi tugas-tugas besar menjadi yang lebih kecil sebelumnya dan Anda harus memiliki satu set data historis yang besar untuk membuatnya bekerja cukup tepat.


1

Ada "tidak dikenal yang diketahui" dan "tidak dikenal". :-)

  1. Perkiraan sering menjadi tenggat waktu.

    • Tidak ada yang mau melewatkan tenggat waktu dan menjadi tajuk utama!
  2. Persyaratan berubah (seringkali rasional) dan programmer tidak dapat memveto itu.

  3. Programmer tidak / mungkin tidak memiliki kendali atas faktor-faktor seperti

    • Ketersediaan kode yang menjadi sandarannya
    • Kualitas kode tempat dia bergantung
    • Keseluruhan arsitektur dan desain sistem
    • API untuk mengakses bagian lain dari sistem
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.