Poin Cerita Agile vs Jam: Cara Memperkirakan Pengembangan Perangkat Lunak dengan Lebih Baik

Membungkus pikiran Anda di sekitar proses pengembangan perangkat lunak bisa jadi sulit. Ketika Anda menemukan ide dan mendekati pengembang dengannya, dua hal pertama yang Anda tanyakan adalah berapa biaya untuk mengimplementasikannya dan berapa lama waktu yang dibutuhkan untuk membangun . Estimasi adalah salah satu langkah pertama dalam pengembangan aplikasi.

Pada artikel ini, kami membandingkan dua model estimasi paling populer dalam pengembangan perangkat lunak modern: Poin cerita tangkas vs jam .

Baca terus untuk mempelajari cara memperkirakan waktu di Agile, dapatkan inti dari kedua model estimasi, pahami perbedaannya, dan lihat mengapa pengembang mungkin memilih satu dari yang lain.

Jam cukup mudah dipahami, dan telah menjadi model estimasi utama dalam pengembangan perangkat lunak untuk waktu yang lama. Jam, juga dikenal sebagai jam kerja atau jam pekerja, adalah jumlah jam yang dihabiskan pengembang untuk proyek tersebut.

Jadi apa itu poin cerita dan mengapa poin itu muncul jika kita sudah memiliki model estimasi yang sederhana dan lugas?

Isi:

1. Apa sebenarnya poin cerita itu?
2. Begini cara poin cerita dihitung di Agile
3. Keuntungan memperkirakan dalam poin cerita
4. Kekurangan memperkirakan dalam poin cerita
5. Keuntungan memperkirakan dalam jam
6. Kerugian memperkirakan dalam jam
7. Bisakah Anda mengubah poin cerita menjadi jam?
8. Poin cerita vs jam: Apa yang harus dipilih untuk pengembangan perangkat lunak?

Apa sebenarnya poin cerita itu?

Poin cerita adalah model estimasi relatif asli dari Agile dan Scrum. Mereka memperkirakan upaya untuk membangun produk dengan menangani tiga aspek pengembangan:

• jumlah pekerjaan yang dibutuhkan produk

• kompleksitas fitur produk

• risiko dan ketidakpastian yang mungkin mempengaruhi pembangunan

Pada awal evaluasi proyek, pengembang memilih kisah pengguna terkecil dan paling sederhana yang dimiliki suatu produk — misalnya, kisah pengguna pendaftaran — dan menetapkannya sebagai kisah pengguna 1 poin. Itulah cerita dasar : cerita pengguna yang akan digunakan untuk perbandingan kompleksitas. Semua cerita pengguna lainnya akan diberikan sejumlah poin cerita berdasarkan seberapa kompleks mereka untuk dikembangkan dibandingkan dengan cerita dasar.

Terlihat cukup sederhana di permukaan, tetapi siapa yang menentukan jumlah poin cerita di setiap cerita?

Begini cara poin cerita dihitung di Agile

Seperti halnya jam, orang yang akan mengerjakan produk biasanya memperkirakan poin cerita untuk pengembangan. Namun, proses estimasinya sedikit berbeda dengan poin cerita.

Untuk menetapkan poin cerita ke cerita pengguna, beberapa pengembang terlibat. Setidaknya harus ada dua, tetapi perusahaan dapat meminta semua pengembang mereka untuk berkontribusi dengan memainkan apa yang disebut industri sebagai Planning Poker . Berikut aturan mainnya:

1. Setiap pengembang mendapat satu set kartu Perencanaan Poker.

2. Pengembang memilih cerita pengguna dan mendiskusikan kompleksitasnya dan upaya pengembangan yang diperlukan.

3. Setiap pengembang mengajukan kartu yang sesuai dengan jumlah poin yang mereka berikan untuk cerita.

4. Jika perkiraan titik cerita sama, perkiraan jumlah titik ditetapkan ke cerita.

5. Jika poin cerita yang disarankan berbeda, pengembang mendiskusikan cerita pengguna sampai mereka menemukan sejumlah poin yang disetujui oleh mayoritas.

6. Pengembang memilih cerita pengguna berikutnya.

7. Ulangi langkah 3 sampai 5.

Ketika semua aktivitas kami menjadi jauh, proses ini telah dimodifikasi. Alih-alih kartu dan rapat, poin cerita diputuskan dalam diskusi online, selama rapat Zoom, atau di messenger.

Ini terlihat seperti ini:

Ini tidak berarti semua pengembang yang terlibat dalam memperkirakan poin cerita akan bekerja pada proyek, tentu saja. Tetapi keuntungan utama dari sistem poin cerita adalah bahwa ia menciptakan kerangka kerja yang kurang lebih universal yang dapat digunakan tidak hanya pada proyek yang bersangkutan tetapi juga pada proyek-proyek masa depan dengan fitur serupa.

Ada dua opsi yang sering digunakan untuk memperkirakan poin cerita. Anda dapat menetapkan poin:

• menggunakan bilangan bulat apa saja (1, 2, 3… 13,14,15, dst.)

• menggunakan angka dalam deret Fibonacci (1, 2, 3, 5, 8, 13… 55, 89, 144, dll.)

Deret Fibonacci adalah pilihan yang lebih nyaman untuk memperkirakan perkembangan karena menyisakan beberapa margin untuk aproksimasi. Model urutan numerik agak terlalu tepat untuk perbandingan yang nyaman.

Selama pengembangan dan di antara proyek, jika cerita pengguna menjadi lebih atau kurang kompleks dari perkiraan semula, poin cerita yang ditetapkan mungkin berubah.

Keuntungan memperkirakan dalam poin cerita

Jika proses pemberian poin cerita terlihat agak rumit, jangan biarkan hal itu membuat Anda bingung. Ada keuntungan untuk perencanaan kapasitas dengan poin cerita.

1. Poin cerita tidak bergantung pada pengembang

Poin cerita untuk setiap cerita ditetapkan oleh beberapa pengembang dalam negosiasi , dan alasannya adalah karena nomor tersebut ditetapkan tidak hanya untuk satu produk tertentu dan satu pengembang tertentu tetapi "rata-rata". Mengapa ini hal yang baik?

Sesuatu terjadi. Terkadang, pengembang proyek Anda mungkin meninggalkan proyek Anda dan digantikan. Mungkin mereka akan jatuh sakit, memutuskan untuk mengambil cuti orang tua atau cuti panjang, atau hanya meninggalkan perusahaan. Mungkin mereka akan menjadi underqualified atau overqualified untuk proyek tersebut.

Saat diganti, pengembang baru mungkin memiliki kecepatan kerja yang berbeda , yang akan menyebabkan estimasi ulang jam kerja yang diperlukan untuk membuat produk.

Poin cerita meminimalkan masalah ini . Ditugaskan oleh beberapa pengembang yang berbeda, mereka memberikan pandangan umum tentang betapa kompleksnya cerita pengguna tertentu. Poin cerita berfungsi untuk semua dan semua pengembang di perusahaan tertentu. (Meskipun harap diingat bahwa perkiraan titik cerita tidak akan benar untuk perusahaan yang berbeda.)

2. Poin cerita memudahkan untuk menghitung ulang waktu pengembangan

Dalam estimasi waktu Agile dengan poin cerita, tim menggunakan istilah kecepatan untuk merujuk pada jumlah poin cerita yang dirilis dalam satu sprint.

Tim terus memantau kecepatan mereka, dan itu cukup bervariasi di awal. Sebuah tim dapat merilis fitur senilai lima poin cerita satu minggu dan dua puluh poin cerita berikutnya. Tapi itu hanya di awal. Seiring berjalannya proyek, grafik kecepatan akan merata .

Dengan jam, jika anggota tim berubah, setiap tugas yang mereka lakukan perlu diperkirakan ulang untuk menyesuaikan tenggat waktu. Dengan poin cerita, ini tidak perlu — tim dapat menyesuaikan tenggat waktu proyek setelah sprint berikutnya dengan mengetahui perubahan kecepatan keseluruhan.

Poin cerita mengevaluasi kinerja tim secara keseluruhan , menghilangkan kebutuhan untuk estimasi ulang berdasarkan tugas.

3. Poin cerita bagus untuk memantau kinerja tim

Saat Anda memiliki tim yang mengerjakan proyek dan/atau tugas serupa pada waktu yang berbeda, kecepatan dapat dengan mudah menunjukkan kemajuan yang telah dibuat setiap tim. Apakah mereka membaik dan seberapa banyak? Tim atau pengembang mana yang kesulitan dan mungkin membutuhkan pelatihan ekstra? Apa kurva belajarnya? Mungkin tim yang berbeda berkinerja lebih baik?

Velocity adalah alat yang hebat untuk mengevaluasi kinerja tim Anda tidak hanya di tempat tetapi terus menerus.

4. Perkiraan waktu peluncuran dengan poin cerita lebih tepat

Dengan melacak kecepatan, tim mengetahui dengan presisi tinggi berapa banyak poin cerita yang dapat mereka lepaskan dalam satu sprint. Meskipun butuh beberapa waktu bagi tim pengembangan aplikasi untuk menghitung kecepatannya, setelah dihitung, perkiraan tanggal peluncuran mudah diprediksi .

Selain itu, perubahan anggota tim, persyaratan, atau jumlah/kompleksitas fitur tidak menyebabkan banyak kesulitan dengan estimasi ulang.

5. Anda dapat menggunakan kembali poin cerita untuk proyek mendatang untuk mempercepat estimasi

Bukan hal yang aneh bagi perusahaan untuk berpengalaman dalam ceruk tertentu (atau beberapa) dan membangun lebih dari satu produk dengan serangkaian fitur yang serupa. Setelah menyelesaikan bahkan satu proyek yang diperkirakan dalam poin cerita, pengembang dapat merujuk pada perkiraan ini untuk proyek baru . Ini akan mempersingkat waktu untuk estimasi.

Namun, penting untuk terus melacak kecepatan untuk setiap proyek karena keadaan dapat berubah.

6. Poin cerita meningkatkan kerja tim

Secara tradisional, perusahaan pengembang memiliki beberapa tim pengembang, masing-masing mengerjakan proyek terpisah. Saat memperkirakan dalam hitungan jam, pengembang yang mengerjakan proyeklah yang membuat perkiraan. Ini adalah hal yang baik, secara umum, karena siapa yang tahu lebih baik berapa lama sesuatu akan memakan waktu daripada orang yang melakukannya?

Namun, memperkirakan kompleksitas dalam poin cerita menawarkan kesempatan bagi pengembang di bidang yang sama untuk bekerja sama — sesuatu yang jarang terjadi sebaliknya. Kerja sama tim semacam ini menjadi peluang besar untuk berbagi pengalaman dan memotivasi satu sama lain.

Kekurangan memperkirakan dalam poin cerita

Selalu ada sisi lain dari argumen tersebut, yaitu bagaimana sistem yang hebat dilahirkan. Estimasi berbasis kompleksitas juga memiliki kekurangan , dan setiap tim harus memutuskan sendiri apakah mereka melebihi keuntungan.

1. Poin cerita harus diberikan oleh lebih dari satu pengembang

Nilai jual dari model poin cerita adalah objektifitas dan nilainya untuk perkiraan masa depan. Namun agar benar, estimasi harus dilakukan oleh lebih dari satu developer . Untuk perusahaan kecil dengan satu tim atau perusahaan di mana hanya ada satu spesialis di suatu bidang (yaitu hanya satu desainer atau pengembang iOS), poin cerita tidak membawa banyak keuntungan. Perusahaan kecil seperti itu secara tradisional memilih jam kerja sebagai model estimasi.

2. Estimasi dalam poin cerita membutuhkan backlog yang cukup besar

Untuk mewujudkan potensi penuh poin cerita, tim Anda perlu menghabiskan banyak waktu . Jika Anda mengerjakan proyek dengan fitur yang belum pernah dikerjakan tim sebelumnya (atau belum pernah bekerja penuh waktu), dua hingga tiga sprint pertama akan sulit diprediksi dari segi kinerja. Memang, semakin banyak item simpanan yang dimiliki tim Anda, semakin tepat perkiraan mereka karena banyaknya data statistik. Tapi poin cerita bukanlah sistem yang siap untuk digunakan segera.

3. Poin cerita lebih kompleks untuk penganggaran

Poin cerita sangat bagus untuk menetapkan tenggat waktu dan tanggal peluncuran yang tepat, yang mungkin penting bagi pengembang dan pemasaran klien. Namun, dalam hal memperkirakan biaya pengembangan aplikasi, mereka kurang nyaman .

Masalahnya, pengembang menghabiskan waktu pada sebuah proyek tidak hanya untuk menulis kode (atau membuat desain, atau menguji). Beberapa waktu dihabiskan untuk penelitian, diskusi — di dalam tim dan dengan klien — membuat perubahan, dll. Waktu yang dihabiskan untuk memperkirakan poin cerita juga menghabiskan waktu untuk proyek, tetapi tidak termasuk dalam poin per cerita.

Penganggaran saat memperkirakan dalam poin cerita dimungkinkan, tetapi biasanya lebih cepat dan lebih mudah untuk menyamakan uang dengan waktu yang dihabiskan untuk proyek tersebut.

4. Kecepatan dihitung per tim

Artinya, jika tim mencampuradukkan proyek, Anda harus menghitung kecepatan untuk setiap kombinasi pengembang secara terpisah. Oleh karena itu, perkiraan untuk satu tim belum tentu benar untuk tim yang berbeda, dan bahkan mengubah satu anggota tim dapat berpotensi membatalkan perkiraan sebelumnya.

Di sisi lain, Anda dapat menggunakan estimasi kompleksitas untuk menemukan kombinasi berkinerja terbaik. Ini akan memakan waktu.

Keuntungan memperkirakan dalam jam

Sementara beberapa tim Agile menggunakan poin cerita, banyak yang belum beralih dari jam kerja. Ada alasan penting untuk itu. Mari kita menutupi mereka juga.

1. Jam adalah model yang familiar

Inovasi itu hebat, tapi butuh waktu. Pengembang dan klien mereka sama-sama berpengalaman dalam estimasi jam kerja. Bagi banyak orang, idenya adalah "jika tidak rusak, jangan perbaiki". Selama sistem menawarkan perkiraan yang bisa diterapkan, mengapa beralih ke yang lain?

Perbedaan ketepatan perkiraan mungkin tidak cukup besar bagi beberapa pengembang untuk mengubah cara mereka melakukan sesuatu.

2. Klien biasanya membayar berjam-jam

Ini membutuhkan sedikit elaborasi. Untuk klien, estimasi berbasis kompleksitas mungkin membingungkan . Selain itu, jika untuk klien anggaran lebih penting daripada tanggal peluncuran (yang sering terjadi), poin cerita tidak akan relevan bagi mereka.

3. Estimasi berbasis jam dapat dilakukan oleh satu pengembang

Untuk tim kecil atau pekerja lepas, poin cerita sebagian besar tidak berguna, karena membutuhkan banyak sudut pandang. Tanpa referensi apa pun, memperkirakan poin cerita adalah kerumitan yang tidak perlu.

Jam, di sisi lain, menawarkan pengembang yang mengerjakan proyek cara untuk membuat perkiraan yang cukup tepat sendiri .

Hal yang sama berlaku untuk kecepatan tim. Ketika tim berubah setiap saat, seperti yang terjadi pada pekerja lepas atau outsourcing sebagian, kecepatan pemantauan menjadi sangat tidak masuk akal. Estimasi berbasis jam adalah pilihan yang lebih baik di sini.

Kerugian memperkirakan dalam jam

Berikut adalah alasan mengapa tim mungkin memutuskan untuk berhenti menggunakan jam sebagai model estimasi.

1. Menjadi satu-satunya yang bertanggung jawab atas estimasi adalah banyak tekanan

Di satu sisi, memperkirakan kebutuhan waktu Anda sendiri bisa lebih mudah, karena Anda hanya mengandalkan diri sendiri.

Di sisi lain, jika Anda gagal memenuhi perkiraan Anda, itu adalah pukulan besar. Terlebih lagi jika tim yang menunggu untuk memulai tugas mereka bergantung pada Anda menyelesaikan tugas Anda.

Selain itu, stres yang disebabkan oleh tekanan untuk memberikan apa yang Anda janjikan sendiri dapat mengganggu tugas yang berjalan dengan baik.

2. Perkiraan satu pengembang selalu kurang tepat daripada perkiraan tim

Estimasi individu bersifat subjektif dan terkait dengan keadaan emosional dan psikologis estimator.

Beberapa pengembang cenderung melebih-lebihkan diri mereka sendiri dan menetapkan kerangka waktu yang kemudian mereka perjuangkan untuk ditegakkan. Ini tidak hanya mengganggu pengembangan (dan membebani tim jika ada denda) tetapi juga menyebabkan stres dan kelelahan pada pengembang .

Yang lain meremehkan keterampilan mereka sendiri , memperpanjang pengembangan lebih dari yang dibutuhkan secara objektif. Ketidakamanan dan kebiasaan untuk terlalu memikirkan, memeriksa, dan memeriksa ulang pekerjaan sering kali menyebabkan tenggat waktu pengembangan ditetapkan ke tanggal berikutnya — dan tugas jarang diselesaikan sebelum tenggat waktu . Masukan tim memungkinkan estimasi yang lebih objektif.

3. Semakin besar tugas, semakin sulit untuk memperkirakan dalam jam

Ini berkorelasi dengan situasi non-pembangunan juga. Sangat mudah untuk mengatakan berapa banyak waktu yang dibutuhkan untuk membaca buklet universitas tiga halaman tetapi lebih sulit untuk memperkirakan berapa lama waktu yang dibutuhkan untuk menyelesaikan War and Peace .

Hal yang sama berlaku untuk pembangunan. Tugas kecil mudah diperkirakan untuk pengembang dengan beberapa pengalaman. Namun, semakin besar tugasnya, semakin banyak hal — yang terjadi baik di dalam maupun di luar proyek — dapat memengaruhi pengembangan. Estimasi berbasis jam tidak menawarkan margin yang dimiliki poin cerita, membuat estimasi menjadi lebih kasar.

4. Sedikit fleksibilitas

Estimasi berbasis jam adalah berbasis pengembang. Jika salah satu anggota tim yang mengerjakan produk berubah di tengah proyek, tim perlu menghitung ulang setiap cerita pengguna yang terpengaruh yang masih dalam pengembangan atau dijadwalkan untuk sprint mendatang. Itu bisa menjadi banyak pekerjaan, tergantung pada tahap proyek dan perbedaan keterampilan antara pengembang asli dan baru. Estimasi waktu berbasis jam cukup kaku.

Bisakah Anda mengubah poin cerita menjadi jam?

Klien dapat meminta tim yang membuat perkiraan dalam poin cerita untuk mengubah pemetaan poin cerita Agile menjadi jam . Kebanyakan orang yang tidak terbiasa dengan tren pengembangan perangkat lunak terbaru tidak akan tahu apa yang membuat poin cerita.

Namun, ketika seorang klien bertanya berapa jam satu poin cerita sama, tidak mungkin untuk menjawab dengan pasti. Salah satu komponen kunci dari estimasi berbasis kompleksitas adalah upaya yang dihabiskan untuk menyelesaikan cerita. Tetapi usaha tidak secara langsung diterjemahkan menjadi waktu yang dihabiskan . Jam mengatasi ketidakpastian dengan cara yang lebih kabur daripada poin cerita.

Semakin kompleks tugas, semakin banyak ketidakpastian dan risiko yang ada. Mengonversi poin cerita menjadi jam dengan cara yang mudah dan hanya mengandalkan kecepatan tidak memperhitungkan banyak risiko seperti itu, karena estimasi berbasis jam lebih merupakan perkiraan daripada poin cerita dalam hal risiko dan ketidakpastian.

Sampai tingkat tertentu, menggunakan deret Fibonacci dalam menetapkan poin cerita akan menjelaskan ketidakpastian dalam waktu pengembangan, tetapi itu tidak memungkinkan untuk konversi langsung.

Berikut adalah contoh.

Sebuah cerita poin 1-cerita (cerita dasar) membutuhkan, katakanlah, dua jam untuk menyelesaikannya.

Sebuah cerita berlantai 13 mungkin memakan waktu 26 jam dalam skenario kasus terbaik — jika tidak ada yang salah atau menghalangi. Misalnya, jika API yang digunakan cocok dengan mulus, titik akhir ke titik akhir. Tetapi jika tidak, ceritanya mungkin memerlukan waktu antara, katakanlah, 30 dan 50 jam — tergantung pada berapa banyak ketidakcocokan yang ada. Tidak ada yang bisa mengatakan sebelumnya bagaimana jadinya jika pengembang belum bekerja dengan API yang dimaksud.

Jadi dalam menerjemahkan poin cerita ke jam, perlu ada pengganda untuk pertumbuhan eksponensial untuk mengatasi ketidakpastian. Dan pengganda itu akan berbeda dari satu tim ke tim lainnya.

Poin cerita vs jam: Apa yang harus dipilih untuk pengembangan perangkat lunak?

Seperti yang Anda lihat, poin cerita dan jam adalah pilihan yang valid bagi pengembang untuk memperkirakan proyek.

Secara keseluruhan, kami akan mengatakan lebih banyak perusahaan produk memilih poin cerita sementara agen outsourcing cenderung bersandar pada jam.

Perusahaan yang bekerja dengan model harga tetap biasanya menggunakan estimasi berbasis jam. Tim yang lebih menyukai Scrum sering memilih poin cerita, karena mereka benar-benar lahir dari Scrum dan asli dari metodologi ini.
Dalam pengalaman kami selama bertahun-tahun, kami melihatnya seperti ini:

• Jika memperkirakan tanggal peluncuran secara akurat lebih penting daripada menyesuaikan anggaran, gunakan poin cerita.

• Jika anggaran lebih penting daripada tanggal peluncuran yang akurat, pertimbangkan jam bukanya.

Atau, yang terbaik, gabungkan keduanya.

Poin cerita sangat nyaman untuk tim pengembangan yang mengerjakan proyek panjang di mana kecepatan pemantauan akan membuat perbedaan.

Jam kerja penting bagi klien yang khawatir akan menguras anggaran mereka. Juga, jam lebih masuk akal untuk proyek jangka pendek.

Sistem berbasis kompleksitas masih cukup muda, seperti halnya Scrum itu sendiri, dan masih berkembang. Menggabungkan kedua model estimasi dan menyusun sistem untuk dengan cepat mengubah setiap titik cerita menjadi jam memberikan manfaat dari kedua model sambil meminimalkan kekurangannya.