Ikhtisar Scrum

Ikhtisar Scrum

Dalam Scrum, manajer proyek disebut sebagai Scrum Master, dan tim proyek disebut sebagai Tim Scrum. Terdapat Product Owner yang memprioritaskan fitur dan persyaratan yang akan dikembangkan pada Product Backlog.

Metodologi Scrum menggunakan Sprints untuk mengirimkan peningkatan kecil dalam pekerjaan dan mengumpulkan umpan balik dari pelanggan.

Terdapat tiga (3) pilar Scrum:

SCRUMmenggunakan pendekatan empiris (kadang disebut empirisme) untuk beradaptasi terhadap kebutuhan pelanggan yang terus berubah. Empirisme adalah praktik pengambilan keputusan berdasarkan pengalaman nyata. Pendekatan empiris berarti bekerja secara berbasis fakta, berbasis pengalaman, dan berbasis bukti—terutama di mana kemajuan didasarkan pada pengamatan realitas, bukan pada rencana awal yang rumit berdasarkan persyaratan awal yang luas.

Singkatnya, kita belajar dan berkembang dari kesalahan dan pengalaman masa lalu. Tiga pilar Scrum yang mendukung pengendalian proses empiris dalam setiap implementasi adalah: Transparansi, Inspeksi, dan Adaptasi, seperti yang ditunjukkan pada diagram di bawah ini:

The Three Pillars of Scrum

  • Transparansi — Bahasa bersama dan standar untuk memastikan konsistensi dan pemahaman bersama.
  • Inspeksi — Tinjauan rutin terhadap kemajuan dan hasil Scrum untuk mendapatkan umpan balik. Sangat penting untuk tidak menyembunyikan kemajuan proyek.
  • Adaptasi — Mudah mengintegrasikan umpan balik yang diterima dan menangani masalah ketika muncul.

Komponen Proses Scrum

The kerangka kerja Scrumsendiri sangat sederhana. Ia hanya mendefinisikan beberapa pedoman umum, bersama dengan sejumlah kecil aturan, peran, hasil kerja, dan acara. Namun, masing-masing komponen ini penting, memiliki tujuan khusus, dan sangat krusial untuk menggunakan kerangka kerja secara sukses.

Komponen utama dari kerangka kerja Scrum adalah:

Diagram di bawah ini menggambarkan elemen-elemen kunci dari kerangka kerja SCRUM. Proses ini telah diimplementasikan dalam Alat perangkat lunak Agile — Kanvas Proses Scrum.

Scrum Framework
Kerangka Kerja Scrum

Peran Scrum

Ketika suatu organisasi memutuskan untuk menerapkan Scrum, salah satu hal pertama yang perlu dipahami adalah bagaimana peran Scrum berbeda dari peran pelaksanaan proyek tradisional. Meskipun Scrum hanya memiliki tiga peran utama, peran-peran tersebut tidak secara otomatis sesuai dengan jabatan yang paling kita kenal. Mari kita mulai dengan definisi singkat dari masing-masing:

Pemilik Produk

Pemilik Produk adalah peran Scrum yang bertanggung jawab untuk mewakili komunitas bisnis atau pengguna dan bekerja sama dengan kelompok pengguna untuk menentukan fitur-fitur mana yang akan dimasukkan dalam rilis produk. Tanggung jawab utama Pemilik Produk adalah:

  • Menentukan arah dan strategi untuk produk atau layanan, termasuk tujuan jangka pendek dan jangka panjang;
  • Memberikan atau mendapatkan pengetahuan tentang produk atau layanan;
  • Membantu tim pengembangan memahami dan menafsirkan kebutuhan pelanggan;
  • Mengumpulkan, memprioritaskan, dan mengelola persyaratan untuk produk atau layanan;
  • Menanggung tanggung jawab atas semua kewajiban terkait anggaran produk atau layanan, termasuk profitabilitasnya;
  • Menentukan tanggal rilis untuk fitur produk atau layanan;
  • Menjawab pertanyaan dan membuat keputusan setiap hari bersama tim pengembangan;
  • Menerima atau menolak fitur yang telah selesai terkait Sprint;
  • Menunjukkan hasil utama tim pengembangan di akhir setiap Sprint;
  • Bertanggung jawab atas Product Backlog.

Master Scrum

Master Scrum adalah fasilitator tim pengembangan agil. Scrum adalah metode yang memungkinkan tim untuk mengatur diri sendiri dan melakukan perubahan cepat sesuai prinsip-prinsip agil. Master Scrum mengelola proses pertukaran informasi. Tanggung jawab utama Master Scrum adalah:

  • Bertindak sebagai pelatih untuk membantu tim mengikuti nilai dan praktik Scrum;
  • Membantu menghilangkan hambatan dan melindungi tim dari gangguan eksternal;
  • Memfasilitasi kolaborasi yang baik antara tim dan pemangku kepentingan;
  • Mempromosikan akal sehat di dalam tim;
  • Melindungi tim dari campur tangan organisasi.

Tim Scrum

Tim Scrum (juga dikenal sebagai Tim Pengembangan) terdiri dari 3 hingga 9 orang yang secara kolektif memiliki semua keterampilan teknis yang dibutuhkan untuk menghasilkan produk atau layanan. Mereka secara langsung dibimbing oleh Master Scrum tetapi tidak dikelola secara langsung. Mereka harus mampu mengatur diri sendiri, berbagai macam keterampilan, dan cukup bertanggung jawab untuk menyelesaikan semua tugas yang diperlukan.

Tim Pengembangan bertanggung jawab untuk menghasilkan peningkatan produk yang dapat dikirimkan dalam setiap Sprint—mulai dari analisis, desain, pengembangan, pengujian, hingga penulisan teknis. Karakteristik utama Tim Scrum meliputi:

  • Tim harus mampu mengatur diri sendiri. Semua anggota tim harus mengelola usaha mereka sendiri untuk menyelesaikan tugas yang diberikan. Dalam Scrum agil, tidak ada pemimpin tim atau figur manajer langsung. Semua orang harus cukup komitmen untuk menjalankan aktivitas mereka dan berkontribusi terhadap keberhasilan tim. Jika satu orang gagal, semua orang gagal.
  • Tim harus bersifat lintas fungsi. Semua anggota tim harus memiliki pengetahuan dan keterampilan yang diperlukan untuk menghasilkan layanan atau produk yang lengkap dan siap digunakan. Ahli dapat digunakan jika diperlukan, tetapi hanya sebagai pelatih untuk mentransfer pengetahuan ke tim dan mengisi celah khusus.
  • Product Owner membutuhkan visi bisnis. Product Owner mewakili suara pelanggan dan harus menyampaikan kebutuhan mereka kepada Master Scrum dan Tim Pengembangan. Ini biasanya merupakan peran penuh waktu.
  • Master Scrum bukan manajer langsung. Mereka memberikan pelatihan yang dibutuhkan untuk Tim Pengembangan dan membantu menghilangkan hambatan yang dihadapi tim.

Backlog Produk

Ini adalah daftar terurut semua pekerjaan yang harus dilakukan pada proyek. Ini disajikan dalam bentuk cerita, yang umum disebut cerita pengguna.

Cerita Pengguna — Representasi berbeda tentang bagaimana pengguna berinteraksi dengan hasil proyek (produk, layanan, atau hasil). Melalui cerita pengguna, tim mengidentifikasi fitur dan fungsi yang dibutuhkan untuk hasil proyek.

Oleh karena itu, Backlog Produk berisi cerita pengguna yang diprioritaskan (fitur dan fungsi) untuk produk/layanan/hasil. Product Owner bertanggung jawab atas pemrioritasan backlog.

Catatan: Anda tidak perlu membuat semua cerita untuk seluruh proyek sebelum memulai pekerjaan (ini salah satu keunggulan pendekatan agile). Mulailah dengan cerita-cerita yang Anda ketahui, dan seiring Anda mempelajari lebih banyak, tambahkan ke dalam daftar backlog dan atur kembali prioritas sesuai kebutuhan.

Perencanaan Sprint

Berbeda dengan pendekatan waterfall, tim agile tidak merencanakan semuanya di awal. Di sini, tim merencanakan sedikit: apa yang dibutuhkan untuk Sprint saat ini (Sprint biasanya berdurasi 2 hingga 4 minggu), menyerahkannya, belajar darinya, dan kemudian merencanakan Sprint berikutnya lagi.

Tim Scrum meninjau Product Backlog dan memilih jumlah cerita pengguna yang dapat mereka selesaikan dalam waktu Sprint. Cerita pengguna yang dipilih menjadi Sprint Backlog. Sprint Backlog mewakili tujuan Sprint.

Definisi Selesai juga ditetapkan. Definisi Selesai dapat dipahami sebagai kriteria penerimaan untuk item-item di backlog.

Rencanakan hanya pekerjaan yang sesuai dengan kapasitas tim—yaitu pekerjaan yang dapat diselesaikan secara realistis oleh tim dalam setiap Sprint.

Rapat Harian Scrum (Standup Harian)

Tim menggunakan pertemuan ini untuk membuat komitmen kecil satu sama lain, mengidentifikasi masalah, dan memastikan pekerjaan Sprint berjalan lancar dalam tim. Pertemuan ini biasanya berdurasi 15 menit. Tim menjawab pertanyaan-pertanyaan berikut:

  • Apa yang telah saya selesaikan sejak rapat Scrum terakhir?
  • Apa rencana saya hari ini? Apa yang ingin saya selesaikan antara sekarang dan rapat Scrum berikutnya?
  • Apakah ada hambatan (masalah, isu, atau risiko) yang menghalangi saya?

Ingat, pertemuan ini bukan pertemuan status—bukan untuk menyelesaikan masalah, tetapi untuk menyadari adanya masalah (jika ada). Jika diperlukan pertemuan untuk menyelesaikan isu, adakan secara terpisah.

Rapat Tinjauan Sprint

Pada akhir setiap Sprint, tim menunjukkan semua item pekerjaan yang telah selesai. Rapat tinjauan ini digunakan untuk menerima masukan dari pemangku kepentingan proyek dan permintaan perubahan.

Penting untuk dicatat bahwa item pekerjaan yang belum 100% selesai sesuai dengan Definisi Selesai yang ditetapkan selama perencanaan tidak akan ditampilkan, karena mereka belum “Selesai.”

Rapat Refleksi Sprint

Pertemuan ini dilakukan setelah Tinjauan Sprint. Tujuannya adalah membantu tim belajar dari Sprint. Proses ini berfokus pada perbaikan berkelanjutan daripada menyalahkan tim jika sesuatu tidak berjalan baik selama Sprint.

Tim merefleksikan cara menjadi lebih efektif dan mengidentifikasi area lain yang perlu ditingkatkan.

Master Scrum menentukan tingkat kepentingan setiap item perbaikan, lalu tim memilih jumlah yang sesuai dari item perbaikan untuk diimplementasikan pada Sprint berikutnyaSprint.

Leave a Reply