Kisah Panganggo
Kisah pangguna minangka cara sing efektif kanggo nyatakake syarat kanggo piranti lunak ing pangembangan. Crita kasebut ngemot saran singkat kanggo pangguna piranti lunak kasebut.
Wiwit ing metodologi Scrum, nyetel gol biasane dadi prerogatif saka pelanggan utawa pemilik piranti lunak, dheweke dianggep minangka cara utama kanggo mengaruhi proses pangembangan. Saben Crita Panganggo duwe watesan babagan jumlah teks lan kerumitan presentasi. Sejarah paling asring ditulis ing lembaran cilik, sing mbatesi volume dhewe.
Thanks kanggo crita pangguna, sampeyan bisa nyathet kepinginan klien lan cepet nanggapi panjaluk pasar.
Kisah Panganggo kudu dianggep minangka ukuran syarat sing simplistik amarga ora kalebu prosedur tes sing ditampa. Kompilasi crita pangguna kudu tundhuk karo prosedur diakoni. Iki bakal mesthekake yen Crita pangguna entuk target.
Struktur crita katon kaya mangkene: "Minangka pangguna <tipe pangguna>, aku pengin nindakake <tindakan> kanggo entuk <asil>" (Minangka pemilik produk aku pengin ...). Struktur kasebut ora mung prasaja, nanging uga bisa dingerteni kabeh wong.
Keuntungan nggunakake crita pangguna:
- Crita cilik lan gampang digawe.
- Mbantu kabeh pemangku kepentingan kanggo ngrembug babagan proyek lan dhukungan.
- Ora mbutuhake pangopènan sing terus-terusan.
- Relevan mung nalika digunakake.
- Ngapikake interaksi karo klien.
- Thanks kanggo wong-wong mau, sampeyan bisa mbagi proyek kasebut dadi tahapan cilik.
- Nggampangake karya ing proyek kanthi syarat sing kurang dimangerteni.
- Nyederhanakake evaluasi tugas.
Kekurangan crita pangguna:
- Tanpa persetujuan sadurunge, prosedur bisa nggawe angel digunakake minangka basis kanggo persetujuan.
- Panggunaan kasebut mbutuhake kontak sing cedhak karo klien sajrone kabeh proyek, sing kadhangkala nggawe alur kerja angel.
- Dheweke duwe kekurangan nalika nggawe skala ing proyek gedhe.
- Langsung ana hubungane karo tingkat profesional pangembang.
- Digunakake kanggo miwiti diskusi, nanging ora bisa mungkasi diskusi, lan ora digunakake kanggo dokumentasi sistem.
Backlog
Backlog produk minangka tugas saiki ing wangun dhaptar, disusun miturut prioritas. Dhaptar kasebut digawe adhedhasar peta dalan (peta dalan) proyek kasebut lan titik-titik kasebut. Tugas sing paling penting biasane ana ing ndhuwur dhaptar. Iki perlu kanggo mangerteni karya sing kudu ditindakake dhisik.
Tim pangembangan milih kacepetan ngrampungake tugas backlog preduli saka kepinginan pelanggan, nanging adhedhasar kualifikasi lan pengalaman saka sprint kepungkur. Iku arang banget undesirable kanggo "nyetel" programer. Tim kasebut dhewe milih tugas saka backlog miturut pertimbangan lan kemampuan dhewe. Eksekusi ditindakake tanpa gangguan (Kanban) utawa sawetara iterasi (Scrum).
Loro kondisi backlog penting
Inti saka backlog produk kalebu peta dalan, proposal, lan kahanan eksekusi. Epik ngemot kahanan lan Crita Panganggo. Ayo goleki conto peta dalan sing khas.

Nggawe situs web "Tim ing Angkasa" minangka proposal pisanan saka peta dalan. Perlu dipérang dadi epik (ing gambar ditampilake ing werna ijo, biru lan pirus) lan Crita Panganggo kanggo saben epik.

Pelanggan piranti lunak nggawe siji dhaptar saka sawetara Kisah Panganggo. Yen perlu, dheweke bisa ngganti urutan crita sing dieksekusi, supaya para pangembang bakal ngatasi salah sawijining epik sing paling penting (kiwa) utawa mriksa cara kerja pesenan tiket diskon. Kanggo nindakake iki, sampeyan kudu ngetrapake crita saka epik (tengen). Loro-lorone opsi bisa dideleng ing ngisor iki.

Adhedhasar faktor apa sing kudu diutamakake pelanggan?
- Relevansi kanggo pangguna.
- Anane umpan balik.
- Kompleksitas pembangunan.
- Hubungan antarane tugas (kanggo ngrampungake "B", sampeyan kudu nindakake "A" dhisik).
Prioritas ing karya ditemtokake dening pelanggan, nanging pihak liya bisa nyatakake pendapat babagan iki. Sukses backlog gumantung, antarane liyane, ing pendapat pelanggan lan programer. Bebarengan, padha bisa entuk asil sing luwih apik lan mesthekake pangiriman pas wektune produk rampung.
Carane njaga backlog
Yen backlog wis digawe, banjur sampeyan kudu ngganti kanthi periodik sajrone karya luwih lanjut. Pelanggan piranti lunak kudu nggawe manawa backlog wis disusun kanthi bener sadurunge saben rencana pengulangan anyar. Iki bakal mbantu njlentrehake prioritas utawa ngganti soko sawise analisis pengulangan pungkasan. Nyetel backlog ing Agile kadhangkala disebut "dandan" utawa "refinement" utawa "pangopènan backlog".
Yen backlog wis cukup gedhe, mula pelanggan kudu nglumpukake tugas kanthi eksekusi jangka pendek lan jangka panjang. Tugas jangka pendek kudu ditliti sadurunge diwenehi status iki. Sampeyan kudu nyipta Kisah Panganggo, ngerteni kabeh nuansa ing tim.
Kanggo tugas jangka panjang, mesthine para pangembang menehi penilaian. Iki bakal luwih gampang kanggo nggawe prioritas. Mbok menawa ana sing bakal diganti, nanging tim bakal nambah pangerten babagan tugas lan ngrampungake tugas kanthi luwih cepet.
Backlog minangka komponen penting ing antarane pelanggan lan tim pemrograman. Pelanggan bisa tansah ngganti prioritas adhedhasar umpan balik pelanggan, ramalan, utawa syarat anyar.
Disaranake supaya ora nggawe owah-owahan langsung sajrone operasi. Iki nduwe pengaruh ala ing alur kerja lan kahanan emosional programer.
Sprint
Sprint minangka wektu sing cendhak nalika jumlah karya sing disepakati sadurunge kudu rampung. Sprint adhedhasar metodologi Scrum lan Agile. Milih sprint sing tepat mbantu tim sing lincah ngembangake piranti lunak sing berkualitas.
"Nganggo Scrum, sampeyan bisa ngembangake produk ing pirang-pirang iterasi kanthi durasi sing jelas - sprint. Iki mbantu ngilangi proyek gedhe dadi tugas sing luwih cilik, "ujare Megan Cook, Jira Lead ing Atlassian.

Kepiye Scrum ngrancang lan nglakokake sprint?
Miturut penulis metodologi Scrum, kanggo ngrancang sprint ing mangsa ngarep, saben wong kudu ketemu ing rapat sing kapisah. Ing acara iki, anggota tim kudu nemokake jawaban kanggo rong pitakonan utama: apa sing kudu ditindakake ing sprint iki lan cara paling apik kanggo nindakake?
Pelanggan piranti lunak, master Scrum lan programer melu nemtokake dhaptar tugas kerja. Pelanggan nerangake tujuan sprint lan tugas saka backlog.
Banjur tim ngembangake rencana miturut tugas ing sprint bakal rampung. Rencana iki, bebarengan karo item karya sing dipilih, diarani sprint backlog. Sawise rapat perencanaan, tim bakal kerja. Pangembang milih tugas saka backlog, amarga karya wis rampung, status saben tugas diganti saka "Ing Progress" dadi "Rampung".
Sajrone sprint, tim nganakake rapat Scrum saben dina (stand-up) kanggo ngrembug masalah lan kemajuan saiki. Rapat kasebut dibutuhake kanggo ngenali kesulitan sing bisa nyebabake ngrampungake sprint.
Yen sprint rampung, banjur tim nuduhake asil karya ing review asil (demo). Saben peserta proyek bisa kenal karo asil. Familiarization kudu rampung sadurunge kode rampung digabung menyang lingkungan produksi.
Retrospektif ngrampungake siklus sprint. Ing kono, tim kasebut nemtokake wilayah sing kudu ditingkatake ing sprint mangsa ngarep.

Apa sing kudu digatekake lan apa sing ora kudu ditindakake
Umume tim enom angel ngenalake sprint menyang alur kerja sing sepisanan. Kanggo ngindhari masalah, disaranake sampeyan mriksa dhaptar tumindak sing mbutuhake perhatian prioritas.
Apa sing kudu kita lakoni:
- Priksa manawa tim ngerti tujuane sprint lan kepiye carane bisa sukses. Iki perlu kanggo saben wong kanggo pindhah menyang asil sukses bebarengan.
- Sampeyan kudu duwe backlog sing jelas lan bisa dingerteni. Yen backlog ora dikelola kanthi bener, iki bisa dadi masalah sing bisa ngrusak alur kerja.
- Priksa manawa perkiraan jangkah kerja sampeyan bener, kanthi preian musim panas lan faktor liyane.
- Aktif melu perencanaan sprint. Dorong anggota tim kanggo nggedhekake rencana crita, bug, lan tugas.
- Nolak tugas sajrone pangembang ora bakal bisa ngrampungake masalah ketergantungan.
- Sawise rencana disetujoni, pilih karyawan sing bakal tanggung jawab nglebokake data menyang program manajemen proyek (kertu Jira, lsp).
Apa sing kudu dihindari:
- Aja nggunakake akeh crita, kanthi ati-ati ngevaluasi kecepatan kerja lan aja menehi tugas sing bakal angel ditindakake kanthi cepet.
- Elinga kualitas karya sampeyan. Priksa manawa sampeyan duwe cukup wektu kanggo kontrol kualitas lan ndandani kewan omo ing kode kasebut.
- Priksa manawa kabeh anggota tim ngerti kanthi jelas isi sprint kasebut. Aja ngoyak kacepetan. Kabeh tim kudu pindhah bebarengan.
- Aja overburden pangembang karo karya ekstra. Sprint liyane bakal teka.
- Yen tim nyatakake keprihatinan babagan beban kerja utawa tenggat wektu, sampeyan kudu nggatekake pendapate. Ngatasi masalah lan mbenerake yen perlu.
papan scrum
Papan Scrum minangka alat sing nuduhake cara kerja Tim Scrum ditindakake. Sampeyan bisa nampilake informasi ing papan kasebut ing kertas, ing tembok utawa ing wangun elektronik (JIRA, Trello).
Papan Scrum paling ora ana telung kolom: To Do, In Progress, lan Rampung. Punika conto papan:

Papan Scrum ngemot kabeh informasi saka backlog, sing sadurunge disetujoni kanggo perencanaan. Minangka aturan, kertu tugas bisnis disematake ing papan kanthi prioritas saka ndhuwur nganti ngisor. Sampeyan bisa dibagi dadi jinis karya tartamtu (karya ing kode, desain, lan liya-liyane).
Sawise bagean saka karya rampung, kertu dipindhah tengen Papan kanggo kolom sabanjuré. Kanggo nuduhake visibilitas kemajuan karya tim, "kerja sing isih ana" saben dina ing Grafik Burndown mbantu.
Sampeyan uga bisa nggunakake papan flipchart. Ing kono, jeneng karya ditulis ing stiker kertas lan ditempelake ing papan kasebut. Sanalika karya rampung, stiker dipindhah menyang kolom liyane.
grafik burndown
Grafik burndown nuduhake jumlah karya sing ditindakake lan jumlah karya sing isih ana. Dianyari saben dina lan kasedhiya kanggo kabeh pihak sing kasengsem. Grafik dibutuhake kanggo nuduhake kemajuan ing karya ing sprint.
Ana rong jinis grafik:
- Grafik Burndown nuduhake kemajuan karya ing sprint.
- Grafik Burndown nuduhake kemajuan karya nganti rilis produk (data diringkes saka sawetara sprint).
Tuladha bagan:

Conto iki nggunakake psikologi: grafik ora nuduhake jumlah tugas sing wis rampung, nanging jumlah sing isih ana (ora rampung).
Yaiku, yen tim wis nindakake 90 tugas saka 100, mula bisa uga ana perasaan palsu yen kabeh wis siyap. Sawise kabeh, kemajuan saka 90 nganti 100 tugas ora ngganti apa-apa.
Yen sampeyan nampilake jumlah tugas sing isih ana, mula sampeyan ora bisa ngerteni kepiye saben wektu dadi kurang. Iki subconsciously spurs peserta project kanggo entuk goal luwih cepet - ana ngirim ora rampung tugas ing Papan.
GO TO FULL VERSION