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.
Rabu, Februari 27, 2008
Metodologi tangkas dalam pengembangan software
Langganan:
Posting Komentar (Atom)
2 komentar. Sampeyan sudah?:
"tidak bisa diprediksi kapan selesainya"
Kayaknya kurang tepat kalo tidak bisa diprediksi. Justru karena salah satu prinsip dari Agile Methodology adalah kolaborasi antara developer dengan pelanggan dalam hal salah satunya estimasi waktu penyelesaian dan prioritas pekerjaan.
"TOR atau kerangka acuan kerja yang sejelas mungkin padahal bisa jadi saat pekerjaan dilaksanakan banyak perubahan terjadi disana sini nggak sesuai KAK awal"
Apa yang dimaksud dengan TOR yang sejelas mungkin? Saya kira TOR itu hanya sebatas User Requirement, dan tidak akan lebih detail dari itu. Untuk User Requirement, XP mempunyai User Stories dan Scrum mempunyai Backlog.
Oke Puas.
:)
Saya setuju bahwa prinsip agile methodology ini memang salah satunya adalah eskalasi skala prioritas. Dan itu belum terpaparkan di tulisan ini. Pada awal proyek, mungkin kita bisa memperkirakan kapan selesainya proyek ini. Namun, dalam perjalanannya karena banyaknya kebutuhan user yang belum sempat teridentifikasi secara utuh diawal, bisa jadi prediksi tersebut meleset. Itu yang saya sebut tidak bisa diprediksi kapan selesainya.
Tentang TOR, saya juga sependapat bahwa TOR bisajadi hanya memuat kebutuhan2 user yang "terfikir"kan saat TOR itu dibuat dan tidak lebih dari itu. Jadi yang dimaksud dengan TOR sejelas mungkin adalah pendefinisian seutuh mungkin dari semua user req. tsb.
Thanks bro!
Posting Komentar