Metodologi tangkas dalam pengembangan software

Bahasa kerennya sih Agile Development Methodologies.

Metodologi pengembangan software ini muncul karena adanya beberapa alasan antara lain ;
- susahnya melakukan prediksi apa saja yang bakal terjadi selanjutnya dari proyek pengambangan software karena tuntutan kebutuhan user yang selalu berubah.
- kesulitan untuk dapat melakukan pendefinisian secara utuh kebutuhan2 user dari sebuah proyek
- tuntutan lingkungan bisnis yang sangat dinamis.

Kent Beck telah memberikan beberapa sila dari manifesto pengembangan software menggunakan metodologi ini :
- kemampuan individual dan interaksi lebih diutamakan daripada proses dan tools
- working software lebih diutamakan daripada sekedar dokumentasi. Working software merupakan hasil yang ingin dicapai dari sebuah pengembangan sistem.
- kolaborasi dengan user lebih diutamakan daripada negosiasi dan kontrak.
- memberikan respon di setiap perubahan yang diinginkan user daripada mengikuti rencana pengembangan awal.

Filosofi dari metodologi ini lebih didasarkan pada :
- kepuasan pelanggan adalah yang nomer satu!
- sedapat mungkin melakukan delivery software sedini mungkin, namun bukan prototipe.
- biasanya merupakan tim kecil yang memiliki motivasi yang tinggi.
- meminimalisasi dokumentasi dari pengembangan, namun tidak dihilangkan sama sekali.
- jadikan keseluruhan pengembangan sesederhana mungkin.

Intinya sih, pada metodologi ini, user harus dilibatkan dalam tim pengembangan (kalo bisa) sehingga bisa sedini mungkin jika terdapat perubahan dapat langsung direspon dengan baik. Kadang pula batasan antara customer dan developer dihilangkan. Ini penting, karena agar muncul kerjasama yang baik antara pengembang dan pengguna software itu sendiri.

Namun, karena tujuan awalnya adalah untuk meningkatkan kepuasan pelanggan, tak jarang metodologi ini jadi tak bisa efektif diterapkan. Proyek bakalan tidak bisa selesai2. Lha wong, yang namanya customer khan maunya banyak :D

Agar efektif maka penerapan metodologi ini harus didasarkan pada tiga kunci asumsi yaitu :
a. diterapkan kepada situasi yang sangattttttt susah diprediksi.
b. perancangan dan pengembangan adalah satu kegiatan yang interleaved. (konstruksi digunakan untuk membuktikan desain)
c. analisa, perancangan dan testing tidak bisa diprediksi sesuai dengan rencana yang seharusnya.

Ada sedikit pertanyaan yang menggelitik, karena metodologi ini lebih banyak ditujukan untuk secepat mungkin merespon setiap perubahan, maka tak jarang pekerjaan jadi lebih panjang dari waktu yang diharapkan dan tidak bisa diprediksi kapan selesainya. Bagaimana dengan pola kerjasama dengan user? Jelas tidak bisa menggunakan konsep kontrak proyek selesai putus. Memang ada beberapa hal yang bisa diusulkan, salah satunya adalah metoda outsourcing pengembang software dalam jangka panjang (1 tahun, 2 tahun dst). Hal ini bisa lebih efektif. Namun untuk pekerjaan dalam lingkungan pemerintahan (RI 'kali), hal ini agak sulit dilakukan, mengingat sebelum pekerjaan di tenderkan, tentunya sudah disiapkan TOR atau kerangka acuan kerja yang sejelas mungkin padahal bisa jadi saat pekerjaan dilaksanakan banyak perubahan terjadi disana sini nggak sesuai KAK awal. Apakah kita sebagai pengembang masih bisa menerapkan metodologi ini? Atau kita bersikap kaku aja? Atau, bagaimana dong?

Mengingat betapa dituntut sedemikian responsipnya metodologi ini, maka gak bisa main-main untuk menyusun tim pengembang. Kriteria2 sbb harus ada dalam anggota tim tsb :
- Kompetensi --> spesific software skill
- Fokus pada deliveri
- Bisa berkolaborasi dan komunikasi yang baik dengan user dan bisnis manager.
- Memiliki kemampuan decision making yang baik, terutama untuk teknis dan project issue pada situasi2 yang tidak jelas.
- Memiliki sikap kepercayaan dan respek yang tinggi, dan menyadari bahwa tim memiliki tujuan yang sama.
- Memiliki kemampuan untuk bisa mengatur diri sendiri

Beberapa langkah pengembangan software menggunakan metodologi ini adalah :
–Customer communication --> contoh : user akan bercerita (user stories)
–Planning
–Modeling
–Construction
–Delivery
–Evaluation

Referensi :
- http://en.wikipedia.org/wiki/Agile_software_development
- Roger S. Pressman, Software Engineering: A Practitioner’s Approach, McGrawHill, 2005.

Memahami konsep CMM (bukan : Cwi Mie Malang)

Coba bayangkan dalam sebuah pertandingan bola.

Ketika sebuah bola ditendang oleh seorang pemain, kemudian bola tersebut melayang bebas ke arah sebuah tim apa yang terjadi? Mungkin Anda pernah melihat sebuah pertandingan sepak bola yang ada di kampung dan diadakan dalam rangka ulang tahun kemerdekaan, dimana para pemainnya adalah para amatir yang terdiri dari pemuda-pemuda kampung. Bagaimana cara mereka bertanding? Ya tentu saja ketika ada bola yang harus diperebutkan, mungkin mereka akan serta merta berlarian saling merebutkan bola. Atau mungkin ada pula yang dengan tenang-tenang saja berjalan-jalan tanpa melakukan apa-apa. Ketika bola tersebut ditendang lagi, mungkin mereka juga akan melakukan hal yang berbeda dari sebelumnya. Kadang, bisa jadi seorang kiper bisa merangkap menjadi penyerang :D

Coba bandingkan dengan pertandingan sepak bola dunia, misalnya Piala Dunia dimana pemain-pemainnya adalah pemain profesional. Ketika sebuah bola ditendang, mungkin setiap pemain akan langsung pindah ke posisi yang semestinya. Kadang mungkin mereka gagal bermain dengan baik, tapi selalu saja mereka akan mencoba melakukan sesuatunya dengan benar sesuai dengan porsinya masing-masing.

Tim kesebelasan profesional jelas lebih matang (mature) dibandingkan dengan tim kesebelasan cap kampung tadi. Mereka akan selalu bermain dengan baik, melakukan regenerasi dan selalu mencari cara-cara baru untuk bermain lebih baik lagi.

Sama halnya dengan membangun sebuah perangkat lunak. Sebuah organisasi pengembang profesional yang berkualitas bagus tentu berbeda dengan pengembang perangkat lunak kelas amatir. CMM (capability maturity model) mencoba menangkap perbedaan-perbedaan itu. CMM berusaha keras untuk menciptakan pengembang software yang 'matang' atau lebih matang dibandingkan sebelum menerapkan CMM.

CMM di deskripsikan menjadi 5 level yang bisa dilihat di gambar berikut :

Level 1 : Initial

Perusahaan dengan predikat CMM - Level 1, berkarakter : Pengelolaan yang tidak menentu, tidak dikelola dengan baik, tidak ada dokumentasi, proyek terkadang melebihi deadline dan tidak terencana.

Level 2 : Repeatable

Pada level ini, perusahaan mulai sadar akan pentingnya kualitas. Tidak hanya kualitas pada software sebagai ‘produk’ tapi juga kualitas pada cara penanganan proyek. Mulai memperhitungkan kelayakan proyek terhadap kemampuan organisasi (perusahaan).

Mulai mendokumentasi perencanaan dan perhitungan cost, dan menjadikannya rujukan di proyek-proyek selanjutnya.

Di level ini mulai ada Key Process Area (KPA) :

• Requiremets Analisys
• Software Project Planning
• Software Project Tracking
• Software sub-contract management (out-sourcing)
• Software Quality Assurance
• Software Configuration Management

Level 3 : Defined

Tidak hanya mulai sadar, tapi sudah mulai melakukan peningkatan-peningkatan baik dari segi organisational atau di level project quality. Istilah kerennya mulai “Tercerahkan”.

Tak hanya pemuasan konsumen (stake holder) tapi juga ada pencerahan untuk developer, training tentang kesadaran kualitas (quality awareness) dan penerapannya di semua divisi.

KPA-nya meliputi :

• Organisation Process Focus
• Organisation Process Definition
• Training Program
• Integrated Software Management
• Software product re-engineering
• Inter-group coordination
• Peer Reviews

Level 4 : Managed

Peningkatan kualitas sudah membudaya, sehingga kualitas proyek sudah bisa di prediksi sejak awal. Statistik sudah mulai diterapkan untuk mengukur dan mengontrol variasi proyek dan diterapkan di semua divisi organisasi.

KPA :

• Quantitative Process Management
• Software Quality Management

Level 5 : Optimized

Kualitas adalah segalanya, di semua lini organisasi sudah aware akan pentingnya kualitas baik untuk operasional organisasi ataupun terhadap proyek yang ditangani.

KPA :

• Defect Prevention
• Technology Change Management
• Process Change Management

Intinya point CMM pada dasarnya adalah bagimana mengelola sebuah software process.

Bagaimana menerapkan CMM dalam organisasi kita? Ada beberapa cara, diantaranya :
1. Menyewa assesor resmi yang telah bersetifikat CMM untuk conduct evaluasi secara formal. Misalnya untuk memenangkan tender pemerintah, untuk mencari sub kontraktor pengembang software yang berkualitas baik atau hanya untuk pure development shop --> memberi kesan kualitas yang baik kepada klien.
2. Mengirim pegawai/karyawan untuk mengikuti training CMM kemudian melakukan internal asessement
dll.

Referensi :
- Kim Caputo, CMM Implementation Guide : Choreographing Software Process Improvement, Addison Wesley, 1998
- http://goblog.wordpress.com/2006/11/28/cmm-is-a-religion/