PENDEKATAN DOKUMENTASI PADA AGILE METHODS Lutfi Budi Ilmawan1, Azhari SN2 Jurusan Ilmu Komputer, Fakultas MIPA, Universitas Gadjah Mada e-mail:
[email protected],
[email protected]
1,2
Abstract
At this time the method of software development has been growing rapidly. The method has been switched to a simpler method with emphasis on the flexibility of the changes that occur during the process of development, the method is called the agile methods. Any software development method should have the documentation as a reference for the future of software development. But in agile methods, Working software over comprehensive documentation. It has been observed through literature that good documentation plays a very important role in software development. It helps in increasing development speed and also helps in communication and maintaining relationship among developers and other stakeholders. So many software developers who do not want to switch to agile methods on because they think that the agile methods are not too concerned with documentation, but this perception is not necessarily true because the agile manifesto as merely a preference, not a requirement. In this paper will be discussed about the documentation of agile methods, how and when documentation is needed. Keywords: agile methods, stakeholder, developer PENDAHULUAN Perkembangan dalam metode pengembangan perangkat lunak saat ini telah mengalami banyak perubahan untuk menutupi kelemahan dari metode-metode sebelumnya. Jika kita melihat ke belakang, metode yang digunakan tidak mampu menangani kemungkinan perubahan atau penambahan requirement pada saat proses pengembangan perangkat lunak berlangsung. Hal inilah yang menjadi pendorong munculnya metode baru dalam pengembangan perangkat lunak. Untuk menangani kelemahan tersebut diperkenalkan metode baru pada dekade 90-an, yakni agile methods (Widodo & Subekti, 2006). Saat ini hasil dari perkembangan dari agile methods sudah cukup banyak, diantaranya: 1. eXtreme Programming 2. Scrum Methodology 3. Crystal Family 4. Dynamic System Development Method 5. Adaptive Software Development 6. Feature Driven Development Arti kata agile sendiri berarti tangkas, cepat, atau ringan. Agility merupakan metode yang ringan dan cepat dalam pengembangan perangkat lunak(Widodo & Subekti, 2006). Agile Alliance mendefinisikan 12 prinsip untuk mencapai proses yang termasuk dalam agility: 1. Prioritas tertinggi adalah memuaskan pelanggan melalui penyerahan awal dan berkelanjutan perangkat lunak yang bernilai. 2. Menerima perubahan requirements meskipun perubahan tersebut diminta pada akhir pengembangan(Turk dkk, 2004). 3. Memberikan perangkat lunak yang sedang dikerjakan dengan sering, beberapa minggu atau beberapa bulan, dengan pilihan waktu yang paling singkat. 4. Pihak bisnis dan pengembang harus bekerja sama setiap hari selama pengembangan berjalan.
5. Bangun proyek dengan individu-individu yang bermotivasi tinggi dengan memberikan lingkungan dan dukungan yang diperlukan, dan mempercayai mereka sepenuhnya untuk menyelesaikan pekerjaannya. 6. Metode yang paling efektif dan efisien dalam menyampaikan informasi kepada tim pengembangan adalah dengan komunikasi langsung face-to-face(Turk dkk, 2004). 7. Perangkat lunak yang dikerjakan merupakan pengukur utama kemajuan. 8. Proses agile memberikan proses pengembangan yang bisa ditopang. Sponsor, pengembang, dan user harus bisa menjaga ke-konstanan langkah yang tidak pasti. 9. Perhatian yang terus menerus terhadap rancangan dan teknik yang baik meningkatkan agility. 10. Kesederhanaan –seni untuk meminimalkan jumlah pekerjaan– adalah penting. 11. Arsitektur, requirements, dan rancangan terbaik muncul dari tim yang mengatur sendiri(Ashima & Aggarwal, 2010). 12. Pada interval reguler tertentu, tim merefleksikan bagaimana menjadi lebih efektif, kemudian menyesuaikannya(Kniberg, 2007). Metode yang berkembang telah beralih ke metode yang lebih sederhana dengan mengutamakan fleksibilitasdan dengan lingkungan yang cepat berubah-ubah (Nasution & Weistroffer, 2009). Metode agile yang sering digunakan adalah metodeextreme programming danscrum. Extreme programming didasarkan pada planning game dan panduan dalam pengkodean program (Bostrom dkk, 2006). Pendekatan dengan scrum telah dikembangkan untuk mengelola proses pengembangan perangkat lunak di lingkungan yang berubah-ubah berdasarkan fleksibiltas, kemampuan beradaptasi, dan produktivitas (Abrahamsson, 2003).Scrum adalah sebuah proses kerangka kerja yang disusun untuk menunjang pengembangan produk yang kompleks. Scrum terdiri dari tim scrum beserta peran-peran yang diperlukan, acara, artefak dan aturan main. Setiap komponen di dalam kerangka kerja ini memiliki tujuan tertentu dan peran penting terhadap keberhasilan dari jalannya proses Scrum (Schwaber & Sutherland, 2011). Scrum fokus ke praktek manajement dan organisasi sedangkan XP sebagian besar fokus kepada praktek pemrograman. Oleh karena itulah keduanya bisa digabungkan dengan baik, karena keduanya mengatasi area yang berbeda dan saling melengkapi (Kniberg, 2007). Subjek dari metode agile dan dokumentasi perangkat lunak terus menjadi isu sensitif dan pusat dari banyak kontroversi. Hal ini didorong oleh filosofi bahwa metode agile sangat berbeda dari metode tradisional. Dan memang metode agile berbeda dari metode tradisional. Kita tahu metode agile berbeda dari Metode Tradisional, karena pencipta metode agile mengatakan begitu(Rico, 2008). Mari kita memeriksa agile manifesto, yang menyatakan dengan tegas bahwa empat nilai utama dari metode agile adalah: 1. Individu dan interaksi lebih dari proses dan sarana perangkat lunak. 2. Perangkat lunak yang bekerja lebih dari dokumentasi yang menyeluruh 3. Kolaborasi dengan klien lebih dari negosiasi kontrak 4. Tanggap terhadap perubahan lebih dari mengikuti rencana. Nilai kedua dari manifesto agile tampaknya bukan hanya menjadi duridisisi metode agile, tapi juga merupakan pendukung darimetode tradisional. Alasan untuk perpecahan ini yang membagi komunitas metode agile dan tradisional.Tradisionalis khususnya, karena dokumentasi perangkat lunak menyeluruh adalah salah satu nilai dasar yang baik dari
metode tradisional(Rico, 2008). Pendukung metode tradisional mengklaim bahwa dokumentasi perangkat lunak yang baik merupakan hal terpenting dalam siklus hidup dari metodetradisional, persyaratan dan desain, kualitas perangkat lunak, dan pemeliharaan perangkat lunak. Jadi tanpa dokumentasi perangkat lunak yang baik, perangkat lunak tidak dapat ditentukan, dirancang, atau dipertahankan, dan pada akhirnya menghasilkan kualitas perangkat lunak yang rendah. Untuk memperburuk situasi, pencipta metode agilemembuat kebalikan dari apa yang biasa atau diterima dari kebijaksanaan konvensional lama dengan mendefinisikan nilai yang mengatakan bahwa "perangkat lunak bekerja lebih dari dokumentasi yang komprehensif." Oleh karena itu, dalam pikiran tradisionalis, metode agile merupakan metode yang tidak benar, sesat, dan tidak lebih dari hacking yang sederhana. Kebanyakan pihak memiliki persepsi bahwa dalam metode agile, dokumentasi tidak terlalu dipentingkan sehingga banyak organisasi pengembang IT yang tidak ingin untuk beralih ke metode agile. Sebab telah diamati melalui literatur bahwa dokumentasi yang baik memainkan peran yang sangat penting dalam pengembangan perangkat lunak. Ini membantu dalam meningkatkan kecepatan pengembangan dan juga membantu dalam mmpertahankan komunikasi dan hubungan di antara para developer dan stakeholder lainnya(Uikey dkk, 2011).Namun persepsi yang mengatakan bahwa dalam metode agile tidak terlalu mementingkan dokumentasi belum tentu benar sebabagile manifesto sifatnya lebih ke preferensi, bukan keharusan atau mandat. Sedangkan dalam scrum sendiri, penggunaan kerangka kerjanya sangat beragam (Schwaber & Sutherland, 2011). Jadi selama dokumentasi itu memiliki nilai, maka dokumentasi tersebut harus dibuat. Jadi sering terjadi kesalahpahaman dari pemahaman terhadap metode agile. Beberapa mitos umum tentang agile adalah(Kar, 2006): 1. Agile hanya untuk perusahaan yang kecil atau yang berukuran sedang. Hal ini merupakan pemikiran yang salah karena agile bukan merupakan fungsi (function) dari ukuran sebuah perusahaan. Agile dapat menangani mulai dari perusahaan yang kecil sampai perusahaan yang berukuran sangat besar. 2. Agile berarti proses yang “ringan” artinya merupakan metode yang tidak tersturktur dengan dokumentasi yang sedikit atau tanpa dokumentasi. Hal ini tidak benar karena, ringan di sini berarti kemampuan proses untuk beradaptasi dengan perubahan. Metodologi agile berusaha untuk menggunakan dokumentasi seminimal mungkin. Penekanan terhadap dokumentasi hanya dilakukan saat dokumentasi pada kasusnya itu dianggap penting dan tidak mencampur adukkan dengan dokumentasi yang tidak relevan. DOKUMENTASI AGILE METHOD Ketika pertama kali bekerja dengan Agile Modeling, diharapkan agar dapat terfokus pada prinsip dan praktek untuk pemodelan yang efektif, tapi segera disadari bahwa ruang lingkup ini tidak cukup. Perlu mempertimbangkan bagaimana penciptaan dan pemeliharaan dokumentasi menjadi efektif. Beberapa model agile akan berkembang ke dalam dokumentasi pada system yang resmi, meskipun sebagian besar tida, dan oleh karena itu relevan untuk membahas bagaimana menjadi agile dalam melakukannya. Hubungan antara model, dokumen, source code, dan dokumentasi, seperti yang tampak pada gambar di bawah. 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).
Gambar 1 Hubungan antara model, dokumen, source code, dan dokumentasi Eelco Gravendeel menyatakan bahwa hanya ada dua jenis dokumentasi dalam Agile(Hazrati, 2009): 1. 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. 2. Dokumentasi untuk dikirim dengan produk akhir - Adalah dokumen yang merupakan bagian dari pengiriman produk dan kelanjutan hubungan dengan klien yang baik. Contoh umum termasuk: a. User manual b. Deployment manual c. Pemeliharaan manual (ditujukan untuk mengoperasikan perangkat lunak) d. Teknis dokumentasi (ditujukan untuk menjaga basis kode), dll
Model Belum Tentu Dokumen
Gambar 2 Sebuah UML statechart yang menggambarkan siklus hidup agile modeling Implikasi dari Gambar 2 adalah bahwa model tidak selalu dokumen.Banyak model bersifat sementara padadasarnya. 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): 1. Stakeholder proyek atau pemilik produk memerlukannya(SAP, 2007). 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. 2. 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. 3. 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. 4. 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): 1. 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. 2. Pemohon keliru berpikir bahwa dokumentasi ada hubungannya dengan keberhasilan proyek. 3. 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. 4. Pemohon tidak mengetahui yang lebih baik. Banyak orang telah bekerja dalam organisasi yang telah mengikuti prosesnon-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.
5. Prosesnya yang mengatakan untuk membuat dokumen. Meskipun bukanmerupakan permasalahan dengan proses perangkat lunak agile, tapihal 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. 6. 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. 7. 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. 8. 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). Jadi pembuatan dokumentasi pada metode agile didasarkan pada proses bisnisnya. Kita telah membahas alasan yang sah dan alasan yang dipertanyakan dalam pembuatan dokumentasi. Bagian selanjutnya akan membahas studi kasus dengan pendekatan dokumentasi melalui agile methods.
Hubungan Antara Dokumentasi dan Kesuksesan Proyek Tidak ada hubungan yang solid antara keberhasilan proyek dan dokumentasi tertulis yang komprehensif, dan sebenarnya itu lebih mungkin bahwa dokumentasi yang dilakukan semakin besar kemungkinannya dapat menyebabkan kegagalan proyek. Mengapa orang keliru dalam berpikir bahwa dokumentasi merupakan faktor penentu keberhasilan dalam pengembangan perangkat lunak? Teori dari Scott W. Ambler menyatakan bahwa pada tahun 1970-an dan 1980-an banyak organisasi memindahkan departemen IT mereka dari code and fixhackingke prosesdocumentation-heavy serial waterfall. Ketika mereka melakukannya, tingkat keberhasilan mereka benar-benar meningkat. Bahkan dapat dilihat hari ini dengan CMM (Capability Maturity Model)/CMMI, yakni ketika kita berpindah dari code and fixCMM (I) tingkat 1 ke tingkat 2 atau 3, kita sebenarnya dapat melihat perbaikan dalam produktivitas meskipun telah ditambahkan pembuatan dokumentasi yang lebih banyak untuk prosesnya. Mereka telah belajar bahwa dokumentasi meningkatkan upaya pengembangan perangkat lunak, dan merasa puas dengan jawabannya dan itu benar-benar disayangkan. Para pendukung CMM (I), atau strategi lain yang mendukung adanya dokumentasi yang berat, sepertinya tidak pernah mengajukan pertanyaan tentang apakah ada cara yang lebih baik untuk bekerja. Bukankah memfokuskan upaya dalam membuat perangkat lunak berkualitas tinggi (misalnya tes-driven development yang pada dasarnya menghasilkan spesifikasi executable) memberikan nilai kembalian yang lebih besar daripada menulis dokumentasi? Bukankah mencari cara untuk pembuatan kode program yang berkualitas tinggi (misalnya refactoring) memberikan pengembalian yang lebih besar daripada menulis dokumentasi? Bukankah nilai sebenarnya dari dokumentasi meningkatkan pemahaman tentang masalah domain, atau solution domain dalam kasus arsitektur/desain, dan bukan dokumentasi itu sendiri? Jika demikian, mungkin hanya berfokus pada upaya pemodelan (misalnya agile model driven development) dan bukan pada dokumentasi(Ambler S. , 2002). STUDI KASUS Berikut ini adalah contoh studi kasus pada beberapa perusahaan yang menggunakan salah satu metode agileyakni scrum (Scrumway, 2011): Perusahaan Multifinance Dokumentasi seperti Business Requirement Document (BRD) yang mau tidak mau harus dibuat. Tujuannya adalah supaya pihak end-user atau developer yang akan memaintain sistem ini dapat mengerti requirement dari sistem.BRD ini menjadi jembatan komunikasi dan dokumentasi mengenai cara kerja sistem berisi kebutuhan yang desain pusat data harus penuhi (Ekanita, 2006). Adapun tujuan requirement secara umum adalah sebagai berikut: - Menetapkan dan menjaga kesepakatan dengan customer dan stakeholder lain tentang apa yang harus dilakukan oleh sistem. - Untuk memberikan pemahaman yang lebih baik kepada pengembang sistem tentang kebutuhan sistem. - Menetapkan batasan sistem. - Untuk menyediakan dasar perencanaan teknis. - Untuk menyediakan dasar perkiraan biaya dan waktu pengembangan sistem. - Untuk mendefinisikan user interface sistem. BRD dalam sistem ini harus dibuat karena sifat dari sistemnya beresiko tinggi karena ada hubungannya dengan uang, sehingga pemahaman mengenai sistem sangat diperlukan agar
tidak terjadi hal yang tidak diinginkan ketika perubahan atau enhancement pada sistem dilakukan. Selain sifat dari sistem yang mission critical, sistem ini memiliki lifecycle yang sangat panjang, bahkan mungkin bisa lebih panjang dari umur developer yang menanganinya. Developer-nya bisa saja kerja di perusahaan tersebut untuk 2 tahun tapi sistem tetap berjalan walaupun developernya tidak bekerja di perusahaan itu lagi. Untuk kasus seperti ini berarti kita dapat melihat bahwasanya dokumentasi memiliki nilai jadi dokumentasi harus dibuat. Di dalam tim scrum dalam organisasi ini akan ada seorang Business Analyst yang akan mensinkronisasikan pekerjaan tim dan mendokumentasikannya ke dalam bentuk BRD ini. Perusahaan Perangkat Lunak Word Processor Ada lagi contoh sebuah perusahaan pembuat software word processor yang dijual secara massal dan digunakan oleh banyak pengguna yang awam yang bukan berada dalam organisasi tersebut. Untuk organisasi seperti ini dokumentasi seperti BRD tidak akan memiliki nilai karena sifatnya yang terlalu formal. Bahkan orang awam pun akan mengalami kesulitan untuk membacanya. Dalam kasus seperti ini, dokumentasi yang memiliki nilai adalah user manual(Sabharwal, 2008). Dalam kasus seperti ini user manual akan memiliki nilai tambah terhadap produk karena apabila pengguna tidak memiliki panduan mengenai bagaimana menggunakan perangkat lunaknya maka kemungkinan di masa mendatang mereka tidak meneruskan license dari produk ataupun bahakn mencemooh produk ini di social media. Hal ini dapat berimplikasi buruk terhadap bisnis mereka oleh karena itu user manual harus dibuat. Di dalam tim scrum dalam organisasi ini akan ada seorang Technical Writer yang menuliskan user manual dengan bahasa yang dapat dimengerti orang awam. Peran technical writer sebagai developer perangkat lunak yang memiliki pengetahuan dan memiliki keterampilan dalam pembuatan dokumentasi . Technical writer dapat terlibat dalam prosesscrum dengan menghadiri pertemuan yang selama 15 menit dengan komunikasi yang cepat dengan anggota tim (Uikey dkk, 2011). Perusahaan Aplikasi Mobile Dokumentasi tidak diperlukan di dalam aplikasi-aplikasi mobile tersebut. Bahkan user manual sekalipun. Alasannya adalah natur bisnis perusahaan ini yang bergerak sangat cepat(Wasserman, 2010). Di dalam bisnis mereka, setiap 3 bulan sekali produk yang mereka kembangkan mungkin akan menjadi usang, dibuang ataupun tidak digunakan lagi. Yang artinya setiap 3 bulan sekali mereka terus mengembangkan aplikasi mobile untuk dapat tetap memenuhi kebutuhan pasar(Wasserman, 2010). Karena biasanya aplikasi mobile yang mereka buat sangat sederhana dan dapat langsung dimengerti oleh orang awam sekalipun, maka mereka tidak perlu membuat user manual. User manual produk mereka sudah di-embed dalam penggunaan produk mereka yang begitu mudah dimengerti. Dari situ disepakati bahwasanya dokumentasi justru akan menghambat mereka untuk bisa deliver produk setiap 3 bulan sekali dan berkeputusan bahwasanya dokumentasi tidak perlu dibuat karena tidak ada nilainya bagi produk yang mereka kembangkan. Multinasional Terdistribusi Sebuah perusahaan multinasional yang memiliki cabang dan developer di berbagai negara. Mereka membutuhkan dokumentasi yang komprehensif mulai dari Design Specification, User Manual, User Requirement, dan sebagainya(Alexandru, 2012). Bahkan email dan messengerchat log pun diarsipkan oleh tim. Belum lagi termasuk wiki entry mereka yang sangat komprehensif. Perusahaan ini adalah salah satu perusahaan multinasional yang paling agile di dunia. Lalu
pertanyaannya adalah kalau mereka agile, kenapa mereka membutuhkan dokumentasi yang sekomprehensif itu? Bukankah itu bertentangan dengan nilai agile? Perlu diingat bahwasanya ada nilai agile lagi yang penting yakni kolaborasi dan komunikasi. Mereka sepakat karena letak anggota timnya yang terdistribusi di berbagai negara yang memiliki timezone yang berbeda-beda dokumentasi adalah salah satu sarana dimana mereka dapat berkomunikasi dengan anggota tim lainnya(Prikladnicki dkk, 2003). Tanpa dokumentasi-dokumentasi ini mereka sepakat hal tersebut dapat menyebabkan mereka sangat sulit untuk dapat tetap berada di atas jalur. Dari contoh diatas kiranya dapat memberi gambaran bahwasanya tim agile tidak mengesampingkan dokumentasi sama sekali(Scrumway, 2011). Pertama harus mencari tahu terlebih dahulu sejauh mana kebutuhan akan dokumentasi dan seberapa bernilai dokumentasi itu untuk bisnis dan produk yang dikembangkan. Dari kebanyakan kasus yang terjadi di lapangan, dokumentasi tidak memiliki nilai karena dipakai untuk mencari kambing hitam atau sebagai kontrak mati. Dari kebanyakan kasus yang terjadi di lapangan, dokumentasi tidak memiliki nilai karena dipakai untuk mencari kambing hitam atau sebagai kontrak mati(Ambler S. W., 2001). Dalam hal ini dokumentasi yang seperti ini sebaiknya tidak perlu dibuat karena sifatnya tidak bernilai karena cuma digunakan sebagai bumerang saja. KESIMPULAN Proses dokumentasi dalam agile tidak dikesampingkan sama sekali. Tim agile akan mempertimbangkan adanya pembuatan dokumentasi jika memang diperlukan dan bernilai bagi para pengembang maupun perangkat lunaknya sendiri(Scrumway, 2011). Agile manifesto yang menyebutkan bahwa perangkat lunak yang berkerja lebih dari dokumentasi yang menyeluruh, manifesto tersebut bukanlah keharusan atau mandat yang harus dilakukan, hanya sebagai preferensi. Manifesto tersebut mengarahkan para pengembang agar tidak terlalu mengutamakan dokumentasi yang tidak penting dan seharusnya lebih mengutamakan dalam pembuatan perangkat lunaknya sendiri(Ambler S. W., 2001), sebab hasil akhir dari pengembangan ini tentunya adalah perangkat lunak. DAFTAR PUSTAKA
Abrahamsson, P. (2003). New directions on agile methods: a comparative analysis. ICSE '03, Proceedings of the 25th International Conference on Software Engineering, IEEE Computer Society Washington, DC, USA, 244-254. Alexandru, C. (2012). Empirical Studies on Distributed Development: Methods and Results. 1-16. Ambler, S. (2002). Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process. Canada: Wiley Computer Publishing. Ambler, S. W. (2001). Agile/Lean Documentation: Strategies for Agile Software Development. Dipetik April 15, 2012, dari Agile Modeling: http://www.agilemodeling.com/essays/agileDocumentation.htm Ashima, & Aggarwal, H. (2010). Multidimensionality in Agile Software Development. International Journal of Computer Science and Information Security, 234-237. Bostrom, G., Wayrynen, J., & Boden, M. (2006). Extending XP Practices to Support Security Requirements Engineering. Proceedings of the 2006 international workshop on Software engineering for secure systems, ACM New York, NY, USA.
Ekanita, A. (2006). Perancangan Kerangka Kerja Daur Hidup dan Implementasi Dashboard dan Manajerial Pusat Data, Studi Kasus PT Adira Dinamika Multifinance, TBK. Bogor. Fricker, S., Gorschek, T., & Myllyperkiö, P. (2007). Handshaking Between Software Projects and Stakeholders Using Implementation Proposals. REFSQ, 144-159. Hazrati, V. (2009, Agustus 12). Two Types of Agile Documents - No More, No Less! Dipetik Juli 15, 2012, dari InfoQueue: http://www.infoq.com/news/2009/08/agile-documentation Jakob, M., Pěchouček, M., Miles, S., & Luck, M. (2008). Case Studies for Contract-based Systems. IST-UseCase, 55-62. Josef. (2007). PANDUAN AGILE UP. Pusat Ilmu Komputer UI, 1-49. Kar, N. J. (2006). Adopting Agile Methodologies of Software Development. SETLabs Briefings Vol. 4 No. 1, 1-8. Kniberg, H. (2007). Scrum dan XP Secara Praktis. United States of America: C4Media. Nasution, M., & Weistroffer, H. (2009). Documentation in Software Development: A Significant Criterion for Project Success. Proceedings of the 42nd Hawaii International Conference on System Sciences, 1. Prikladnicki, R., Audy, J. L., & Evaristo, R. (2003). Global Software Development in Practice Lessons Learned. SOFTWARE PROCESS IMPROVEMENT AND PRACTICE, 267281. Rico, D. F. (2008). Agile Methods and Software Documentation. 1-6. Sabharwal, S. (2008). Software Engineering. New Delhi: New Age International. SAP. (2007). Stake Holder Analysis. SAP AG. Schwaber, K., & Sutherland, J. (2011, Oktober). Panduan Scrum: Aturan Dalam Bermain. Scrumway. (2011, September 3). Persepsi salah tentang Agile/Scrum: Dokumentasi. Dipetik April 16, 2012, dari Scrumway: http://blog.scrumway.co/post/9728823541/persepsi-salah-tentangagile-scrum-dokumentasi Turk, D., France, R., & Rumpe, B. (2004). Assumptions Underlying Agile Software Development Processes. Journal of Database Management, 1-37. Uikey, N., Suman, U., & Ramani, A. (2011). A Documented Approach in Agile Software Development. International Journal of Software Engineering, 13-20. Wasserman, A. I. (2010). Software Engineering Issues for Mobile Application Development. FoSER. Widodo, & Subekti, M. (2006). Requirements Management Pada Extreme Programming. Seminar Nasional Aplikasi Teknologi Informasi 2006 (SNATI 2006), 95-100.
