Rekayasa Perangkat Lunak Melalui Mendekatan AGILE

Dalam beberapa kasus pengembangan aplikasi perangkat lunak, mungkin kita pernah mengalami situasi sebagai berikut.

Kita berharap user atau calon pengguna aplikasi mampu meng-artikulasikan dan menggambarkan dengan tepat ekspektasi yang dia harapkan dari aplikasi yang sedang dikembangkan. Kemudian orang IT mencoba untuk meng-interpretasikan itu sebagai user requirement dan mulai men-desain. Dalam beberapa kasus, terjadi gap yang lebar antara tim IT dengan kemampuan imajinasi user, sehingga tim IT terkadang menggunakan asumsi berdasarkan pengalaman pribadinya. Akhirnya, desain selesai dan pembuatan program berjalan sesuai desain dan tiba saatnya bagi tim IT untuk menunjukkan hasil kerjanya. Dan yang terjadi, user mendapat banyak hal yang diluar bayangannya dan yang kadang justru menjadi tidak puas dengan hasilnya.

Situasi di atas telah menjadi sesuatu yang sering terjadi saat ini, karena begitu banyaknya pilihan teknologi yang tersedia dan semakin kompleknya proses bisnis di sebuah enterprise. Orang-orang bekerja pada industri IT kini memiliki kesulitan untuk selalu mengejar kecepatan perubahan yang muncul dari kemajuan dan banyaknya pilihan yang tersedia. Sedangkan pengguna teknologi, akan semakin mengalami kesulitan untuk meng-artikulasi dan berimajinasi untuk membuat sebuah user requirement apalagi jika aplikasi yang dibangun adalah sebuah proses dari titik nol.

Kini pada para praktisi rekayasa perangkat lunak mencoba untuk mencari semacam framework (kerangka kerja) yang sesuai untuk mengakomodasi situasi di atas sehingga proyek dapat berjalan dan menghasilkan sesuatu seperti yang diharapkan oleh user dan orang IT dapat menurunkan resiko akan kegagalan sebuah proyek.

Tulisan ini mencoba membuka sedikit wawasan mengenai pendekatan baru dalam rekayasa perangkat lunak. Cerita akan dimulai dengan melihat salah satu pendekatan rekayasa lunak yang sering disebut sebagai waterfall model dan telah digunakan selama cukup lama dalam rekayasa perangkat lunak. Dan kita mencoba melihat beberapa point sehingga waterfall model tidak selamanya bisa menjadi "satu obat mujarab untuk semua jenis penyakit". Setelah itu, baru kita mencoba melihat salah satu "obat alternatif" yang dapat kita pergunakan dalam rekayasa perangkat lunak, yang saat ini lebih dikenal dengan metode "AGILE".

Model Rekayasa Perangkat Lunak "Waterfall"

Hampir beberapa dekade, kita telah mengenal dan menerapkan pengembangan atau rekayasa perangkat lunak menggunakan pendekatan warerfall. Pendekatan ini secara sederhana membagi proses rekayasa perangkat lunak menjadi lebih kurang 5 tahapan inti.

• Analisis, adalah tahapan dimana tim IT berdiskusi dengan user untuk mendapatkan kebutuhan user dan ekspektasi user terhadap aplikasi yang akan dibuat. Secara ringkat, tahapan ini akan menghasilkan sebuah dokumen yang bisa kita sebut sebagai User Requirement.
• Desain, adalah tahapan dimana tim IT mulai menterjemahkan user requirement yang telah diserahkan atau disetujui oleh user. Biasanya, proses ini akan menghasilkan dokumen yang dapat kita sebut sebagai Technical Design. Kalo kita sedang merencanakan pembuatan rumah, tahap ini lebih kurang sama dengan proses pembuatan dokumen arsitek.
• Coding, pada saat ini pengembangan yang sesungguhnya dari aplikasi dimulai. Program-program mulai dikerjakan, tentu saya programmer yang bertugas membuat software akan selalu mengacu kepada dokumen Technical Design. Tahap ini dinyatakan selesai jika semua program telah selesai dibuat dan/atau di-'package'. Aplikasi telah selesai dan disiap untuk dilakukan proses pengujian.
• Testing, kini tiba waktunya untuk melakukan testing apakah aplikasi yang dibuat telah sesuai dengan yang sudah dituangkan dalam user requirement. Biasanya keluaran dari tahapan ini adalah dokumen pernyataan tentang "User Acceptance Test".
• Deploy, setelah tahapan testing selesai, kini tiba waktunya untuk menginstall program tersebut dan aplikasi mulai dioperasikan serta bekerja sesuai fungsinya.

Kini kita mencoba melihat berbagai kondisi nyata dalam proyek rekayasa perangkat lunak, sehingga terkadang metode waterfall ini tidak bisa menjadi obat mujarab untuk semua proyek rekayasa perangkat lunak. Ini tidak berarti bahwa waterfall tidak relevan lagi, tapi lebih tepatnya adalah kita harus melihat kenyataan bahwa warerfall bukan satu-satunya pendekatan yang harus dijalankan dalam setiap proyek rekayasa perangkat lunak.

Pendekatan Waterfall jarang sekali terjadi kolaborasi yang cukup kuat dan konsisten antara satu tim dengan tim lainnya. Pada setiap stage atau tahapan diatas, sangat mungkin tim yang bertanggung jawab terhadap tahapan tersebut menggunakan asumsi-asumsi yang berbeda dengan tim yang bertanggung jawab pada proses sebelumnya yang bisa disebabkan karena berbagai alasan seperti perbedaan domain knowledge, pengalaman industri dan lain sebagai. Orang- orang yang bertanggung jawab membuat user requirement, umumnya domain knowledgenya adalah business process pada industri tertentu. Pada saat orang desain mulai melakukan technical design, sangat dimungkinkan dia memiliki pengetahuan business process yang sama levelnya dengan tim yang membuat user requirement, sehingga dia bisa menggunakan asumsi yang mungkin berbeda pada saat user requirement dibuat. 

Apa yang dihasilkan oleh satu tahapan, merupakan "kontrak kerja untuk tahapan selanjutnya, umumnya dilegitimasi dengan istilah sign-off. Jadi jika User Requirement telah di sign-off pada tahap analisis, dokumen ini menjadi kontrak kerja bagi tahapan desain untuk menghasilkan technical design. Programmer yang bekerja pada saat coding, akan menggunakan techinal design yang telah mendapatkan sign-off sebagai kontrak kerja. Beberapa kemungkinan masalah yang dapat muncul kemudian adalah:

• Kesalahan atau kekurangan yang terjadi pada tahap awal akan mengakibatkan kesalahan berantai ditahap-tahap selanjutnya.
• Karena testing (UAT) baru mulai dilakukan setelah semua program selesai, respon terhadap kesalahan akan sangat terlambat sehingga proses perbaikan akan jauh lebih lama.
• Proses ini cenderung lambat untuk "time-to-market", sehingga pada saat aplikasi selesai dan siap beroperasi, lingkungan bisnis telah berubah sehingga aplikasi tersebut tidak bisa menggali pasar yang diharapkan sebelum aplikasi dibuat.

Perangkat input dari aplikasi berkembang pesat seperi card reader, scanner, kamera dan lainnya. Perangakat outputnya, juga semakin beragam, mulai dari tampilan grafis, resolusi warna, video dan lain sebagainya. Jika dulu, Sistem Informasi Manajemen (SIM), umumnya tampil dalam bentuk 'text mode' dengan 'menu driven'-nya. Pada saat itu, para user dan tim IT dapat dengan mudah untuk berdiskusi tentang User Requirement. Kini pilihan yang teknologi semakin banyak ditambah bisnis proses yang semakin komplek, user mengalami kesulitan untuk membuat sebuah user requirement yang menyeluruh dan tim IT juga harus memahami juga pilihan IT yang ada.

Banyak sekali proyek IT yang cenderung gagal karena hasilnya tidak sesuai ekspektasi atau waktu yang berjalan molor. Para praktisi rekayasa perangkat lunak melihat bahwa pendekatan waterfall sangat cocok, jika user dan tim IT sangat tahu persis tentang proses bisnis dan pilihan teknologi yang akan digunakan. Kondisi ini akan menghasilkan user requirement dan technical design yang komprehensif dan terstruktur dengan baik.

Waterfall model akan mengalami kesulitan pada saat user dan tim IT berada pada situasi yang komplek untuk membuat user requirement dan technical design karena minimnya pengalaman terhadap aplikasi yang sedang dibuat. Praktisi rekayasa perangkat lunak mencoba mencari merode lain, dimana aplikasi dikembangkan secara bertahap, berkolaborasi secara total dan adanya learning curve selama proyek berjalan. Pada bagian selanjunya kita akan melihat model alternatif yang mungkin dapat kita gunakan dalam proyek rekayasa perangkat lunak kita. Pendekatan ini kemudian sering kita kenal sebagai pendekatan AGILE.

Model Rekayasa Perangkat Lunak "AGILE"

Rekayasa perangkat lunak menggunakan AGILE sering juga disebut sebagai "iterative method" dan dapat juga disebut sebagai "incremental product development". Pada saat, tim IT dan tim user mengalami kesulitan untuk mendefinisikan kebutuhan mereka secara komprehensif, kemungkinanan cara ini akan lebih efektif. 

Proses pengembangan berjalan secara 'incremental', artinya aplikasi tidak harus diselesaikan secara sekaligus, melainkan bertahap. Disaat yang saman, 'incremental' ini juga terkain dengan kegiatan yang berulang-ulang ('iterative'). Dan hal yang terpenting adalah kolaborasi penuh antara semua personal proyek.

Mari kita lihat sebuah ilustrasi sederhana rekayasa perangkat lunak menggunakan AGILE :

• Tim agile tidak menuntut jumlah personal yang banyak, secara efektif sekitar 7 orang. Mereka terdiri dari orang bisnis (sering disebut sebagai product owner), orang-orang IT dan fasilitator AGILE.
• Mereka kemudian menetapkan waktu iterasi, jika kita menggunakan Scrum, iterasi ini disebut juga sebagai sprint (Scrum adalah salah satu metode implementasi AGILE. Selain agile ada juga Extreme Programming - mungkin pada topik mendatang saya akan mencoba untuk melihat lebih detail mengenai hal ini). 
• Sprint ini adalah waktu yang pendek, mungkin sekitar 2 minggu. 
• Pada saat tim agile menetapkan sprint atau iterasi selama 2 minggu, tim ini kemudian menetapkan 'incremental product'.
• Misal, iterasi pertama (2 minggu pertama), tim menetapkan untuk membuat 'screen untuk input data pegawai', iterasi kedua kemudian tim menetapkan incremental kedua dan seteruskan.
• Selama 2 minggu ini, tim Agile berkolaborasi secara terus menerus dan mereka memiliki meeting harian lebih kurang 15 menit. 
• Pada tim agile, semuanya bertanggung jawab terhadap incremental product. Mereka adalah satu kesatuan sebagai tim (orang bisnis, orang IT dan fasilitator). Selama 2 minggu itu, mereka berdiskusi, mendesain, membuat program dan testing secara bekerja sama sehingga incremental product itu siap untuk di deploy. 
• Umumnya, konsep ini akan berjalan sangat baik jika semua anggota agile berada pada lokasi yang sama. Mereka harus berdiskusi tiap hari lebih kurang 15 menit dengan 3 agenda utama (apa yang telah dikerjakan kemaren, apa yang akan dikerjakan hari ini dan kendala apa yang bisa menghambat progress).

Pada pendekatan waterfall, seolah-olah terdapat kontrak kerja antara pihak User dan IT yang dituangkan dalam user requirement. Pada metode Agile, User dan IT berkolaborasi bersama. Mereka menetapkan secara bersama apa yang ingin dibangun pada setiap iterasi, mereka sama-sama melakukan testing dan mereka bersama-sama belajar dari satu iterasi ke iterasi berikutnya. Setiap iterasi mereka selalu menghasilkan incremental produk yang tentu saya workable, tested dan membangun integrasi dari satu iterasi ke iterasi berikutnya.

Mari kita lihat beberapa kelebihan yang ditawarkan oleh pendekatan ini.

• Selalu terdapat RUNNING version. Sejak dari  iterasi pertama selesai, kita telah memilki versi yang sudah berjalan dan dapat kita manfaatkan. Misal, kita telah memiliki fungsi untuk memasukkan data.
• Error dapat lebih mudah untuk diidentifikasi. Karena tim bekerja secara kolaborasi dan incremental, error akan mudah terdeteksi lebih awal dan perbaikan dan dikerjakan secara cepat. 
• Respon terhadap error menjadi lebih cepat karena tim user dan IT saling berkolaborasi sebagai satu tim tanpa ada sekat. Sehingga proses perbaikan menjadi lebih cepat dan tepat.
• Agile juga menjadikan aplikasi "time-to-market". Respon terhadap kebutuhan pun menjadi lebih cepat. Karena prioritas incremental item pada setiap iterasi dapat menyesuaikan kebutuhan di market dan tim dapat memberikan respon yang cepat.

Summary 

AGILE sangat cocok digunakan pada tim IT dan user berada pada kondisi "uncertain requirement combined with unpredictable technology". User dan IT berkolaborasi bersama untuk memcoba menggali solusi secara bertahap dan terdapat proses pembelajaran dati setiap iterasi.

Jika user mampu untuk menggambarkan user requirement secara terstruktur dan menyeruh, serta diikuti oleh tim IT yang sagat familiar dengan proses bisnis dari aplikasi yang sedang dikembangkan, waterfall model akan memberikan solusi yang effisien. Hal ini karena, tim IT dan user dapat memprediksi hasil akhir jauh lebih terstruktur dan bisa mempersiapkan solusi yang cepat dan tepat guna menyelesaikan aplikasi tersebut.

NEXT

Semoga tulisan ini dapat memberikan gambaran tentang adanya pendekatan rekayasa perangkat lunak AGILE sebagai alternatif pendekatan Waterfall yang sudah kita kenal luas. Selanjutnya, saya akan mencoba untuk mempersiapkan tulisan berikutnya untuk memberikan gambaran yang lebih detail dan beberapa metode yang dapat digunakan untuk mengimplementasikan AGILE.

• Karakteristik dari pengembangan AGILE, apa saja prinsip pokok dari sebuah implementasi AGILE dan manisfesto AGILE
• Agile Menggunakan Extreme Programming (XP), metode ini berfokus pada programming practices
• Agile Menggunakan Scrum, metode ini, metode ini berfokus pada project management
• Lean Development dan Kanban, metode ini mencoba mengadapsi proses manufaktur yang diperkenalkan oleh TOYOTA dalam rekayasa perangkat lunak.

--------

Link:

Topik tentang mengenai kehidupan di Singapura: Kehidupan di Singapura 

Topik tentang mengenali teknologi informasi: Mengenali Teknologi Informasi

Semoga Bermanfaat

Singapore, Januari 2014
"Dipersiapkan selama perjalanan rumah-kantor di atas MRT (pengguna setia MRT)"