Saya seorang pengembang yang mengerjakan aplikasi seluler baru untuk Android dan iOS dengan komponen backend yang besar. Kami telah berada di tiga sprint proyek ini, dan kami menggunakan Scrum dengan semua upacara (perbaikan, perencanaan, harian, retrospektif, dll.).

Dalam dua sprint, tim harus bekerja (tidak dibayar) lembur dan akhir pekan, karena manajemen sangat khawatir kami tidak akan menyelesaikan komitmen sprint tepat waktu. Semua orang bekerja keras, tetapi beberapa ketergantungan eksternal dan perkiraan optimis membuat kami berjuang untuk menyelesaikan semua cerita sprint.

Dalam pengalaman saya memiliki sebagian kecil cerita yang tidak selesai selama beberapa sprint agak normal, dan mereka dapat ditangani pada yang berikutnya. Tetapi manajer proyek kami mengatakan itu adalah kesalahan kami karena kami membuat estimasi sendiri, jadi kami harus menyelesaikan semua item dalam sprint.

1. Apakah ini variasi Scrum yang dapat diterima / umum yang tidak saya sadari?

2. Bagaimana Anda menyarankan agar saya menindaklanjutinya?

Beberapa hal menonjol bagi saya.

Gagasan yang dimiliki manajemen bahwa tim berkomitmen pada serangkaian pekerjaan tidak konsisten dengan versi terbaru dari Panduan Scrum. Kata "komit" atau "komitmen" hanya digunakan dua kali dalam versi terbaru dari Panduan Scrum (November 2017) - sekali ketika mendaftarkan Nilai Scrum dan sekali untuk menunjukkan bahwa "orang secara pribadi berkomitmen untuk mencapai tujuan Tim Scrum ".

Gagasan tujuan penting bagi Scrum. Tidak hanya organisasi dan tim memiliki tujuan yang luas, tetapi di Scrum, setiap Sprint memiliki Tujuan Sprint yang didefinisikan pada Perencanaan Sprint sebagai kolaborasi antara Pemilik Produk dan Tim Pengembangan. Sasaran Sprint dipenuhi dengan mengimplementasikan item dari Product Backlog, tetapi tidak hanya "menyelesaikan pekerjaan ini" dan sering tidak mewakili Sprint Backlog yang lengkap. Artinya, Anda harus dapat mencapai Sprint Goal tanpa menyelesaikan setiap Item Backlog Produk yang dipilih untuk Sprint atau setiap item tunggal di Sprint Backlog. Pemikiran saya saat ini adalah bahwa pekerjaan yang diperlukan untuk mencapai Tujuan Sprint harus sekitar 60-70% dari kapasitas tim Anda, namun Anda memperhitungkan kapasitas. Namun, organisasi yang berbeda akan berbeda, tetapi '

Bekerja lembur dan akhir pekan juga merupakan praktik Pengembangan Perangkat Lunak anti-Agile. Salah satu prinsip yang mendasarinya adalah bahwa semua pemangku kepentingan dari suatu upaya dapat bekerja dengan kecepatan yang berkelanjutan. Hari dan akhir pekan yang panjang, bahkan jika dibayar, tidak berkelanjutan untuk tim.

Pada titik ini, ada beberapa langkah selanjutnya. Scrum Master tim harus mendidik manajemen tentang nilai-nilai dan prinsip-prinsip Pengembangan Scrum dan Agile Software (seperti "komitmen" dan "kecepatan berkelanjutan"). Tim harus bekerja pada kemampuannya untuk meramalkan pekerjaan dan menegosiasikan ruang lingkup dengan Pemilik Produk. Tim juga harus mengidentifikasi dan bekerja untuk menyelesaikan atau mencegah hambatan yang mengarah pada situasi ini (menghilangkan atau mengurangi dampak ketergantungan eksternal).

Situasi yang Anda gambarkan, di mana manajemen mengharuskan tim bekerja lembur untuk menyelesaikan semua cerita yang direncanakan, adalah salah satu alasan mengapa literatur Scrum berhenti menggunakan istilah "komitmen." Komitmen sejati hanya dapat diberikan ketika semua ketidakpastian dikeluarkan, termasuk ketidakpastian tentang dependensi pihak ketiga, berapa banyak pekerjaan setiap item, berapa banyak waktu yang tersedia bagi setiap orang dengan mempertimbangkan penyakit, dll.

Salah satu ide dasar Scrum adalah bahwa tim bekerja dengan kecepatan yang berkelanjutan, yang pada dasarnya berarti bekerja dengan jam normal tanpa lembur (dibayar atau tidak dibayar). Ini secara langsung berarti bahwa Anda tidak mengalami variasi Scrum yang dapat diterima.

Apa yang dapat Anda lakukan tergantung pada peran Anda.

Jika Anda seorang pengembang, maka yang terbaik yang dapat Anda lakukan adalah

• (secara kolektif sebagai tim pengembang) menolak untuk "berkomitmen" untuk melakukan lebih banyak pekerjaan daripada yang Anda yakini dapat Anda lakukan dalam sprint. Ini mungkin jauh lebih sedikit daripada apa yang manajemen inginkan untuk Anda lakukan.
• tetap fokus pada menyelesaikan pekerjaan, daripada memulai pada tugas-tugas baru. Jika Anda melihat bahwa beberapa pekerjaan tidak dapat diselesaikan, tunjukkan ini sedini mungkin sehingga rencana dapat disesuaikan.

Jika Anda seorang master Scrum, maka Anda benar-benar dapat membuktikan nilai Anda dengan mendidik manajemen tentang Scrum. Beberapa poin yang menonjol bagi saya:

• Sebagaimana dinyatakan dalam paragraf pertama, tim tidak memberikan komitmen selama perencanaan sprint, tetapi mereka memberikan perkiraan pekerjaan yang mereka harapkan telah selesai.
• Meskipun tim harus menghindari pekerjaan yang belum selesai pada akhir sprint, situasi ini hampir tidak dapat dihindari pada awal proyek (atau setelah perubahan komposisi tim). Berapa banyak kerja tim yang dapat dicapai secara realistis dalam sprint hanya dapat ditentukan berdasarkan angka historis dari beberapa sprint terakhir tim dalam komposisi ini. Di awal proyek, angka sejarah seperti itu tidak ada, jadi tim yang berhasil dalam 3 sprint pertama persis apa yang direncanakan untuk setiap sprint lebih merupakan kecelakaan daripada perencanaan yang baik. Setelah sekitar 5 sprint dengan kecepatan berkelanjutan, ada cukup data untuk mendapatkan ide yang masuk akal berapa banyak pekerjaan yang dapat diselesaikan tim secara realistis dalam sprint.

PM Anda tidak memiliki bisnis yang terlibat dalam scrum Anda.

PM Anda tidak punya bisnis yang meminta lembur tanpa bayaran kepada Anda.

Hal yang jelas harus dilakukan adalah memperkirakan semua tugas sedemikian rupa sehingga Anda dapat menjamin mereka akan selesai tepat waktu. Maka Anda harus dapat pergi ke pub dengan cara kedua, karena jelas jika meremehkan tugas berarti Anda menyelesaikannya secara gratis, maka melebih-lebihkan berarti Anda punya waktu tanpa bekerja.

Ada beberapa aspek dalam hal ini, tetapi pada tingkat tinggi, ya - PM pasti ingin memahami dengan jelas mengapa pekerjaan yang direncanakan belum selesai. Namun, ini harus diangkat (dan diselesaikan) dalam retrospektif. Dari sisi dev, ada banyak faktor yang dapat menyebabkan kegagalan sprint.

Beberapa hal yang mungkin ingin Anda pertimbangkan:

Terlalu banyak dalam sprint

Jika Anda secara teratur melakukan terlalu banyak pekerjaan, maka sprint akan gagal. Kecepatan sprint harus dilacak dari waktu ke waktu untuk mengetahui berapa jumlah titik (atau hari) yang optimal.

Alokasi sumber daya

Pastikan bahwa perencanaan sprint mencukupi untuk kegiatan non-pengembangan seperti upacara, liburan, pelatihan, admin, dukungan, dan proyek lainnya, dll. Secara otomatis dengan asumsi setiap orang mengembangkan setiap menit setiap jam mereka secara fisik di kantor tidak praktis dan akan segera menempatkan Anda pada kaki belakang dari mulai.

Perkirakan variasi

Anda sedang melakukan penyempurnaan, tetapi adakah tugas-tugas tertentu yang selalu dikuasai? Biasanya ini karena persyaratan yang hilang atau tidak jelas. Jika persyaratannya tidak jelas, cerita seharusnya tidak membuatnya menjadi sprint kecuali jika sudah disempurnakan atau spike telah direncanakan.

Kecepatan

Jika kecepatannya dilacak dengan benar, jumlah sebenarnya cerita harus menjadi jelas. Itu tidak berarti mereka akan selalu selesai tepat waktu, tetapi itu akan membuat banyak hal lebih mudah.

Niat baik

Pada proyek apa pun, niat baik terbatas. Jika Anda terus-menerus bekerja selama berjam-jam untuk memberikan, semangat kerja akan menderita dan devs akan kelelahan - ini adalah kegagalan manajemen proyek . Seperti yang sudah saya jelaskan, pastikan perencanaan sprint hanya menjadwalkan sejumlah cerita realistis menggunakan kecepatan dan paku untuk membantu Anda sepanjang jalan.

Sepatu berduri

Jika suatu item disempurnakan dengan buruk atau hanya terbuat dari wol, jangan takut untuk melakukan spike untuk memberikan perkiraan yang lebih baik untuk sprint selanjutnya. Ya, beberapa orang hanya buruk dalam estimasi tetapi sebagian besar waktu, fakta lengkap hanya tidak diketahui pada saat itu. Idealnya, ini seharusnya sudah tercakup dalam penyempurnaan atau diambil lebih awal oleh PO, tetapi kadang-kadang mereka dapat lolos dari sprint. Pengembang harus mendorong kembali pada hard ini karena ini dapat dengan mudah torpedo sprint yang jika tidak berjalan dengan baik.

Tidak, ini bukan bentuk Agile yang diakui , karena satu alasan yang sangat penting: jika Anda berkomitmen untuk memberikan segalanya , Anda tidak melakukan Agile, Anda melakukan Waterfall - dan jika Anda berpikir Anda menggunakan Agile sebagai gantinya , Anda mungkin melakukan Waterfall dengan buruk , pada saat itu. Saya yakin Anda pernah mendengar gergaji tua "bagus, cepat, murah, pilih dua," benar? Dengan pengembangan perangkat lunak, ini lebih seperti "semua fitur yang dikirim, tepat waktu, sesuai anggaran, pilih yang pertama atau dua lainnya". Waterfall memilih yang pertama, dan Agile mengambil yang kedua.

Jika Anda akan gesit, Anda perlu fleksibilitas untuk menjatuhkan Cerita dari Sprint yang tidak dapat Anda selesaikan tepat waktu. Salah satu cara yang mungkin untuk melakukan ini adalah meminta Pemilik Produk Anda untuk menilai cerita menggunakan prioritas MoSCoW. Ini akan melibatkan memilih tidak lebih dari 60% dari Cerita (dengan total Poin Cerita) sebagai Must Have yang akan selesai, 20% sebagai Should Have yang harus Anda selesaikan oleh proyek menyimpulkan dan Minimum Viable Product dirilis, 20% sebagai Bisa Punya yang mungkin selesai jika Anda punya waktu, dan apa pun di luar lingkup rilis saat ini sebagai Tidak akan Punya. Penting juga untuk dicatat bahwa ketika digabungkan, Must Have harus memiliki cukup daging untuk tulang mereka untuk menciptakan Produk yang Layak Minimum tanpa perlu memasukkan item apa pun dari kategori lain.

Menentukan apakah akan menjatuhkan item dari Sprint Backlog adalah tanggung jawab Pemilik Produk, setelah diminta oleh Tim, dan semua item yang dikeluarkan dari Sprint Backlog akan dinilai oleh Pemilik Produk, dan kemudian menjadi dijatuhkan sepenuhnya dari proyek, atau ditempatkan di Backlog Proyek dalam posisi yang sesuai peringkat.

Dalam hal ini, saya menduga bahwa Pemilik Produk Anda adalah Manajer Proyek Anda, bukan? Adalah tugasnya untuk menentukan tugas mana yang harus dijatuhkan, jadi dia tentu tidak seharusnya menyalahkan Anda karena terlalu berkomitmen, karena itu adalah tugasnya untuk membatalkan tugas untuk mengimbangi itu, dan tampaknya dia tidak melakukannya.

Dia benar, bahwa seharusnya tidak ada carry-over antara sprint. Tim Scrum memiliki carry-over antara sprint adalah anti-pola dan bukan sesuatu yang diterima Scrum sebagai hasil yang valid.

Tapi, pendekatannya tidak bagus.

Selama sprint, tim harus terus memantau pekerjaan yang sedang dilakukan dan jika mereka dapat menjaga komitmen mereka dalam perencanaan sprint tentang menyelesaikan cerita yang dipilih. Jika tim mengidentifikasi, bahwa itu tidak dapat menyelesaikan semua cerita, itu harus bertemu dengan PO dan memilih cerita untuk dihapus dari sprint. Dengan melakukan itu, semua orang BERHENTI BEKERJA DI CERITA, dan berfokus untuk menyelesaikan cerita yang tersisa. Ingat: Itu selalu lebih baik untuk menyelesaikan satu cerita sepenuhnya daripada memiliki dua cerita setengah jadi.

Masalah ketergantungan eksternal dan estimasi yang tidak tepat adalah alasan mengapa Retrospektif ada. Selama Retro, tim harus merefleksikan dan mengidentifikasi masalah-masalah ini. Dan tim kemudian harus menemukan dan mengimplementasikan solusi untuk masalah-masalah itu. Estimasi dapat dibuat lebih tepat dengan lebih mengenal sistem dan pengalaman sederhana. Ketergantungan eksternal lebih sulit, tetapi bukan tidak mungkin untuk diperbaiki.

PM Anda ( apa yang bahkan PM lakukan pada tim Scrum ?? ) tidak boleh diizinkan oleh Scrum Master untuk memaksa Anda menyelesaikan semua cerita. Sebaliknya, jika ia mengeluh, ia harus menyimpannya untuk Retrospektif. Dan yang lebih baik lagi, harus menjadi bagian dari penyelesaian masalah yang mencegah agar cerita tidak selesai tepat waktu.

Apakah ini variasi Scrum yang dapat diterima / umum yang tidak saya sadari?

Tidak ada . Ini sepenuhnya salah. Saya mungkin bisa bersimpati dengan lembur yang dibayarkan , jika PO membuat kesalahan dengan memberikan perkiraan sebagai fakta sebelum sprint berakhir, tetapi lembur yang tidak dibayar benar-benar konyol dan akan membuat saya mencari pekerjaan lain ASAP.

Bagaimana Anda menyarankan agar saya bertindak tentang hal ini?

Dalam pengalaman saya, orang-orang yang begitu banyak rel tidak akan mendengarkan argumen logis. Satu-satunya cara bagi mereka untuk melihat betapa rusaknya itu adalah menunjukkan , bukan memberi tahu. Jadi lain kali saat Anda memperkirakan dan berkomitmen, komit dengan jumlah sekecil mungkin . Berkomitmen untuk menyelesaikan tiket kecil di ujung sprint. Satu yang bisa Anda lakukan dalam sehari. Lihat bagaimana reaksi PM Anda. Kemudian mulai diskusi dari sana pada sistem apa yang digunakan untuk dan apa sistem yang harus digunakan untuk.

Secara umum, pada awal proyek, ketika kami memutuskan kecepatan tim, kami memilih angka konservatif (lebih rendah dari biasanya) mengingat fakta bahwa itu adalah tim baru, akan butuh sedikit waktu bagi tim untuk menyelesaikannya , memahami satu sama lain, memahami persyaratan fungsional dan NFR, dll. Pada dasarnya, setelah beberapa sprint pertama kami mengoptimalkan kecepatan tim dan jelas kecepatan hanya akan meningkat dari titik itu.

Tidak ada gunanya melakukan kecepatan yang lebih tinggi di awal dan meregangkan tim untuk mencapainya.

Satu hal lagi adalah bahwa, dalam skenario satu kali, di mana ada komitmen pengiriman yang tidak dapat dilewatkan, manajer proyek mungkin memberi tekanan pada tim untuk peregangan, bekerja lembur dan bekerja selama akhir pekan. Tapi kemudian itu harus dianggap sebagai pengecualian dan bukan norma kerja. Bekerja seperti itu dapat meningkatkan kecepatan dalam jangka pendek, tetapi dalam jangka panjang akan menjadi kontraproduktif, karena dapat mengakibatkan masalah kualitas kode, masalah kelelahan tim, tim yang tidak bahagia dengan motivasi rendah, dll.

FAQ Komitmen

Apakah perilaku ini normal?

Saya tidak yakin.

Apakah ini mengejutkan?

Tidak. Beberapa orang akan selalu memahami "komitmen" yang berarti segala sesuatu dalam komitmen harus diselesaikan.

Apakah itu ide yang bagus?

Tidak. Pengembangan tangkas memiliki keberlanjutan sebagai topik utama: Bekerja hanya sebanyak / lama / sekeras yang dapat Anda lakukan tanpa batas. Itu adalah ide yang masuk akal di sebagian besar waktu. (Jika manajemen Anda tidak menerima ini, mereka tidak boleh menyebut organisasi mereka gesit.)

Apa yang harus kita lakukan?

• Jelaskan bahwa konten sprint didasarkan pada perkiraan . "Perkiraan" berarti bahwa kadang-kadang hanya akan benar - dan biasanya salah. Ketika salah, terkadang terlalu rendah dan kadang terlalu tinggi.
• Jelaskan bahwa jauh lebih mudah untuk mengubah perilaku estimasi daripada kecepatan kerja.
• Jelaskan bahwa ketika tim dihukum karena memperkirakan terlalu tinggi, itu hanya akan memperkirakan lebih rendah dan manajemen akan kehilangan lebih banyak kemajuan seperti itu daripada dengan mendorong beberapa konten dari satu sprint ke sprint berikutnya sesekali.

Yang menyenangkan adalah: Manajer proyek Anda akan mengetahui semua hal ini dan mengakui mereka sebagai yang benar. Hanya saja dalam jangka pendek seseorang dapat memilih untuk mengabaikannya.

Saya tidak setuju dengan tim manajemen Anda. Mereka seharusnya tidak membuat Anda bekerja lembur untuk menyelesaikan sprint.

Namun, gagasan bahwa komitmen tidak mungkin datang dari kesalahpahaman pengembangan perangkat lunak. Saya telah melihat banyak tim mencoba memprediksi cerita yang dapat mereka selesaikan dalam sprint dengan jumlah poin cerita yang telah mereka selesaikan dalam sprint sebelumnya. Jika itu mungkin akan dikatakan bahwa pengembangan perangkat lunak adalah linier, yaitu jika saya bekerja dua jam saya mendapatkan dua kali lebih banyak dari yang dilakukan dalam satu jam.

Pengembangan perangkat lunak itu kreatif, dan karenanya, tidak linier. Ini adalah praktik yang lebih baik bagi tim untuk memberi tahu manajemen apa yang dapat mereka lakukan dalam sprint dan kemudian menyampaikan kisah-kisah itu. Jika Anda secara konsisten kehilangan komitmen Anda, Anda mungkin tidak tahu tentang ruang lingkup cerita untuk memulai atau Anda sedang ditekan oleh pemilik produk Anda untuk mengambil lebih banyak.

Dalam kasus sebelumnya, Anda harus memastikan bahwa Anda memahami ruang lingkup cerita sebelum Anda setuju untuk meneruskannya. Jika yang terakhir, Anda memiliki masalah budaya dan ada sedikit yang bisa dilakukan.