Daftar Isi:
estimasi proyek perangkat lunak
Pixabay
pengantar
Estimasi itu sulit. Sayangnya, ini juga sangat diperlukan. Perusahaan menggunakan perkiraan untuk memproyeksikan jadwal rilis, membuat komitmen kepada pelanggan mereka, memutuskan apakah fitur yang diusulkan layak diterapkan, melacak kecepatan tim, dan memprioritaskan pekerjaan secara efektif. Para eksekutif sering kali ingin tahu kapan fitur atau kiriman akan siap untuk produksi. Bagaimanapun, pengembangan perangkat lunak bukanlah investasi yang sepele. Tanpa perkiraan, bagaimana manajer proyek membuat penilaian? Jika manusia dapat memprediksi masa depan secara akurat, orang tidak akan menang dalam pacuan kuda 2% dari waktu. Estimasi adalah teka-teki besar. Sangat penting dan perlu bagi perusahaan untuk meminta karyawan mereka melakukan hal yang tidak mungkin: memprediksi masa depan.
Pertama, mari kita tinjau beberapa metode estimasi populer (jika Anda melewatkan beberapa keseruan). Kemudian kita dapat melihat apa artinya ini bagi kita dan proyek kita.
Model Peramal
Model ini hampir tidak memerlukan usaha untuk menghasilkan perkiraan. Estimator berpikir sejenak tentang apa yang perlu dilakukan untuk mengimplementasikan dan menguji fitur, lalu mereka mengeluarkan angka. Kedengarannya sangat mirip dengan "… (jeda panjang)… Ummmmm… 6 minggu." Kemudian semua orang mengangguk dan kami melanjutkan. Mereka dapat menghabiskan cukup banyak waktu di bagian depan untuk membicarakan apa yang mereka ketahui tentang persyaratan (yang mungkin bukan gambaran lengkapnya). Analisis yang cermat ini membuat perkiraan mereka terasa lebih andal. Di akhir proyek, selalu ada alasan yang diterima mengapa perkiraan tersebut sangat jauh dari kenyataan. Selalu ada keadaan tak terduga yang bisa menjadi kambing hitam. Seringkali tidak terpikir oleh siapa pun bahwa modelnya sangat cacat.
Jadi bagaimana kita bisa membuat proses ini lebih baik? Aku tahu! Kita bisa menggunakan Teknik Dekomposisi (yaitu membagi dan menaklukkan). Pendekatan ini mengasumsikan bahwa Anda mengetahui cakupan lengkap fitur atau proyek di front end. Setiap fitur dipecah menjadi potongan seukuran gigitan. Setiap potongan diperkirakan (gaya peramal), lalu kami menambahkannya untuk mendapatkan perkiraan fitur / proyek secara keseluruhan. Ini tentunya pendekatan yang lebih rumit, tetapi tampaknya lebih baik karena dua alasan:
- Potongan pekerjaan yang lebih kecil cenderung lebih mudah diperkirakan dengan andal.
- Meskipun masih ada peluang untuk kesalahan (+/- sejumlah tertentu), ada asumsi bahwa kesalahan akan membatalkan satu sama lain ketika Anda menambahkan semuanya dan Anda akan mendapatkan perkiraan keseluruhan yang lebih dapat diandalkan.
Kelemahan mendasar dari pendekatan ini adalah kontributor individu (orang yang benar-benar melakukan pekerjaan) secara universal meremehkan. Mereka masih jauh lebih baik daripada yang di atas dan di sekitar mereka, tetapi itu bukan standar yang tinggi. Tampaknya tidak demikian karena kita semua pernah melihat kasus di mana pengembang mengejutkan diri sendiri dengan menyelesaikan sesuatu lebih cepat dari jadwal. Tapi ini adalah titik data tunggal, bukan tren. Orang terkadang benar-benar menang di kasino; menghabiskan uang di kasino setiap hari selama setahun dan Anda akan memiliki lebih sedikit uang daripada yang Anda mulai. Jika Anda melacak perkiraan vs. aktual selama satu atau dua tahun, Anda akan menemukan bahwa perkiraan tersebut tidak sesuai dengan kenyataan. Sementara banyak pebisnis benar-benar yakin bahwa pengembang dengan malas membuat perkiraan mereka dan menggunakan waktu ekstra untuk "lempeng emas" atau memeriksa saham mereka,data menunjukkan sebaliknya. Strategi "membatalkan" tidak berhasil.
Jadi, sekarang bagaimana? Mari kita tinggalkan model peramal dan beralih ke pendekatan berbasis ukuran. Ternyata, meskipun manusia sangat buruk dalam memperkirakan waktu penyelesaian, sebenarnya kita cukup pandai dalam mengatakan seberapa besar sesuatu itu. Kami sangat ahli dalam ukuran komparatif ("lebih besar dari itu, tapi lebih kecil dari itu di sana"). Jika kita berpikir dalam ukuran atau kompleksitas daripada waktu, otak kita memprosesnya dengan lebih andal. Kemudian kita dapat mengambil nilai ukuran dan menghitung jumlah jam sebenarnya untuk proyek tersebut berdasarkan rumus ajaib yang bagus! Dan saat itulah model titik fungsi populer memasuki layar (kiri panggung).
Function Points Analysis (FPA)
Untuk analisis titik fungsi, kita perlu mengidentifikasi lima jenis hal dalam aplikasi kita: masukan eksternal, keluaran eksternal, kueri eksternal, file antarmuka eksternal, dan file logis internal (jangan terlalu khawatir tentang definisi; Anda dapat menelitinya nanti). Setiap contoh dari mereka (fungsi) memiliki kompleksitas yang terkait dengannya (rendah, rata-rata, atau tinggi). Kami menggunakan tabel di bawah ini untuk mencari tahu berapa banyak poin yang diberikan setiap fungsi.
Sekarang jika kita menjumlahkan poin untuk semua fungsi kita, kita mungkin mendapatkan angka seperti 457 poin fungsi untuk proyek kita. Lalu kami hanya perlu rumus untuk mengetahui jumlah jam… Berdasarkan proyek terakhir kami, “tingkat pengiriman” kami adalah 15 poin fungsi per orang per bulan. Itu kira-kira senilai 30 orang bulan kerja, yang seharusnya memakan waktu lebih dari dua setengah bulan untuk tim saya 12 orang. Ta-da!
Ini tentu lebih kompleks dari model kami sebelumnya. Faktanya, ada empat area utama kompleksitas yang harus dikenali.
- Kelima jenis komponen belum tentu intuitif, dan mudah lupa untuk memasukkan sesuatu ke dalam daftar atau menugaskannya ke keranjang yang salah.
- Tabel yang digunakan untuk benar-benar menghasilkan poin fungsi berisi angka ajaib yang membutuhkan banyak usaha untuk memvalidasi. Apakah angka-angka ini dikalibrasi dengan benar untuk menghasilkan perkiraan yang dapat diandalkan untuk tim saya?
- Tingkat pengiriman (bagian penting dari teka-teki) dihitung berdasarkan produktivitas tim Anda. Seberapa sering kita perlu menghitung angka baru? Sebenarnya hanya ada sedikit panduan tentang ini.
- Apa yang termasuk kompleksitas rendah, sedang, atau tinggi? Bagaimana kita mendefinisikannya sehingga semua orang memahaminya? Bukankah mendapatkan hak itu penting untuk keakuratan perhitungan kita?
Ada beberapa bagian yang bergerak dalam contoh yang sangat sederhana ini, dan kami bahkan belum membahas model kompleksitas yang lebih rumit dan data lain yang dapat ikut berperan (misalnya tingkat biaya, tingkat dukungan, kepadatan cacat, dll.). Lebih banyak bagian yang bergerak berarti lebih banyak peluang terjadinya kesalahan. Apakah kita membuat estimasi terlalu rumit sekarang? Kami tidak membayar pengembang untuk mencurahkan banyak waktu untuk estimasi. Saya tidak bisa menjual perkiraan kepada pelanggan saya. Saya membutuhkan perangkat lunak yang berfungsi. Apakah ada hal lain di luar sana?
Going Agile
Sekarang mari kita lihat secara singkat agile scrum (cukup untuk melakukan perbandingan). Seperti yang dinyatakan sebelumnya, manusia sangat buruk dalam memperkirakan waktu, dan cukup baik dalam menentukan ukuran komparatif. Berikut beberapa istilah yang perlu dipahami:
- Sprint - periode waktu tertentu (biasanya dua minggu).
- Kisah pengguna - sebuah karya tersendiri, sebaiknya cukup kecil untuk dikerjakan oleh satu orang dalam satu sprint. Ini adalah hal yang kami perkirakan.
Strategi yang paling populer adalah menggunakan urutan fibonacci (0, 1, 2, 3, 5, 8, 13) untuk perkiraan. Ini tidak linier - saat Anda naik skala, ukuran celah meningkat. Kuncinya adalah bahwa celah tersebut harus cukup lebar sehingga tidak ada alasan untuk memperdebatkan perbedaan yang tidak signifikan. Setelah Anda mendapatkan di atas 3, perbedaan antara 4 dan 5 atau 7 dan 8 sangat kecil sehingga tidak ada gunanya menghabiskan waktu memikirkan yang mana. Urutan basis-2 juga akan berfungsi (0, 1, 2, 4, 8, 16, dll.).
“Tapi tunggu, ini hanya angka. Apa artinya? Berapa jam satu poin? ” Poin tidak dimaksudkan untuk berkorelasi langsung dengan jam, karena jika mereka melakukannya tim akan tergoda untuk kembali memperkirakan dalam jam dan kemudian mengubahnya menjadi poin. Seperti yang dibahas sebelumnya, keakuratan perkiraan kami berasal dari ukuran komparatif dan tidak memperkirakan jumlah jam yang dibutuhkan sesuatu. Jika Anda memberi tim kemampuan untuk berpikir dalam hitungan jam, Anda membahayakan kemampuan Anda untuk memperkirakan secara akurat.
Misalkan Anda memulai dengan latihan kalibrasi. Tarik tim Anda ke sebuah ruangan dan pandu mereka melalui daftar 10-12 cerita pengguna. Pilih satu yang kecil tapi bukan yang terkecil dan lakukan yang itu dulu. Tinjau dan umumkan bahwa cerita ini adalah "3". Anda tidak bertanya. Anda memberitahu. Lalu lanjutkan ke cerita berikutnya. “Jika itu 3, apa yang ini?” Sekarang, tim mengukur cerita dibandingkan dengan cerita lain. Akhirnya, mereka akan memiliki gagasan yang cukup bagus apa yang merupakan "1", "2", dll. Mereka tidak memperkirakan. Waktu tidak penting. Mereka mengukur cerita, relatif terhadap cerita lain yang sudah memiliki angka. Anda kemudian dapat meletakkan contoh cerita untuk setiap nomor dalam urutan dalam dokumen yang disebut penggaris. Mereka dapat menggunakannya sebagai referensi jika mereka tidak yakin apa itu "5".
Sekarang inilah kuncinya. Saus ajaib yang membuat ini berhasil adalah "kecepatan" (jumlah poin yang bisa diselesaikan tim dalam satu sprint rata-rata di 3-4 sprint). Misalkan sprint Anda adalah dua minggu dan tim Anda yang terdiri dari 8 orang memiliki kecepatan rata-rata 35 poin. Anda mendapatkan 35 poin dalam 640 jam kerja (8 x 80 jam). Jika kami mengetahui bahwa sebuah fitur akan membutuhkan sekitar 100 poin pekerjaan mulai diselesaikan, maka saya tahu itu sekitar 6 minggu kerja dan ~ 1900 jam. Tim menjadi sangat pandai dalam mengukur cerita secara konsisten, dan Anda memanfaatkannya untuk melakukan perencanaan proyek Anda. Perhitungan ini berhasil karena durasinya konsisten dari sprint ke sprint.
Untuk melakukan perencanaan tingkat tinggi jangka panjang, Anda dapat meminta prospek Anda untuk memecah fitur tingkat tinggi menjadi cerita satu baris sementara dan memberi nilai poin pada mereka. Akan ada tingkat akurasi yang hilang, tetapi Anda memanfaatkan model yang sudah mereka pahami. Jalur yang lebih akurat adalah ukuran relatif pada tingkat fitur. "Fitur ini lebih besar dari fitur 40 poin itu, lebih kecil dari fitur 120 poin di sana, dan sedikit lebih besar dari fitur 65 poin yang baru saja kami buat." Cerita dikelompokkan menjadi "epik". Jika setiap fitur adalah epik, pada akhirnya Anda akan tahu berapa banyak poin yang diperlukan untuk menyelesaikan fitur itu. Simpan riwayat itu dan Anda dapat menggunakannya untuk perencanaan rilis Anda.
Kesimpulan
Ada banyak metodologi yang digunakan saat ini. Masing-masing memiliki pro dan kontra. Entah bagaimana kita perlu mencari cara bagaimana memaksimalkan keakuratan perkiraan kita sehingga kita dapat membuat keputusan yang baik. Itu tidak berarti perkiraan kami harus akurat. Mereka hanya perlu cukup akurat sehingga berguna. Jika Anda tidak memahami estimasi, Anda mungkin berasumsi bahwa estimasi tersebut tidak akurat karena tim tidak melakukan pekerjaan dengan baik. Mereka tidak memperkirakan dengan benar, atau mereka tidak menjalankan proyek dengan benar. Pemukulan akan berlanjut sampai perkiraan membaik. Tetapi perkiraan tidak boleh digunakan sebagai komitmen. Ini adalah tebakan terbaik berdasarkan informasi terbatas yang kita miliki saat ini. Ketika informasi baru muncul, kami harus mengizinkan perkiraan untuk ditinjau kembali. Ada lagi yang mengharapkan hal yang tidak mungkin, yang merupakan masalah dengan kepemimpinan (bukan dengan tim).
Pendekatan Scrum jauh lebih sederhana daripada yang kita lihat dalam analisis titik fungsi. Dan saya akan mengatakan itu jauh lebih dapat dipercaya daripada tabel ajaib dengan angka ajaib. Ini mendapatkan hasil maksimal (upaya minimal dengan tingkat akurasi yang cukup tinggi). Dari perspektif upaya, ini tidak menciptakan proses yang berat untuk dipahami dan digunakan oleh tim. Potongan estimasi agile sebenarnya dapat terjadi dengan sangat cepat setelah semua orang memahami detail pekerjaan yang sedang diperkirakan. Ini tentu lebih baik daripada menarik angka begitu saja. Kecepatan leverage melakukan sesuatu yang sangat penting: membawa data historis ke dalam kalkulasi. Setiap sprint, Anda menghitung ulang kecepatan Anda. Ini penting, karena throughput waktu berubah. Tim yang menggunakan FPA mungkin mendapatkan tingkat pengiriman mereka dari proyek sebelumnya,yang dalam beberapa kasus terjadi beberapa bulan lalu. Banyak hal mungkin telah berubah sejak saat itu. Saran saya bagi Anda untuk menjelajahi Agile dan benar-benar berusaha memahami poin dan kecepatan cerita. Jangan kembali memperkirakan dalam hitungan jam hanya karena itulah yang Anda pahami. Saya yakin Anda akan berterima kasih pada diri sendiri nanti.