Referensi dan Panduan Scrum Mini

Artikel ini adalah panduan mini dan panduan untuk metode Scrum, dibuat sebagai hasil dari membaca buku Sutherland, artikel dari Internet dan aplikasi praktis.

Penting untuk membedakan antara Agile dan Scrum. Agile adalah metodologi (sains), dan Scrum adalah metode untuk mencapai tujuan.

Menggunakan Scrum, penting untuk memiliki tim profesional sejati, mengamati kondisi transparansi, keterbukaan, dan kepercayaan.

Anggota tim harus senang dengan kegiatan mereka, bahagia dalam pekerjaan mereka. Kondisi kebahagiaan membuat orang mencapai hasil yang luar biasa.

Orang yang bahagia 50% lebih sukses. Jadi mereka 50% lebih produktif jika mereka bahagia dan menemukan makna dalam pekerjaan mereka. Selain itu, mereka 88% lebih loyal, karena mereka mengerti bahwa mereka bekerja tidak sia-sia, mencurahkan setengah dari waktu mereka untuk pengembangan bisnis ini

- Dr. Corrie Block, Pakar Strategi Bisnis dalam Penilaian Kebahagiaan.

Panduan Mini Scrum

Scrum - Scrum, metode manajemen proyek yang fleksibel. Istilah ini berasal dari permainan rugby.

Pemilik Produk - pemilik produk, tautan antara pelanggan dan tim pengembangan. Tanggung jawab paling penting dari Pemilik Produk adalah menciptakan dan mengendalikan Backlog Produk.

Tanggung jawab utama dan tanggung jawab Pemilik Produk dalam mengelola Product Backlog adalah:

• mendefinisikan item backlog untuk suatu produk;
• pengaturan elemen yang tepat untuk mengoptimalkan pencapaian tujuan;
• Memastikan kejelasan dan transparansi dari Product Backlog;
• memastikan transparansi dan pemahaman tentang persyaratan yang harus dikerjakan oleh seluruh Tim Scrum;
• optimalisasi umum untuk mencapai nilai tertinggi dari pekerjaan Tim Pengembangan;
• tanggung jawab untuk memahami simpanan oleh tim pengembang.

Scrum Team (Scrum Team) - citra kolektif tim yang terdiri dari Tim Pengembangan, Master Scrum, dan Pemilik Produk. Tim sepenuhnya mandiri dan tidak bergantung pada spesialis eksternal atau pelanggan.

Scrum Master (scrum master) - arbiter yang mengatur dan mengadakan pertemuan, memantau kepatuhan terhadap semua prinsip scrum, menyelesaikan kontradiksi dan melindungi tim dari gangguan, memfasilitasi pertemuan, bertanggung jawab untuk akuntansi, penyimpanan, dan penerbitan peralatan SCRUM. Peran ini tidak menyiratkan apa pun selain proses scrum yang benar.

Scrum Master tidak memberikan tugas, tetapi menghilangkan masalah yang muncul di dalam tim.
Tim lintas fungsi pengembang proyek, yang terdiri dari spesialis berbagai profil: pemrogram, penguji, analis, arsitek, dll.

Tim Pengembangan (tim pengembang) - tim pengembangan, tim lintas fungsi pengembang proyek, yang terdiri dari spesialis di berbagai bidang: programmer, penguji, analis, arsitek, dll. Ukuran tim adalah dari 5 hingga 9 orang (5 optimal). Tim adalah satu-satunya peserta pengembangan yang terlibat penuh dan bertanggung jawab atas hasilnya secara keseluruhan. Unit kerja ini mandiri, mandiri dan mengatur diri sendiri. Itu seperti sebuah organisme tunggal yang terdiri dari unsur-unsur yang terpisah.

Stakeholder - secara harfiah pemegang saham, orang yang memulai proyek (pelanggan bisnis), kepada siapa proyek scrum akan membawa manfaat. Mereka hanya terlibat dalam scrum selama Tinjauan Sprint.

Pengguna - pengguna produk.

Product Backlog (product backlog) - atau persyaratan produk Backlog, keinginan pelanggan untuk fungsionalitas dan desain, semua "Wishlist"; mereka diurutkan berdasarkan tingkat kepentingan dan nilai bagi pelanggan.

Epic adalah salah satu dari beberapa fitur produk global. Epik dapat berisi Cerita Pengguna, misalnya, paket keinginan satu pengguna atau daftar tugas (Tugas) untuk mengimplementasikan Epic.

User Story - atau Story, plot yang berisi keinginan pengguna.

Tugas (tugas) - tugas, sebuah fragmen yang harus diselesaikan untuk mencapai tujuan proyek.

Sprint (sprint) - periode waktu 1 hingga 4 minggu, di mana tim menciptakan bagian dari produk, siap untuk demonstrasi dan bermanfaat bagi pelanggan. Durasi optimal sprint adalah 1-2 minggu. Hal ini dilakukan agar informasi yang diterima pada awal minggu pertama tidak dilupakan pada akhir minggu kedua dan waktu tidak diperlukan untuk memulihkan komunikasi.

Sprint Goal ( Sprint Goal ) - tujuan dari sprint.

Pertemuan Perencanaan Sprint (Sprint Planin Mitin) - Perencanaan Sprint, pertemuan Scrum, di mana Tim Scrum berpartisipasi. Tugas backlog yang dapat diselesaikan dalam sprint dipilih.

Scrum Poker adalah cara cepat dan akurat untuk mengumpulkan skor menggunakan setumpuk kartu dengan angka Fibonacci (1,2,3,5,8,13). Anda dapat menggunakan aplikasi seluler untuk Scrum Poker. Tugas dengan penilaian 13 harus dibagi menjadi yang lebih kecil.

Story Points - unit untuk menilai kesulitan menyelesaikan tugas. Masuk akal untuk menerapkan Poin Cerita jika proyek terdiri dari 3 sprint atau lebih, karena tim mengumpulkan statistik dan pengalaman dalam menilai tugas. Pada proyek satu atau dua sprint, tidak masuk akal untuk menggunakan Poin Cerita, jika tidak untuk berlatih.

Rapat Scrum Harian (Daily Scrum Mitin) - pertemuan harian tidak lebih dari 15 menit, diadakan pada waktu yang sama. Tim Scrum berpartisipasi, semua orang dapat mengamati. Dilakukan oleh master scrum. Tujuan dari rapat umum adalah pertukaran informasi yang cepat, semua orang menyadari apa yang terjadi, tidak ada kesenjangan komunikasi. Tiga pertanyaan diajukan: apa yang Anda lakukan kemarin? apa yang akan kamu lakukan hari ini apa saja hambatan dalam perjalanan menuju tujuan?

Ulasan Sprint (sprint review) - ulasan sprint, semua orang yang terlibat, rapat terbuka. Tim menceritakan apa yang telah dilakukan dan menunjukkan bagian-bagian proyek yang akhirnya siap.

Sprint Retrospective Meeting (sprint retrospective Mitin) - tim scrum retrospektif yang terlibat. Bertemu di meja bundar. Pertanyaan dibahas: apa yang berjalan dengan baik dan apa yang menjadi buruk? apa yang bisa dilakukan dengan lebih baik? Yang utama adalah tidak menghukum siapa pun! Alur kerja sedang dipertimbangkan. Tujuannya adalah untuk meningkatkan alur kerja, menjadi tim "super".

Definisi Done (DoD) adalah kriteria yang menentukan tingkat kesiapan suatu tugas. Ini digunakan dalam kasus-kasus ketika akhirnya tidak mungkin untuk memeriksa kesiapan tugas, misalnya, jika elemen fungsional berada di tim lain atau scrum perusahaan. Deskripsi DoD dimulai dengan garis “selesai =”, misalnya, selesai = fungsionalitas diimplementasikan dalam lingkungan pengujian, diperlukan pembongkaran dan verifikasi di lingkungan utama.

Velocity (Velocity) - kecepatan tim; Untuk analitik, grafik Velocity dibuat, di mana sumbu X menghitung sprint dan Poin Cerita sumbu Y. Berdasarkan indikator ini, Kecepatan rata-rata dan Poin Cerita dibuat.

Burndown Chart - grafik pembakaran tugas. Arah grafik adalah dari atas ke bawah. Dirancang untuk melacak jumlah pekerjaan yang tersisa, di mana pada sumbu X jumlah hari sprint, dan pada sumbu Y jumlah Story Points. Hari pertama sprint sesuai dengan jumlah maksimum Story Points.

Burnup Chart - Burnup Chart. Arah grafik adalah dari bawah ke atas. Dirancang untuk melacak jumlah pekerjaan, di mana pada sumbu X jumlah hari sprint, dan pada sumbu Y jumlah Story Points. Hari terakhir sprint sesuai dengan jumlah maksimum Story Points.

Terminasi Abnormal (termormol abnormal ) - sprint stop, aksi abnormal. Pemberhentian dimulai oleh Pemilik Produk. Unjuk rasa sedang berlangsung untuk membahas penyebab Abnormal Termination. Kemudian Sprint mulai lagi.

Panduan Scrum

Tumpukan produk
Ini dibentuk selama pertemuan umum atau wawancara individu dengan semua pihak yang berkepentingan (pemangku kepentingan, pengguna). Kisah Pengguna, persyaratan dan keinginan dicatat.

1. Bidang utama dalam kartu: id, nama, kepentingan, peringkat, rilis, deskripsi, penulis, artis;
2. Kolom tambahan di kartu. Misalnya, bidang "Subjek" - peringkat produk di toko online tidak diperlukan sekarang, dan peringkat tersebut mencakup beberapa tugas. Kemudian Anda dapat mengubah "pentingnya" semua tugas dengan tema ini;
3. Tugas sebaiknya dipecah menjadi jenis yang sama.

Tugas dengan komponen seperti: 3IIIC, 5VE lebih rumit dan membutuhkan lebih banyak waktu.

123, ABC lebih cepat karena otak tidak perlu beralih di antara berbagai jenis tugas.

Kisah pengguna

1. Menerima tujuan bisnis dari pelanggan. Kami menyusun Peta Dampak untuk setiap sasaran bisnis: Mengapa? -> Siapa? -> Bagaimana? -> Apa? (Kenapa? -> Siapa? -> Bagaimana? -> Apa yang perlu dilakukan?);
2. Kata-kata Kisah Pengguna:
   Sebagai pengguna <...> Saya ingin melakukan <...> untuk mendapatkan <...>.
   Sebagai manajer gudang, saya menerima laporan saldo stok untuk membuat keputusan LEBIH CEPAT;
   Tulisan tanpa TO (lebih baik).
   Sebagai seorang <user>, saya <ingin mendapatkan sesuatu>, <untuk tujuan seperti itu>.
   Sebagai manajer gudang, saya menerima laporan saldo stok CEPAT.
3. Pembagian "aktor" ke dalam kelompok: target, penting, kurang penting, dll. Menetapkan nama unik untuk aktor dalam grup ini, bahkan jika ada peran yang identik untuk "Pengguna Sistem";
4. Menulis cerita dari sudut pandang aktor-aktor ini dengan nama-nama unik;
5. Sebagai hasilnya, Anda dapat melihat cerita apa yang diperlukan untuk aktor-aktor dari kelompok sasaran, kelompok penting, dll. Karena itu, Anda dapat memprioritaskan;
6. Aksi Penting untuk menggambarkan cerita di tingkat "Apa?" Apakah, bukannya "Bagaimana?", menggambarkan masalah, bukan solusinya. "Bagaimana?" bersama tim;
7. Nilai. Penolakan kata-kata "Untuk." Untuk beberapa cerita, Anda dapat menunjukkan nilai cerita dalam format "Kepada", tetapi tidak untuk sebagian besar;
8. Transisi dari konsep "nilai" (nilai) ke konsep "dampak" (dampak). Cerita tidak harus memiliki nilai, tetapi harus berdampak pada aktor yang ditunjukkan dalam cerita. Pengaruh ini pada akhirnya mengarah pada tujuan;
9. Cerita Pengguna dipecah oleh kepentingan dan fungsionalitas dan selanjutnya dipecah menjadi tugas-tugas di backlog.

Memperbaiki dan Mengevaluasi Backlog Produk

Terjadi bersamaan dengan tim Pengembangan. Tim harus mengevaluasi setiap tugas: apakah pada prinsipnya layak? Apakah ada informasi yang cukup untuk dieksekusi?

Dibentuk oleh Sprint. Pertemuan Perencanaan Sprint. Scrum poker

Durasi pertemuan tidak lebih dari 8 jam. Untuk sprint 2 minggu, reli berlangsung selama 2 jam. Untuk memvisualisasikan pelaksanaan tugas dalam sprint, lebih mudah menggunakan papan Kanban.

1. Bagian pertama dari pertemuan terbuka untuk semua.
   Hak suara dengan Pemilik Produk dan Tim Pengembang. Pemilihan Kisah Pengguna dan Tugas dari Backlog Produk ke Sprint Backlog;
   Formulasi Sasaran Sprint - Sasaran Sprint. Menentukan nilai bisnis. Penjelasan singkat tentang tujuan bisnis tempat sprint ini dilakukan. Membantu tim membuat keputusan berdasarkan informasi bisnis, atau keputusan alternatif.
2. Bagian kedua dari reli hanya melibatkan Tim Scrum. Mengisi Sprint Backlog.
   Menentukan bagaimana ruang lingkup pekerjaan akan diimplementasikan. Diskusi rincian teknis;

Scrum Poker (Poker Perencanaan).

Story Points (berdasarkan seri Fibonacci - 1,2,3,5,8,13). Tugas 13 atau lebih poin perlu dibagi menjadi yang lebih kecil. Batas waktu untuk menyelesaikan tugas oleh satu pengembang tidak lebih dari satu hari atau 8 jam. Jika proyek hanya memiliki satu sprint, maka tidak masuk akal untuk menetapkan Story Points, karena tidak akan ada statistik dan, karenanya, tidak akan ada akurasi dalam menentukan peringkat.
Untuk menetapkan Poin Cerita dengan benar, Anda dapat menyimpan statistik, seperti dalam tabel berikut:

1. Scrum Master memimpin pertemuan;
2. Pemilik Produk memberikan ikhtisar singkat tentang setiap tugas;
3. Ada diskusi, pertanyaan diajukan;
4. Anggota Tim Pengembang memilih satu kartu, lalu balik;
5. Jika sebagai akibat dari pemungutan suara, ada sebaran besar di poin, maka dengarkan dua yang telah membalik kartu dengan nilai minimum dan maksimum;
6. Kemudian mereka memilih lagi dan menetapkan Poin Cerita untuk tugas itu.

Rapat scrum harian

Itu diadakan setiap hari. Semua orang bisa menonton. Hanya Tim Scrum yang berbicara. Dilakukan oleh Scrum Master.

1. Itu dilakukan pada saat yang sama;
2. Itu berlangsung ketat tidak lebih dari 15 menit. Pemecahan masalah dilakukan di luar kerangka rapat umum dan sebagai bagian dari orang-orang yang terkena dampak langsung dari hambatan ini;
3. Semua hanya menjawab tiga pertanyaan, saling menjawab, bukan Scrum Master: Apa yang saya lakukan kemarin? Apa yang akan saya lakukan hari ini? Masalah apa yang saya miliki dan tim dalam perjalanan ke tujuan?

Rapat Tinjauan Sprint

Setiap orang terlibat. Peningkatan fungsi produk yang signifikan. Demonstrasi produk jadi atau fungsionalitas.

Durasi rapat: satu jam untuk setiap minggu sprint (2 jam Sprint Review = sprint 2 minggu). Persiapan untuk pertemuan ini tidak boleh lebih dari 2 jam.

Pertemuan Retrospektif Sprint. Retrospektif.

Diadakan pada hari terakhir sprint.

Dirancang untuk mengevaluasi hasil tim. Pertanyaan diajukan: apa yang bisa diperbaiki? bagaimana Bagaimana cara meningkatkan efektivitas tim?
Waktu retrospektif untuk sprint 2 minggu tidak lebih dari 2 jam.
Konsep kaizen dan kebahagiaan. Kaizen - perbaikan terus menerus. Orang yang bahagia = tim berkinerja tinggi.

Anda dapat mengajukan pertanyaan: Apa yang bisa membuat Anda lebih bahagia di sprint berikutnya? Apa yang membuat Anda lebih bahagia?