Agile Modeling adalah suatu proses yang berdasarkan praktek untuk memodelkan dan mendokumentasikan suatu sistem secara efektif. Agile Modeling juga dikatakan sebagai suatu kumpulan dari kebiasaan-kebiasaan berdasarkan beberapa nilai dan prinsip-prinsip teknik rekayasa perangkat lunak yang terpercaya.
Apa yang dimaksud dengan Agile Modeling (AM) ?
Agile Modeling adalah suatu metodologi yang praktis untuk proses dokumentasi dan pemodelan sistem perangkat lunak. Agile Modeling sendiri adalah kumpulan nilai-nilai, prinsip dan praktek-praktek untuk memodelkan perangkat lunak agar dapat diaplikasian pada proyek pengembangan perangkat lunak secara efektif dan efisien.
Prinsip dalam Agile Modeling antara lain :
Dengan menggunakan Agile Modeling, diharapkan tim pengembang (developer) dapat fokus pada prinsip dan praktek pemodelan yang efektif.
Gambar Hubungan antara model, dokumen, source code, dan dokumentasi dalam Agile Modelling
Dari sudut pandang agile modeling, dokumen adalah segala sesuatu yang bersifat eksternal dari source code yang tujuannya adalah untuk menyampaikan informasi secara persisten. Ini berbeda dari konsep model, yang merupakan abstraksi yang menggambarkan satu atau lebih aspek dari masalah atau solusi potensial dalam mengatasi masalah.
Beberapa model akan menjadi dokumen, meskipun lebih banyak yang akan dibuang begitu telah terpenuhi. Beberapa model akan digunakan untuk mendorong pengembangan source code, meskipun beberapa model mungkin hanya digunakan untuk mendorong pengembangan model lainnya.
Source code adalah urutan instruksi, termasuk komentar yang menggambarkan instruksi tersebut, untuk sistem komputer.
Meskipun source code jelas sebuah abstraksi, meskipun yang rinci, dalam lingkup agile modelingtidak akan dianggap sebagai model karena akan dibedakan dari konsepnya. Jadi dokumentasi meliputi dokumen dan komentar dalam source code (Ambler S. , 2002).
Eelco Gravendeel menyatakan bahwa hanya ada dua jenis dokumentasi dalam Agile (Hazrati, 2009), yaitu :
Dokumen yang diperlukan untuk semua anggota tim untuk bekerja pada proyek
Dalam dunia yang ideal, tim ini merelokasi dan semua pengetahuan akan dibagi dan diserahkan dengan komunikasi langsung. Namun, jika tim didistribusikan dan pengetahuan harus ditransfer kemudian menulis dokumen dan melengkapi dengan panggilan audio visual akan sangat berguna. Satu set dokumen minimal yang umum juga dibutuhkan oleh tim untuk berbicara bahasa macam-macam dan berada di level yang sama pemahaman. Eelco menyatakan bahwa banyak dokumen, yang dibuat untuk mendukung penciptaan produk, panggilan untuk perhatian lebih karena mereka dibuang segera setelah proyek selesai.
Dokumentasi untuk dikirim dengan produk akhir
Dokumen ini merupakan bagian dari pengiriman produk dan kelanjutan hubungan dengan klien yang baik. Contoh umum termasuk:
Gambar UML statechart yang menggambarkan siklus hidup agile modeling
Pada Gambar diatas dapat disimpulkan bahwa model tidak selalu dokumen. Banyak model bersifat sementara. Selain itu, dokumen tidak selalu model. Misalnya: kita tidak akan mempertimbangkan manual untuk menjadi model. Hal ini penting karena banyak orang percaya sebaliknya. Ketika mereka mendengar kata “model” mereka secara otomatis menerjemahkan ke “dokumen” dan semua konotasi negatif (meskipun jarang yang positif).
Konsep “model” dan "dokumen"adalah ortogonal karenakitajelas dapat memiliki satu tanpa yang lainnya.Penerimaan dari ide ini adalah langkah penting menuju menjadi lebih agile.
Kebutuhan Untuk Dokumentasi
Para pengembang agile mengakui bahwa dokumentasi merupakan bagian intrinsik dari sistem apapun. Ada 4 alasan yang sah untuk membuat dokumentasi (Ambler S. , 2002):
Stakeholder proyek atau pemilik produk memerlukannya.
Penciptaan dokumentasi merupakan sebuah keputusan bisnis yang fundamental, bukan pada hal teknis. Para pengembang perangkat lunak berinvestasi sumber daya dari stakeholder proyek dalam pengembangan dokumentasi, karena itu, mereka harus memiliki kata terakhir mengenai apakah uang mereka akan dikeluarkan atau tidak. Jika stakeholder proyek meminta dokumentasi dari pihak pengembang, mungkin pada saran pihak pengambang itu sendiri, dan memahami trade-off yang terlibat, maka pihak pengembang harus membuat dokumen.
Untuk menentukan model kontrak.
Kontrak merupakan persetujuan antara dua pihak yang tertulis dan dilaksanakan oleh hukum. Model Kontrak menentukan bagaimana sistem yang dikembangkan dan sistem eksternal berinteraksi satu sama lain(Jakob dkk, 2008). Beberapa interaksi dua arah, sedangkan yang lain adalah uni-directional, membuat interaksi secara eksplisit untuk semua orang yang terlibat. Model Kontrak sering diperlukan bila kelompok eksternal mengontrol sumber informasi bahwa sistem yang dikembangkan membutuhkan, seperti database, aplikasi warisan, atau layanan informasi.
Untuk mendukung komunikasi dengan anggota tim pada tempat yang berbeda.
Pengembang dalam tanggung jawabnya harus mengkomunikasikan requirements (Josef, 2007). Tidak mungkin untuk bekerja sama dengan tim pengembangan dan stakeholder proyek (atau setidaknya yang dibutuhkan pada saat itu) ada setiap saat. Bila pengembang perlu untuk bekerja dengan tim yang memiliki lokasi yang berbeda, pengembang perlu menemukan cara untuk berkomunikasi dengan mereka, dan dokumentasi sering menjadi bagian dari solusi(Fricker dkk, 2007).
Untuk menggunakan dokumentasi sebagai sarana utama komunikasi adalah sebuah kesalahan sebab terlalu mudah untuk terjadi kesalahpahaman tentang sesuatu yang telah ditulis, namun merupakan mekanisme pendukung yang baik. Cara yang baik untuk berpikir dokumentasi dalam situasi ini adalah bahwa hal itu merupakan pilihan terakhir.
Untuk memikirkan sesuatu yang lebih.
Banyak orang akan menulis dokumentasi untuk meningkatkan pemahaman mereka sendiri. Menulis, menempatkan ide-ide di atas kertas, dapat membantu anggota tim untuk memperkuat tim dan menemukan masalah dengan pemikirannya. Apa yang tampak jelas dalam pikiran sering menjadi sangat rumit setelah dicoba untuk menggambarkan secara rinci. Untuk itu, disarankan bahwa orang menulis komentar sebelum mereka menulis kode mereka.
Hal di atas tentu sangat berbeda dengan alasan yang selama ini digunakan untuk pembuatan dokumentasi. Developer sering dipaksa untuk membuat dokumentasi dengan tujuan yang tidak jelas demi untuk kepentingan politik, dan dokumen seperti ini biasanya dianggap sebagai dokumen yang tidak efektif karena hanya akan membuang waktu, tenaga dan biaya.
Adapun alasan-alasan yang tidak jelas untuk pembuatan dokumentasi serta cara untuk mengatasinya adalah sebagai berikut(Ambler S. W., 2001):
Pemohon ingin dilihat berada dalam kontrol.
Orang akan meminta dokumen, seperti spesifikasi dan dokumen arsitektur secara rinci agar mereka dapat menandatanganinya dan berkata. Setiap kali menemukan hal seperti dalam situasi ini maka katakan kepada invidu yang meminta dokumen tadi apakah mereka ingin dilihat sebagai orang bertanggung jawab atas kegagalan proyek karena tim pengembangan terlalu sibuk berfokus pada dokumentasi yang tidak perlu dan tidak pada perangkat lunak yang sedang dibangun. Saya kemudian akan menyarankan bahwa alih-alih meminta dokumentasi mereka malah harus meminta akses ke perangkat lunak itu sendiri, bahkan jika itu hanya sebuah rilis internal perangkat lunak, sehingga mereka dapat memberikan umpan balik konstruktif tentang hal itu. Mereka masih dapat dilihat untuk menjadi peserta aktif dalam proyek dan dapat melakukannya dengan cara yang produktif.
Pemohon keliru berpikir bahwa dokumentasi ada hubungannya dengan keberhasilan proyek.
Pemohon ingin membenarkan keberadaan mereka.
Ini biasanya terjadi ketika seseorang dalam organisasi yang tidak berguna lagi sangat ingin terlihat melakukan sesuatu. Hal ini merupakan bahaya yang terselubung karena pemohon sering memiliki sesuatu yang tampak pada permukaan untuk menjadi alasan yang baik untuk meminta dokumentasi, ini merupakan sesuatu yang telah mereka lakukan selama bertahun-tahun, dan manajemen sering berpendapat itu perlu. Untuk mengatasi masalah ini maka minta kepada pemohon apakah yang mereka inginkan dengan adanya dokumen, mengapa mereka memerlukannya, mengapa dengan penciptaan dokumentasi bagi mereka adalah lebih penting daripada pekerjaan lain, dan sebagainya untuk mencoba menentukan yang sebenarnya nilai apa yang mereka lakukan. Ini adalah pertanyaan yang valid untuk bertanya, meskipun yang tidak nyaman bagi seseorang yang tidak menambah nilai lebih kepada upaya pembangunan.
Pemohon tidak mengetahui yang lebih baik.
Banyak orang telah bekerja dalam organisasi yang telah mengikuti proses non-agile selama bertahun-tahun, proses yang berpusat pada dokumentasi, proses yang menghasilkan banyak dokumen untuk diperiksa dan akhirnya akan menghasilkan perangkat lunak. Hal ini yang terbiasa mereka lakukan sehingga mereka akan hanya meminta pengembang untuk sesuatu yang mereka sudah dapatkan di masa lalu. Gagasan bahwa pengembang dapat menghasilkan perangkat lunak di awal proyek, bahwa itu merupakan tujuan utama, adalah hal yang baru dan sering menjadi hal yang radikal bagi banyak orang.
Prosesnya yang mengatakan untuk membuat dokumen.
Meskipun bukan merupakan permasalahan dengan proses perangkat lunak agile, tapi hal seperti itu pasti dapat disatukan dengan proses perangkat lunak yang preskriptif. Alasan paling umum untuk masalah ini termasuk orang yang ingin membenarkan keberadaan mereka (lihat di atas), orang tidak memahami proses pengembangan perangkat lunak atau setidaknya implikasi dari apa yang mereka minta, dan situasi di mana tujuan utamanya adalah untuk mendapatkan bayaran untuk per jamnya sebagai lawan untuk mengembangkan perangkat lunak secara efektif. Strategi terbaik untuk mengatasi masalah ini adalah untuk menyelidiki apakah penciptaan dokumen benar-benar memberikan nilai pada usaha yang dilakukan.
Seseorang ingin kepastian bahwa semuanya baik-baik saja.
Stakeholder proyek menginvestasikan sumber daya yang penting dalam tim proyek, mereka mengambil risiko pada developer, dan mereka ingin tahu bahwa investasi mereka sedang dibelanjakan dengan baik. Untuk mendapatkan kepastian ini mereka akan meminta adanya dokumentasi, laporan status atau mungkin dokumen secaramenyeluruh, mereka tidak memahami bahwa perlu mengambil waktu untuk melakukannya dan hal itu jauh dari tujuan sejati yakni mengembangkan perangkat lunak.Dan mereka tidak menyadari bahwa permintaan yang lebih baik adalah melihat perangkat lunak itu sendiri (seperti yang ditunjukkan sebelumnya, mereka tidak tahu lebih baik). Developer harus mengenali kapan hal seperti ini terjadi, yaknijika pada awal proyek mereka tidak percaya tim pengembang, dan mencari cara alternatif untuk memberikan jaminan itu.
Anggota tim bekerja dengan tim yang lain.
Meskipun telah diidentifikasi Agile Modeling sepertinya tidak tepat dalam situasi ini. Dokumentasi adalah salah satu cara untuk berkomunikasi tetapi bukan cara terbaik. Sebaiknya temukan pendekatan alternatif, seperti pertemuan sesekali dengan kelompok lain atau penggunaan alat-alat kolaboratif, untuk mengurangi ketergantungan tim pada dokumentasi.
Dokumen kontrak pengembangan yang secara rutin digunakan kembali untuk kompetisi.
Masalah ini sering terjadi di perusahaan yang bekerja untuk instansi pemerintah, meskipun perusahaan tersebut mengancam kontraktor mereka dengan menempatkan proyek untuk tawaran lagi jika mereka tidak melakukannya. Jika tujuan utamanya adalah untuk mengembangkan perangkat lunak maka seharusnya pengembang fokus untuk melakukannya dan pengembang lebih mungkin untuk melakukan hal secukupnya untukpembuatan kontrak. Klien langsung dalam situasi ini sering beroperasi di bawah keyakinan yang sesat bahwa jika pengembang tidak melakukannya maka mereka dapat mengambil dokumentasi yang dibuat dan memberikan kepada kontraktor berikutnya yang akan mulai dari apa yang telah dikerjakan oleh pengembang sebelumnya. Hal ini berbatasan delusi menurut saya. Tapitidak peduli bagaimana pengembang melihatnya, kontraktor berikutnya sangat tidak mungkin untuk mengambil keuntungan dari dokumentasi yang dihasilkan tadi.
Pengembang Agile mengakui bahwa dokumentasi yang efektif adalah tindakan penyeimbangan, tujuannya adalah untuk hanya memiliki dokumentasi yang cukup pada waktu yang tepat dan hanya untuk audiens yang tepat dan juga merupakan tanggung jawab dari pengembang agile dalam hal ini adalah business analyst untuk melakukan dokumentasi (Josef, 2007).
Sumber : Lutfi Budi Ilmawan, Azhari SN, Pendekatan dokumentasi pada agile methods
