TUGAS SOFTSKILL

I. PENDAHULUAN
   
            Di tahun 1997, Jeff De Luca, seorang warga negara Australia bersama tim berusaha menyelesaikan proyek skala besar yang diberikan oleh United Overseas Bank di Singapura. Sebelumnya proyek telah dikerjakan oleh tim lain namun gagal. Proyek mengalami kendala pada kompleksitas model obyek, sehingga setelah dua tahun berjalan dan tidak kunjung selesai, proyek dinyatakan gagal. Kedatangan Jeff De Luca yang memekerjakan Peter Coad yang dikenal dengan
tulisannya dalam analisis dan desain berorientasi obyek dalam pengembangan software untuk proyek TI skala besar dalam timnya akhirnya mampu mengerjakan proyek tersebut dengan menyajikan 2000 fitur yang berjalan dengan baik, membutuhkan waktu 15 bulan pengerjaan dengan 50 orang pemrogram, menghabiskan biaya yang lebih rendah dari anggaran.
            De Luca memperkenalkan metode proses dalam pengerjaan software tersebut sebagai “metode Coad”. Yang menjadi fokus dalam Metode Coad ini adalah sebuah analisis dalam dokumen yang disebut “fitur (feature)”. Fitur-fitur tersebut terdengar sebagai sebuah requirement menggunakan bahasa domain yang dapat dimengerti oleh sponsor proyek. Konsep fitur tersebut ditujukan agar setiap fitur yang telah dituliskan membuat sponsor proyek mengerti arti fitur dan dipastikan masuk ke dalam domain sistem. Pertemuan para pemikir software engineering pada tahun 2001 menghasilkan manifesto yang dikenal dengan Manifesto for Agile Software Development, dengan isi termasuk diantaranya FDD sebagai salah satu metode yang dikenal sebagai Agile bersama metode lainnya seperti Scrum, Extreme Programming atau Adaptive Software Development. Sebagai jantung dari pengembangan software Agile adalah dua2 buah idea utama yaitu adalah sangat penting untuk memberikan nilai berbentuk software yang bekerja kepada klien serta mampu merespon perubahan yang mungkin terjadi selama pengembangan dalam pasar yang penuh dengan inovasi dan selalu berubah menyebabkan harus dibangun dengan berbagai metode pengembangan software. Hal ini berarti telah memecahkan anggapan tradisional yang menyatakan “ rencanakan pekerjaan dan kemudian kerjakan perencanaan itu”, menuju pendekatan penyajian (delivery) dengan perencanaan yang adaptif. Kunci utama dari kebanyakan metode Agile adalah bagaimana pendefinisian nilai yang dapat langsung dikenali klien. Extreme Programming memiliki “User Story”, sedangkan FDD memiliki “Feature”. Menurut Abrahamsson, Salo, & Rokainen (2002, p47) yang disadur dari Palmer & Felsing (2002), Feature Driven Development (FDD) adalah pendekatan yang cepat dan adaptif dalam pengembangan sebuah aplikasi. Pendekatan FDD tidak membahas pengembangan software secara keseluruhan tetapi lebih berfokus kepada fase desain dan pembuatan program. FDD terdiri dari 5 tahapan proses. Pada bagian ang terus berulang di FDD (desain dan pembuatan sistem) yang mendukung agile development dengan adaptasi yang cepat untuk memenuhi perubahan pada proses bisnis.    
   
   




II. PENELITIAN TERDAHULU
Sebelum kita masuk ke materi Feature Driven Development, kita harus mengetahui dulu mengenai Agile Methods
Agile Development Methods adalah sekelompok metodologi pengembangan perangkat lunak yang didasarkan pada prinsip-prinsip yang sama atau pengembangan sistem jangka pendek yang memerlukan adaptasi cepat dari pengembang terhadap perubahan dalam bentuk apapun. Agile development methods merupakan salah satu dari Metodologi pengembangan perangkat lunak yang digunakan dalam Palembang perangkat lunak. Agile memiliki pengertian bersifat cepat, ringan, bebas bergerak, dan waspada. Sehingga saat membuat perangkat lunak dengan menggunakan agile development methods diperlukan inovasi dan responsibiliti yang baik antara tim pengembang dan klien agar kualitas dari perangkat lunak yang dihasilkan bagus dan kelincahan dari tim seimbang.
Saat bekerja dalam tim untuk mengerjakan suatu proyek sangatlah penting menentukan Methodology pengembangan perangkat lunak dan Proses pengembangan perangkat lunak yang akan digunakan. Metodologi pengembangan perangkat lunak sendiri adalah sebuah metodologi yang digunakan untuk membuat struktur, rencana, dan kontrol pengerjaan suatu proyek, sedangkan Proses pengembangan perangkat lunak adalah model-model dan metodologi yang digunakan untuk mengembangkan suatu perangkat lunak. Ada beberapa model Metodologi pengembangan perangkat lunak diantaranya     : waterfall, fountain, spiral, rapid, prototyping, incremental, build & fix, dan synchronize & stabilize. Terdapat enam langkah yang digunakan dalam Metodologi pengembangan perangkat lunak, yaitu     :
    Perencanaan, pada langkah ini pengembang dan klien membuat rencana tentang kebutuhan dari perangkat lunak yang akan dibuat.
    Implementasi, bagian dari proses dimana programmer melakukan pengkodean perangkat lunak.
    Tes perangkat lunak, disini perangkat lunak yang telah dibuat di tes oleh bagian kontrol kualitas agar bug yang ditemukan bisa segera diperbaiki dan kualitas perangkat lunak terjaga.
    Dokumentasi, setelah dilakukan tes perangkat lunak langkah selanjutnya yaitu proses dokumentasi perangkat lunak untuk mempermudah proses maintenanance kedepannya.
    Deployment, yaitu proses yang dilakukan oleh penjamin kualitas untuk menguji kualitas sistem. Setelah sistem memenuhi syarat maka perangkat lunak siap dideployment.
    Pemeliharaan, langkah terakhir yaitu pemeliharaan. Tidak ada perangkat lunak yang 100% bebas dari bug, oleh karena itu sangatlah penting agar perangkat lunak dipelihara secara berkala.
Agile development methods terdefinisi dalam empat nilai, biasa di sebut Agile Alliance’s Manifesto,
 diantaranya     :
1.    Interaksi dan personel lebih penting dari pada proses dan alat.
2.    Perangkat lunak yang berfungsi lebih penting daripada dokumentasi yang lengkap.
3.    Kolaborasi dengan klien lebih penting dari pada negosiasi kontrak.
4.    Respon terhadap perubahan lebih penting daripada mengikuti rencana.
Pengertian dari Agile Alliance's Manifesto dijelaskan di bawah ini:
    Interaksi dan personel lebih penting dari pada proses dan alat, di dalam agile interaksi antar anggota tim sangatlah penting, karena tanpa adanya interaksi yang baik maka proses pembuatan perangkat lunak tidak akan berjalan sesuai rencana.
    Perangkat lunak yang berfungsi lebih penting daripada dokumentasi yang lengkap, saat melakukan proses demonstrasi kepada klien, perangkat lunak yang berfungsi dengan baik akan lebih berguna daripada dokumentasi yang lengkap.
    Kolaborasi dengan klien lebih penting dari pada negosiasi kontrak, salah satu ciri dari agile adalah klien menjadi bagian dari tim pengembangan perangkat lunak. Kolaborasi yang baik dengan klien saat proses pembuatan perangkat lunak sangatlah penting ketika menggunakan agile. Karena fungsi-fungsi dari perangkat lunak yang dikembangkan harus terus menerus dibicarakan dan diimprovisasi disesuaikan dengan keinginan klien.
    Respon terhadap perubahan lebih penting daripada mengikuti rencana, agile development methods berfokus terhadap kecepatan respon tim ketika klien menginginkan perubahan saat proses pembuatan perangkat lunak.
Agar suatu tim berhasil dalam menerapkan agile development methods, maka tim tersebut harus mengikuti dua belas prinsip yang ditetapkan oleh Agile Alliance, yaitu     :
1.    Prioritas utama proses agile adalah memuaskan klien dengan menghasilkan perangkat lunak yang bernilai dengan cepat dan rutin.
2.    Menyambut perubahan kebutuhan, walaupun terlambat dalam pengembangan perangkat lunak. Proses Agile memanfaatkan perubahan untuk keuntungan kompetitif klien.
3.    Menghasilkan perangkat lunak yang bekerja secara rutin, dari jangka waktu beberapa minggu sampai beberapa bulan, dengan preferensi kepada jangka waktu yang lebih pendek.
4.    Rekan bisnis dan pengembang perangkat lunak harus bekerja sama tiap hari sepanjang proyek.
5.    Kembangkan proyek di sekitar individual yang termotivasi. Berikan mereka lingkungan dan dukungan yang mereka butuhkan, dan percayai mereka untuk menyelesaikan pekerjaan dengan baik.
6.    Metode yang paling efisien dan efektif untuk menyampaikan informasi dari dan dalam tim pengembang perangkat lunak adalah dengan komunikasi secara langsung.
7.    Perangkat lunak yang bekerja adalah ukuran utama kemajuan.
8.    Proses agile menggalakkan pengembangan berkelanjutan. Sponsor-sponsor, pengembang-pengembang, dan pengguna-pengguna dapat mempertahankan kecepatan tetap secara berkelanjutan.
9.    Perhatian yang berkesinambungan terhadap keunggulan teknis dan rancangan yang baik meningkatkan Agility.
10.                        Kesederhanaan (memaksimalkan sumber daya yang tersedia) adalah hal yang amat penting.
11.                        Arsitektur, kebutuhan, dan rancangan perangkat lunak terbaik muncul dari tim yang yang dapat mengorganisir diri sendiri.
12.                        Secara berkala, tim pengembang berefleksi tentang bagaimana untuk menjadi lebih efektif, kemudian menyesuaikan dan menyelaraskan kebiasaan bekerja mereka.
Dua belas prinsip tersebut menjadi suatu dasar bagi tim agar sukses menerapkan agile development methods. Dengan prinsip-prinsip tersebut agile berusaha untuk menyiasati tiga masalah yang biasanya dihadapi saat proses pembuatan perangkat lunak, yaitu:
    Kebutuhan perangkat lunak sulit diprediksi dari awal dan selalu akan berubah. Selain itu, prioritas klien juga sering berubah seiring berjalannya proyek.
    Desain dan pembangunan sering tumpang tindih. Sulit diperkirakan seberapa jauh desain yang diperlukan sebelum pembangunan.
    Analisis, desain, pembangunan dan testing tidak dapat diperkirakan seperti yang diinginkan.
Beberapa model dari agile development methods, yaitu     :

    Acceptance Test Driven Development (ATDD)
    Agile Modeling
    Adaptive Software Development (ASD)
Adaptive software development (ASD) diajukan oleh Jim Highsmith sebagai teknik untuk membangun software dan sistem yang kompleks. Filosofi yang mendasari adaptive software development adalah kolaborasi manusia dan tim yang mengatur diri sendiri. Sistem kerja adaptive software development     : collaboration dan learning. '
1.                          Collaboration     : orang-orang yang bermotivasi tinggi bekerja sama, saling melengkapi, rela membantu, kerja keras, terampil di bidangnya, dan komunikasikan masalah untuk menyelesikan masalah secara efektif.
2.                          Learning: tim developer sering merasa sudah tahu semua hal tentang proyek, padahal tidak selamanya begitu. Karena itu proses ini membuat mereka belajar lebih tentang proyek melalui tiga cara:
3.                          Fokus grup, klien dan pengguna memberi masukan terhadap perangkat lunak.
4.                          Formal Technique Reviews, tim ASD lengkap melakukan review.
5.                          Postmortems, tim ASD melakukan instrospeksi pada kinerja dan proses.
    Agile Unified Process (AUP)
    Continuous integration (CI)
    Crystal Clear
    Crystal Methods
    Dynamic Systems Development Method (DSDM)
Pada Dynamic System Development Method menyajikan kerangka kerja (framework) untuk membangun dan memelihara sistem dalam waktu yang terbatas melalui penggunaan prototip yang incremental dalam lingkungan yang terkondisikan. Metode ini bisa membuat pengerjaan software lebih cepat 80%.Hal -hal yang perlu diperhatikan jika menggunakan dynamic system development method:
1.                          Feasibility study, siapkan requirement, dan batasan, lalu uji apakah sesuai gunakan proses DSDM.
2.                          Business Study, susun kebutuhan fungsional dan informasi, tentukan arsitektur aplikasi dan identifikasi kebutuhan pemeliharaan untuk aplikasi.
3.                          Functional model iteration, perlihatkan fungsi perangkat lunak ke klien untuk mendapatkan feedback
4.                          Design and Build Iteration, cek ulang prototip yang dibangun dan pastikan bahwa prototip dibangun dengan cara yang memungkinkan fungsi tersebut benar-benar bekerja.
5.                          Implementation: buat perangkat lunak sesuai protoip yang ada dan terus tambah fungsionalitasnya.
    Extreme Programming (XP)
    Feature Driven Development (FDD)
Feature driven development merupakan sebuah model pengembangan perangkat lunak yang berdasarkan pada fitur yang akan dibuat. Keuntungan dari metode feature driven development     :
1.                          User dapat menggambarkan dengan mudah bentuk sistem yang akan dibuat.
2.                          Dapat diorganisasikan atau diatur ke dalam kelompok bisnis sesuai hirarki yang ada.
3.                          Desain dan kode lebih mudah diperiksa secara efektif.
4.                          Perancangan proyek, biaya pembuatan dan jadwal rilis ditentukan oleh fiturnya.
    Graphical System Design (GSD)
    Kanban
    Lean software development
    Rational Unified Process (RUP)
Rational unified process, adalah suatu kerangka pengembangan perangkat lunak iteratif yang dibuat oleh Rational Software, suatu divisi dari IBM sejak 2003. Rational unified process bukanlah suatu proses dengan aturan yang konkrit, melainkan suatu kerangka proses yang dapat diadaptasi dan dimaksudkan untuk disesuaikan oleh tim pengembang perangkat lunak yang akan memilih elemen proses disesuaikan dengan kebutuhan mereka.Model ini membagi suatu sistem aplikasi menjadi beberapa komponen sistem dan memungkinkan para developer aplikasi untuk menerapkan metoda iterative (analisis, disain, implementasi dan pengujian) pada tiap komponen. Dengan menggunakan model ini, Rational unified process membagi tahapan pengembangan perangkat lunaknya ke dalam 4 fase sebagai berikut.
1.                          Inception, merupakan tahap untuk mengidentifikasi sistem yang akan dikembangkan. Aktivitas yang dilakukan pada tahap ini antara lain mencakup analisis sistem, perumusan target dari sistem yang dibuat, identifikasi kebutuhan, perumusan kebutuhan pengujian, pemodelan diagram UML, dan pembuatan dokumentasi.
2.                          Elaboration, merupakan tahap untuk melakukan disain secara lengkap berdasarkan hasil analisis di tahap inception. Aktivitas yang dilakukan pada tahap ini antara lain mencakup pembuatan disain arsitektur subsistem, disain komponen sistem, disain format data disain database, disain antarmuka/tampilan, disain peta tampilan, penentuan design pattern yang digunakan, pemodelan diagram UML, dan pembuatan dokumentasi.
3.                          Construction, merupakan tahap untuk mengimplementasikan hasil disain dan melakukan pengujian hasil implementasi. Pada tahap awal construction, ada baiknya dilakukan pemeriksaan ulang hasil analisis dan disain, terutama disain pada diagram sequence,class, component, dan deployment. Apabila disain yang dibuat telah sesuai dengan analisis sistem, maka implementasi dengan bahasa pemrograman tertentu dapat dilakukan. Aktivitas yang dilakukan pada tahap ini antara lain mencakup pengujian hasil analisis dan disain (misal menggunakan class responsibility collaborator untuk kasus pemrograman berorientasi obyek), pendataan kebutuhan implementasi lengkap (berpedoman pada identifikasi kebutuhan di tahap analisis), penentuan coding pattern yang digunakan, pembuatan program, pengujian, optimasi program, pendataan berbagai kemungkinan pengembangan / perbaikan lebih lanjut, dan pembuatan dokumentasi.
4.                          Transition, merupakan tahap untuk menyerahkan sistem aplikasi ke konsumen (roll-out), yang umumnya mencakup pelaksanaan pelatihan kepada pengguna dan testing beta aplikasi terhadap ekspetasi pengguna.
    Scrum
    Scrum-ban
    Story-driven modeling
    Test-driven development (TDD)
    Velocity tracking
    Software Development Rhythms
Tujuan Agile
Secara garis besar tujuan dirumuskannya agile development methods, yaitu     :
1.    High-value & working App system, diharapkan dengan memakai agile development methods dapat dihasilkan perangkat lunak yang mempunyai nilai jual yang tinggi, biaya pembuatan bisa di tekan dan perangkat lunak bisa berjalan dengan baik.
2.    Iterative, incremental, evolutionary, agile adalah metode pengembangan perangkat lunak yang iteratif, selalu mengalami perubahan, dan evolusioner. Tim harus bekerja dalam waktu yang singkat(biasanya 1-3 minggu) dan juga selalu menambah fungsionalitas dari perangkat lunak sesuai dengan kebutuhan klien. Agile dapat dianalogikan ketika seseorang ingin pergi ke suatu kota dan dia tidak tahu jalannya. Lalu bagaimana dia bisa sampai tujuan? Dengan sering bertanya kepada orang yang dia temui dijalan hingga dia sampai di tempat tujuan.
3.    Cost control & value-driven development, salah satu tujuan dari agile yaitu pengembangan perangkat lunak disesuaikan dengan kebutuhan pengguna, tim bisa dengan cepat merespon kebutuhan yang diinginkan pengguna sehingga waktu dan biaya pembuatan perangkat lunak bisa dikontrol.
4.    High-quality production, walaupun biaya pembuatan perangkat lunak bisa ditekan dan proses pembuatan bisa dipercepat , tetapi kualitas dari perangkat lunak yang dibuat harus tetap dijaga. Dengan melakukan tes setiap fungsionalitas perangkat lunak setelah selesei dibuat berarti agile juga mengakomodir kebutuhan ini.
5.    Flexible & risk management, jika kita menggunakan metode pembuatan yang biasanya dipakai, jika ingin mengubah fungsionalitas dari wireframe yang telah dibuat di butuhkan proses yang rumit. Mulai dari pertemuan dengan sistem analis untuk merubah sistem perangkat lunak, perubahan rencana rilis produk hingga perubahan biaya produksi. Pertemuan dengan klien untuk melakukan tes perangkat lunak juga sering dilakukan sehingga fungsionalitas perangkat lunak mudah diubah dan akhirnya kegagalan perangkat lunakpun bisa diminimalisir.
6.    Collaboration, dengan menggunakan agile, tim pengembang diharuskan sering bertemu untuk membahas perkembangan proyek dan feedback dari klien yang nantinya akan ditambahkan dalam perangkat lunak, sehingga tim bisa berkolaborasi dengan maksimal.
7.    Self-organizing, self-managing teams, rekrut orang terbaik, beri dan dukung kebutuhan mereka lalu biarkan mereka bekerja. Itulah perbedaan agile dan SDM lainnya. Dengan agile, developer dapat memanajemen dirinya sendiri, sedangkan manajer tim hanya bertugas mengkolaborasikan developer perangkat lunak dengan klien. Sehingga terciptalah tim yang solid.
   
   
   

Topik selanjutnya yaitu tentang cara kerja agile development methods. Disini akan dijelaskan bagaimana agile development methods (model scrum) digunakan dalam manajemen proyek.
Komposisi tim
Secara umum komposisi dari sebuah tim pengembang perangkat lunak yaitu     :
    Owner / Klien, bersama dengan developer sebagai bagian terpenting dalam proyek, tugas dari klien menentukan fungsi dari perangkat lunak yang akan di buat, melakukan testing dan memberikan feedback.
    Manajer / Scrum Master, bertugas mengkolaborasikan developer dengan klien, membuat dan mengevaluasi target pengerjaan perangkat lunak.
    Sistem Analis, membuat arsitektur sistem dari perangkat lunak yang akan dibuat.
    Developer, merupakan titik vital dalam tim, tanpa developer perangkat lunak tidak akan bisa dibuat.
Story
Story adalah daftar kebutuhan atau fitur yang nanti akan dibuat. Story berisi apa yang klien kehendaki, dan ditulis dalam bahasa yang dimengerti klien. Dengan kata lain dapat disimpulan Story adalah bagian terpenting dari Scrum.
Story terdiri dari kolom-kolom berikut ini:
    ID – Identifikasi unik, biasanya berupa nomor urut. Hal ini untuk menghindari kehilangan jejak story kalau kita mengganti namanya.
    Nama – Nama story bersifat deskriptif, padat, singkat, dan jelas (2-10 kata), sehingga tim dan klien memahami kira-kira story yang dibicarakan.
    Kepentingan – Derajat kepentingan yang diberikan oleh klien terhadap story. Pemberian derajat kepentingan biasanya menggunakan deret fibonacci (1,1,2,3,5,dst). Semakin tinggi nilainya maka semakin tinggi pula prioritas pengerjaannya.
    Perkiraan awal – Perkiraan awal tim tentang berapa banyak kerja yang diperlukan untuk mengimplementasikan sebuah story.
    Demo – deskripsi umum bagaimana cara story ini didemokan pada waktu sprint demo (lakukan ini, klik itu, lalu ini akan muncul,dll).


Sprint
Sprint (Rapat perencanaan pembuatan perangkat lunak dilakukan 2-8 minggu sekali), yang perlu diperhatikan saat melaksanakan sprint antara lain     :
    Tujuan sprint.
    Daftar anggota tim harus lengkap.
    Sprint backlog (daftar story yang akan diikutkan dalam sprint).
    Tanggal demo yang pasti.
    Tempat dan waktu yang jelas untuk pelaksanaan sprint berikutnya.
Tim akan melakukan sprint secara simultan sampai perangkat lunak selesei dikerjakan, sebagai contoh:
Sprint 1, tim membuat fungsi login,logout dan demo perangkat lunak akan dilakukan 3 minggu kemudian. Setelah dilakukan demo untuk mengevaluasi kerja yang dilakukan tim pada Sprint 1, maka Sprint 1 dianggap selesei. Bahan evaluasi dari Sprint 1 akan dibawa ke Sprint 2 begitu seterusnya sampai aplikasi selesei dikerjakan.
Kelebihan dan Kekurangan
Kelebihan
Beberapa kelebihan dari agile diantaranya:
    82% Menambah produktivitas tim.
    77% Menambah kualitas perangkat lunak.
    78% Menambah kepuasan klien.
    37% Menghemat biaya.
Kekurangan
Sedangkan kekurangan dari agile antara lain     :
    Agile tidak akan berjalan dengan baik jika komitmen tim kurang.
    Tidak cocok dalam skala tim yang besar (>20 orang).
    Perkiraan waktu release dan harga perangkat lunak sulit ditentukan.
   

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 alam 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:

1.      User manual
2.      Deployment manual
3.      Pemeliharaan manual (ditujukan untuk mengoperasikan perangkat lunak)
4.      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):

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

            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.
            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). 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 agartidak 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. Didalam             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.
Kelebihan      Metode Agile
1.           Meningakatkan rasio kepuasan pelanggan.
2.           Bisa melakukan reviw pelanggan mengenai software yang dibuat lebih awal.
3.           Mengurangi resiko kegagalan implementasi software dari non-teknis.
4.           Besar kerugian baik secara material atau imaterial tidak terlalu besar jika terjadi kegagalan.
Langkah-langkah pengembangan perangkat lunak Agile adalah suatu filosofi yang mendorong kepuasan pelanggan, penyerahan hasil perangkat lunak secara bertahap, tim proyek yang kecil, metoda informal, dan proses pengembangan perangkat lunak dengan perancangan minimal namun tetap efektif. Agile membantu mempermudah para pengembang perangkat lunak untuk melakukan penyerahan produk tepat waktu dari suatu tahap operasional perangkat lunak yaitu analisa dan desain.
   
Metode Coad yang dikenal selama pengerjaan proyek di Singapore tahun 1997 – 1999 kemudian berevolusi menjadi Feature-Driven Development setelah mendapat ide dari apa yang dikerjakan oleh Gerald Weinberg, Frederick Brooks, Timothy Lister, dan Tom De Marco dengan pandangan dari
Jeff De Luca dan disusun oleh Stephen Palmer. De Luca dan Coad kemudian mempublikasikan penjelasan FDD melalui bukunya yang berjudul “Java Modeling in Color with UML”
di tahun 1999. Palmer dan Flesing kemudian menyusun textbook yang lebih definitif berjudul “A Practical Guide to Feature-Driven Development” di tahun 2001.
Setelah itu banyak publikasi yang dilakukan terkait FDD seperti Ambler yang menyatakan bahwa  menurut survei ternyata FDD bekerja dengan baik dalam prakteknya. Terdapat pula penelitian-penelitian akademis yang berusaha membandingkan FDD dengan metode pengembangan Agile
yang lain seperti terhadap metode Scrum dan Extreme Programming. Namun, secara explisit belum ditemukan penelitian atau kajian yang secara langsung mencari kelemahan dari metode FDD ini.
   
            Feature-driven Development juga merupakan salah satu metodologi yang digunakan dalam pembuatan software atau pun aplikasi. Dalam pembuatan suatu software dibutuhkan adanya metodologi, metodologi Feature-driven Development sangat cocok digunakan untuk pembuatan aplikasi web. Feature-driven Development berfokus pada fitur-fitur yang dibutuhkan pengguna, Feature-driven Development juga lebih terstruktur dibandingkan metodologi Extreme Programming dan memiki lebih sedikit persyaratan ataupun ketentuan dibandingkan metodologi Rational Unified. Metodologi FDD mencakup pengembangan perangkat lunak sebagai aktivitas manusia, sesuai dengan keterbatasan manusia dan manfaat dari kekuatan manusia.

            Fitur-driven Development (FDD) adalah bersifat iteratif dan incremental dalam proses pengembangan perangkat lunak karena itulah FDD dikatakan identik dengan agile modeling yang juga menggunakan praktek-praktek tradional dan menggunakan tahap planning, design dan dokumentasi. sebagai salah satu metodologi yang di kembangkan dari metodologi agile, FDD memadukan sejumlah industri yang diakui menggunakan praktik terbaik untuk menjadi satu kesatuan yang kohesif. Praktik-praktik ini semua berdasar dari sudut pandang fungsi client-valued atau berfokus pada nilai-nilai dan fitur yang di butuhkan client. Tujuan utamanya adalah untuk memberikan nilai nyata, mengerjakan software secara berulang-ulang pada waktu yang tepat.

            Feature-driven Development terbagi menjadi lima proses yang akan dijelaskan secara detail pada bab-bab selanjutnya. Menurut teori Palmer dan Felsing, FDD mengklasifikasikan peran menjadi tiga kategori yaitu: main roles, supporting role, dan additional, peran itu termasuk project manager, kepala arsitek, development manajer, pemimpin tim, pemilik class, dan ahli Domain, semua memainkan peran penting dalam merumuskan fitur, memprioritaskan, dan merancang solusi bisnis.
   
   
III. FEATURE-DRIVEN DEVELOPMENT
   
Menurut Palmer (2001), FDD adalah proses yang didesain dan dilaksanakan untuk menyajikan (deliver) hasil kerja secara berulang-ulang dalam waktu tertentu dan dapat diukur. FDD adalah pendekatan yang mengacu pembuatan sistem menggunakan metode yang mudah dimengerti dan mudah
diimplentasikan; teknik problem solving; dan pelaporan yang mudah dimengerti dan dikontrol oleh stakeholders. Pemrogram diberikan informasi yang cukup dan diberikan alat bantu yang baik untuk menyelesaikan aplikasi yang diberikan. Team leader dan manajer proyek diberikan informasi yang baik berdasar waktu mengenai tim dan proyek yang berjalan untuk menghindari resiko yang mungkin terjadi. Pelaporan menjadi lebih mudah, tidak membebani, periodik dan akurat.
            Pengguna (sponsor, end user, customer) secara langsung dapat melihat bagian mereka sebagai hasil progress proyek dan memberikan umpan balik semasih dalam tahap pengembangan. Dengan hal ini diharapkan proyek dapat menghasilkan sebuah sistem yang benar-benar diinginkan oleh klien.

•         Nilai-nilai Utama
Menurut Calberg, nilai-nilai utama yang terkandung dalam FDD sehingga FDD mampu memberikan nilai lebih bagi proses pengembangan software adalah:
Tangible results rather than Process Pride
Proses dalam FDD lebih mengutamakan memberikan nilai-nilai yang dapat diukur daripada sederet proses yang rumit dan menghabiskan banyak tenaga dan sumber daya.

A system for building system is necessary
Sangat penting untuk membentuk sebuah sistem yang solid dan rapi untuk membuat sistem (software) bekerja sesuai dengan yang diharapkan.·
Simple is better
Desain yang dibuat harus sesederhana mungkin namun mampu menggali semua requirement yang disyaratkan oleh klien.
· Process steps should be obviously valuable to each team member
· Good processes move to the background
   
•         6 Pemeran Utama
Menurut Palmer dan Flesing (2001), Calberg, Abrahamsson dan Juhani (2002) setiap proses dalam FDD melalui orangorang di dalamnya dan kelebihan serta kekurangan setiap orang sangat berpengaruh pada keluaran proyek, terdapat 6 pemeran utama proses FDD yaitu:
1.      Project Manager adalah seseorang yang diberikan tanggung jawab untuk memimpin tim proyek di dalam mengelola, merancang, mengeksekusi dan menutup proyek sesuai dengan tujuan dari proyek yang telah ditetapkan. Peran kunci dari project manager di dalam project management diantaranya adalah menentukan tujuan proyek yang ingin dicapai, membangun requirement proyek dan mengelola 3 batasan dari proyek yaitu scope, cost dan schedule ditambah batasan kualitas secara efektif.
Di dalam pengerjaan proyek peran dari seorang project manager adalah mengetahui, mentranslasikan dan mengimplementasikan kebutuhan dari klien, untuk mencapai hal ini kemampuan untuk beradaptasi dan berkompromi dengan berbagai stakeholder yang ada serta melakukan negosiasi memiliki peranan penting dalam memastikan isu penting seperti cost, waktu dan kualitas dapat dicapai sehingga tercapai kepuasan customer. Project manager juga berperan sebagai pemimpin administratif terhadap budget, orang-per-orang dan laporan pencapaian, mengoperasikan sistem proyek serta melindungi pekerja dari gangguan luar.
2.      Chief Architect berperan sebagai penanggung jawab desain sistem secara keseluruhan, menjalankan workshop desain, dan mengarahkan proyek terkait kendala teknis.

3.      Development Manager berperan sebagai pemimpin pengembangan dari hari-ke-hari, mengatasi konflik sumberdaya, biasanya juga dikombinasikan dengan Project Manager dan Chief Architect.


4.      Chief Programmer adalah developer yang berpengalaman memimpin grup kecil dari sekumpulan developer individual.

5.      Class Owner adalah developer individual yang mendesain, mengkodekan dan menguji dan mendokumentasikan fitur.

6.      Domain Expert yaitu user, klien, sponsor dll. Dikenal baik oleh developer. Selain enam pemeran utama tersebut diatas juga terdapat pemeran pembantu seperti domain manager, release manager, language guru, bild engineer, toolsmith, dan system administrator. Selain itu juga terkadang cukup membantu adalah tester, deployer, dan technical writer.
   
•         5 Proses FDD
FDD terdiri dari 5 proses berurut selama mendesain dan mebangun sistem. Proses FDD yang iteratif dalam mendesain dan membangun (design and build) mendukung metode Agile dengan adaptasi yang cepat terhadap perubahan requirement dan kebutuhan bisnis. [6] Kelima proses tersebut adalah:
·Develop an Overall Model
Pada tahap awal ini, client memberikan gambaran secara garis besar mengenai program yang akan dibuat dan fitur – fitur yang perlu dibuat.  Ketika fase ini dimulai, Domain Expert telah menyadari scope, konteks dan requirement dari sistem yang akan dibangun. Pembuatan dokumen requirement seperti use case atau spesifikasi fungsional ada dalam fase ini. Namun FDD tidak secara eksplisit menggali, mencari dan mengatur requirement ini. Domain expert menyajikan apa yang disebut “walkthrough” yang mana anggota tim dan Chief Architect diinformasikan dengan deskripsi level tinggi dari sistem. Domain keseluruhan (overal domain) lebih lajut dibagi kedalam area domain yang berbeda sedangkan walkthrough yang lebih detail deberikanoleh anggota domain. Kemudian anggota tim      developer bekerja dalam grup-grup kecil untuk mengerjakan project model dari domain area yang telah diterima.
Build a Feature List
Walkthrough, object model dan dokumentasi requirement yang ada memberikan dasar yang kuat dalam membangun feature list yang komprehensif untuk sistem yang dikerjakan. Dalam daftar (list), tim menyajikan masing-masing client valued functions ke dalam sistem. Fungsi-fungsi tersebut dibagikan kepada masing-masing domain area dan masing-masing grup dari fungsi tersebut disebut sebagai major feature set. Sebagai tambahan, major feature sets kemudian dibagi lagi menjadi feature sets. Ini merepresentasikan aktifiti yang berbeda di setiap domain area. Feature list adalah yang dilihat oleh user atau sponsor untuk validitas dan kelengkapan mereka. Feature dalam hal ini adalah langkah-langkah aktifitas bisnis, berbasis customer bukan teknologi. Bahasa yang digunakan mencakup bahasa yang dimengerti oleh cutomer. Nomenklatur untuk menunjukkannya terdiri atas:

Misalnya:
untuk .
Fitur – fitur besar dibagi kembali menjadi fitur – fitur yang lebih kecil. Fitur – fitur ini menjelaskan lebih spesifik tentang sistem di suatu tempat. List fitur ini kemudian dilihat oleh client untuk diperiksa validitas dan kelengkapannya.
Plan by Features
Plan by feature mencakup perencanaan pada level yang lebih tinggi, dimana feature set diatur sedemikian rupa sesuai dengan prioritas dan hubungannya. Prioritas ditentukan sesuai dengan kebutuhan customer yang disetujui oleh Chief Programmer. [6] Dalam fase ini, Project Manager, Development Manager dan Chief Programmer merencanakan urutan feature-feature yang akan dikerjakan dengan demikian class owenership telah dilengkapi. Merencanakan mulai pembuatan fitur – fitur secara sequential menurut prioritasnya dan ketergantungannya kepada fitur – fitur lain.    
Gambar 3.2 Proses Design by Feature dan Build by Feature[7]
·
Design by Feature dan Build by Feature
Tahapan ini adalah pembuatan program sesuai fitur – fitur yang telah disusun.      Proses      design by eature dan      build by feature      ada      proses      yang prosedur yang berulang selama sebuah fitur ini dibuat. Setelah sebuah fitur telah selesai dibuat, maka fitur tersebut akan dipindahkan kepada fitur utama dalam program untuk dijadikan satu kesatuan. Sekelompok kecil fitur diambil dari eature set dan diperlukan feature team untuk membangun fitur terpilih yang disebut sebagai class owner. Proses design by feature dan build by feature bersifat iteratif selama fitur yang dipilih tersebut diproduksi. Satu kali terasi memerlukan waktu beberapa hari sampai 2 minggu. Proses iteratif ini mencakup beberapa tugas seperti inspeksi rancangan, pengkodean, pengujian unit, integrasi dan inspeksi kode seperti yang dijelaskan dalam gambar 3.2.
Project Tracking Methodology
Penelusuran proyek (Project Tracking) diperlukan untuk mengetahui sejauh mana proyek telah berjalan dan mengevaluasi strategi dan kemungkinan yang akan dijalankan terkait situasi itu. Menurut Pulla, untuk mengukur kemajuan tiap feature dalam proses FDD terdiri dari 6 milestone di setiap featurenya menggunakan ukuran prosentase, mencatat waktu feature selesai, diatur dari feature set dan feature area, direpresentasikan secara grafis kepada manajemen di level yang lebih tinggi, juga disusun tren dan grafik digunakan untuk menunjukkan kemajuan.

Karakteristik
Menurut Calberg, penggunaan FDD sebaiknya digunakan jika; memekerjakan 10 – 250 developer yang memiliki kemampuan teknis lebih dari rata-rata, dan jangan digunakan jika; jumlah tim kurang dari 10, tim sedang belajar menguasai pekerjaan dan jika kurang dukungan dari sistem. FDD lebih terhirarki daripada Extreme Programming, memiliki class owenership yang terpisah-pisah, sukses jika dalam rentang jumlah developer diatas rata-rata, klien tidak dilibatkan dalam ambar 3.1 Lima Proses FDD 4 seluruh urutan proses (hanya dalam proses 1, 2 dan 4) dan menghargai developer sebagai individu manusia yang menentukan sukses atau tidaknya pengembangan.
   
IV. KELEMAHAN
Sangat sedikit rujukan yang bisa dijadikan acuan untuk menunjukkan kelemahan metode FDD secara eksplisit, oleh karena itu dibagian ini akan dijelaskan hasil penelusuran materi terkait kelemahan FDD dengan dua cara studi yaitu studi analitik dan studi komparasi. Studi analitik dilakukan
untuk mencoba mengungkap kelemahan FDD dari dalam yaitu dengan menelusuri proses, karakteristik, pemeran dan lain sebagainya sehingga dapat dirumuskan hasilnya. Studi komparatif dilakukan dengan mencoba membandingkan karakteristik FDD jika dibandingkan dengan metode Agile yang lain.

Studi Analitik
Dari sisi anlitik dapat dirumuskan beberapa kelemahan
dari FDD, yaitu :

1.      Jumlah pekerja dalam project tersebut. FDD memerlukan jumlah pekerja/personel yang
cukup banyak, yang dipecah-pecah ke dalam masingmasing bagian. Jika dilihat dari segi biaya, semakin banyak pekerja, maka semakin banyak pula biaya
yang dikeluarkan untuk membayarkan hak mereka. Jelas bagi project skala kecil, hal ini tidak sesuai. Dimana project dibiayai dengan dana yang terbatas. Hal lain yang bisa menimbulkan masalah adalah dengan banyaknya jumlah pekerja, banyak juga kepentingan yang saling bertentangan.

2.      Masalah class ownership dari feature dalam FDD. Dalam FDD dikenal dengan class ownership,
dimana tiap feature akan ditangani oleh tiap Class owners. Masalah yang bisa terjadi adalah misal, apabila seorang Class owners melakukan perubahan pada feature yang ditanganinya, anggap sebagai A. Dan ternyata perubahan tersebut berpengaruh pada feature B, yang dikerjakan oleh Class owners lainnya. Hal ini akan berdampak buruk apabila ternyata feature B memerlukan feature A. Dan pada akhirnya pengerjaan feature B harus menunggu kepastian
feature A terselesaikan. Jelas ini akan berdampak pada mundurnya jadual kerja dari project.

3.      FDD hanya membatasi penambahan feature kurangdari 10 % dari total waktu, biaya, cakupan, dan kualitas apabila feature tersebut dikemukan setelah
proses Build Feature List.


            bahwa 3 proses awal (Develop an Overall Model, Build a Feature List, dan Plan by Feature) merupakan tahap-tahap yang krusial dan mendapat porsi waktu yang lebih banyak. Tetapidalam prakteknya, banyak perubahan justru terjadi setelah tahap-tahap tersebut di atas.
            Perubahan tersebut bisa bersifat teknis, seperti kendala dengan keterbatasan perangkat lunak atau perangkat keras, maupun kendala non-teknis seperti pergantian project sponsor yang dapat berakibat berubahnya kebijakan yang telah disepakati sebelumnya.
   



V. KESIMPULAN
Metode FDD memiliki proses dengan tingkat hirarkis yang tinggi sehingga setiap proses merupakan rangkaian tugas yang baku dan klien hanya berperan dalam sebagian proses saja tidak dalam keseluruhan proses. Fleksibilitas dan kemampuannya menghadapi perubahan masih bisa dilakukan
walaupun melalui proses iteratif yang panjang karena melampau beberapa prosedur sampai feature diberikan ke klien. Pengubahan feature hanya dapat dilakukan hanya pada proses pertama dan secara keseluruhan hanya mampu memberikan penambahan kurang dari 10%. Dibandingkan dengan Extreme Programming, FDD terlalu banyak memberikan pemodelan daripada langsung melakukan
pengkodean membuat hasil akan terlihat dalam waktu yang lama, walaupun hal ini memberikan keuntungan untuk proyek dengan skala dan kerumitan lebih besar. Walaupun proses dalam FDD tidak mendukung sepenuhnya ciri-ciri dari metode Agile yang ideal, namun masih tetap mampu memberikan keuntungan sebagai metode yang fokus dalam memberikan hasil nyata bagi konsumen dan tanggap
akan perubahan yang mungkin terjadi dalam masa pengembangan. Dengan kerumitan yang lebih tinggi, orangorang yang lebih banyak dan waktu yang lebih lama membuat FDD cocok diaplikasikan untuk proyek-proyek dengan skala yang lebih besar.