Dalam standup Scrum, haruskah diskusi tentang apa yang dilakukan kemarin dibatasi pada tugas-tugas di papan tulis atau semua pekerjaan yang dilakukan?


10

Saya tahu bahwa aturan Scrum dalam standup harian mengatakan bahwa tim hanya boleh berbicara tentang apa yang mereka lakukan kemarin, apa yang mereka lakukan hari ini, dan apa pun yang menghalangi mereka. Tidak ada lagi. Tetapi masalahnya adalah, kadang-kadang pengembang menghabiskan hari mereka melakukan pekerjaan yang tidak relevan dengan tugas mereka, dan kemudian membicarakannya di standup. Itu yang mereka lakukan kemarin!

Dalam pengalaman saya, saya menemukan bahwa lebih efektif untuk berbicara tentang tugas-tugas di papan tulis, untuk menjaga fokus tetap, dan untuk menjaga fokus semua orang pada tugas mereka, untuk meninjau estimasi mereka & melacak catatan mereka setiap hari.

Apakah valid untuk membatasi diskusi dengan tugas-tugas di papan tulis?


1
Bahwa pengembang menghabiskan sepanjang hari tidak mengerjakan tugas mereka bisa menjadi masalah yang tidak akan terlihat jika tidak disebutkan?
RemcoGerlich

Semua orang berbicara 30 detik untuk mengatakan apa yang mereka lakukan sebelumnya. Seberapa jauh lebih fokus yang Anda inginkan? Anda tidak meninjau estimasi. Anda melacak tugas saat Anda menyerahkannya ke orang berikutnya (resensi atau penguji).
gnasher729

Jawaban:


5

Sesuai konten Panduan Scrum pada standup harian, tiga pertanyaan untuk diskusi adalah:

  • Apa yang saya lakukan kemarin yang membantu Tim Pengembangan memenuhi Sasaran Sprint?
  • Apa yang akan saya lakukan hari ini untuk membantu Tim Pengembangan memenuhi Sasaran Sprint?
  • Apakah saya melihat ada halangan yang menghalangi saya atau Tim Pengembangan untuk memenuhi Sasaran Sprint?

Semua pertanyaan fokus pada Tujuan Sprint, bukan tugas yang ada di papan tulis. Sekali lagi, sesuai Panduan Scrum, Tujuan Sprint dibuat dalam Perencanaan Sprint dan mendefinisikan "sebuah tujuan yang akan dipenuhi dalam Sprint melalui implementasi Product Backlog, dan memberikan panduan kepada Tim Pengembangan tentang mengapa ia membangun Kenaikan".

Segala sesuatu yang dilakukan oleh tim pengembangan Anda harus, secara ideal, membantu tim berkembang menuju Tujuan Sprint. Ini mungkin kegiatan yang tidak direncanakan yang tidak ada di papan tulis yang harus dilakukan, atau bisa saja hal-hal di tingkat yang lebih rendah yang mungkin telah dipertimbangkan dan diperkirakan, tetapi pada tingkat yang lebih rendah daripada item di papan tulis.

Saya akan mengatakan biarkan tim Anda berbicara tentang semua yang mereka lakukan kemarin. Jika mereka berbicara tentang hal-hal yang tidak membantu tim mencapai Tujuan Sprint, maka seseorang harus mengemukakan hal ini, terutama jika ada hal-hal lain yang bisa mereka lakukan yang memindahkan tim lebih dekat untuk menyelesaikan Tujuan Sprint.

Satu pengecualian mungkin jika seseorang mendukung beberapa tim Scrum. Dalam pertemuan itu, mereka mungkin tidak boleh berbicara tentang semua yang mereka lakukan kemarin, tetapi apa yang mereka lakukan untuk mendukung tim yang saat ini memiliki standup.

The Sprint Retrospective adalah waktu yang tepat untuk berbicara tentang masalah ini dengan tim. Ada banyak pertanyaan untuk dipertimbangkan:

  • Apakah tim sedang mengerjakan item yang terkait dengan Sprint Goal?
  • Apakah ada terlalu banyak pekerjaan yang tidak direncanakan?
  • Dari mana karya yang tidak direncanakan berasal dan siapa yang mengotorisasi itu?
  • Mengapa orang mengerjakan sesuatu yang tidak ada di papan tulis?
  • Haruskah kita menunjukkan lebih banyak detail di papan tulis untuk mengikat hal-hal yang Anda lakukan dengan barang-barang di papan tulis dengan lebih mudah?

2
masalah dengan "Sprint Goal" adalah terlalu kabur dan membingungkan. dalam praktiknya Sprint Goal == menyelesaikan tugas di papan tulis. jika apa yang Anda kerjakan tidak ada di sana baik itu seharusnya atau Anda tidak boleh bekerja di atasnya
Ewan

1
@ Ewan Seorang pelanggan menelepon dan memberi tahu kami bahwa perangkat lunak langsung macet dan kami memiliki log dan laporan bug. Sangat penting untuk meluangkan waktu untuk memeriksa laporan itu segera, bahkan jika itu tidak ada di papan tulis sekarang. Mungkin dibawa ke ruang lingkup atau mungkin dimasukkan ke dalam tumpukan, tapi itu adalah sesuatu yang saya lakukan kemarin dan bisa jadi mengapa saya tidak bisa membantu Bob dengan masalahnya sampai setelah makan siang. Saya seharusnya tidak melakukan tugas itu secara membabi buta, tapi tidak ada yang mungkin akan menaruhnya di papan kecuali ditarik ke Sprint ini. Saya bisa memikirkan contoh lain juga.
Thomas Owens

1
Anda harus menambahkan tiket "triage live bug" ke papan tulis dan menandainya sudah selesai. Lalu pada akhir sprint bisa Anda katakan dengan pasti. 'sprint ini kami habiskan berjam-jam melihat kesalahan pengguna. Itu sebabnya kami terlambat. kita perlu melatih helpdesk yang lebih baik 'Kalau tidak, kamu tidak akan melakukan sprint dan PM hanya punya alasan desas-desus dari tim' oh ada banyak bug untuk dilihat minggu ini! shrug '
Ewan

1
@ Ewan, saya pikir itu sangat tidak perlu. Saya tidak ingin menghabiskan hari saya menulis tiket. Sebuah proses perlu membiarkan saya menyelesaikan pekerjaan saya, dan mengambil 90 menit untuk melakukan triase alih-alih 95 menit untuk melakukan triase dan kemudian memasukkan tiket yang mengatakan bahwa saya melakukan triase tiket adalah konyol. Apalagi jika Anda harus triase beberapa tiket. Anda tidak perlu tiket untuk membahas hal-hal di retrospektif. Jika Anda menggunakan alat elektronik, Anda dapat menemukan tiket yang dimodifikasi oleh tim di Sprint untuk melihat apakah ada banyak hal yang perlu dipertimbangkan - tidak ada kabar angin di sana.
Thomas Owens

1
tingkat pelaporan jika hingga scrummaster / pm / perusahaan Anda. Anda bisa menulis satu tiket "trigaing bugs" untuk meliput semua pekerjaan Anda hari itu. Tetapi yang penting adalah Anda MENCATATI SEBAGAI BAGIAN DARI SPRINT. jangan berasumsi bahwa itu hanya diperhitungkan oleh beberapa metrik lainnya
Ewan

0

Tidak, Anda harus membicarakan apa yang Anda lakukan kemarin.

Jika tidak ada di papan tulis, Anda perlu melakukan salah satu dari yang berikut:

  • letakkan di papan,
  • berhenti melakukannya
  • atau ganti tim.

Yang paling umum, katakanlah untuk pekerjaan darurat yang tidak direncanakan, adalah menulis kartu dan menempelkannya di papan tulis. Ini memastikan bahwa pada akhir sprint Anda dapat mengukur kecepatan dan menjelaskan mengapa tujuan sprint tidak tercapai.

Seorang anggota tim yang mengerjakan hal-hal yang tidak ada dalam sprint menurut saya salah satu alasan utama kegagalan adopsi tangkas. Paling umum ini adalah pengembang dialihkan untuk memperbaiki masalah langsung di proyek lain.

Hal menjengkelkan lain dalam sprint adalah "PM berbicara tentang pertemuan untuk proyek lain". Dalam pandangan saya PM bukan bagian dari tim scrum, mereka mengisi peran Scrum 'Pemilik Produk' dan dengan demikian ada untuk menjawab pertanyaan, bukan melaporkan kemajuan.


3
Ada yang namanya pekerjaan yang tidak direncanakan - pekerjaan yang perlu dilakukan untuk membuka blokir seseorang atau melakukan tugas-tugas lain yang ada di papan tulis, tetapi itu bukan di papan tulis. Seringkali, mungkin lebih cepat untuk melakukannya kemudian menaruhnya di papan tulis. Terserah tim untuk membahas cara menanganinya. Tim saya saat ini memiliki aturan - apa pun yang digunakan untuk lingkungan produksi atau QA atau tugas yang memakan waktu 2 jam. Kadang-kadang masih ada tugas yang lebih pendek yang perlu terjadi yang dibicarakan tetapi tidak membuat papan karena tidak sesuai dengan kriteria.
Thomas Owens

@ Ewan, bisakah Anda mengembangkannya? Siapa yang menangani memperbaiki bug langsung, jika tidak ada dalam Sprint? Bagaimana Pemilik Proyek sekaligus Manajer Proyek? (Maksud saya yang mana dia, atau dia menyulap kedua peran)
Dennis

diedit untuk kejelasan
Ewan

@ Dennis: Manajer Proyek bukan peran Scrum.
RemcoGerlich

@ Ewan, terima kasih. Ini tidak penting untuk jawabannya, tetapi saya ingin tahu - "PM berbicara tentang pertemuan untuk proyek lain", bagaimana cara kerjanya? Apakah PM datang ke pertemuan tentang proyek X, tetapi berbicara tentang Y? Saya kesulitan membayangkan ini. Bagaimana / mengapa ini mungkin? Apakah maksud Anda mereka datang dan pada dasarnya mulai bergosip atau keluar topik atau apakah ada alasan yang lebih dalam bagi mereka untuk berbicara tentang tujuan / kebutuhan spesifik pertemuan yang tidak langsung? Saya akan mengatakan "hei senang mendengar ini, tetapi saya bukan bagian dari proyek Y ... tidak ada pengetahuan / pengalaman di sana, bisakah kita kembali ke X?"
Dennis
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.