Untuk memberikan gambaran yang lebih rinci tentang proses agile, saya akan memaparkan Extreme Programming (XP), suatu pendekatan yang banyak digunakan dalam pengembangan perangkat lunak agile. Meskipun ide dan metode yang terkait dengan XP telah muncul pada akhir 1980-an, Kent Beck telah menulis secara ekstensif mengenai topik ini. Baru-baru ini, sebuah varian XP yang disebut Industrial XP (IXP) telah diajukan. IXP telah menyempurnakan XP dan dirancang untuk digunakan khusus dalam organisasi besar dengan proses yang lebih fleksibel.
1.1 XP Values
Sebuah seperangkat lima nilai yang menjadi dasar bagi seluruh pekerjaan yang dilakukan dalam XP telah didefinisikan oleh Beck. Nilai-nilai ini mencakup communication, simplicity, feedback, courage, dan respect, dan masing-masing nilai ini digunakan sebagai motivasi dalam aktivitas, tindakan, dan tugas XP yang spesifik.
XP menekankan pada kolaborasi yang erat namun tidak formal secara verbal untuk mencapai komunikasi yang efektif antara perekayasa perangkat lunak dan pemangku kepentingan lainnya, seperti untuk menetapkan fitur dan fungsi yang diperlukan untuk perangkat lunak. Selain itu, XP juga mendorong pembentukan metafora yang efektif untuk membantu mengkomunikasikan konsep-konsep penting, umpan balik yang berkelanjutan, dan menghindari penggunaan dokumentasi yang berlebihan sebagai media komunikasi.
XP membatasi pengembang dalam merancang hanya untuk kebutuhan yang mendesak dan tidak mempertimbangkan kebutuhan di masa depan untuk mencapai kesederhanaan. Hal ini dilakukan untuk menciptakan desain yang sederhana dan mudah diimplementasikan dalam kode. Jika ada kebutuhan untuk memperbaiki desain, hal tersebut dapat dilakukan dengan melakukan refaktorisasi di waktu yang lain.
XP memperoleh umpan balik dari tiga sumber, yaitu perangkat lunak yang telah diimplementasikan, pelanggan, dan anggota tim perangkat lunak lainnya. Untuk mendapatkan umpan balik dari perangkat lunak, XP merancang dan menerapkan strategi pengujian yang efektif dan menggunakan unit test sebagai taktik utama. Setiap kelas yang dikembangkan harus diuji menggunakan pengujian unit untuk memastikan bahwa operasi berjalan sesuai dengan fungsi yang telah ditentukan. Saat inkremen dikirim ke pelanggan, cerita pengguna atau kasus penggunaan yang diimplementasikan dalam inkremen tersebut digunakan sebagai dasar untuk pengujian penerimaan. Dalam hal ini, perangkat lunak diuji untuk melihat sejauh mana output, fungsi, dan perilaku use case telah diimplementasikan. Terakhir, karena persyaratan baru sering diturunkan sebagai bagian dari perencanaan berulang, tim memberikan umpan balik yang cepat kepada pelanggan mengenai dampak biaya dan jadwal yang terkait.
Menurut Beck, mengikuti praktik XP tertentu dengan ketat membutuhkan disiplin yang kuat. Meskipun ada tekanan untuk merancang kebutuhan masa depan, tim XP yang tangkas harus memiliki keberanian untuk merancang hanya untuk kebutuhan mendesak hari ini. Mereka harus sadar bahwa persyaratan di masa depan dapat berubah secara dramatis, sehingga menuntut perubahan desain dan kode yang substansial, dan disiplin diperlukan untuk menghindari kelebihan desain yang tidak perlu.
Tim tangkas akan membangun rasa hormat di antara semua anggota tim serta dengan pemangku kepentingan lainnya dan secara tidak langsung dengan perangkat lunak itu sendiri dengan mengikuti setiap nilai XP. Ketika tim berhasil meningkatkan kualitas perangkat lunak, mereka akan semakin mengembangkan rasa hormat terhadap proses XP.
1.2 The XP Process
XP adalah kerangka kerja pengembangan perangkat lunak yang menggunakan pendekatan berorientasi objek dan menerapkan seperangkat aturan dan praktik dalam empat aktivitas utama, yaitu: planning, design, coding, dan testing. Proses XP dijelaskan dan beberapa ide serta tugas utama yang terkait dengan setiap aktivitas juga dicatat dalam Gambar 1. Selain itu, aktivitas kunci dalam XP dirangkum dalam paragraf berikut.
Planning. Kegiatan perencanaan dalam Extreme Programming (XP) dimulai dengan kegiatan pengumpulan persyaratan yang disebut "planning game" yang memungkinkan anggota teknis dari tim XP untuk memahami konteks bisnis perangkat lunak dan kebutuhan fungsionalnya. Kegiatan ini melibatkan "listening" dari pelanggan dan menghasilkan satu set cerita pengguna yang menjelaskan fitur, fungsionalitas, dan keluaran yang diperlukan untuk perangkat lunak yang akan dibangun. Setiap cerita dinilai berdasarkan nilai bisnis keseluruhan dan diberi prioritas oleh pelanggan. Anggota tim XP menetapkan biaya dalam minggu pengembangan untuk setiap cerita. Jika cerita diperkirakan memerlukan lebih dari tiga minggu pengembangan, pelanggan diminta untuk membagi cerita menjadi beberapa cerita yang lebih kecil dan nilai dan biaya ditetapkan ulang. Hal penting yang perlu diingat adalah bahwa cerita baru dapat ditulis kapan saja.
Pelanggan dan pengembang bekerja sama untuk menentukan bagaimana cara mengelompokkan cerita ke dalam rilis berikutnya, yang merupakan peningkatan perangkat lunak berikutnya yang akan dikembangkan oleh tim XP. Setelah kesepakatan dasar tercapai, termasuk cerita yang akan disertakan, tanggal pengiriman, dan masalah proyek lainnya, tim XP memesan cerita yang akan dikembangkan menggunakan salah satu dari tiga pendekatan berikut: (1) semua cerita diterapkan segera dalam beberapa minggu, (2) cerita dengan nilai tertinggi diprioritaskan dan diterapkan terlebih dahulu, atau (3) cerita yang paling berisiko diprioritaskan dan diimplementasikan terlebih dahulu.
Setelah rilis awal proyek (juga disebut sebagai peningkatan perangkat lunak) selesai, tim XP mengukur kecepatan proyek. Dalam hal ini, kecepatan proyek diukur dengan jumlah cerita pelanggan yang telah diimplementasikan selama rilis pertama. Kecepatan proyek ini kemudian dapat digunakan untuk dua tujuan utama: (1) membantu memprediksi tanggal pengiriman dan jadwal rilis berikutnya, dan (2) mengevaluasi apakah terdapat overcommitment terhadap seluruh cerita di seluruh proyek pengembangan. Jika terjadi overcommitment, konten rilis mungkin harus diubah atau tanggal pengiriman harus diubah.
Selama proses pengembangan berlangsung, pelanggan berhak menambahkan cerita baru, memodifikasi nilai dari cerita yang telah ada, membagi cerita, atau bahkan menghilangkan cerita yang telah disepakati sebelumnya. Dalam hal ini, tim XP akan merevaluasi seluruh rencana rilis yang masih tersisa dan melakukan penyesuaian yang diperlukan.
Design. Desain dalam Extreme Programming (XP) selalu mengikuti prinsip "KIS" (Keep It Simple). Prinsip ini menekankan bahwa desain yang sederhana selalu lebih disukai daripada yang kompleks. Dalam XP, desain hanya memberikan panduan implementasi sesuai dengan apa yang ditulis dalam cerita, tidak kurang dan tidak lebih. Dalam hal desain fungsionalitas tambahan, hal ini tidak disarankan karena pengembang diharapkan hanya fokus pada fitur yang telah diminta oleh pelanggan.
XP menganjurkan penggunaan kartu CRC (Class-Responsibility-Collaborator) sebagai alat yang efektif untuk mempertimbangkan perangkat lunak dalam konteks berorientasi objek. Kartu CRC berfungsi untuk mengidentifikasi dan mengatur kelas yang relevan dalam konteks peningkatan perangkat lunak saat ini. Dalam latihan desain, tim XP menggunakan proses yang mirip dengan yang dijelaskan di Bab 8. Kartu CRC adalah satu-satunya hasil kerja desain yang dihasilkan dalam proses XP.
XP merekomendasikan membuat prototipe operasional segera jika terdapat masalah desain yang sulit diidentifikasi selama tahap perencanaan cerita. Solusi lonjakan, seperti yang disebut, memungkinkan pengembang untuk mengimplementasikan dan mengevaluasi bagian desain yang sulit secara langsung. Tujuan utamanya adalah untuk mengurangi risiko pada tahap implementasi dan memvalidasi estimasi awal untuk cerita yang memiliki masalah desain.
Sebelumnya, telah disebutkan bahwa XP mendorong teknik pemfaktoran ulang sebagai metode untuk mengoptimalkan desain konstruksi. Fowler memberikan penjelasan tentang pemfaktoran ulang sebagai berikut:
Proses refactoring adalah suatu cara untuk memodifikasi struktur internal dari sistem perangkat lunak dengan tujuan memperbaiki kode tanpa mengubah perilaku eksternalnya. Refactoring dilakukan dengan disiplin untuk membersihkan kode dan mengurangi kemungkinan munculnya bug. Refactoring dilakukan untuk meningkatkan desain kode setelah ditulis.
Desain dalam XP dianggap sebagai artefak sementara dan hampir tidak menggunakan notasi atau menghasilkan produk kerja selain kartu CRC dan solusi lonjakan. Oleh karena itu, desain harus terus dimodifikasi selama proses konstruksi. Refactoring dilakukan untuk mengontrol modifikasi ini dengan menyarankan perubahan desain kecil yang dapat secara drastis meningkatkan desain. Namun, perlu diingat bahwa upaya yang dibutuhkan untuk refactoring bisa tumbuh secara signifikan seiring bertambahnya ukuran aplikasi.
XP memandang bahwa desain perangkat lunak harus terjadi sebelum dan sesudah kode ditulis. Oleh karena itu, refactoring menjadi penting karena memungkinkan desain untuk terus ditingkatkan selama pembangunan sistem. Aktivitas pembangunan perangkat lunak dianggap sebagai panduan untuk meningkatkan desain dalam XP.
Coding. Tim XP tidak langsung memulai penulisan kode setelah cerita dan desain awal telah selesai dikembangkan, tetapi mereka membuat rangkaian tes unit untuk melatih setiap cerita yang akan dimasukkan dalam rilis yang akan datang. Dengan tes unit yang telah dibuat, pengembang dapat fokus pada implementasi fitur yang dibutuhkan untuk melewati tes unit tersebut, tanpa menambahkan fitur yang tidak perlu (tetap sederhana). Setelah kode selesai ditulis, pengembang dapat segera menguji kode tersebut dengan tes unit, sehingga memberikan umpan balik yang cepat kepada mereka.
Dalam kegiatan pengkodean, konsep utama yang diusung oleh XP adalah pair programming. XP merekomendasikan agar dua orang bekerja bersama di satu komputer workstation untuk menulis kode untuk sebuah cerita. Hal ini memungkinkan terjadinya pemecahan masalah secara waktu nyata (dua kepala seringkali lebih baik dari satu) serta jaminan kualitas waktu nyata (kode ditinjau saat dibuat). Selain itu, hal ini juga membuat pengembang fokus pada masalah yang sedang dihadapi. Dalam praktiknya, setiap orang memegang peran yang berbeda-beda. Contohnya, satu orang mungkin fokus pada detail pengkodean dari suatu bagian desain, sementara yang lain memastikan bahwa standar pengkodean (yang merupakan bagian integral dari XP) diikuti, atau bahwa kode cerita tersebut akan lolos dalam pengujian unit yang telah dikembangkan untuk memvalidasi kode terhadap cerita tersebut.
Setelah selesai bekerja, pasangan pemrogram akan mengintegrasikan kode yang mereka hasilkan dengan kode dari orang lain. Ada dua cara yang dapat dilakukan untuk integrasi: tim integrasi dapat melakukannya setiap hari atau pasangan pemrogram dapat melakukannya sendiri. Metode integrasi berkelanjutan seperti ini membantu menghindari masalah kompatibilitas dan antarmuka dan juga menyediakan lingkungan pengujian yang dapat mengungkap kesalahan lebih awal tentang "smoke testing".
Testing. Dalam pendekatan XP, pembuatan tes unit sebelum pengkodean dimulai dianggap sebagai elemen penting. Tes unit harus dikembangkan menggunakan kerangka kerja yang dapat diotomatisasi sehingga dapat dijalankan dengan mudah dan diulang berkali-kali. Pendekatan ini mendorong penerapan strategi pengujian regresi setiap kali kode dimodifikasi, yang merupakan filosofi refactoring XP.
Dalam pendekatan XP, tes unit yang dibuat harus diintegrasikan dalam universal testing suite yang memungkinkan pengujian integrasi dan validasi sistem dilakukan setiap hari. Dengan cara ini, tim XP dapat mengukur kemajuan secara terus-menerus dan menemukan masalah lebih awal sebelum terlambat. Wells menegaskan bahwa memperbaiki masalah secara teratur setiap beberapa jam memakan waktu lebih sedikit dibandingkan dengan menyelesaikan masalah besar tepat sebelum tenggat waktu.
Dalam XP, acceptance tests atau customer tests adalah jenis pengujian yang ditentukan oleh pelanggan dan berfokus pada fungsionalitas keseluruhan sistem yang dapat dilihat dan ditinjau oleh pelanggan. Tes ini disebut juga sebagai customer tests karena melibatkan partisipasi aktif dari pelanggan dalam menentukan kriteria dan skenario pengujian. Acceptance tests didasarkan pada cerita pengguna yang telah diimplementasikan sebagai bagian dari rilis perangkat lunak.
1.3 Industrial XP
Joshua Kerievsky menjelaskan Industrial Extreme Programming (IXP) sebagai berikut: “IXP adalah evolusi organik dari XP. Itu dijiwai dengan semangat XP yang minimalis, berpusat pada pelanggan, dan digerakkan oleh tes. IXP paling berbeda dari XP asli dalam penyertaan manajemennya yang lebih besar, perannya yang diperluas untuk pelanggan, dan praktik teknisnya yang ditingkatkan.” IXP menggabungkan enam praktik baru yang dirancang untuk membantu memastikan bahwa proyek XP bekerja dengan sukses untuk proyek penting dalam organisasi besar.
Readiness assessment. Sebelum memulai proyek IXP, organisasi harus melakukan evaluasi kesiapan terlebih dahulu. Evaluasi ini bertujuan untuk memastikan apakah (1) lingkungan pengembangan yang sesuai tersedia untuk mendukung IXP, (2) tim terdiri dari pemangku kepentingan yang tepat, (3) organisasi memiliki program kualitas yang berbeda dan mendukung perbaikan berkelanjutan, (4) budaya organisasi dapat mendukung nilai-nilai baru dari tim yang dinamis, dan (5) komunitas proyek yang lebih luas akan diisi dengan tepat.
Project community. Dalam XP klasik, disarankan untuk merekrut anggota yang tepat untuk membentuk tim yang tangkas agar dapat memastikan keberhasilan proyek. Hal ini menyiratkan bahwa anggota tim harus terlatih dengan baik, mampu beradaptasi, memiliki keterampilan yang sesuai, dan memiliki karakter yang cocok untuk berkontribusi dalam tim yang mandiri. Namun, ketika XP diterapkan pada proyek besar dalam organisasi, konsep "tim" harus diubah menjadi "komunitas". Komunitas mungkin terdiri dari seorang teknolog dan pelanggan yang menjadi pusat kesuksesan proyek, serta banyak pemangku kepentingan lainnya (misalnya staf hukum, auditor kualitas, jenis manufaktur atau penjualan) yang "sering berada di pinggiran proyek IXP namun mereka mungkin memainkan peran penting dalam proyek". Dalam IXP, anggota komunitas dan peran mereka harus didefinisikan dengan jelas, dan mekanisme komunikasi dan koordinasi antar anggota komunitas harus ditetapkan.
Project chartering. Parafrase tanpa plagiat dari kalimat tersebut adalah sebagai berikut: Tim IXP melakukan evaluasi pada proyek untuk mengevaluasi apakah terdapat justifikasi bisnis yang memadai untuk melaksanakan proyek tersebut dan apakah proyek tersebut sejalan dengan tujuan dan sasaran keseluruhan organisasi. Selain itu, tim juga mengevaluasi konteks proyek untuk menentukan cara-cara untuk menambah, memperluas, atau mengganti sistem atau proses yang sudah ada.
Test-driven management. Untuk proyek IXP, diperlukan suatu kriteria yang dapat diukur untuk mengevaluasi kondisi proyek dan kemajuan yang telah dicapai hingga saat ini. Dalam manajemen berbasis tes, ditetapkan serangkaian "tujuan" yang dapat diukur dan dilakukan penentuan mekanisme untuk menentukan apakah tujuan tersebut telah tercapai atau belum.
Retrospectives. Setelah pengiriman peningkatan perangkat lunak, tim IXP melakukan tinjauan teknis khusus yang disebut retrospektif. Tinjauan ini bertujuan untuk mengevaluasi "masalah, peristiwa, dan pelajaran yang diperoleh" dari semua peningkatan atau rilis perangkat lunak secara keseluruhan. Dengan melakukan retrospektif, tujuan tim IXP adalah untuk terus memperbaiki proses pengembangan perangkat lunak.
Continuous learning. Dalam XP, pengajaran merupakan bagian yang sangat penting dari upaya meningkatkan proses yang berkelanjutan. Sebagai motivasi, anggota tim XP didorong dan mungkin diberikan insentif untuk terus mempelajari teknik dan metode baru yang dapat membantu menghasilkan produk dengan kualitas yang lebih baik.
IXP melakukan beberapa modifikasi terhadap beberapa praktik XP yang sudah ada, selain dari enam praktik baru yang dibahas. SDD yang didorong oleh cerita menekankan penulisan cerita pengujian penerimaan sebelum satu baris kode pun ditulis. Dalam Domain-driven design (DDD), IXP meningkatkan konsep "system metaphor" yang digunakan dalam XP dengan menyarankan pembuatan model domain yang berkembang seiring waktu dan akurat dalam merepresentasikan cara para pakar domain berpikir tentang subjek mereka. IXP juga memperluas konsep pemrograman berpasangan XP dengan memasangkan manajer dan pemangku kepentingan lainnya untuk meningkatkan berbagi pengetahuan di antara anggota tim XP yang tidak terlibat langsung dalam pengembangan teknis. IXP juga menerapkan iterative usability untuk mencegah desain antarmuka yang front-loaded dan mendukung desain kegunaan yang terus berkembang seiring interaksi pengguna dengan perangkat lunak yang disampaikan.
IXP melakukan beberapa modifikasi kecil pada praktik XP yang sudah ada dan juga mendefinisikan ulang beberapa peran dan tanggung jawab agar lebih cocok untuk proyek-proyek besar di organisasi. Untuk informasi lebih lanjut mengenai IXP, silakan kunjungi http://industrialxp.org.
1.4 The XP Debate
Para peserta dalam diskusi yang membahas model dan metode proses baru, termasuk Extreme Programming, seringkali terlibat dalam diskusi yang bermanfaat atau bahkan perdebatan yang sengit. Menurut Stephens dan Rosenberg dalam sebuah buku yang meneliti efektivitas XP, banyak praktik XP yang berguna, meskipun ada beberapa praktik yang dilebih-lebihkan dan beberapa di antaranya memiliki masalah. Menurut mereka, sifat saling ketergantungan dari praktik XP adalah kekuatan dan kelemahan dari proses ini. Namun, karena banyak organisasi hanya mengadopsi sebagian dari praktik XP, maka kemanjuran seluruh proses menjadi lemah. Meskipun ada beberapa kritikus XP yang masih menghadapi masalah yang terus-menerus, para pendukungnya percaya bahwa XP terus berkembang dan banyak masalah yang diangkat oleh para kritikus telah diatasi ketika praktik XP semakin matang:
- Requirements volatility. Tim XP memasukkan pelanggan sebagai anggota tim aktif, sehingga perubahan persyaratan dapat diminta secara informal. Oleh karena itu, ada kemungkinan bahwa ruang lingkup proyek berubah dan pekerjaan sebelumnya harus dimodifikasi untuk memenuhi kebutuhan saat ini. Namun, para pendukung menganggap bahwa hal ini terjadi pada setiap proses dan XP telah memberikan mekanisme untuk mengendalikan perubahan ruang lingkup yang tidak terduga.
- Conflicting customer needs. Dalam banyak proyek, terdapat banyak pelanggan yang masing-masing memiliki kebutuhan yang berbeda. Namun, dalam XP, tim itu sendiri diberi tugas untuk memahami dan memenuhi kebutuhan pelanggan yang beragam, meskipun kadang-kadang pekerjaan tersebut mungkin berada di luar kewenangan mereka.
- Requirements are expressed informally. Dalam XP, user stories dan acceptance tests adalah satu-satunya cara yang jelas untuk mengekspresikan persyaratan. Beberapa kritikus menganggap bahwa model atau spesifikasi yang lebih formal dibutuhkan untuk memastikan kelengkapan, konsistensi, dan kesalahan ditemukan sebelum pembangunan sistem. Namun, pendukung XP berpendapat bahwa sifat persyaratan yang terus berubah membuat model dan spesifikasi seperti itu menjadi usang dengan cepat.
- Lack of formal design. XP menekankan pentingnya desain arsitektur dan memperlihatkan bahwa jenis desain yang relatif informal dapat digunakan dalam banyak kasus. Namun, kritikus berpendapat bahwa dalam pembangunan sistem yang kompleks, desain yang cermat harus ditekankan untuk memastikan kualitas dan kemudahan pemeliharaan dari keseluruhan struktur perangkat lunak. Di sisi lain, pendukung XP mengklaim bahwa proses inkremental yang digunakan dalam XP membatasi kompleksitas sistem (kesederhanaan adalah nilai inti) dan dengan demikian, mengurangi kebutuhan akan desain yang terlalu rumit.
Perlu dicatat bahwa setiap proses perangkat lunak memiliki kekurangan dan beberapa organisasi perangkat lunak telah berhasil mengadopsi XP. Hal yang penting adalah untuk mengenali area di mana suatu proses dapat memiliki kelemahan dan menyesuaikannya dengan kebutuhan unik organisasi Anda.
Source: Pressman, Roger S. 2010. Software engineering : A Practitioner’s Approach (7th. Edition). New York: McGraw-Hill Higher Education.
Comments
Post a Comment