Sajarah Scrum

Wiwit diterbitake laporan Winston Royce "Ngatur Pengembangan Sistem Perangkat Lunak Gedhe" ing taun 1970, akeh sing nyoba nemokake metodologi sing bisa ngilangi kekurangan model pangembangan Waterfall. Alternatif kanggo "grojogan" yaiku metode Scrum, sing bakal dibahas saiki.

Scrum entuk jeneng ing taun 1986 saka karya Takeuchi lan Nonaki The New Rules for New Product Development. Dokumen iki ujar manawa cara sing paling efektif kanggo nggayuh tujuan kasebut yaiku menehi pangembang rencana tumindak sing jelas.

Ing taun 1995, pandhuan liyane, "Pengembangan Perangkat Lunak karo Scrum," dening Sutherland lan Schweiber, muncul. Publikasi iki wis dianyari kaping pirang-pirang. Saiki dianggep minangka pandhuan utama kanggo pangembangan metode iki. Pandhuan Scrum versi saiki ngemot informasi sing dianyari ing 2020.

Pranata utama Pandhuan Scrum nyaranake manawa cithakan manajemen proyek kudu adhedhasar kasunyatan manawa pangembang ngirim produk rampung ing wektu sing disepakati - sprints. Kanggo implementasine sukses Scrum, disaranake nggunakake struktur sing dumadi saka sawetara unsur: peran, acara, aturan, lan artefak.

Peran ing Scrum

Ana telung peran ing Scrum, kabeh dadi tim Scrum:

Pelanggan produk piranti lunak minangka wong sing paling penting ing proyek kasebut, amarga mung dheweke ngerti regane kanggo bisnis kasebut. Pelanggan nerangake kabutuhan pangguna produk mangsa menyang pangembang, nanging dheweke ora tanggung jawab kanggo bagean teknis proses pangembangan. Pelanggan uga nemtokake prioritas nalika nggawe unsur utawa fungsi tartamtu ing produk kasebut.

Pangembang dipasrahake karo implementasine tugas teknis, fungsi lintas sing gumantung saka ruang lingkup aplikasi. Pangembang sibuk nggawe backlog sprint, nulis kode, nyelarasake proyek kasebut menyang target sprint, lan tugas liyane.

Scrum Master minangka fasilitator tim Scrum. Iku menehi pitulungan kanggo pelanggan lan pangembang. Cukup, Scrum Master sibuk komunikasi antarane sing ora melu proyek lan wong sing nulis kode kasebut. Kadhangkala tim coder sing beda-beda ing perusahaan gedhe sing padha komunikasi lan koordinasi ing rapat umum master scrum saka tim kasebut.

Acara ing Scrum

Ana 5 jinis acara scrum:

Sprint minangka bagean paling penting saka Scrum. Iki kalebu perencanaan sprint, stand-up saben dina (scrum saben dina), review lan retrospektif sprint.

Sprint planning. Kabeh anggota tim Scrum melu nggawe rencana kanggo sprint mangsa ngarep. Ing kene ide produk ditampilake lan saben anggota tim bisa nyatakake pendapate, apa sing dikira babagan iki. Banjur ing rapat kasebut, prioritas ditemtokake lan tenggat wektu diumumake.

Daily Scrum minangka acara scrum singkat saben dina, ora luwih saka 15 menit. Biasane ditindakake kanggo ngrancang karya encoder kanggo dina iki utawa sesuk. Ing Daily Scrum, sampeyan bisa ngrembug masalah saiki. Kabeh pangembang sing melu proyek kasebut kudu melu ing bengkel kasebut. Ing ngarsane Scrum Master diijini, nanging ora dibutuhake.

Sprint Review (Demo) - Nuduhake asil sing digawe sajrone sprint. Biasane acara iki ditindakake ing tahap pungkasan. Kabeh wong sing kasengsem melu.

Sprint Retrospective - diskusi babagan asil sprint. Anggota tim nuduhake pendapat babagan carane ngatasi tugas sing ditugasake lan carane nambah asil kerja ing mangsa ngarep.

Kajaba iku, backlog refinement kadhangkala ditindakake - Backlog Refinement. Iki mbahas item backlog, nyiapake sprint sabanjure, lan prioritas tugas saiki.

artefak

Artefak scrum minangka karya sing kedadeyan ing pungkasan proyek utawa sprint. Ana telung artefak - backlog produk, backlog sprint, lan increment. Saben wong perlu kanggo pangiriman piranti lunak pas wektune kanggo pangguna. Ana uga artefak tambahan (ngobong grafik lan liya-liyane).

Komponen sing kalebu ing artefak sprint:

Backlog Product - antarmuka lan fitur backend.

Backlog sprint minangka dhaptar tugas sing kudu ditindakake sajrone pengulangan. Padha disepakati sadurunge miwiti sprint.

Increment - Jumlah total item backlog piranti lunak sing digawe sajrone sprint lan nilai tambahan sing digawe sadurunge. Tambah anyar sing wis rampung kudu ditampilake sadurunge pungkasan sprint. Iki tegese sampeyan duwe versi kerja sing nyukupi syarat tim scrum.

Item backlog produk - kudu rampung sajrone pengulangan sprint. Minangka aturan, unsur dipérang dadi sawetara tugas cilik.

Tujuan sprint yaiku tugas sing kudu dirampungake (nggawe item backlog utawa tugas liyane).

Burndown sprint yaiku karya sing ditinggalake sadurunge pungkasan sprint. Grafik burn down yaiku munggah utawa mudhun. Iku kabeh gumantung ing kangelan sing diadhepi anggota tim nalika makarya. Iku ora minangka indikator kemajuan, nanging mung cara kanggo ngatasi masalah lan insentif.

Product Release/Product Burn-Down Chart minangka grafik sing digambar dening Scrum Master sadurunge pungkasan sprint sabanjure. Sumbu horisontal yaiku sprint, sumbu vertikal minangka jumlah kerja sing ditinggalake.

Aturan kerangka Scrum

Peran, acara lan artefak minangka basis Scrum, nanging ana aturan liyane saliyane iki. Kabeh mau nambah efisiensi proses kerja. Ing ngisor iki dhaptar aturan kasebut:

  • Tim scrum kalebu pelanggan piranti lunak, master scrum, lan pangembang.
  • Kabeh sprint kudu padha dawa.
  • Sawise ngrampungake siji sprint, nggarap sing anyar langsung diwiwiti.
  • Sprint tansah diwiwiti kanthi rencana.
  • Anggota tim duwe scrum esuk ing wiwitan dina kerja.
  • Saben sprint dideleng sajrone saben sprint. Iki nambah komunikasi antarane tim lan stakeholder.
  • Ora dianjurake kanggo ngganti backlog sprint sajrone sprint.

Watesan ing Scrum

Bebarengan karo kaluwihan sing jelas, Scrum uga duwe kekurangan:

  • Scrum asring nyebabake nyuda jumlah karya sing ditindakake amarga ora ana tenggat wektu sing umum.
  • Kanthi keterlibatan sing sithik utawa ora gelem kerja sama ing antarane para peserta proyek, ana kemungkinan gedhe kanggo gagal asil kasebut.
  • Struktur scrum angel digunakake ing tim gedhe, nanging isih bisa. Ana kerangka skala kanggo iki: LeSS, SAFe, Nexus lan liya-liyane.
  • Mangkat saka siji utawa luwih anggota saka tim ing tengah proyek ora mengaruhi proyek banget.