Halo, Habr! Nama saya Artyom dan saya adalah pemimpin tim di Skyeng. Tim pengembangan saya memiliki pelanggan, dia adalah manajer produk, dia hanya Vanya. Vanya percaya bahwa skema penilaian kami tidak sempurna. Misalnya, nilai 2 hari tidak memberinya apa-apa. Dia akan melihat tugasnya dijual dalam seminggu atau 10 hari atau lebih. Atau kurang.
Ini bukan karena kami gagal dalam tugas, tetapi karena dengan Perkiraan tradisional, pada kenyataannya, kami hanya mengevaluasi waktu pengembang menulis kode. Tetapi ada juga pengujian dan review kode. Oke, kami akan memasukkan semuanya ke dalam penilaian. Tetapi juga:
- kami memiliki antrian sebelum pengembangan dan pengujian,
- ada peningkatan, kita bukannya tanpa dosa,
- tugas-tugas mendesak terbang masuk
- ketika implementasi memengaruhi beberapa layanan, kami mengharapkan ulasan dari tim terkait.
Bagaimana cara belajar menjawab pertanyaan "Kapan?" jika prediktabilitas tidak mungkin?
Bagaimana kami mempertanyakan Estimate
Tim kami, seperti banyak orang di perusahaan, memiliki pertemuan yang sangat berguna - tinjauan teknis (atau, singkatnya, ulasan teknologi ). Ini membutuhkan jumlah waktu dan upaya yang layak, tetapi menambah kemungkinan untuk diprediksi: kami menjadwalkan solusi teknis untuk masalah sebelumnya, dan pada saat yang sama mengevaluasinya.
Karena kita selalu berada di kejauhan, semuanya terjadi di JIRA: ada papan di mana tahapan pekerjaan divisualisasikan. Kartu meninggalkan status "Tinjauan Teknologi" dan beralih ke "Siap untuk dikembangkan" setelah kami menjelaskan dan mengevaluasi semuanya. Pada saat inilah kami berkomitmen untuk menyelesaikan pekerjaan.
"Ready for Development" memiliki batas WIP - tidak boleh ada lebih dari 8 tugas secara bersamaan. Ada aturan yang berlawanan: begitu tugas dalam kolom menjadi lebih sedikit, kami memulai tinjauan teknis baru.
Fakta: Kami menghabiskan banyak waktu untuk mengevaluasi. Tinjauan teknologi biasanya dilakukan dua kali seminggu, 4 tugas dengan penjabaran dan penilaian terperinci dapat berlangsung 1,5-3 jam. Tapi! Maka kita masih bisa meluangkan waktu untuk mencari tahu mengapa Estimate terlampaui.
Namun, peringkat atau tanya jawab tidak menambah nilai pada produk kami. Sebaliknya, kita membuang-buang waktu untuk mereka. Dan uang. Untuk waktu yang lama saya meragukan perlunya prosedur ini, dan pada satu titik saya jatuh tempo untuk percakapan serius dengan produk. Dan kami berdua mengenali masalahnya.
"Kemejanya kering dan sepenuhnya ..." bukan XS
Kami memutuskan: mari bereksperimen dengan pendekatan penilaian. Saya menyarankan fokus pada Ukuran T-Shirt - ukuran t-shirt digunakan sebagai unit pengukuran dalam teknik ini. Anda harus menemukan tugas terkecil yang harus Anda lakukan dan kesalahan untuk XS. Setelah itu, tugas yang tersisa dinilai berdasarkan "seberapa besar mereka XS" - dan, tergantung pada ini, mereka ditugaskan ukuran S, M, L atau XL.
Menyuap kesempatan untuk mengevaluasi "dengan mata". Idenya sederhana: kami akan mengumpulkan statistik tentang berapa banyak pengembangan yang dibutuhkan untuk menyelesaikan tugas satu dimensi atau yang lain, menghitung rata-rata dan dapat memprediksi waktu.
Kesalahan dalam satu atau dua hari akan dimaafkan oleh pelanggan - itu berarti tidak ada lagi pembekalan. Dan pada ulasan teknologi Anda tidak perlu membuang waktu untuk memilih interaktif dan rahasia. Semuanya lancar!
Kami telah bekerja dengan cara ini selama beberapa bulan, mengumpulkan statistik. Dan hanya Ivan yang menatap kami dengan curiga.
Ternyata XS, seperti S, kami melakukannya dalam 1 hari, lalu pada 10. Dan pada L kami menghabiskan 5 atau 15 hari. Karena pada kenyataannya, kami mengambil beberapa pekerjaan di tempat pertama, beberapa di tempat kedua, dan beberapa di tempat kelima - dan tugas dari dimensi yang sama menghabiskan waktu yang berbeda dalam status menunggu. Ups, ini rata-rata.
Singkatnya, pencar tidak ada di sini dalam beberapa hari - dan untuk Vanya, sedikit yang berubah. Kami mengakui eksperimen itu tidak berhasil, namun demikian, gagasan bahwa tugas-tugas tersebut dapat dikategorikan entah bagaimana diselesaikan di kepala saya. Dan saya mulai berpikir ke arah ini lebih jauh.
“Semua orang suka kue. Engah! " Keledai dari Shrek
Dan saya suka. Selain itu, ulang tahun anak-anak adalah acara yang menyenangkan! Saya pergi ke situs favorit saya dan mulai memilih:
- Anda bisa seperti itu, tetapi Anda tidak bisa,
- Anda bisa mendekorasi, tetapi Anda tidak bisa mendekorasi,
- bisa 2kg, tapi bisa 5kg.
Saya tidak akan mengungkapkan preferensi selera saya, tetapi saya memilih kue. Dan mereka membawanya ke tanggal yang ditentukan. Selanjutnya akan menjadi filosofi kue timlid makan berlebihan.
Tentu saja, saya bukan Newton, dan kue itu bukan sebuah apel, tetapi wawasan telah datang.
Saya dapat memilih dari banyak opsi, tetapi apa pun yang saya pilih, tanggal pengiriman tidak berubah. Saya membutuhkan kue dalam seminggu. Dan mereka siap memberikan layanan ini kepada saya. Dan ukuran kue, berat, dan segala macam lonceng dan peluit tidak mempengaruhi hasil akhir - lebih tepatnya, dalam hal ini, tidak mempengaruhi sama sekali. Ini bukan tentang ukurannya, seperti kata mereka. Dan apa? Dalam harga.
Misalnya, orang-orang memiliki pesanan kilat: dengan biaya tambahan, mereka akan membawakan saya kue mewah yang sama hanya dalam beberapa hari, dan tidak dalam 5. Pesanan saya, sebagai yang paling berharga dibandingkan dengan yang lain, akan keluar dari barisan. Pada dasarnya, toko roti memiliki dua SLA: satu untuk pesanan reguler dan satu untuk VIP. Ada sesuatu untuk dipikirkan.
Gagasan SLA dipicu karena saya membacanya di Panduan Kanban
Dari sudut pandang metode Kanban, semuanya adalah layanan. Dan terlepas dari kenyataan bahwa kami tidak menyediakan kue, dan produk kami tidak dapat dirasakan atau dimakan, pengembangan juga merupakan layanan. Dan kami juga memiliki sikap berbeda terhadap tugas.
Mari kita ingat papan kami:
Layanan ini terdiri dari beberapa tahap (pengembangan, tinjauan kode, pengujian), dan kolom "Siap untuk dikembangkan" adalah titik komitmen kami kepada pelanggan.
Kami melakukan beberapa hal dalam ritme yang biasa kami lakukan, tetapi ketika tugas yang berat tiba, kami meninggalkan semuanya. Masih memahami apa yang kita miliki SLA - dan akan mungkin untuk menyimpulkan kesepakatan dengan Vanya.
Cara mengevaluasi SLA tim Anda: membangun diagram spektral (mudah)
Untuk memahami kelas layanan apa yang kami miliki dan SLA apa yang mereka miliki, Kanban menyarankan untuk membangun grafik berikut:
- Lead Time (LT) — . « » «».
- Y — LT1, LT2, LT3 ..
Kami mengambil tugas yang ditutup selama beberapa bulan terakhir dan menerima yang berikut:
Kami menutup 3 tugas dalam sehari, 6 dalam dua, paling utama dalam 5, dan di suatu tempat kami telah berjuang dengan tugas selama lebih dari dua minggu ...
Nah, sekarang saatnya untuk menganalisis. Apa tugas-tugas ini? Mengapa mereka berakhir di sini? Mengapa kita melakukan lebih banyak dalam LT tertentu daripada yang lain, apa yang ada di sana? Anda dapat menggali pelanggan dan pemain, serta mempelajari komentar untuk tugas tersebut.
Inilah yang berhasil kami temukan. Ini adalah pekerjaan rutin kami .
Spreadnya cukup besar, tetapi bisa dianalisis.
Secara umum, sebagian besar tugas didistribusikan dalam interval 7-14 hari, dan pasangan terbang sangat jauh - di ekor ini ada beberapa tugas (tidak semua) dari PR ke layanan lain. Tugas-tugas yang diselesaikan dalam 3-4 hari lebih cenderung merupakan pengecualian daripada aturan.
, , , 75% 10 .
Dan dengan probabilitas 90%, itu akan memakan waktu 14 hari. Nah, jika pengembangan memengaruhi layanan lain dari perusahaan, Anda harus menunggu sedikit lebih lama - kita perlu peninjauan kode dari tim lain dan kemudian penerapan lain.
Mari kita melangkah lebih jauh. Kami menyebut kelas ini "Penting . "
Untuk beberapa alasan, tugas-tugas ini diambil untuk bekerja lebih awal daripada yang lain: ada lebih banyak nilai atau biaya penundaan lebih tinggi.
Dan di sini kita juga bisa menyuarakan SLA: dengan probabilitas 75%, tugas akan dijual dalam 5 hari, dengan probabilitas 90% dalam 7. Mari kita lanjutkan?
Tugas-tugas dimana kita menyerahkan segalanya dan melihat, melihat, melihat adalah penghalang .
Dalam 100% kasus, ini adalah peningkatan kecil yang tidak kami perhitungkan saat menerapkan fitur utama, atau bug yang memengaruhi fungsionalitas vital dalam produksi.
Terlepas dari kenyataan bahwa kami berhasil menyelesaikan semua situasi seperti itu dalam 2 hari, kami masih akan mengumumkan persentil ke-90. Pertama, Anda tidak harus berjanji 100% - tidak pernah kepada siapa pun :) Kedua, Anda perlu meletakkan variabilitas: ingat kasus pekerjaan reguler, ketika beberapa tugas terbang dalam 20 + hari, karena ada ketergantungan pada tim lain.
Selesai! Kami dapat menyetujui Vanya pada SLA untuk semua kelas layanan:
Kami telah memilih tepat 90% dalam hal persyaratan - ini, pada kenyataannya, adalah toleransi pelanggan untuk ketidakpatuhan. Artinya, jika 1 dari 10 tugas tidak sesuai dengan SLA, kami siap memaafkannya.
Jika pelanggan Anda tidak begitu baik, lebih baik menyuarakan persentil ke-95, misalnya.
Alih-alih sebuah kesimpulan
- Dan apa yang mencegah Vanya dari mendapatkan hanya tugas-tugas penting atau pemblokir?
- Batas WIP Horizontal.
Kami menyetujui batasan jumlah tugas di kelas layanan: Anda tidak dapat mengambil lebih dari dua pemblokir, Anda tidak dapat mengambil lebih dari dua tugas penting. Anda mungkin memiliki nomor lain - ini adalah masalah perjanjian dengan pelanggan. Anda tidak dapat menetapkan batas seperti itu di JIRA tanpa plugin, sehingga perjanjian verbal sangat diperlukan. Alat alat, tetapi tanpa interaksi dengan orang di mana pun.
Terima kasih atas perhatian dan perencanaan Anda yang sukses!