Seberapa sering tim Scrum harus memenuhi komitmen Sprint-nya? [Tutup]

10

Komitmen adalah janji, dan kita semua telah diajari bahwa Anda harus menepati janji Anda. Tetapi apakah realistis untuk menjaga komitmen untuk setiap Sprint? Kadang-kadang orang sakit, kadang-kadang pendekatan teknis terbukti salah dan Anda harus memikirkan kembali semuanya, kadang-kadang selama diskusi lebih lanjut dengan pemilik produk atau pengguna yang Anda pahami bahwa fitur tersebut harus sangat berbeda dari yang semula dipikirkan.

Saya tahu bahwa Panduan Scrum resmi sekarang menggunakan kata "perkiraan" daripada komitmen, mungkin untuk mengatasi masalah ini.

Jadi pertanyaan saya adalah seberapa sering tim dalam organisasi Anda menjaga komitmen mereka dan apakah Anda menyukai pendekatan ini atau Anda ingin mengubahnya.

Terima kasih.

scrum

— Eugene
sumber

meta.programmers.stackexchange.com/questions/6483/…

— gnat

1

Sebuah pertanyaan yang saya sering bertanya-tanya dan dua jawaban yang bagus

— matt freake

1

Jika Anda selalu memenuhi komitmen Anda, Anda mungkin tidak cukup agresif. Akurasi Anda diharapkan akan meningkat seiring berjalannya waktu, karena bagian dari tujuan Scrum adalah untuk meningkatkan keterampilan semua orang dalam memperkirakan berapa lama tugas yang diberikan akan berlangsung di Dunia Nyata.

— keshlam

1

@keshlam itu tidak sepenuhnya benar. Ada sekumpulan pemikiran dalam gerakan lincah yang secara aktif mencoba untuk melampaui perkiraan tradisional, mengenali potensi racunnya.

— Stefan Billiet

1

Memang, @StefanBilliet ... tetapi Scrum berniat untuk secara simultan mengurangi perkiraan sejauh yang menyangkut dunia luar sambil meningkatkan rasa internal tim tentang berapa banyak pekerjaan tambahan yang akan mereka dapat lakukan ketika.

— keshlam

21

Ini bukan pertanyaan seberapa sering tim harus "menepati janji".
Ini lebih merupakan pertanyaan menyelidiki mengapa tim akan memiliki masalah memenuhi komitmennya.

Jika itu adalah intervensi yang saleh, itu tidak masalah. Tetapi jika Anda menemukan bahwa Anda sering perlu kembali ke papan gambar, karena pendekatan teknis Anda benar-benar salah, atau bahwa PO terus berubah pikiran, atau bahwa cerita tidak cukup jelas pada awal sprint, maka Anda perlu menyelidiki mengapa.

Tidak memenuhi komitmen sprint adalah gejala; Anda harus tertarik dengan akar masalahnya.

— Stefan Billiet
sumber

Jadi haruskah kita berusaha untuk memenuhi komitmen dalam 99,99% kasus? Jika itu adalah level jaminan yang diperlukan bahwa komitmen akan dipenuhi, kami hanya akan berkomitmen untuk setengah dari rata-rata pekerjaan yang biasanya dapat kami hasilkan. Jadi saya kira ini bukan 99,99%. Jadi apa itu? 50-70%? 80-90%?

— Eugene

@Eugene Mengapa Anda perlu nomor dan siapa yang perlu diyakinkan? Saya mulai mendapatkan gagasan bahwa ada seseorang di organisasi Anda yang akan menghukum Anda jika Anda tidak memenuhi tujuan lari Anda ...

— Stefan Billiet

Tidak semuanya. Bahkan di organisasi saya tidak ada yang peduli apakah komitmen itu dipenuhi atau tidak. Saya mencoba untuk mengubahnya, karena saat ini memperbaiki bug dan menulis tes ditinggalkan karena tidak ada waktu untuk mereka. Saya ingin menasihati tim untuk berkomitmen kurang sehingga mereka dapat memenuhi komitmen mereka secara teratur. Tapi apalagi? Jika memenuhi komitmen adalah masalah hidup atau mati maka Anda pasti akan berkomitmen untuk kurang dari jika itu hanya ramalan yang tidak bergantung pada siapa pun.

— Eugene

2

Dengan suara itu, Anda memiliki beberapa masalah yang lebih mendasar. Anda perlu memiliki pemahaman tim tentang 'selesai' sebelum Anda dapat mengukur kinerja pada jumlah cerita yang telah 'selesai'

— Michael Shaw

13

Jika semuanya baik-baik saja, maka itu normal bagi tim untuk memenuhi komitmen scrum mereka. Mereka harus berjalan cukup dingin untuk mengatasi gangguan skala kecil, masuk akal dan kemungkinan seperti penyakit hari, darurat perawatan anak dll ... tanpa itu segera dan secara otomatis memicu kegagalan untuk memberikan komitmen sprint. Jika tidak bisa maka dalam pandangan saya sprint sudah selesai dan berjalan terlalu panas untuk kebaikan jangka panjang mereka sebagai sebuah tim.

Jika sprint secara konsisten gagal disampaikan, maka scrum telah memenuhi janjinya, untuk membuat 'masalah' terlihat. Masalahnya mungkin termasuk tidak memiliki tugas yang ditetapkan dengan benar, pengalaman yang tidak memadai dalam tim, atau budaya manajemen yang terus-menerus berusaha melakukan pengiriman berlebih - dan karenanya terus gagal.

Apa pun caranya, solusinya adalah mengidentifikasi penyebab utama, dan memperbaikinya, daripada mencambuk pengembang lebih keras.

Tim yang selalu 'dekat' untuk memenuhi komitmen mereka gagal dengan cara yang lebih serius. Anda dapat memastikan bahwa mereka tidak melakukan pengujian yang cukup.

— Michael Shaw
sumber

4

Saya pribadi percaya bahwa jika tidak ada orang di organisasi yang peduli untuk memenuhi komitmen Anda, Anda tidak berbicara tentang komitmen. Anda membutuhkan dua mitra untuk membuat kesepakatan dan untuk membentuk komitmen.

Komitmen sprint adalah sesuatu yang harus Anda pertahankan, dengan mempertimbangkan semua "variasi normal". Anda dapat membaca posting blog saya tentang dasar-dasar perencanaan tangkas jika Anda ingin tahu lebih banyak tentang apa yang saya maksud dengan variasi dasar. Dan seperti yang Stefan katakan , tidak memenuhi komitmen Anda adalah gejala bukan penyakit.

Setelah setiap sprint, Anda memiliki waktu untuk memeriksa kecepatan aktual sprint itu dan menyesuaikan "kecepatan rata-rata" Anda dengan itu (seperti dijelaskan dalam posting yang disebutkan di atas ). Jika kecepatan Anda terus turun, sprint demi sprint, Anda mulai melihat pola yang dapat membantu Anda mendeteksi akar penyebab sebenarnya dari ini. Ini bisa jadi pekerjaan yang tidak direncanakan terlalu banyak (mis. Tugas-tugas kecil yang mendesak, bug dalam kode yang sedang Anda kerjakan, perubahan pada kriteria penerimaan selama sprint, ...). Semua data ini perlu dilacak, kemungkinan besar oleh master scrum untuk membantunya mencari tahu pola mana yang ada di sana. Itu akan membantu tim untuk membuat tindakan selama retrospektif.

— talboomerik
sumber

2

Perspektif saya adalah bahwa tim tidak membuat komitmen. Boleh dibilang, mereka bahkan tidak membuat perkiraan. Prakiraan dibuat sebelum sprint direncanakan - ramalannya adalah bahwa rata-rata mereka akan memenuhi kecepatannya. Itu berarti kadang-kadang mereka akan melakukan beberapa poin lebih banyak daripada kecepatan mereka, kadang-kadang mereka akan melakukan sedikit lebih sedikit.

Jika Anda melakukan kurang dari kecepatan Anda secara teratur, kecepatan Anda turun untuk mencerminkan hal itu. Perkiraan demikian turun juga. Jika Anda terus menarik lebih banyak cerita daripada kecepatan historis Anda mengatakan Anda bisa melakukan sprint demi sprint, itu bukan kegagalan dalam eksekusi, itu adalah kegagalan dalam perencanaan. Anda tahu kecepatan Anda, jadi Anda seharusnya tidak membawa lebih banyak poin daripada sejarah yang bisa Anda capai.

Untuk menjawab pertanyaan spesifik Anda, dari tiga organisasi tempat saya menggunakan scrum, hanya satu yang melacak metrik "lewatkan komitmen" seiring waktu. Untuk perusahaan itu, tim biasanya mencapai perkiraan mereka sekitar 85% dari waktu.

— Bryan Oakley
sumber

Setuju. Saya berada di satu tim di mana pada akhir setiap perencanaan sprint, manajer menuntut komitmen untuk menyelesaikan semua cerita untuk sprint. Saya terbiasa mengatakan "ya" dan terus gesit. Saya pikir itu mungkin membuatnya merasa lebih baik seperti itu.

— Rob

1

@RobY: Saya pikir ada ruang untuk komitmen dalam tim yang matang. Dalam pengalaman saya, kebanyakan tim lincah tidak terlalu matang, dan PO apa pun yang meminta komitmen bukanlah PO yang baik. Saya berada di satu tim yang cukup solid dengan kecepatannya dan kami merasa cukup nyaman membuat komitmen yang sebenarnya ketika diperlukan, tetapi tim lain yang saya ikuti belum matang.

— Bryan Oakley

Aku sedikit gelisah. Saya setuju, biasanya ada satu set inti cerita yang bisa Anda komit, tetapi ketika Anda mendekati kecepatan, itu sedikit kurang yakin. Karena kecepatan adalah rata-rata, maka menurut definisi terkadang Anda akan berakhir, dan terkadang di bawah. BTW bahwa manajer yang sama akan memuat kami dengan 2x atau 3x kecepatan kami setiap kali dan kemudian menuntut komitmen ... jadi ...;) (Saya sebagian besar bereaksi terhadap paragraf pertama Anda, yang saya pikir nyatakan dengan sangat baik)

— Rob

2

Jika Anda tidak memenuhi komitmen Anda maka Anda harus mengurangi kecepatan Anda. Jika Anda selalu bertemu, Anda harus meningkatkan sampai Anda kadang-kadang gagal.

Masalahnya adalah seberapa buruk Anda gagal? Itu harus selalu dekat. Entah Anda membuatnya dengan sedikit kendur atau gagal hanya sedikit. Itu adalah tujuan yang sehat untuk disiplin apa pun , waktu berlari, angkat berat, dll. Idealnya jumlah rata-rata pekerjaan yang dilakukan dalam sprint haruslah distribusi normal di sekitar kecepatan Anda.

Yang lebih penting adalah tren jangka panjang dalam kecepatan Anda. Jika setiap minggu Anda menambahkan 15 poin cerita ke kecepatan Anda tetapi hanya mencapai 10 lebih dari yang Anda lakukan minggu sebelumnya, apakah itu benar-benar hal yang buruk? Di beberapa tempat mereka menganggap ini "tujuan yang meluas".

— Kereta luncur
sumber

Saya sangat tidak setuju dengan jawaban ini. Sifat manusia adalah mencoba untuk memberikan, dan Anda dapat bertaruh dolar bawah Anda bahwa tim akan memotong 'pengujian' untuk disampaikan, daripada menjatuhkan cerita. Jika Anda selalu sedekat ini dengan garis, Anda tidak akan menguji cukup menyeluruh, dan itu akan kembali menggigit.

— Michael Shaw

@Ptolemy di situlah disiplin, kebanggaan profesional, dan " definisi selesai " diperlukan. Itu harus mencegah Anda dari pengiriman barang. Juga, Anda tidak harus menghitung sesuatu seperti yang dilakukan jika Anda telah mengambil jalan pintas.

— Kereta luncur

Itu jauh lebih jelas pada bagian pengembang daripada pada bagian pengujian scrum. Anda dapat tidak memiliki cacat yang diketahui karena tester difokuskan pada pengujian fungsionalitas inti, dan tidak punya waktu untuk 'peristiwa acak' yang terjadi untuk mengekspos bug.

— Michael Shaw

2

@Ptolemy: tim tidak bisa secara teknis "memotong pengujian" karena pengujian adalah bagian dari cerita. Jika mereka memotongnya, itu tidak berbeda dengan memotong bagian dari pengkodean. Jika Anda menghilangkan bagian dari fitur kode, apakah Anda menyelesaikan cerita? Demikian juga, jika Anda memotong pengujian, Anda tidak menyelesaikan cerita.

— Bryan Oakley

Saya tidak pernah menggunakan scrum tetapi saya telah membuat komitmen dan saya telah menilai apakah semuanya telah dilakukan. Alangkah baiknya jika definisi yang dilakukan sepenuhnya obyektif, yaitu tidak ada ruang bagi kelompok untuk menafsirkan definisi tersebut dengan mempertimbangkan apakah perlu dilakukan untuk memenuhi komitmen. Bahasa alami menjadi seperti apa adanya, ini sepertinya tidak realistis. Jika Anda cukup santai tentang komitmen dan cukup dekat dengan definisi objektif, ini tidak akan menjadi masalah. Ketika Ptolemy mengatakan "sifat manusia adalah untuk berusaha menyampaikan", dalam skema saya itu berarti "orang tidak cukup santai tentang komitmen".

— Steve Jessop