Estimasi Agile dalam Scrum? Poin Cerita dan Poker Perencanaan

Dalam proses pengembangan perangkat lunak, tim sering memiliki pertanyaan:

Bagaimana waktu kerja diperkirakan agar lebih akurat?

Bagi pemilik proyek atau produk, ini adalah informasi yang sangat penting untuk pengukuran sumber daya proyek dan garis waktu mereka, tetapi praktik ini telah menyebabkan banyak masalah.

Banyak pengembang selalu merasa bahwa PM menggunakan tenggat waktu untuk mendorong maju mundur. Mereka tidak peduli apakah fitur dapat diselesaikan dengan kualitas.

“Selesaikan dulu, baru cari yang lebih baik” telah beredar di industri perangkat lunak untuk waktu yang lama.

Banyak PM selalu merasa bahwa pengembang cenderung “melebih-lebihkan” ketika mereka memperkirakan pekerjaan mereka. Sepertinya mereka semua menggunakan metode estimasi kerja yang khas: “Perkirakan tiga kali lipat dari waktu sebenarnya sebagai buffer”

Sebenarnya, jam kerja tidak dapat diperkirakan menjadi “sangat akurat”, tetapi ada beberapa cara untuk memperkirakan “relatif objektif”. Karena kompleksitas jam kerja dan persyaratan, sering kali ada korelasi positif. Oleh karena itu, artikel ini akan terlebih dahulu menjelaskan masalah umum sebagai respons terhadap kompleksitas persyaratan, mengusulkan solusi yang diusulkan, dan menjelaskan tujuan dari banyak desain dalam solusi.

Masalah

Tambang Pengembang

• “Ini sangat sederhana. Seharusnya tidak memakan waktu terlalu lama untuk membuatnya?”
• PM berkata kepada Anda hari ini: “Saya harus menyerahkannya sebelum besok. “Selesaikan dulu sebelum mencari kualitas”
• PM berkata kepada Anda lusa: “Mengapa kualitas program ini begitu buruk?”
• Ketika telah tertunda, rekan-rekan lain: “Mengapa Anda perlu menghabiskan waktu begitu lama? Ini memiliki kode siap pakai untuk referensi. Ini memiliki lapisan dasar yang baik untuk digunakan. Mengapa Anda tidak bertanya kepada saya?”
• Rekan-rekan lain: “Saya hanya perlu satu hari, mengapa Anda menghabiskan begitu banyak hari?”
• “Ini adalah akal sehat! Jika kita tidak menyebutkan persyaratan, Anda seharusnya tahu apa yang harus dilakukan.”

Tambang PM/PO

• “Mengapa ini begitu sederhana? Mengapa memakan waktu begitu lama?”
• “Mengapa Anda melihat bahwa Anda sedang mengunjungi Facebook, tetapi Anda tidak punya waktu untuk membuatnya?”
• “Mengapa kualitas dari hal-hal yang dibuat begitu buruk?”
• “Mengapa dia membuatnya terakhir kali, berapa banyak hari yang Anda butuhkan untuk melakukannya?”
• Karena spesifikasi atau persyaratan tidak ditulis dengan jelas, pengembang digambarkan sebagai perubahan persyaratan.

Hasil

• Permusuhan peran: Unit permintaan dan unit pengembangan tidak lagi mengantarkan produk yang dapat memberikan manfaat kepada pengguna, tetapi saling menyerang untuk kepentingan mereka sendiri, untuk menghindari harus menanggung tanggung jawab tambahan. Oleh karena itu, situasi di mana unit permintaan dan unit pengembangan sama sekali bukan tim tunggal.
• Tanggung jawab: Tim berpikir bahwa “Saya tidak salah, jadi keterlambatan bukan tanggung jawab saya”, Alih-alih memprioritaskan kebutuhan pengguna.
• Pembekuan permintaan: Pengembang dipaksa untuk mengubah persyaratan mereka karena tekanan tenggat waktu, jika tidak, mereka akan tertunda dan tanggung jawab akan dihitung pada pengembang. Akibatnya, baik diminta untuk bekerja lembur untuk menghasilkan sesuatu yang menyembunyikan banyak bug, atau untuk membuat semacam fitur yang tidak memenuhi kebutuhan pengguna; dan keduanya akan mengurangi kepuasan pengguna.
• Kualitas rendah: Status PM sering kali lebih tinggi daripada pengembang. Oleh karena itu, untuk memenuhi tenggat waktu kontrak atau menghindari penalti, dll., tim akan diminta untuk “Selesaikan dulu, baru cari yang lebih baik”, tetapi akhirnya sering kali “pertama, tidak ada waktu untuk mencari yang baik.” Akumulasi utang teknis semakin meningkat, dan hasilnya adalah model rantai tanggung jawab dunia nyata, yang memiliki tanggung jawab dan biaya terbesar di akhir rantai. Jadi tim seperti pop tumpukan, pengembang tidak dapat bertahan satu per satu, yang merupakan salah satu faktor mengapa insinyur perusahaan proyek sering memiliki tingkat perputaran yang tinggi.
• Meningkatkan beban kode: Untuk mengoptimalkan efisiensi, posisi orang yang paling akrab selalu digunakan untuk memperkirakan jam kerja, sehingga orang yang paling akrab dengan modul dan proses akan selalu memperhatikan persyaratan yang relevan. Pada akhirnya, hanya orang-orang itu yang dapat memelihara kode mereka sendiri, ini seperti kotak Pandora, Anda tidak pernah tahu sapi dan hantu mana yang akan keluar setelah dibuka. Karena kotak hitam sering kali kotor, tetapi perusahaan tidak tahu bagaimana menyelesaikan masalah ini. Anda juga berharap dia tidak akan pergi, jika tidak, beberapa kode tidak akan dipahami.

Solusi

Solusi yang diusulkan di sini adalah cara umum untuk memperkirakan kompleksitas persyaratan dalam Scrum, tetapi bahkan jika itu bukan tim Scrum, disarankan agar pembaca dapat mengidentifikasi cara terbaik untuk memperkirakan tim Anda berdasarkan prinsip dan tujuan desain.

Ingatlah bahwa tanpa peluru perak, praktik terbaik orang lain tidak selalu berlaku untuk tim Anda, jadi pertama-tama pahami apa masalah yang saat ini dialami tim Anda, dan kemudian cari tahu apa yang tepat untuk Anda untuk menyelesaikan masalah dari praktik orang lain, selama itu tidak menimbulkan masalah baru atau risiko biaya dari masalah baru dapat diterima.

Unit yang digunakan di sini untuk memperkirakan kompleksitas persyaratan adalah poin cerita (unit relatif), bukan jam kerja (unit absolut).

Unit yang digunakan untuk memperkirakan kompleksitas permintaan di sini adalah poin cerita (unit relatif), bukan waktu kerja (unit absolut). Ada beberapa alasan untuk melakukan ini:

1. Perbandingan tidak bervariasi dari orang ke tempat: kompleksitas persyaratan sering kali tidak bervariasi dari orang ke orang, dan waktu yang dibutuhkan untuk praktik akan bervariasi dari orang ke orang.

2. “Relatif” lebih mudah dievaluasi daripada “Absolut”: Jika Anda melihat jam kerja, Anda perlu memperkirakan angka absolut, dan Anda perlu memikirkan detail implementasi dalam proses estimasi. Untuk menggunakan poin cerita untuk memperkirakan kompleksitas, Anda hanya perlu membandingkan ukuran dengan persyaratan lainnya.

Sebagai contoh, sulit untuk mengatakan dengan jelas bahwa “Sebuah Menara setinggi beberapa meter”, tetapi lebih mudah untuk menunjukkan bahwa “Menara ini sekitar 2 kali lebih tinggi dari bangunan itu.”

3. Tekanan untuk memperkirakan poin cerita dari sebuah cerita pengguna lebih kecil daripada memperkirakan waktu kerjanya: fokus pada persyaratan itu sendiri, tanpa khawatir tentang sumber daya sendiri dan sumber daya proyek, cukup menilai kompleksitas persyaratan. Selama proses estimasi, anggota tim kurang stres dan memainkan bagian dari pengembangan perangkat lunak seperti sebuah permainan.

Meskipun kompleksitas permintaan sering kali berhubungan positif dengan jam kerja, karena kondisi implementasi yang berbeda, masih mungkin memiliki fitur dengan poin cerita tinggi, dan permintaan untuk jam kerja lebih rendah dari poin cerita. Tetapi dalam Scrum, Anda dapat menggunakan sprint iterasi untuk mengevaluasi seberapa banyak kompleksitas yang dapat dicerna oleh setiap tim sprint. Untuk PO/PM, alih-alih memperkirakan jalur waktu yang tidak berhasil, lebih baik memperkirakan jalur waktu yang lebih akurat dan objektif sehingga mereka dapat memahami pada waktu pertama, seberapa jauh dari jalur waktu yang diharapkan dari proyek. Jika sumber daya terbatas, bagaimana memprioritaskan persyaratan atau mencari dukungan lain.

Selanjutnya, jelaskan berbagai aspek dari solusi.

Kapan

Lakukan penilaian sebelum memutuskan siapa yang perlu melakukannya: Manfaat melakukan ini adalah untuk meminimalkan faktor pribadi pengembang. Karena Anda tidak tahu siapa yang akan melakukannya, tidak perlu memperkirakan secara berlebihan untuk menambahkan buffer karena tugas atau tenggat waktu Anda sendiri.

Siapa

Hanya orang-orang yang melakukan hal-hal untuk mengevaluasi bersama: dua poin kunci:

1. Hanya orang yang melakukan hal-hal yang dapat diperkirakan. Waktu atau kompleksitas yang diperkirakan oleh unit permintaan tidak objektif, karena mereka bukan orang yang sebenarnya melakukan pekerjaan tersebut, dan tidak ada kekuatan untuk mempengaruhi estimasi tim pengembangan berdasarkan penilaian kemampuan kerja. Ini juga memudahkan untuk menghindari evaluasi kompleksitas persyaratan dari tenggat waktu.
2. Orang-orang yang melakukan hal-hal bersama memperkirakan. Karena Anda tidak tahu siapa yang akan melakukannya, angka yang diperkirakan setiap orang bersama-sama mudah untuk mencapai konsensus setelah diskusi dan penilaian ulang. Setiap orang memiliki partisipasi, mereka akan memiliki rasa partisipasi, dan karena setiap orang memiliki partisipasi, hasil estimasi ditentukan oleh semua orang, jadi siapa yang akan melakukannya di masa depan tidak akan mengeluh.

Apa

Gunakan Poker Perencanaan untuk memperkirakan poin cerita.

Kartu poker dan urutan Fibonacci

YangSeri Fischer memiliki fitur menarik, dan setiap angka adalah hasil penjumlahan dari dua angka pertama. Di sisi lain, semakin besar perbedaan antara angka dan angka berikutnya, semakin besar perbedaannya.

Seperti yang ditunjukkan di atas, jarak antara 8 dan 13 adalah 5, dan perbedaan antara 13 dan 20 adalah 7. Namun, bagaimana ini terkait dengan memperkirakan kompleksitas permintaan? Kita bukan di kelas matematika.

Karakteristik Estimasi Terkait dengan urutan Fibonacci

Estimasi juga memiliki karakteristik, yaitu semakin besar semakin akurat, semakin besar permintaan atau tugas dipotong menjadi granularitas yang lebih halus, sering kali diperkirakan lebih akurat. Sama seperti jika sepotong batu besar yang tidak teratur dipasang di dalam cangkir, akan ada lebih banyak celah di tengah, yang merupakan bagian yang tidak sejajar atau terbuang. Jika Anda memasang batu dengan ukuran yang lebih halus dan ketidakaturan yang sama, celahnya akan relatif kecil, dan mudah untuk disesuaikan, dan dapat mengisi celah dengan lebih nyaman.

Bahkan jika perbedaan dalam angka sebelumnya relatif kecil, itu tidak masalah karena angkanya kecil, yang berarti bahwa pergerakannya fleksibel dan risikonya rendah. Jika estimasi waktu tidak akurat karena faktor tertentu, tugas dari angka kecil di depan adalah sekitar 20 menit lembur. Alih-alih bekerja lembur selama 2 atau 5 hari.

Karena celah digital yang besar besar (rasio perbedaan dari dua nilai depan dan belakang dari seri Fermi mendekati 1.618), adalah mungkin untuk menghindari estimasi ‘apakah kompleksitas ini 20 atau 21’. ‘Jika Anda ingin 13, Anda ingin 20, Anda ingin 40.

Celah seperti itu dapat menyoroti perbedaan dalam estimasi dari kebutuhan yang sama, karena hampir semuanya lebih dari 1,5 kali lebih buruk. Rasio ini cukup mudah bagi manusia untuk menilai ukuran relatif, dan oleh karena itu dapat mengurangi banyak nuansa dan biaya proses Re-estimasi yang tidak perlu.

Angka Khusus dalam Kartu Poker

Selain itu, gambar di atas dapat dilihat dengan beberapa angka khusus, yaitu 0, tak terhingga, dan tanda tanya.

• 0 mungkin berarti bahwa kebutuhan ini tidak perlu dilakukan sama sekali, atau sudah selesai.
• Tak terhingga berarti bahwa permintaan jelas, tetapi yang melebihi angka maksimum menunjukkan bahwa permintaan perlu dibagi menjadi beberapa kebutuhan yang lebih kecil.
• Tanda tanya menunjukkan bahwa permintaan tidak jelas dan membutuhkan PO/PM untuk menjelaskan atau mengklarifikasi.

Bagaimana

1. Pertama, definisikan unit kompleksitas 1, seperti fungsi dari kueri komprehensif tabel tunggal. Karena proses estimasi kami didasarkan pada ukuran relatif, kami pertama-tama mendefinisikan unit tolok ukur perbandingan, dan ada dasar untuk perbandingan setelah tim melakukan estimasi.

2. Pembawa acara mengucapkan dengan keras kebutuhan (seperti Kartu Cerita Pengguna) untuk memastikan bahwa semua orang memahami kebutuhan dan setiap orang menyajikan kompleksitas estimasi mereka sendiri. Alasan menggunakan poker perencanaan adalah karena angka yang Anda evaluasi dapat disajikan secara bersamaan, alih-alih memutar angka yang telah Anda evaluasi. Mudah untuk mengeluarkan angka dan menyebabkan hasil orang di belakangnya terpengaruh oleh angka sebelumnya.

3. Jika ada estimasi yang berbeda dalam tim, dua di antaranya diperkirakan sebagai yang terkecil dan terbesar, dan mereka akan menilai mengapa mereka rumit atau sederhana. Dalam contoh di atas, dalam proses estimasi, jika satu orang memperkirakan bahwa poin cerita adalah 13, sebagian besar orang memperkirakan 20 dan orang lain memperkirakan 40. 13 dan 40 hampir 3 kali lebih buruk, jadi pada dasarnya harus ada beberapa informasi penting yang belum disinkronkan.

Misalnya, orang yang memperkirakan 13 berpikir bahwa permintaan ini hampir sama dengan kebutuhan di masa lalu, dan kebutuhan ini tidak serumit yang dibayangkan. Orang yang memperkirakan 40 mungkin merasa relatif rumit karena dia tidak cukup akrab dengan kebutuhan atau proses ini.

4. Angka minimum dan maksimum alasan untuk penilaian diselesaikan dan pemungutan suara lebih lanjut diadakan. Jika masih ada angka suara yang berbeda, dan sebagian besar orang memiliki konsensus, dan tidak ada konsensus bahwa kompleksitas yang diperkirakan hanya satu tingkat dari kompleksitas konsensus, Anda dapat bertanya kepada anggota yang memperkirakan angka yang berbeda apakah mereka dapat menerima angka yang telah Anda nilai.

5. Jika angka masih memiliki celah di atas suatu tingkat, atau jika konsensus tidak dapat diperoleh, ulangi langkah 3 hingga 5 sampai konsensus tercapai.

Sekali lagi, hanya mereka yang benar-benar melakukan tugas atau menyelesaikan kebutuhan yang dapat berpartisipasi dalam proses pemungutan suara, dan PO/PM tidak dapat campur tangan.

Mengapa

Ada beberapa keuntungan dari cara estimasi ini:

1. Orang yang bekerja sama memutuskan hasil estimasi yang wajar dan objektif, memiliki rasa partisipasi dan tidak ada keluhan.
2. Hasil keputusan adalah konsensus antara PO dan Tim, yang akan mengurangi terjadinya situasi saling balas di masa depan.
3. Semua orang dapat memahami kebutuhan. Di masa depan, semua orang dapat bertindak sebagai orang yang memenuhi kebutuhan. Ketika kebutuhan dukungan diperlukan, orang juga dapat saling membantu atau mendukung.
4. Sebelum Anda melakukannya, Anda dapat mengklarifikasi bagian dari kebutuhan yang tidak jelas dan bagian yang memiliki keraguan.
5. Sebelum Anda dapat melakukannya, Anda dapat menemukan cara terbaik dan paling efisien untuk bekerja dalam tim.
6. Kecuali seluruh tim adalah orang yang tidak dapat diandalkan, angka ini mencerminkan fakta bahwa estimasi dibagikan oleh tim, dan PO dapat memahami celah antara permintaan dan evaluasi.
7. Dengan membandingkan ukuran relatif kompleksitas antara kebutuhan, PO di masa depan akan dapat menjanjikan seberapa banyak pekerjaan yang dapat dipenuhi dalam satu iterasi, dan akan ada dasar untuk perbandingan.

Kesimpulan

Melalui proses estimasi di atas, keputusan semacam itu terbuka, transparan, objektif, dan konsensual. Untuk dua peran:

Untuk PO/PM:

• Jangan khawatir tentang memperkirakan tugas secara berlebihan untuk buffer oleh anggota tertentu.
• Memahami kesulitan mendasar dalam menerapkan kebutuhan atau tugas dalam proses penilaian.
• Memahami apakah ada bagian dari kebutuhan yang perlu dinyatakan dengan jelas atau disalahpahami.

Untuk tim:

• Orang-orang yang tidak lagi melakukan hal-hal diberikan batas waktu yang tidak wajar sesuai dengan tenggat waktu.
• Pertukaran pengetahuan antara pengembang sebelum mereka mulai mengerjakan tugas. Terlepas dari apakah angka yang diperkirakan meningkat atau menurun, permintaan menjadi lebih jelas dan estimasi menjadi lebih objektif.
• Karena Anda masih tidak tahu siapa yang mengklaim tugas ini, jadi proses estimasi dapat dicapai secara objektif dan dengan konsensus tim, Anda tahu siapa yang akrab dengan tugas ini melalui proses tersebut. Ketika Anda benar-benar melakukannya, Anda dapat melakukan pemrograman pasangan atau tahu siapa yang harus dimintai bantuan.

Solusi yang diusulkan dalam makalah ini adalah solusi umum. Fokusnya bukan pada bentuk, tetapi pada tujuan desain dari setiap tautan dalam proses estimasi agile, untuk menyelesaikan masalah jenis apa.

Artikel dalam Teknik Scrum

• Apa itu Acara Scrum?
• Apa itu Upacara Scrum?
• Apa itu Perawatan Backlog Produk?
• Apa 3 Pertanyaan Penting dalam Scrum Harian?
• Siklus Sprint Scrum dalam 8 Langkah
• Apa itu Sprint dalam Scrum?
• Detak Jantung Scrum — Standup Harian
• Pertemuan Scrum Harian — Panduan Singkat
• Mengapa Sprint dengan Panjang Tetap dalam Scrum?
• Apa itu Perencanaan Rilis Scrum?
• Apa itu Perencanaan Sprint?
• Apa itu Tinjauan Sprint?
• Apa itu Rapat Retrospektif Sprint dalam Scrum?
• Apa itu Penyempurnaan Backlog Produk?
• Apa itu Integrasi / Pengiriman / Penyebaran Berkelanjutan dalam Scrum?
• Apa itu Acara Terikat Waktu dalam Scrum?
• Apa itu Spike dalam Scrum?
• Apa itu Poker Perencanaan dalam Agile?

This post is also available in Deutsch, English, Español, فارسی, Français, 日本語, Polski, Portuguese, Ру́сский, Việt Nam, 简体中文 and 繁體中文.