Di perusahaan saya, satu tugas tidak pernah dapat diselesaikan oleh satu orang. Akan ada orang yang terpisah untuk QA dan Peninjauan Kode setiap tugas. Artinya, setiap individu akan memberikan perkiraan, per tugas, berapa banyak waktu yang dibutuhkan untuk menyelesaikannya.

Masalahnya adalah, bagaimana saya harus mendekati membakar? Jika saya menjumlahkan jam bersama, anggaplah perkiraan berikut:

10 jam - Waktu dev

4 jam - QA

4 jam - Tinjauan Kode.

Perkiraan Tugas = 18 jam

Pada akhir setiap hari saya meminta agar tugas diperbarui dengan "berapa banyak waktu yang tersisa sampai selesai". Namun, setiap orang umumnya hanya memikirkan bagian mereka saja. Haruskah mereka menandai upaya yang tersisa, dan kemudian ADD memperkirakan upaya itu? Bagaimana kalian melakukan ini?

MEMPERBARUI

Untuk membantu memperjelas beberapa hal, di organisasi saya setiap Tugas dalam sebuah cerita membutuhkan 3 orang.

1. Seseorang untuk mengembangkan tugas. (lakukan tes unit, dll ...)
2. Seorang spesialis QA untuk meninjau tugas (mereka terutama melakukan tes integrasi dan regresi)
3. Petunjuk teknis untuk melakukan tinjauan kode.

Saya tidak berpikir ada cara yang salah atau cara yang benar, tetapi ini adalah cara kita ... dan itu tidak akan berubah. Kami bekerja sebagai tim untuk menyelesaikan bahkan tingkat terkecil dari sebuah cerita bila memungkinkan. Anda tidak dapat benar-benar menguji apakah sesuatu berfungsi sampai dev selesai, dan Anda tidak dapat meninjau kualitas kode juga ... jadi yang terbaik yang dapat Anda lakukan adalah membagi beberapa hal menjadi irisan logis kecil sehingga fungsi minimum yang telanjang dapat diuji dan ditinjau sedini mungkin dalam proses.

Pertanyaan saya kepada mereka yang bekerja dengan cara ini adalah bagaimana membakar "tugas" ketika mereka diatur dengan cara ini. Kecuali jika Tugas memiliki sub tugas sendiri (yang tidak diizinkan JIRA) ... Saya tidak yakin cara terbaik untuk menyelesaikan pelacakan "apa yang tersisa" setiap hari.

Itu adalah 3 tugas, bukan satu.

Mungkin satu fitur / cerita, tetapi ini adalah tiga tugas. Satu tugas dapat diselesaikan oleh satu orang dalam waktu terbatas.

TL; DR

Anda menggunakan pembakaran yang salah dalam beberapa cara. Tugas dan cerita dilakukan atau tidak dilakukan; dengan mencoba melacak penyimpangan dari perkiraan perencanaan berbasis waktu di burn-down Anda, Anda sebenarnya memperkirakan ulang jadwal Anda daripada memperkirakan sisa produk kerja.

Di Scrum, Anda harus mengukur kemajuan menuju Tujuan Sprint daripada mengukur kotak waktu Sprint. Ini menjaga fokus pada kapasitas tim dan pengiriman fitur daripada pada penyesuaian penjadwalan berkelanjutan.

Tugas vs. Cerita

Anda menggabungkan tugas dan cerita. Cerita terdiri dari semua tugas yang diperlukan untuk menyelesaikan cerita sesuai "definisi selesai" tim Anda. Kisah ini dianggap 100% tidak lengkap kecuali semua tugasnya selesai. Dalam Scrum, cerita selalu diperkirakan dengan cara tertentu; paling sering, mereka diperkirakan dalam poin cerita.

Tugas adalah langkah atau tonggak yang diperlukan untuk menyelesaikan cerita. Meskipun setiap tugas mungkin memiliki dependensi dan prasyarat, Anda tentu dapat mengatakan bahwa tinjauan kode selesai atau tidak, terlepas dari tugas lainnya.

Terbakar

Di Scrum, bagan burn-down Anda menunjukkan jumlah pekerjaan yang tersisa untuk sprint atau proyek. Grafik burn-down yang nyata seringkali memiliki dataran tinggi; dalam beberapa kasus, grafik bahkan dapat naik. Misalnya, pada sprint satu minggu dengan dua cerita bernilai 3 dan 5 poin, poin data Anda mungkin terlihat seperti ini:

Mon | Tue | Wed | Thu | Fri
--- | --- | --- | --- | ---
 8  |  5  |  5  |  5  |  0

Dalam skenario idealis ini, Anda mulai dengan 8 poin cerita. Cerita 3 poin selesai Selasa sore, sementara cerita 5 poin tidak selesai sampai Jumat. Poin cerita tidak dikurangkan dari burn-down sampai cerita telah memenuhi definisi selesai. Jika Anda menggunakan jam yang ideal alih-alih poin cerita, satu-satunya hal yang berubah adalah skala Anda.

Time-Boxing

Praktik yang diterima secara umum adalah untuk memastikan bahwa tugas Anda didekomposisi menjadi potongan berukuran gigitan antara 1/2 hari dan 2 hari. Varian lebih dari satu hari harus jelas dari stand-up harian atau Sprint Backlog; seharusnya tidak perlu melakukan tarikan status formal.

Anda juga dapat melakukan analisis statistik pada grafik burn-down untuk menentukan apakah sprint Anda sedang trending dengan benar. Penyimpangan kecil atau dataran tinggi adalah normal, tetapi jika tidak ada yang menaikkan blocker di stand-up harian tetapi burn-down Anda tampaknya macet, itu umumnya merupakan tanda bahwa Sprint Backlog telah salah perkiraan atau ada "pekerjaan tak terlihat" yang perlu dibuat eksplisit dalam proses Anda.

Bisakah Anda mendefinisikan tugas dev sebagai "selesai" sebelum QA melakukan bagian mereka? Bisakah Anda mendefinisikan ulasan kode sebagai "selesai" sebelum dev dilakukan? Bisakah QA "diselesaikan" jika dev dan review kode tidak?

Saya akan mengatakan bahwa Anda harus menggabungkan tiga item menjadi satu tugas dan tiga orang harus bekerja sama untuk itu.

Scrum TIDAK mengatakan bahwa barang apa pun adalah tanggung jawab salah satu anggota tim. Justru sebaliknya - item sprint log adalah tanggung jawab TIM. Jika dibutuhkan tiga orang untuk melakukan tugas, maka itulah yang diperlukan.

Itu tidak masalah. Selama itu relatif konsisten di seluruh cerita, bagan burndown Anda akan tetap berfungsi baik. Gunakan cara apa pun yang paling alami bagi tim Anda untuk melaporkan.

Tim saya sebenarnya melakukan semacam hibrida, meskipun tidak dengan persetujuan formal. Kami menempatkan 16 jam jika kami pikir tugas akan memakan waktu satu orang dua hari, tetapi jika dua orang akhirnya mengerjakannya bersama, kami tidak mengubahnya.

Setelah perkiraan awal, secara informal menjadi lebih dari satu persen selesai untuk tim kami daripada satu jam tersisa. Jika awalnya kami pikir itu akan memakan waktu dua hari, tetapi setelah satu hari, kami pikir itu hanya 25% selesai, kami mengambil 4 dari 16 jam asli. Itu berarti 12 jam di mana secara teknis kami memperkirakan 24, karena kami mungkin akan mengurangi 4 jam selama 3 hari tersisa.

Itu mengganggu saya sebagai master scrum pada awalnya, tetapi aneh karena tampaknya, itu adalah cara yang sangat alami untuk memberikan perkiraan, karena pengembang benar-benar benci menambahkan jam pada perkiraan. Semuanya rata-rata untuk membuat pembakaran masih bermanfaat, dan itulah yang penting.

Waktu yang tersisa untuk tugas tidak terlalu menjadi masalah: tidak ada yang dapat disampaikan hingga keseluruhan cerita selesai.

Jika Anda ingin melacak berapa banyak waktu yang tersisa pada sebuah cerita (keseluruhan) dengan meminta orang mengisi waktu yang tersisa untuk suatu tugas, maka bagi tugas-tugas per orang.

Yang mengatakan:

• Tugas besar mungkin menjadi indikasi cerita Anda terlalu besar. Dalam hal ini, solusi terbaik adalah mengurangi ruang lingkup dan ukuran cerita, dan jika Anda menguranginya cukup melacak sisa waktu pada tugas tidak masalah lagi (baik sudah selesai atau belum - jumlah perkiraan untuk tugas yang belum selesai cukup granular).
• SCRUM mendorong semua orang untuk mengambil apa yang perlu dilakukan. Jika Anda memberikan tugas kepada orang-orang (sebagai lawan dari peran), maka Anda berpotensi mencegah diri Anda untuk menyampaikan berita, bahkan jika pengembang tidak melakukan apa pun - karena QA mengalami kemacetan.

Bagilah tugas menjadi beberapa tugas dan masukkan sebagai tugas di mana masing-masing ditangani oleh orang yang berbeda.

Tugas Asli: Perbaiki sesuatu

Tugas Baru: (anak dari orang tua dari tugas asli)

• Dev A - Memperbaiki masalah
• Dev B - Membantu Dev A dalam memperbaiki masalah (mis. Pemrograman pasangan, ulasan kode)
• Dev A - dev menguji perbaikan menggunakan Dataset X
• Dev B - dev menguji perbaikan menggunakan Dataset Y