"Perangkat lunak selesai ketika dilakukan, tidak lebih cepat, tidak lebih lambat."
Ini benar, tetapi untuk setiap tugas yang mulai dikerjakan oleh pengembang Anda, apakah semua orang di organisasi Anda memahami Definisi Selesai untuk setiap tugas?
Tampaknya salah satu masalah terbesar Anda adalah Estimasi , tetapi pengembang hanya dapat memberikan perkiraan realistis ketika mereka memiliki 'definisi selesai' yang jelas dan jelas. (Yang termasuk masalah proses perusahaan - misalnya dokumentasi pengguna, paket kerja pada rilis resmi, dll.)
Tidak mengherankan bahwa estimasi berlebihan menyebabkan masalah, mengingat sebagian besar pengembang melihat bahwa memperkirakan waktu yang dibutuhkan untuk menyelesaikan tugas adalah yang paling sulit yang harus mereka tanyakan.
Namun, sebagian besar pengembang cenderung memiliki pegangan yang masuk akal (meskipun optimis ) pada jumlah upaya yang dapat mereka lakukan, untuk jangka waktu tertentu.
Masalahnya sering adalah bahwa pengembang berjuang untuk menciptakan hubungan antara tugas dan jumlah jumlah usaha yang diperlukan ketika mereka sedang berhadapan dengan informasi yang tidak lengkap - terutama jika mereka ditekan untuk datang dengan semua jawaban up-depan untuk tugas benar-benar besar .
Ini secara alami menyebabkan perkiraan waktu menjadi terputus dari kenyataan, dan mereka kehilangan pandangan terhadap hal-hal seperti proses pembuatan dan dokumentasi pengguna.
Putus cenderung dimulai pada awal ketika tugas dijelaskan; dan biasanya diperparah oleh orang non-teknis yang menyusun daftar persyaratan tanpa mengetahui jumlah upaya yang diperlukan.
Terkadang orang-orang di manajemen senior menentukan tugas dan sepenuhnya mengabaikan masalah proses perusahaan; itu tidak biasa bagi manajemen senior untuk berpikir bahwa hal-hal seperti mendefinisikan tes, atau membuat versi resmi dirilis, atau memperbarui dokumen pengguna hanya terjadi secara ajaib tanpa waktu atau usaha. yg dibutuhkan.
Terkadang proyek gagal sebelum pengembang bahkan menulis sederet kode karena seseorang, di suatu tempat tidak melakukan pekerjaan mereka dengan benar.
Jika tim pengembangan tidak terlibat dalam menyetujui persyaratan atau menangkap kriteria penerimaan, maka itu merupakan kegagalan manajemen - karena itu berarti seseorang yang tidak memiliki pemahaman yang cukup tentang kode dan masalah teknis telah menjadikan bisnis untuk serangkaian persyaratan yang tidak lengkap, dan membiarkan proyek terbuka untuk salah tafsir, cakupan creep, pelapisan emas, dll.
Jika tim pengembangan terlibat dalam menangkap dan menyetujui persyaratan, maka itu bisa merupakan kegagalan tim, yang bertanggung jawab untuk mengklarifikasi detail (dan kriteria penerimaan - yaitu "Seperti apa tampilan yang dapat dikirim? Kapan itu dilakukan ?" ). Tim pengembang juga bertanggung jawab untuk mengatakan TIDAK ketika ada masalah pemblokiran lain di jalan, atau jika persyaratan hanya tidak realistis.
Jadi, jika pengembang terlibat dalam penangkapan persyaratan:
- Apakah tim memiliki kesempatan untuk duduk bersama manajer produk untuk mengklarifikasi persyaratan / definisi yang telah dilakukan?
- Apakah tim mengajukan pertanyaan yang cukup untuk mengklarifikasi persyaratan yang disiratkan / dianggap? Seberapa sering pertanyaan-pertanyaan itu dijawab dengan memuaskan?
- Apakah tim menuntut kriteria Penerimaan (definisi selesai) sebelum memberikan perkiraan?
- Seberapa baik kriteria Penerimaan biasanya ditangkap untuk setiap tugas? Apakah dokumen tersebut samar-samar dengan detail yang jarang atau apakah itu menggambarkan fungsionalitas yang nyata, dan mengatakan bahwa pengembang dapat secara jelas menerjemahkan ke dalam pengujian?
Kemungkinannya adalah bahwa produktivitas tim Anda tidak menjadi masalah; tim Anda mungkin melakukan semua upaya yang mereka dapat lakukan sehubungan dengan pengembangan. Masalah nyata Anda dapat berupa satu atau lebih hal berikut ini:
- Persyaratan tidak lengkap dan tidak jelas.
- Persyaratan / tugas yang terlalu besar di tempat pertama.
- Komunikasi yang buruk antara tim pengembangan dan manajemen tingkat atas.
- Kurangnya kriteria penerimaan yang jelas sebelum tugas diserahkan kepada tim.
- Spesifikasi tes penerimaan yang tidak lengkap atau tidak jelas / ambigu. (yaitu Definisi Selesai)
- Tidak cukup waktu yang dialokasikan untuk mendefinisikan / menyetujui kriteria penerimaan.
- Pengembang tidak mempertimbangkan waktu untuk menguji kode dasar yang ada atau memperbaiki bug yang ada
- Pengembang memang menguji kode dasar yang ada tetapi tidak meningkatkan bug sebagai Masalah Pemblokiran sebelum memberikan perkiraan pada persyaratan
- Manajemen melihat masalah / bug dan memutuskan bahwa bug tidak perlu diperbaiki sebelum menulis kode baru.
- Pengembang berada di bawah tekanan untuk memperhitungkan 100% dari waktu mereka, meskipun mungkin 20% (atau jumlah yang serupa) dari waktu mereka mungkin diambil oleh rapat, gangguan, email, dll.
- Perkiraan disetujui berdasarkan nilai nominal dan tidak ada yang menyesuaikan ruang untuk kesalahan atau kontingensi (mis. "Kami memutuskan ini akan memakan waktu 5 hari, jadi kami akan mengharapkannya selesai pada 8.").
- Perkiraan diperlakukan oleh semua orang (pengembang dan manajemen) sebagai angka tunggal alih-alih angka "rentang" yang realistis - yaitu
- Perkiraan kasus terbaik
- Estimasi realistis
- Estimasi kasus terburuk
... daftarnya bisa bertahan lebih lama dari itu.
Anda perlu melakukan beberapa "pencarian fakta" dan mencari tahu mengapa perkiraan tersebut secara konsisten terputus dari kenyataan. Apakah perangkat lunak dasar yang ada buruk? Apakah tidak memiliki cakupan unit test? Apakah pengembang Anda menghindari komunikasi dengan manajemen? Apakah manajemen menghindari komunikasi dengan pengembang? Apakah ada keterputusan antara ekspektasi manajemen dan ekspektasi pengembang dalam hal "Definisi Selesai" ?