Intro
Dalam membangun sebuah perangkat lunak, tim IT memiliki beberapa metode untuk mewujudkannya. Metode pembangunan perangkat lunak atau yg lebih populer dengan nama SDLC (software development life cycle) menjadi sebuah pedoman dalam pengerjaan project. Namun pengaplikasian metode-metode tersebut sangat fleksibel sesuai dengan kebutuhan dan karakteristik masing-masing perusahaan. Sebut saja metode waterfall sebagai metode yang (menurut penulis) hanya bisa diterapkan pada kondisi ideal, dimana semua requirement dari user sudah tergali lengkap, sehingga tim analis sukses dengan dokumen rancangannya, dan para kuli coding merealisasikannya dalam bentuk software.
Oke, cukup dengan penulisan bahasa formal, sekarang pake bahasanya penulis 
Metode waterfall cuma bisa jalan pada kondisi ideal dimana user bisa njelasin keinginannya, atau paling nggak si tim analis bisa nangkap apa yang dia mau. Nah bisa jadi karena beda lingkungan, beda ilmu dsb akhirnya si analis salah nangkap maksudnya, atau bisa aja bahkan si user g tau apa yg dia inginkan sehingga si analis harus bolak-balik ketemu dsb. Dengan kondisi yg demikian, muncullah metode iterative dimana si software bisa dibangun terlebih dahulu, kemudian di evaluasi bersama-sama dengan user, lalu diperbaiki, dievaluasi lagi, diperbaiki lagi, sampai pada looping yang kesekian dan si software dianggap selesai. Disini tim IT harus membuat perjanjian sama user, dia mau berapa kali looping, atau membuat kesepakatan tertulis tentang waktu pengerjaan atau scope yg mau dibikin. Kalo nggak gitu bisa jadi tim IT kelabakan, karena seperti kata salah seorang pakar ekonomi bahwa keinginan manusia itu tidak terbatas, nah lho.. mau looping berapa kali sampe si user puas.
Semakin lama waktu pengerjaan maka semakin banyak biaya yang dikeluarkan, dan bila tidak ada limitasi bisa jadi semakin mendekati ambang kehancuran bagi kedua belah pihak. Tim IT capek, usernya juga capek. Bila software yang mau dibikin cukup besar, maka lama waktu pengerjaannya juga akan lama. Akan jadi malapetaka kalo seandainya software yg sudah dikerjakan jauh2 hari itu tiba2 nggak sesuai dengan kondisi real karena kebijakan atau bisnis proses sudah berubah disaat yang sama ketika software itu dibangun. Kalo nggak bisa dibilang sia2 mungkin bisa pake kata2 muspro hehehe.
Nah.. untuk menghindari ke-muspro-an itu, ada sebuah metode (yang baru saja didengar penulis beberapa minggu yg lalu) dengan nama Agile Methodology.
Apa sih Agile ini ?
Ada temen yg nyebutnya sebagai aji gile.. kayaknya emang bakalan aji gile ritme kerjanya metodologi ini. Aku lebih suka menulisnya (Fr)agile, agile buat tim ITnya, fragile buat tim devnya (semoga nggak beneran gitu deh).
Sesuai dengan artinya dalam bahasa Indonesia, metode ini dipakai untuk menghadapi ketidakpastian yang dihadapi dalam membangun perangkat lunak melalui proses incremental dan model irama kerja yang berulang (iterative). So.. hampir mirip dengan iterative, namun tiap kali proses looping nya, maka ada fungsionalitas dari software yang bertambah. Secara gampangnya dibuat secara modular.
Misalnya pemilik resto mau bikin software untuk rumah makannya yang sudah memiliki banyak cabang di berbagai daerah. Software yang diminta berupa pembelian, penjualan, penyimpanan bahan makanan di gudang, inventaris asset restoran, dan penggajian karyawan. Dengan banyaknya permintaan dari si pemilik restoran, maka tim IT bisa membagi-bagi pengerjaannya dalam beberapa modul. Berbeda dengan rapid yang membagi pengerjaan modul2 tersebut kedalam beberapa tim yang berbeda, Agile lebih menekankan pada fokus penyelesaian satu modul seefisien mungkin. Modul yang sudah fix akan diluncurkan setiap periode yang sudah ditentukan sebelumnya (misalnya 2 minggu sekali). Walaupun software utuhnya belum didapatkan, tapi pemilik resto sudah bisa menggunakan fitur-fitur tertentu untuk mendukung proses bisnisnya. Misalnya modul penggajian paling dahulu dikerjakan. Dengan pengerjaan yang relatif singkat pada tiap modulnya, tim IT diharapkan dapat responsif terhadap keinginan user (termasuk membedakan keinginan demi kebaikan proses bisnis dan hanya keinginan kurang penting). Tim developer diharapkan mampu bekerja cepat sehingga modul yang dihasilkan tepat sama dengan kebijakan dan bisnis proses yang ada saat ini. Jadi si agile ini akan mendevelop dan merilis produk tepat sama dengan apa yg dibutuhkan oleh user alias konsumen.
Berikut manfaat yang ditawarkan Agile berdasarkan situs wedigtech.com :
1. Memberikan nilai-nilai bisnis tertinggi pada awal proyek
2. Meningkatkan kepuasan pelanggan
3. Menyediakan pendekatan berbasis pelanggan
4. Fokus pada kecepatan pengiriman
5. Menyediakan keterbukaan dan visibilitas kepada pelanggan
6. Menghapus hambatan dalam cara yang diprioritaskan dan sistematis
7. Meningkatkan retensi karyawan dengan memberdayakan karyawan dan dengan mempromosikan pengelolaan diri, komunikasi tim, belajar, dan nilai-bangunan
Source : www.wedigtech.com, www.agilemethodology.com
