Bagikan melalui

Scrum dan praktik terbaik

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 mencatat detail ini pada formulir item backlog. Selama bagian rapat ini, tim Anda mempelajari apa yang harus dibangunnya.

Saat Anda merencanakan sprint, Anda mungkin menemukan persyaratan lain yang perlu dicatat dan ditambahkan 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 sasaran, Anda menciptakan pemahaman bersama dalam tim mengenai inti dari tujuan tersebut. Tujuan sprint juga dapat membantu memandu tim ketika konflik muncul di sekitar prioritas.

Tips dari pengalaman langsung: 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 menetapkan tujuan sprint sebelum memilih banyak item produk 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.

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

Tips agar rapat triase sukses

Memperbaiki bug mewakili pertukaran dengan pekerjaan lain. Gunakan rapat triase Anda untuk menentukan pentingnya memperbaiki setiap bug dibandingkan dengan prioritas lain yang terkait dalam 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 prosedur triase Anda bersama dengan dokumen tim lainnya 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. Pada tahap awal, Anda mungkin memutuskan untuk memperbaiki sebagian besar bug yang Anda urutkan. Namun, nanti dalam siklus, Anda dapat menaikkan kriteria triase untuk mengurangi jumlah bug yang perlu Anda perbaiki.
  • Setelah Anda menangani bug, tetapkan ke seorang pengembang. Pengembang kemudian dapat menyelidiki dan menentukan cara menerapkan perbaikan.

Mengelola utang teknis Anda

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

Tips dari lapangan: Pengelolaan bug

"Agile Bug Management": Bukan Oksimoron
oleh Gregg Boer, Principal Program Manager, Visual Studio Cloud Services di Microsoft

Mengatasi utang bug yang diketahui setiap sprint

Setiap sprint, tim meninjau bug yang tersisa di backlog bug dan mendedikasikan kapasitas mereka untuk mengurangi jumlah 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 jika mereka merupakan prioritas tinggi, mereka dimasukkan ke backlog bug untuk sprint selanjutnya.

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 penutup serangga.

Misalnya, pertimbangkan batas tiga bug untuk setiap 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 untuk selalu berada di bawah batas anggarannya, tetapi tim tersebut memutuskan bagaimana mereka ingin melakukannya. Batasan bug memastikan bahwa tim tidak membawa beban bug terlalu lama. Tim dapat belajar dari kesalahan yang menyebabkan bug masuk di awalnya.

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 belum selesai, 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 PBI, kisah 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 pilihan Anda.

Peran Scrum Master

Scrum Masters membantu membangun dan memelihara tim yang sehat dengan menggunakan proses Scrum. Mereka membimbing, melatih, mengajar, dan membantu tim Scrum dalam penggunaan 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.

  • Lindungi agar pemilik produk atau anggota tim tidak 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 agar potensi masalah tidak berkembang menjadi masalah besar. 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.

  • Cegah tim menyajikan cerita pengguna yang tidak lengkap selama rapat tinjauan 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?

Nota

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. Sebenarnya, kata diselesaikan tidak pernah muncul.

Penting untuk memastikan bahwa tidak ada yang mengganggu selama sesi pelaporan. Setiap orang harus memiliki cukup waktu untuk menjawab tiga pertanyaan tersebut.

Diskusi yang lebih mendalam dan tindak lanjut sebaiknya dilakukan setelah rapat, ketika orang-orang sudah kembali ke meja mereka, atau, jika diperlukan percakapan yang signifikan, diadakan 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.

Pertemuan tinjauan 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 kumpulan cerita diberi peringkat dan diperkirakan atau dihitung ulang 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 tinjauan 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.

Nota

Untuk mendukung retrospektif tim Anda, pertimbangkan untuk menginstal ekstensi Marketplace Retrospectives. 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.

Fokus pada mengatasi bidang ini selama sesi retrospektif tim sprint Anda.

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

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

  • Apa yang menyebabkan item backlog 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 kritis yang mengancam kesuksesan sprint. Anggota tim individu memasukkan jam tambahan sementara anggota tim lain frustrasi, mereka tidak dapat melakukan lebih banyak hal untuk membantu. Ke depan, tim memutuskan untuk berlatih Pemrograman Ekstrem 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 menciptakan sebuah uji coba dan mengatur pekerjaan itu sehubungan dengan sisa backlog produk.