Agile: Apakah cocok untuk PPL?
Agile atau lebih lengkapnya Agile software development merupakan pendekatan dalam pengembangan perangkat lunak yang memiliki beberapa ciri. Secara umum, Agile mendorong pengembang untuk lebih adaptif dan menghasilkan produk secara bertahap.
Konsep Agile dipopulerkan melalui Manifesto for Agile Software Development yang berisi ajakan kepada sesama pengembang untuk menggunakan nilai-nilai agile dalam pengembangan perangkat lunak.
Manifesto Pengembangan Perangkat Lunak Agile
Kami menemukan cara yang lebih baik untuk mengembangkan
perangkat lunak dengan menggunakannya dan membantu sesama untuk menggunakannya.
Melalui usaha ini kami menghargai:Individu dan interaksi daripada proses dan alat
Perangkat lunak yang bekerja daripada dokumentasi yang menyeluruh
Kolaborasi dengan klien daripada negosiasi kontrak
Tanggap terhadap perubahan daripada mengikuti rencanaDemikian, walaupun kami menghargai hal di sisi kanan, kami lebih menghargai hal di sisi kiri.
Sumber: Manifesto Pengembangan Perangkat Lunak Agile dengan beberapa modifikasi alih bahasa.
Sebelum menjelaskan hubungan agile dengan mata kuliah PPL, ada baiknya mari kita memahami apa itu Agile dan Scrum.
Agile vs. yang lain
Agile memiliki beberapa nilai yang membuatnya berbeda dari pendekatan perangkat lunak yang lain.
Pengembangan iteratif dan berkelanjutan
Dalam pengembangan perangkat lunak, terdapat proses analisis, desain, coding, dan testing. Pada pendekatan tradisional, proses ini dilakukan sekali selama masa pengembangan. Pada Agile, proses ini dilakukan berulang-ulang selama masa pengembangan. Setiap iterasinya akan menghasilkan produk yang berfungsi dan fungsionalitasnya akan bertambah seiring banyaknya iterasi.
Perencanaan yang adaptif
Perencanaan dalam pengembangan perangkat lunak memang perlu. Namun, pada Agile, perencanaan lebih adaptif terhadap perubahan. Hal ini diperlukan karena Agile lebih berorientasi pada pengguna. Jika pengguna memang membutuhkan perubahan, maka requirement awal bisa saja diubah di tengah masa pengembangan. Selain itu, keterbatasan cakupan juga dapat menyebabkan perubahan. Misalnya produk yang kita dibuat perlu selesai sebelum waktu yang ditentukan agar tidak kalah bersaing dengan kompetitor, maka ada hal lain yang dapat dikompromi, misalnya biaya yang perlu ditambah, kualitas yang perlu diturunkan atau fungsionalitas yang perlu dikurangi.
Perencanaan yang adaptif dipercaya dapat menekan biaya dan meningkatkan produktifitas.
Kolaborasi lintas peran
Dalam proyek Agile, batas peran seseorang semakin kabur. Masing-masing anggota tim memang tetap memiliki keahlian masing-masing dan melakukan pekerjaannya masing-masing. Hanya saja, setiap anggota tim dapat melakukan apapun untuk membuat proyek yang dibuatnya berhasil. Dengan demikian, pengambilan keputusan tidak hanya dilakukan oleh pemimpin. Tim lintas peran seperti ini dipercaya dapat meningkatkan kreatifitas tim dalam menyelesaikan masalah.
Mengedepankan produk yang berfungsi
Sesuai dengan namanya, Agile mengedepankan kecepatan dalam menghasilkan produk yang bekerja. Oleh karena itu, Agile “mengorbankan” artefak seperti dokumentasi, rencana proyek, test, dan analisis karena Agile menganggap hal tersebut tidak memiliki nilai di mata pengguna. Dengan demikian, Agile dapat mengantarkan produk lebih cepat kepada pengguna. Artefak tersebut tetap penting dibuat untuk kemudahan tim pengembang sendiri, hanya saja tidak diutamakan dalam pengembangan dengan Agile.
Agile dan Scrum
Agile adalah kumpulan nilai. Sedangkan Scrum adalah salah satu bentuk implementasinya. Scrum merupakan kerangka kerja dalam pengembangan perangkat lunak yang menggunakan konsep Agile. Scrum memiliki Roles, Artifacts, dan Time Boxes yang membedakan framework ini dengan framework agile lainnya.
Artifacts
Requirement dalam Scrum disebut Product Backlog Item (PBI). Sebelum menentukan PBI, product owner perlu membuat User Story —functional requirement berbentuk narasi yang berisi fitur yang diperlukan oleh pengguna. User story biasanya berbentuk “Sebagai <tipe pengguna>, saya ingin <tujuan>, sehingga <alasan>”.
Selain user story, ada juga non-functional requirements yang disebut Technical Story. Selain itu ada Defect atau bug report yang merupakan deskripsi dari kegagalan produk untuk berjalan sesuai yang diharapkan.
Nantinya, story akan diolah menjadi PBI kemudian dijabarkan menjadi task yang akan dikerjakan oleh Development Team.
Roles
Ada beberapa peran dalam Scrum. Pertama adalah Scrum Master. Scrum Master bertanggung jawab untuk membuat proses dalam scrum berjalan lancar. Tugasnya termasuk membantu Product Owner mencapai tujuannya dan meningkatkan produktifitas Development Team.
Product Owner (PO) adalah orang yang menyediakan requirement produk dan rencana implementasi. PO merupakan penghubung antara orang bisnis dan tim pengembang.
Development Team (Tim Pengembang) adalah sebuah tim yang self-organizing dan cross-functional yang melakukan implementasi dan test terhadap produk. Tim pengembang juga berhak bagaimana cara mengerjakan dan membagi tugas yang ada selama sprint. Tim pengembang biasanya berisi lima sampai sembilan orang.
Time Boxes
Masa pengembangan dibagi dalam rentang waktu yang disebut Sprint. Sebuah sprint biasanya berjalan dua sampai empat pekan sesuai dengan kesepakatan tim di awal.
Sebelum melakukan sprint, PO menetapkan sprint backlog — PBI yang akan dikerjakan pada sprint berikutnya. Kemudian sprint backlog dipecah menjadi beberapa task dan dibagikan kepada tim pengembang. Aktifitas ini disebut Sprint Planning.
Selama sprint berjalan, tim scrum berkumpul setiap hari untuk melakukan Daily Scrum Meeting. Pada aktifitas ini, masing-masing anggota menjelaskan apa yang telah dilakukan, apa yang akan dilakukan dan masalah apa yang perlu dibantu untuk diselesaikan.
Setelah sprint selesai, tim akan melakukan Sprint Review untuk mengulas apa saja yang sudah dilakukan selama sprint. Sprint Review juga digunakan untuk menunjukkan hasil pekerjaan tim kepada stakeholder.
Setelah sprint review, ada Sprint Retrospective Meeting. Aktifitas ini bertujuan untuk mengevaluasi sprint sebelumnya terkait anggota tim, hubungan dalam tim, proses dan alat. Pada aktifitas ini, tim mengidentifikasi dan merencanakan perbaikan yang dapat dilakukan untuk sprint berikutnya. Selelah sprint retrospective selesai, sprint dinyatakan selesai dan tim memulai sprint berikutnya.
Scrum dan PPL
Pada mata kuliah PPL, kami — mahasiswa FASILKOM UI — belajar menggunakan metode scrum dalam pengembangan perangkat lunak. Masing-masing tim terdiri dari 5 orang mahasiswa yang menjadi development team, 2 orang asisten dosen yang menjadi product owner dan scrum master. Tiap tim memiliki klien yang memberikan requirement produknya.
Saat tulisan ini dibuat, tim kami — DUARPPL — telah melakukan satu sprint. Sprint planning dilakukan dengan mengambil beberapa PBI yang telah dibuat oleh PO, membuat task berdasarkan PBI tersebut, kemudian membagikan task tersebut kepada masing-masing anggota tim pengembang sesuai minat dan kemampuannya.
Selama sprint berjalan, kami melakukan daily scrum meeting dua kali seminggu pada hari senin dan rabu. Memang tidak “daily”, sih. Tetapi lumayan untuk saling membagikan progress antar anggota tim. Namun, karena kesibukan kuliah kami, progress yang signifikan biasanya ada saat akhir pekan. Sehingga jadwal scrum meeting pada senin rabu tidak terlalu efektif karena sering kali jawaban masing-masing anggota adalah “belum ngapa-ngapain”.
Di akhir sprint, kami melakukan sprint review. Kami mempresentasikan hasil kerja yang telah kita lakukan di depan dosen, PO dan scrum master kami. Kebetulan klien kami tidak hadir saat itu. Hasilnya tidak terlalu baik. Banyak anggota kami yang task nya tidak selesai semua dan belum di-merge ke staging. Menurut saya, hal ini karena pada sprint pertama ini, kami masih meraba-raba kemampuan kami dalam menyelesaikan task. Belum lagi, kami belum begitu familiar dengan stack yang kami gunakan.
Setelah melakukan review, kami melakukan sprint retrospective. Kami mengevaluasi kinerja dan kesulitan masing-masing anggota. Setelah melakukan retrospective, kami menemukan beberapa faktor buruknya kinerja kami pada sprint ini selain faktor “masih meraba-raba” seperti dugaan saya di atas. Masalah tim kami antara lain kesalahan strategi pembagian task dan “alasan personal” masing-masing anggota. Dengan demikian, kami merencanakan bagaimana agar kesalahan ini tidak terulang kembali. Pada sprint berikutnya, kami membagikan task dengan lebih kohesif. Satu orang mengambil satu PBI sehingga mengurangi depedensi dalam pengerjaan.
Jadi, cocok ngga?
Memang sih, PPL itu adalah sarana belajar pengembangan perangkat lunak dan ada pelajaran agile dan scrum di sana. Namun, implementasi agile masih belum sepenuhnya dijalankan. Salah satu contohnya adalah jangka waktu pengembangan yang tetap. Kami diberikan waktu 5 kali sprint. Mungkin hal ini masih dapat dimaklumi karena sebenarnya pada PPL, requirement-nya cenderung tetap. Untuk tim pengembang, itu memang hal baik, sih. Namun, dalam agile sesungguhnya, requirements kadang kali berubah menyesuaikan dengan keadaan pasar dan kompetitor sehingga scope nya bisa saja berubah. Scope dapat berarti waktu pengembangan yang menjadi lebih panjang, atau mengatur ulang biaya, kualitas dan fungsionalitas.
Kesimpulannya, menurut saya PPL adalah simulasi kecil dalam pengembangan perangkat lunak yang mencoba untuk menerapkan agile dan scrum. Walaupun jika dipikir-pikir tidak setiap proyek memerlukan agile, tetapi simulasi ini lumayan untuk mengenalkan mahasiswa konsep agile dan metode scrum agar tidak kaget saat terjun ke industri.
Sumber:
