Joel on Software

Joel on Software   Pojok Software Joel

 

Artikel-artikel "Joel on Software" lain dalam bahasa Indonesia

Artikel-artikel "Joel on Software" lain dalam bahasa Inggris

Email pengarang (hanya dalam bahasa Inggris)

 

Pembuatan Jadwal Software yang mudah


Oleh Joel Spolsky
Diterjemahkan oleh Mas Agung Sachli
29 Maret 2000

Oktober lalu, perusahaan Northeast US mengiklankan sesuatu yang dinamakan Acela, sebuah kereta api cepat dari Boston ke Washington. Dengan iklan TV, papan reklame, dan poster dimana-mana, anda akan berpikir bahwa hal tersebut akan menciptakan permintaan untuk jasa express baru dari Amtrak ini.

Mungkin saja. Namun Amtrak tidak mendapat kesempatan untuk mengetahuinya. Acela ditunda, dan ditunda lagi, sehingga kampanye marketing dimulai saat jasa Acela belum juga tersedia. Yang mana mengingatkan saya terhadap apa yang dikatakan oleh seorang manager marketing saat produknya mendapat ulasan yang bagus satu bulan sebelum produknya dijual: "Publisitas yang bagus! Sayang anda tidak dapat membeli produk tersebut!"

Perusahaan game Testosterone-crazed sering menyatakan di web site mereka bahwa game berikutnya akan dijual "saat sudah siap". Jadwal? Kami tidak memerlukan jadwal apa pun! Kami adalah programer game yang hebat! Kebanyakan perusahaan tidak mempunyai kemewahan seperti itu. Tanyakan pada Lotus. Saat mereka merilis 123 versi 3.0, program tersebut memerlukan komputer 80286, yang mana saat itu belum terlalu umum. Mereka menunda produk tersebut selama 16 bulan sementara mereka bekerja untuk bisa jalan di batas memory 640K dari 8086. Saat mereka sudah siap, Microsoft telah mendahului 16 bulan dalam mengembangkan Excel, dan yang lucunya lagi, 8086 sudah ketinggalan jaman.

Saat saya menulis artikel ini, web browser Netscape's 5.0 telah hampir 2 tahun terlambat. Sebagian, ini karena mereka telah melakukan kesalahan yang fatal dengan membuang semua kode mereka dan mulai dari awal lagi: kesalahan yang sama yang menyebabkan Ashton-Tate, Lotus dan MacOS-nya Apple masuk ke dalam tong sampah sejarah software. Netscape telah melihat pangsa pasar browser-nya turun dari 80% menjadi 20% selama saat itu, sementara itu mereka tidak dapat melakukan apapun untuk mengatasi masalah persaingan ini, karena produk software utama mereka telah dipecah ke lantai menjadi 1000 bagian dan tidak ada bentuknya lagi. Keputusan buruk tersebut, melebihi apa pun, menjadi bom nuklir yang meledakkan Netscape sendiri. (Lihat detailnya di artikel Jamie Zawinski: world-famous tantrum ).

Jadi, anda harus membuat jadwal. Hampir tidak ada programer yang ingin melakukan hal tersebut. Menurut pengalaman saya, sebagian besar bahkan berusaha menghindari pembuatan jadwal sama sekali. Dari sedikit yang membuat jadwal, kebanyakan karena disuruh oleh atasan mereka untuk melakukannya, dengan setengah hati, dan tidak ada yang benar-benar percaya jadwal tersebut kecuali management tingkat atas, yang secara bersamaan percaya bahwa "tidak ada proyek software yang pernah tepat waktu" dan percaya adanya UFOs.

Lalu, kenapa tidak ada orang yang membuat jadwal? Ada dua alasan. Pertama, melakukan hal tersebut sungguh menyebalkan. Kedua, tidak ada yang percaya bahwa hal tersebut ada manfaatnya. Mengapa menjalani segala kesulitan dalam membuat jadwal jika jadwalnya tidak akan tepat? Ada persepsi bahwa jadwal secara konsisten selalu salah dan makin hari makin buruk, jadi mengapa menderita untuk hal yang sia-sia?

Ini ada cara yang sederhana dan mudah untuk membuat jadwal yang benar-benar tepat.

1) Gunakan Microsoft Excel. Jangan gunakan yang hebat-hebat seperti Microsoft Project. Kesulitan bila memakai Microsoft Project adalah asumsi bahwa anda mau menghabiskan banyak waktu untuk mengkhawatirkan tentang ketergantungan. Sebuah ketergantungan adalah jika anda mempunyai dua tugas, yang satu harus dikerjakan dulu sebelum yang lain bisa mulai. Saya menyadari bahwa di software, ketergantungan tersebut sangatlah jelas, sehingga tidak sebanding usaha untuk secara formal mengawasi hal tersebut.

Masalah yang lain pada Project adalah asumsi bahwa anda ingin dapat menekan satu tombol kecil dan "menyeimbangkan" jadwal tersebut. Tidak dapat dihindari, hal ini berarti jadwal akan diatur ulang dan di-assign ulang ke orang yang berbeda. Untuk software, hal ini tidak masuk akal. Programer tidak dapat ditukarkan. Akan memakan waktu 7 kali lebih lama untuk John untuk memperbaiki bug-nya Rita dibandingkan Rita memperbaiki bug-nya Rita. Dan jika anda mencoba meminta programer UI menyelesaikan masalah WinSock, dia akan macet dan menghabiskan seminggu agar bisa terbiasa dengan WinSock Programming. Intinya adalah Project dirancang untuk membangun bangunan perkantoran, bukan untuk software.

2) Jadikan sederhana. Format standard yang saya pakai untuk jadwal sebegitu sederhananya sehingga anda dapat menghafalkan. Anda mulai dengan tujuh kolom:

Jika anda mempunyai beberapa orang developer, anda dapat memilih membuat sebuah lembar yang terpisah untuk masing-masing programer, atau dibuatkan sebuah kolom lagi dengan nama programer pada masing-masing tugas.

3) Setiap fitur harus terdiri dari beberapa tugas. Sebuah fitur adalah sesuatu seperti menambahkan spell checker ke program anda. Menambah Spell Checker terdiri dari beberapa tugas yang berbeda yang harus dilakukan oleh programer. Bagian yang paling penting dalam pembuatan jadwal adalah membuat daftar tugas. Jadi aturan yang utama adalah:

4) Hanya programer yang akan menulis kode saja yang boleh menyusun jadwal. Sistem mana pun di mana management menuliskan sebuah jadwal dan menyerahkannya kepada programer akan dipastikan gagal. Hanya programer yang akan mengerjakan tugas tersebut yang dapat membayangkan langkah apa yang akan dilakukan untuk membuat fitur tersebut. Dan hanya programer yang dapat memperkirakan berapa lama waktu yang diperlukan.

5) Buat tugas yang sangat detail. Hal ini merupakan bagian yang paling penting agar jadwal anda bisa berhasil. Tugas anda harus diukur dalam hitungan jam, bukan hari. (Saat saya melihat sebuah jadwal yang diukur dalam hari, bahkan dalam minggu, saya tahu itu tidak nyata). Anda mungkin berpikir bahwa sebuah jadwal yang sangat detail pasti tidak tepat. Salah! Sangat keliru! Saat anda mulai dengan sebuah jadwal dengan tugas yang besar dan memecahkannya menjadi tugas yang lebih kecil, anda akan mendapati bahwa anda mendapatkan hasil yang berbeda, tidak hanya yang lebih tepat. Benar-benar angka yang sangat berbeda. Mengapa hal ini terjadi?

Saat anda harus membuat tugas yang detail, anda akan memaksa diri sendiri untuk benar-benar memikirkan langkah apa yang harus diambil. Menulis subrutin foo. Membuat dialog ini dan itu. Baca file Wawa. Langkah ini mudah untuk diperkirakan, karena anda sudah pernah menulis subrutin, membuat dialog, dan membaca file wawa sebelumnya.

Jika anda ceroboh, dan mengambil tugas yang besar, lalu anda belum benar-benar memikirkan apa yang akan dilakukan. Dan saat anda belum memikirkan apa yang akan dilakukan, anda pasti tidak bisa mengetahui berapa banyak waktu yang diperlukan.

Sebagai panduannya, setiap tugas harus antara 2 sampai 16 jam. Jika anda mempunyai tugas 40 jam (satu minggu) dalam jadwal anda, anda belum cukup memecahkan tugas tersebut.

Alasan yang lain untuk memilih tugas yang detail: hal ini akan memaksa anda untuk merancang fitur tersebut. Jika anda mempunyai fitur menarik yang dinamakan "Internet Integration" dan anda menjadwalkan 3 minggu untuk itu, anda akan celaka, teman. Jika anda harus membayangkan subrutin apa yang harus ditulis, anda akan dipaksa untuk memperbaiki fitur tersebut. Dengan dipaksa untuk merencanakan kedepan di level ini, anda menghilangkan banyak ketidakstabilan di dalam sebuah proyek software.

6) Catat terus perkiraan asli dan perkiraan saat ini. Saat anda pertama kali menambahkan sebuah tugas di jadwal, perkirakan berapa lama hal ini akan berlangsung dalam hitungan jam dan letakan di kolom Orig[inal] Est[imate] dan Curr[ent] Est[imate]. Sejalan dengan waktu, jika tugas tersebut memakan waktu yang lebih lama (atau lebih singkat) yang anda pikir, anda bisa mengubah kolom CurrEst sebanyak yang anda butuhkan. Ini merupakan cara terbaik untuk belajar dari kesalahan dan mengajari diri anda sendiri bagaimana membuat estimasi dengan baik. Kebanyakan programer tidak mengetahui bagaimana menebak berapa lama suatu tugas dikerjakan. Tidak masalah. Sepanjang anda terus menerus belajar dan selalu mengubah jadwal sambil belajar, jadwal tersebut akhirnya akan tepat.(Anda mungkin harus memotong fitur atau kelewatan, namun jadwal tersebut akan tetap bekerja dengan tepat, dalam pengertian bahwa ia akan secara konstan memberitahukan anda kapan harus memotong fitur atau kelewatan). Saya mendapati bahwa kebanyakan programer menjadi pembuat jadwal yang sangat baik dalam waktu kira-kira satu tahun pengalaman.

Saat tugas selesai, field Curr Est dan Elapsed akan sama, dan field Remain akan menjadi 0.

7) Update kolom Elapsed setiap hari. Anda tidak perlu memperhatikan stopwatch saat anda menulis kode. Tepat sebelum anda pulang, atau tidur di bawah meja jika anda gila kerja, anggap anda telah bekerja selama 8 jam (ha!), pikirkan tugas apa saja yang telah anda lakukan, dan bagikan 8 jam tersebut ke kolom elapsed yang sesuai. Field sisa waktu akan dihitung oleh Excel secara otomatis.

Pada saat yang sama, update kolom Curr Est untuk tugas tersebut untuk mencerminkan kenyataan yang terakhir. Meng-update jadwal anda setiap hari seharusnya hanya memakan waktu 2 menit. Itu sebabnya mengapa disebut Methode Penjadwalan yang Painless -- hal ini cepat dan mudah.

8) Tambahkan baris untuk Cuti, Hari Libur, dll. Jika jadwal anda akan memakan waktu sekitar 1 tahun, setiap programer kemungkinan akan mengambil 10 sampai 15 hari cuti. Anda harus mempunyai sebuah fitur di jadwal anda yang namanya Cuti, satu untuk Hari Libur, dan lainnya yang memakan waktu. Idenya adalah tanggal selesai dapat dihitung dengan menjumlahkan isi kolom waktu sisa dan dibagi dengan 40 -- didapatkan berapa minggu lagi perkerjaan akan selesai, termasuk semuanya.

9) Tambahkan waktu debugging ke dalam jadwal! Debugging merupakan hal yang tersulit untuk diperkirakan. Pikirkan kembali proyek terakhir yang anda kerjakan. Kemungkinan adalah, debugging memakan waktu 100% - 200% dari waktu yang diperlukan untuk menulis kode itu sendiri. Ini harus menjadi 1 baris item di jadwal, dan mungkin menjadi baris yang terbanyak.

Begini caranya. Anggap seorang programer sedang mengerjakan wawa. Orig Est-nya adalah 16 jam, namun sampai sekarang sudah memakan waktu 10 jam dan nampaknya masih membutuhkan 10 jam lagi. Jadi programer itu mengisi 30 di kolom Curr Est dan 20 di kolom Elapsed.

Pada akhir milestone, semua "slips" ini mungkin telah bertambah besar. Teorinya, untuk mengakomodasi slip ini, kita harus memotong fitur untuk dapat menyelesaikan tepat waktu. Untungnya, fitur utama yang dapat kita potong dulu adalah fitur besar yang dinamakan Buffer yang memiliki banyak waktu yang dialokasikan untuk dia.

Pada prinsipnya, developer mendebug kodenya seiring dengan mereka penulisan kode. Seorang programer jangan pernah menulis kode baru jika mereka harus memperbaiki bug. Jumlah bug harus serendah mungkin setiap saat. Alasannya:

1) Akan lebih mudah memperbaiki bug pada hari yang sama anda menulisnya. Akan sangat sulit dan memakan waktu untuk memperbaiki bug satu bulan kemudian ketika anda telah lupa bagaimana kode anda bekerja.

2) Mencari bug seperti perkerjaan ilmiah. Tidaklah mungkin memperkirakan kapan anda akan membuat suatu penemuan dan menyelesaikan suatu bug. Jika hanya ada satu atau dua bug yang belum selesai di setiap saat, akan mudah untuk memperkirakan kapan produknya siap dipasarkan, karena tidak ada banyak bagian yang tidak dapat diprediksi. Di lain pihak, jika ada ratusan bahkan ribuan bug outstanding, tidak mungkin untuk memprediksi kapan mereka dapat diperbaiki.

Jika developer selalu memperbaiki bug sambil jalan, untuk apa ada item debugging? Walaupun anda berusaha untuk memperbaiki bug sambil jalan, di setiap milestone, akan muncul banyak bug yang tidak dapat dihindari saat tester (internal dan beta) menemukan bug yang sangat sulit.

10) Tambahkan waktu integrasi ke dalam jadwal. Jika anda memiliki lebih dari seorang programer, tidak dapat dihindari, akan ada hal dimana dua programer melakukan sesuatu yang tidak konsisten dan perlu digabung. Mungkin mereka berdua membuat kotak dialog untuk tujuan yang sama yang tidak konsisten. Seseorang harus memeriksa semua menu, keyboard accelerators, toolbar tools, dll, membersihkan dan mengatur semua menu item baru yang telah ditambah macam-macam hal. Akan ada kesalahan compiler yang muncul saat dua orang memasukan kode. Hal ini perlu diperbaiki, dan harus merupakan satu baris item pada jadwal.

11) Tambahkan buffer ke dalam jadwal. Segala sesuatu cenderung salah. Ada dua macam buffer yang perlu dipertimbangkan. Pertama: buffer untuk menampung tugas yang pekerjaannya melebihi waktu yang diperkirakan. Kedua: buffer untuk tugas yang anda tidak tahu bahwa harus dikerja, biasanya karena management telah memutuskan bahwa implementasi wawa adalah SUPER PENTING dan tidak dapat ditunda ke release berikutnya.

Anda akan terkejut mendapati bahwa jumlah gabungan antara waktu cuti, hari libur, debugging, integrasi, dan buffer lebih besar dari waktu untuk tugas yang sebenarnya. Jika anda terkejut dengan ini, berarti anda belum lama membuat program kan? Abaikan hal ini dengan resiko anda sendiri.

12) Jangan pernah membiarkan manager meminta untuk mengurangi suatu estimasi. Banyak manager software baru berpikir bahwa mereka dapat "memotivasi" programer mereka bekerja lebih cepat dengan cara memberikan jadwal yang bagus dan "ketat" (yang pendek & tidak realistis). Saya pikir motivasi demikan akan membunuh pikiran. Saat saya terlambat, saya akan merasa kecewa dan tertekan dan tidak termotivasi. Saat saya lebih awal dari jadwal, saya senang dan produktif. Suatu jadwal bukanlah tempat untuk bermain permainan psikologi.

Jika manager anda mengharuskan anda mengurangi suatu perkiraan, ini yang harus anda lakukan. Buat sebuah kolom baru di jadwal tersebut yang namanya Rick's Estimate (asumsi nama anda adalah Rick, tentu saja). Letakkan estimasi anda di sini. Biarkan manager lakukan apa pun yang ingin dia lakukan dengan kolom Curr Est. Abaikan estimasi manager anda. Saat proyeknya selesai, lihat estimasi siapa yang lebih dekat dengan realitas. Saya menyadari bahwa melakukan pekerjaan ini sama mengancamnya, khususnya bila manager anda menyadari mereka baru saja masuk ke suatu kontes untuk melihat seberapa lambatnya anda bekerja!

Mengapa manager yang tidak bijak mencoba meminta programer untuk mengurangi waktu estimasinya?

Saat suatu proyek mulai, manager teknik pergi menemui orang bisnis, dan muncul dengan sebuah daftar fitur yang mereka pikir akan memakan waktu kira-kira 3 bulan, namun sebenarkan akan memakan waktu 9. Ketika anda berpikir tentang menulis kode tanpa memikirkan seluruh langkah yang harus diambil, akan kelihatannya membutuhkan waktu n, namun kenyataan akan memakan waktu 3n. Saat anda membuat sebuah jadwal yang sebenarnya, anda menambahkan semua tugas dan menyadari bahwa proyek ini akan berlangsung lebih lama dari pemikiran awal. Kenyataan yang menyedihkan.

Manager yang tidak bijak mencoba mengatasi hal ini dengan memikirkan cara agar orangnya bekerja lebih cepat. Hal ini sangat tidak realistik. Anda mungkin bisa menggaji orang lagi, namun mereka perlu penyesuaian dan mungkin akan bekerja dengan efisiensi 50% selama beberapa bulan (dan menyeret efiensi orang yang harus membimbing mereka). Bagaimana pun, di bidang ini, menambahkan programmer yang bagus akan memakan waktu 6 bulan.

Anda mungkin dapat menghasilkan 10% kode mentah dari karyawan anda sebentar dengan resiko membuat mereka burn out 100% selama satu tahun. Bukan hasil yang sepadan, dan hal ini seperti memakan bibit jagung anda sendiri.

Anda mungkin dapat menghasilkan 20% lebih banyak kode mentah dari staf anda dengan memohon setiap orang untuk bekerja super keras, tidak perduli seberapa letihnya mereka. Boom, waktu debugging menjadi dua kali lipat. Suatu langkah bodoh yang menghasilkan hal buruk yang kelihatan seperti nasib.

Namun anda tidak pernah bisa mendapatkan 3n dari n, dan jika anda pikir bisa, tolong email saya nama stock perusahaan anda sehingga saya dapat membelinya.

13) Sebuah jadwal seperti balok kayu. Jika anda memiliki setumpuk balok kayu, dan anda tidak dapat memasukkannya ke dalam sebuah kota, anda mempunyai 2 pilihan: mencari kotak yang lebih besar, atau membuang beberapa balok. Jika anda pikir anda dapat menyelesaikan dalam 6 bulan, namun anda memiliki 12 bulan pada jadwal, anda haru menunda peluncuran, atau mencari fitur yang harus dibuang. Anda tidak dapat menyusutkan baloknya, dan jika anda berpura-pura bisa, maka anda akan kehilangan kesempatan untuk benar-benar melihat ke depan dengan menipu diri anda akan apa yang dilihat di sana.

Dan perlu anda ketahui, hasil sampingan lain yang bagus dengan menepati jadwal seperti ini adalah anda akan dipaksa untuk menghapus jadwal. Mengapa ini bagus? Bayangkan anda mempunyai 2 fitur: saya yang benar-benar berguna dan akan membuat produk anda sangat bagus (contoh: tabel di Netscape 2.0), dan yang lainnya yang sungguh mudah dan yang programmer akan senang untuk membuatkan (contoh: tag BLINK), namun tidak berguna atau tidak ada tujuan marketingnya.

Jika anda tidak membuat jadwal, programer akan melakukan fitur yang mudah/menyenangkan dulu. Kemudian mereka akan kehilangan waktu, dan anda tidak mempunyai pilihan lagi kecuali mundur dari jadwal release untuk melakukan fitur yang berguna/penting.

Jika anda membuat jadwal, bahkan sebelum anda mulai bekerja, anda akan sadar bahwa anda harus memotong sesuatu, jadi anda akan memotong fitur yang mudah/menyenangkan dan hanya melakukan fitur yang berguna/penting. Dengan memaksa diri anda untuk memilih beberapa fitur untuk dibuang, anda akan membuat produk yang lebih powerful dan lebih baik dengan kombinasi fitur bagus yang selesai lebih awal.

Saya ingat saat mengerjakan Excel 5. Daftar asli fitur kami sangat besar sekali dan melebihi jadwal. Ya ampun! Kami pikir. Semuanya adalah fitur yang super penting! Bagaimana kita bisa hidup tanpa wizard macro editing?

Saat disadari, kami tidak mempunyai pilihan, dan kami memotong apa yang kami pikir "sampai ke tulang" untuk membuat jadwal. Setiap orang merasa tidak senang dengan pemotongan tersebut. Untuk memperbaiki perasaan ini, kami berkata pada diri kami bahwa kami tidak memotong fitur, hanya menundanya sampai Excel 6, karena fiturnya kurang penting.

 Saat Excel 5 hampir selesai, saya mulai mengerjakan spec untuk Excel 6 dengan seorang rekan kerja, Eric Michelman. Kami duduk menelurusi daftar fitur "Excel 6" yang merupakan pemotongan dari jadwal Excel 5. Kami sangat terkejut melihat bahwa daftar fitur yang terpotong itu merupakan daftar terburuk yang dapat anda bayangkan. Tidak satu pun dari fitur tersebut yang pantas untuk dikerjakan. Saya rasa tidak satu pun dari fitur tersebut yang pernah dibuat, bahkan untuk 3 release ke depan.

Proses pemotongan fitur untuk disesuaikan dengan jadwal merupakan hal yang terbaik yang dapat kami lakukan. Jika kami tidak melakukan hal ini, Excel 5 mungkin akan memakan wkatu 2 kali lebih lama dan termasuk 50% fitur yang tidak berguna. (Saya sangat yakin hal ini yang terjadi dengan Netscape 5/Mozilla: mereka tidak mempunyai jadwal, mereka tidak mempunyai daftar fitur yang pasti, tidak ada yang berniat memotong fitur apapun, dan mereka tidak pernah selesai. Saat mereka selesai, mereka akan mempunyai banyak fitur seperti IRC client yang seharusnya tidak mereka habiskan waktu untuk itu.

Appendix: Hal yang perlu anda ketahui tentang Excel

Salah satu alasan kenapa Excel merupakan produk yang sangat bagus untuk melakukan penjadwalan software adalah karena Excel digunakan oleh sebagian besar programer Excel hanya untuk memelihara jadwal software mereka! (Tidak banyak dari mereka yang menjalankan skenario bisnis... mereka adalah programer!)

Shared Lists Menggunakan perintah File/Shared Lists memperbolehkan setiap orang membuka suatu file pada saat yang bersamaan. Karena seluruh tim anda harus meng-update jadwal secara konstan, hal ini sangat membantu.

Auto Filter Ini merupakan cara yang terbaik untuk menyaring jadwal agar, sebagai contoh, anda hanya melihat semua fitur yang di assign ke anda. Dikombinasikan dengan Auto Sort, anda dapat melihat semua fitur yang di-assign ke anda dengan urutan prioritas yang secara efektif menjadi daftar "yang harus dikerjakan" anda. Kereeeeeen!

Pivot Tables Ini merupakan cara terbaik untuk melihat rangkuman dan crosstabulation. Sebagai contoh, anda dapat melihat sebuah grafik yang menampilkan sisa jam untuk masing-masing programer untuk masing-masing prioritas. Pivot Table menjadi seperti potongan roti dan milkshake coklat. Anda harus belajar cara memakainya karena hal tersebut akan membuat Excel jutaan kali lebih powerful.

The WORKDAY Function dari Analysis Toolpak-nya Excel merupakan cara terbaik untuk mendapatkan tanggal kalendar dari sebuah jadwal yang mudah.



Artikel ini aslinya bahasa Inggris dengan judul Painless Software Schedules  

Joel Spolsky adalah pendiri Fog Creek Software, sebuah perusahaan software kecil di New York City. Dia lulus dari Yale University, dan pernah bekerja sebagai programer dan manajer di Microsoft, Viacom, dan Juno.


Isi halaman-halaman ini mewakili opini dari satu orang.
Semua isi Hak Cipta ©1999-2005  dari Joel Spolsky. Hak Cipta dilindungi Undang-undang

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky