Templat Retrospektif Sprint untuk Pasukan Kejuruteraan

Mengapa kebanyakan retro tidak menghasilkan perubahan

Retrospektif sprint mempunyai masalah struktur yang tidak dibetulkan oleh templat: pasukan menjana idea penambahbaikan tetapi tidak menyemaknya. Retro menghasilkan lima butiran tindakan. Retro seterusnya dibuka dengan kertas kosong. Masalah yang sama muncul semula.

Templat di bawah memasukkan semakan itu ke dalam pembukaan supaya ia tidak boleh dilangkau. Satu perubahan tunggal itu berbuat lebih banyak untuk keberkesanan retro daripada mana-mana pelarasan format.

Agenda (salin-tampal ini)

Tempoh: 60 minit untuk sprint 2 minggu; 45 minit untuk sprint 1 minggu
Format: Dipermudah, dengan papan kongsi tak segerak (Miro, FigJam, Notion β€” pilihan anda)


Bahagian 1 β€” Semakan butiran tindakan (10 min)

  • Baca butiran tindakan sprint lepas satu demi satu
  • Tandakan setiap satu: Selesai / Sedang berjalan / Digugurkan (sebab ringkas untuk pengguguran)
  • Bawa ke hadapan mana-mana butiran yang belum selesai; jangan perdebatkannya semula sekarang

Bahagian 2 β€” Petikan data (5 min)

  • Kelajuan sprint berbanding sasaran
  • Kerja tidak dirancang yang melebihi satu hari
  • Insiden atau peristiwa bertugas
  • Perubahan skop di tengah-tengah sprint
  • Letakkan data di skrin tanpa perbincangan lagi

Bahagian 3 β€” Apa yang berjalan lancar (10 min)

  • Pasukan menambah butiran secara tak segerak sebelum mesyuarat atau dalam 3 minit pertama
  • Bincangkan 2-3 teratas; langkau butiran yang jelas dipersetujui
  • Jangan habiskan masa pada perkara yang tidak boleh diambil tindakan

Bahagian 4 β€” Apa yang perlu diperbaiki (15 min)

  • Format sama: input tak segerak, bincangkan butiran berisyarat tertinggi
  • Untuk setiap butiran: kejadian sekali sahaja atau corak berulang? Hanya corak menjadi butiran tindakan
  • Tugas pemudah cara ialah menukar "ini mengecewakan" menjadi sesuatu yang khusus dan boleh diubah

Bahagian 5 β€” Butiran tindakan (15 min)

  • Setiap butiran mesti mempunyai: penerangan, satu penanggung jawab (bukan "pasukan"), tarikh akhir
  • Sasarkan maksimum 2-3 butiran; lebih daripada itu mencairkan akauntabiliti
  • Bawa ke hadapan mana-mana butiran yang belum selesai daripada Bahagian 1

Penutup (5 min)

  • +/-/delta pantas tentang retro itu sendiri
  • Sahkan ringkasan dihantar sebelum penghujung hari

Apa yang terlepas oleh format retro popular

Start/Stop/Continue dan Apa Yang Berjalan Lancar/Apa Yang Perlu Diperbaiki/Butiran Tindakan kedua-duanya adalah format yang sah. Masalahnya bukan formatnya β€” tetapi templat jarang menyulam langkah semakan di hadapan. Langkah itu ialah satu-satunya perkara yang mencipta kesinambungan akauntabiliti daripada satu retro ke retro yang seterusnya. Tanpanya, retro ialah mesin perasaan, bukan mesin perubahan.

Templat juga tidak menangani disiplin had masa. "Apa yang perlu diperbaiki" berlarutan hampir secara universal kerana ia lebih menarik secara emosi daripada "apa yang berjalan lancar." Tanpa had yang tegas, retro 60 minit menjadi 90 minit perbincangan dan 5 minit butiran tindakan yang tergesa-gesa di penghujung. Butiran tindakan itulah satu-satunya bahagian yang mengubah apa-apa.

Jurang ketiga: butiran tindakan ditulis sebagai arahan yang kabur. "Perbaiki komunikasi frontend-backend" bukan butiran tindakan. "Sarah akan menjadualkan penyelarasan mingguan 30 minit antara ketua frontend dan backend, bermula Isnin depan" adalah butiran tindakan. Penanggung jawab dan tarikh mula perlu dinamakan di dalam bilik β€” kemudian, butiran khusus itu semakin mengabur.

Kos berganda daripada corak ini muncul beberapa minggu kemudian sebagai konteks yang tidak pernah dirakam dan keputusan yang diperdebatkan semula. Cukai mesyuarat merangkumi bagaimana ini kelihatan secara kuantitatif sepanjang suku tahun.

Mengapa ringkasan retro lebih sukar ditulis daripada nota standup

Ringkasan standup adalah pendek. Ringkasan perancangan sprint adalah berstruktur. Ringkasan retrospektif adalah sukar kerana kandungannya bersepah β€” nota lekat, perbincangan yang melompat antara bahagian, campuran sentimen dan data. Sesiapa yang menulis ringkasan terpaksa membina semula benang yang koheren daripada mesyuarat yang bergerak ke pelbagai arah serentak.

Pavleur menguruskan ini dengan baik tepat kerana kesepahan itu. Ia merakam segala yang dikatakan semasa mesyuarat dan apa sahaja yang ada di skrin β€” papan kongsi, carta kelajuan daripada Bahagian 2, tiket insiden yang seseorang rujuk dalam Bahagian 4. Laporan selepas mesyuarat adalah berstruktur, dengan butiran tindakan diekstrak daripada apa yang sebenarnya diputuskan di dalam bilik (berserta penanggung jawab dan tarikh, seperti yang dinamakan). Tiada pembinaan semula diperlukan, tiada pembersihan selepas panggilan.

Alat transkripsi audio sahaja merakam perkataan tetapi bukan konteks visual. Dalam retro, visual sering menjadi bahagian yang paling penting β€” papan nota lekat, graf yang menimbulkan corak, tiket yang menambat perbincangan. Konteks itu tidak wujud dalam ringkasan audio sahaja. Untuk perbandingan alat secara langsung: Pavleur berbanding alternatif.

Mod kegagalan retro yang biasa

Butiran tindakan yang sama muncul dalam tiga retro berturut-turut. Bahagian 1 tidak boleh ditawar. Jika sesuatu butiran terus tidak disiapkan, sama ada gugurkannya dengan sebab yang dinyatakan atau eskalasikannya β€” jangan bawa ke hadapan tanpa henti.

Perbincangan bertukar menjadi luahan tanpa penyelesaian. Tugas pemudah cara dalam Bahagian 4 ialah menterjemah "proses itu rosak" menjadi satu perkara yang khusus dan boleh diubah. Jika ia tidak boleh dijadikan khusus dalam 30 saat, ia dimasukkan ke dalam ruang tangguh.

Tiada sesiapa menambah butiran secara tak segerak sebelum mesyuarat. Hantar papan itu 24 jam lebih awal. Semaikannya dengan 2-3 butiran untuk memecahkan masalah kanvas kosong. Mesyuarat berjalan lebih lancar apabila semua orang tiba dengan sesuatu yang telah ditulis.

Templat Retrospektif Sprint untuk Pasukan Kejuruteraan | Pavleur