Advertisement
  1. Code
  2. General

Prinsip-prinsip Pengambangan Agile

by
Read Time:11 minsLanguages:

Indonesian (Bahasa Indonesia) translation by Aditia Dwiperdana (you can also view the original English article)

Agile atau Pengembangan Agile, kita semakin sering mendengar istilah itu belakangan ini. Tapi apakah kita tahu apa maksudnya? Bagaimana hal tersebut membantu kita lebih efektif sembari bersenang-senang saat mengembangkan perangkat lunak? Bagaimana kita bisa menggunakannya untuk berkomunikasi dengan orang bisnis diain membuat komunikasi itu mudah dan membangun untuk kedua pihak?


Apa itu Pengembangan Agile?

Ada banyak orang yang berbakat dan berpengalaman membuat perangkat lunak yang serius. Para developer ini melihat perusahaan dan tim pengembang lain, bagaimana proses yang mereka miliki membuat pekerjaan mereka lebih mudah. Mereka mengumpulkan pengamatan mereka untuk membuat Agile Manifesto. Dan mereka bilang:

Kami menemukan cara lebih baik untuk mengembangkan perangkat lunak dengan melakukan dan membantu orang lain melakukannya. Dengan melakukan pekerjaan itu kami merumuskan nilai-nilai:

  • Individu dan interaksi daripada proses dan peralatan.
  • Perangkat lunak yang bekerja daripada dokumentasi lengkap
  • Kolaborasi pengguna daripada negosiasi kontrak
  • Merespon perubahan daripada mengikuti sebuah rencana

Artinya, walau ada nilai dari hal-hal di sebelah kanan, kita lebih menghargai hal-hal di sebelah kiri.

Dalam artikel ini saya akan menjelaskan dua belas teori dan teknik Pengembangan Agile. Ini hanyalah langkah pertama ke dunia baru proses Pengembangan Perangkat Lunak.


1 - Kepuasan Pelanggan

Prioritas tertinggi kita adalah untuk memuaskan pelanggan dengan delivery perangkat lunak yang bernilai walau tidak lengkap fiturnya, lebih awal dan kontinu. Artinya kita mengembangkan perangkat lunak dan menambahkan setidaknya satu fitur, per iterasi.

Bayangkan kita ingin membuat engine blog; kita mungkin melakukan proses berikut:

  1. Buat halaman yang menampilkan blog; kirim ke pelanggan
  2. Buat fitur pengelolaan user dan keanggotaan; kirim ke pelanggan
  3. Tambahkan fitur memberi komentar dan pengelolaan komentar; kirim ke pelanggan
  4. Dan seterusnya...

Ini adala pendekatan yang sederhana, tapi pelanggan bisa melihat kemajuan dari perangkat lunak mereka dan memberimu masukan untuk setiap fitur. Fitur tersebut bisa sempurna namun bisa juga membutuhkan perbaikan, tapi kamu bisa merespon perubahan dengan cepat: ini adalah kondisi yang menguntungkan untuk semua pihak.


2 - Beradaptasi dengan Kebutuhan yang Berubah

Walau sudah jauh di siklus pengembangan, proses Agile membuat kamu bisa menerima perubahan demi keuntungan pelanggan.

Pelanggan ini proyek diselesaikan dengan cepat dan semiirip mungkin dengan desain yang mereka bayangkan. Hal ini bisa dicapai dengan mudah dengan mendengarkan masukan merka dan siap untuk berubah. Jika kita bisa bereaksi dengan cepat terhadap perubahan kebutuhan, kita akan menjadi pilihan terbaik yang diambil klien. Semua tentang Agile berhubungan dengan komunikasi dan perubahan. Kita melakukan berbagai hal sebagaimana yang diminta, membuat proses pengembangan perangkat lunak selesai lebih cepat. Ini bisa dicapai karena kita mengembangkan potongan-potongan kecil dari perangkat lunak tersebut, dan perubahan terhadap kebutuhan tidak terlalu memperngaruhi kita.


3 - Kirim Kemajuan secara Rutin

Kita perlu kirim versi baru antara beberapa minggu atau beberapa bulan sekali; semakin pendek jangka waktunya semakin baik.

Pelanggan lebih percaya dengan kita dan produk kita selama selalu kita perbarui

Dari pengalaman saya, pelanggan merasa lebih percaya dengan kita dan produk kita selama diperbarui, yang merupakan hal yang sangat penting dalam menjaga hubungan dengan mereka. Keuntungan lainnya adalah masukan dari klien kita, membuat kita bisa bereaksi dengan mengubah kelas, fitur, modul, atau bahkan arsitektur. Kita tidak akan tiba-tiba bangun setelah bekerja berhari-hari atau berbulan-bulan hanya untuk melihat semua yang kita buat dibuang begitu saja. Pertimbangkan situasi berikut:

Kamu diminta membuat modul yang akan menampilkan teks sederhana dalam pengelola konten. Tiba-tiba kebutuhan beubah dan kamu harus menambahkan form yang akan mengirim email ke alamat tertentu. Ditambah lagi, form ini harus bisa disesuaikan jadi user bisa menambahkan data baru dan pemeriksanya. Jadi kamu harus melupakan tentang kebutuhan teks sederhana di awal. Seberapa cepat kamu ingin tahu tentang perubahan ini?

Jika kamu bekerja dalam sebuah proyek dengan klien dan mengirim kemajuan dengan rutin, kamu bisa tahu tentang perubahan ini lebih cepat, dan perubahan seperti itu akan menjadi lebih mudah untuk kedua pihak.


4 - Bekerja Bersama dengan Rutin

Hal ini mungkin menjadi prinsip yang paling sulit dibiasakan, terutama jika kamu terbiasan membuat perangkat lunak dengan metode lama 'waterfall'. Kamu, sebagai developer, biasanya tidak berbicara dengan bahasa yang sama dengan klien, tapi kamu bisa mencari cara untuk menjalin komunikasi yang penuh makna dengan mereka. Satu cara terbaik menurut saya adalah untuk menjelaskan semuanya dengan cerita sederhana yang memberitahu kita untuk siapa sebuah fitur dibuat, apa tanggung jawabnya dan kenapa kita membutuhkannya. Tentu saja, ini akan lebih mudah semakin banyak kita bekerja dengan klien kita. Pendekatan lain yang bisa membantu adalah Behavior Driven Development (BDD), tapi itu adalah topik untuk artikel yang berbeda.


5 - Membuat Proyek dengan Individu yang Bersemangat

Berikan lingkungan yang baik untuk orang-orang yang berkerja denganmu dan penuhi kebutuhan mereka, dan percayai mereka untuk menyelesaikan pekerjaannya.

Penting untuk menyediakan atmosfir yang baik dan semua kelengkapan yang dibutuhkan untuk membangun perangkat lunak yang baik. Perusahaan akan kehilangan pekerja terbaik jika perusahaan tersebut tidak benar-benar mempedulikan mereka. Kepercayaan bahwa developer bisa menulis, menguji, dan mendeploy perangkat lunak ke server menggunakan klien FTP dan mengedit file di server lalu membuat masalah. Jika kamu masih mempercayai kebiasan lama ini, kamu harus berubah sekarang.

Mempertahankan karyawan hanya salah satu keuntungan; kamu juga bisa membangun perangkat lunak yang lebih besar dan lebih baik dengan lebih cepat. Coba pikirkan: menulis kode yang bisa digunakan kembali, pengujian otomatis, dan deployment otomatis ke semua server akan sangat mengurangi waktu pengembangan. Kita biasanya berpikir kita akan membuat proyek lebih lama karena harus belajar menggunakan perangkat bantuan seperti Jenkins, GIT, SVN, Gerrit, Behat, dan lain-lain. Memang benar, tapi kita akan bisa menggunakan kembali perangkat dan konsep tersebut di proyek di masa depan.


6 - Menggunakan Komunikasi Tatap Muka

Ini adalah metode yang paling efisien dan efektif untuk menyampaikan informasi ke klien dan tim pengembang.

Siapa yang tidak kewalahan atau marah melihat 6.255.384 email dalam inbox karena perusahaan menginkan semua komunikasi 'tertulis'? Saya melihat beberapa kali dalam hidup saya, dan saya tidak merekomendasikan bekerja dalam perusahaan dengan kebiasaan seperti itu. Komunikasi tatap muka membuat komunikasi lebih mudah dan lancar, dan membuat kita bisa memberi lebih banyak informasi. Kita bisa menggunakan komunikasi verbal dan non-verbal untuk memberitahu anggota tim apa yang kita pikirkan. Sudah pasti cara ini lebih cepat daripada mengirim email satu sama lain.

Tapi yang paling penting adalah kita percaya satu sama lain; kepercayaan bisa didapat dengan mudah dalam ligkungan yang mendukung komunikasi tatap muka.


7 - Mengukur Kemajuan dengan Perangkat Lunak yang Bekerja

Ini adalah aturan favorit saya; aturan ini membolehkan kita bekerja sesuai dengan proses kita sendiri. Pengembang perangkat lunak berbeda dengan karyawan lain; jadi seharusnya diperlakukan berbeda pula. Dari pengalaman pribadi saya, saya belajar untuk tidak menilai seseorang dari tim pengembang selama pekerjaannya selesai. Developer tidak ingin membuat perangkat lunak yang jelek, dan mereka tidak akan melakukannya jika kita biarkan mereka bekerja sesuai dengan preferensi mereka masing-masing. Karena pelanggan akan senang asalklan pekerjaan yang mereka bayar selesai dengan baik; mereka tidak peduli bagaimana caranya.


8 - Mempertahankan Kecepatan yang Konstan

Proses Agile mendorong pengembangan yang berkelanjutan, membuat kita bisa mempertahankan kecepatan pengembangan untuk seterusnya.

Keuntungan yang paling dikenal dari Agile (seperti penerimaan perubahan kebutuhan, reaksi cepat terhadap masukan, dan lain-lain) cukup umum diketahui, namun menurut saya keuntungan terbesarnya adalah bisa mengetahui waktu yang dibutuhkan untuk sebuah proyek atu fitur. Setelah beberapa pengiriman, tim pengembang akan menghasilkan nilai bisnis yang paling berharga: kapasitas. Kapasitas adalah jumlah pekerjaan yang bisa diselesaikan tim dalam satu iterasi. Nilai kapasitas akan stabil setelah beberapa iterasi, dan kita bisa menghindari deadline yang tidak masuk akal dan estimasi waktu yang 'dikeluarkan dari topi' saat mempresentasikan penawaran perusahaan ke pelanggan.

Banyak orang berkata tidak mungkin dan penjadwalan akan lebih akurat. Saya tidak setuju; jadwal mengasumsikan bahwa tidak akan ada kesalahan atau penundaan yang tidak bisa dihindari.

Itu adalah rencana yang sempurna untuk tim yang sempurna, dan tim seperti itu tidak ada.


9 - Perhatikan Kemajuan Industri

Memperhatikan perkembangan industri akan membantu kita berkerja lebih cepat.

Kita diharapkan untuk berkembang dan membuat kemajuan. Kita harus terus belajar setiap hari, karena industri bergerak dengan sangat cepat. Karena perangkat keras dan perangkat lunak erus menjadi leibh baik, kita harus tetap kekinian; jika tidak, kita akan menemukan diri kita di dalam 'laut baru' dan akan sulit untuk bisa mengikutinya.

Refactoring adalah solusi untuk sebagian besar masalah. Dengan melakukan refactoring secara konstan (saat dibutuhkan), kita bisa menerapkan teknik baru dan memperbaiki arsitektur perangkat lunak kita.


10 - Kesederhanaan itu Penting

Bill Gates pernah berkata:

Jika saya punya pekerjaan yang rumit, saya akan memberinya pada orang yang paling pemalas yang saya punya, karena mereka akan menemukan cara paling sederhana untuk menyelesaikannya.

Kesederhanaan adalah aturan yang penting. Ini tidak berartti kamu harus menjadi pemalas, tapi itu berarti developer sering mempersulit pekerjaannya sendiri. Jika kamu hanya melakukan pekerjaan yang klien inginkan, tanpa fitur tambahan dan pengembangan, beban pekerjaan akan lebih ringan dan kamu akan mencapai tujuan kamu. Akhirnya, itulah yang dibutuhkan pelanggan.


11 - Mengelola Diri Sendiri

Arsitektur, kebutuhan, dan desain terbaik muncul dari tim yang mengelola diri sendiri.

Kita hanya manusia; kita tidak bisa memperkirakan semua hal.

Apakah kamu pernah ada dalam situasi di mana kamu mengembangkan aplikasi yang besar dan makan waktu, dan setelah menghabiskan banyak waktu di depan layar menulis ribuan baris kode dan membaca artikel, tutorial, dan buku, kamu duduk melihat kode yang buruk (tapi bekerja dengan benar) dan berpikir, "Sekarang saya tahu bagaimana menulisnya lebih baik"? Saya pikir kita semua punya pengalaman seperti itu.

Ini adalah waktunya aturan ke-11 muncul. Kita memiliki tim developer yang bisa mengikuti prinsip Test Driven Development (TDD), di mana refactoring adalah bagian dari proses. Secara ajaib, perangkat lunak kita itu berguna, cantik, ditulis dengan baik, teruji, dan dibuat dengan cepat. Kita hanya manusia; kita tidak bisa memperkirakan semua hal.

Semua ini muncul dari ide tim yang mengelola diri sendiri, di mana setiap anggota memiliki peran, tidak diberikan atau dipaksakan, tapi yang muncul setelah sekian lama bekerja bersama-sama. Itu adalah keindahan dari kerjasama.


12 - Refleksi dan Penyesuaian

Secara rutin, tim development perlu melakukan refleksi tentang bagaimana untuk menjadi lebih efektif, dan menyesuaikan perilakunya sesuai kebutuhan.

Hal ini mungkin memerlukan beberapa siklus development, tapi tim akan bekerja secara harmonis. Bahkan menambahkan orang baru ke tim tidak akan merusak. Tim pengembang Agile fokus untuk menyelesaikan pekerjaan. Jika mereka bekerja dalam lingkungan yang bersahabat, mereka akan menemukan 'irama bekerja', dan kamu akan lihat seberapa cepat pengembangan perangkat lunak bisa dilakukan.


Beberapa Metodologi Pengembangan Agile

Ada beberapa metodologi yang diturunkan dan dibangun berdasarkan prisip Agile. Saya tidak akan menjelaskan semuanya karena masing-masing metodologi bisa memiliki artikel sendiri. Saya akan menyebutkan beberapa pendekatan Agile yang terkenal. Satu hal yang perlu diingat adalah tidak ada satu metodologi yang paling baik. Pilih salah satu yang cocok dengan kebutuhanmu, dan aturlah agar sesuai dengan kebutuhanmu.

SCRUM

Dibuat oleh Ken Schwaber dan Jeff Sutherland, SCRUM adalah kerangka kerja berbasis bisnis untuk mengelola proses pengembangan perangkat lunak. Ada banyak tipe SCRUM; ingatlah bahwa tujuan utamanya adalah untuk bekerja secara efektif dan efisien dan tidak hanya mengikuti aturan semata.

Extreme Programming (XP)

Dibuat oleh Kent Back, XP adalah daftar praktik terbaik yang bisa diikuti oleh developer saat membuat perangkat lunak. XP sering disebut sebagai ekstensi dari SCRUM. Metodologi berbasis developer ini lahir karena SCRUM terlalu berbasis bisnis.

Pengembangan Perangkat Lunak Lean

Dua prinsip utama Lean adalah: DALAP (Decide As Late As Possible) dan DAFAP (Deliver As Fast As Possible). Saya sarankan untuk membaca lebih banyak tentang metodologi ini, karena akan sangat berguna.

Ada beberapa metodologi lain di keluarga Agile; saya hanya menyebutkan beberapa pilihan populer. Jika kamu memutuskan untuk menggunakan Agile di proses pengembanganmu, kamu perlu tahu seperti apa metodologi ini, agar bisa memilih metodologi yang cocok untuk kamu.


Penutup

Apakah teknik Agile benar-benar bekerja?

Apakah teknik Agile benar-benar bekerja, dan apakah metodologi benar-benar seajaib yang orang-orang bilang? Tidak selalu.

Masalah yang saya hadapi di perusahaan-perusahaan, di mana metode Agile tidak hasilnya tidak baik (atau membuat berbagai hal lebih buruk), adalah metodologi yang dipilih dengan salah dan kurangnya keseriusan diantara penggunanya (anggota bisnis, tim pengembang, dan lain-lain). Karena itulah, pendapat penulis, kamu perlu memastikan semua yang terlibat dalam proses mengerti aturan dan mereka tahu bagaimana menjalankannya.

Terima kasih sudah membaca!

Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.