Cetak Biru Manajemen Proyek Bagian 1: Perbandingan Komprehensif Agile, Scrum, Kanban, dan Lean

Ringkasan

Banyak metodologi yang digunakan dalam pengembangan perangkat lunak saat ini. Anda mungkin pernah mendengar istilah-istilah seperti Waterfall, Agile, Scrum, Kanban, Lean, Extreme Programming, dll.

Dalam artikel ini, saya akan mendefinisikan istilah-istilah ini, membahas bagaimana mereka terkait satu sama lain dan bagaimana mereka berbeda satu sama lain. Banyak dari kata kunci yang disebutkan di atas didasarkan pada konsep dari Lean Manufacturing yang awalnya didasarkan pada Toyota Manufacturing System (TPS), jadi kita akan membicarakannya terlebih dahulu.

Metodologi Lean

Asal Mula Lean dan Lean Manufacturing

Istilah "Lean" berasal dari manufaktur di mana ia diciptakan untuk menggambarkan model manufaktur berdasarkan Sistem Produksi Toyota (TPS) yang awalnya dikembangkan oleh Sakichi Toyoda, Kiichiro Toyoda, dan Taiichi Ohno yang awalnya terinspirasi oleh Henry Ford. TPS berfokus pada filosofi "penghapusan total semua limbah" dan merevolusi manufaktur pada 1950-an hingga 1970-an. TPS dikenal sebagai “Lean Manufacturing” pada tahun 1990 ketika “The Machine That Changed the World” diterbitkan.

TPS mengidentifikasi tiga jenis limbah di Toyota:

• Muda: diterjemahkan sebagai "limbah." Ada tujuh jenis muda yang diidentifikasi di Toyota dan yang kedelapan kemudian ditambahkan. Ini adalah:
  • Cacat: upaya yang terlibat dalam menemukan dan memperbaiki cacat
  • Overproduksi: produksi mendahului permintaan
  • Menunggu: menunggu langkah produksi berikutnya, interupsi, dll.
  • Bakat yang tidak digunakan: kemampuan yang kurang dimanfaatkan, pelatihan yang tidak memadai, dll
  • Transportasi: bagian atau produk bergerak yang tidak diperlukan untuk diproses
  • Persediaan: persediaan jadi dan pekerjaan dalam proses
  • Gerak: bergerak atau berjalan lebih dari yang dibutuhkan untuk pemrosesan

  • Kelebihan Pemrosesan: dari perkakas atau desain produk yang buruk

• Muri: diterjemahkan sebagai “overburden.” Muri biasanya hasil dari mura tetapi bisa juga hasil dari muda. Muri memanifestasikan dirinya dalam kerusakan, ketidakhadiran, masalah keamanan, dll.
• Mura: diterjemahkan sebagai "ketidakrataan." Mura dapat ditemukan dalam fluktuasi permintaan pelanggan, waktu proses per produk atau variasi waktu siklus untuk operator yang berbeda. Ketika mura tidak dikurangi, seseorang meningkatkan kemungkinan untuk muri dan, oleh karena itu, muda. Mura dapat dikurangi dengan menciptakan keterbukaan dalam rantai pasokan, mengubah desain produk, dan menciptakan standar kerja untuk semua operator.

TPS bekerja untuk menghilangkan pemborosan dengan menerapkan dua konsep inti berikut:

• Jidoka: diterjemahkan secara longgar sebagai "otomatisasi dengan sentuhan manusia" menetapkan bahwa "Kualitas harus dibangun selama proses pembuatan!" yang berarti bahwa ketika terjadi masalah, peralatan segera berhenti, mencegah produk cacat diproduksi.
• Just-in-Time: Membuat hanya “apa yang dibutuhkan, ketika dibutuhkan, dan dalam jumlah yang dibutuhkan.”

Seiring berkembangnya TPS, pilar dan nilai inti ini dibangun di atas konsep Jidoka dan JIT dan menjadi mengakar:

• Perbaikan terus-menerus:
  • Tantangan: membentuk visi jangka panjang dan menghadapi tantangan dengan keberanian dan kreativitas untuk mewujudkan impian
  • Kaizen: meningkatkan operasi bisnis secara terus menerus, selalu mendorong inovasi dan evolusi, menghilangkan satu muda pada satu waktu
  • Genchi Genbutsu: berlatih genchi genbutsu, pergi ke sumber untuk menemukan fakta untuk membuat keputusan yang benar, membangun konsensus, dan mencapai tujuan dengan kecepatan terbaik kita
• Menghormati Orang:
  • Menghormati: menghormati orang lain dan melakukan segala upaya untuk memahami satu sama lain, mengambil tanggung jawab dan melakukan yang terbaik untuk membangun rasa saling percaya
  • Kerja tim: merangsang pertumbuhan pribadi dan profesional, berbagi peluang untuk pengembangan, dan memaksimalkan kinerja individu dan tim
• Andon: indikator visual status atau masalah
• Heijunka: berarti leveling atau leveling produksi
• Hansei: artinya refleksi diri. Untuk meningkatkan efisiensi, pekerja harus menantang asumsi di balik proses saat ini untuk menemukan yang lebih baik.
• Kanban: papan nama yang digunakan sebagai alat visual untuk mengontrol produksi
• Poka-yoke: Juga disebut sebagai pemeriksaan kesalahan atau pemeriksaan kesalahan
• Sistem Tarik: Material ditarik ke tempat kerja sesuai kebutuhan
• Seiri: adalah prinsip yang mencerminkan pemborosan. Seiri menyatakan bahwa apa yang tidak perlu harus dihapus. Ini mencakup semua tujuh limbah TPS asli
• Standardisasi: mengatur semua pekerjaan di sekitar gerakan manusia dan menciptakan urutan produksi yang efisien tanpa muda. Ini membantu mengarah pada kualitas, kecepatan konstan, dan memungkinkan peningkatan berkelanjutan.

Diagram di bawah ini menunjukkan bagaimana konsep inti dan nilai-nilai inti berhubungan satu sama lain.

Manajemen yang ramping

Sistem Produk Toyota dan Lean Manufacturing berkembang dari waktu ke waktu dan diterapkan di sejumlah area termasuk manajemen.

Manajemen Lean menerapkan nilai-nilai inti peningkatan berkelanjutan dan rasa hormat terhadap orang-orang dan menyaringnya menjadi satu set lima prinsip Lean preskriptif yang akan diulang beberapa kali untuk terus meningkatkan dan menghilangkan pemborosan:

1. Identifikasi Nilai: Tentukan nilai dari sudut pandang pelanggan akhir menurut kelompok produk.
2. Petakan Aliran Nilai: Identifikasi semua langkah dalam aliran nilai untuk setiap kelompok produk, sedapat mungkin hilangkan langkah-langkah yang tidak menciptakan nilai.
3. Create Flow: Buat langkah-langkah penciptaan nilai terjadi dalam urutan yang ketat sehingga produk akan mengalir dengan lancar ke arah pelanggan.
4. Menetapkan Tarik: Saat aliran diperkenalkan, biarkan pelanggan menarik nilai dari aktivitas hulu berikutnya.
5. Carilah Kesempurnaan: Ketika nilai ditentukan, aliran nilai diidentifikasi, langkah-langkah yang terbuang dihilangkan, dan aliran dan tarikan diperkenalkan, mulai proses lagi dan lanjutkan sampai keadaan kesempurnaan tercapai di mana nilai sempurna diciptakan tanpa pemborosan.

Prinsip-prinsip ini dan aspek lain dari manajemen Lean diformalkan ketika Womack & Jones menerbitkan "Lean Thinking" pada tahun 1996.

Pengembangan Perangkat Lunak Lean

Lean sejak itu telah diterapkan pada manajemen, pengembangan perangkat lunak, dan bidang lainnya.

Pada 1980-an dan 1990-an, industri pengembangan perangkat lunak mendekati krisis karena proyek yang dieksekusi menggunakan metodologi air terjun tradisional memakan waktu lebih lama dan lebih lama. Ini sering mengakibatkan jeda besar antara kebutuhan bisnis yang diidentifikasi dan solusi perangkat lunak yang disampaikan. Terkadang jeda ini diukur dalam beberapa tahun, atau bahkan dalam beberapa dekade di industri tertentu dengan persyaratan khusus, seperti industri dirgantara.

Selama jangka waktu multitahun ini, persyaratan, sistem, atau bahkan seluruh bisnis berubah. Seringkali, proyek akan dibatalkan sebagian atau mereka akan menyelesaikan cakupannya, hanya untuk mengetahui bahwa apa yang mereka berikan tidak lagi memenuhi kebutuhan bisnis seperti yang diidentifikasi di awal proyek.

Metodologi Waterfall memberi penghargaan kepada pemangku kepentingan karena memikirkan segalanya karena mereka dipaksa untuk menulis kontrak meskipun mereka mungkin tidak yakin dengan apa yang mereka butuhkan. Metodologi Waterfall memaksa keputusan dibuat selama persyaratan atau fase desain, dan keputusan ini sangat sulit untuk diubah tanpa mengubah kontrak dan menambah biaya proyek. Persentase yang tinggi dari proyek perangkat lunak gagal sepenuhnya, atau terlambat dan melebihi anggaran, atau gagal memberikan apa yang dibutuhkan.

Frustrasi umum ini menyebabkan berbagai pemimpin pemikiran mencoba memperbaiki Air Terjun. Contoh awal termasuk Rapid Application Development (RAD) yang berfokus pada pengurangan pemborosan dengan mempersingkat persyaratan dan fase desain melalui pengembangan prototipe secara cepat dan berkolaborasi dengan bisnis untuk mengembangkan persyaratan lebih lanjut. Ada juga pergerakan menuju pengembangan berulang di mana sebuah proyek kecil diselesaikan dan fitur ditambahkan dalam iterasi berkelanjutan. Sementara metodologi ini membantu, mereka tidak memecahkan masalah inti yang terkait dengan Air Terjun.

Pada 1990-an dan awal 2000-an, beberapa penulis menerbitkan buku tentang penerapan prinsip-prinsip Lean untuk pengembangan perangkat lunak. Robert Charette menerbitkan "Pengembangan Perangkat Lunak Lean" pada tahun 1993 dan "12 Prinsip Pengembangan Perangkat Lunak Lean" pada tahun 2003.

Tom dan Mary Poppendieck menerbitkan “Lean Software Development: An Agile Toolkit” pada tahun 2003. Buku ini merinci tujuh prinsip Lean Development, yang berkorelasi langsung dengan tujuh bentuk pemborosan dalam Lean Manufacturing. Persamaan dan perbedaan antara dua publikasi Lean yang berbeda dan Agile (dibahas di bagian selanjutnya) disajikan dalam diagram di bawah ini.

Perbedaan Antara Ramping dan Agile

Menurut Dr. Charette, salah satu perbedaan utama antara Lean dan Agile adalah bahwa Agile adalah dari bawah ke atas, sedangkan Lean adalah dari atas ke bawah.

Kerangka Agile

Asal Mula Agile dan Manifesto Agile

Sekitar waktu yang sama ketika Charette dan Poppendiecks menerbitkan buku mereka, Kerangka Agile diciptakan untuk membantu memecahkan masalah yang sama. Pada bulan Februari 2001, sekelompok perintis Agile bertemu di pertemuan Snowbird yang terkenal di Snowbird, Utah untuk mencoba dan menemukan solusi.

Hasilnya adalah Agile Manifesto yang menjabarkan serangkaian nilai dan prinsip untuk metodologi yang berupaya beradaptasi dengan perubahan persyaratan dan kebutuhan pelanggan, mengurangi pemborosan, dan memberikan manfaat lebih cepat menggunakan pendekatan inkremental dan iteratif.

Manifesto Agile berbunyi sebagai berikut:

“Kami menemukan cara yang lebih baik untuk mengembangkan perangkat lunak dengan melakukannya dan membantu orang lain melakukannya. Melalui pekerjaan ini kami telah mencapai nilai:

• Individu dan interaksi atas proses dan alat
• Perangkat lunak yang berfungsi melalui dokumentasi yang komprehensif
• Kolaborasi pelanggan melalui negosiasi kontrak
• Menanggapi perubahan mengikuti rencana

Artinya, sementara ada nilai pada barang-barang di sebelah kanan, kami lebih menghargai barang-barang di sebelah kiri.”

Selaras dengan nilai-nilai dalam manifesto adalah 12 prinsip di balik Agile Manifesto:

“Kami mengikuti prinsip-prinsip ini:

1. Prioritas tertinggi kami adalah untuk memuaskan pelanggan melalui pengiriman perangkat lunak yang berharga secara dini dan berkelanjutan.
2. Menyambut perubahan persyaratan, bahkan terlambat dalam pengembangan. Proses tangkas memanfaatkan perubahan untuk keunggulan kompetitif pelanggan.
3. Kirimkan perangkat lunak yang berfungsi sesering mungkin, dari beberapa minggu hingga beberapa bulan, dengan preferensi pada skala waktu yang lebih pendek.
4. Pebisnis dan pengembang harus bekerja sama setiap hari selama proyek berlangsung.
5. Bangun proyek di sekitar individu yang termotivasi. Beri mereka lingkungan dan dukungan yang mereka butuhkan, dan percayai mereka untuk menyelesaikan pekerjaan.
6. Metode penyampaian informasi yang paling efisien dan efektif ke dan di dalam tim pengembangan adalah percakapan tatap muka.
7. Perangkat lunak yang berfungsi adalah ukuran utama kemajuan. Proses tangkas mempromosikan pembangunan berkelanjutan.
8. Sponsor, pengembang, dan pengguna harus dapat mempertahankan kecepatan konstan tanpa batas.
9. Perhatian terus menerus pada keunggulan teknis dan desain yang baik meningkatkan kelincahan.
10. Kesederhanaan—seni memaksimalkan jumlah pekerjaan yang tidak dilakukan—sangat penting.
11. Arsitektur, persyaratan, dan desain terbaik muncul dari tim yang mengatur diri sendiri.
12. Secara berkala, tim merefleksikan bagaimana menjadi lebih efektif, kemudian menyesuaikan dan menyesuaikan perilakunya.”

Nilai dan prinsip di atas merupakan penerapan prinsip Lean seperti Jidoka, JIT, Genchi Genbutsu, Kaizen, Hansei, Heijunka, dan reduce waste.

Prinsip Agile yang Diterapkan pada Pengembangan Perangkat Lunak

Agile adalah kerangka kerja payung yang berlaku untuk proses apa pun yang menerapkan serangkaian nilai dan prinsip Agile.

Beberapa contohnya adalah:

• Pemrograman Ekstrim
• Scrum
• Kanban

Scrum

Sejarah Singkat Scum

Scrum adalah kerangka kerja yang menerapkan prinsip Agile yang diciptakan secara terpisah oleh banyak orang, beberapa di antaranya menandatangani Manifesto Agile:

• Hirotaka Takeuchi dan Ikujiro Nonaka awalnya memperkenalkan istilah "scrum" dalam konteks manufaktur di buku putih mereka "The New Product Development Game." diterbitkan pada tahun 1986 di Harvard Business Review.
• Jeff Sutherland, John Scumniotales dan Jeff McKenna mengimplementasikan Scrum di Easel Corporation pada tahun 1993.
• Ken Schwaber menggunakan apa yang akan menjadi Scrum di perusahaannya, Metode Pengembangan Lanjutan pada 1990-an.

Schwaber dan Sutherland berkolaborasi sepanjang tahun 1990-an untuk mengembangkan dan menyempurnakan kerangka kerja dalam konteks pengembangan perangkat lunak, berbicara di berbagai konferensi. Schwaber bekerja dengan Mike Beedle untuk menjelaskan metode dalam buku, "Pengembangan Perangkat Lunak Agile dengan Scrum" pada tahun 2001.

Schwaber melanjutkan untuk membuat kedua otoritas sertifikasi Scrum utama:

• Scrum Alliance: dibuat pada tahun 2001. Mengatur seri akreditasi Scrum Bersertifikat .
• Scrum.org: dibuat pada tahun 2009 setelah Schwaber meninggalkan Scrum Alliance. Siapkan seri akreditasi Scrum Profesional paralel.

Seiring waktu, beberapa kerangka kerja/badan sertifikasi dibuat untuk menangani penskalaan kerangka kerja Scrum ke tim dan proyek yang lebih besar karena Scrum awalnya dirancang untuk tim kecil (7 plus atau minus 2 anggota):

• AMAN: Kerangka Kerja Agile Berskala
• KURANG: Scrum Skala Besar
• Scrum@scale: Scrum dalam Skala yang dibuat oleh Jeff Sutherland

Nilai Scrum

Menurut Aliansi Scrum:

Scrum adalah seperangkat prinsip dan praktik yang sederhana namun sangat kuat yang membantu tim memberikan produk dalam siklus pendek, memungkinkan umpan balik yang cepat, peningkatan berkelanjutan, dan adaptasi cepat terhadap perubahan.

Scrum adalah kerangka kerja preskriptif, inkremental, dan iteratif untuk mengembangkan perangkat lunak yang menerapkan prinsip Agile. Nilai dan prinsip Scrum diuraikan dalam bagan di bawah ini dan memiliki keselarasan yang signifikan dengan nilai dan prinsip Lean dan Agile.

Ikhtisar Scrum

Pekerjaan dibagi menjadi iterasi kotak waktu singkat yang disebut sprint yang biasanya 1-3 minggu. Ini sangat kontras dengan perencanaan Waterfall yang mendalam. Pekerjaan yang direncanakan untuk sprint saat ini dipilih dari atas backlog prioritas item pekerjaan yang disebut Product Backlog (Sistem Tarik, Heijunka), dan itu diperbaiki setelah sprint dimulai. Tujuannya adalah memiliki perangkat lunak yang berfungsi di akhir setiap sprint, memungkinkan umpan balik yang cepat.

Di akhir sprint, tim bertemu untuk meninjau pekerjaan yang telah diselesaikan, bagaimana sprint berjalan, dan merencanakan sprint berikutnya. Panjang sprint, serta ritual dan irama sprint, ditetapkan untuk setiap sprint.

Sprint dijalankan oleh tim lintas fungsi yang berisi semua keterampilan yang dibutuhkan untuk menyelesaikan pekerjaan dalam sprint. Perencanaan harian dan pelacakan kemajuan dilakukan dengan menggunakan artefak visual seperti papan scrum dan grafik burndown sprint.

Pekerjaan dalam sprint diambil dari backlog yang diprioritaskan. Mengikuti metode ini memungkinkan untuk mengubah persyaratan dari waktu ke waktu dan mendorong umpan balik yang konstan dari pengguna akhir.

Diagram peta pikiran di bawah ini menguraikan beberapa konsep utama Scum yang akan dibahas di bagian mendatang.

Peran Scrum

Scrum memiliki tiga peran:

• Scrum Master : Scrum Master adalah pemimpin pelayan tim Scrum. Mereka adalah pelatih tim yang membantu memfasilitasi kolaborasi, menghilangkan hambatan, menegakkan dan menjaga proses Scrum, dan melindungi tim. Ini biasanya berarti bahwa mereka mengatur dan memfasilitasi ritual sprint, memastikan bahwa pemilik produk memiliki backlog yang diprioritaskan dan dipersiapkan dengan benar, memastikan bahwa tim tidak ditekan untuk berkomitmen berlebihan pada sprint, memastikan bahwa ruang lingkup tidak ditambahkan ke sprint. sprint, memastikan bahwa Definisi Selesai dipatuhi. Mereka tidak memberikan tugas kepada anggota tim (Genchi Genbutsu) dan mereka tidak bertanggung jawab atas pengiriman proyek
• Pemilik Produk : pemilik produk adalah 'leher yang bisa diremas tunggal' yang bertanggung jawab atas pengiriman produk. Pemilik produk mendefinisikan visi tentang apa yang ingin mereka bangun dan menyampaikan visi tersebut kepada tim dan organisasi. Pemilik produk memiliki kebutuhan bisnis dan pasar dan memprioritaskan semua pekerjaan yang perlu dilakukan melalui pembuatan dan pengelolaan backlog produk. Mereka memutuskan fitur mana yang akan dikirim kapan. Mereka bekerja dengan tim dan pemangku kepentingan lainnya untuk memastikan semua orang memahami item dalam backlog produk. Mereka menerima atau menolak pekerjaan yang diselesaikan dalam sprint di sprint demo.
• Anggota Tim : Tim Scrum adalah tim lintas fungsi yang mengorganisir diri sendiri yang biasanya terdiri dari lima hingga tujuh anggota. Semua orang di proyek bekerja bersama dan saling membantu dan tidak harus terikat pada peran yang berbeda seperti arsitek, programmer, desainer, atau penguji. Semua orang menyelesaikan set pekerjaan bersama-sama. Tim Scrum merencanakan berapa banyak pekerjaan yang dapat mereka selesaikan setiap sprint dan memiliki rencana tersebut (Genchi Genbutsu).

Alur Scrum, Aktivitas, dan Upacara

Seperti yang dibahas di atas, Scrum memiliki alur yang jelas dan serangkaian ritual dan aktivitas. Alur lari sprint adalah sebagai berikut.

Perencanaan Sprint:

Sebelum sprint dimulai, Scrum Master memfasilitasi pertemuan dengan tim scrum dan pemilik produk, yang disebut pertemuan perencanaan sprint, di mana pemilik produk mengidentifikasi tujuan sprint yang akan datang, dan tim kemudian merencanakan pekerjaan mereka sesuai dengan tujuan.

Ini biasanya dilakukan dengan kegiatan berikut:

• Kapasitas Sprint: tim menentukan kapasitas untuk sprint, dengan mempertimbangkan jumlah hari, jumlah anggota tim, hari libur, dll.
• Tujuan Sprint: pemilik produk mengidentifikasi apa tujuan sprint. Sangat penting bahwa jaminan simpanan produk diprioritaskan sesuai dengan tujuan (yaitu, cerita yang relevan berada di atas) dan dipersiapkan.
• Seleksi Pekerjaan: cerita atau tugas ditarik dari atas backlog ke dalam sprint sampai perkiraan kapasitas tercapai. Saat cerita ditarik, pemilik produk akan menjelaskan cerita dan menjawab pertanyaan dari tim, memperbarui cerita sesuai kebutuhan, hingga pemilik produk dan tim Scrum memiliki pemahaman yang baik dan sama tentang cerita. Setelah aktivitas ini selesai, tim memiliki ruang lingkup sprint awal yang diusulkan.
• Perincian Tugas: tim Scrum membahas setiap cerita secara rinci dengan penekanan pada perencanaan bagaimana mereka akan menyelesaikan cerita dan menangani semua kriteria penerimaan dan DoD. Mereka akan menghasilkan daftar subtugas yang diperlukan untuk menyelesaikan cerita. Setelah daftar subtugas selesai, perkiraan cerita ditinjau dan diperbarui jika perlu.
• Komitmen Sprint: setelah semua cerita dipecah dan perkiraan diperbarui, cakupan sprint awal yang diusulkan ditinjau. Cerita dapat dihapus dari sprint dan dimasukkan kembali ke backlog dan/atau cerita tambahan dapat ditambahkan. Setelah ini selesai, HANYA tim Scrum ( dan bukan Scrum Master atau pemilik produk) yang berkomitmen untuk menyelesaikan pekerjaan dalam sprint, dan sprint dimulai.

Jumlah total pekerjaan atau ruang lingkup yang dilakukan untuk sprint diukur dalam poin cerita.

Eksekusi Sprint

Selama sprint, anggota tim menarik item pekerjaan (cerita pengguna, tugas, dll.) dari bagian atas daftar To Do sprint untuk dikerjakan. Berbagai anggota tim akan mengerjakan berbagai item pekerjaan atau subtugas mereka. Mereka akan memperbarui status item bila perlu dengan memindahkannya dari satu kolom ke kolom berikutnya (biasanya To Do > In Progress > Testing > Done atau beberapa variasinya) di Scrum Board sampai selesai.

Kemajuan dilacak menggunakan bagan burndown yang menunjukkan jumlah pekerjaan yang diselesaikan dan sisanya diukur dalam poin cerita. Titik cerita yang tersisa ditampilkan pada sumbu Y dan waktu yang tersisa ditampilkan pada sumbu X. Bagan burndown diperbarui ketika cerita selesai.

Setiap hari, Scrum Master berfokus pada:

• Memfasilitasi pertemuan standup harian untuk merencanakan hari dan meninjau kemajuan (lihat di bawah)
• Memastikan bahwa tim memiliki rencana untuk hari itu
• Menghilangkan penghalang jalan
• Melindungi ruang lingkup sprint dan tim dari gangguan
• Membantu tim mempertahankan grafik burndown mereka dan statistik Scrum lainnya

Standup Harian

Di awal setiap hari dalam sprint, Scrum Master memfasilitasi pertemuan singkat selama 15 menit dengan tim scrum dan pemilik produk untuk merencanakan hari dan meninjau kemajuan sprint. Ini adalah pertemuan singkat di mana setiap orang berdiri di depan Dewan Scrum dan setiap orang dalam pertemuan tersebut menjawab pertanyaan-pertanyaan berikut dalam 2 menit atau kurang, mengacu pada item tertentu di papan sprint:

• Apa yang kamu lakukan kemarin?
• Apa yang Anda rencanakan untuk dilakukan hari ini?
• Apakah ada hambatan yang menghalangi Anda untuk menyelesaikan pekerjaan Anda?

Hal ini memungkinkan setiap orang untuk melihat apa yang sedang dikerjakan setiap orang, melihat kemajuan apa yang dibuat atau tidak, dan mengidentifikasi hambatan dan/atau bantuan yang dibutuhkan.

Penyelesaian Sprint

Scrum Master memfasilitasi dua upacara untuk menutup sprint sebelum merencanakan sprint berikutnya.

Demo lari cepat

Di akhir sprint, Scrum Master memfasilitasi pertemuan demo sprint di mana setiap cerita yang telah selesai didemonstrasikan pada perangkat lunak yang berfungsi kepada pemilik produk dan anggota tim lainnya. Pemilik produk akan menerima cerita tersebut jika semua kriteria penerimaan terpenuhi, atau mereka akan menolak cerita tersebut. Jika sebuah cerita ditolak, kekurangannya diidentifikasi dan cerita tersebut dimasukkan kembali ke dalam product backlog dalam urutan prioritas untuk diselesaikan di lain waktu atau tidak sama sekali. Seringkali, bagian dari cerita yang tidak diterima oleh pemilik produk dipecah menjadi cerita yang terpisah dan cerita aslinya ditutup.

Jumlah total poin cerita yang diselesaikan per sprint (Velocity) dihitung dan sprint ditutup. Kecepatan digunakan untuk melacak tingkat keluaran tim dan digunakan untuk memperkirakan kapan fitur atau rilis akan selesai.

Retrospektif Sprint

Setelah sprint demo tetapi sebelum rapat perencanaan sprint berikutnya, Scrum Master memfasilitasi sprint retrospective dimana tim merefleksikan sprint yang baru saja selesai dan mendiskusikan apa yang berjalan dengan baik dan apa yang tidak berjalan dengan baik sehingga mereka dapat secara terus menerus dan bertahap meningkatkan proses dan kualitas dari waktu ke waktu (Kaizen, Hansei). Ada banyak format atau latihan retrospektif yang dapat digunakan untuk membantu tim menghasilkan diskusi.

Daftar item tindakan perbaikan dibuat dan terkadang menghasilkan item yang ditambahkan ke backlog produk, perubahan pada DoD atau piagam tim, dll.

Manajemen Backlog Produk

Pembuatan Backlog Produk

Sebelum sprint dapat direncanakan atau dijalankan, pemilik produk perlu membuat product backlog pekerjaan. Backlog biasanya dimulai dengan item pengembangan fitur yang disebut cerita yang ditulis oleh pemilik produk dan seiring waktu juga diisi dengan tugas pengembangan atau QA, lonjakan, dan cacat, dll. yang berpotensi dibuat oleh anggota tim mana pun. Semua item dalam backlog diatur dalam urutan prioritas.

Perawatan Backlog

Setelah backlog produk awal dibuat dan diprioritaskan, proses backlog groom yang sedang berlangsung akan mengambil alih. Tujuannya adalah untuk selalu memiliki, minimal, cukup item teratas dalam backlog yang dipersiapkan dan diperkirakan sehingga siap untuk ditarik ke dalam sprint selama pertemuan perencanaan sprint. Hal ini biasanya dilakukan dengan mengadakan pertemuan backlog grooming secara berkala dengan manajer produk dan tim yang difasilitasi oleh Scrum Master.

Sebelum pertemuan, daftar cerita dikirim ke tim sehingga mereka dapat meninjau dan mempersiapkan pertemuan perawatan. Pada pertemuan grooming, setiap item dibahas dalam hal kriteria penerimaan, kompleksitas, risiko, ukuran, strategi implementasi, dll. Kriteria penerimaan dan detail cerita lainnya ditinjau dan direvisi hingga tim, pemilik produk, dan Scrum Master memiliki pemahaman yang sama tentang cerita. Pada saat itu, cerita diperkirakan dalam poin cerita menggunakan teknik yang disebut poker perencanaan.

Estimasi Titik Cerita

Poin cerita adalah unit upaya yang menggunakan ukuran relatif di mana cerita dibandingkan dengan karya sebelumnya, yang diketahui, dan dipahami dengan baik. Anda selalu mengajukan pertanyaan "apakah cerita ini lebih besar, lebih kecil, atau kira-kira berukuran sama" dengan karya lain.

Skala Fibonacci (1, 2, 3, 5, 8, 13, 21…) adalah skala yang paling umum digunakan di mana setiap kenaikan kira-kira dua kali lebih besar dari sebelumnya (yaitu, cerita lima poin kurang lebih dua kali lipat sebesar cerita tiga poin). Terkadang timbangan lain seperti ukuran T-shirt (XS, S, M, L, XL) atau bahkan ikan (ikan kecil, ikan mas, trout, tuna, paus, dll.) digunakan. Skala apa pun yang memungkinkan Anda membandingkan ukuran sesuatu relatif dengan yang lain akan berfungsi.

Poin cerita mewakili seluruh upaya tim untuk mengimplementasikan cerita, termasuk pengembangan, pengujian, desain, dan tugas lain-lain yang diperlukan untuk Definisi Selesai. Estimasi memperhitungkan jumlah pekerjaan, kompleksitas, dan risiko. Setelah ukuran relatif dari cerita ditentukan, ukuran pada skala ditetapkan sebagai perkiraan.

Tim mempersiapkan proses estimasi poin cerita dengan terlebih dahulu menetapkan dasar estimasi dengan memilih cerita berukuran "paling menengah" yang dipahami seluruh tim sebagai cerita referensi. Beberapa cerita referensi tambahan yang lebih besar dan lebih kecil juga dipilih.

Estimasi titik cerita dilakukan selama pertemuan perawatan dan terkadang selama perencanaan sprint menggunakan Perencanaan Poker:

1. Setiap anggota tim/estimator memiliki satu set kartu.
2. Item backlog dibahas satu per satu seperti yang dijelaskan di atas.
3. Setelah item telah dibahas sepenuhnya, setiap penaksir secara pribadi memilih kartu untuk mewakili perkiraan mereka.
4. Ketika semua penaksir telah membuat perkiraan mereka, mereka mengungkapkan kartu mereka pada waktu yang sama.
   • Jika semua perkiraan cocok, penaksir memilih item simpanan lain dan ulangi proses yang sama.
   • Ketika perkiraan berbeda, penaksir mendiskusikan masalah untuk mencapai konsensus.

Keuntungan dari estimasi titik cerita adalah:

• Cepat: perkiraan relatif terhadap item backlog produk yang sudah selesai.
• Cukup Akurat: cukup akurat untuk memberikan gambaran tentang ruang lingkup, merencanakan pekerjaan di masa depan, memprioritaskan, dan mengelola harapan.
• Merangkul Ketidakpastian: Poin cerita menentukan rentang waktu yang tidak diketahui. Memilih dari urutan titik cerita seperti Fibonacci tertentu memungkinkan menangkap ketidakpastian.
• Olahraga Tim: Melibatkan semua orang (pengembang, desainer, QA, manajer produk). Menggunakan berbagai perspektif untuk menentukan ukuran pekerjaan tetapi hanya anggota tim yang melakukan pekerjaan yang dapat memperkirakan
• Mengukur Kecepatan Tim: mengukur seberapa banyak pekerjaan yang dilakukan tim dalam sprint versus jumlah waktu yang dihabiskan untuk melakukan pekerjaan itu. Saat tim meningkat, mereka akan menyelesaikan cerita dengan ukuran yang sama lebih cepat, menghasilkan kecepatan titik cerita yang lebih tinggi dari waktu ke waktu.

Perkiraan dan Pelacakan Rilis

Estimasi titik cerita juga digunakan dalam konteks perencanaan rilis menggunakan teknik berikut:

1. Daftar semua cerita yang akan diukur
2. Urutkan dari terkecil ke terbesar
   • Ambil cerita pengguna pertama dan kedua.
   • Putuskan mana yang lebih besar dan letakkan yang lebih besar di bawah
   • Kemudian ambil yang berikutnya dan putuskan di mana itu cocok dengan dua lainnya
   • Ulangi prosesnya sampai semua cerita sekarang ada dalam daftar (secara berurutan dari yang terkecil hingga yang terbesar)
3. Ukuran cerita

Perkiraan cerita untuk semua cerita dalam rilis yang dikombinasikan dengan kecepatan tim akan memungkinkan Anda memperkirakan kapan rilis akan selesai dan melacak kemajuannya. Ini sering ditampilkan dalam grafik burn-up rilis.

Artefak dan Ketentuan Scrum

• Product Backlog: Daftar backlog semua item pekerjaan untuk produk tertentu yang dapat mencakup fitur (cerita), tugas teknis, paku, dan cacat
• Release Burn-up: Bagan grafis yang digunakan untuk menunjukkan kemajuan pada tingkat rilis dan untuk memprediksi kapan rilis akan selesai menggunakan Kecepatan Sprint. Poin cerita yang diselesaikan ditampilkan pada sumbu Y dan sprint ditampilkan pada sumbu X.
• Sprint Backlog: Daftar backlog dari semua item pekerjaan yang harus diselesaikan dalam sprint tertentu. Isi sprint backlog disepakati pada saat rapat perencanaan sprint.
• Scrum Board: Papan gaya tabel yang melacak kemajuan pekerjaan yang dilakukan untuk sprint. Status ditampilkan di bagian atas dalam kolom vertikal dan item kerja dipindahkan di setiap status hingga selesai. Papan scrum diisi selama pertemuan perencanaan sprint dan diatur ulang pada akhir sprint.
• Sprint Burndown: Bagan grafis yang menunjukkan jumlah pekerjaan yang diselesaikan dan sisanya diukur dalam poin cerita selama sprint. Titik cerita yang tersisa ditampilkan pada sumbu Y dan waktu yang tersisa ditampilkan pada sumbu X.
• Kecepatan Sprint: Jumlah poin cerita yang diselesaikan oleh tim Scrum dalam sebuah sprint.
• Hambatan Backlog: Daftar hambatan yang perlu ditangani oleh Scrum Master agar tim dapat terus bekerja. Ketika anggota tim diblokir, mereka akan menambahkan item ke backlog hambatan untuk memberikan visibilitas ke tim dan Scrum Master.
• Epik: Epik adalah kumpulan besar karya yang terdiri dari beberapa cerita pengguna terkait.
• Kisah Pengguna: Kisah pengguna adalah deskripsi fitur perangkat lunak dari perspektif pengguna akhir. Kisah pengguna menggambarkan tipe pengguna, apa yang mereka inginkan dan mengapa. Kisah pengguna membantu membuat deskripsi persyaratan yang disederhanakan dan menyertakan kriteria penerimaan. Cerita pengguna dibuat dan dikelola oleh pemilik produk.
• Tugas: Tugas adalah bagian dari pekerjaan yang dimasukkan oleh Scrum Master atau anggota tim yang mungkin secara langsung atau tidak langsung terkait dengan cerita pengguna. Mereka biasanya bersifat teknis dan akan mencakup kriteria penerimaan.
• Spike: Spike adalah jenis tugas khusus yang digunakan saat Anda perlu meneliti, membuat prototipe, dan/atau merancang suatu saat sebelum Anda dapat memutuskan bagaimana menerapkan atau memperkirakan cerita pengguna.
• Subtugas: Subtugas adalah tugas yang dimasukkan sebagai langkah implementasi untuk menyelesaikan cerita atau tugas pengguna. Mereka biasanya dimasukkan oleh tim selama pertemuan perencanaan sprint.
• Estimasi Titik Cerita: Skala estimasi ukuran relatif yang didasarkan pada skala Fibonacci (1, 2, 3, 5, 8, 13, 21…)
• Kriteria Penerimaan: Daftar cerita spesifik, item yang dapat diuji termasuk dalam setiap cerita yang harus diselesaikan sebelum pemilik produk menerima cerita sebagai selesai.
• Definisi Selesai (DoD): Daftar langkah atau kriteria umum yang harus diselesaikan sebelum cerita apa pun dapat dianggap selesai. Tim menyetujui hal ini dan mendokumentasikannya sehingga tidak harus dicantumkan di setiap cerita.

Kelebihan dan Kekurangan Scrum

Keuntungan utama Scrum adalah penerapan nilai dan prinsip Agile serta konsep Lean seperti Seiri, Jidoka, Just-in-Time, Kaizen, Genchi Genbutsu, Heijunka, Pull System, dan Iterasi. Applying these principles allow project teams to receive continuous feedback, quickly adapt to changing requirements and uncertainty, reduce waste, increase visibility and transparency, and strive for continuous improvement. By always focusing on the most important items in the product backlog and only working in short iterations that always produce working software, Scrum is more customer focused and allows customers to see what they like (and don't like) and make changes as needed. The overhead cost in terms of process and management is smaller, thus leading to quicker, cheaper results.

Scrum is a great methodology for projects with requirements that are not clearly known and/or expected to change. This applies to most projects. Scrum is also great for experienced, motivated teams as it allows teams to organize the work themselves and it provides visibility, transparency, and accountability for both progress and problems. All of this will result in teams improving and becoming more productive over time.

Scrum does have some disadvantages and is not the best methodology in some situations:

• Transparency: Scrum increases transparency and accountability which is both an advantage and disadvantage as problems and poor performance within and outside the team and are exposed. This can be uncomfortable and can lead to resistance if not handled properly within the Scrum framework of continuous improvement.
• Team Experience and Commitment: Inexperienced and/or uncommitted Scrum teams or Scrum Masters can cause serious problems through misapplying the Scrum methodology. There are no defined roles in the Scrum team as everyone does everything, so it requires committed team members with technical experience to follow the Scrum process and improve over time. It can also be very detrimental if other parts of the organization are resistant to Scrum.
• Scope Creep: There is a risk of scope creep, especially if there isn't a defined end date as stakeholders are allowed to add to the scope. Being able to change scope and priorities is one of the main advantages of Scrum, but it can also be a disadvantage if discipline isn't used.
• Poorly defined work: Poorly defined and understood user stories or tasks can lead to rework, inaccurate estimates, and scope creep. Although Scrum is focused on working software over documentation, the product owner needs to be clear on what they want and be able to clearly communicate that in conversations and in the user stories.
• Scaling: Adopting the Scrum framework in large teams is challenging as Scrum is meant for smaller teams.

Kanban

What Is Kanban?

Kanban is a lighter weight process that applies many of the Lean and Agile values as well as a subset of the Scrum values and principles but there are also some fundamental differences. Kanban focuses on visualization, flow, and limiting work in progress.

Kanban is Japanese for “signboard” or “billboard.” Toyota line-workers used a kanban (ie, an actual board) to signal extra capacity in various steps in their manufacturing process. In software, this is done with a Kanban board, which is very similar to the Scrum board. There is a prioritized backlog of To Do items and vertical columns for each status that a work item can have. Like Scrum, work items are moved from one status to another; however, in Kanban, the amount of work in progress is strictly limited to a maximum number of items in each status based on team capacity. New work cannot be pulled in until existing work is moved to the next step in the process. In Scrum, work in progress in indirectly limited by controlling the amount of work planned for a sprint.

In Kanban, there are no fixed iterations or sprints, just a constant flow where work items are pulled from one stage to the next. This means that the Kanban board is never reset. It also means that many of the Scrum rituals not used. Kanban teams often have daily standup meetings but they are not prescribed. There are no regularly planned sprint planning meetings, sprint demos or sprint retrospectives, so the process is more lightweight. Some of the activities in those rituals may or may not be performed at an informal level. Continuous improvement is accomplished by tracking and analyzing the flow of items from one state to another and making constant incremental improvements based on what issues are uncovered.

Kanban also doesn't prescribe the roles that Scrum does. The only role needed is the team member role, however, there is often a project manager that manages the team and the backlog. Often a single Kanban board can serve multiple function based roles and/or teams that only work on items in a certain status. For example, a development team might pull items from To Do to In Progress and move them to Testing, and the test team might test items in Testing and move them to Done.

Many of the backlog management activities for prioritizing and grooming of work items still need to be done to ensure that a given work item is well understood and ready to be worked on, however, estimating the work items is prescribed as optional.

Kanban vs. Scrum

The following table compares Scrum and Agile:

Summary: The End of Part 1

In this part, we reviewed a few of the most popular methodologies used for Software Development. By now you should have a good understanding of Lean, Agile, Scrum, and Kanban and their historical roots in Lean Manufacturing and TPS. In the next part of the series, we will continue reviewing and comparing other Software Development methodologies such as Waterfall, JTBD, and SAFe (and other scaling frameworks), as well as hybrid methodologies, so you have all of them conveniently explained in one place.