Industrial XP: Perbedaan antara revisi
maraton |
(Tidak ada perbedaan)
|
Revisi per 31 Juli 2019 05.57
Industrial XP adalah evolusi organik dari Extreme Programming (XP). Hal tersebut diilhami oleh spirit Extrereme Programming yang minimalis, berpusat pada pelanggan, dan digerakkan oleh pengujian. Hal yang paling membedakan antara Extreme Programming dan IXP (Industrial Extreme Programming) adalah dalam inklusi manajemen yang lebih besar, perannya pelanggan yang diperluas, dan praktik teknisnya yang ditingkatkan[1]. IXP menggabungkan enam praktik baru yang dirancang untuk membantu memastikan bahwa proyek Extreme Programming bekerja dengan sukses untuk proyek-proyek penting dalam organisasi berskala besar organisasi[2].
Proses IXP
Penilaian kesiapan (Readiness Assessment)
Sebelum memulai proyek IXP, organisasi harus melakukan penilaian kesiapan. Penilaian tersebut dilakukan untuk memastikan (1) apakah terdapat lingkungan pengembangan yang tepat untuk mendukung IXP, (2) apakah tim akan diisi oleh pemangku kepentingan yang tepat, (3) apakah organisasi memiliki program kualitas yang berbeda dan mendukung peningkatan berkelanjutan, (4) apakah budaya organisasi akan mendukung nilai-nilai [2]baru dari agile team, dan (5) apakah komunitas proyek yang lebih luas akan diisi dengan tepat[2].
Komunitas proyek (Project Community)
Extreme Programming klasik menyarankan agar orang yang tepat digunakan untuk mengisi agile team untuk memastikan kesuksesan sebuah proyek. Implikasinya adalah bahwa orang-orang dalam tim harus terlatih, mudah beradaptasi, dan terampil, serta memiliki temperamen yang tepat untuk berkontribusi pada tim yang dapat mengatur diri sendiri. Ketika Extreme Programming akan diterapkan untuk proyek yang signifikan dalam organisasi besar, konsep "tim" harus berubah menjadi sebuah komunitas. Suatu komunitas mungkin memiliki teknologi dan pelanggan yang penting bagi keberhasilan suatu proyek serta banyak pemangku kepentingan lainnya (misalnya, staf hukum, auditor kualitas, tipe manufaktur atau penjualan) yang “sering berada di pinggiran proyek IXP namun mereka dapat memainkan peran penting dalam proyek ”[1]. Dalam IXP, anggota komunitas dan peran mereka harus didefinisikan secara eksplisit dan mekanisme untuk komunikasi dan koordinasi antara anggota komunitas harus dibentuk[2].
Pemborongan Proyek (Project Chartering)
Tim IXP menilai proyek itu sendiri untuk menentukan apakah ada justifikasi bisnis yang sesuai untuk proyek tersebut dan apakah proyek akan memajukan tujuan (goal) dan sasaran (objective) keseluruhan organisasi. Pemborongan juga dapat memeriksa konteks proyek untuk menentukan bagaimana ia melengkapi, memperluas, atau mengganti sistem atau proses yang ada[2].
Manajemen Berbasis Pengujian (Test-driven Management)
Proyek IXP membutuhkan kriteria yang terukur untuk menilai keadaan proyek dan kemajuan yang telah dibuat hingga saat ini. Manajemen yang digerakkan oleh pengujian menetapkan serangkaian “destination” yang terukur [1] dan kemudian mendefinisikan mekanisme untuk menentukan apakah tujuan-tujuan ini telah tercapai atau tidak[2].
Retrospektif (Retrospective)
Tim IXP melakukan tinjauan teknis khusus setelah software increment disampaikan. Disebut retrospektif, karena tinjauan ini meneliti "masalah (issue), peristiwa (event), dan pelajaran yang didapat (lessons-learned)"[1] di seluruh software increment dan / atau seluruh rilis perangkat lunak. Tujuannya adalah untuk meningkatkan proses IXP[2].
Pembelajaran Berkelanjutan (Continues Learning)
Karena pembelajaran adalah bagian penting dari peningkatan proses yang berkelanjutan, anggota tim XP didorong (dan mungkin, diberi insentif) untuk mempelajari metode dan teknik baru yang dapat menghasilkan produk berkualitas lebih tinggi.
Selain enam praktik baru yang dibahas, IXP memodifikasi sejumlah praktik XP yang ada. Story-driven development (SDD) menegaskan bahwa stories untuk acceptance test ditulis sebelum satu baris kode dihasilkan. Domain-driven design (DDD) adalah peningkatan pada konsep "system metaphor" yang digunakan di XP. DDD[3] menyarankan penciptaan evolusioner dari model domain yang secara akurat mewakili bagaimana para ahli domain berpikir tentang subjek mereka[1]. Pairing memperluas konsep pemrograman berpasangan XP untuk memasukkan manajer dan pemangku kepentingan lainnya. Tujuannya adalah untuk meningkatkan berbagi pengetahuan di antara anggota tim XP yang mungkin tidak terlibat langsung dalam pengembangan teknis. Iterative usability menghambat desain antar muka yang dimuat dalam mendukung desain kegunaan yang berkembang sebagai peningkatan perangkat lunak disampaikan dan interaksi pengguna dengan perangkat lunak dipelajari. IXP membuat modifikasi yang lebih kecil untuk praktik XP lainnya dan mendefinisikan kembali peran dan tanggung jawab tertentu untuk membuatnya lebih dapat menerima proyek signifikan untuk organisasi besar[2].
Referensi
- ^ a b c d e Kerievsky, J., Industrial XP: Making XP Work in Large Organizations, Cutter Consortium, Executive Report, vol. 6., no. 2, 2005, available at www.cutter.com/content-and-analysis/ resource-centers/agile-project-management/sample-our-research/apmr0502.html.
- ^ a b c d e f g h Pressman, Roger S. (2015). Software engineering : a practitioner's approach. McGraw-Hill Education. ISBN 9781259253157. OCLC 949696534.
- ^ Evans, E., Domain Driven Design, Addison-Wesley, 2003