Manajer proyek saya tidak menerima carry-over di Scrum - apakah itu normal?


52

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?


66
.. apalagi, ketika kontrak kerja Anda memungkinkan kerja lembur yang tidak dibayar dan bekerja di akhir pekan, dan atasan Anda dapat memerintahkan Anda untuk melakukannya atas kehendak mereka sendiri, maka saya khawatir tindakan terbaik adalah dengan menambahkan margin keselamatan setidaknya faktor. dari 2 untuk setiap sprint eastimation, atau untuk menemukan majikan yang berbeda.
Doc Brown

59
Tidak, ini bukan praktik yang dapat diterima sejak penghapusan roman galley. Ini adalah serangan panik khas manajer proyek yang kompetensinya masih bisa dikembangkan lebih lanjut. Menendang orang di pantat dengan anggapan bahwa mereka tidak melakukan yang terbaik tanpa perkiraan dan situasi yang menantang tidak akan membantu mengatasi kekacauan ini. Tetapi masalah ini terlalu luas untuk dibahas di sini ...
Christophe

27
Tanyakan kepada diri Anda sendiri apa pandangan manajemen jika Anda menyelesaikan "komitmen" sprint Anda sebelumnya. Apakah tim akan mendapatkan sisa sprint (termasuk dibayar)?
Qwerky

13
Seorang Project Manager tidak normal di Scrum. Panduan Scrum cukup eksplisit tentang peran: Scrum Master, Pemilik Produk, Tim Scrum. Tidak disebutkan PM. Bahkan, banyak orang (termasuk sebagian besar penandatangan Agile Manifesto) telah berulang kali mengklaim bahwa proyek merugikan kelincahan. Juga, Anda adalah satu-satunya yang memutuskan itu dapat diterima. Jika itu tidak dapat Anda terima, poles CV Anda dan cari perusahaan yang lebih baik.
Blueriver

5
Dua hal: Komitmen dibuat oleh tim, bukan PM, jadi berkomitmen untuk kurang sebagai perbaikan langsung, namun masalah yang lebih besar adalah apa yang terjadi jika Anda tidak memberikan? Apa konsekuensinya? Biasanya PM, TPM, Scrum master, pemilik produk, dll ... didorong untuk bekerja dengan tim karena ... mereka tidak memiliki wewenang nyata atas tim dalam struktur matriks Agile / SCRUM cocok untuknya. Jadi ini mungkin tidak lebih dari sebuah @ mencoba untuk memajukan karir mereka dengan mengorbankan orang lain.
RandomUs1r

Jawaban:


75

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).


2
Jawaban yang bagus - Anda bahkan dapat memperbaikinya dengan menyorot atau TL; DR poin penting: komitmen hanya dapat datang secara bebas dari pengembang sendiri dan pekerjaan harus berkelanjutan
Falco

Juga, jika Anda memiliki penundaan karena ketergantungan dari tim lain, jumlah waktu Anda diblokir harus terlihat oleh tim Anda.
luizfzs

2
Saya percaya mereka mengubah kata-kata menjadi 'perkiraan'; seperti ramalan cuaca, bisa salah, memiliki tingkat kepastian, dan cerita yang diselesaikan dalam sprint membantu tim menjadi lebih baik dalam memperkirakan di masa depan.
George Stocker

1
@ GeorgeStocker Ya - kata "perkiraan" digunakan alih-alih "komit" sehubungan dengan Sprint Backlog dan item kerja tertentu. Namun, "komitmen" dan "komitmen" digunakan sehubungan dengan tujuan tim.
Thomas Owens

1
dan juga ya, 9 wanita tidak bisa menghasilkan 1 bayi dalam 1 bulan :)
Michael Durrant

33

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.

Ya, dan ketidakpastian dikeluarkan hanya ketika proyek selesai :-)
Christophe

3
Kebanyakan orang sangat pandai dalam prediksi. Satu-satunya pengecualian adalah tentang masa depan.
Michael Durrant

21

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.


1
"PM Anda tidak punya urusan terlibat dalam scrum Anda." Di bawah metodologi Agile tertentu (yaitu DSDM), mereka melakukannya. Pure Scrum bahkan tidak mengenali "Manajer Proyek" sebagai peran yang ada.
nick012000

3
Jika kontrak kerja mengatakan mungkin ada lembur yang tidak dibayar, PM pasti memiliki bisnis untuk memintanya. Dan jika tim dilakukan lebih awal dari yang diperkirakan, itu lagi merupakan "kesalahan" dari tim sehingga tidak ada alasan untuk menjadi malas setelahnya, lebih baik mulai memperkirakan untuk sprint berikutnya sehingga estimasi tidak jauh ^^ (berbicara dalam logika PM) ). Bukannya saya setuju dengan cara manajemen menangani hal ini, tetapi argumen Anda juga tidak berlaku (kecuali untuk PM yang terlibat dalam scrum, tergantung pada beberapa kendala - sebagai pemangku kepentingan, ia dapat terlibat, hanya saja tidak menghalangi dia saat ini).
Frank Hopkins

Respons logis lainnya untuk dipaksa berkomitmen pada estimasi adalah menjadwalkan waktu untuk meneliti semua hal yang tidak diketahui sebelum Anda dapat memperkirakan tugas yang sebenarnya.
Robin Bennett

Saya tidak pernah bekerja di mana pun scrum / gesit dijalankan dengan cara yang sama, tetapi dalam goresan luas, sementara PM tidak diakui sebagai peran tertentu, mereka sering mengelola anggaran dan risiko. Akibat wajar dari ini adalah bahwa mereka benar-benar tidak memiliki kepentingan dipegang seberapa baik / buruk pembangunan akan dan mereka dapat meminta lembur yang belum dibayar meskipun dalam pengaturan yang baik-kehendak. Bagaimana ini difasilitasi dalam tim akan sangat bervariasi dari satu toko ke toko. Di beberapa tempat, mereka secara ketat menyerahkan kepada scrum master, di tempat lain mereka berpartisipasi dalam berdiri (bertentangan dengan praktik yang diterima).
Robbie Dee

DSDM bukan metodologi tangkas, ini adalah tumpukan mengepul **** ****** **** **** ******* yang disukai manajer karena itu memberi mereka banyak Keterlibatan dalam proses.
gbjbaanb

12

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.


2
Saya tidak yakin "push back from the PM" adalah framing paling berguna. Seluruh tim, secara keseluruhan, ingin meningkatkan proses mereka — itulah tujuan retrospektifnya — dan semua masalah yang Anda identifikasi adalah hal-hal hebat yang perlu dipertimbangkan sebagai bagian dari diskusi itu, tetapi saya pikir paling berguna untuk berpikir itu sebagai "bagaimana tim dapat membantu memastikan bahwa perkiraan yang diberikan oleh tujuan sprint lebih berguna di masa depan?" daripada seorang PM mendorong kembali tim karena tidak menyelesaikan tugas.
Zach Lipton

1
Saya pikir Anda sampai ke inti masalahnya. PM harus mengemukakan ini sangat penting untuk memahami mengapa proyek ini terlambat, tetapi alasan # 1 adalah 'perkiraan salah' karena alasan apa pun. (dan alasan # 1 untuk itu adalah karena PM tidak suka perkiraan tinggi!)
Ewan

Bagi saya, ini jelas jawaban terbaik sejauh ini. +1
angryITguy

Bagaimana kalau kita menyebut 'pushback' (yang menyiratkan pendekatan yang berpotensi antagonis) sebagai "pertanyaan" yang tampaknya lebih netral dan efektif bagi saya?
Michael Durrant

1
@MichaelDurrant et al. Cukup adil - Saya telah memodifikasi kata-kata dari paragraf pertama.
Robbie Dee

10

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.


dimanapun saya pernah melihat Scrum digunakan, air terjunnya.
gbjbaanb

6

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.


Saya tidak setuju dengan komentar "bukan hasil yang valid". Meskipun ini bukan hasil yang diinginkan , tim scrum harus menyadari bahwa beberapa cerita tidak masuk akal dari waktu ke waktu. Ini tentu bukan hasil yang normal, jika Anda gagal menyelesaikan lebih dari satu cerita, itu menunjukkan Anda melakukan sesuatu yang salah, tetapi untuk mengatakan itu tidak pernah hasil yang valid sedikit kuat menurut saya. Saya lebih suka memiliki tim yang memilih terlalu banyak pekerjaan untuk dilakukan daripada memilih tidak cukup.
Bryan Oakley

5

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.


diputuskan, meskipun perspektif over-time yang tidak dibayar dapat masuk akal jika kontrak dirumuskan dengan cara itu (dan upah umum dihitung untuk ini, yaitu di atas rata-rata - atau ada manfaat lain).
Frank Hopkins

4

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.


1
Bagus! +1. Dengan risiko rambut membelah, Anda tidak "memutuskan" kecepatan, itu hanya sesuatu yang muncul setelah beberapa sprint tapi ya, dengan sprint 0 (atau berapa pun Anda menghitungnya) - Anda menumpuk papan dengan banyak cerita yang Anda yakini dapat dicapai.
Robbie Dee

2

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.


2

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.

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.