Manifesto Agile: 4 Nilai Inti & 12 Prinsip Dijelaskan

Gambar di bawah ini berasal dari situs web Manifesto Agile dan menunjukkan empat pernyataan nilai Agile.

Agile Manifesto and the 4 Agile Values answer what agility is

Seperti yang dapat Anda lihat dalam pendahuluan nilai-nilai tersebut, penulis menyatakan bahwa mereka sedang menemukan cara-cara yang lebih baik untuk mengembangkan perangkat lunak dan membantu orang lain. Semua nilai penting, tetapi nilai-nilai di sebelah kiri diprioritaskan dibandingkan nilai-nilai di sebelah kanan.

Individu dan interaksi di atas proses dan alat

Seperti yang sebelumnya disebutkan, ketika Manifesto Agile dirilis, ia menantang metodologi berat. Model Kematangan Kemampuan (CMM) dan ITIL merupakan tren populer yang cenderung pada pendekatan berbasis proses pada masa itu.

Dengan demikian, mengejutkan bahwa para pemikir ini memilih untuk memulai dari manusia. Mereka percaya bahwa menemukan orang-orang yang tepat (individu) dalam tim dan membantu mereka bekerja sama secara efektif (interaksi) jauh lebih penting daripada mengikuti proses tertentu dan/atau menggunakan alat tertentu. Karena itulah mereka menempatkan penekanan di sebelah kiri: individu dan interaksi.

Perangkat lunak yang berfungsi di atas dokumentasi yang komprehensif

Dalam pengembangan perangkat lunak tradisional atau air terjun, tim akan menghabiskan waktu yang signifikan untuk mengumpulkan persyaratan dan mengembangkan desain serta spesifikasi, baru membangun sesuatu yang nyata di akhir siklus hidup. Penulis manifesto percaya bahwa memiliki solusi yang berfungsi lebih berharga daripada memiliki kumpulan besar dokumen yang menjelaskan bagaimana solusi tersebut bekerja.

Kolaborasi pelanggan di atas negosiasi kontrak

Nilai ketiga adalah kolaborasi pelanggan di atas negosiasi kontrak—di mana negosiasi kontrak berarti berdebat tentang apa yang termasuk dalam lingkup. Misalnya, Anda mungkin mendengar frasa seperti “Itu bukan yang ada dalam dokumen persyaratan Anda.” Para pemikir ini percaya bahwa bekerja sama dengan pelanggan untuk memberikan solusi yang benar-benar dibutuhkan jauh lebih penting.

Menanggapi perubahan di atas mengikuti rencana

Nilai Agile keempat dan terakhir adalah menanggapi perubahan di atas mengikuti rencana. Penulis setuju bahwa perencanaan penting—memang, tim Agile melakukan banyak perencanaan. Namun para pemikir ini percaya bahwa kemampuan untuk menanggapi perubahan yang tak terhindarkan jauh lebih penting daripada tetap berpegang pada rencana yang dibuat di awal proyek, ketika informasi masih terbatas.

Semua nilai-nilai ini dalam manifesto penting, tetapi nilai-nilai di sebelah kiri memiliki prioritas yang lebih tinggi dibandingkan nilai-nilai di sebelah kanan.

12 Prinsip Agile

Selain keempat nilai Agile ini, penulis Manifesto Agile setuju untuk menerapkan serangkaian 12 Prinsip Agile, yang membentuk dasar dari cara-cara kerja Agile. Meskipun kurang dikenal dibandingkan empat nilai Agile, saya merasa 12 prinsip Agile lebih praktis dan memberikan panduan yang lebih jelas untuk praktik Agile.

12 Agile Principles behind the Agile Manifesto

Untuk kemudahan, saya telah memberi nomor pada 12 prinsip tersebut, meskipun pada situs resmi.

  1. Prinsip pertama adalah prioritas tertinggiadalah memuaskan pelanggan melalui pengiriman perangkat lunak yang bermanfaat secara awal dan terus-menerus. Frasa ‘perangkat lunak yang bermanfaat’ membingungkan beberapa orang. Ingat, pada tahun 2001, ketika para pemikir ini memperkenalkan nilai dan prinsip Agile, mereka hanya fokus pada pengembangan perangkat lunak. Sejak itu, Agile telah diadopsi di hampir semua industri—arsitektur, manufaktur mobil, bahkan produksi pesawat tempur. Jika lebih masuk akal bagi Anda, gantilah ‘solusi yang bermanfaat’ dengan ‘perangkat lunak yang bermanfaat’.
  2. Prinsip kedua adalah untuk selamat datang pada perubahan persyaratan, bahkan di akhir tahap pengembangan. Meskipun kebanyakan orang saat ini fokus pada mengendalikan perubahan atau mengelola “penyebaran cakupan,” kenyataannya perubahan adalah hal yang tak terhindarkan. Proses Agile menunda pengambilan keputusan, mempersingkat siklus pengembangan, dan mendukung analisis permintaan secara tepat waktu. Ini memungkinkan tim Agile beradaptasi dengan cepat dan dengan biaya rendah. Hal ini memberikan keunggulan kompetitif dan merupakan salah satu pilar utama dari kerja Agile.
  3. Prinsip ketiga adalah untuk mengirimkan perangkat lunak yang berfungsi secara berkala, dari beberapa minggu hingga beberapa bulan, lebih disukai dengan jangka waktu yang lebih pendek. Salah satu manfaat utama dari pengiriman yang sering adalah mendapatkan umpan balik untuk memastikan Anda berada di jalur yang benar dan benar-benar membangun apa yang dibutuhkan pelanggan.
  4. Prinsip Agile keempat adalah tentang orang bisnis dan pengembang bekerja bersama setiap hari sepanjang proyek. Saat ini, pemangku kepentingan bisnis sering membuat dokumen persyaratan dan “melemparkannya ke dinding” ke pengembang. Berbulan-bulan bahkan bertahun-tahun kemudian, pengembang menyerahkan solusi kepada pemberi permintaan untuk pengujian akhir—hanya untuk menemukan bahwa solusi tersebut salah dimengerti, dibangun secara salah, atau sudah tidak dibutuhkan lagi. Penekanan pada prinsip ini adalah pada kolaborasi antara mereka yang membangun solusi dan mereka yang menggunakannya, untuk menghindari hasil seperti itu.
  5. Prinsip Agile kelima adalah untuk membangun proyek di sekitar individu yang termotivasi, memberi mereka lingkungan dan dukungan yang dibutuhkan, serta mempercayai mereka untuk menyelesaikan pekerjaan. Secara esensial ini adalah pendekatan tiga bagian: memberdayakan orang, memberi mereka otonomi, dan mempercayai mereka.
  6. Prinsip Agile keenam mendorong pengembangan yang berkelanjutan. Pendukung, pengembang, dan pengguna harus mampu mempertahankan ritme yang konstan tanpa batas waktu. Saat saya pertama kali mulai bekerja pada proyek teknologi, mereka sering berlangsung selama 6 bulan, 12 bulan, atau lebih lama. Sangat umum untuk mencapai sedikit hasil dalam bulan pertama atau kedua. Tidak mengherankan, hal ini menyebabkan periode tekanan besar di akhir, di mana beban kerja besar harus diselesaikan. Anggota tim diharapkan bekerja di malam hari atau akhir pekan untuk memenuhi tenggat waktu dan cakupan yang tetap. Ini dikenal sebagai proyek “march of death”. Agile tidak mengatakan Anda tidak akan pernah bekerja di malam hari atau akhir pekan—tetapi ia menekankan bekerja pada ritme yang berkelanjutan bagi semua orang.
  7. Prinsip ketujuh adalah bahwa perangkat lunak yang berfungsi adalah ukuran utama kemajuan. Secara tradisional, persentase penyelesaian digunakan untuk melacak kemajuan proyek. Persentase penyelesaian sangat tidak andal karena sulit untuk dinilai, terutama ketika mencapai 80% atau 90%. Persentase penyelesaian 90% sering berarti hanya 10% usaha atau waktu yang tersisa. Tim Agile menghindari persentase penyelesaian dengan membagi pekerjaan menjadi fitur atau fungsi, membaginya menjadi bagian-bagian kecil, dan melacak apakah bagian-bagian tersebut telah selesai. Pendekatan ini menghindari metrik kemajuan yang menyesatkan.
  8. Prinsip kedelapan adalah bahwa cara yang paling efektif dan efisien untuk menyampaikan informasi kepada tim pengembang dan di dalam tim adalah melalui percakapan tatap muka. Saat ini, alat komunikasi yang paling populer mungkin adalah email. Ini efisien bagi pengirim—setelah semua, mereka bisa mengirim pesan ke ratusan atau ribuan sekaligus. Tapi itu bukan komunikasi yang sebenarnya. Penelitian menunjukkan bahwa membaca tulisan orang lain meninggalkan ruang besar untuk salah paham. Para pendukung Agile telah belajar bahwa pemahaman bersama yang sejati membutuhkan mengumpulkan orang-orang bersama. Jika percakapan tatap muka tidak memungkinkan, gunakan saluran komunikasi dengan bandwidth tertinggi yang tersedia—ini bisa berupa panggilan video atau telepon. Ini jauh lebih baik daripada memposting dokumen ke SharePoint! Intinya di sini adalah menggunakan saluran komunikasi dengan bandwidth tertinggi yang tersedia. Efek samping dari memilih interaksi tatap muka adalah masuk akal untuk mengelompokkan anggota tim dari tim Agile yang sama. Saat ini, banyak organisasi mengabaikan poin yang tampaknya jelas ini.
  9. Prinsip kesembilan adalah fokus berkelanjutan pada keunggulan teknis dan desain yang baik untuk meningkatkan kelenturan. Fokusnya adalah menghindari jalan pintas atau utang teknis. Jangan melakukan sesuatu yang membuat pekerjaan lebih cepat dalam jangka pendek tetapi menimbulkan biaya lebih besar dalam jangka panjang. Jika Anda terus menumpuk utang teknis, Anda akan kehilangan kelenturan. Hal ini umum terjadi pada proyek waterfall dengan jadwal tetap. Untuk memenuhi tenggat waktu yang dijanjikan, jalan pintas dilakukan. Siklus pengujian mungkin dikurangi atau dihilangkan untuk menghemat waktu, yang mengakibatkan lebih banyak masalah dalam produksi setelah peluncuran. Ini menghasilkan penanganan darurat dan kode yang sulit dipelihara.
  10. Prinsip kesepuluh adalah tentang menjaga hal-hal tetap sederhana dan menghilangkan pekerjaan yang tidak perlu. Sederhana—seni memaksimalkan jumlah pekerjaan yang tidak dilakukan—adalah hal yang penting.Artinya, kita harus meninjau proses kita dan menghilangkan segala sesuatu yang tidak menambah nilai bagi pelanggan, sehingga memaksimalkan jumlah pekerjaan yang belum selesai sambil tetap mengirimkan apa yang dibutuhkan.
  11. Prinsip kesepuluh juga tentang tim yang mandiri. Arsitektur, persyaratan, dan desain terbaik berasal dari tim yang mandiri. Kita harus membiarkan mereka yang paling dekat dengan pekerjaan menentukan cara terbaik untuk menyelesaikannya—ini adalah inti dari prinsip ini.
  12. Prinsip terakhir, nomor 12, adalah tentang refleksi. Tim secara rutin merefleksikan cara menjadi lebih efektif dan kemudian sesuaikan dan beradaptasiperilaku mereka sesuai dengan itu.

Nilai dan prinsip Agile mungkin tidak terasa radikal saat ini, tetapi ketika diumumkan pada tahun 2001, mereka sangat revolusioner. Karena itulah istilah “Manifesto”. Mereka menggambarkan cara kerja yang sama sekali berbeda dari cara organisasi beroperasi di abad sebelumnya. Sebelum itu, pengembangan perangkat lunak sebagian besar meniru praktik kerja era industri. Memahami konteks sejarah ini sangat penting, seperti yang dibahas di bawah ini.

 

 

Leave a Reply