Metode apa yang digunakan pengembang untuk mengevaluasi tugas?

Halo semua! Teori yang diperlukan untuk memulai pengembangan sangat luas. Beberapa spesialis (pengembang backend dalam Java dan bahasa lain) memiliki lebih banyak, sementara yang lain (misalnya, pengembang frontend dalam JavaScript - React Native) memiliki lebih sedikit. Namun, keduanya harus memiliki bekal pengetahuan yang besar tidak hanya teknis, tetapi juga “organisasi”. Pengetahuan “organisasi” ini adalah salah satu titik persimpangan antara pengembang frontend dan backend. Hari ini saya ingin berbicara tentang salah satu aspek dari pengetahuan organisasi non-teknis - tentang penilaian tugas (estimasi). Dan karena saya hanya bekerja di metodologi Agile (yang sebenarnya dianggap paling populer), di subbagiannya, Scrum , saya akan mempertimbangkan penilaian tugas dalam konteks Scrum . Saya akan langsung mengatakan bahwa penilaian, yang disebut juga estimasi, itu sulit. Bagi saya pribadi sebagai pengembang, ini adalah salah satu aspek pekerjaan yang paling sulit/tidak diinginkan. Ada banyak faktor berbeda yang perlu dipertimbangkan yang dapat mempengaruhi penilaian suatu tugas. Pada saat yang sama, rencana pengembangan lebih lanjut akan didasarkan pada perkiraan Anda.

Bagaimana jika penilaian Anda tidak tepat?

Jika seorang pengembang menghabiskan lebih banyak waktu untuk suatu tugas daripada yang akan dihabiskan pada akhirnya, tampaknya dia bukan spesialis terbaik, karena perkiraannya sangat tidak akurat. Jadi bisa dikatakan, satu jari di langit. Pada saat yang sama, jika pengembang tidak berinvestasi dalam waktu yang diperkirakan, ia membahayakan rencana pelanggan untuk merilis produk/fitur baru. Ini adalah bisnis, dan bisnis berarti uang, dan hanya sedikit pelanggan yang menyukai tusukan seperti itu. Ini sebenarnya kenapa saya kurang suka estimasi, karena terkadang sangat sulit menentukan waktu yang tepat untuk menyelesaikan suatu tugas.

Bagaimana waktu dinilai?

Biasanya, estimasi dilakukan dalam jam atau poin cerita. Secara pribadi, saya lebih dekat dengan proses evaluasi dalam poin cerita . Jika jam tangan adalah sesuatu yang bersifat fisik, maka sesuatu yang bisa disalahartikan, poin ceritanya sedikit tentang sesuatu yang lain, lebih abstrak. Biasanya, tim pengembangan perangkat lunak memberikan perkiraan dalam format waktu: jam, hari, minggu, bulan. Perkiraan waktu tersebut terutama didasarkan pada pengalaman pribadi, dugaan, atau intuisi. Dalam hal ini, pengembang hanya melihat tugas dan memberikan perkiraan berapa lama waktu yang dibutuhkan. Akibatnya sangat jarang akurat, karena terlalu banyak faktor yang dapat mempengaruhi batas waktu penyelesaian pekerjaan. Oleh karena itu, banyak tim yang bekerja menurut metodologi Agile menggunakan poin cerita. Mari kita cari tahu.

Apa itu poin Cerita

Titik cerita adalah satuan ukuran yang menyatakan penilaian terhadap upaya total yang diperlukan untuk sepenuhnya melaksanakan suatu bidang pekerjaan (fungsi) tertentu. Artinya, ini adalah kompleksitas yang relatif . Tim menetapkan poin cerita berdasarkan kompleksitas pekerjaan, ruang lingkup pekerjaan, dan risiko atau ketidakpastian. Biasanya, nilai-nilai ini ditetapkan untuk memecah pekerjaan menjadi bagian-bagian yang lebih kecil secara lebih efisien, sehingga menghilangkan ketidakpastian. Seiring waktu, hal ini membantu tim memahami apa yang dapat mereka capai dalam jangka waktu tertentu dan membantu mereka merencanakan area pekerjaan selanjutnya dengan lebih akurat. Hal ini mungkin tampak sangat berlawanan dengan intuisi Anda, namun abstraksi ini sebenarnya cukup berguna: hal ini mendorong tim untuk mengambil keputusan yang lebih sulit mengenai kompleksitas pekerjaan. Mari kita lihat beberapa alasan menggunakan poin cerita dalam perencanaan:

• ketidakakuratan estimasi dalam interval waktu dapat dihindari;
• Berbeda dengan memperkirakan dari waktu ke waktu, biaya overhead dapat diperhitungkan dengan lebih baik: komunikasi antara anggota tim dan pelanggan, berbagai diskusi dan perencanaan tim, serta situasi yang tidak terduga;
• Setiap tim akan menilai pekerjaan pada skala yang berbeda, yang berarti kecepatan mereka (diukur dalam poin) akan berbeda;
• Dengan menentukan skala untuk menetapkan setiap poin cerita, Anda dapat dengan cepat mendistribusikan poin tanpa banyak kontroversi.

Bagaimana TIDAK menggunakan poin cerita

Sayangnya, poin cerita seringkali digunakan untuk tujuan lain. Poin-poin cerita dapat memiliki kelemahan ketika digunakan untuk mengevaluasi orang, menentukan tenggat waktu dan sumber daya secara rinci, dan ketika poin-poin tersebut secara keliru digunakan sebagai ukuran kinerja. Sebaliknya, tim perlu menggunakannya untuk memahami volume/kompleksitas pekerjaan di setiap tugas dan untuk membuat prioritas. Mungkin saja bagian-bagian yang dinilai lebih sulit sebaiknya dikerjakan terlebih dahulu agar dapat diselesaikan sebelum sprint berakhir , namun bagian-bagian yang lebih mudah dapat diundur ke belakang. Izinkan saya mengingatkan Anda apa itu sprint dalam konteks metodologi Scrum : Berapa lama jangka waktu ini ditentukan pada awal pengembangan berdasarkan kesepakatan antara tim dan pelanggan. Ini bisa dalam jangka waktu dua minggu atau satu bulan, atau jangka waktu lainnya. Biasanya, estimasi tugas dilakukan pada awal sprint untuk merencanakan kemungkinan jumlah pekerjaan yang diselesaikan pada akhir sprint, ketika pekerjaan yang telah selesai diserahkan ke pelanggan. Ini membantu Anda melihat kemajuan Anda dalam pengembangan produk, menerima umpan balik dari pelanggan dan menyesuaikan pengembangan proyek sesuai dengan visi pelanggan. Tapi tetap saja, kita ngelantur sedikit: mari kembali ke estimasi. Mengevaluasi tugas oleh satu pengembang saja akan terlalu subyektif. Oleh karena itu, sebagai suatu peraturan, ini adalah kerja tim. Ada beberapa teknik untuk penilaian tim. Hari ini kita akan melihat yang paling banyak digunakan - Scrum poker . Teknik ini membutuhkan seorang manajer yang akan menjadi pemimpin Scrum poker ini . Ini bisa berupa orang yang berspesialisasi dalam Scrum Master , atau PM .

Apa itu Scrum Poker

Scrum poker - atau perencanaan poker - adalah teknik evaluasi yang didasarkan pada pencapaian kesepakatan. Terutama digunakan untuk menilai kompleksitas pekerjaan yang akan datang atau volume relatif tugas yang harus diselesaikan selama pengembangan perangkat lunak. Saya akan segera mencatat bahwa Scrum poker adalah praktik umum dalam pengembangan, dan Anda pasti perlu mengetahui jenis binatang apa itu. Untuk proses ini, kami biasanya menggunakan beberapa jenis aplikasi atau situs web yang memungkinkan kami mengatur penilaian tim terhadap tugas tertentu. Bagaimana ini bisa terjadi? Tim mengambil item simpanan (tugas baru, fungsionalitas), mendiskusikan secara singkat kemungkinan jebakan dan nuansa lain yang terkait dengannya. Setiap peserta kemudian memilih kartu dengan nomor yang mewakili tingkat kesulitannya. Oh, dan saat memperkirakan, yang digunakan bukan deret biasa, melainkan angka Fibonacci . Angka Fibonacci sangat populer di scrum poker karena kesenjangan di antara keduanya meningkat seiring waktu (mengingatkan pada level piramida). Ada tugas-tugas yang memiliki kompleksitas yang sangat besar, dan sejumlah kecil poin cerita tidak dapat dicapai. Penjelasan untuk kartu yang tidak biasa:

jumlah titik akhir yang tidak diketahui

tugas yang sangat panjang

butuh istirahat

Metode estimasi yang lebih langka:

• dalam ukuran kaos - S, M, L, XL
• atau pada anjing - chihuahua, pug, dachshund, bulldog, dan sebagainya (menurut saya, ini adalah unit paling aneh untuk mengevaluasi tugas =D)

Tim kemudian membandingkan perkiraan yang diberikan untuk masalah yang sama oleh pengembang yang berbeda, dan jika mereka setuju, bagus! Jika tidak, maka perlu dibahas alasan terjadinya perbedaan penilaian (argumentasi). Setelah ini, kita bisa bersama-sama mencapai satu perkiraan, yang semua orang, plus atau minus, akan setuju. Nah, mengapa poker digunakan untuk merencanakan proyek perangkat lunak yang serius? Bagaimanapun, ini aneh. Faktanya, gamifikasi seperti itu mendorong anggota tim untuk berpikir mandiri, meminta mereka untuk menunjukkan hasil mereka pada saat yang sama dengan rekan satu tim mereka. Hal ini, pada gilirannya, menghindari ketergantungan pada pandangan anggota tim lainnya. Jika tidak, pengembang yang kurang berpengalaman akan melihat dan mengandalkan penilaian dari anggota tim yang lebih berpengalaman, yang akan meniadakan kegunaan penilaian mereka sendiri. Tetapi dengan pembukaan hasil secara bersamaan, hal ini pada dasarnya tidak mungkin. Contoh aplikasi penjadwalan Scrum Poker berasal dari Atlassian .

Contoh penilaian tugas

Bayangkan tim Anda telah mengidentifikasi skala tertentu untuk evaluasi dalam poin cerita: Scrum Poker memulai sebuah tugas, dan Anda mengevaluasinya seperti ini:

• Anda belum pernah bekerja dengan penerapan fungsi serupa sebelumnya - +3
• fungsionalitas tugas berukuran sedang - +2
• pelaksanaan tugas memiliki kompleksitas tinggi - +3
• kompleksitas tinggi dalam menulis tes untuk fungsi ini - +3

Hasilnya, Anda mendapatkan 11 poin cerita, tetapi karena tidak ada kartu seperti itu, Anda menawarkan 13. Rekan Anda yang lain mengevaluasi tugas tersebut:

• bekerja dengan masalah serupa sebelumnya - +1
• fungsionalitas tugas berukuran sedang - +2
• pelaksanaan tugas memiliki kompleksitas rata-rata - +2
• kompleksitas rata-rata tes penulisan untuk fungsi ini - +2

Hasilnya, dia mendapat 7 poin cerita, tetapi tidak ada hal seperti itu di angka Fibonacci, dan dia menempatkan kartu dengan angka terdekat - 8. Oleh karena itu, anggota tim lainnya memberikan perkiraan berdasarkan pandangan subjektif mereka. Selanjutnya, Anda menunjukkan hasil Anda dan menemukan bahwa hampir semua rekan Anda memberikan perkiraan 13, kecuali satu pengembang yang memberikannya 8. Dalam hal ini, dia diberi dasar dan dia memberikan alasan. Dan mereka, misalnya, seperti ini: dia sebelumnya mengerjakan masalah yang sama, dan itu tidak sesulit kelihatannya, dan pada akhirnya dia meyakinkan anggota tim lainnya untuk mengubah solusi mereka dari 13 menjadi 8 cerita. poin, mengatakan bahwa dia akan membantu siapa pun yang mengambil tugas ini untuk mengetahuinya. Atau, pada akhirnya, dia akan melakukannya sendiri. Dan secara umum, tidak masalah apakah orang lain mendengarkan argumennya atau tidak, karena dengan satu atau lain cara, tugas ini akan diberi peringkat, dan tim akan melanjutkan untuk membiasakan diri dengan tugas berikutnya. Pada kali pertama, perkiraan akan menjadi tidak akurat, begitu pula perkiraan jumlah pekerjaan yang Anda rencanakan untuk dilakukan pada periode waktu berikutnya (sprint). Bagaimanapun, perkiraan ini dibuat berdasarkan perkiraan. Setelah beberapa waktu, sekitar tiga bulan, tim akan mulai memperkirakan tugas dengan lebih akurat, dan jumlah rata-rata pekerjaan yang dapat diselesaikan tim per sprint akan terlihat. Tapi ini adalah perencanaan umum ruang lingkup pekerjaan, lebih pada waktu, dan dalam hal ini mungkin ada banyak faktor berbeda yang berdampak. Misalnya, salah satu pengembang pergi berlibur selama dua minggu. Artinya, Anda perlu mencoret sejumlah pekerjaan yang direncanakan (fungsi yang direncanakan). Atau pengembang baru telah datang ke tim, tetapi Anda tidak perlu sepenuhnya mengandalkannya, karena... Anda perlu memperhitungkan waktu yang diperlukan untuk beradaptasi dengan proyek, yang disebut orientasi . Ini bisa memakan waktu dua minggu, plus atau minus seminggu, tergantung kompleksitas proyek. Itu saja untuk hari ini, saya harap saya dapat sedikit meningkatkan pengetahuan Anda di bagian pengetahuan non-teknis seperti estimasi masalah. Jika Anda ingin mempelajari lebih dalam topik ini, serta detail tentang Scrum, saya sangat menyarankan Anda untuk membaca buku “SCRUM” oleh Jeff Sutherland. Saya tidak bisa menjamin konsekuensinya, karena mungkin setelah itu Anda akan memiliki keinginan yang mengganggu untuk menjadi Scrum Master =D