Scrum: Implementasi Agile Software Development

Sering terjadi keperluan untuk mengubah requirements di tengah pengembangan suatu perangkat lunak. Hal ini dapat disebabkan karena adanya kesalahpahaman antar client dan developer team, sistem atau hardware yang tidak memadai, atau bisa juga karena kondisi eksternal yang telah berubah sehingga requirements yang telah disusun menjadi tidak relevan.

Jika pengembangan perangkat lunak menggunakan metodologi yang memprioritaskan fokus terhadap rencana awal, pengembangan akan kurang fleksibel terhadap keperluan untuk mengubah requirements. Sebagai solusinya, dikembangkan agile process model.

Agile Process Model

sumber gambar

Kata agile pada agile process model memiliki arti cepat beradaptasi. Model proses pengembangan perangkat lunak ini didasari oleh sekumpulan nilai yang dinamakan Agile Manifesto. Nilai-nilai yang dimaksud adalah:

1. Individuals and interactions over processes and tools, yaitu mengutamakan individu dan komunikasi antar individu atau kelompok. Pada suatu proyek, anggota-anggota proyek lah yang menggerakkan pengembangan. Tanpa mereka proyek tidak akan berjalan. Tentunya dalam proyek kelompok tidak hanya satu anggota saja yang bekerja. Karena itu juga diutamakan komunikasi antar anggota. Hal ini agar tiap anggota mengetahui kemampuan masing-masing sehingga pembagian tugas tidak dengan asal dan mencegah terjadinya konflik antar pengerjaan tugas.
2. Working software over comprehensive documentation, yaitu mengutamakan hasil yang bekerja daripada dokumentasi. Hal ini diterapkan agar waktu tidak banyak terbuang akibat pembuatan dokumentasi yang banyak. Dengan ini, lebih banyak waktu yang dapat disalurkan untuk pengembangan perangkat lunak yang menjadi target proyek sehingga hasil dapat lebih cepat diberikan ke client.
3. Customer collaboration over contract negotiation, yaitu mengutamakan kolaborasi dengan client. Nilai ini diterapkan agar client lebih terlibat dalam proses pengembangan sehingga dapat mengecek apakah yang dikerjakan oleh developer sesuai dengan yang diinginkan atau tidak. Dengan itu, developer juga mendapat wawasan yang lebih terkait yang dikembangkannya. Beda dengan process model pengembangan dimana client hanya memberi wawasan di awal saja.
4. Responding to change over following a plan, yaitu mengutamakan pemberian tanggapan terhadap suatu perubahan. Ketika kondisi eksternal atau keperluan dari client berubah, pengembangan sebaiknya dapat menyesuaikan pengembangan dengan perubahan tersebut. Jika hanya fokus ke rencana awal, terdapat kemungkinan sistem yang dibuat tidak up-to-date.

Untuk menerapkan agile manifesto, process model ini menggabungkan process model inkremental dan iteratif dimana pada tiap akhir iterasi pengembangan dihasilkannya suatu produk yang bekerja. Dengan cara ini, produk yang bekerja dapat lebih sering dihasilkan dan client juga dapat lebih sering memberikan tanggapan atau masukan. Semua ini dapat memastikan bahwa perangkat lunak yang dikembangkan sesuai dengan ekspektasi dan kebutuhan.

Dari keempat nilai agile manifesto, dibuatlah 12 prinsip utama agile development.

1. Memprioritaskan kepuasan client dengan memberikan hasil pengembangan yang baik secara berkelanjutan
2. Menerima perubahan terhadap requirements untuk kepentingan client walaupun dalam pertengahan atau tahap akhir pengembangan
3. Sering menghasilkan produk yang bekerja dengan jangka waktu yang ditetapkan bersama. Lebih sering lebih diutamakan
4. Business people dan developer harus bekerja sama dari awal sampai akhir pengembangan
5. Pengembangan proyek dilakukan dengan orang-orang yang bersemangat. Memberikan mereka lingkungan pekerjaan yang diperlukan, dukungan, dan kepercayaan bahwa mereka akan menyelesaikan pekerjaan yang ditugaskan kepada mereka
6. Penyampaian informasi sebaiknya dilakukan dengan percakapan langsung
7. Ukuran utama progres adalah hasil yang bekerja
8. Orang-orang yang terlibat pada pengembangan harus dapat mempertahankan kinerjanya sampai batas waktu yang tidak pasti
9. Diperhatikannya keunggulan secara teknis dan desain
10. Mengutamakan suatu satu tugas daripada langsung mengerjakan semua tugas sehingga hasil lebih berkualitas
11. Pembuatan arsitektur, requirements, dan desain yang baik
12. Tim pengembangan melakukan refleksi terhadap proses dan kinerja pengembangan secara berkala

Stacey Matrix

Stacey matrix merupakan matriks yang dibuat oleh Ralph Douglas Stacey untuk membantu dalam memilih tindakan lebih lanjut berdasarkan kompleksitas kondisi saat itu. Matriks tersebut memiliki 2 variabel, yaitu agreement dan certainty.

sumber gambar

Suatu proyek dekat ke certainty ketika dapat diketahui efek hasil proyek dan terdapat proyek-proyek serupa yang telah dikerjakan. Biasanya proyek yang jauh dari certainty merupakan proyek yang mengakar dari ide baru dan inovatif sehingga tidak ada data yang dapat digunakan untuk mengetahui pasti efek hasil proyek tersebut dan tidak adanya proyek-proyek sebelumnya yang dapat dijadikan referensi dalam pengembangan.

Selanjutnya, suatu proyek dekat ke agreement ketika client utama proyek memiliki pemikiran dan keputusan yang selaras dengan tim pengembangan sehingga proyek dapat berjalan dengan konflik yang minim. Biasanya proyek jauh dari agreement ketika terdapat konflik terhadap pemikiran dan keputusan antara client utama proyek dan tim pengembang.

Dalam matriks ini, terdapat beberapa zona yang terdefinisi:

1. Simple Zone: Dekat dengan agreement, dekat dengan certainty. Karena kondisi yang ideal, dapat menggunakan process model waterfall.
2. Political Zone: Agak jauh dari agreement, dekat ke certainty. Dapat melakukan negosiasi dan meluangkan waktu berdialog untuk menyelaraskan pemikiran antar client dan tim developer. Dapat menggunakan process model agile. Jika tidak terlalu jauh dari agreement, process model waterfall dapat digunakan
3. Complicated Zone: Dekat dengan agreement, agak jauh dari certainty. Dapat konsultasi dengan spesialis atau orang-orang yang memiliki pengalaman berkaitan dengan proyek untuk meningkatkan certainty. Dapat menggunakan process model agile. Jika tidak terlalu jauh dari certainty, process model waterfall dapat digunakan
4. Complex Zone: Agak jauh dari agreement, agak jauh dari certainty. Perlu mengimplementasikan best practice dalam praktiknya dan bereksperimentasi dalam mencari titik tengah. Process model agile direkomendasikan pada situasi ini
5. Chaotic Zone: Jauh dari agreement, jauh dari certainty. Harus dapat menilai situasi dari informasi yang dapat digali dan mengurus masalah yang paling besar dalam keberlanjutan proyek terlebih dahulu sehingga dapat keluar dari zona ini

Implementasi Agile pada Scrum

Scrum merupakan salah satu metodologi pengembangan perangkat lunak yang mengimplementasikan agile process model. Scrum juga dapat dikatakan sebagai suatu kerangka sekumpulan komponen seperti beberapa peran, aktivitas, dan artifact dalam mengelola pengembangan suatu perangkat lunak. Pengimplementasian prinsip-prinsip agile dibantu oleh komponen-komponen yang telah didefinisikan.

Komponen Artifact

Komponen artifact merupakan komponen yang harus dihasilkan untuk membantu jalannya kegiatan pada proyek scrum. Terdapat tiga artifact utama dalam scrum, yaitu:

1. Product Backlog
2. Sprint Backlog
3. Increment

Product backlog merupakan daftar utama pekerjaan yang harus diselesaikan. Isi dari product backlog dapat berubah tergantung dengan kondisi dan requirements. Walaupun dapat diperbarui, sebaiknya product backlog tidak diubah sebelum iterasi pengembangan saat itu berakhir agar tidak mengganggu alur kerja yang telah ditetapkan.

Sprint backlog merupakan daftar pekerjaan yang ingin diselesaikan pada sprint cycle saat itu. Sifatnya fleksibel, dapat berubah di tengah sprint. Pekerjaan yang diambil merupakan pekerjaan yang ada di dalam product backlog.

Increment merupakan produk hasil suatu sprint cycle. Produk yang dimaksud merupakan perangkat lunak yang bekerja sesuai dengan harapan sprint tersebut. Pada akhir tiap sprint, increment yang dihasilkan akan didemonstrasikan ke client untuk diberikan feedback.

Komponen Peran

Komponen peran merupakan komponen scrum team yang memastikan scrum berjalan dengan semestinya. Terdapat tiga peran utama dalam scrum, yaitu:

1. Product Owner
2. Scrum Master
3. Development Team

Product owner merupakan pihak yang bertugas sebagai jembatan antara development team dengan client. Ia bertugas untuk memahami requirements yang ada dan merancang product backlog dari requirements tersebut. Ia harus memastikan bahwa produk yang dikembangkan oleh development team sesuai dengan harapan client dan memastikan bahwa yang diharapkan client tidak terlalu berat untuk development team. Product owner juga berhak untuk menolak suatu increment.

Scrum master merupakan pihak yang bertugas untuk memastikan bahwa kegiatan-kegiatan pada scrum berjalan dengan lancar. Ia membantu product owner mengelola product backlog dan merencanakan pekerjaan development team. Ia mengecek kondisi development team secara rutin pada saat kegiatan scrum.

Development Team merupakan anggota-anggota kelompok yang bertugas untuk menyelesaikan tugas-tugas yang ada di dalam product backlog. Mereka akan mendemonstrasikan produk yang dihasilkan tiap iterasi pengembangan.

Komponen Aktivitas

Dalam implementasinya, scrum memiliki beberapa aktivitas, yaitu:

1. Perancangan backlog: aktivitas memproses requirements untuk mendefinisikan pekerjaan yang perlu dimasukkan ke product backlog
2. Sprint planning: aktivitas untuk menentukan pekerjaan apa saja yang ada pada product backlog yang akan dikerjakan pada sprint saat itu. Pekerjaan yang dipilih akan dimasukkan ke dalam sprint backlog. Biasanya dilakukan sehari sebelum pelaksanaan sprint. Setiap anggota kelompok mengambil item pada backlog untuk dia kerjakan. Nanti jika sudah selesai dengan pekerjaannya, ia dapat mengambil item lain pada backlog untuk dikerjakan pada sisa waktu sprint tersebut.
3. Sprint: fase atau suatu periode waktu yang disediakan untuk menyelesaikan sebagian pekerjaan pada product backlog. Pekerjaan yang dimaksud adalah pekerjaan yang ada pada sprint backlog saat itu. Hasil pekerjaan sprint tersebut adalah increment. Pada mata kuliah PPL 2022/2023 semester genap, kami melakukan tiga kali sprint.
4. Daily scrum/stand up: rapat harian yang diinisiasi oleh scrum master untuk membahas progres pekerjaan tiap orang, mengecek rencana pengerjaan tiap anggota, mengecek apakah ada masalah, memastikan bahwa tidak ada kesalahpahaman terhadap pengerjaan suatu tugas, dan memastikan bahwa apa yang dikerjakan tidak melenceng dari requirements. Dianjurkan daily scrum hanya memakan waktu yang singkat seperti 15 menit.
5. Sprint review: aktivitas di akhir suatu sprint dimana development team mendemontrasikan increment yang telah dibuat pada sprint itu untuk mendapat masukan dari client. Pada tahap ini, product owner berhak menolak increment yang didemonstrasikan.
6. Sprint retrospective: rapat pada akhir sprint dimana scrum team membahas apapun tentang sprint yang baru berakhir. Anggota dapat ‘curhat’ dan membahas apa saja yang harus dibuang, dipertahankan, dan ditambahkan untuk sprint berikutnya.

Scrum Values

Dalam pelaksanaan scrum, anggota-anggota scrum team harus memiliki nilai-nilai sebagai berikut:

1. Komitmen: tiap anggotanya saling berkontribusi dalam pengembangan produk.
2. Keberanian: tiap anggota berani untuk mencoba hal-hal baru, membahas progres dan membahas hambatan, dan berani meminta bantuan.
3. Fokus: tiap anggota harus fokus terhadap pekerjaannya agar increment dapat selesai tepat waktu.
4. Keterbukaan: tiap anggota harus terbuka untuk berdiskusi tentang pekerjaan dan kelompok agar jika ada masalah dapat mencoba mencari solusi bersama.
5. Saling Menghargai: dalam kolaborasi, tiap anggota harus dapat menghargai satu sama lain untuk meminimalisir rasa tidak suka pada kelompok yang dapat menghambat komunikasi dan kelancaran kerja.

Kekurangan dari Scrum

1. Sulitnya mencari waktu untuk rapat full team karena agenda yang berbeda antar anggota
2. Kurangnya dokumentasi karena scrum lebih fokus kepada pembuatan working product
3. Masukan dari client harus tidak ambigu karena product backlog didefinisikan dari masukan tersebut
4. Sulit untuk mengestimasi berapa usaha yang harus dikerahkan untuk proyek besar pada tahap awal

Progress Implementasi Scrum Kelompok PPL

Product backlog kami dalam bentuk spreadsheet PBI. Sudah beberapa kali kami perbarui karena informasi baru dari client dan penyelesaian beberapa kesalahpahaman dengan beliau. Karena kami belum mendapatkan beberapa komponen teknis, beberapa item pada product backlog belum mendetil.

Sprint planning untuk sprint pertama telah dilaksanakan. Dalam penentuan item yang akan dimasukkan ke dalam sprint backlog, kami mempertimbangkan fitur yang ingin difokuskan oleh client, tingkat kesulitan tiap pekerjaan, pemahaman kami terhadap kode dalam repository yang didapat, dan komponen teknis yang diperlukan. Sprint backlog dibuat menggunakan aplikasi trello. Setelah mendefinisikan pekerjaan-pekerjaan pada sprint pertama, tiap anggota mengambil satu pekerjaan dan memindahkan item yang bersangkutan ke daftar ‘in progress’.

Kekurangan Implementasi Scrum PPLunny

Setelah menyelesaikan sprint review ketiga pada proyek ini, ditemukan beberapa hal yang tidak efektif.

1. Estimasi story point untuk tiap backlog yang tidak akurat. Hal ini karena kurangnya pengetahuan teknis terhadap hal yang terkait dengan backlog. Karena itu, backlog yang sebenarnya susah dapat dikategorikan sebagai backlog yang mudah dan sebaliknya. Backlog juga dapat dikategorikan ke dalam isu yang salah. Misalnya masalah struktur data dikategorikan menjadi masalah pengolahan data. Masalah teknis dikategorikan sebagai masalah logika. Pada sprint kedua, kami salah mengategorikan suatu task yang sebenarnya masalah backend sebagai masalah frontend. Hal ini dapat mengakibatkan tidak cocoknya backlog dan developer yang mengambilnya. Misalnya developer yang lebih handal mengerjakan masalah frontend mengambil masalah backend.
2. Daily scrum yang seharusnya dapat menjadi sarana untuk membahas masalah yang ditemukan saat pengembangan sering hanya mengecek status progress tiap developer. Status yang dimaksud adalah apakah task yang diambil tengah sedang pada tahapan “in progress”, “testing”, “review”, atau “done”. Tidak digali lebih lanjut mengapa task berada pada tahap tersebut dan apakah sudah layak berada di tahap tersebut. Terdapat kasus dimana anggota kelompok menyatakan bahwa pekerjaannya sudah selesai dan telah di-merge ke staging namun saat demonstrasi ke client ternyata masih ada bug dan unit test-nya tidak lengkap. Terdapat kasus dimana semalam sebelum sesi UAT, anggota kelompok baru mengabarkan bahwa masih terdapat bug pada bagiannya padalah saat daily scrum ia tidak melaporkan hal tersebut. Dari kasus-kasus yang ditemukan, dapat disimpulkan bahwa daily scrum dapat berjalan dengan seharusnya hanya jika semua anggota berani menyatakan kesulitannya dan aktif berkomunikasi.

Metodologi Agile Selain Scrum

Kanban merupakan metodologi dimana suatu papan digunakan untuk menunjukkan progres dan proses dari pengembangan. Setiap tahap proses dibagi per kolom. Jika suatu task ada pada proses tersebut, maka kartu yang merepresentasikan task tersebut diletakkan pada kolom yang terkait. Seiring dengan perubahan informasi dan proses, papan tersebut juga dapat berubah. Kanban juga membatasi jumlah task yang berada pada suatu tahap proses, misalnya hanya boleh ada 6 task pada tahap ‘in progress’.

Extreme Programming (XP) merupakan metodologi yang mirip dengan scrum, bersifat iteratif. Bedanya adalah, scrum tidak menegaskan praktik programming yang harus dipakai oleh tim developer. Pada XP, diterapkan pair-programming dimana 2 programmer bekerja sama dalam menyelesaikan satu task dan harus mengimplementasikan test driven development (TDD).

Kesimpulan

Scrum merupakan salah satu solusi untuk membuat proses pengembangan perangkat lunak lebih fleksibel. Namun, peluang keberhasilannya sangat bergantung terhadap komunikasi rutin. Harus diperhatikan apakah scrum cocok untuk proyek yang ingin dikembangkan.

Sumber Referensi

Principles behind the Agile Manifesto

Stacey matrix

Agile vs. Scrum: What's the Difference?

Software Engineering | Agile Software Development - GeeksforGeeks

Scrum - what it is, how it works, and why it's awesome

Agile Scrum Roles | Atlassian

The Difference between Extreme Programming vs. Scrum

Kanban vs. Scrum boards: 11 major differences