Bekerja dengan Scrum

Kisah Pengguna

Cerita pengguna adalah cara yang efektif untuk menyatakan persyaratan perangkat lunak dalam pengembangan. Kisah-kisah semacam itu berisi nasihat singkat atas nama pengguna perangkat lunak.

Karena dalam metodologi Scrum, menetapkan tujuan biasanya merupakan hak prerogatif pelanggan atau pemilik perangkat lunak, tujuan tersebut dianggap sebagai cara utama untuk memengaruhi proses pengembangan. Setiap Cerita Pengguna memiliki batasan dalam jumlah teks dan kompleksitas penyajian. Sejarah paling sering ditulis pada lembaran kecil, yang dengan sendirinya membatasi volumenya.

Berkat cerita pengguna, Anda dapat mendokumentasikan keinginan klien dan dengan cepat menanggapi permintaan pasar.

Kisah Pengguna harus dianggap sebagai ukuran persyaratan yang disederhanakan karena tidak menyertakan prosedur pengujian penerimaan. Kompilasi cerita pengguna harus mematuhi prosedur penerimaan. Ini akan memastikan bahwa Kisah Pengguna mencapai tujuannya.

Struktur ceritanya terlihat seperti ini: “Sebagai pengguna <jenis pengguna>, saya ingin melakukan <tindakan> untuk mendapatkan <hasil>” (Sebagai pemilik produk, saya ingin ...). Struktur seperti itu tidak hanya sederhana, tetapi juga dapat dimengerti oleh semua orang.

Manfaat menggunakan Cerita Pengguna:

• Cerita berukuran kecil dan mudah dibuat.
• Bantu semua pemangku kepentingan untuk mendiskusikan pekerjaan proyek dan dukungannya.
• Tidak memerlukan perawatan konstan.
• Relevan hanya bila digunakan.
• Meningkatkan interaksi dengan klien.
• Berkat mereka, Anda dapat membagi proyek menjadi tahapan-tahapan kecil.
• Memfasilitasi pekerjaan pada proyek dengan persyaratan yang kurang dipahami.
• Menyederhanakan evaluasi tugas.

Kerugian Cerita Pengguna:

• Tanpa adanya kesepakatan sebelumnya, prosedur dapat menyulitkan untuk digunakan sebagai dasar kesepakatan.
• Penggunaannya membutuhkan kontak dekat dengan klien di seluruh proyek, yang terkadang membuat alur kerja menjadi sulit.
• Mereka memiliki kelemahan saat menskalakan proyek besar.
• Terkait langsung dengan tingkat profesional pengembang.
• Digunakan untuk memulai diskusi, tetapi mungkin tidak mengakhiri diskusi, dan tidak digunakan untuk dokumentasi sistem.

Jaminan simpanan

Product backlog adalah tugas saat ini dalam bentuk daftar, disusun berdasarkan urutan prioritas. Daftar tersebut dibentuk berdasarkan peta jalan (roadmap) proyek dan poin-poin yang ditetapkan di dalamnya. Tugas yang paling penting biasanya berada di bagian atas daftar. Ini diperlukan untuk memahami pekerjaan mana yang harus dilakukan terlebih dahulu.

Tim pengembang memilih kecepatan menyelesaikan tugas simpanan terlepas dari keinginan pelanggan, tetapi berdasarkan kualifikasi dan pengalaman mereka dari sprint sebelumnya. Sangat tidak diinginkan untuk "menyesuaikan" pemrogram. Tim itu sendiri memilih tugas dari backlog sesuai dengan pertimbangan dan kemampuannya sendiri. Eksekusi berlangsung tanpa interupsi (Kanban) atau beberapa iterasi (Scrum).

Dua kondisi backlog penting

Inti dari product backlog terdiri dari roadmap, proposal, dan kondisi eksekusi. Epik berisi kondisi dan Kisah Pengguna. Mari kita lihat lebih dekat contoh peta jalan umum.

Pembuatan situs web "Teams in Space" adalah proposal pertama dari roadmap. Perlu dibagi menjadi epos (pada gambar ditampilkan dalam warna hijau, biru dan biru kehijauan) dan Kisah Pengguna untuk setiap epik.

Pelanggan perangkat lunak membentuk satu daftar dari beberapa Cerita Pengguna. Jika perlu, dia dapat mengubah urutan eksekusi cerita, sehingga pengembang pertama-tama akan berurusan dengan salah satu epos terpenting (kiri) atau memeriksa cara kerja pemesanan tiket diskon. Untuk melakukan ini, Anda perlu mengimplementasikan cerita dari epos (kanan). Kedua opsi tersebut dapat dilihat di bawah ini.

Berdasarkan faktor apa yang harus diprioritaskan pelanggan?

• Relevansi dengan pengguna.
• Kehadiran umpan balik.
• Kompleksitas pembangunan.
• Hubungan antar tugas (untuk menyelesaikan "B", Anda harus melakukan "A" terlebih dahulu).

Prioritas dalam pekerjaan ditentukan oleh pelanggan, namun pihak lain dapat mengungkapkan pendapatnya mengenai hal tersebut. Keberhasilan backlog bergantung, antara lain, pada pendapat pelanggan dan pemrogram. Bersama-sama, mereka dapat mencapai hasil yang lebih baik dan memastikan pengiriman produk jadi tepat waktu.

Bagaimana cara menyimpan backlog

Jika backlog telah dibuat, maka setelah itu Anda perlu mengubahnya secara berkala untuk pekerjaan selanjutnya. Pelanggan perangkat lunak harus memastikan bahwa backlog dikompilasi dengan benar sebelum setiap perencanaan iterasi baru. Ini akan membantu memperjelas prioritas atau mengubah sesuatu setelah analisis iterasi terakhir. Menyesuaikan backlog di Agile terkadang disebut "grooming" atau "refinement" atau "backlog maintenance".

Jika backlog sudah relatif besar, maka pelanggan perlu mengelompokkan tugas berdasarkan eksekusi jangka pendek dan jangka panjang. Penugasan jangka pendek harus diteliti sebelum diberi status ini. Anda harus membuat Cerita Pengguna, mencari tahu semua nuansa di dalam tim.

Adapun tugas jangka panjang, sangat diinginkan bahwa pengembang memberi mereka penilaian mereka. Ini akan membuatnya lebih mudah untuk diprioritaskan. Mungkin sesuatu akan berubah, tetapi tim akan meningkatkan pemahaman mereka tentang tugas dan menyelesaikan pekerjaan lebih cepat.

Backlog adalah komponen penting antara pelanggan dan tim pemrograman. Pelanggan selalu dapat mengubah prioritas berdasarkan umpan balik pelanggan, prakiraan, atau persyaratan baru.

Disarankan untuk menghindari melakukan perubahan secara langsung selama pengoperasian. Ini berdampak buruk pada alur kerja dan keadaan emosional programmer.

Lari cepat

Sprint adalah periode singkat di mana jumlah pekerjaan yang telah disepakati sebelumnya harus diselesaikan. Sprint didasarkan pada metodologi Scrum dan Agile. Memilih sprint yang tepat membantu tim yang gesit mengembangkan perangkat lunak berkualitas.

“Dengan menggunakan Scrum, Anda dapat mengembangkan produk dalam beberapa iterasi dengan durasi yang jelas - sprint. Ini membantu memecah proyek besar menjadi tugas yang lebih kecil, ”kata Megan Cook, Jira Lead di Atlassian.

Bagaimana Scrum merencanakan dan menjalankan sprint?

Menurut penulis metodologi Scrum, untuk merencanakan sprint di masa mendatang, setiap orang perlu bertemu di pertemuan terpisah. Di acara ini, anggota tim harus menemukan jawaban atas dua pertanyaan utama: apa yang perlu dilakukan dalam sprint ini dan bagaimana cara terbaik melakukannya?

Pelanggan perangkat lunak, master Scrum, dan pemrogram terlibat dalam menentukan daftar tugas kerja. Pelanggan menjelaskan tujuan sprint dan tugas dari backlog.

Kemudian tim mengembangkan rencana yang dengannya tugas-tugas dalam sprint akan diselesaikan. Rencana ini, bersama dengan item pekerjaan yang dipilih, disebut sprint backlog. Setelah rapat perencanaan, tim mulai bekerja. Pengembang memilih tugas dari backlog, saat pekerjaan selesai, status setiap tugas berubah dari "Sedang Berlangsung" menjadi "Selesai".

Selama sprint, tim mengadakan pertemuan Scrum harian (stand-up) untuk membahas masalah dan kemajuan terkini. Pertemuan semacam itu diperlukan untuk mengidentifikasi kesulitan-kesulitan yang dapat mempengaruhi penyelesaian sprint.

Jika sprint sudah selesai, maka tim menunjukkan hasil pekerjaannya pada review hasil (demo). Setiap peserta proyek dapat mengetahui hasilnya. Pengenalan harus dilakukan sebelum kode yang telah selesai digabungkan ke dalam lingkungan produksi.

Retrospektif melengkapi siklus sprint. Di atasnya, tim mengidentifikasi area yang perlu diperbaiki dalam sprint mendatang.

Apa yang harus diperhatikan dan apa yang tidak boleh dilakukan

Sebagian besar tim muda merasa kesulitan untuk memperkenalkan sprint ke dalam alur kerja mereka untuk pertama kalinya. Untuk menghindari masalah, sebaiknya tinjau daftar tindakan yang memerlukan perhatian prioritas.

Apa yang harus kita lakukan:

• Periksa apakah tim memahami tujuan sprint dan bagaimana itu akan berhasil. Ini diperlukan agar setiap orang bergerak menuju hasil yang sukses bersama.
• Anda harus memiliki backlog yang jelas dan dapat dimengerti. Jika backlog tidak dikelola dengan benar, ini bisa menjadi masalah yang dapat merusak alur kerja.
• Pastikan perkiraan kecepatan kerja Anda benar, dengan mempertimbangkan liburan musim panas dan faktor lainnya.
• Berpartisipasi aktif dalam perencanaan sprint. Dorong anggota tim untuk memperluas rencana untuk cerita, bug, dan tugas.
• Menolak tugas di mana pengembang tidak akan dapat menyelesaikan masalah ketergantungan.
• Setelah rencana disetujui, tunjuk karyawan yang akan bertanggung jawab memasukkan data ke dalam program manajemen proyek (kartu Jira, dll.).

Apa yang harus dihindari:

• Jangan terlalu sering menggunakan cerita dalam jumlah besar, menilai kecepatan kerja dengan bijaksana dan jangan menetapkan tugas yang akan sulit diselesaikan dalam sprint.
• Perhatikan kualitas pekerjaan Anda. Periksa apakah Anda memiliki cukup waktu untuk kontrol kualitas dan memperbaiki bug dalam kode.
• Pastikan semua anggota tim memahami dengan jelas isi sprint. Jangan mengejar kecepatan. Seluruh tim harus bergerak bersama.
• Jangan membebani pengembang dengan pekerjaan ekstra. Sprint lain segera hadir.
• Jika tim menyatakan keprihatinan tentang beban kerja atau tenggat waktu, Anda harus mempertimbangkan pendapat mereka. Tangani masalah dan perbaiki jika perlu.

papan scrum

Dewan Scrum adalah alat yang menunjukkan bagaimana pekerjaan Tim Scrum dilakukan. Anda dapat menampilkan informasi di papan seperti itu di atas kertas, di dinding, atau dalam bentuk elektronik (JIRA, Trello).

Papan Scrum memiliki setidaknya tiga kolom: To Do, In Progress, dan Done. Berikut adalah contoh papan:

Papan Scrum berisi semua informasi dari backlog, yang sebelumnya disetujui untuk perencanaan. Sebagai aturan, kartu tugas bisnis disematkan ke papan berdasarkan prioritas dari atas ke bawah. Anda dapat membaginya menjadi jenis pekerjaan tertentu (mengerjakan kode, desain, dan lainnya).

Setelah sebagian pekerjaan selesai, kartu dipindahkan melintasi papan ke kolom berikutnya. Untuk menunjukkan visibilitas kemajuan kerja tim, "pekerjaan yang tersisa" di siang hari di Burndown Chart membantu.

Anda juga dapat menggunakan papan flipchart. Di atasnya, nama-nama karya dituliskan di stiker kertas dan ditempelkan di papan tulis. Segera setelah pekerjaan selesai, stiker dipindahkan ke kolom lain.

grafik burndown

Grafik burndown menunjukkan jumlah pekerjaan yang dilakukan dan jumlah pekerjaan yang tersisa. Itu diperbarui setiap hari dan tersedia untuk semua pihak yang berkepentingan. Grafik diperlukan untuk menunjukkan kemajuan dalam pengerjaan sprint.

Ada dua jenis bagan:

• Bagan burndown menunjukkan kemajuan pekerjaan dalam sprint.
• Bagan burndown yang menunjukkan progres pekerjaan hingga keluarnya produk (data dirangkum dari beberapa sprint).

Contoh bagan:

Contoh ini menggunakan psikologi: bagan tidak menunjukkan jumlah tugas yang diselesaikan, tetapi jumlah yang tersisa (belum selesai).

Artinya, jika tim telah menyelesaikan 90 tugas dari 100, maka mungkin ada perasaan yang salah bahwa semuanya sudah siap. Lagi pula, kemajuan dari 90 menjadi 100 tugas tidak benar-benar mengubah apa pun.

Jika Anda menampilkan jumlah tugas yang tersisa, maka Anda tidak bisa tidak memperhatikan bagaimana setiap kali mereka menjadi semakin sedikit. Ini secara tidak sadar memacu peserta proyek untuk mencapai tujuan lebih cepat - tidak boleh ada tugas yang belum selesai di papan tulis.