Sprint planning
Perencanaan sprint minangka tahap awal ing sprint Scrum. Iki nemtokake ruang lingkup lan cara nindakake karya sajrone sprint. Kabeh tim Scrum melu ngrancang.
Sprint minangka wektu sing ditemtokake kanthi jelas sajrone karya tartamtu kudu rampung. Sprint mbutuhake perencanaan sadurunge diwiwiti. Kaping pisanan, sampeyan kudu nemtokake durasi lan tujuan sprint.
Ing lokakarya perencanaan, dhaptar tugas lan tujuan sprint disepakati. Penting kanggo ngisi tim kanthi motivasi sing tepat kanggo kerja, supaya saben anggota fokus ing sukses.
Yen sprint ora direncanakake kanthi apik, mula bisa nyebabake tim kasebut gagal. Pangembang ora bakal bisa ngatasi pangarepan sing ditindakake, amarga tugas kasebut ora nyata.
Pitakonan sing kudu ditimbang nalika ngrancang sprint:
- Pelanggan utawa pemilik piranti lunak ngumumake tujuan sprint, ing sadawane dalan nerangake carane entuk. Tim Scrum nemokake tugas apa sing bisa dirampungake ing sprint mangsa ngarep kanggo nggayuh tujuan kasebut.
- Pangembang nyebarake rencana kerja ing antarane awake dhewe, sing disepakati karo pelanggan piranti lunak.
- Pelanggan (pemilik) prodhuk tansah melu nggawe rencana sprint. Dheweke nemtokake target, lan tim pemrograman kudu ngerteni manawa bisa ditindakake kanthi cepet.
- Rencana kasebut kudu nggunakake backlog produk, informasi sing bisa ditambahake menyang rencana kasebut.
- Anggota tim kudu mungkasi rapat perencanaan kanthi pangerten sing jelas babagan apa sing dibutuhake kanggo entuk asil. Sampeyan bisa nampilake urutan tumindak ing mangsa ngarep ing backlog sprint.
Perencanaan ngirim ora ngluwihi rong jam saben minggu. Scrum Master kudu nerangake marang saben wong yen ana watesan wektu. Yen kabeh masalah kerja dirampungake kanthi cepet, rapat kasebut bisa rampung luwih awal tinimbang biasane. Ora ana durasi minimal kanggo rapat kasebut.
Evaluasi tugas
Nemtokake kerumitan karya ora perlu ngluwihi. Proses perencanaan ora mbutuhake persis, nanging paling ora ana perkiraan babagan kerumitan pembangunan. Tim kasebut ora mung kudu ngerti tujuane sprint, nanging uga mbandhingake gol karo kemampuan tim.
Kanggo netepake kerumitan, sampeyan bisa nggunakake ukuran sandhangan biasa kanggo saben wong (L, XL, XXL). Mesthi, iki ora menehi jaminan akurasi, nanging isih.
Supaya evaluasi kompleksitas luwih akurat, perlu saling pengertian. Anggota tim kudu mbukak pendapat lan ora wedi takon marang pemilik produk.
Kritik marang tim sawise karya rampung bisa nyebabake kasunyatan manawa nalika ngrancang sprint sabanjure, ramalan bakal kurang optimistis. Iki bakal mbantu tim supaya ora mbaleni kesalahan kasebut lan nglindhungi supaya ora ditaksir kanthi negatif ing mangsa ngarep.
Evaluasi kangelan ing TCTerms, TCTerms lan jam
Biasane, tim pangembang ngira kerumitan karyane sajrone wektu. Nanging sawetara tim Agile milih kanggo menehi rating kangelan ing poin utawa poin. Iki minangka indikasi sing luwih apik babagan total biaya sing dibutuhake kanggo ngetrapake item backlog utawa tugas liyane sing ditugasake.
Poin dianugerahi adhedhasar kerumitan lan volume karya. Kajaba iku, risiko sing bisa ditindakake dianggep. Nyetak nggunakake cara iki mbantu kanggo èfèktif break mudhun karya dadi langkah-langkah cilik.
Kanthi rutin nggunakake metode nyetak (titik) nalika ngrancang, tim duwe pangerten sing luwih apik lan akurat babagan wektu sing dibutuhake kanggo ngrampungake karya kasebut. Kajaba iku, ana uga kaluwihan liyane.
- Perkiraan wektu ora nganggep karya sing ora ana hubungane langsung karo proyek kasebut, sanajan mesthi bakal katon. Ngrembug masalah kerja liwat utusan, nganakake rapat - kabeh iki uga butuh wektu kanggo anggota tim.
- Emosi bisa mengaruhi pilihan tanggal. Skor nalika ngevaluasi karya ngilangi faktor iki.
- Evaluasi kerumitan karya lan, kanthi mangkono, kacepetan ngrampungake tugas bisa uga beda kanggo saben tim. Nggarap poin sing digawe ora bisa dianggep minangka indikator kacepetan. Tegese, ora ana tekanan psikologis ing tim.
- Kanthi nyebarake biaya tenaga kerja lan kerumitan kanthi bener, sampeyan bisa kanthi cepet lan tanpa konflik titik pamisah kanggo karya sing ditindakake ing antarane para peserta.
- Jumlah TCTerms ditampa kanggo ngrampungake tugas gumantung ing kerumitan sawijining, lan ora ing wektu ngginakaken. Mulane, programer bakal mikir babagan ningkatake efisiensi, lan dudu babagan suwene.
Kerugian estimasi kompleksitas yaiku asring disalahake. Contone, cara iki ora bisa digunakake kanggo ngevaluasi karyawan.
Tim kudu nggunakake sistem pemarkahan supaya luwih ngerti jumlah karya sing ditugasake lan menehi prioritas kanthi bener.
Rapat Scrum Saben dina
Lokakarya penting: ing dheweke, anggota tim nuduhake pendapat, komunikasi lan setuju babagan tumindak luwih lanjut. Rapat scrum saben dina uga dibutuhake kanggo nambah semangat tim lan ngumumake kabar saiki.
Stand-up minangka rapat singkat para peserta proyek utama: pemilik piranti lunak, programer lan master scrum. Struktur stand-up kasusun saka telung pitakonan.
- Apa sing bisa ditindakake wingi?
- Apa sing kita lakoni dina iki?
- Apa sing ngalangi kita entuk asil?
Njaluk pitakonan iki ngrangsang pangembangan lan mbantu ngenali masalah ing tim. Nalika saben peserta ngandhani carane dheweke mbantu nggayuh tujuan umum, iki nambah pemahaman bebarengan ing tim.
Penting kanggo elinga yen ora ana cithakan siji kanggo carane nindakake stand-up. Saben tim nganakake rapat miturut model dhewe, adhedhasar karakteristik tim kasebut.
Lan saiki ayo ngrembug apa sing dibutuhake kanggo stand-up sing sampurna lan kenal karo conto stand-up sing efektif.
Pisanan sampeyan kudu milih wektu sing cocog karo kabeh wong. Biasane stand-up kanggo tim saka kantor sing padha dianakake ing wiwitan dina kerja - antarane jam 9 lan 10 esuk. Iki menehi wektu kanggo ngrancang jadwal sing luwih apik kanggo dina. Yen anggota tim kerja ing wilayah sing beda-beda, banjur dipilih wektu sing cocog karo kabeh wong. Contone, yen sawetara anggota tim manggon ing California lan Sydney, banjur stand-up diwiwiti ing 15:30 wektu California. Mesthi, ngadeg sawise nedha bengi ora trep kanggo kabeh wong, nanging ndadekake iku bisa kanggo tetep ing tutul karo kolega ing sisih liya saka segara.
Nglacak produktivitas stand-up. Aja nganakake rapat kasebut nganti suwe - konsentrasi perhatian kudu tetep paling apik. Yen bisa, tahan stand-up ora luwih saka 15 menit.
Gunakake bal. Bisa dibuwang siji-sijine. Dadi saben wong bakal melu diskusi. Game iki mbantu kanggo njaga manungsa waé ing grup. Gunakake tim retrospektif. Stand-up digunakake ing akeh metodologi Agile, iki ora nyegah kita ngrembug babagan efektifitas stand-up ing retrospektif. Ana sing ketemu saben dina, tim liyane - kaping pindho saben minggu. Yen angel kanggo tim kanggo entuk manfaat saka stand-up, goleki alasan kanggo iki lan ngganti soko.
review Sprint
Tinjauan musim semi ditindakake ing tahap pungkasan sprint. Sampeyan kudu mriksa kenaikan produk lan nyetel backlog. Kabeh tim scrum lan kabeh pemangku kepentingan melu ing review asil sprint. Rapat kasebut dianakake kanthi format santai kanggo nambah interaksi peserta proyek.
Review Asil Sprint kalebu unsur ing ngisor iki:
- Pamilik piranti lunak nuduhake apa saka backlog wis rampung lan apa sing durung.
- Para programer ngrembug babagan apa sing ditindakake kanthi becik, ing ngendi alangan kasebut muncul, lan kepiye cara ngilangi.
- Tim pangembang nuduhake asil karyane sajrone sprint, lan kenaikan produk apa sing ditampa.
- Pemilik Produk nuduhake pikirane babagan backlog saiki. Iku uga menehi ramalan kanggo goal sabanjuré lan deadline kanggo implementasine.
- Saben uwong mbahas apa sing paling apik sing kudu ditindakake sabanjure adhedhasar pambiji pasar lan kapentingan pangguna.
- Ana ijol-ijolan tampilan babagan wektu, anggaran lan prospek kanggo nambah backlog.
Asil kasebut minangka backlog sing dianyari kanthi gol anyar kanggo sprint sabanjure. Backlog bisa diganti yen kahanan mbutuhake.
Sprint Retrospektif
Sprint Retrospective minangka bengkel sing ngrembug babagan carane nambah alur kerja sampeyan. Iki uga nggawe rencana perbaikan kanggo sprint sabanjure. Rapat kasebut biasane ditindakake sawise review sprint lan ora luwih saka telung jam. Pimpinan rapat kasebut yaiku Scrum Master.
Tujuan utama Sprint Retrospective kalebu:
- Analisis Sprint (karya peserta, asil lan masalah).
- Rembugan solusi sing bisa kanggo nambah alur kerja ing sprint sakteruse.
- Nggawe rencana kanggo implementasine dandan dening anggota tim sajrone implementasine proyek kasebut.
Scrum Master ngajak anggota tim kanggo menehi saran babagan carane nambah efisiensi pembangunan. Tim kasebut mbahas usulan kasebut lan menehi saran cara lan teknik tartamtu kanggo implementasine.
Ing pungkasan Sprint Retrospective, tim kudu nyorot sawetara saran perbaikan kanggo dileksanakake ing sprint sabanjure. Saran bisa ditindakake kapan wae, nanging Sprint Retrospective menehi kesempatan kanggo ndeleng luwih jero babagan adaptasi sing bisa ditindakake saka sudut pandang tim.
Ing kene kita mungkasi diskusi babagan metodologi Scrum. Sampeyan bisa sinau luwih lengkap babagan iki ing dokumentasi tematik utawa ing papan kerja pisanan sampeyan.