Apa itu Agile Manifesto?


Sering kali terdengar pengembangan software secara agile disebut dimana-mana. Sebenarnya apa itu agile software development? Apa setiap kali membuat program dengan cepat sudah termasuk memakai teknik agile ini? Pada tanggal 17 Februari 2001, tujuh belas developer (termasuk diantaranya adalah Ken Beck dan Martin Fowler) berjumpa untuk mendiskusikan teknik pengembangan software yang ringan dan lincah. Mereka kemudian menghasilkan apa yang disebut sebagai The Agile Manifesto yang terdiri atas 4 nilai dan 12 prinsip. Isinya dapat dilihat di http://agilemanifesto.org. Bahkan, saya juga dapat melihat hasil terjemahan dalam Bahasa Indonesia yang dapat dilihat di http://agilemanifesto.org/iso/id/ yang isinya adalah:

Manifesto Pengembangan Perangkat Lunak Agile

Kami menemukan cara yang lebih baik untuk mengembangkan
perangkat lunak dengan melakukan dan membantu sesama untuk menggunakannya.
Melalui usaha ini kami telah dapat menghargai:

Individu dan interaksi lebih dari proses dan sarana perangkat lunak
Perangkat lunak yang bekerja lebih dari dokumentasi yang menyeluruh
Kolaborasi dengan klien lebih dari negosiasi kontrak
Tanggap terhadap perubahan lebih dari mengikuti rencana

Demikian, walaupun kami menghargai hal di sisi kanan, kami lebih menghargai hal di sisi kiri.

Beberapa permasalahan yang berkaitan dengan individu dan interaksi dapat terpantau dari contoh perkataan seperti berikut ini:

  1. “Loh, modul gw ‘kan pake modulnya si B! Gw hanya tinggal pakai, titik! Yang elo bilang error sebenarnya tuh dibuat sama B!” (melempar tanggung jawab dan saling menyalahkan).
  2. “Apa sih yang gw dapat selama kerja disini? Tiap hari cuman copy-paste. Emanknya ga ada kerjaan lain ya?” (tidak termotivatasi)
  3. “Hah, udah berubah? Sejak kapan?? Percuma gw mati-matian bikinnya!!” (kurangnya kolaborasi)

Salah satu ciri tim yang agile adalah tim yang kompak dan masing-masing anggotanya dapat bekerja sendiri tanpa harus diperintah. Pada Dreyfus model, terdapat 5 jenis peran seseorang, yaitu novice (butuh panduan dan bimbingan), advanced beginner (masih berfokus pada proses), competent (dapat melakukan perencanaan), proficient (dapat melihat situasi secara keseluruhan), dan expert (dapat menemukan jalan dalam situasi baru). Sebuah tim yang sukses harus memiliki sejumlah anggota yang mencapai peran competent atau proficient. Ini adalah syarat agar salah satu prinsip Agile Manifesto dapat diterapkan:

Kembangkan proyek di sekitar individual yang termotivasi.
Berikan mereka lingkungan dan dukungan
yang mereka butuhkan, dan percayai mereka
untuk menyelesaikan pekerjaan dengan baik.

Prinsip di atas juga berarti tidak ada pemaksaan tool yang dipakai oleh developer. Sebagai contoh, developer boleh memakai IDE dan sistem operasi favorit mereka. Dengan memberikan kebebasan bagi developer, mereka diharapkan memiliki produktifitas semaksimal mungkin.

Berdasarkan prinsip agile, setiap developer tidak boleh masa bodoh terhadap pekerjaan developer lain. Mereka harus memahami hasil pekerjaan rekannya sehingga tidak saling melempar tanggung jawab. Hal ini akan membuat mereka lebih percaya diri dan menghasilkan kode program yang lebih berkualitas. Untuk mencapai kondisi ini, praktisi agile sering menerapkan apa yang disebut sebagai pair programming dimana dua developer bekerja di depan satu komputer. saat seorang developer bekerja, developer yang satunya lagi mengamati. Tujuannya adalah agar pengetahuan dapat tersebar secara merata ke seluruh developer. Tidak ada lagi ‘anak emas’ yang menjadi pusat konsentrasi pekerjaan. Tapi pada prakteknya, entah mengapa, saya sering merasa selalu ada pihak-pihak yang ingin menutup akses pengetahuan😉

Dokumentasi seperti diagram BPMN dan UML memang penting, tapi sebaiknya bukan merupakan media utama dalam berkomunikasi dengan klien. Gunakan perangkat lunak yang bekerja sebagai media komunikasi. Salah satu cara yang dapat ditempuh adalah dengan menggunakan metode iteration. Sebagai contoh, saya memiliki kebiasaan untuk memakai versi prototype yang diawali 0 seperti 0.1, 0.2, 0.3, dan seterusnya. Selama pengembangan, fokus saya adalah menghasilkan perangkat lunak yang bekerja secepat mungkin (walaupun belum mencakup seluruh kebutuhan), kemudian meminta feedback (masukan) dari klien. Saya mencatat keluhan dari klien seperti fitur yang kurang atau tampilan yang terlalu sulit dipakai. Kemudian tim developer akan memperbaharui software, merilis versi berikutnya, dan saya kembali menunjukkan software pada klien. Proses ini dilakukan terus menerus hingga klien merasa puas (atau mungkin bosan😉 ).

Tidak semua klien memahami metodeiterasi. Beberapa klien menganggap bahwa software adalah sebuah benda mati yang diam dan tinggal di-copy sehingga mereka hanya ingin terima ‘jadi’. Padahal kolaborasi dengan klien adalah hal yang penting. Untuk membuat klien awam bersedia bekerja sama, saya sering memakai analogi seperti: “Microsoft terus berinovasi menciptakan Windows 95, Windows 98, Windows 2000, Windows XP, Windows 7 hingga Windows 8 mengikuti kebutuhan pelanggannya. Bayangkan bila Microsoft hanya merilis Windows 95 saja, apakah dia bisa memenuhi kebutuhan pelanggannya sekarang? Demikian juga dengan kami, produk XXX 0.1 akan terus berinovasi menjadi 0.2, 0.3 dan seterusnya untuk menyesuaikan dengan kebutuhan bisnis Anda.” Terkadang saya akan memakai contoh perusahan dan produk lain yang dikenal oleh orang awam, misalnya Google dan Android. Tujuannya adalah untuk menunjukkan bahwa software adalah sesuatu yang dinamis dan bersifat iteratif, dimana pemicu setiap iterasi adalah feedback dari klien.

Iterasi yang dilengkapi kolaborasi dengan klien adalah sesuatu yang sangat efektif bila mendapat dukungan penuh dari semua pihak. Setiap iterasi menghasilkan software yang dapat ditunjukkan pada klien. Pada tahap ini, walaupun software belum dipakai di production, masing-masing pihak sudah memiliki gambar seperti apa hasil akhirnya nanti. Kenapa harus repot seperti ini? Mengapa tidak langsung membuat software yang dapat langsung dipakai di production? Berdasarkan pengalaman, software ‘pertama kali’ yang dipresentasikan kepada klien tidak selalu sesuai kebutuhan. Klien selalu meminta perubahan. Jadi mengapa harus menghabiskan waktu lama untuk menghasilkan software ‘pertama’ kali’ ini?

Sebagai contoh, saya pernah bekerja di industri software yang memakai metode konvensional. Proyek diawali dengan pertemuan antara tim analyst dan klien selama beberapa minggu. Setelah analyst kembali ke kantor, mereka mulai membuat diagram dan membagi tugas ke developer. Saat ini para developer tentu saja belum memahami apa yang mereka kerjakan; oleh sebab itu, mereka akan sering bertanya ke analyst. Terkadang analyst juga belum memahami permasalahan secara sepenuhnya, sehingga mereka berusaha menjawab ‘ala kadar’-nya, terkadang memakai insting atau memberi jawaban diplomatis seperti “kerjakan saja sebisa elo!”😉. Resiko kesalahpahaman dalam tim sangat tinggi! Hari demi hari berlalu, bulan terus berganti, dan tahun baru pun tiba. Developer sudah bekerja keras menciptakan apa yang diimpikan analyst. Hari dimana system integration testing (SIT) pun tiba. Semua anggota tim merasa bangga! Namun, saat user acceptance test (UAT) dilakukan, alangkah terkejutnya klien melihat dirinya mendapatkan sebuah software yang sangat berbeda dari yang dibutuhkannya padahal sudah menanti selama setahun!

Contoh di atas adalah contoh klasik kegagalan yang terjadi akibat lebih mementingkan negosiasi kontrak dan mengikuti rencana. Pengembangan perangkat lunak agile menyarankan untuk lebih mementingkan kolaborasi dengan klien lebih dari negosiasi kontrak. Selain itu, contoh di atas lebih mementingkan proses (misalnya, tahapan pengembangan dari analyst ke developer) dan juga adanya gap ‘pengetahuan’ yang mencolok antara analyst dan developer (karena developer tidak ikut serta dalam kolaborasi dengan klien).

Pengembangan secara iteratif menyebabkan proses pengembangan software harus tanggap terhadap perubahan. Penjadwalan tidak butuh gantt chart dimana ada milestone yang tersusun secara rapi dan harus dipatuhi. Satu-satunya jadwal (selain estimasi selesai) adalah target jangka pendek untuk merilis iterasi terbaru. Setiap rilis mungkin saja melibatkan perubahan signifikan pada codebase sehingga developer juga harus siap terhadap perubahan (misalnya dengan selalu membuat unit test dan melakukan refactoring secara teratur).

Agile manifesto mendeskripsikan roh dari metode pengembangan software agile, tapi ia tidak memberikan panduan atau kerangka kerja. Untuk kerangka kerja, saya dapat melihat beberapa ‘implementasi’-nya seperti Scrum, Extreme Programming (XP), Adaptive Software Development (ASD), Crystal, Agile Unified Process (AUP), dan sebagainya. Perlu diingat bahwa sama seperti metode pengembangan lainnya, metode agile yang disebutkan bukanlah sebuah solusi yang dapat memecahkan semua masalah dalam segala situasi. Tidak ada salahnya menyesuaikan metode agile dengan kebutuhan dan situasi, sambil terus mempertahankan nilai dan prinsip dalam agile manifestor.

Perihal Solid Snake
I'm nothing...

One Response to Apa itu Agile Manifesto?

  1. Ping-balik: Memakai PHPUnit Di Zend Studio | The Solid Snake

Apa komentar Anda?

Please log in using one of these methods to post your comment:

Logo WordPress.com

You are commenting using your WordPress.com account. Logout / Ubah )

Gambar Twitter

You are commenting using your Twitter account. Logout / Ubah )

Foto Facebook

You are commenting using your Facebook account. Logout / Ubah )

Foto Google+

You are commenting using your Google+ account. Logout / Ubah )

Connecting to %s

%d blogger menyukai ini: