Sprint Review: Cara Menjalankannya (Agenda dan Contoh)

Sprint review adalah tempat pasukan menunjukkan apa yang sebenarnya telah mereka bina. Jika dijalankan dengan baik, ia adalah salah satu jam yang paling bernilai dalam sesebuah sprint: satu perbualan sebenar antara orang yang membina produk dan orang yang menggunakan atau membiayainya.

Apakah Sprint Review?

Sprint review ialah acara Scrum formal yang diadakan pada penghujung setiap sprint. Pasukan memeriksa increment (segala yang telah disiapkan sepanjang sprint) dan bekerjasama dengan pihak berkepentingan untuk menyesuaikan backlog produk berdasarkan apa yang mereka pelajari.

Scrum Guide (Schwaber dan Sutherland, 2020) mentakrifkannya sebagai "sesi kerja" berbanding laporan status atau demo sehala. Perbezaan ini penting. Pihak berkepentingan bukan penonton; mereka adalah peserta yang membantu pasukan menentukan apa yang perlu dibina seterusnya.

Sprint review dihadkan masa kepada maksimum empat jam bagi sprint sebulan. Sprint yang lebih pendek mendapat review yang lebih pendek secara berkadar; kebanyakan pasukan sprint dua minggu mengekalkannya kepada satu atau dua jam.

Fakta Utama

• Scrum Guide (2020) menetapkan had masa empat jam bagi sprint sebulan, dikurangkan secara berkadar untuk sprint yang lebih pendek.
• Sprint review adalah salah satu daripada lima acara Scrum: sprint planning, daily scrum, sprint review, sprint retrospective, dan sprint itu sendiri.
• Laporan State of Agile 2023 (Digital.ai) mendapati 71% responden menggunakan Scrum atau hibrid Scrum, menjadikan sprint review salah satu mesyuarat maklum balas berstruktur yang paling banyak diamalkan dalam industri perisian.

Satu rangka fikir yang berguna: sprint review menjawab "Adakah kita membina perkara yang betul?" Sprint retrospective pula menjawab "Adakah kita membinanya dengan cara yang betul?"

Sprint Review lawan Sprint Retrospective

Kedua-dua acara ini berlaku berturut-turut pada penghujung setiap sprint, jadi pasukan sering mengelirukan antara kedua-duanya. Sebenarnya, mereka adalah perbualan yang sangat berbeza secara mendasar.

Untuk huraian lengkap format retrospektif dan soalan-soalannya, lihat panduan sprint retrospective.

Siapa yang Menghadiri Sprint Review?

Scrum Guide menyenaraikan peserta berikut:

• Pasukan Scrum: pembangun yang membina increment tersebut, Product Owner, dan Scrum Master
• Pihak berkepentingan: sesiapa sahaja yang dijemput oleh Product Owner, seperti pelanggan, pengguna, eksekutif, atau penaja perniagaan
• Pakar bidang: secara pilihan, pakar yang inputnya relevan kepada keputusan mengenai apa yang perlu dibina seterusnya

Product Owner biasanya menjemput pihak berkepentingan. Scrum Master memastikan acara ini kekal produktif dan dalam had masa. Pembangun membentangkan increment dan menjawab soalan secara langsung. Keterusterangan ini adalah sengaja. Pihak berkepentingan mendapat maklumat tanpa tapisan; pembangun mendapat reaksi tanpa tapisan.

Agenda Sprint Review

Sprint review yang berstruktur baik bergerak melalui lima bahagian. Berikut agenda contoh bagi review 90 minit (biasa untuk sprint dua minggu):

Bahagian 1: Pembukaan (10 minit)

Product Owner membuka sesi dengan merumuskan semula matlamat sprint dan menyenaraikan item yang dirancang untuk sprint tersebut. Jangan langkau ini. Pihak berkepentingan yang tidak hadir semasa sprint planning memerlukan konteks sebelum melihat demo tersebut.

Bahagian 2: Demo Increment (40 minit)

Pembangun mendemonstrasikan perisian yang berfungsi. Perisian sebenar, bukan slaid. Demo tersebut sepatutnya berkait langsung dengan matlamat sprint dan menunjukkan kriteria penerimaan telah dipenuhi. Setiap ciri sepatutnya didemonstrasikan dalam senario yang realistik, bukan tunjuk cara yang telah dibersihkan.

Tip: berikan setiap pembangun ciri yang mereka bina. Mereka menerangkan konteks dan menerangkan fungsi tersebut. Ini lebih boleh dipercayai berbanding satu orang mendemonstrasikan segalanya.

Bahagian 3: Maklum Balas Pihak Berkepentingan (20 minit)

Ini adalah teras sprint review. Product Owner memudahcarakan perbualan terbuka. Soalan untuk mencetuskan maklum balas berguna:

• Adakah ini menyelesaikan masalah yang anda fikirkan?
• Apa yang boleh menjadikan ini lebih berguna?
• Apa yang perlu kita tumpukan seterusnya?
• Adakah sesuatu yang tertinggal atau salah?

Dokumenkan segalanya. Input pihak berkepentingan secara langsung membentuk kemas kini backlog seterusnya.

Bahagian 4: Semakan Backlog (15 minit)

Product Owner menyemak backlog produk yang dikemas kini. Di sinilah pembelajaran daripada sprint diterjemahkan menjadi kerja masa hadapan. Item baharu muncul. Keutamaan berubah. Pasukan dan pihak berkepentingan menyelaraskan apa yang paling penting seterusnya.

Bahagian 5: Penutup (5 minit)

Pratonton matlamat sprint seterusnya, sahkan tarikh review seterusnya, dan ucapkan terima kasih kepada pihak berkepentingan. Ringkas dan jelas.

Cara Menjalankan Sprint Review yang Berkesan

Langkah 1: Sediakan persekitaran demo lebih awal

Jangan tunggu sehingga pagi hari review. Sediakan persekitaran staging, sahkan akaun demo berfungsi, dan uji sebarang integrasi langsung sehari sebelumnya. Demo yang rosak membazirkan masa semua orang dan menjejaskan kepercayaan.

Langkah 2: Berikan taklimat kepada pihak berkepentingan sebelum mesyuarat

Hantar bacaan awal yang ringkas: matlamat sprint, apa yang akan didemonstrasikan, dan sebarang konteks berkaitan (aliran kerja pengguna yang sedang anda tambah baik, pepijat yang telah anda betulkan). Pihak berkepentingan memberikan maklum balas yang lebih baik apabila mereka memahami titik permulaan.

Langkah 3: Kekal pada perisian yang berfungsi

Tunjukkan hanya apa yang telah disiapkan mengikut Definition of Done. Jika sesuatu itu 80% siap, jangan demonstrasikannya. Menunjukkan kerja yang belum lengkap mewujudkan kekeliruan dan jangkaan yang tidak selaras. Increment hanyalah apa yang memenuhi piawaian pasukan untuk "selesai."

Langkah 4: Jemput pihak berkepentingan yang betul

Lebih ramai tidak semestinya lebih baik. Jemput orang yang mempunyai kuasa membuat keputusan atau pandangan pengguna secara langsung. Kumpulan tumpuan lima orang yang terlibat menghasilkan maklum balas yang lebih baik berbanding penonton pasif seramai dua puluh orang.

Langkah 5: Rekod maklum balas secara masa nyata

Tugaskan seorang untuk mendokumentasikan input pihak berkepentingan semasa perbincangan. Item yang boleh diambil tindakan terus dimasukkan ke dalam backlog sebelum sesi berakhir, atau sekurang-kurangnya ditandakan untuk diproses segera oleh Product Owner selepas itu.

Langkah 6: Akhiri dengan langkah seterusnya yang jelas

Sebelum bilik itu kosong, nyatakan fokus yang berkemungkinan untuk sprint seterusnya. Ia tidak perlu muktamad. Tetapi meninggalkan tanpa sebarang hala tuju yang dikongsi adalah satu peluang yang terlepas. Sprint review sepatutnya terasa seperti satu bab yang ditutup dan satu bab baharu dibuka.

Amalan Terbaik Sprint Review

• Kekalkan demo yang realistik. Gunakan data sebenar atau senario yang hampir menyerupai sebenar. Demo yang tidak semula jadi tidak akan mendedahkan masalah kebolehgunaan sebenar.
• Hadkan masa setiap segmen demo. Jika pasukan mempunyai lima item untuk ditunjukkan, peruntukkan masa bagi setiap item. Tanpa struktur, demo akan berlarutan dan maklum balas tergesa-gesa.
• Putarkan siapa yang membentangkan. Setiap pembangun membentangkan kerja mereka sendiri membina keyakinan pasukan dan memberikan pihak berkepentingan gambaran yang lebih jelas mengenai pasukan tersebut.
• Jangan campurkan topik retrospektif. Isu proses sepatutnya berada dalam retro. Jika seorang pihak berkepentingan membangkitkan kebimbangan proses pasukan semasa review, catatkannya dan tangguhkan kepada retro.
• Rekod keputusan penting. Apa yang diluluskan oleh pihak berkepentingan? Apa yang diturunkan keutamaannya? Apa permintaan baharu yang timbul? Keputusan-keputusan ini memerlukan jejak dokumentasi.

Kesilapan Biasa

Melayan review sebagai demo sehala. Jika pihak berkepentingan hanya menonton dan bertepuk tangan, anda sedang membazirkan nilai. Sprint review adalah sesi kolaboratif, bukan persembahan teater.

Mendemonstrasikan ciri yang belum siap. Menunjukkan kerja dalam progres seolah-olah ia lengkap menjejaskan kepercayaan. Jika sesuatu belum sedia, katakan begitu. Langkau atau tunjukkan secara ringkas dengan amaran yang jelas.

Melangkau perbincangan backlog. Pasukan yang mendemonstrasikan lalu meninggalkannya terlepas bahagian paling penting: apa yang berubah kerana apa yang mereka baru pelajari. Perbincangan backlog adalah tempat output sprint bertukar menjadi input sprint seterusnya.

Menjalankannya tanpa pihak berkepentingan yang betul. Sprint review yang hanya dihadiri ahli pasukan dalaman hanyalah satu penyegerakan pasukan. Nilainya datang daripada perspektif luaran dan maklum balas pengguna sebenar.

Tiada persediaan. Demo ad hoc sering gagal atau berlarutan. Senarai semak persediaan ringkas, disemak sehari sebelumnya, mencegah kebanyakan bencana sprint review.

Soalan Lazim

Apakah sprint review?

Sprint review ialah acara Scrum yang diadakan pada penghujung setiap sprint di mana pasukan mendemonstrasikan increment yang telah disiapkan kepada pihak berkepentingan dan mengumpul maklum balas untuk mengemas kini backlog produk. Ia adalah sesi kerja kolaboratif, bukan pembentangan formal atau laporan status.

Berapa lamakah sprint review sepatutnya?

Scrum Guide mengesyorkan maksimum empat jam bagi sprint sebulan. Bagi sprint dua minggu, kebanyakan pasukan menjalankan review dalam satu hingga dua jam. Had masa berkadar dengan tempoh sprint: sprint lebih pendek, review lebih pendek.

Apakah perbezaan antara sprint review dan sprint retrospective?

Sprint review menumpukan kepada produk: pasukan menunjukkan apa yang mereka bina dan pihak berkepentingan memberikan maklum balas. Sprint retrospective menumpukan kepada proses pasukan: bagaimana mereka bekerja bersama dan apa yang perlu ditambah baik. Kedua-duanya berlaku pada penghujung sprint, tetapi mereka berkhidmat untuk tujuan berbeza dan mempunyai peserta yang berbeza.

Siapa yang mengendalikan sprint review?

Product Owner biasanya memudahcarakan sprint review, membuka sesi, dan memimpin perbincangan backlog. Scrum Master memastikan acara ini kekal dalam had masa dan produktif. Pembangun membentangkan increment secara langsung.

Apa yang berlaku jika matlamat sprint tidak tercapai?

Pasukan mendemonstrasikan apa yang telah disiapkan. Item yang belum lengkap tidak dibentangkan sebagai selesai. Jurang antara apa yang dirancang dan apa yang dihantar menjadi input untuk kedua-dua kemas kini backlog dan retrospektif. Ketelusan di sini lebih bernilai berbanding cuba memutar belitkan hasil.

---

Sprint review adalah salah satu acara Scrum paling mudah untuk dijalankan dan salah satu paling mudah untuk dijalankan dengan buruk. Demo yang ringkas dan bersedia baik dengan pihak berkepentingan yang betul di dalam bilik mengubah setiap sprint menjadi gelung maklum balas yang sebenar. Dan itulah yang memastikan pasukan membina produk yang betul, bukan sekadar membina dengan pantas.

Untuk acara Scrum lain, mulakan dengan upacara agile dan daily standup.