Cara terbaik untuk merencanakan pemrograman untuk tim kecil? [Tutup]

Saya adalah Direktur organisasi startup kecil. Saat ini kami memiliki dua programmer (satu berpengalaman, satu kurang berpengalaman) yang sedang membangun platform aplikasi web.

Salah satu tantangan terbesar sejauh ini adalah proses perencanaan. Programmer biasanya bertugas merencanakan pekerjaan mereka sendiri, tetapi kami terus melampaui tenggat waktu yang ditentukan sendiri. Misalnya, tugas yang mereka perkirakan akan memakan waktu 2 hari, akhirnya memakan waktu 8 hari.

Bagi saya sulit untuk mendukung mereka dalam perencanaan, karena saya tidak memiliki pengetahuan teknis untuk secara tepat memperkirakan berapa lama tugas tertentu akan berlangsung.

Apakah kamu punya ide:

1. Apa alasannya, apakah ini biasa untuk programmer?
2. Apa yang dapat saya lakukan untuk mendukung mereka dalam perencanaan? Apakah ada metode atau alat yang berguna bagi pemrogram dalam tim kecil?

Teknik umum agak masuk akal, yang penting untuk diketahui adalah bahwa mereka tidak memerlukan banyak keahlian teknis.

Titik awal dengan perencanaan adalah untuk mengidentifikasi masalah yang tepat yang perlu diselesaikan dan memiliki persyaratan yang jelas dan tidak ambigu. Jika Anda tidak memilikinya, perkiraan Anda akan salah. Memiliki ini didokumentasikan dalam semacam spesifikasi fitur sebelum siapa pun mulai menulis kode akan berarti bahwa setiap pertanyaan yang perlu ditanyakan akan ditanyakan sebelum pengkodean dimulai. Ini adalah penghemat waktu yang sangat efektif. Kembali dan mengklarifikasi persyaratan memecah aliran seseorang sebagai programmer dan menunggu tanggapan dapat menghalangi kemajuan.

Setelah Anda mengidentifikasi persyaratan, Anda perlu mengidentifikasi tugas-tugas pekerjaan yang terlibat dalam menyelesaikannya. Ini adalah latihan membagi dan menaklukkan klasik - tugas apa pun yang dapat dipecah lebih lanjut perlu dipecah lebih lanjut.

Dalam tim yang lebih besar, Anda dapat menggunakan poker estimasi untuk mendapatkan estimasi berdasarkan pengalaman semua orang yang terlibat. Itu tidak bekerja dengan baik di tim yang lebih kecil, tetapi masih berguna untuk mendapatkan perkiraan independen dari kedua pengembang Anda dan mungkin untuk memasukkan satu dari Anda sendiri juga - kurangnya keahlian khusus Anda dapat membantu di sini karena dalam menjelaskan kepada Anda apa tugas ini melibatkan dari perspektif mereka, tim pengembangan mungkin akan memahami masalah dengan lebih baik.

Dengan tim yang lebih kecil dapat membantu untuk mendapatkan estimasi kasus terbaik / yang diharapkan / terburuk untuk setiap tugas, yang memberi Anda berbagai nilai, tetapi jika Anda mendapatkan banyak perkiraan overrun, Anda dapat condong ke arah kasus terburuk sampai dev Anda belajar memperkirakan lebih akurat.

Di sebuah toko kecil, pengembang sering berakhir menjadi dua kali lipat sebagai sysadmin, tim pendukung, dan bahkan penguji (meskipun dari semua hal yang dapat mereka lakukan, pengujian adalah yang harus Anda coba hindari dengan cara apa pun) sehingga Anda perlu memperhitungkannya. Cari tahu berapa banyak waktu mereka yang dihabiskan pengembang Anda untuk mengerjakan fitur-fitur baru dan faktor yang menjadi perkiraan Anda. Jika tugas diperkirakan 2 hari tetapi devs Anda hanya dapat bekerja pada pengembangan baru 60% dari waktu, maka Anda akan membutuhkan 4 hari untuk selesai. Anda mungkin dapat membantu dengan ini juga dengan mengendalikan saluran tugas-tugas lain yang perlu mereka tangani sehingga admin yang tidak mendesak atau tugas-tugas pendukung dapat dikumpulkan bersamaan daripada ditangani secara ad-hoc. Banyak programmer (tentu termasuk saya yang satu ini) bukan manajer waktu yang hebat, jadi apa pun yang dapat Anda lakukan untuk membantu dalam hal itu akan membantu. Single-tasking selalu lebih mudah bagi programmer daripada multi-tasking. Memblokir waktu di siang hari juga bisa membantu.

Menyimpan catatan - setiap kali Anda memiliki sesi perencanaan, catat estimasi dan aktualnya. Anda kemudian dapat menggunakan ini a) sebagai panduan untuk berapa banyak mengembang perkiraan mereka dengan selama perencanaan dan b) untuk membantu mereka memperbaiki keterampilan estimasi mereka. Pada akhir setiap iterasi (atau apa pun yang setara dengan yang Anda miliki), seluruh tim harus meninjau pekerjaan yang telah dilakukan dan mencari tahu mengapa perlu waktu lebih lama dari yang diharapkan sehingga ini dapat dimasukkan dalam perkiraan di masa mendatang. Ini harus menjadi tugas yang tidak bersalah - Anda tampaknya memiliki sikap yang benar di sini tetapi jawaban ini mungkin ada beberapa saat sehingga saya akan melakukan pengamatan. Jika seseorang mengatakan "Saya membuat kesalahan di sini" Anda dapat mengubahnya menjadi "apa yang bisa Anda lakukan dengan lebih baik", tetapi mengatakan kepada orang-orang bahwa mereka terlalu lambat atau melakukan kesalahan hanya akan memperburuk keadaan.

Saya menyadari tidak ada peluru perak untuk masalah jenis ini tetapi faktor terbesar adalah komunikasi - yang sebenarnya lebih mudah dengan tim yang lebih kecil - dan menggunakan umpan balik untuk memperbaiki keterampilan kolektif Anda.

Apa alasan untuk [perkiraan 2 hari untuk 8 hari], apakah ini biasa untuk programmer?

Yaitu, jika:

• Sebenarnya tidak jelas apa yang seharusnya mereka lakukan, sehingga mereka mengambil lebih banyak waktu untuk memperbaikinya (dan mereka harus mengatakannya, tidak menebak tentang berapa lama waktu yang dibutuhkan)
• Mereka tidak terbiasa dengan tugas yang ada (maka mereka harus menyebutkan itu dan memasukkan penelitian dalam perkiraan)
• Integrasi tugas selesai dengan produk yang lebih besar membutuhkan waktu lebih lama daripada yang diperkirakan (yang mungkin berarti arsitektur produk lebih rendah)
• Pengembang suka menemukan kembali roda, dan melakukan hal itu tersandung masalah yang telah dipecahkan oleh orang lain, tersedia secara bebas di perpustakaan
• Perubahan diperkenalkan oleh pemilik produk saat tugas sedang dilaksanakan, membutuhkan pendekatan yang berbeda dan ulangan pekerjaan sudah dilakukan
• Pengembang tidak bekerja di lingkungan yang produktif (jadi ketika di rumah mereka kira itu akan memakan waktu dua hari, tetapi di tempat kerja mereka akan membutuhkan delapan untuk mengkompensasi semua gangguan)

Untuk menyebutkan beberapa hal.

Mungkin yang terbaik adalah bertanya kepada pengembang Anda mengapa menurut mereka perkiraan mereka jauh. :-)

Anda tidak akan menjadi yang pertama dalam kesulitan untuk mencoba mencari cara terbaik untuk merencanakan waktu pengembangan. Ini sebagian karena fakta bahwa sulit untuk mengukur sesuatu yang Anda tidak dapat benar-benar melihat sedang dibangun, dan sebagian karena bulan mitos manusia , yang merupakan kontras langsung dengan ide intuitif bahwa jika Anda memiliki 2 programmer, Anda harus dapat berkembang dua kali lebih cepat daripada jika Anda memiliki 1 programmer.

Seperti yang mungkin sudah Anda sadari, itu jauh lebih rumit dari itu. Salah satu pendekatan untuk memperkirakan waktu pengembangan sebagai pengelompokan sekelompok orang yang sangat berkualifikasi untuk apa yang menyangkut pengembangan perangkat lunak dan meminta mereka untuk memperkirakan jumlah waktu yang dibutuhkan untuk menyelesaikan suatu proyek (menjelaskan sedetail mungkin). Anda mengambil yang tertinggi dari semua perkiraan dan Anda menggandakannya . Ya, Anda membaca dengan benar. Anda berlipat gandaestimasi tertinggi dan Anda harus memiliki perkiraan yang cukup akurat. Saya tahu, karena dengan waktu, beginilah cara saya dapat memberi tahu bos saya secara akurat berapa lama saya melakukan sesuatu. Saya mengumpulkan pendapat dari sesama programmer dan saya sendiri dan menggandakan estimasi tertinggi. Jika nampaknya nilai ini terlalu tinggi, pertimbangkan untuk menguji fungsionalitas baru yang penting dan pertimbangkan perbaikan bug yang mungkin terjadi setelahnya, dan itu akan terlihat seperti angka yang lebih masuk akal.

Dalam pengalaman pribadi saya sebagai seorang programmer, saya dapat memberitahu Anda bahwa membantu memecah proyek menjadi tonggak sejarah. Berapa lama waktu yang dibutuhkan untuk mencapai tonggak 1, lalu dari tonggak 1 ke tonggak 2, lalu tonggak 2 hingga tonggak 3, dll.? Ketika dipecah seperti ini, jawabannya biasanya jauh lebih akurat daripada mencoba memperkirakan keseluruhan proyek secara keseluruhan. Anehnya, jika Anda meringkas perkiraan dari semua tonggak ini, biasanya akan lebih besar dari perkiraan awal pada seluruh proyek (jika programmer tetap jujur ​​pada dirinya sendiri), yang hanya membuat saya berpikir bahwa detail adalah kuncinya sini.

Mungkin Anda tidak memiliki pengetahuan teknis, tetapi Anda harus tetap mencoba untuk mengikuti pada tingkat yang lebih umum. Programmer tidak memiliki masalah dengan pengulangan. Ini tikungan dan belokan yang menempati sepanjang waktu dalam mengembangkan program. Jadi kemungkinan besar, semakin banyak fungsionalitas yang ingin Anda sertakan, semakin rumit program yang akan terjadi, dan dengan asumsi fungsi baru ini tidak memiliki pengaruh pada bagian kode yang sebelumnya diterapkan, pengembangan akan linear sesuai dengan jumlah pekerjaan yang harus dilakukan. dilakukan. Kemungkinan besar, fungsionalitas baru sangat memengaruhi bagian yang diimplementasikan sebelumnya dan dengan demikian pengembangan tidak hanya melibatkan fungsionalitas baru tetapi memperbaiki kode lama, membuat waktu pengembangan eksponensial.

Saran saya kepada Anda adalah, tanpa memberi tahu programmer cara melakukan pekerjaan mereka, cobalah untuk memahami bagaimana program bekerja pada tingkat umum dan Anda akan segera dapat melihat bagaimana fungsionalitas baru akan mengubah perilaku itu dan dengan demikian memberikan perkiraan yang masuk akal tentang berapa lama waktu yang dibutuhkan untuk melakukannya. Gabungkan ini dengan perkiraan mereka (dua kali lipat tertinggi), dan Anda mulai mendapatkan ide yang lebih baik tentang cara memperkirakan waktu pengembangan.

Saya harap itu membantu!

Salah satu alasan estimasi seringkali jauh adalah karena estimasi sebenarnya cukup sulit dan membutuhkan pengalaman dan pengetahuan tentang sistem yang akan diubah. Paling sering membantu untuk memecah langkah besar menjadi yang lebih kecil.

Sekarang Anda memiliki banyak kemungkinan yang akan saya sebutkan dua:

• Perencanaan Poker
• PERT (Teknik Evaluasi dan Tinjauan Program)

Perencanaan Poker

Ini bekerja cukup baik di tim tangkas kecil.

Kutipan dari wikipedia:

• Seorang Moderator, yang tidak akan bermain, memimpin rapat.
• Manajer Produk memberikan gambaran singkat. Tim diberi kesempatan untuk bertanya dan berdiskusi untuk mengklarifikasi asumsi dan risiko. Ringkasan diskusi direkam oleh Manajer Proyek.
• Setiap individu meletakkan kartu menghadap ke bawah mewakili perkiraan mereka. Unit yang digunakan bervariasi - bisa dalam durasi hari, hari ideal atau poin cerita. Selama diskusi, angka tidak boleh disebutkan sama sekali dalam kaitannya dengan ukuran fitur untuk menghindari penahan.
• Semua orang memanggil kartu mereka secara bersamaan dengan membalikkannya.
• Orang-orang dengan perkiraan tinggi dan perkiraan rendah diberikan kotak sabun untuk memberikan justifikasi atas estimasi mereka dan kemudian diskusi berlanjut.
• Ulangi proses estimasi hingga konsensus tercapai. Pengembang yang kemungkinan besar memiliki barang kiriman memiliki sebagian besar "suara konsensus", meskipun Moderator dapat menegosiasikan konsensus.
• Pengatur waktu telur digunakan untuk memastikan bahwa diskusi terstruktur; Moderator atau Manajer Proyek dapat kapan saja membalik timer telur dan ketika habis semua diskusi harus dihentikan dan putaran poker lainnya dimainkan. Struktur dalam percakapan diperkenalkan kembali oleh kotak sabun.

Bagian penting di sini adalah klarifikasi, diskusi, serentak memanggil estimasi, sehingga tidak ada bias yang diperkenalkan, dan konsensus.

NAKAL

Seringkali sulit untuk memberikan satu perkiraan yang tepat. Yang lebih mudah adalah memberi kemungkinan. PERT menggunakan 3 nilai untuk estimasi:

• waktu paling optimis untuk menyelesaikan (jika masalah muncul lebih sedikit dari yang diharapkan)
• sebagian besar waktu pesimis untuk menyelesaikan (jika semuanya berjalan salah - tidak termasuk bencana besar)
• kemungkinan besar waktu untuk menyelesaikan (jika semuanya berjalan seperti yang diharapkan) <- inilah yang paling mungkin diperkirakan pengembang Anda saat ini

Dengan menimbang ketiga perkiraan tersebut, Anda mendapatkan perkiraan yang lebih andal.

t_expected = (t_opt + 4 * t_likely + t_pes) / 6

Dan / atau Anda dapat menggunakan ketiga nilai ini untuk membangun distribusi probabilitas yang mungkin lebih mencerminkan ketidakpastian dunia nyata. Distribusi beta dan distribusi segitiga adalah pilihan yang menonjol. Dengan menggunakan ini, Anda sekarang dapat menerapkan statistik seperti "seberapa besar kemungkinannya untuk selesai pada tanggal x dengan perkiraan saat ini" atau "jika saya ingin kepastian 95%, pada titik waktu itu akan selesai".

Sebenarnya PERT terdiri dari lebih dari aspek-aspek yang disebutkan di sini, yang saya hilangkan demi singkatnya.

Adalah fakta bahwa jika Anda tidak menyimpan metrik historis maka Anda bahkan tidak bisa mendekati memberikan perkiraan yang masuk akal dengan tingkat akurasi yang masuk akal. Dan bertanya pada perusahaan / orang lain berapa lama mereka tidak akan membantu. Masalahnya adalah bahwa setiap perusahaan dan pengembang memiliki cara mereka sendiri dalam melakukan sesuatu. Dengan demikian, setiap perusahaan akan memiliki jangka waktu yang berbeda untuk melakukan tugas yang sama persis. Setiap pengembang akan memiliki jangka waktu yang berbeda untuk melakukan tugas yang sama persis.

Tindakan terbaik Anda adalah mulai melacak waktu dan entah bagaimana mencari cara untuk mengelompokkan tingkat kesulitan untuk tugas tersebut. Beberapa perusahaan menggunakan baris kode, beberapa menggunakan fitur, beberapa hanya berjalan dengan perasaan. Selain itu, Anda juga harus mempertimbangkan apakah ini mirip dengan sesuatu yang sudah dibangun oleh pengembang atau sesuatu yang baru, seperti teknologi baru, fitur baru yang belum pernah dibuat sebelumnya oleh tim, dll. sistem waktu maka kompleksitas umumnya naik sedikit.

Kecuali jika Anda mengumpulkan data nyata, tidak peduli berapa kali pengembang Anda memberi Anda perkiraan, mereka benar-benar hanya akan menarik angka dari belakang mereka setiap kali Anda bertanya kepada mereka. Ya, mengumpulkan data nyata itu menyusahkan dan pada awalnya itu tidak memberikan banyak info berguna, tetapi seiring waktu itu benar-benar mulai memberikan perkiraan yang cukup akurat.

Saya juga ingin menunjukkan bahwa perkiraan umumnya hanya baik untuk gambaran besar dan bukan untuk pengukuran jangka pendek. Misalnya, pengembang memperkirakan 2 hari tetapi butuh 8. Yah pengembang tidak memperhitungkan harus menyiapkan lingkungan pengujian dan mengembangkan simulator atau bahwa ada teknologi yang sama sekali baru yang harus mereka pelajari atau mereka terjebak pada bug mereka tidak dapat mengetahui atau fungsionalitasnya memerlukan refactoring dari sistem yang ada. Anda tidak selalu dapat memprediksi hal-hal semacam itu untuk tugas-tugas kecil. Namun, selama keseluruhan proyek, 6 hari ekstra tersebut dapat terhapus oleh tugas-tugas lain yang memakan waktu kurang dari 6 hari.

Saya telah menjadi pengembang tunggal di beberapa proyek kecil saya sendiri dan memiliki beberapa pengalaman industri bekerja dengan tim besar. Saya perhatikan bahwa teknik yang digunakan perusahaan besar tidak selalu berhasil untuk tim kecil. Pada satu titik saya melakukan lebih banyak perencanaan dan dokumentasi daripada menulis kode. Saya menyarankan Anda mencoba mencari cara yang baik untuk bekerja terlebih dahulu dengan mencoba teknik yang berbeda (jawaban lain memberikan beberapa wawasan hebat) dan alat, ini akan menghabiskan waktu dan usaha tetapi Anda akan mendapat manfaatnya nanti. Beberapa alat / teknik yang menurut saya bermanfaat adalah:

-Pelacak Penting - Program hebat untuk melacak cerita dan mendorong mogok -tugas, sangat cepat dalam memasukkan cerita dan secara otomatis menyimpulkan kecepatan. https://www.pivotaltracker.com/ .

-Dokumen dokumentasi karena mudah untuk memiliki banyak pengguna yang mengedit dan berdiskusi pada saat yang sama.

-Pada sebuah perusahaan tempat saya bekerja dulu kami biasa mengadakan pertemuan untuk masing-masing dan setiap cerita yang kami mulai, pertemuan ini harus melibatkan seorang programmer senior karena dia akan lebih baik dalam menilai berapa lama suatu tugas akan berlangsung. Dia juga akan lebih baik dalam menilai apa bagian yang sulit dalam suatu tugas.

Singkatnya saya percaya bahwa kunci untuk bekerja dalam tim kecil adalah memiliki rezim perencanaan yang solid yang cepat dan lancar. Juga setiap kesulitan dengan cerita dapat diidentifikasi sejak dini sehingga perencanaan tugas akan mengingatnya (ini dapat menyebabkan membangun sesuatu yang berbeda).

Semoga ini membantu