Bagikan melalui

Scrum dan praktik terbaik

  • Artikel

Layanan Azure DevOps | Azure DevOps Server 2022 - Azure DevOps Server 2019

Rapat perencanaan sprint

Sebagian besar perencanaan sprint melibatkan negosiasi antara pemilik produk dan tim untuk menentukan fokus dan pekerjaan untuk mengatasi dalam sprint mendatang. Ini berguna untuk mengatur waktu rapat perencanaan, membatasinya hingga 4 jam atau kurang.

Di bagian pertama rapat, pemilik produk Anda bertemu dengan tim Anda untuk membahas cerita pengguna yang mungkin disertakan dalam sprint. Pemilik produk Anda berbagi informasi dan menjawab pertanyaan apa pun yang dimiliki tim Anda tentang cerita-cerita tersebut. Percakapan ini mungkin mengungkapkan detail seperti sumber data dan tata letak antarmuka pengguna. Atau mungkin mengungkapkan harapan waktu respons, dan pertimbangan untuk keamanan dan kegunaan. Tim Anda harus mengambil detail ini dalam formulir item backlog. Selama bagian rapat ini, tim Anda mempelajari apa yang harus dibangunnya.

Saat merencanakan sprint, Anda dapat menemukan persyaratan lain untuk menangkap dan menambahkan ke backlog Anda. Pastikan itu didefinisikan dengan baik dan dalam urutan prioritas.

Selain itu, menetapkan tujuan sprint sebagai bagian dari upaya perencanaan Anda dapat membantu tim tetap fokus pada apa yang paling penting untuk setiap sprint.

Setelah merencanakan sprint, Anda mungkin ingin berbagi rencana dengan pemangku kepentingan utama.

Anda dapat mempelajari lebih lanjut dari sumber daya ini:

Menetapkan tujuan sprint

Tim Scrum menggunakan tujuan sprint untuk memfokuskan aktivitas sprint mereka. Mereka sering menetapkan tujuan ini selama pertemuan perencanaan sprint mereka. Tujuannya merangkum apa yang ingin dicapai tim pada akhir sprint. Dengan secara eksplisit menyatakan tujuan, Anda membuat pemahaman bersama dalam tim tujuan inti. Tujuan sprint juga dapat membantu memandu tim ketika konflik muncul di sekitar prioritas.

Tips dari parit: Tentukan tujuan sprint

Tujuan sprint mendefinisikan apa yang dipertimbangkan pemilik produk dan tim sebagai target utama untuk mencapai sprint tersebut. Ini bukan pilihan acak item backlog yang tidak benar-benar memiliki hubungan, tetapi teks singkat yang menangkap apa yang harus dicoba oleh tim. Biasanya pemilik produk muncul dengan tujuan sprint sebelum memilih banyak item untuk sprint berikutnya. Item untuk sprint tersebut semuanya harus sesuai dengan tujuan umum tersebut.

Tujuan sprint dapat berorientasi pada fitur, tetapi mungkin juga memiliki komponen proses besar seperti otomatisasi penyebaran atau otomatisasi pengujian.

Contohnya:

  • Sprint ini akan kita fokuskan pada cerita pengguna sederhana. Kami akan menggunakannya untuk membuktikan bahwa solusi yang diusulkan berfungsi.
  • Sprint ini berputar di sekitar mengimplementasikan fitur keamanan yang mengamankan bagian administrasi situs web dengan benar.
  • Sprint ini adalah tentang mengintegrasikan gateway pembayaran yang paling penting sehingga kita dapat mulai mengumpulkan uang.

Menetapkan tujuan sprint membantu tim untuk tetap fokus. Ini memudahkan untuk menentukan prioritas tugas dalam sprint dan mungkin membantu membatasi jumlah pemangku kepentingan dan pengguna akhir yang terlibat.

Selama tinjauan sprint, pertanyaan terpenting yang harus Anda tanyakan pada diri sendiri adalah apakah Anda berhasil mencapai tujuan sprint. Berapa banyak cerita yang Anda selesaikan datang kedua. Jika tujuan dicapai, sprint berhasil, bahkan jika tidak semua cerita selesai.

Disumbangkan oleh Jesse Houwing, Visual Studio devops Ranger dan konsultan senior yang bekerja untuk Avanade Belanda.

Tips untuk rapat triase yang berhasil

Memperbaiki bug mewakili trade-off dengan pekerjaan lain. Gunakan rapat triase Anda untuk menentukan seberapa penting memperbaiki setiap bug terhadap prioritas lain yang terkait dengan memenuhi cakupan, anggaran, dan jadwal proyek.

  • Tetapkan kriteria tim untuk mengevaluasi bug mana yang harus diperbaiki dan cara menetapkan prioritas dan tingkat keparahan. Bug yang terkait dengan fitur nilai signifikan (atau biaya peluang penundaan yang signifikan), atau risiko proyek lainnya, harus diberi prioritas dan tingkat keparahan yang lebih tinggi. Simpan kriteria triase Anda dengan dokumen tim lain dan perbarui sesuai kebutuhan.
  • Gunakan kriteria triase Anda untuk menentukan bug mana yang akan diperbaiki dan cara mengatur Status, Prioritas, Tingkat Keparahan, dan bidang lainnya.
  • Sesuaikan kriteria triase Anda berdasarkan tempat Anda berada dalam siklus pengembangan Anda. Dini, Anda dapat memutuskan untuk memperbaiki sebagian besar bug yang Anda triase. Namun, nanti dalam siklus, Anda dapat menaikkan kriteria triase untuk mengurangi jumlah bug yang perlu Anda perbaiki.
  • Setelah Anda melakukan triase bug, tetapkan ke pengembang. Pengembang kemudian dapat menyelidiki dan menentukan cara menerapkan perbaikan.

Mengelola utang teknis Anda

Pertimbangkan untuk mengelola bilah bug dan utang teknis Anda sebagai bagian dari serangkaian aktivitas peningkatan berkelanjutan tim Anda secara keseluruhan. Anda mungkin menemukan sumber daya yang menarik ini:

Tips dari parit: Manajemen bug

Manajemen Bug Tangkas: Bukan Oxymoron
oleh Gregg Boer, Principal Program Manager, Visual Studio Cloud Services di Microsoft

Mengatasi utang bug yang diketahui setiap sprint

Setiap sprint, tim melihat bug apa pun yang tersisa di backlog bug dan mendedikasikan kapasitas untuk mendapatkan serangkaian bug yang diketahui hingga nol, atau mendekati nol. Apakah ini satu hari, satu minggu, atau seluruh sprint, mereka memperbaiki bug terlebih dahulu. Bug yang ditemukan kemudian, dalam sprint, tidak dianggap sebagai bagian dari komitmen awal tersebut. Kecuali mereka prioritas tinggi, mereka dimasukkan ke backlog bug untuk sprint berikutnya.

Banyak tim bekerja dalam organisasi berbasis komitmen. Seringkali, manajemen menempatkan nilai tinggi pada kemampuan tim untuk memenuhi komitmen mereka. Melakukan perencanaan kapasitas terhadap serangkaian bug yang diketahui membuat perencanaan sprint lebih deterministik, meningkatkan kesempatan mereka untuk memenuhi komitmen. Setiap bug baru yang ditemukan selama sprint bukan bagian dari komitmen awal, dan dapat diatasi sprint berikutnya.

Mengelola utang bug di seluruh perusahaan

Organisasi yang beralih ke budaya di mana utang terus dihilangkan kemungkinan berurusan dengan pertanyaan berikut: Bagaimana Anda mendapatkan tim untuk mengurangi jumlah bug mereka tanpa memberi tahu mereka apa yang harus dilakukan? Kepemimpinan ingin tim berubah, namun memberikan otonomi tim untuk menentukan bagaimana mereka berubah. Salah satu opsinya adalah menggunakan batas bug.

Misalnya, pertimbangkan batas bug tiga bug per insinyur. Dengan demikian, tim yang terdiri dari 10 orang tidak boleh memiliki lebih dari 30 bug di backlog bug-nya. Jika tim melebihi batasnya, diharapkan untuk berhenti mengerjakan fitur baru dan berada di bawah batas bug. Sebuah tim diharapkan berada di bawah batasnya selalu, tetapi tim memutuskan bagaimana ia ingin melakukan itu. Batas bug memastikan bahwa tim tidak membawa utang bug terlalu lama. Tim dapat belajar dari kesalahan yang menyebabkan bug disuntikkan di tempat pertama.

Ingatlah bahwa tutup bug mewakili bug di backlog bug. Ini tidak termasuk bug yang ditemukan dan diperbaiki dalam sprint tempat fitur dikembangkan. Bug tersebut dianggap sebagai pekerjaan yang dibatalkan, bukan utang.

Sementara bug berkontribusi pada utang teknis, mereka mungkin tidak mewakili semua utang.

Desain perangkat lunak yang buruk, kode yang ditulis dengan buruk, atau perbaikan jangka pendek semuanya dapat berkontribusi pada utang teknis. Utang teknis mencerminkan pekerjaan pengembangan ekstra yang timbul dari semua masalah ini.

Lacak pekerjaan untuk mengatasi utang teknis sebagai PBA, cerita pengguna, atau bug. Untuk melacak kemajuan tim dalam menimbulkan dan mengatasi utang teknis, Anda harus mempertimbangkan cara mengategorikan item kerja dan detail yang ingin Anda lacak. Anda dapat menambahkan tag ke item kerja apa pun untuk mengelompokkannya ke dalam kategori yang Anda pilih.

Peran Scrum Master

Scrum Masters membantu membangun dan memelihara tim yang sehat dengan menggunakan proses Scrum. Mereka membimbing, pelatih, mengajar, dan membantu tim Scrum dalam pekerjaan metode Scrum yang tepat. Scrum Masters juga bertindak sebagai agen perubahan untuk membantu tim mengatasi hambatan dan mendorong tim menuju peningkatan produktivitas yang signifikan.

Tanggung jawab inti Scrum Masters meliputi:

  • Dukung tim untuk mengadopsi dan mengikuti proses Scrum. Misalnya, Anda tidak boleh membiarkan rapat Scrum harian menjadi diskusi terbuka yang berlangsung selama 45 menit.

  • Jaga pemilik produk atau anggota tim dari menambahkan pekerjaan setelah sprint dimulai.

  • Hapus masalah pemblokiran yang mencegah tim membuat kemajuan ke depan. Pekerjaan ini mungkin mengharuskan Anda menyelesaikan tugas kecil, seperti menyetujui pesanan pembelian untuk komputer build baru atau menyelesaikan konflik dalam tim Anda.

  • Bantu tim bekerja untuk menyelesaikan konflik dan masalah yang muncul dan belajar dari proses.

  • Ajukan pertanyaan yang mengungkapkan masalah tersembunyi dan konfirmasikan bahwa apa yang dikomunikasikan orang-orang dipahami dengan baik oleh seluruh tim.

  • Identifikasi dan lindungi tim dari potensi masalah menjadi masalah utama. Sama seperti lebih murah untuk memperbaiki bug segera setelah ditemukan, juga lebih mudah dan kurang mengganggu untuk memperbaiki masalah tim ketika kecil dan dapat dikelola.

  • Mencegah tim menyajikan cerita pengguna yang tidak lengkap selama rapat peninjauan sprint.

  • Kumpulkan, analisis, dan sajikan data kepada pemangku kepentingan bisnis untuk menunjukkan bagaimana tim meningkat dan berkembang. Misalnya, jika tim Anda telah meningkatkan jumlah nilai yang telah dikirimkannya sambil menghasilkan lebih sedikit bug, buat nilai terlihat melalui komunikasi rutin kepada pemangku kepentingan bisnis.

Master Scrum yang baik memiliki atau mengembangkan keterampilan komunikasi, negosiasi, dan resolusi konflik yang sangat baik. Mereka secara aktif mendengarkan kata-kata yang orang katakan dan tulis. Mereka juga mendengarkan bagaimana mereka mengirimkan pesan mereka, misalnya bahasa tubuh mereka, ekspresi wajah, kecepatan vokal, dan komunikasi nonverbal lainnya.

Sama seperti lebih murah untuk memperbaiki bug segera setelah ditemukan, itu juga lebih mudah dan kurang mengganggu untuk memperbaiki masalah tim ketika kecil dan dapat dikelola sebelum tumbuh menjadi masalah besar.

Rapat Scrum Harian

Pertemuan Scrum harian membantu menjaga tim tetap fokus pada apa yang perlu dilakukan keesokan harinya. Tetap fokus membantu tim memaksimalkan kemampuan mereka untuk memenuhi komitmen sprint. Scrum Master Anda harus memberlakukan struktur rapat dan memastikan bahwa itu dimulai tepat waktu dan selesai dalam 15 menit atau kurang.

Tiga aspek keberhasilan pertemuan Scrum adalah:

  • Semua orang berdiri. Berdiri membantu menjaga agar rapat tetap fokus dan singkat.
  • Mereka mulai dan berakhir tepat waktu dan terjadi pada saat yang sama di lokasi yang sama setiap hari
  • Setiap orang berpartisipasi, setiap anggota tim menjawab tiga pertanyaan Scrum:
    • Apa yang telah saya capai sejak Scrum terbaru?
    • Apa yang bisa saya capai sebelum Scrum berikutnya?
    • Masalah atau hambatan pemblokiran apa yang dapat memengaruhi pekerjaan saya?

Catatan

Fokus untuk rapat scrum adalah pada status pekerjaan yang perlu diteruskan dari satu anggota tim ke anggota tim lain.

Anggota tim harus berusaha untuk menjawab pertanyaan mereka dengan cepat dan ringkas. Contohnya:

"Kemarin, saya memperbarui kelas untuk mencerminkan elemen data baru yang kami tarik dari database, dan saya mendapatkannya untuk muncul di antarmuka. Tugas ini selesai. Hari ini, saya memastikan bahwa elemen data baru dihitung dengan benar dengan prosedur tersimpan dan elemen data lainnya dalam tabel. Aku percaya aku bisa menyelesaikan tugas ini hari ini. Aku butuh seseorang untuk meninjau perhitunganku. Saya tidak memiliki hambatan atau masalah pemblokiran."

Respons ini menyampaikan apa yang dicapai anggota tim, apa yang akan dicapai anggota tim, dan bahwa anggota tim ingin bantuan melihat kode.

Kontras dengan contoh berikutnya ini:

"Kemarin, saya bekerja di kelas, dan berhasil. Hari ini, saya bekerja pada antarmuka. Tidak ada masalah pemblokiran."

Anggota tim tidak memberikan detail yang cukup tentang kelas apa yang mereka kerjakan atau tentang komponen antarmuka yang akan mereka selesaikan. Bahkan, kata yang dicapai tidak pernah muncul.

Penting bahwa tidak ada yang mengganggu selama laporan keluar. Setiap orang harus memiliki cukup waktu untuk menjawab tiga pertanyaan tersebut.

Diskusi yang lebih mendalam dan tindak lanjut harus dilakukan setelah rapat, karena orang kembali ke meja mereka atau, jika diperlukan sejumlah besar percakapan, dalam rapat tindak lanjut.

Banyak tim menunda diskusi dengan menggunakan metode "tempat parkir virtual". Ketika subjek muncul bahwa anggota tim berpikir perlu diskusi lebih lanjut, mereka dapat berjalan diam-diam ke papan tulis atau flipchart dan mencantumkan subjek di tempat parkir. Di akhir rapat, tim menentukan cara mereka menangani item yang tercantum.

Rapat peninjauan sprint

Lakukan rapat tinjauan sprint Anda pada hari terakhir sprint. Tim Anda menunjukkan setiap item backlog produk yang diselesaikan dalam sprint. Pemilik produk, pelanggan, dan pemangku kepentingan menerima cerita pengguna yang memenuhi harapan mereka dan mengidentifikasi persyaratan baru apa pun. Pelanggan sering memahami kebutuhan mereka lebih sepenuhnya setelah melihat demonstrasi dan dapat mengidentifikasi perubahan yang ingin mereka lihat.

Berdasarkan rapat ini, beberapa cerita pengguna diterima sebagai selesai. Cerita pengguna yang tidak lengkap tetap berada di backlog produk. Cerita pengguna baru ditambahkan ke backlog. Kedua set cerita diberi peringkat dan diperkirakan atau diperkirakan kembali dalam rapat perencanaan sprint berikutnya.

Setelah rapat ini dan rapat retrospektif, tim Anda merencanakan sprint berikutnya. Karena kebutuhan bisnis berubah dengan cepat, Anda dapat memanfaatkan pertemuan ini dengan pemilik produk, pelanggan, dan pemangku kepentingan Anda untuk meninjau prioritas backlog produk lagi.

Rapat retrospektif sprint

Retrospektif, ketika dilakukan dengan baik dan secara berkala, mendukung peningkatan berkelanjutan.

Rapat retrospektif sprint biasanya terjadi pada hari terakhir sprint, setelah rapat peninjauan sprint. Dalam pertemuan ini, tim Anda mengeksplorasi eksekusi Scrum dan apa yang mungkin perlu di-tweak.

Berdasarkan diskusi, tim Anda mungkin mengubah satu atau beberapa proses untuk meningkatkan efektivitas, produktivitas, kualitas, dan kepuasannya sendiri. Pertemuan ini dan peningkatan yang dihasilkan sangat penting untuk prinsip organisasi mandiri yang tangkas.

Catatan

Untuk mendukung retrospektif tim Anda, pertimbangkan untuk menginstal ekstensi Retrospektif Marketplace. Ekstensi ini mendukung pengumpulan umpan balik tentang tonggak pencapaian proyek Anda, mengatur dan memprioritaskan umpan balik, dan membuat dan melacak tugas yang dapat ditindakkan untuk membantu tim Anda meningkat dari waktu ke waktu.

Lihat untuk mengatasi area ini selama retrospektif sprint tim Anda:

  • Masalah yang memengaruhi efektivitas, produktivitas, dan kualitas umum tim Anda.

  • Elemen yang memengaruhi kepuasan tim Anda secara keseluruhan dan alur proyek.

  • Apa yang terjadi dengan menyebabkan item backlog yang tidak lengkap? Tindakan apa yang dapat dilakukan tim untuk mencegah masalah ini di masa mendatang?

    Misalnya, pertimbangkan tim yang memiliki beberapa tugas yang hanya dapat dilakukan oleh satu individu di tim. Keahlian terisolasi menciptakan jalur penting yang mengancam keberhasilan sprint. Anggota tim individu memasukkan jam tambahan sementara anggota tim lain frustrasi, mereka tidak dapat melakukan lebih banyak hal untuk membantu. Ke depannya, tim memutuskan untuk mempraktikkan Pemrograman eXtreme untuk membantu memperbaiki masalah ini dari waktu ke waktu.

Sebagai tim, bekerja untuk menentukan apakah akan beradaptasi satu atau beberapa proses untuk meminimalkan terjadinya masalah selama sprint.

Tim Anda mungkin perlu melakukan beberapa pekerjaan untuk menerapkan peningkatan. Misalnya, tim yang menemukan diri mereka dipengaruhi secara negatif oleh terlalu banyak build yang gagal memutuskan untuk menerapkan integrasi berkelanjutan. Karena mereka tidak ingin mengganggu proses, mereka membutuhkan waktu beberapa jam untuk menyiapkan build uji coba sebelum mengaktifkannya di build produksi mereka. Untuk mewakili pekerjaan ini, mereka membuat lonjakan dan mengatur yang bekerja melawan backlog produk lainnya.