Bahasa Melayu

Perancangan Sprint: Cara Menjalankan Mesyuarat Perancangan Sprint yang Berkesan

Rajah agenda mesyuarat perancangan Sprint

Perancangan Sprint ialah acara yang mengubah Backlog idea menjadi pelan yang jelas dan berkomitmen yang sebenarnya boleh dilaksanakan oleh pasukan. Jika dilakukan dengan baik, ia mengambil masa kurang dua jam dan meninggalkan pasukan dengan semangat. Jika dilakukan dengan buruk, ia melanjut hingga petang dan menghasilkan senarai yang tiada sesiapa percaya.

Apakah perancangan Sprint?

Perancangan Sprint ialah acara terikat masa dalam Scrum di mana pasukan pembangunan, Product Owner, dan Scrum Master bertemu pada permulaan setiap Sprint untuk memutuskan kerja apa yang akan mereka siapkan dan bagaimana cara melakukannya. Mesyuarat menghasilkan dua output: matlamat Sprint (the "mengapa") dan Backlog Sprint (item khusus yang dipilih oleh pasukan untuk memenuhi matlamat tersebut).

Perancangan Sprint berada dalam rangka kerja metodologi Agile yang lebih luas. Sprint ialah kitaran pendek panjang tetap (biasanya satu hingga empat minggu) yang memberikan pasukan rentak tetap untuk menghantar perisian yang berfungsi atau peningkatan kerja yang siap. Perancangan Sprint adalah cara setiap kitaran bermula dengan niat berbanding andaian.

Panduan Scrum mentakrifkan dua soalan teras untuk setiap sesi perancangan Sprint: apa yang boleh dihantar dari Product Backlog semasa Sprint ini, dan bagaimana kerja yang dipilih akan diselesaikan? Dua soalan tersebut dipetakan terus kepada dua bahagian mesyuarat, yang komuniti Scrum sering menyebutnya "Bahagian 1: Apa" dan "Bahagian 2: Bagaimana."

Mesyuarat perancangan Sprint yang dikendalikan dengan baik adalah spesifik tentang skop, jujur tentang kapasiti, dan berasaskan matlamat Sprint yang memberikan pasukan satu titik tumpuan untuk dua minggu seterusnya.

Fakta Utama

  • Panduan Scrum memperuntukkan sehingga 8 jam untuk perancangan Sprint dalam Sprint 1 bulan, diskala secara berkadar untuk Sprint yang lebih pendek (Panduan Scrum, 2020).
  • Pasukan yang menetapkan matlamat Sprint yang jelas adalah 2.5x lebih berkemungkinan untuk menyerahkan komitmen Sprint penuh (Laporan Keadaan Agile Edisi ke-17, 2024).
  • Perancangan Sprint menggunakan kira-kira 5% daripada waktu kerja Sprint 2 minggu apabila dijalankan dengan cekap (data komuniti Scrum.org, 2024).

Mengapa perancangan Sprint penting

Tanpa perancangan Sprint, pasukan kembali kepada keutamaan secara ad hoc. Kerja diambil berdasarkan siapa yang bertanya paling kuat, bukan apa yang paling penting. Perancangan Sprint memutuskan corak tersebut dengan mewujudkan komitmen bersama sebelum kerja bermula, bukan selepasnya.

Manfaatnya kelihatan dengan cara yang boleh diukur. Pasukan dengan matlamat Sprint yang jelas mempunyai lebih sedikit perubahan arah di pertengahan Sprint kerana semua orang sudah bersetuju tentang seperti apa "selesai" dalam kitaran ini. Perancangan kapasiti (dilakukan dengan betul semasa perancangan Sprint) menghalang pasukan daripada berkomitmen terlalu banyak, yang merupakan punca tunggal terbesar kegagalan Sprint. Dan ritual itu sendiri membina keselamatan psikologi: apabila pasukan berkomitmen bersama, mereka lebih berkemungkinan untuk membangkitkan halangan lebih awal berbanding menyembunyikannya hingga hari terakhir.

Perancangan Sprint juga mewujudkan hubungan langsung antara kerja harian dan Roadmap produk. Setiap matlamat Sprint harus dipetakan kepada objektif strategik yang lebih besar. Apabila pasukan melihat hubungan tersebut dinyatakan secara eksplisit pada permulaan setiap Sprint, kerja terasa kurang seperti senarai tugas dan lebih seperti kemajuan.

Bagi pasukan yang beralih daripada metodologi Waterfall, perancangan Sprint sering menjadi bukti paling jelas bahawa penghantaran Agile berfungsi secara berbeza. Berbanding pelan enam bulan yang diturunkan dari atas, pasukan membentuk dua minggu seterusnya sendiri, dengan keterlihatan penuh tentang apa yang mereka persetujui.

Dua bahagian perancangan Sprint

Panduan Scrum menstrukturkan perancangan Sprint kepada dua perbualan yang berbeza. Kebanyakan mesyuarat perancangan Sprint yang gagal runtuh kerana pasukan terus ke Bahagian 2 sebelum Bahagian 1 benar-benar diselesaikan.

Bahagian 1: Apa yang akan kita lakukan? (matlamat Sprint dan pemilihan item)

Product Owner membentangkan item teratas dari Product Backlog yang diutamakan. Pasukan bertanya soalan tentang skop, kriteria penerimaan, dan kebergantungan. Bersama-sama, mereka merangka matlamat Sprint: kenyataan tunggal yang ringkas tentang apa yang Sprint ini perlu capai dari perspektif pihak berkepentingan. Setelah matlamat ditetapkan, pasukan memilih Item Product Backlog (PBI) yang, jika diselesaikan, akan mencapainya.

Bahagian 1 selesai apabila pasukan bersetuju dengan matlamat Sprint dan mempunyai senarai calon item. Itu sahaja. Jangan teruskan sehingga kedua-dua output tersebut wujud.

Bahagian 2: Bagaimana kita akan melakukannya? (penguraian tugas dan semakan kapasiti)

Dengan item yang dipilih di atas meja, pasukan memecahkan setiap satu kepada tugas konkrit (biasanya setengah hingga dua hari usaha setiap satu). Di sinilah perancangan kapasiti berlaku: pasukan menyemak sama ada tugas-tugas itu sesuai dalam jam atau mata cerita Sprint yang tersedia berdasarkan ketersediaan sebenar mereka. Item yang tidak sesuai dikembalikan ke Backlog.

Bahagian 2 menghasilkan Backlog Sprint: matlamat Sprint ditambah item yang dipilih ditambah pecahan tugas. Ini adalah pelan operasi pasukan untuk Sprint seterusnya.

Agenda perancangan Sprint (mesyuarat 2 jam)

Aliran mesyuarat perancangan Sprint dua bahagian

Jadual di bawah menunjukkan agenda dua jam untuk Sprint dua minggu. Skala masa secara berkadar untuk Sprint yang lebih pendek atau lebih panjang.

Blok masa Aktiviti Output
0:00 hingga 0:10 Scrum Master membuka: ringkasan Sprint lepas, rujukan Velocity, dan kapasiti yang tersedia Pasukan selaras dengan konteks
0:10 hingga 0:40 Product Owner membentangkan item Backlog teratas; pasukan bertanya soalan penjelasan Pemahaman bersama tentang 8-12 item teratas
0:40 hingga 1:00 Pasukan merangka matlamat Sprint secara kolaboratif Matlamat Sprint dipersetujui dan ditulis
1:00 hingga 1:10 Pasukan memilih PBI yang dipetakan kepada matlamat Sprint Backlog Sprint calon (apa)
1:10 hingga 1:45 Pasukan menguraikan item yang dipilih kepada tugas; semakan kapasiti berbanding mata yang tersedia Senarai tugas, disesuaikan untuk sesuai dengan kapasiti
1:45 hingga 2:00 Pasukan berkomitmen; Scrum Master merekod Backlog Sprint; soalan terbuka dilog Backlog Sprint yang berkomitmen

Jika mesyuarat melampaui dua jam untuk Sprint dua minggu, hentikan dan buat diagnosis. Punca biasa: item Backlog tidak diperhalusi sebelum mesyuarat, matlamat Sprint tidak dipersetujui sebelum beralih ke pemilihan item, atau terlalu banyak item yang tidak ditentukan dengan jelas.

Cara menjalankan mesyuarat perancangan Sprint: langkah demi langkah

Langkah 1: Kira kapasiti sebelum mesyuarat bermula

Sebelum sesiapa duduk, Scrum Master (atau sesiapa yang memudahkan) mengira kapasiti yang tersedia untuk pasukan bagi Sprint. Ini bukan "semua orang bekerja 10 hari jadi kita mempunyai kapasiti 10 hari setiap orang." Ia mengambil kira mesyuarat, cuti, tugas siap sedia, dan faktor fokus (peratusan realistik masa yang dihabiskan untuk kerja Sprint berbanding gangguan).

Jadual kapasiti ringkas (dibincangkan secara mendalam dalam bahagian seterusnya) mengambil masa lima minit untuk dibina dan menjimatkan empat puluh minit perdebatan di pertengahan mesyuarat.

Langkah 2: Sahkan item Backlog memenuhi definisi sedia

Sebelum item boleh dipilih untuk Sprint, mereka perlu lulus definisi sedia (DoR). DoR ialah senarai semak yang ditakrifkan oleh pasukan yang perlu dipenuhi oleh item Backlog sebelum perancangan Sprint. Kriteria biasa termasuk:

  • Kriteria penerimaan ditulis dan difahami oleh pasukan
  • Kebergantungan dikenal pasti dan tidak disekat (atau risiko diketahui)
  • Item dianggar (mata cerita atau saiz t-shirt)
  • Tiada item tunggal merentasi lebih daripada separuh panjang Sprint

Item yang gagal DoR ditanda dalam Backlog dan diserahkan kembali kepada Product Owner untuk pemurnian. Jangan bawa mereka ke dalam Sprint.

Langkah 3: Rangka matlamat Sprint bersama-sama

Product Owner mencadangkan draf matlamat Sprint. Pasukan memperhalusi bahasa sehingga ia mencerminkan apa yang pasukan sebenarnya sedang membina, bukan hanya apa yang perniagaan ingin lihat. Matlamat Sprint yang baik adalah:

  • Cukup spesifik untuk boleh disangkal (Anda boleh memberitahu pada penghujung Sprint sama ada Anda mencapainya)
  • Cukup fleksibel untuk membenarkan beberapa PBI ditukar jika sesuatu yang tidak dijangka muncul
  • Satu benang (satu matlamat setiap Sprint; pelbagai matlamat melemahkan fokus)

Contoh matlamat Sprint yang lemah: "Perbaiki aliran Onboarding." Contoh matlamat Sprint yang kuat: "Pengguna baharu boleh mengaktifkan akaun mereka dan menyelesaikan tindakan utama pertama mereka tanpa menghubungi sokongan."

Langkah 4: Pilih Item Product Backlog

Dengan matlamat Sprint yang dipersetujui, pasukan memilih PBI dari bahagian atas Backlog yang paling menyokong matlamat. Ini adalah perbualan, bukan muat turun: pasukan bertanya soalan, berunding tentang skop, dan kadangkala membahagikan item besar kepada item yang lebih kecil untuk muat dalam Sprint.

Gunakan Velocity (purata mata cerita yang diselesaikan oleh pasukan setiap Sprint selama tiga hingga lima Sprint terakhir) sebagai siling untuk pemilihan. Jangan pilih lebih daripada Velocity. Jika pasukan telah purata 32 mata setiap Sprint, jangan muatkan 45.

Langkah 5: Uraikan item kepada tugas

Untuk setiap PBI yang dipilih, pasukan menyenaraikan tugas konkrit yang diperlukan untuk memenuhi kriteria penerimaan. Tugas perlu cukup kecil supaya kemajuan kelihatan setiap hari (kira-kira 0.5 hingga 2 hari setiap satu). Penguraian ini juga mendedahkan kerumitan tersembunyi: kisah yang kelihatan seperti 3 mata kadangkala mendedahkan lima tugas dengan anggaran gabungan yang jauh lebih tinggi.

Jika senarai tugas kisah menolaknya jauh melebihi anggaran asal, pasukan boleh menganggar semula, membahagikan kisah, atau mengembalikannya ke Backlog. Lebih baik membuat keputusan itu sekarang berbanding pada hari kelapan Sprint.

Langkah 6: Komitmen dan tutup

Pasukan melakukan semakan kapasiti akhir: jumlah anggaran usaha tugas berbanding kapasiti Sprint yang tersedia. Jika sesuai, pasukan berkomitmen. Jika tidak, item keluar (tidak pernah masuk). Scrum Master menulis Backlog Sprint dan merekod sebarang soalan terbuka atau kebergantungan yang memerlukan tindak lanjut pada hari pertama.

Komitmen di sini tidak bermakna kontrak. Ia bermakna pasukan benar-benar percaya item ini boleh dicapai berdasarkan apa yang mereka tahu sekarang. Perbezaan tersebut penting, terutamanya dalam pasukan yang telah terbakar oleh janji berlebihan.

Perancangan kapasiti: matematik

Contoh pengiraan kapasiti Sprint dengan ketersediaan pasukan dan faktor fokus

Perancangan kapasiti adalah aritmetik mudah, tetapi mudah silap jika Anda melangkau faktor fokus.

Formula:

Kapasiti yang Tersedia (mata) = Hari Tersedia x Faktor Fokus x Mata setiap Hari

Faktor fokus mewakili pecahan realistik setiap hari bekerja yang dihabiskan untuk kerja Sprint (berbanding mesyuarat, e-mel, tiket sokongan, dan gangguan lain). Bagi kebanyakan pasukan ia berjalan antara 0.6 dan 0.8. Pasukan baharu atau pasukan dengan beban sokongan yang tinggi cenderung ke arah hujung yang lebih rendah.

Contoh jadual kapasiti untuk Sprint 2 minggu (10 hari bekerja):

Ahli pasukan Hari tersedia Faktor fokus Kapasiti (mata)
Alex (Pembangun) 8 0.7 14
Sam (Pembangun) 9 0.6 13
Priya (Pembangun) 7 0.8 14
Jordan (Kawalan Kualiti) 10 0.6 12
Jumlah 34 53 mata

Dalam contoh ini siling Velocity pasukan ialah 53 mata cerita. Jika Velocity sejarah pasukan ialah 40 mata, gunakan 40 sebagai siling praktikal: Velocity mengambil kira kerja yang tersangkut atau lebih kompleks daripada yang dijangkakan walaupun orang tersedia.

Jangan pernah gunakan hari bekerja mentah sebagai proksi untuk kapasiti. Pasukan lima pembangun yang masing-masing bekerja 10 hari tidak mempunyai 50 hari kapasiti Sprint. Faktor fokus wujud untuk menjadikan perancangan jujur.

Contoh perancangan Sprint mengikut jenis pasukan

Jenis pasukan Contoh matlamat Sprint Item Backlog biasa Nota kapasiti
Pasukan kejuruteraan "Pengguna boleh menetapkan semula kata laluan mereka tanpa menghubungi sokongan" Kemas kini perkhidmatan pengesahan, templat e-mel, kes ujian kawalan kualiti, dokumentasi Sertakan hari giliran siap sedia sebagai tidak tersedia
Pasukan pemasaran "Aset kempen siap untuk go-live pelancaran S3" Kelulusan salinan, final reka bentuk, pembinaan halaman pendaratan, persediaan UTM Ambil kira pusingan semakan agensi sebagai pengguna kapasiti
Pasukan reka bentuk "Aliran pembayaran mudah alih diuji dan diserahkan kepada pembangunan" Sintesis penyelidikan pengguna, wireframe v2, prototaip, ujian kegunaan Faktorkan jurang penjadualan peserta sebagai hari melahu
Pasukan kejayaan pelanggan "Buku panduan Onboarding merangkumi 5 jenis tiket sokongan teratas" Draf buku panduan, semakan SME, artikel pangkalan pengetahuan, latihan pasukan Kakitangan CS kanan sering dibahagikan antara kerja Sprint dan akaun aktif

Pendekatan struktur pecahan kerja berfungsi dengan baik untuk memecahkan item Sprint besar kepada komponen peringkat tugas, terutamanya untuk pasukan kejuruteraan dan reka bentuk di mana kisah mempunyai berbilang sub-tugas teknikal.

Kesilapan perancangan Sprint biasa (dan pembetulan)

Kesilapan Mengapa berlaku Pembetulan
Melangkau pemurnian Backlog sebelum perancangan Sprint Pasukan menganggap perancangan Sprint sebagai satu-satunya sesi pemurnian Jalankan sesi pemurnian berasingan di pertengahan Sprint; perancangan Sprint harus memperhalusi, bukan memperkenalkan
Tiada matlamat Sprint, hanya senarai tugas Pasukan melihat matlamat sebagai formaliti Rangka matlamat dahulu, sebelum sebarang pemilihan item; gunakannya sebagai penapis pemilihan
Memilih item berdasarkan naluri, mengabaikan Velocity Berat sebelah optimisme; tekanan daripada pihak berkepentingan untuk mengambil lebih banyak Paparkan purata Velocity 3 Sprint terakhir pada permulaan perancangan; anggapkannya sebagai siling, bukan sasaran
Menguraikan kepada tugas dalam Bahagian 1 Ketidaksabaran untuk sampai kepada "kerja sebenar" Simpan perbincangan Bahagian 1 pada peringkat kisah/kriteria penerimaan; simpan tugas untuk Bahagian 2
Membiarkan suara paling kuat mendominasi pemilihan item Dinamik kuasa dalam bilik Gunakan pengundian senyap atau pengundian titik untuk perselisihan keutamaan item
Tidak merekod soalan terbuka Tekanan masa pada penghujung mesyuarat Simpan dokumen bersama terbuka semasa mesyuarat; rekod soalan secara masa nyata
Menganggap komitmen sebagai kontrak prestasi Budaya pengurusan yang menghukum kesilapan Bezakan ramalan daripada komitmen dalam retrospektif; raikan penskopan semula yang jujur

Amalan terbaik perancangan Sprint

  • Hadkan masa dan hormatinya. Sprint dua minggu mendapat mesyuarat perancangan dua jam. Apabila mesyuarat melanjut, ia menandakan masalah proses (Backlog yang kurang diperhalusi, matlamat yang tidak jelas), bukan masalah beban kerja.
  • Perhalusi Backlog sebelum perancangan Sprint. Mesyuarat perancangan Sprint terbaik terasa hampir terlalu mudah kerana item sudah difahami dengan baik. Jalankan sesi pemurnian di pertengahan Sprint untuk pra-jaga 10 hingga 15 item teratas.
  • Tulis matlamat Sprint di dinding (atau dalam dokumen bersama). Matlamat yang hanya ada dalam ingatan seseorang berhenti membimbing keputusan menjelang hari ketiga. Letakkan di suatu tempat yang dilihat oleh seluruh pasukan setiap hari.
  • Gunakan skala anggaran yang konsisten. Sama ada Anda menggunakan mata cerita, saiz t-shirt, atau hari ideal, pilih satu dan kekalkan merentasi Sprint supaya perbandingan Velocity kekal bermakna.
  • Sertakan keseluruhan pasukan Scrum, tiada orang lain. Perancangan Sprint adalah untuk Product Owner, Scrum Master, dan pasukan pembangunan. Pihak berkepentingan, pengurus, dan eksekutif bukan peserta. Input mereka perlu tiba melalui Backlog, bukan mesyuarat.
  • Mulakan dengan kanta kitar hayat projek untuk aliran baharu. Bagi pasukan yang memulakan produk atau inisiatif baharu, mendasarkan matlamat Sprint pertama dalam kitar hayat projek yang lebih luas membantu pasukan memahami bagaimana Sprint ini berhubung dengan lengkungan penghantaran.
  • Bincang dalam retrospektif. Jika pasukan secara konsisten terlepas matlamat Sprint, itu adalah masalah perancangan Sprint. Retrospektif harus mengkaji ketepatan perancangan bersama prestasi penghantaran.
  • Latih silang tentang perdagangan Scrum vs Kanban. Pasukan yang memahami kedua-dua kaedah membuat keputusan perancangan Sprint yang lebih baik, terutamanya apabila mereka memutuskan sama ada struktur Sprint adalah padanan yang betul untuk jenis kerja mereka.

Soalan lazim

Berapa lama perancangan Sprint sepatutnya?

Panduan Scrum menetapkan maksimum 8 jam untuk Sprint satu bulan, diskala secara berkadar untuk Sprint yang lebih pendek. Untuk Sprint dua minggu, itu bermakna maksimum 4 jam, walaupun pasukan yang bersedia dengan baik secara rutin selesai dalam 2 jam atau kurang. Jika perancangan Sprint Anda secara konsisten berjalan lama, puncanya hampir selalu Backlog yang kurang diperhalusi atau matlamat Sprint yang pasukan belum selaras sebelum mesyuarat bermula.

Apakah definisi sedia?

Definisi sedia (DoR) ialah senarai semak yang ditakrifkan oleh pasukan yang mesti dipenuhi oleh Item Product Backlog sebelum ia layak untuk perancangan Sprint. Kriteria DoR biasa termasuk kriteria penerimaan yang ditulis, anggaran mata cerita, kebergantungan yang dikenal pasti, dan skop yang cukup kecil untuk sesuai dalam satu Sprint. DoR bukan konsep Panduan Scrum tetapi amalan yang diterima pakai secara meluas yang menghalang pasukan daripada menarik kisah yang benar-benar belum sedia untuk dikerjakan. Pasukan bersetuju tentang DoR mereka dalam retrospektif dan mengemas kininya apabila mereka belajar.

Siapa yang menghadiri perancangan Sprint?

Peserta yang diperlukan ialah Product Owner, Scrum Master, dan pasukan pembangunan penuh. Product Owner membentangkan dan mengutamakan item Backlog; pasukan pembangunan bertanya soalan, menganggar, dan memilih item; Scrum Master memudahkan dan menghapuskan halangan proses. Pengurus, pihak berkepentingan, dan pelanggan tidak hadir. Keperluan mereka diwakili melalui item Product Backlog yang dibawa oleh Product Owner ke mesyuarat.

Apakah perbezaan antara perancangan Sprint dan pemurnian Backlog?

Pemurnian Backlog (kadangkala dipanggil pembersihan Backlog) ialah aktiviti berterusan di mana Product Owner dan pasukan mengkaji, menganggar, dan menjelaskan item Backlog yang akan datang sebelum ia diperlukan untuk perancangan Sprint. Perancangan Sprint ialah mesyuarat rasmi yang terikat masa yang membuka setiap Sprint. Fikirkan pemurnian sebagai kerja persediaan dan perancangan Sprint sebagai mesyuarat keputusan. Pasukan yang melangkau pemurnian menghabiskan masa mesyuarat perancangan Sprint untuk melakukan kedua-dua kerja sekaligus, itulah sebabnya sesi tersebut berjalan lama dan menghasilkan komitmen yang tidak pasti.

Apa yang berlaku jika pasukan tidak boleh berkomitmen kepada kerja yang mencukupi?

Jika kapasiti pasukan lebih rendah daripada biasa (cuti, sakit, keutamaan bersaing), perancangan Sprint perlu mencerminkan itu dengan jujur. Pilih lebih sedikit item, tetapkan matlamat Sprint yang lebih kecil, dan komunikasikan skop yang dikurangkan kepada pihak berkepentingan sebelum Sprint bermula. Jangan isikan Sprint berkapasiti rendah dengan matlamat regangan atau item yang pasukan tidak percaya dapat diselesaikan. Skop yang berkomitmen lebih kecil yang dihantar lebih baik berbanding skop yang bercita-cita tinggi yang dihantar sebahagian dan meninggalkan pihak berkepentingan tidak pasti tentang apa yang sebenarnya selesai.

Perancangan Sprint yang berkesan bukan tentang memuatkan kerja sebanyak mungkin dalam dua minggu. Ia tentang memilih kerja yang betul, bersetuju tentang mengapa ia penting, dan membina keyakinan bersama bahawa pasukan boleh menyampaikan apa yang mereka janjikan. Apabila perancangan Sprint berfungsi dengan baik, Sprint hampir berjalan sendiri, dan itulah tepat bagaimana ia sepatutnya terasa.