Halo. Izinkan saya memberi tahu Anda tentang pengalaman saya dalam mengevaluasi produk perangkat lunak. Saya telah melakukan ini tanpa gangguan selama 15 tahun sekarang, dan saya ingin berbagi pengalaman saya dan evolusi pandangan saya tentang penilaian. Saya yakin ini akan bermanfaat. Mari kita mulai dengan penetapan tujuan. Mengapa harus mengukur? Siapa yang membutuhkannya?
Jawabannya sebenarnya sangat sederhana - orang menginginkan kepastian, khususnya jawaban atas pertanyaan "kapan akan siap?" Kapan saya bisa pergi berlibur, saat penjualan dimulai, kapan harus melakukan tugas terkait. Di sisi lain - Anda tidak pernah tahu apa yang diinginkan orang, mengapa karena keinginan orang lain untuk membuang waktu mereka untuk kegiatan ini?
Tetapi, pada akhirnya, kita semua ingin menerima gaji, dan gaji tersebut tidak muncul begitu saja, perusahaan mengambilnya dari hasil, dalam kasus terpisah - dari investasi. Dan agar pendapatan ini menjadi, kita perlu mencapai tujuan bisnis. Dan orang-orang yang merumuskan tujuan bisnis sangat menyukai semua jenis formula keuangan - ROI, LTV, dan EBITDA lainnya. Dan rumus ini selalu menampilkan tenggat waktu. Tanpa mereka buaya tidak ditangkap, kelapa tidak tumbuh.
Ada juga alasan kedua, yang sedikit kurang penting: jika perkiraan fitur jelas, maka ini memengaruhi prioritasnya, tugas yang lebih sederhana cenderung mendapat prioritas lebih tinggi. Karena dalam pendekatan agile konvensional, backlog secara teratur diguncang, informasi masukan tentang peringkat tugas membantu membuat proses pemrioritasan ulang lebih efisien.
Akibatnya: kemungkinan besar, Anda masih harus mengevaluasi. Rendahkan dirimu .
Sekarang mari kita bicara tentang bagaimana melakukan ini, agar tidak mengutuk segalanya dan semua orang dalam prosesnya. Bagaimana orang yang tidak tahu cara mengevaluasi hal-hal IT biasanya menilai? Seperti ini:
- Kami mengevaluasi semua pekerjaan secara pribadi.
- Tambahkan 10% untuk berjaga-jaga.
- Bagi dengan jumlah pengembang.
- Kami menambahkan jumlah hari yang dihasilkan ke tanggal saat ini dan mendapatkan tanggal akhir.
- Itu saja.
Karena itu, kilas balik Vietnam dari gambar judul masih berkedip di depan mata saya: terlalu banyak saraf saya yang hilang dalam perang ini. Dan Anda akan mati jika Anda mulai mengevaluasi dengan cara ini. Masalahnya adalah bahwa inilah jenis penilaian yang diharapkan dari Anda:
"Jangan bermain-main dengan poin cerita Anda, tunjukkan tangan Anda."
Masalah apa yang akan dihadapi selama penilaian
Mari kita mulai dengan situasi yang ideal:
- Kami memiliki tugas atom (sederhana, tak terpisahkan).
- Tidak ada ketergantungan pada tugas lain, tidak perlu mengoordinasikan apa pun.
- Ada 100% orang yang berdedikasi untuk tugas yang tahu bagaimana melakukannya.
Bahkan dalam kasus ini, muncul pertanyaan "Siapa yang akan membuat penilaian?" Pada saat ini, mesin kendali yang tak kenal ampun dimulai. Pertama, manajer berpikir: jika pengembang akan melakukan ini, apa yang akan mencegahnya untuk menentukan biaya tenaga kerja yang besar untuk dibodohi? -> Oleh karena itu, manajer mengevaluasi sendiri tugas tersebut. -> Namun, manajer tidak memahami topik dengan cukup dalam dan tidak melihat (atau tidak ingin melihat) jebakan. -> Estimasi tersebut ternyata diremehkan dan tidak dapat diperbaiki. -> Tim tidak memenuhi tenggat waktu. -> Kematian dan pembusukan.
Situasi yang dijelaskan di atas adalah masalah budaya perusahaan klasik dari ketidakpercayaan karyawannya. Namun, sebagian besar pengembang memiliki motivasi intrinsik untuk memecahkan masalah yang menarik, bagi mereka itu jauh lebih menarik daripada bermain bodoh di depan komputer, jadi tidak ada alasan untuk ketidakpercayaan yang meluas. Secara umum, perusahaan harus dibangun atas dasar asumsi kepercayaan pada karyawannya, dan tidak memutarbalikkan proses bisnis normal agar terlihat seperti kambing hitam.
Budaya ketidakpercayaan sangat umum dalam hubungannya dengan budaya ketakutan perusahaan: bahkan jika seorang pengembang mengevaluasi tugas, apa yang terjadi di kepalanya selama evaluasi? Dia menjawab pertanyaan: "Bagaimana reaksi perusahaan saya terhadap perbedaan antara tanggal yang direncanakan dan yang sebenarnya?" Jika pengembang dimarahi karena tenggat waktu yang gagal, dia akan melebih-lebihkannya. Jika penilaian lebih lanjut pengembang dipotong untuk tugas yang dibuat sebelumnya, dia tidak akan menyerahkan tugas sebelumnya.
Contoh terbaru dari budaya ketakutan adalah rilis Cyberpunk 2077. Game ini dirilis dengan kualitas menjijikkan di konsol generasi sebelumnya. CEO perusahaan tersebut mengatakan dalam sebuah pernyataan bahwa "ternyata, banyak masalah yang Anda temui dalam game tidak ditemukan selama pengujian." Yang, tentu saja, merupakan kebohongan total. Masalah terlihat dengan mata telanjang, penguji secara fisik tidak bisa melewatkan ini. Ini adalah situasi khas dalam budaya ketakutan: masalah ditutup-tutupi. Jadi informasi di sepanjang jalan menuju lantai atas manajemen berubah dari "game tidak dapat dimainkan di konsol dasar" menjadi "mari rilis".
Jika ini bukan kasus Anda, maka Anda dapat mengevaluasi lebih lanjut. Jika Anda kurang beruntung dengan budaya di perusahaan, jangan membaca lebih lanjut, karena Anda perlu mengeluarkan penilaian bukan untuk akurasi, tetapi untuk meminimalkan tendangan dari pihak berwenang, dan ini adalah tugas yang sama sekali berbeda.
Jadi Anda memberi perkiraan, misalnya - 1 minggu. Ini hanya tebakanmu, tidak lebih. Evaluasi menentukan tanggal penyelesaian tugas yang direncanakan, tetapi tidak dapat menentukan kapan akan benar-benar selesai. Di mana tepatnya waktu penyelesaian tugas yang sebenarnya akan dijelaskan dengan distribusi normal. Untuk saat ini, mari kita ingat ini sebagai aksioma, pada akhirnya akan ada alur cerita.
Semuanya semakin diperumit oleh fakta bahwa beberapa tugas pada dasarnya tidak dibagi menjadi beberapa bagian, dan kebetulan juga tidak dapat diparalelkan. Ada juga tugas yang saling bergantung, Anda perlu menyelami konteks tugas. Ditambah, saat berkembang, tim perlu berkomunikasi untuk menyelaraskan aktivitas mereka.
Kami juga tidak tahu bagaimana melihat masa depan. Akibatnya, tugas terus-menerus muncul yang tidak kami perkirakan, dan tidak dapat diramalkan. Apa itu?
- Keinginan pelanggan atau Pemilik Produk.
- Masalah mendadak, sesuatu yang perlu diperbaiki.
- Hukum tak terduga.
- Dan banyak hal.
Yang paling tidak terduga adalah masalah kecepatan pengembang yang berbeda.
Untuk pengembang nyata dengan level yang sama dan dengan gaji yang sama, produktivitas dapat berbeda dalam urutan besarnya:
- Seseorang akan memotong dan men-debug kode selama seminggu, dan seseorang akan mengacaukan perpustakaan yang terbuka dalam setengah hari.
- Seseorang akan merokok Stack overflow, dan seseorang telah memecahkan masalah tersebut dan akan segera mulai mendapatkan keuntungan.
Akibatnya, Gaussian kami berubah menjadi seperti ini (perkiraan terlihat sama ketika tugas tidak berukuran cukup):
Secara umum, semuanya rumit, kami tidak menggali parit di sini. Bagaimana Anda dapat memperoleh nilai yang baik dalam kondisi seperti itu?
Kriteria nilai yang baik:
- Penilaian kecepatan tinggi - penilaian itu sendiri tidak membawa nilai bisnis apa pun, jadi logis untuk melakukannya secepat mungkin agar tidak teralihkan dari perkembangan.
- Evaluasi adalah tanggung jawab seluruh tim, dan ada prinsip "Anda menilai, Anda melakukannya" yang melindungi tim dari batas atas.
- Jangan lupa tentang semua komponen keluaran fitur dalam produksi - analitik, pengembangan, pengujian unit, pengujian otomatis, pengujian integrasi, devops. Semua ini harus dievaluasi.
Seperti yang Anda lihat, saya belum menulis apa pun tentang akurasi. Selama 15 tahun saya membuat perkiraan, saya belum belajar cara membuatnya secara akurat, jadi mari kita lebih sederhana dan mencoba untuk memperkirakan setidaknya kira-kira. Keseluruhan proses penilaian terlihat seperti ini:
- Menempatkan tugas ke dalam product backlog.
- Kami mengevaluasi cerita prioritas tertinggi di backlog menggunakan metode apa pun (ada banyak metode, saya akan menceritakannya di bawah).
- Kami mulai bekerja (misalnya, di Scrum - dengan sprint).
- Setelah beberapa sprint, kami mengukur berapa banyak poin cerita yang kami dapatkan rata-rata setiap iterasi. Ini adalah Kecepatan kami - kecepatan pengembangan tim rata-rata.
- . burndown chart. , .
Tetapi dunia ini tidak sempurna, jadi kami memperbaiki berapa banyak fitur baru (juga diperkirakan dalam poin cerita) Pemilik Produk kami menghasilkan setiap sprint. Garis merah akan menunjukkan pertumbuhan backlog, sekarang perpotongan garis merah dan biru adalah tanggal yang diinginkan.
Jika Pemilik Produk sangat kreatif, bahkan mungkin seperti ini:
Dan sekarang kita ingat bahwa penilaian tersebut mematuhi hukum distribusi normal, tetapi alur cerita - orang Gaussi seperti itu bertambah sempurna. Oleh karena itu, inilah yang ternyata (ini disebut grafik pembakaran yang ditingkatkan):
Tampaknya impian seorang matematikawan muda menjadi kenyataan: dari tumpukan kekacauan kami mendapatkan grafik yang indah dan dapat menyiarkan dengan tampilan yang cerdas bahwa " dengan probabilitas 50% kita akan menyelesaikan sprint 14, dengan probabilitas 80% di sprint ke-17, dari 95% - di sprint ke-19.
Ada sejumlah kendala dalam keseluruhan proses ini.
Pertama, saya akan segera mengatakan tentang gajah di dalam ruangan: backlognya besar, ada banyak tugas yang tidak diketahui kecuali deskripsi dalam format cerita pengguna, jadi perkiraannya akan sangat mendekati dalam hal apa pun . Saya telah menunjukkan di atas bagaimana perkiraan kasar terlihat dalam bahasa matematika.
Kedua, masalah "pengembang bekerja dengan produktivitas berbeda" pada prinsipnya tidak diselesaikan dengan cara apa pun ... Ini berarti bahwa kami mendapatkan peningkatan probabilitas yang sangat datar, yang tidak banyak membantu dalam membuat keputusan manajemen: “dengan probabilitas 50% kami akan menyelesaikan sprint ke-14, dengan probabilitas 80% - di sprint ke-27, dengan 95% - di 39 ”- jadi dalam bahasa matematika, itu terdengar seperti" jari ke langit. "
Oleh karena itu, saya pribadi memaksimalkan metrik "tingkat penilaian" dan sekarang saya akan memberi tahu Anda metode yang saya coba.
Metode perencanaan poker
Ini adalah salah satu teknik penilaian yang paling populer, mungkin karena ini yang paling tua.
- Peserta dalam proses menggunakan kartu yang diberi nomor khusus dengan angka Fibonacci.
- Pemilik Produk membuat pengumuman singkat tentang cerita selanjutnya dan menjawab pertanyaan dari tim.
- Setelah menerima informasi tersebut, peserta "poker" memilih kartu dengan penilaian yang sesuai, menurut pendapat mereka dan tidak menunjukkannya kepada siapa pun.
- Kemudian semua diungkapkan bersama, dan peserta dengan skor terendah dan tertinggi memberikan komentar singkat yang menjelaskan pilihan skor mereka.
- Sebagai hasil dari proses diskusi, tim sampai pada satu keputusan, dan kemudian melanjutkan ke cerita berikutnya.
Selama satu jam sesi dengan cara ini, Anda dapat mengevaluasi dari 4 hingga 8 cerita. Ini adalah masalah terbesar dengan metode ini - metode ini panjang, orang bosan dan teralihkan. Bukan tanpa alasan saya menggunakan ungkapan "semua diungkapkan bersama."
Metode "tatanan bangunan"
Ini adalah pendekatan yang kami gunakan saat ini di tempat kerja. Intinya adalah mengevaluasi tugas relatif satu sama lain. Beginilah urutan tugas yang diurutkan berdasarkan kesulitan dibangun. Untuk metode ini, Anda harus terlebih dahulu mengakumulasi kumpulan tugas yang dievaluasi dan menempatkannya pada skala.
- Saat waktunya untuk mengevaluasi, setiap anggota tim secara bergiliran membuat gerakan mereka (seperti dalam permainan papan). Langkah-langkahnya bisa sebagai berikut: letakkan tugas pada skala, pindahkan tugas di sepanjang skala, diskusikan cerita dengan rekan kerja, lewati langkah Anda.
- Akibatnya, tugas terus berpindah-pindah di papan, penilaian mereka relatif satu sama lain disempurnakan sampai diperoleh keadaan yang memuaskan seluruh tim.
- Saat semua peserta ketinggalan giliran, Anda sudah selesai.
Ini adalah teknik cepat. Dengan bantuannya, Anda dapat memperkirakan 15-20 lantai per jam, yang biasanya cukup.
Metode besar / kecil / tidak jelas
Saya telah menggunakannya beberapa kali, tetapi tidak berakar.
- Tiga zona ditandai di papan tulis: "tugas besar", "tugas kecil", dan "informasi tidak cukup".
- , «/». « » = « ».
- .
Metode ini memiliki nilai tambah yang besar - sangat cepat. Jadi, Anda dapat memproses 50 cerita pengguna per jam.
Di sini ada masalah dalam menerjemahkan perkiraan ini menjadi poin cerita, tetapi ketika kecepatan tim sudah diketahui, maka kami memahami berapa banyak poin cerita yang akan dikunyah seseorang per sprint di Jira dan mengevaluasi tugas-tugas kecil di sekitar metrik ini.
Adapun tugas-tugas lainnya. Saya mengirim tugas dari area "informasi tidak mencukupi" ke analitik, dan tugas dari "tugas besar" - ke dekomposisi, sehingga dapat dievaluasi ulang di sesi berikutnya.
Akibatnya, dalam produk kami, kami hanya menggambar peta jalan dengan fitur-fitur yang menurut kami akan memiliki waktu untuk menulis dalam waktu dekat. Jika kita tidak punya waktu - yah, itu terjadi. Dan kami menggunakan perkiraan hanya untuk tugas-tugas langsung, yang telah kami normalkan, dan bahkan kemudian, tidak selalu.
Mungkin saya terlibat dalam membuang ketidakmampuan saya di bidang penilaian dalam istilah pseudo-ilmiah, tetapi bagi saya pribadi, prosesnya sendiri terlihat agak bodoh, seperti kultus kargo aneh yang kami mainkan untuk berpura-pura bahwa kami sama stabil dan industri yang dapat diprediksi, seperti industri lain yang benar-benar stabil dan dapat diprediksi. Saya ingin sekali membaca tentang pengalaman Anda di bidang ini, mungkin saya melewatkan sesuatu.