Agile modeling - Riwayat revisi

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

2026-08-23T14:08:28Z

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

← Revisi sebelumnya		Revisi per 23 Agustus 2026 14.08
Baris 1:		Baris 1:
	'''''Agile modelling'' (AM)''' adalah metodologi untuk pemodelan dan pendokumentasian sistem [[perangkat lunak]] berdasarkan praktik terbaik. Pengembangan ''Agile Modelling'' (AM) dipimpin oleh [[Scott Ambler]] dimulai pada [[musim gugur]] tahun [[2000]]. Awalnya disebut ''Extreme Modelling'' (XM) tetapi saran [[Robert Cecil Martin]] diubah namanya menjadi Agile Modelling pada [[musim semi]] [[2001]]. Buku Agile Modeling diterbitkan pada tahun 2002 oleh John Wiley Press. Ia juga memiliki situs web promosi.		'''''Agile modelling'' (AM)''' adalah metodologi untuk pemodelan dan pendokumentasian sistem [[perangkat lunak]] berdasarkan praktik terbaik. Pengembangan ''Agile Modelling'' (AM) dipimpin oleh [[Scott Ambler]] dimulai pada [[musim gugur]] tahun [[2000]]. Awalnya disebut ''Extreme Modelling'' (XM) tetapi saran [[Robert Cecil Martin]] diubah namanya menjadi Agile Modelling pada [[musim semi]] [[2001]]. Buku Agile Modeling <ref>Ambler, Scott. [http://worldcat.org/oclc/718657841 Agile modeling : effective practices for eXtreme programming and the unified process]. J. Wiley & Sons. 2009. ISBN 9780471202820.</ref> diterbitkan pada tahun 2002 oleh John Wiley Press. Ia juga memiliki situs web promosi.<ref>[http://www.AgileModeling.com/ The Agile Modeling Home Page].</ref>

	Ada banyak situasi di mana praktisi perangkat lunak harus membangun sistem yang besar dan ''business-critical''. Cakupan dan kompleksitas sistem tersebut harus dimodelkan sehingga semua konstituen dapat lebih memahami apa yang harus dicapai, masalah dapat dipartisi secara efektif di antara orang-orang yang harus menyelesaikannya, dan kualitas dapat dinilai saat sistem sedang direkayasa dan dibangun. Selama 30 tahun terakhir, berbagai macam metode pemodelan dan notasi [[rekayasa perangkat lunak]] telah diusulkan untuk analisis dan desain (baik tingkat arsitektur maupun komponen). Metode-metode ini pantas, tetapi terbukti sulit diterapkan dan menantang untuk dipertahankan (di banyak proyek). Bagian dari masalahnya adalah “bobot” atau ''"weight"'' dari metode pemodelan ini. Maksudnya adalah volume notasi yang diperlukan, tingkat formalisme yang disarankan, ukuran model untuk proyek-proyek besar, dan kesulitan dalam mempertahankan model saat terjadi perubahan. Namun pemodelan analisis dan desain memiliki manfaat besar untuk proyek-proyek besar, jika tidak ada alasan lain selain membuat proyek-proyek ini dapat dikelola secara intelektual.		Ada banyak situasi di mana praktisi perangkat lunak harus membangun sistem yang besar dan ''business-critical''. Cakupan dan kompleksitas sistem tersebut harus dimodelkan sehingga semua konstituen dapat lebih memahami apa yang harus dicapai, masalah dapat dipartisi secara efektif di antara orang-orang yang harus menyelesaikannya, dan kualitas dapat dinilai saat sistem sedang direkayasa dan dibangun. Selama 30 tahun terakhir, berbagai macam metode pemodelan dan notasi [[rekayasa perangkat lunak]] telah diusulkan untuk analisis dan desain (baik tingkat arsitektur maupun komponen). Metode-metode ini pantas, tetapi terbukti sulit diterapkan dan menantang untuk dipertahankan (di banyak proyek). Bagian dari masalahnya adalah “bobot” atau ''"weight"'' dari metode pemodelan ini. Maksudnya adalah volume notasi yang diperlukan, tingkat formalisme yang disarankan, ukuran model untuk proyek-proyek besar, dan kesulitan dalam mempertahankan model saat terjadi perubahan. Namun pemodelan analisis dan desain memiliki manfaat besar untuk proyek-proyek besar, jika tidak ada alasan lain selain membuat proyek-proyek ini dapat dikelola secara intelektual.<ref>Pressman, Roger S. [http://worldcat.org/oclc/949696534 Software engineering : a practitioner's approach]. McGraw-Hill Education. 2015. ISBN 9781259253157.</ref>

	Di situs resmi ''Agile Modelling,'' Scott Ambler menjelaskan ''Agile Modelling'' (AM) dengan cara berikut: "''Agile Modeling'' (AM) adalah metodologi berbasis praktik untuk pemodelan dan dokumentasi yang efektif dari sistem berbasis perangkat lunak. Sederhananya, ''Agile Modeling'' (AM) adalah kumpulan nilai, prinsip, dan praktik untuk pemodelan perangkat lunak yang dapat diterapkan pada proyek pengembangan perangkat lunak secara efektif dan ringan. Model ''agile'' lebih efektif daripada model tradisional karena mereka hampir tidak bagus, mereka tidak harus sempurna."		Di situs resmi ''Agile Modelling,'' Scott Ambler <ref>Ambler, S., “What Is Agile Modeling (AM)?” 2002, www.agilemodeling.com/index.htm.</ref> menjelaskan ''Agile Modelling'' (AM) dengan cara berikut: "''Agile Modeling'' (AM) adalah metodologi berbasis praktik untuk pemodelan dan dokumentasi yang efektif dari sistem berbasis perangkat lunak. Sederhananya, ''Agile Modeling'' (AM) adalah kumpulan nilai, prinsip, dan praktik untuk pemodelan perangkat lunak yang dapat diterapkan pada proyek pengembangan perangkat lunak secara efektif dan ringan. Model ''agile'' lebih efektif daripada model tradisional karena mereka hampir tidak bagus, mereka tidak harus sempurna."<ref>Pressman, Roger S. [http://worldcat.org/oclc/949696534 Software engineering : a practitioner's approach]. McGraw-Hill Education. 2015. ISBN 9781259253157.</ref>

	''Agile Modelling'' mengadopsi semua nilai yang konsisten dengan ''agile manifesto'' . Filosofi ''agile modeling'' menyadari bahwa tim ''agile'' harus memiliki keberanian untuk membuat keputusan yang dapat menyebabkannya sebuah desain ditolak dan di-''refactor.'' Tim juga harus memiliki kerendahan hati untuk mengakui bahwa teknolog tidak memiliki semua jawaban dan bahwa para pakar bisnis dan [[pemangku kepentingan]] lainnya harus dihormati dan dianut.		''Agile Modelling'' mengadopsi semua nilai yang konsisten dengan ''agile manifesto'' . Filosofi ''agile modeling'' menyadari bahwa tim ''agile'' harus memiliki keberanian untuk membuat keputusan yang dapat menyebabkannya sebuah desain ditolak dan di-''refactor.'' Tim juga harus memiliki kerendahan hati untuk mengakui bahwa teknolog tidak memiliki semua jawaban dan bahwa para pakar bisnis dan [[pemangku kepentingan]] lainnya harus dihormati dan dianut.<ref>Pressman, Roger S. [http://worldcat.org/oclc/949696534 Software engineering : a practitioner's approach]. McGraw-Hill Education. 2015. ISBN 9781259253157.</ref>

	== Prinsip ''Agile Modelling'' ==		== Prinsip ''Agile Modelling'' ==
	Meskipun ''Agile Modelling'' menyarankan beragam prinsip pemodelan ''“core”'' dan ''“supplementary”,'' yang membuat ''Agile Modelling'' menjadi unik adalah:		Meskipun ''Agile Modelling'' menyarankan beragam prinsip pemodelan ''“core”'' dan ''“supplementary”,'' yang membuat ''Agile Modelling'' menjadi unik adalah:<ref>Ambler, S., “What Is Agile Modeling (AM)?” 2002, www.agilemodeling.com/index.htm.</ref>

	'''''Model with purpose'''''		'''''Model with purpose'''''

	Pengembang yang menggunakan ''Agile Modelling'' harus memiliki tujuan spesifik (mis. Untuk mengomunikasikan informasi kepada pelanggan atau untuk membantu memahami lebih baik beberapa aspek perangkat lunak) sebelum mempertimbangkan membuat model. Setelah tujuan untuk model diidentifikasi, jenis notasi yang akan digunakan dan tingkat perincian yang diperlukan akan lebih jelas.		Pengembang yang menggunakan ''Agile Modelling'' harus memiliki tujuan spesifik (mis. Untuk mengomunikasikan informasi kepada pelanggan atau untuk membantu memahami lebih baik beberapa aspek perangkat lunak) sebelum mempertimbangkan membuat model. Setelah tujuan untuk model diidentifikasi, jenis notasi yang akan digunakan dan tingkat perincian yang diperlukan akan lebih jelas.<ref>Ambler, S., “What Is Agile Modeling (AM)?” 2002, www.agilemodeling.com/index.htm.</ref>

	'''''Use multiple models'''''		'''''Use multiple models'''''

	Ada banyak model dan notasi yang dapat digunakan untuk menggambarkan perangkat lunak. Hanya sebagian kecil yang penting untuk sebagian besar proyek. ''Agile Modelling'' menyarankan bahwa untuk memberikan wawasan yang diperlukan, setiap model harus menyajikan aspek yang berbeda dari sistem dan hanya model-model yang memberikan nilai kepada audiens yang dituju yang harus digunakan.		Ada banyak model dan notasi yang dapat digunakan untuk menggambarkan perangkat lunak. Hanya sebagian kecil yang penting untuk sebagian besar proyek. ''Agile Modelling'' menyarankan bahwa untuk memberikan wawasan yang diperlukan, setiap model harus menyajikan aspek yang berbeda dari sistem dan hanya model-model yang memberikan nilai kepada audiens yang dituju yang harus digunakan.<ref>Ambler, S., “What Is Agile Modeling (AM)?” 2002, www.agilemodeling.com/index.htm.</ref>

	'''''Travel Light'''''		'''''Travel Light'''''

	Saat pekerjaan rekayasa perangkat lunak berlangsung, simpan hanya modul yang akan memberikan nilai jangka panjang dan membuang sisanya. Setiap ''work product'' yang disimpan harus dipertahankan jika terjadi perubahan. Ini mewakili pekerjaan yang memperlambat tim. Ambler mencatat bahwa “Setiap kali Anda memutuskan untuk menjaga model, Anda menukar ketangkasan ''(agility)'' untuk kenyamanan memiliki informasi yang tersedia untuk tim Anda secara abstrak (sehingga berpotensi memperpanjang komunikasi di dalam tim Anda serta dengan pemangku kepentingan proyek)."		Saat pekerjaan rekayasa perangkat lunak berlangsung, simpan hanya modul yang akan memberikan nilai jangka panjang dan membuang sisanya. Setiap ''work product'' yang disimpan harus dipertahankan jika terjadi perubahan. Ini mewakili pekerjaan yang memperlambat tim. Ambler<ref>Ambler, S., “What Is Agile Modeling (AM)?” 2002, www.agilemodeling.com/index.htm.</ref> mencatat bahwa “Setiap kali Anda memutuskan untuk menjaga model, Anda menukar ketangkasan ''(agility)'' untuk kenyamanan memiliki informasi yang tersedia untuk tim Anda secara abstrak (sehingga berpotensi memperpanjang komunikasi di dalam tim Anda serta dengan pemangku kepentingan proyek)."<ref>Ambler, S., “What Is Agile Modeling (AM)?” 2002, www.agilemodeling.com/index.htm.</ref>

	'''''Content is more important than representation'''''		'''''Content is more important than representation'''''

	Pemodelan harus menyertakan informasi kepada audiens yang dituju. Model yang sempurna secara sintaksis, yang memberikan sedikit konten bermanfaat tidak sama berharganya dengan model dengan notasi yang cacat yang tetap menyediakan konten yang berharga bagi pemirsanya.		Pemodelan harus menyertakan informasi kepada audiens yang dituju. Model yang sempurna secara sintaksis, yang memberikan sedikit konten bermanfaat tidak sama berharganya dengan model dengan notasi yang cacat yang tetap menyediakan konten yang berharga bagi pemirsanya.<ref>Ambler, S., “What Is Agile Modeling (AM)?” 2002, www.agilemodeling.com/index.htm.</ref>

	'''''Know the models and the tools you use to create them'''''		'''''Know the models and the tools you use to create them'''''

	Pahami kekuatan dan kelemahan masing-masing model dan alat yang digunakan untuk membuatnya.		Pahami kekuatan dan kelemahan masing-masing model dan alat yang digunakan untuk membuatnya.<ref>Ambler, S., “What Is Agile Modeling (AM)?” 2002, www.agilemodeling.com/index.htm.</ref>

	'''''Adapt Locally'''''		'''''Adapt Locally'''''

	Pendekatan pemodelan harus disesuaikan dengan kebutuhan tim ''agile''''.''		Pendekatan pemodelan harus disesuaikan dengan kebutuhan tim ''agile''<ref>Ambler, S., “What Is Agile Modeling (AM)?” 2002, www.agilemodeling.com/index.htm.</ref>''.''

	Segmen utama dari komunitas rekayasa perangkat lunak telah mengadopsi ''[[Unified Modeling Language]]'' (UML) sebagai metode yang disukai untuk mewakili model analisis dan desain. ''[[Unified Process]]'' (UP) telah dikembangkan untuk menyediakan kerangka kerja untuk aplikasi UML. Scott Ambler telah mengembangkan versi sederhana dari UP yang mengintegrasikan filosofi pemodelan ''agile''-nya.		Segmen utama dari komunitas rekayasa perangkat lunak telah mengadopsi ''[[Unified Modeling Language]]'' (UML) sebagai metode yang disukai untuk mewakili model analisis dan desain. ''[[Unified Process]]'' (UP) telah dikembangkan untuk menyediakan kerangka kerja untuk aplikasi UML. Scott Ambler<ref>Ambler, S., “The Agile Unified Process (AUP), 2006, available at www.ambysoft.com/unifiedprocess/agileUP.html.</ref> telah mengembangkan versi sederhana dari UP yang mengintegrasikan filosofi pemodelan ''agile''-nya.<ref>Pressman, Roger S. [http://worldcat.org/oclc/949696534 Software engineering : a practitioner's approach]. McGraw-Hill Education. 2015. ISBN 9781259253157.</ref>

	== Kerangka Kerja (Framework) Populer ==		== Kerangka Kerja (Framework) Populer ==
Baris 40:		Baris 40:

	=== 1. Scrum ===		=== 1. Scrum ===
	[[Scrum]] adalah kerangka kerja yang paling populer, menggunakan siklus waktu tetap (biasanya 2–4 minggu) yang disebut '''Sprint'''. Scrum memiliki peran yang sangat spesifik seperti ''Product Owner'', ''Scrum Master'', dan ''Development Team''. Fokus utamanya adalah transparansi, inspeksi, dan adaptasi.		[[Scrum]] adalah kerangka kerja yang paling populer, menggunakan siklus waktu tetap (biasanya 2–4 minggu) yang disebut '''Sprint'''. Scrum memiliki peran yang sangat spesifik seperti ''Product Owner'', ''Scrum Master'', dan ''Development Team''. Fokus utamanya adalah transparansi, inspeksi, dan adaptasi.<ref>Ken Schwaber. [https://www.scirp.org/reference/referencespapers?referenceid=3975507 The Scrum Guide]. ''Report atau Generic Booklet''. 2020.</ref>

	=== 2. Kanban ===		=== 2. Kanban ===
Baris 46:		Baris 46:

	=== 3. Lean Software Development ===		=== 3. Lean Software Development ===
	Diadaptasi dari sistem produksi [[Toyota]], Lean bertujuan untuk menghilangkan hal yang tak diperlukan dalam proses pengembangan, seperti fitur yang tidak digunakan, penundaan, atau dokumentasi yang berlebihan.		Diadaptasi dari sistem produksi [[Toyota]], Lean bertujuan untuk menghilangkan hal yang tak diperlukan dalam proses pengembangan, seperti fitur yang tidak digunakan, penundaan, atau dokumentasi yang berlebihan.<ref>Mary Poppendieck. [https://archive.org/details/leansoftwaredeve0000mary Lean Software Development: An Agile Toolkit]. Addison-Wesley Professional. 2003. ISBN 978-0321150783.</ref>

	== Referensi ==		== Referensi ==
			<references />


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

	Konten artikel ini diadaptasi dari [https://id.wikipedia.org/w/index.php?title=Agile+modeling&oldid=29437375 Wikipedia bahasa Indonesia], revisi 29437375 (2026-07-09T21:51:06Z), 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=Agile+modeling&oldid=29437375 Wikipedia bahasa Indonesia], revisi 29437375 (2026-07-09T21:51:06Z), 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 -->

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

2026-08-23T13:48:22Z

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

Halaman baru

'''''Agile modelling'' (AM)''' adalah metodologi untuk pemodelan dan pendokumentasian sistem [[perangkat lunak]] berdasarkan praktik terbaik. Pengembangan ''Agile Modelling'' (AM) dipimpin oleh [[Scott Ambler]] dimulai pada [[musim gugur]] tahun [[2000]]. Awalnya disebut ''Extreme Modelling'' (XM) tetapi saran [[Robert Cecil Martin]] diubah namanya menjadi Agile Modelling pada [[musim semi]] [[2001]]. Buku Agile Modeling diterbitkan pada tahun 2002 oleh John Wiley Press. Ia juga memiliki situs web promosi.

Ada banyak situasi di mana praktisi perangkat lunak harus membangun sistem yang besar dan ''business-critical''. Cakupan dan kompleksitas sistem tersebut harus dimodelkan sehingga semua konstituen dapat lebih memahami apa yang harus dicapai, masalah dapat dipartisi secara efektif di antara orang-orang yang harus menyelesaikannya, dan kualitas dapat dinilai saat sistem sedang direkayasa dan dibangun. Selama 30 tahun terakhir, berbagai macam metode pemodelan dan notasi [[rekayasa perangkat lunak]] telah diusulkan untuk analisis dan desain (baik tingkat arsitektur maupun komponen). Metode-metode ini pantas, tetapi terbukti sulit diterapkan dan menantang untuk dipertahankan (di banyak proyek). Bagian dari masalahnya adalah “bobot” atau ''"weight"'' dari metode pemodelan ini. Maksudnya adalah volume notasi yang diperlukan, tingkat formalisme yang disarankan, ukuran model untuk proyek-proyek besar, dan kesulitan dalam mempertahankan model saat terjadi perubahan. Namun pemodelan analisis dan desain memiliki manfaat besar untuk proyek-proyek besar, jika tidak ada alasan lain selain membuat proyek-proyek ini dapat dikelola secara intelektual.

Di situs resmi ''Agile Modelling,'' Scott Ambler menjelaskan ''Agile Modelling'' (AM) dengan cara berikut: "''Agile Modeling'' (AM) adalah metodologi berbasis praktik untuk pemodelan dan dokumentasi yang efektif dari sistem berbasis perangkat lunak. Sederhananya, ''Agile Modeling'' (AM) adalah kumpulan nilai, prinsip, dan praktik untuk pemodelan perangkat lunak yang dapat diterapkan pada proyek pengembangan perangkat lunak secara efektif dan ringan. Model ''agile'' lebih efektif daripada model tradisional karena mereka hampir tidak bagus, mereka tidak harus sempurna."

''Agile Modelling'' mengadopsi semua nilai yang konsisten dengan ''agile manifesto'' . Filosofi ''agile modeling'' menyadari bahwa tim ''agile'' harus memiliki keberanian untuk membuat keputusan yang dapat menyebabkannya sebuah desain ditolak dan di-''refactor.'' Tim juga harus memiliki kerendahan hati untuk mengakui bahwa teknolog tidak memiliki semua jawaban dan bahwa para pakar bisnis dan [[pemangku kepentingan]] lainnya harus dihormati dan dianut.

== Prinsip ''Agile Modelling'' ==
Meskipun ''Agile Modelling'' menyarankan beragam prinsip pemodelan ''“core”'' dan ''“supplementary”,'' yang membuat ''Agile Modelling'' menjadi unik adalah:

'''''Model with purpose'''''

Pengembang yang menggunakan ''Agile Modelling'' harus memiliki tujuan spesifik (mis. Untuk mengomunikasikan informasi kepada pelanggan atau untuk membantu memahami lebih baik beberapa aspek perangkat lunak) sebelum mempertimbangkan membuat model. Setelah tujuan untuk model diidentifikasi, jenis notasi yang akan digunakan dan tingkat perincian yang diperlukan akan lebih jelas.

'''''Use multiple models'''''

Ada banyak model dan notasi yang dapat digunakan untuk menggambarkan perangkat lunak. Hanya sebagian kecil yang penting untuk sebagian besar proyek. ''Agile Modelling'' menyarankan bahwa untuk memberikan wawasan yang diperlukan, setiap model harus menyajikan aspek yang berbeda dari sistem dan hanya model-model yang memberikan nilai kepada audiens yang dituju yang harus digunakan.

'''''Travel Light'''''

Saat pekerjaan rekayasa perangkat lunak berlangsung, simpan hanya modul yang akan memberikan nilai jangka panjang dan membuang sisanya. Setiap ''work product'' yang disimpan harus dipertahankan jika terjadi perubahan. Ini mewakili pekerjaan yang memperlambat tim. Ambler mencatat bahwa “Setiap kali Anda memutuskan untuk menjaga model, Anda menukar ketangkasan ''(agility)'' untuk kenyamanan memiliki informasi yang tersedia untuk tim Anda secara abstrak (sehingga berpotensi memperpanjang komunikasi di dalam tim Anda serta dengan pemangku kepentingan proyek)."

'''''Content is more important than representation'''''

Pemodelan harus menyertakan informasi kepada audiens yang dituju. Model yang sempurna secara sintaksis, yang memberikan sedikit konten bermanfaat tidak sama berharganya dengan model dengan notasi yang cacat yang tetap menyediakan konten yang berharga bagi pemirsanya.

'''''Know the models and the tools you use to create them'''''

Pahami kekuatan dan kelemahan masing-masing model dan alat yang digunakan untuk membuatnya.

'''''Adapt Locally'''''

Pendekatan pemodelan harus disesuaikan dengan kebutuhan tim ''agile''''.''

Segmen utama dari komunitas rekayasa perangkat lunak telah mengadopsi ''[[Unified Modeling Language]]'' (UML) sebagai metode yang disukai untuk mewakili model analisis dan desain. ''[[Unified Process]]'' (UP) telah dikembangkan untuk menyediakan kerangka kerja untuk aplikasi UML. Scott Ambler telah mengembangkan versi sederhana dari UP yang mengintegrasikan filosofi pemodelan ''agile''-nya.

== Kerangka Kerja (Framework) Populer ==
Agile adalah sebuah payung besar yang menaungi berbagai metodologi spesifik. Beberapa yang paling banyak diadopsi meliputi:

=== 1. Scrum ===
[[Scrum]] adalah kerangka kerja yang paling populer, menggunakan siklus waktu tetap (biasanya 2–4 minggu) yang disebut '''Sprint'''. Scrum memiliki peran yang sangat spesifik seperti ''Product Owner'', ''Scrum Master'', dan ''Development Team''. Fokus utamanya adalah transparansi, inspeksi, dan adaptasi.

=== 2. Kanban ===
[[Kanban]] berfokus pada visualisasi aliran kerja menggunakan '''Kanban Board'''. Metode ini tidak memiliki batasan waktu seperti Scrum, melainkan berfokus pada pembatasan jumlah pekerjaan yang sedang berjalan (''Work in Progress'' atau WIP) untuk mengoptimalkan efisiensi dan kecepatan aliran.

=== 3. Lean Software Development ===
Diadaptasi dari sistem produksi [[Toyota]], Lean bertujuan untuk menghilangkan hal yang tak diperlukan dalam proses pengembangan, seperti fitur yang tidak digunakan, penundaan, atau dokumentasi yang berlebihan.

== Referensi ==

== Sumber dan atribusi ==

Konten artikel ini diadaptasi dari [https://id.wikipedia.org/w/index.php?title=Agile+modeling&oldid=29437375 Wikipedia bahasa Indonesia], revisi 29437375 (2026-07-09T21:51:06Z), yang tersedia berdasarkan lisensi Creative Commons Atribusi-BerbagiSerupa (CC BY-SA). Mohon gunakan konten ini secara bijak serta sesuai dengan ketentuan lisensi yang berlaku.