{"id":571,"date":"2022-01-26T01:39:34","date_gmt":"2022-01-26T01:39:34","guid":{"rendered":"https:\/\/www.cybermedian.com\/id\/?p=571"},"modified":"2025-02-14T17:52:36","modified_gmt":"2025-02-14T09:52:36","slug":"agile-estimation-relative-estimates-vs-absolute-estimates","status":"publish","type":"post","link":"https:\/\/www.cybermedian.com\/id\/agile-estimation-relative-estimates-vs-absolute-estimates\/","title":{"rendered":"Estimasi Agile: Estimasi relatif vs Estimasi absolut"},"content":{"rendered":"
\n
\n
\n

Akurasi Estimasi Kelompok vs. Individu<\/p>\n

Apakah tim sedang mengerjakan produk atau proyek, kita perlu menjawab pertanyaan \u201cKapan kita akan selesai?\u201d Atau seberapa jauh kita bisa pergi pada titik tertentu dalam waktu. Sama seperti pengembangan tradisional, kita perlu memperkirakan usaha sebelum kita memulai proyek.<\/p>\n

Apa itu Estimasi Proyek?<\/h3>\n

Sebuahestimasi<\/a>adalah perhitungan kasar tentang sesuatu. Misalnya, estimasi biaya proyek adalah konsep umum dari model harga proyek. Ini membantu Anda memberikan angka yang lebih realistis ketika pelanggan atau pemangku kepentingan proyek lainnya meminta Anda untuk mengevaluasi biaya dan waktu proyek.<\/p>\n

Estimasi Agile vs Tradisional<\/h4>\n

Secara tradisional, kita mengalokasikan waktu untuk memperkirakan proyek perangkat lunak, sementara dalammetode agile<\/a>, mereka lebih suka memberikan poin cerita untuk item backlog sebagai ukuran kerja relatif. Ini memungkinkan tim untuk mempertimbangkan pekerjaan lain yang telah mereka lakukan di masa lalu dan membandingkannya dengan backlog produk yang akan mereka estimasi. Poin cerita tidak diukur dengan memberikan waktu absolut, tetapi dengan memperkirakan beban kerja yang diperlukan untuk menyelesaikan tugas serupa berdasarkan pengalaman masa lalu.<\/p>\n

Estimasi agile<\/a>memiliki tiga karakteristik berikut:<\/p>\n

    \n
  1. Estimasi Kolektif Tim<\/li>\n
  2. Usaha Relatif vs Estimasi Waktu Absolut<\/li>\n
  3. Estimasi Kecepatan Tim<\/li>\n<\/ol>\n

    1. Estimasi kolektif<\/h3>\n

    Selama pengembanganScrum<\/a>, tim berbagi tanggung jawab dan secara kolektif berkomitmen pada pekerjaan setiapSprint<\/a>, jadi beban kerja yang diperkirakan untuk tim agile menggunakan pendekatan estimasi kolektif. Estimasi kolektif biasanya menggunakan Planning poker sebagai alat, tim membuat estimasi kolektif dengan bermain permainan estimasi.Planning poker<\/a>dianggap sebagai teknik yang paling efektif dan sangat menarik untuk melakukan estimasi beban kerja dalamAgile<\/a>. Ini terdiri dari sekumpulan angka yang mirip dengan angka Fibonacci, termasuk: 0, 0.5, 1, 2, 3, 5, 8, 20, 40,\u00a0?, \u221e, setiap dek kartu poker memiliki 4 kelompok angka Fibonacci tersebut untuk digunakan oleh 4 orang.<\/p>\n

    Akurasi Estimasi Kelompok vs. Individu<\/strong><\/h4>\n

    Menurut beberapa studi tentang akurasi estimasi usaha antara individu dan kelompok dalam sebuah eksperimen untuk proyek perangkat lunak. 20 profesional perangkat lunak dari perusahaan yang sama secara individu memperkirakan usaha kerja yang diperlukan untuk mengimplementasikan proyek pengembangan perangkat lunak yang sama. Para peserta memiliki latar belakang yang berbeda danperan<\/a>dan proyek perangkat lunak telah diimplementasikan sebelumnya. Setelah itu, mereka membentuk lima kelompok. Setiap kelompok sepakat pada satu estimasi dengan mendiskusikan dan menggabungkan pengetahuan di antara mereka.<\/p>\n

    Hasil\u200a\u2014\u200aEstimasi berdasarkan diskusi kelompok lebih akurat daripada estimasi individu.<\/p>\n

    Langkah-langkah untuk Melakukan Planning Poker<\/strong><\/h4>\n
      \n
    1. Setiap anggota tim mendapatkan satu set kartu, termasuk 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40,\u00a0?, \u221e, total 12 kartu.<\/li>\n
    2. Anggotaproduk<\/a>akan membaca atau menjelaskan fitur kepada tim.<\/li>\n
    3. Anggotatim<\/a>mendiskusikan fitur dan, mengajukan pertanyaan kepada pemilik produk jika diperlukan.<\/li>\n
    4. Ketika anggota telah menyelesaikan diskusi mereka, setiap anggota memilih satu kartu poker untuk mewakili estimasi. Kartu-kartu tersebut kemudian diungkapkan secara bersamaan.<\/li>\n
    5. Jika tim mengevaluasi estimasi yang berbeda. Apakah kita setuju? Apakah ada perbedaan? Apakah ada sesuatu yang belum saya pertimbangkan? Mereka yang memilih nilai tertinggi atau terendah harus membagikan alasan mereka kepada kelompok sebelum setiap anggota memilih kartu poker lainnya.<\/li>\n
    6. Setelah diskusi, Anda dapat memperkirakan putaran lain, dan tim perlu mencapai kesepakatan.<\/li>\n
    7. Kembali ke langkah kedua dan mulai memperkirakan entri berikutnya.<\/li>\n<\/ol>\n

      2. Usaha Relatif vs Estimasi Waktu Absolut<\/h3>\n

      Sebuah estimasi tidak lebih dari sekadar tebakan yang terdidik dengan baik. Kami menggunakan semua pengetahuan dan pengalaman yang ada untuk membuat tebakan tentang jumlah waktu yang akan dibutuhkan. Jadi, alih-alih melihat setiap item kerja baru secara terpisah, mengapa tidak membandingkannya dengan item kerja yang telah selesai sebelumnya? Lebih mudah bagi manusia untuk mengaitkan dengan item yang serupa daripada menebak ukuran sebenarnya dari sesuatu.<\/p>\n

      Misalnya, apakah ini lebih dekat dengan hal yang sangat kecil ini? Atau apakah ini lebih mirip dengan item berukuran normal ini? Atau apakah ini benar-benar besar seperti satu pekerjaan yang kita selesaikan bulan lalu? Melakukan estimasi relatif tidak hanya akan mengurangi jumlah waktu yang dihabiskan untuk memperkirakan pekerjaan, tetapi juga akan sangat meningkatkan akurasi estimasi.<\/p>\n

      Otak kita tidak mampu melakukan estimasi absolut; kita selalu menempatkan hal baru yang perlu kita estimasi dalam hubungan dengan hal-hal yang sudah kita ketahui.<\/p>\n

      <\/figure>\n

      3. Estimasi Kecepatan\u200a\u2014\u200aMencatat dan Rata-rata kecepatan tim setiap<\/h3>\n

      Timkecepatan<\/a> adalah jumlah dari poin cerita<\/a> yang tim Scrum<\/a> benar-benar menyelesaikan dalam sebuah Sprint. Kecepatan tim memberi tahu Anda seberapa cepat tim bekerja. Sebuah proyek atau tim yang baru diperkirakan (tanpa merujuk pada catatan kecepatan di masa lalu), kita bisa melakukan 1\u20132 Sprint<\/a> untuk mengukur kecepatan sebagai kecepatan awal. Dalam proses implementasi Sprint, kita perlu mencatat kecepatan setiap Sprint, untuk rencana mendatang.<\/p>\n

      <\/figure>\n

      Kami memperkirakan total jumlah poin cerita<\/a> untuk Backlog produk<\/a>, dan kemudian kita mengetahui rata-rata kecepatan setiap Sprint, kemudian kita bisa menghitung berapa banyak Sprint yang kita butuhkan untuk menyelesaikan, dan dengan demikian Sprint diharapkan diperlukan untuk proyek seperti yang ditunjukkan pada Gambar di bawah.<\/p>\n

      <\/figure>\n<\/div>\n<\/div>\n<\/section>\n
      \n
      \n
      \n<\/div>\n
      \n
      \n