Industrial XP - Riwayat revisi

Maintenance script: Presentation V4: sitasi, referensi, Math, Wikimedia Commons, dan atribusi

2026-08-23T22:55:22Z

Presentation V4: sitasi, referensi, Math, Wikimedia Commons, dan atribusi

Maintenance script: Impor teks terkontrol dari Wikipedia bahasa Indonesia; revisi 28478007; atribusi sumber disertakan.

2026-08-23T22:17:01Z

Impor teks terkontrol dari Wikipedia bahasa Indonesia; revisi 28478007; atribusi sumber disertakan.

Halaman baru

'''''Industrial'' XP''' adalah evolusi organik dari [[Extreme programming|''Extreme Programming'' (XP)]]. Hal tersebut diilhami oleh spirit ''Extreme Programming'' yang minimalis, berpusat pada pelanggan, dan digerakkan oleh [[Pengujian perangkat lunak|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. 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.

== 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 baru dari ''agile team'', dan (5) apakah [[komunitas]] proyek yang lebih luas akan diisi dengan tepat.

=== 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 tetapi mereka dapat memainkan peran penting dalam proyek ”. Dalam IXP, anggota komunitas dan peran mereka harus didefinisikan secara eksplisit dan mekanisme untuk komunikasi dan koordinasi antara anggota komunitas harus dibentuk.

=== 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.

=== 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 dan kemudian mendefinisikan mekanisme untuk menentukan apakah tujuan-tujuan ini telah tercapai atau tidak.

=== 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)''" di seluruh ''software increment'' dan / atau seluruh rilis perangkat lunak. Tujuannya adalah untuk meningkatkan proses IXP.

=== 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 menyarankan penciptaan evolusioner dari model domain yang secara akurat mewakili bagaimana para ahli domain berpikir tentang subjek mereka. ''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.

== Sumber dan atribusi ==

Konten artikel ini diadaptasi dari [https://id.wikipedia.org/w/index.php?title=Industrial+XP&oldid=28478007 Wikipedia bahasa Indonesia], revisi 28478007 (2025-11-14T05:57:57Z), yang tersedia berdasarkan lisensi Creative Commons Atribusi-BerbagiSerupa (CC BY-SA). Mohon gunakan konten ini secara bijak serta sesuai dengan ketentuan lisensi yang berlaku.

← Revisi sebelumnya		Revisi per 23 Agustus 2026 22.55
Baris 1:		Baris 1:
	'''''Industrial'' XP''' adalah evolusi organik dari [[Extreme programming\|''Extreme Programming'' (XP)]]. Hal tersebut diilhami oleh spirit ''Extreme Programming'' yang minimalis, berpusat pada pelanggan, dan digerakkan oleh [[Pengujian perangkat lunak\|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. 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.		'''''Industrial'' XP''' adalah evolusi organik dari [[Extreme programming\|''Extreme Programming'' (XP)]]. Hal tersebut diilhami oleh spirit ''Extreme Programming'' yang minimalis, berpusat pada pelanggan, dan digerakkan oleh [[Pengujian perangkat lunak\|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.<ref>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.</ref> 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.<ref>Pressman, Roger S. [http://worldcat.org/oclc/949696534 Software engineering : a practitioner's approach]. McGraw-Hill Education. 2015. ISBN 9781259253157.</ref>

	== Proses IXP ==		== Proses IXP ==

	=== Penilaian kesiapan ''(Readiness Assessment)'' ===		=== 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 baru dari ''agile team'', dan (5) apakah [[komunitas]] proyek yang lebih luas akan diisi dengan tepat.		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 <ref>Pressman, Roger S. [http://worldcat.org/oclc/949696534 Software engineering : a practitioner's approach]. McGraw-Hill Education. 2015. ISBN 9781259253157.</ref>baru dari ''agile team'', dan (5) apakah [[komunitas]] proyek yang lebih luas akan diisi dengan tepat.<ref>Pressman, Roger S. [http://worldcat.org/oclc/949696534 Software engineering : a practitioner's approach]. McGraw-Hill Education. 2015. ISBN 9781259253157.</ref>

	=== Komunitas proyek ''(Project Community)'' ===		=== 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 tetapi mereka dapat memainkan peran penting dalam proyek ”. Dalam IXP, anggota komunitas dan peran mereka harus didefinisikan secara eksplisit dan mekanisme untuk komunikasi dan koordinasi antara anggota komunitas harus dibentuk.		''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 tetapi mereka dapat memainkan peran penting dalam proyek ”.<ref>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.</ref> Dalam IXP, anggota komunitas dan peran mereka harus didefinisikan secara eksplisit dan mekanisme untuk komunikasi dan koordinasi antara anggota komunitas harus dibentuk.<ref>Pressman, Roger S. [http://worldcat.org/oclc/949696534 Software engineering : a practitioner's approach]. McGraw-Hill Education. 2015. ISBN 9781259253157.</ref>

	=== Pemborongan Proyek ''(Project Chartering)'' ===		=== 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.		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.<ref>Pressman, Roger S. [http://worldcat.org/oclc/949696534 Software engineering : a practitioner's approach]. McGraw-Hill Education. 2015. ISBN 9781259253157.</ref>

	=== Manajemen Berbasis Pengujian ''(Test-driven Management)'' ===		=== 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 dan kemudian mendefinisikan mekanisme untuk menentukan apakah tujuan-tujuan ini telah tercapai atau tidak.		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 <ref>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.</ref> dan kemudian mendefinisikan mekanisme untuk menentukan apakah tujuan-tujuan ini telah tercapai atau tidak.<ref>Pressman, Roger S. [http://worldcat.org/oclc/949696534 Software engineering : a practitioner's approach]. McGraw-Hill Education. 2015. ISBN 9781259253157.</ref>

	=== Retrospektif ''(Retrospective)'' ===		=== 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)''" di seluruh ''software increment'' dan / atau seluruh rilis perangkat lunak. Tujuannya adalah untuk meningkatkan proses IXP.		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)''"<ref>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.</ref> di seluruh ''software increment'' dan / atau seluruh rilis perangkat lunak. Tujuannya adalah untuk meningkatkan proses IXP.<ref>Pressman, Roger S. [http://worldcat.org/oclc/949696534 Software engineering : a practitioner's approach]. McGraw-Hill Education. 2015. ISBN 9781259253157.</ref>

	=== Pembelajaran Berkelanjutan ''(Continues Learning)'' ===		=== 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.		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 menyarankan penciptaan evolusioner dari model domain yang secara akurat mewakili bagaimana para ahli domain berpikir tentang subjek mereka. ''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.		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<ref>Evans, E., ''Domain Driven Design'', Addison-Wesley, 2003</ref> menyarankan penciptaan evolusioner dari model domain yang secara akurat mewakili bagaimana para ahli domain berpikir tentang subjek mereka.<ref>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.</ref> ''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.<ref>Pressman, Roger S. [http://worldcat.org/oclc/949696534 Software engineering : a practitioner's approach]. McGraw-Hill Education. 2015. ISBN 9781259253157.</ref>


			== Referensi ==
			<references />

	== Sumber dan atribusi ==		== Sumber dan atribusi ==

	Konten artikel ini diadaptasi dari [https://id.wikipedia.org/w/index.php?title=Industrial+XP&oldid=28478007 Wikipedia bahasa Indonesia], revisi 28478007 (2025-11-14T05:57:57Z), yang tersedia berdasarkan lisensi Creative Commons Atribusi-BerbagiSerupa (CC BY-SA). Mohon gunakan konten ini secara bijak serta sesuai dengan ketentuan lisensi yang berlaku.		Konten artikel ini diadaptasi dari [https://id.wikipedia.org/w/index.php?title=Industrial+XP&oldid=28478007 Wikipedia bahasa Indonesia], revisi 28478007 (2025-11-14T05:57:57Z), yang tersedia berdasarkan lisensi Creative Commons Atribusi-BerbagiSerupa (CC BY-SA). Mohon gunakan konten ini secara bijak serta sesuai dengan ketentuan lisensi yang berlaku.

			<!-- WIKI_UNISSULA_PRESENTATION_V4 -->