Dalam industri TI saat ini, konsep Agile telah menjadi cukup populer. Semua orang membicarakannya. Hampir semua perusahaan TI telah mengadopsi beberapa tingkat agile.
Ada juga banyak metode di bawah payung pengembangan agile, termasuk Extreme Programming (XP), Scrum, Crystal Methods, Adaptive Software Development (ASD), Feature Driven Development (FDD), Dynamic System Development (DSDM), dan ringan. RUP, Test Driven Development (TDD), dan lainnya. Di antara banyak metode pengembangan agile, implementasi Scrum lebih populer.
Agile atau Waterfall? Lihat Angkanya
Laporan terbaru dari Standish Group mencakup proyek yang mereka pelajari antara 2013 hingga 2017. Untuk periode waktu ini, keseluruhan pemecahan keberhasilan, tantangan, dan kegagalan ditunjukkan di bawah ini untuk agile dan waterfall, dengan proyek Agile memiliki kemungkinan sukses sekitar 2X lebih tinggi, dan 1/3 lebih kecil kemungkinan gagal.
(Sumber: vitalitychicago.com — Membandingkan Tingkat Keberhasilan Proyek Waterfall dan Agile)
Artikel ini terutama membagikan pemahaman tentang Scrum, proses implementasi Scrum dan perubahan yang dibawa oleh implementasi Scrum, serta menjelaskan apa itu Scrum yang berjalan.
Apa itu Scrum?
Scrum adalah kerangka kerja untuk mengembangkan dan memelihara produk kompleks dan merupakan proses pengembangan yang inkremental dan iteratif. Dalam kerangka kerja ini, seluruh proses pengembangan terdiri dari beberapa siklus iterasi pendek, siklus iterasi pendek yang disebut Sprint, dan setiap Sprint berlangsung selama 2 hingga 4 minggu.
Dalam Scrum, gunakan Backlog produk untuk mengelola kebutuhan produk. Backlog produk diurutkan berdasarkan prioritas implementasi, dengan nilai komersial sebagai prinsip utama pengurutan. Dalam Sprint, tim Scrum memilih persyaratan dengan prioritas tertinggi dari Backlog produk untuk pengembangan. Persyaratan yang dipilih dibahas, dianalisis, dan diperkirakan dalam Rapat Perencanaan Sprint untuk mendapatkan daftar tugas yang disebut backlog Sprint. Ketika tim Scrum menyelesaikan semua tugas dalam daftar backlog Sprint, Sprint berakhir dan melanjutkan ke siklus iterasi Sprint berikutnya.
Mengapa Scrum Gagal di Beberapa Perusahaan
Scrum memiliki nilai yang besar. Namun, sulit untuk menerapkan Scrum di beberapa perusahaan. Beberapa orang mengatakan bahwa Scrum tidak memiliki efek substansial di organisasi mereka. Mengapa mereka memiliki hasil seperti itu? Alasan utamanya bisa jadi:
- Agile lebih cepat — Tim proyek kurang memahami agile dengan benar. Mereka hanya berpikir bahwa kelincahan itu cepat, yaitu, mengejar kemajuan, dan dapat bebas dari batasan sistem apa pun.
- Agile lebih cepat, atau kita perlu lembur — Saya telah mendengar bahwa beberapa perusahaan harus mengembangkan fungsi baru. Karena implementasi scrum, tim proyek diharuskan untuk lembur, dan tugas pengembangan selama 2 minggu atau lebih akan dirilis dalam satu minggu. Menerapkan Scrum berarti bahwa tim proyek bekerja lembur, yang menyebabkan ‘ketakutan’ dalam kelincahan tim proyek;
- Backlog Produk tidak terkelola dengan baik — PO tidak dapat memenuhi syarat untuk pekerjaan, tidak dapat membagi cerita pengguna yang efektif, atau pembagian cerita pengguna tidak masuk akal, tidak dapat mewujudkan pengembangan generasi inkremental;
- Masalah Pembentukan Tim — Scrum memiliki permintaan tinggi untuk tim yang dapat mengorganisir diri sendiri, tetapi banyak anggota tim merasa bahwa mereka tidak memenuhi standar organisasi mandiri;
- Kurangnya budaya Agile — Scrum mendorong transparansi pekerjaan, penyelesaian proyek secara real-time dan pengakuan tugas setiap orang. Papan Sprint dan grafik burndown proyek tidak terhalang, dan banyak orang merasa tidak nyaman dengan itu;
- Inspeksi dan Adaptasi tidak dilakukan — Dalam proses iterasi, masalah tidak dapat ditemukan tepat waktu, atau masalah ditemukan, dan masalah tidak dapat diselesaikan secara efektif, yang membuat tim proyek merasa frustrasi. dan banyak lagi.
Jika pengetahuan tentang Scrum hanya terjebak di:
“Saya memiliki ide di pagi hari, itu akan direalisasikan di sore hari, dan akan online di malam hari.”
Itu tidak tepat. Menurut pendapat saya, Scrum pasti berharga. Fungsi utama Scrum meliputi:
- Scrum dapat memastikan untuk memprioritaskan pengembangan backlog produk yang memiliki nilai tinggi bagi pelanggan dan lebih baik memenuhi kebutuhan pengguna.
- Dibandingkan dengan metode pengembangan di bawah proses waterfall, dengan menerapkan Scrum, tim dapat menggandakan efisiensi pengembangan dan memaksimalkan peran tim;
- Scrum dapat memperpendek siklus pengembangan dan meningkatkan efisiensi pengiriman proyek.
Namun, menerapkan Scrum tidak berarti bahwa itu tidak tunduk pada aturan dan batasan proyek. Jadi, apa sikap yang benar untuk menerapkan Scrum?
Langkah-langkah untuk Menerapkan Scrum
1. Menunjuk seorang PO
PO adalah Pemilik Produk, yang merupakan sebuah peran, dan PO adalah satu-satunya pemilik daftar tugas manajemen produk. Tentu saja, di beberapa perusahaan PO sudah ada sebagai sebuah organisasi — misalnya, perusahaan kami telah menerapkan PO sebagai organisasi dalam implementasi Scrum.
Sebagai pemilik, harus memiliki gambaran besar; memahami informasi dan arah industri dengan mendalam; mampu memahami arah produk, bertanggung jawab atas perencanaan dan manajemen produk jangka pendek serta jangka menengah dan panjang; mampu melakukan penelitian pengguna dan perencanaan fungsi produk sesuai dengan kebutuhan strategis perusahaan, melacak kebutuhan yang terus berubah, dan terus berinovasi produk.
Selain itu, jika Anda menggunakan PO sebagai organisasi, dalam proyek pengembangan perangkat lunak, tim PO mungkin melibatkan pemangku kepentingan lain termasuk anggota seperti manajer produk, pengguna akhir.
2. Bentuk Tim Pengembangan
Tim adalah pelaksana produk dan bertanggung jawab untuk mengirimkan Increment yang dapat dikirim dan Increment produk yang ‘selesai’ di akhir setiap Sprint.
Tim terutama terdiri dari personel pengembangan dan pengujian, dan tim harus mampu menerapkan visi PO tentang produk.
Ukuran tim harus sekitar 5 hingga 9 orang.
Tim Scrum juga harus bersifat lintas fungsi dan anggota dengan kemampuan ‘full stack’ lebih diutamakan, meskipunitu mungkin sulit untuk diterapkan di sebagian besar perusahaan.
3. Pilih Scrum Master
Scrum Master bertanggung jawab atas proses Scrum dan melayani PO serta tim pengembangan. Scrum Master harus memiliki rasa ritual, dan dapat secara efektif dan efisien mengorganisir rapat perencanaan iteratif, rapat harian, rapat demonstrasi fungsi, dan rapat tinjauan retrospektif; Scrum Master harus memiliki tingkat eksekusi yang tinggi dan menjaga kredibilitas untuk membantu tim. Fokus pada tujuan pengiriman dan tujuan kualitas untuk memastikan tim mengirimkan produk berkualitas tinggi secara efisien; mendorong tim untuk membangun proses yang efisien, membimbing tim tentang nilai-nilai agile, prinsip-prinsip dan praktik agile; bertanggung jawab untuk melatih anggota tim lainnya untuk memastikan bahwa Scrum digunakan dengan benar; Komunikasi, manajemen masalah, penyelesaian konflik, membantu tim menghilangkan semua hambatan.
4. Pertahankan Backlog produk
Product Backlog adalah kumpulan semua item backlog, dan didasarkan pada strategi perusahaan dan visi produk. PO mengurutkan semua item dalam product backlog sesuai dengan urutan prioritas berdasarkan nilai bisnis, dan membentuk daftar item yang diprioritaskan. Theproduct backlog dapat berfungsi sebagai “peta jalan” pengembangan produk. Untuk memahami konteks produk, item-item dalam product backlog adalah referensi terbaik.
Setiap hari kita menghadapi tuntutan baru dari pesaing baru, yang berarti bahwa PO harus terus mengoptimalkan desain produknya dan menyesuaikan prioritas product backlog untuk menghadapi perubahan baru.
Dalam proses ini, PO harus berkonsultasi dengan semua pemangku kepentingan dan tim untuk memastikan bahwa product backlog mencerminkan klaim sebenarnya dari pengguna.
5. Estimasi Agile menggunakan Story Point
Estimasi agile relatif biasanya dilakukan pada perencanaan sprint atau sentuhan selama sprint dan product backlog dievaluasi oleh tim bersama dengan yang bertanggung jawab atas pengembangan dan pengujian yang sebenarnya.
Untuk melakukan perencanaan sprint yang lebih efisien dalam praktik, PO dan Scrum Master akan membuat estimasi kasar sebelum rapat perencanaan sprint. Mereka perlu mengajukan pertanyaan-pertanyaan seperti:
- Lihat apakah rencana sprint itu layak?
- Apakah ada cukup informasi untuk menyelesaikan hal-hal ini?
- Apakah pemisahan item product backlog itu masuk akal?
Ketika tim pengembangan melakukan estimasi, disarankan untuk meninggalkan metode tradisional (yaitu berapa banyak jam yang akan ditugaskan untuk tugas) dan menggunakan pendekatan estimasi agile dengan menggunakan story point – angka Fibonacci (1, 2, 3, 5, 8, 13, 21…) untuk mengevaluasi usaha yang diperlukan untuk pelaksanaan suatu item.
Pada saat estimasi, tim perlu terlebih dahulu mengidentifikasi item backlog yang mungkin dalam bentuk user story sebagai referensi untuk estimasi. Selain itu, penting untuk dicatat bahwaketika satu story point dari penilaian lebih besar dari 21, user story perlu dibagi lagi, dan satu story point user tidak lebih dari 8 adalah keadaan ideal.
6. Rapat perencanaan sprint
Ini adalah rapat Scrum yang pertama. Tim, Scrum Master, dan PO duduk bersama untuk merencanakan konten sprint.Sebagai proyek pengembangan perangkat lunak, saat memasukkan user story dari perencanaan sprint, user story harus sudah dibagi dan desain visual diselesaikan.
Siklus sprint umumnya tetap, biasanya selama 2 hingga 4 minggu. Tim mulai dengan user story yang memiliki prioritas tertinggi dalam daftar tugas produk untuk melihat seberapa banyak yang dapat dilakukan dalam satu sprint.
Jika tim sudah melakukan beberapa sprint, dengan merujuk pada:
- “story points” yang diselesaikan dalam iterasi sebelumnya,
- Tim dapat memperkirakan story points yang kira-kira untuk iterasi ini.
- “Story points” setara dengan kecepatan tim.
Scrum Master dan Tim harus berusaha untuk meningkatkan angka ini di setiap iterasi sprint.
Semua anggota tim harus membentuk konsensus tentang tujuan sprint, yaitu, apa yang perlu dicapai dalam iterasi sprint. Pada rapat perencanaan sprint, PO perlu memberi tahu Tim urutan prioritas pelaksanaan user story. Tim berjanji berapa banyak cerita yang akan mereka selesaikan dalam iterasi sprint berikutnya. Dalam proses sprint, tidak ada yang dapat secara sepihak mengubah konten sprint tanpa otorisasi.
7. Rapat Stand-up Harian
Daily Stand-up adalah sumber vitalitas untuk Scrum. Peserta umumnya termasuk PO, Scrum Master, dan tim. Tim berkomunikasi secara internal di lokasi tetap dan pada waktu tetap setiap hari. Thewaktu biasanya pagi, durasinya tidak lebih dari 15 menit, dan berdiri. Scrum Master bertanya kepada tim anggota pertanyaan berikut:
- Apa yang kamu lakukan kemarin?
- Pekerjaan apa yang kamu rencanakan untuk dilakukan hari ini?
- Apa saja hambatan dan rintangan?
Signifikansi dari ini adalah untuk memberi tahu seluruh tim dengan jelas tentang kemajuan setiap tugas selama siklus sprint ini, dan apakah semua tugas dapat diselesaikan tepat waktu.
Tugas tim tidak ditugaskan dari atas ke bawah, tetapi diputuskan atas inisiatif dan secara sukarela. Jika tugas sebelumnya belum selesai, Anda tidak dapat mengajukan tugas berikutnya, dan Anda tidak dapat mengklaim dua tugas yang tidak dapat diselesaikan pada hari yang sama.
Scrum Master bertanggung jawab untuk menghilangkan hambatan yang dihadapi oleh anggota tim.
8. Melacak Kemajuan Proyek dengan Papan Tugas Scrum
Dalam Scrum, pekerjaan harus transparan, dan praktik yang paling umum adalah menerapkan papan tugas Scrum.
Beberapa tim mahir menggunakan alat pihak ketiga untuk menggunakan papan Scrum elektronik, seperti Visual Paradigm atau Jira; beberapa tim senang menggunakan papan putih fisik besar secara offline.
Terlepas dari apakah Anda menggunakan papan Scrum elektronik atau papan putih fisik, kolom Kanban biasanya mencakup tiga bagian: daftar tugas, item yang sedang berlangsung, dan item yang telah diselesaikan. Seiring kemajuan iterasi, tim akan segera memperbarui hal tersebut ke kolom Kanban Scrum yang sesuai setiap hari.
9. Melacak kemajuan dengan grafik burn-out
Alat lain untuk membuat pekerjaan transparan adalah grafik burn-out. Dalam gambar di bawah, satu sumbu mewakili beban kerja, dan yang lainnya mewakili waktu. Setiap hari Scrum Master mencatat poin yang tersisa untuk diselesaikan dan kemudian menggambarnya di grafik burn-out. Idealnya, grafik adalah kurva menurun, terbakar hingga nol saat sisa pekerjaan diselesaikan.
10. Demonstrasi Produk
Bagian demonstrasi dari Panduan Scrum disebut Rapat Tinjauan Sprint, yang menyatakan bahwa itu harus mencakup demonstrasi pekerjaan yang dilakukan oleh tim pengembangan dan menjawab pertanyaan tentang peningkatan produk. Rapat ini biasanya diadakan sebelum rilis iterasi ini.Pekerjaan terpenting dari rapat ini adalah untuk memverifikasi skenario implementasi user stories dengan evaluasi penerimaan dari setiap item yang diselesaikan untuk memenuhi definisi selesai.
Rapat ini adalah tempat di mana siapa pun dapat menjadi peserta, tidak hanya PO, Scrum Master, dan tim, tetapi juga pemangku kepentingan, bisnis, dan manajer, dan bahkan pelanggan.
Ini adalah rapat terbuka di mana siapa pun dapat menjadi peserta, tidak hanya PO, Scrum Master, dan tim, tetapi juga pemangku kepentingan, bisnis, dan manajer, dan bahkan pelanggan.
Tim harus menunjukkan hanya item-item yang memenuhi definisi selesai, yaitu, hasil yang dapat disampaikan tanpa harus melakukan pekerjaan lebih lanjut. Hasil ini mungkin bukan produk yang lengkap, tetapi setidaknya merupakan fitur yang lengkap dan dapat digunakan oleh pengguna akhir.
11. Retrospektif Sprint
Pertemuan retrospektif sprint biasanya diadakan pada hari kedua setelah akhir Sprint ini.
Pertemuan retrospektif sprint harus dengan hati-hati meninjau pertanyaan-pertanyaan berikut:
- Apa yang telah terjadi untuk diperbaiki;
- Mengapa itu terjadi?
- Mengapa kita mengabaikannya pada saat itu;
- Bagaimana kita bisa mempercepat pekerjaan.
Sebagai sebuah tim, untuk membuat proses retrospektif sprint ini efektif, tim perlu saling percaya. Kita harus mengingat diskusi dan argumen yang berdasarkan pada isu proyek dan teknis:
- Tidak ada yang benar atau salah secara mutlak dan tidak perlu khawatir,
- Dorong terjadinya benturan teknis;
- Tidak boleh melibatkan diskusi tentang serangan pribadi;
- Tahan orang-orang yang memakai kacamata berwarna untuk melihat orang,
- Pandulah semua orang untuk berdiskusi secara rasional;
- Dengan berani terima tantangan dari orang lain,
- Terima ketidaksempurnaan diri sendiri.
- Bertanggung jawab atas proses dan hasil mereka sendiri,
- melakukan brainstorming dan mencari solusi untuk masalah. Ini sangat penting.
Akhirnya, tim mengidentifikasi salah satu perbaikan yang paling berharga dan menetapkannya sebagai prioritas utama untuk sprint berikutnya. Anda perlu mendefinisikan apa yang dianggap “berhasil” dengan cara yang konkret dan dapat ditindaklanjuti sehingga Anda dapat dengan cepat menentukan apakah perbaikan telah dilakukan dalam pertemuan tinjauan sprint berikutnya.
Setelah sprint terakhir selesai, mulai masuk ke iterasi sprint baru.
Ringkasan
Scrum adalah kombinasi dari 3355. Konsep inti dari kerangka kerja scrum dapat diingat dengan sederhana sebagai 3.3.5.5 sebagai berikut:
3 peran
- Pemilik Produk
- Tim Pengembang
- Master Scrum
3 Artefak
- Daftar Pekerjaan Produk
- Daftar Pekerjaan Sprint — Daftar Tugas Sprint
- Inkrement Produk — Inkrement Produk yang Potensial untuk Dikirim
5 acara
- Sprint
- Pertemuan Perencanaan Sprint
- Pertemuan Scrum Harian
- Pertemuan Tinjauan Sprint
- Pertemuan Retrospektif Sprint
5 nilai
- Terbuka
- Menghormati
- Keberanian
- Fokus
- Komitmen
Tujuan dari 3355 ada di balik tiga Pilar Scrum
- Transparan
- Inspeksi
- Adaptasi
Definisi “Selesai” (DoD) dicapai dengan memenuhi 3 pilar melalui 5 acara dari Tim Scrum.
This post is also available in Deutsch, English, Español, فارسی, Français, 日本語, Polski, Portuguese, Ру́сский, Việt Nam, 简体中文 and 繁體中文.