Home » Coding » Kenapa Agile ???

Kenapa Agile ???

Industri software pernah mengalami keterpurukan dimana dilaporkan bahwa 80% project software mengalami kegagalan, selain karena over budget juga terlambat dalam waktu delivery nya.

Kenapa Gagal ????

Berikut beberapa alasan utama kenapa project tersebut gagal

  • Kurangnya keterlibatan user
  • Jeleknya proses pengumpulan requirement
  • Jadwal yang nggak realistis
  • Kurangnya pengetesan
  • Kurangnya change management
  • Kurang flexible dan terlalu banyak proses

Lho serius niee metode SDLC tradisional(ex:waterfall) tidak mampu menyelesaikan masalah tersebut ??? ,
mari kita lihat :

  • Ketika masalahnya adalah kurangnya keterlibatan user, jadinya product itu akan jauh dari harapan user, lalu bagaimana bisa metode yang mengajarkan mari kita bahas requirement di depan dan sampai ketemu nanti di User Acceptence Test yaaa, akan bisa banyak melibatkan user ???
  • Jadwal yang realistis, waktu pengerjaan sudah ditentukan di awal project dan apa yang terjadi ketika ditengah jalan bertemu dengan masalah-masalah yang berat dan tak terprediksi, dengan metode tradisional akan bilang “show must goon”, akhirnya jadwal yang dirasakan oleh team development sudah tidak realistis lagi. Dengan kondisi seperti itu hanya ada 2 jawaban, tepat waktu dengan kualitas product yang jelek atau waktu pengerjaan project jadi molor.
  • Kurang nya pengetesan akan berdampak pada kualitas product, pada method waterfall misalnya, dimana tahapan “Testing” itu dilakukan setelah tahapan “Development” maka apa yang akan terjadi jika waktu untuk “Development” molor karena ada suatu masalah???. Akibatnya kadang waktu untuk tahapan “Testing” yang akan menjadi korban dan dampaknya adalah kurang terjaminnya kualitas product.
  • Terakhir soal flexibilitas, cara-cara tradisional waterfall misalnya, setiap tahapan sudah ditentukan dengan pasti urutannya. Tahapan berikutnya hanya bisa dilakukan kalau tahapan sebelumnya telah selesai, ya tidak perlu penjelasan panjang karena deskripsi tersebut sudah pasti bertentangan dengan flexibilitas pekerjaan/tahapan proses SDLC

Dan bagaimana Agile bisa menjadi jawaban atas kondisi tersebut ??

Agile memang tidak mungkin menjadi jawaban atas semua masalah, namun Agile mempunyai method yang efektif untuk menjawab permasalahan tersebut diatas, dan berikut adalah cara Agile menjawab beberapa masalah tersebut :

Jeleknya pengumpulan requirement ??
Agile menegaskan bahwa sebuah fitur yang diajukan oleh user harus ditulis acceptance test nya terlebih dulu sebelum ditulis code nya. Sebuah requirement / permintaan oleh user didefinisikan sebagai sebuah fitur harus diperjelas dan dilengkapi dulu test case acceptance test nya oleh user, hal ini akan mendorong user untuk lebih detail menjelaskan tentang apa yang mereka minta, user harus berfikir terlebih dahulu tentang yang mereka inginkan sebelum code aplikasi ditulis. Makanya kualitas requirement disini akan menjadi lebih tinggi, lebih jelas, dan memudahkan seorang programmer untuk menulis code nya.

Kurangnya keterlibatan user ??
Dalam Agile, User adalah salah satu komponen team. Dan sebagai anggota team, user bekerja sama dengan team development untuk memastikan kebutuhan yang mereka minta terpenuhi. User memberikan requirement, menyetujui hasil product, dan yang menentukan apakah fitur yang dikerjakan tersebut sudah siap untuk release atau tidak.

Flexibility ??
Agile mengintegrasikan project management ke dalam proses itu sendiri. Fungsi-fungsi project management dibagi ke seluruh team development. Sebuah tema agile lah yang memulai dengan komitmen terhadapa pekerjaan yang diberikan, mereka melakukan negosiasi dengan user, dan mereka yang mengatur dirinya sendiri untuk menyelesaikan fitur-fitur. Selain itu aktifitas yang dilakukan oleh team agile juga tetap menghasilkan data-data pencapaian project, bias dilihat dari burndown chart dan peningkatan velocity dari tiap tahapan/incremental

Jadwal yang tidak realistis ??
Ini adalah hal yang menjadi sebagian masalah besar dalam SDLC, dan bagaimana Agile menyelesaikan masalah jadwal release. Dalam Agile sebuah estimasi penjadwalan adalah proses kolaboratif antara User (Product Owner) dengan Team Development. Pada awal nya User akan memperkirakan estimasi waktu penyelesaian sebuah fitur, kemudian Team Development akan meninjau, menimbang, dan memberikan umpan balik terhadap estimasi tersebut, apakah perlu direvisi atau masih on the track. Begitu seterusnya sampai ditemukan kata sepakat untuk waktu estimasi penyelesaian sebuah fitur. Jadi jadwal bukanlah sebuah hal yang ditentukan sepihak, melainkan hasil kolaborasi 2 belah pihak.

Testing ??
Agile menuntut ketika team development memulai menulis code sebuah fitur, maka mereka juga harus menulis test code, dan test code ini akan selalu dijalankan setiap ada perubahan code fitur. Test code ini selalu dijalankan terus-menerus ketika ada perubahan code fitur. Hal ini berarti  baik code fitur maupun test code harus dikerjakan oleh Team Pengembang, sehingga komitmen dan tanggung jawab test terhadap fitur lebih jelas dan lebih berkualitas.

Kesimpulan :

Agile mungkin tidak menjawab semua permasalahan yang terjadi di dunia pengembangan software, namun ini merupakan sebuah langkah perubahan besar dalam sebuah jalan yang benar. Berdasar Agile Manifesto, Agile lebih mengutamakan proses yang terjadi dalam team, juga memberdayakan semua komponen project management. User sebagai product owner yang harus ikut aktif dalam proses pengembangan, juga Team Development yang selalu berkomitmen terhadap apa yang telah disepakati bersama. Team Development tidak lagi mengenal segmentasi dan perbedaan fungsi, dan mengutamakan kerja sama dalam menyelesaikan fitur yang diminta oleh Product Owner. Dalam Agile tidak ada lagi Project Manager yang paling berkuasa, tidak ada pembagian fungsi, misalnya system architect yang ketika rancangan system nya sudah selesai lalu bisa berkata “aku liburan dulu ya kawan”, juga tidak ada seorang programmer yang selalu disuruh lembur pulang malem dan berangkat pagi. Dalam Agile yang ada adalah sebuah Team, yang berkolaborasi saling mengisi fungsi, sekarang jadi system architect besok melakukan test terhadap fitur dan kadang juga jadi programmer yang menulis code.Semua anggota team berkomitmen dan bertanggung jawab terhadap hal yang sudah disepakati bersama.

So, let’s say “Agile On” ……………..

Leave a Reply

Scroll To Top