Apakah tawar-menawar dan upaya percobaan estimasi Scrum adalah bagian yang sah dari proses?

Saya perhatikan dalam rapat scrum, bahwa pengembang sering memberikan estimasi realistis tentang cerita. Namun, bahkan cerita yang agak sederhana memerlukan banyak upaya untuk konfigurasi, pengaturan komponen pihak ketiga, pengujian dan pembuatan akhir, dan sistem telah mengakumulasikan cukup banyak hutang teknis, sehingga perkiraan seringkali tampak terlalu tinggi untuk pemilik atau manajemen produk.

PO sering mencoba untuk mengalahkan perkiraan seperti itu, seperti: "Apa, Anda ingin 13 poin cerita [4 hari] untuk cerita ini, ini tidak mungkin! Saya tidak bisa menjelaskan ini kepada manajemen, seseorang harus dapat kode ini dengan 3 SP [dalam 4 jam]! " Akibatnya, para pengembang memutar tangan mereka untuk berkomitmen pada perkiraan 5 atau 8 poin poin [1,5 hingga 2 hari] (perkiraan Scrum masih dianggap sebagai komitmen, bukan hanya perkiraan).

Tentu saja, tanpa rencana untuk menurunkan harapan (terutama pada pengujian dan kualitas), sprint ini sering gagal. Perkiraan pengembang adalah jujur, realistis, dan mengalahkan perkiraan tidak mengalahkan pekerjaan yang sebenarnya harus dilakukan.

Seseorang dapat mengatakan: "Anda seharusnya tidak membuat komitmen yang mustahil, hanya karena seseorang mendorong Anda untuk melakukannya!" Tetapi menurut saya, pekerjaan pengembang adalah desain dan pengkodean perangkat lunak, bukan tawar-menawar atau menghadapi tekanan! Mungkin ada jacks dari semua perdagangan, biasanya yang berhubungan langsung dengan pelanggan eksternal, tetapi ini bukan mayoritas pengembang kantor!

Bagi saya, praktik ini hanya membuat pemrogram terlihat seperti tersentak, menyebabkan kegagalan sprint konstan dan mencegah estimasi realistis, serta mencari perbaikan yang sebenarnya.

Apa yang dikatakan pedoman Scrum tentang topik ini, atau apakah mereka mengatakan sesuatu tentangnya?

EDIT: diganti kali dengan poin cerita. Saya mengacu pada tahap estimasi awal dengan Perencanaan Poker dan poin cerita, bukan perencanaan detail tugas. Saya hanya menempatkan hari / jam di sana, karena itu adalah dialog khas seperti ini kadang-kadang, juga dengan waktu, bukan poin. Maaf atas kebingungan! Contoh-contoh titik cerita mewakili periode waktu yang lebih lama daripada contoh waktu.

EDIT 2 Saat ini tidak ada master scrum khusus, dan PO mengambil peran itu, ketika datang ke pertemuan estimasi. Jadi mungkin konflik peran membuat tawar-menawar yang tidak pantas ini menjadi lebih buruk, karena ia muncul sebagai otoritas, bukan master scrum netral atau pengembang. Mungkin, ini bisa diperbaiki dengan menganggapnya sebagai peserta yang bias alih-alih "master", selama tidak ada yang tersedia.

Situasi yang Anda gambarkan beracun. Tawar-menawar semacam ini mengabaikan kenyataan dan keahlian tim, ia dengan sengaja menyembunyikan informasi dari tim dan organisasi pada umumnya, dan itu menghambat tim dari peningkatan dari waktu ke waktu.

Jika Anda ingin kota http://www.scrumguides.org/scrum-guide.html sebagai otoritas saya akan menyoroti:

Hanya Tim Pengembang yang dapat menilai apa yang dapat dicapai selama Sprint mendatang.

dan

Scrum mengandalkan transparansi. Keputusan untuk mengoptimalkan nilai dan mengendalikan risiko dibuat berdasarkan persepsi artefak. Sejauh transparansi lengkap, keputusan-keputusan ini memiliki dasar yang kuat. Sejauh artefak tidak sepenuhnya transparan, keputusan ini dapat cacat, nilai dapat berkurang dan risiko dapat meningkat.

Pemilik produk Anda mungkin menginginkan agar tugas dapat dilakukan hanya dalam 4 jam. Itu bahkan mungkin tujuan yang masuk akal. Reaksi yang sehat mungkin untuk menerima perkiraan tim, mengukurnya apakah itu akurat, dan bertanya "apa yang perlu kita ubah agar dapat menyelesaikan tugas semacam ini lebih cepat?" Menegosiasikan ruang lingkup pekerjaan yang terlibat dalam tugas mungkin juga masuk akal dan menyoroti perbedaan penting dalam bagaimana pengembang dan pemilik produk memahami pekerjaan itu. Menuntut bahwa tim mengubah perkiraan mereka tanpa informasi baru hanya memastikan perkiraan yang tidak akurat.

Ada banyak strategi yang mungkin digunakan tim pengembangan untuk mencoba mengubah pola ini, tetapi ketika Anda memberikan contoh jawaban dari "Saya tidak bisa menjelaskan ini kepada manajemen" Saya menjadi sangat gugup. Sepertinya pemilik produk Anda tidak memiliki kepercayaan manajemen (perkiraan yang tidak akurat yang mereka hasilkan mungkin tidak membantu) dan mungkin tidak mau transparan tentang kegagalan proses saat ini.

Menurut pendapat saya, salah satu pencapaian terbesar SCRUM adalah pengembangan poin cerita, dengan maksud eksplisit yang dinyatakan untuk menghindari masalah perundingan yang disebutkan di sini. Inti cerita-poin adalah untuk menghindari hubungan langsung antara tugas dan berapa hari yang dibutuhkan. Sebaliknya, kedua konsep tersebut dihubungkan oleh gagasan kecepatan.

Jika saya seorang pengembang, dan saya dipaksa memutar cerita 13 poin sebagai cerita 8 poin, saya dengan senang hati akan menurut. Ini kemampuan estimasi mereka yang mereka pengaruhi. Saya hanya akan mengukur semua kesulitan saya untuk mencocokkan. Akhirnya kecepatan tim akan berkurang dalam hal poin cerita per minggu untuk mencocokkan kesediaan manajemen untuk "membagikan" poin cerita. Jumlah yang dikirim ke manajemen harus sesuai: "Kami telah berhasil mengurangi jumlah titik cerita pekerjaan yang dibutuhkan untuk mencapai tonggak sejarah sebesar 50%. Namun, kami telah melihat penurunan kecepatan yang sesuai sebesar 50%, sehingga efek bersihnya adalah kami akan mencapai apa yang akan kita capai dengan tepat dalam jumlah waktu yang dibutuhkan. " Konsep kecepatan ada untuk melawan angan-angan manajemen atas.

Sekarang ada dua ekstrem yang menurut saya layak untuk dilihat. Salah satunya adalah kegagalan manajemen yang lengkap dan yang lainnya sebenarnya merupakan perhatian yang sangat valid bagi manajemen untuk diperhatikan. Kasus pertama adalah hukuman mati bagi SCRUM, ketika pengembang diberi tahu "Anda tidak cukup produktif. Anda perlu menghasilkan lebih banyak pekerjaan dengan nilai cerita-poin." Jika itu terjadi, Anda sebenarnya tidak menggunakan SCRUM, Anda seorang Cookoo, yang menendang SCRUM dari sarangnya dan mencoba untuk diberi makan oleh induk burung yang kembali ke sarang berikutnya.

Sekarang ada satu kasus di mana saya pikir manajemen seharusnyadapat terlibat dalam memutar lengan seperti ini. Seharusnya masuk akal bagi pelanggan untuk mengatakan, "Saya tidak mampu membeli 50 poin cerita untuk menyelesaikan tugas ini jika kecepatan Anda 20 poin / minggu. Saya ingin Anda menyelesaikannya dalam 30 poin poin," jika pelanggan itu mau untuk menegosiasikan ulang konten cerita-cerita itu untuk mengurangi cakupannya hingga 40%. SCRUM bukanlah tiket makan gratis bagi pengembang untuk melakukan apa pun yang mereka inginkan, ini adalah alat komunikasi untuk membantu mereka dan manajemen berbicara secara terbuka tentang apa yang perlu dilakukan. Ini juga berlaku bagi pelanggan untuk menekan pengembang dan mengatakan "lakukan tugas dalam 30 poin" jika mereka mau menerima risiko yang melekat bahwa pekerjaan itu tidak akan selesai tepat waktu. Ketika batas waktu terlewati, jika pengembang dapat mengatakan " dan kemudian menerima apa pun yang sebenarnya dilakukan. Saya pikir ada cara yang lebih baik untuk mengukur produktivitas tim, tetapi saya harus mengakui bahwa itu adalah proses yang berhasil. dan kemudian menerima apa pun yang sebenarnya dilakukan. Saya pikir ada cara yang lebih baik untuk mengukur produktivitas tim, tetapi saya harus mengakui bahwa itu adalah proses yang berhasil.

Pertama, PO seharusnya tidak memberikan informasi tugas kepada manajemen. Estimasi tugas hanya untuk keuntungan tim. Satu-satunya hal yang perlu diketahui oleh siapa pun di luar tim adalah cerita mana yang sedang mereka kerjakan, apa nilai poin mereka, dan apa kecepatan rata-rata tim itu. T

Kedua, kecuali PO adalah pengembang tingkat senior dengan pengetahuan yang mendalam tentang perangkat lunak, pendapat mereka tentang estimasi tugas seharusnya tidak terlalu berpengaruh. Pengembang adalah orang-orang yang memiliki pengetahuan tentang sistem dan orang-orang yang melakukan pekerjaan. Kecuali mereka semua baru keluar dari sekolah dengan keterampilan estimasi nol, estimasi mereka harus dikecualikan.

Itu tidak berarti perkiraan terkadang tidak dapat dipertanyakan. Jika demikian, ini perlu terjadi secara positif. Misalnya "apakah Anda menganggap bahwa kami telah melakukan separuh pekerjaan untuk" x "", atau "Anda ingat memasukkan waktu untuk melakukan Y?".

Intinya: para pengembang harus merasa aman untuk membuat perkiraan apa pun yang mereka inginkan, selama mereka melakukan upaya dengan itikad baik untuk menjadi akurat. Jika mereka mengatakan sesuatu membutuhkan waktu empat jam, Anda harus menerimanya.

Apa yang dikatakan pedoman Scrum tentang topik ini, atau apakah mereka mengatakan sesuatu tentangnya?

Mereka tidak mengatakan apa-apa sama sekali. Estimasi tugas bukan bagian dari scrum. Dengan scrum, estimasi berhenti di titik cerita. Estimasi tugas hanyalah alat untuk membantu tim melakukan lebih baik dalam memperkirakan poin cerita dengan memastikan mereka telah memikirkan semua pekerjaan yang diperlukan untuk menyelesaikan sebuah cerita.

Adalah tugas Master Sampah untuk memastikan proses scrum sedang diikuti. Ini termasuk memastikan bahwa tim tidak (secara konsisten) berkomitmen berlebihan pada jumlah pekerjaan yang dapat mereka lakukan dalam sprint.
Di satu sisi, itu berarti memerintah tim yang terlalu antusias, tetapi di sisi lain juga mendorong kembali ke Pemilik Produk jika dia menekan tim.

Salah satu cara yang baik untuk menjaga komitmen / ramalan tetap realistis adalah dengan melihat kisah-kisah yang benar-benar terwujud dalam beberapa sprint terakhir. Itulah yang telah dibuktikan oleh tim yang dapat mereka selesaikan, jadi tidak ada gunanya menarik lebih banyak pekerjaan ke dalam sprint, karena itu tidak akan selesai.

Seperti jawaban lain juga menunjukkan, tawar-menawar pada perkiraan yang diberikan oleh tim bukan bagian dari proses Scrum. Tim adalah yang paling akrab dengan perangkat lunak, jadi mereka harus tahu dengan baik seberapa banyak pekerjaan itu.

Yang bisa ditawar adalah ruang lingkup sebuah cerita. Jika Pemilik Produk berpikir bahwa suatu cerita diperkirakan jauh lebih besar atau lebih kecil dari yang mereka harapkan, maka mereka dapat meminta klarifikasi dari tim untuk melihat apakah pandangan pekerjaan yang perlu dilakukan sesuai dengan pihak-pihak.
Jika ceritanya benar-benar berhasil, Pemilik Produk dapat memutuskan untuk membaginya dalam beberapa cerita yang lebih kecil dan mendistribusikan fungsinya di atas cerita yang lebih kecil itu.

Tim bertanggung jawab untuk memberikan kualitas dan yang seharusnya tidak pernah terbuka untuk tawar-menawar.

Iya dan tidak.

Ya, tim sprint harus bernegosiasi dengan pemilik produk tentang apa yang masuk ke dalam sprint.

Tidak, pemilik produk tidak dapat menentukan berapa lama waktu yang dibutuhkan. Anda adalah ahlinya, bukan mereka.

Begini, Anda tidak harus berurusan dengan sampah semacam itu - manajer atau pimpinan tim Anda siap membantu Anda. Itu berarti berurusan dengan PM (atau bos mereka) sehingga Anda akan sukses. Yang mengatakan, itu tidak sulit.

"Tidak."

Apa yang akan mereka lakukan? Tulis kodenya sendiri?

Membiarkan perilaku ini adalah kegagalan Master Scrum. Pekerjaannya, pertama dan terutama, adalah melindungi tim. PO, untuk alasan yang diuraikan di atas, tidak terlihat. Scrum Master harus turun tangan dan, dengan cara yang positif, membingkai ulang konteks diskusi.

Tekanan seperti itu tentu saja akan mengarah pada tekanan kecepatan yang menurun, sesuatu yang sudah disebutkan OP. Jika tim secara konsisten tidak menyelesaikan sprint mereka, Scrum Master harus kembali masuk dan bertanya mengapa ini bisa terjadi. Dalam lingkungan yang benar-benar beracun, anggota tim mungkin tidak merasa jujur ​​dalam Retrospektif. Tetapi dalam situasi itu, Scrum Master memiliki tanggung jawab untuk mengeluarkan perilaku buruk dan melindungi tim.

Jika Anda menemukan diri Anda dalam situasi di mana Scrum Master Anda tidak dapat atau tidak akan melakukan hal-hal ini, maka Anda mungkin memerlukan Scrum Master yang berbeda. PO merespons tekanan khas. Tim, dalam mengalah, juga merespons seperti yang sering dilakukan manusia. Adalah tugas Scrum Master untuk melihat ini apa adanya dan menghentikannya. Tanggung jawab OP di sini adalah untuk mengemukakan ini dalam Retrospektif dan, jika perlu, kepada para pemimpin dan manajer. Jika itu masih belum menyelesaikannya, perbarui profil LinkedIn Anda dan temukan orang yang lebih baik untuk diajak bekerja sama.

Tim pengembangan produk (yaitu siapa saja mulai dari pemilik produk, hingga pengembang, hingga penguji) dapat mengikuti proses lincah, dan mendapatkan hasil yang baik mengingat orang yang kompeten dan harapan yang realistis.

Atau mereka dapat mengikuti proses yang dangkal menyerupai proses gesit.

PO itu mungkin berpikir dia akan mendapatkan hasil yang lebih baik dengan mencoba mendapatkan perkiraan waktu yang lebih rendah untuk tugas-tugas. Tentu saja itu tidak berhasil. Jika sesuatu memakan waktu tiga hari, Anda memberi saya banyak uang dan saya akan memberikan perkiraan bahwa saya bisa melakukannya dalam satu jam. Itu masih akan memakan waktu tiga hari. Jika Anda datang dan meneriaki saya karena belum selesai dalam satu jam seperti yang dijanjikan itu akan memakan waktu lima hari.

Yang dia capai adalah menghentikan proses gesit, dan menyerah pada semua hasil positif yang bisa dia dapatkan. Master scrum harus memiliki pengalaman, kekuatan, dan keberanian untuk mencegah hal ini. Jika manajemen membuat seseorang scrum master yang tidak memiliki pengalaman, atau tidak memberikan scrum master kekuatan untuk mencegah hal ini, itu adalah kesalahan mereka yang tangkas rusak. Jika scrum master tidak memiliki keberanian, maka ia berbagi kesalahan dengan PM.

Saya akan mengatakan itu sangat tergantung pada motivasi di sini. Tujuan umum estimasi adalah untuk mendapatkan gambaran tentang seberapa banyak yang dapat dicapai tim selama sprint apa pun, yang kemudian memungkinkan pekerjaan di masa mendatang dapat diperkirakan berdasarkan kecepatan itu. Misalnya, jika tim menyelesaikan 30 poin poin masing-masing sprint, dan dan ada sekitar 60 poin poin di depan Item X di backlog, Pemilik Produk kemudian dapat dengan wajar mengatakan Item X akan lengkap dalam waktu sekitar 6 minggu (berdasarkan pada sprint dua minggu standar).

Untuk membuat estimasi ini seakurat mungkin, bukan tidak pernah terjadi ketidaksetujuan tentang berapa banyak poin cerita dari item tertentu. Scrum sebenarnya mendorongnya. Ketidaksepakatan itu kadang-kadang bisa dipanaskan. Namun, tujuan akhir utama harus secara akurat memperkirakan kompleksitas PBI, tidak secara artifisial mengurangi upaya sehingga Anda dapat mencoba menjejalkan lebih banyak PBI ke dalam kecepatan tertentu.

Ini sebenarnya cara kerja perencanaan poker, pada prinsipnya. Setiap orang menjabarkan estimasi mereka. Scrum Master, kemudian mengambil estimasi tinggi dan rendah dan bertanya mengapa anggota tim berpikir itu harus tinggi / rendah. Ini memberi tim kesempatan untuk mendengar perspektif alternatif dari pekerjaan yang terlibat dan mendapatkan ide yang lebih baik tentang betapa rumitnya tugas itu sebenarnya. Setelah diskusi, semua orang melempar perkiraan mereka lagi. Proses ini dibilas dan diulang sampai ada konsensus umum tentang kompleksitas.

Dengan kata lain, tidak salah untuk menantang perkiraan Anda, mengingat penantang memiliki alasan mengapa mereka tidak setuju, selain dari yang mereka inginkan lebih rendah. Maka, adalah tanggung jawab Anda untuk meyakinkan tim Anda bahwa estimasi Anda benar, jika Anda masih merasa demikian.