[:id]Alkasih ada sebuah perusahaan A yang membutuhkan aplikasi Android untuk mendukung proses bisnisnya. Setelah melalui proses panjang akhirnya ditentukan untuk membeli aplikasi android dari vendor B. Alasan utama dipilihnya vendor B dikarenakan aplikasi android yang sudah didevelop oleh vendor B sudah digunakan oleh perusahan lain yang proses bisnisnya sejenis dengan perusahaan A.

Setelah aplikasi android tersebut digunakan, ditemukan banyak kekurangan atau perlu adanya penambahan fungsi agar proses bisnis dapat berjalan lancar. Untuk kebutuhan tambahan tersebut Vendor A meminta tambahan biaya dan waktu untuk development. Proses negosiasi berjalan alot karena baik perusahaan A maupun Vendor B memiliki pandangan yang berbeda. Perusahaan A menganggap bahwa penambahan tersebut seharusnya sudah masuk dalam delivery dan tidak diperlukan tambahan biaya. Perusahaan A meminta proses development yang cepat karena sangat dibutuhkan oleh user. Sedangkan vendor B menilai hal itu di luar scope dalam perjanjian awal. Selain itu waktu yang dibutuhkan pun di luar ekspektasi dari Perusahaan A.

Mungkin cerita di atas bisa saja terjadi di perusahaan Anda. Proses development aplikasi android atau secara umum pengembangan software boleh dibilang cukup sulit untuk scoping dan penilaian biayanya. Karena jika dibandingkan dengan pengembangan rumah/bangunan maka hasil dan proses development aplikasi Android tidak kasat mata, sukar dilihat oleh user. Untuk pengembangan rumah/bangunan user dapat melihat secara langsung proses pengembangannya dan apa yang dihasilkan. Perencanaan dapat lebih mudah dengan melihat design arsitekturnya.

Dengan mempelajari kasus di atas, saya memberikan solusi pengembangan aplikasi android dengan metode agile. Di mana proses pengembangan dilakukan secara bertahap. Secara garis besar prosesnya dapat dilihat di gambar di bawah.

Konsep utama dari proses ini adalah user harus menentukan requirement yang dibagi per fase. Satu fase mungkin ditentukan berdasarkan lamanya proses development untuk fase tersebut. Misal satu fase adalah satu minggu. Hal lain yang perlu ditentukan adalah keterlibatan user dalam melakukan testing untuk menentukan kekurangan atau penambahan fungsi / feature untuk fase berikutnya.

Contoh requirement fase satu :
1. User dapat registrasi atau login langsung dengan social network
2. Data yang diinput saat registrasi menggunakan email sebagai user id nya.
3. Email yang diinput divalidasi dengan cara user mengklik URL yang dikirimkan server ke alamat email user yang didaftarkan.

Setelah development maka user harus melakukan Testing dan menemukan kekurangan atau tambahan feature yang harus didevelop di fase berikutnya.

Dengan proses seperti ini diharapkan kekurangan atau fitur yang diinginkan dapat dideteksi sedini mungkin selama proses development. Sehingga dapat segera diperbaiki atau disesuaikan sesuai dengan harapan dari user. Berbeda dari kasus perusahaan A di atas, di mana kekurangan / fitur tambahan ditemukan setelah terjadinya kesepakatan, delivery dan digunakan oleh user di Perusahaan A.

Dengan proses ini juga pembayaran dapat disepakasi per fase atau per bulan. Tidak perlu user membayar seluruh proses yang biasanya sangat mahal. Bisa jadi pembayaran bisa lebih murah karena setelah dilakukan maka cukup satu fase sudah selesai. Tidak serumit dari dugaan semula.

Jika di tengah jalan kedua belah pihak tidak ingin melanjutkan proses development, maka hal tersebut dapat dimungkinkan. Tidak ada yang merasa dirugikan karena delivery sudah dilakukan, user sudah menerima apa yang diminta. Dari sisi development pun sudah sesuai dengan bayaran yang disepakati. Intinya lebih dapat terukur. Dibandingkan development dengan requirement yang banyak, waktu development yang lama yang pada akhirnya tidak sesuai dengan yang diharapkan karena sulit untuk dideteksi apa yang diinginkan oleh user.
[:]