1
Feature Driven Development (FDD), apakah bisa disebut Agile? I Wayan Agus Arimbawa STMIK Lombok, Praya email:
[email protected]
Abstract— The emerging technologies and the growth of user needs push software industries toward a new crisis form. Nowadays, the software development faces some obstacles such us, tightly time limit, the needs that continously changes, the requirement that can not fully described, the emerging of new inovative technology, and the unconstant time limit are can not to be adapted by conventional development model [1]. Today the emerging Agile development model is able to overcome these obstacles and proved to be successful in practice [2]. FDD is one of the agile methods that focus on the development and delivery where the requirement and the features are extracted within the scope of the domain language that clients are easy to understand [3]. This paper discusses the FDD from a different point of view to understand the concepts before, we tried to find flaws (disadvantages) in order to learn deeper the FDD itself. The final results are expected to identify deficiencies the FDD method so that the reader understand the practical characteristics of the FDD and get maximum results in the practice or use the appropriate method for a particular condition than other Agile methods.
I. PENDAHULUAN
D
i 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.[5] 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.[3] 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”. [3]
II. PENELITIAN TERDAHULU 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
2 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.
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 (sposor, 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. a. 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 b. 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:
• Project Manager berperan sebagai pemimpin administratif terhadap budget, orang-per-orang dan laporan pencapaian, mengoperasikan sistem proyek serta melindungi pekerja dari gangguan luar. • Chief Architect berperan sebagai penanggung jawab desain sistem secara keseluruhan, menjalankan workshop desain, dan mengarahkan proyek terkait kendala teknis. • Development Manager berperan sebagai pemimpin pengembangan dari hari-ke-hari, mengatasi konflik sumberdaya, biasanya juga dikombinasikan dengan Project Manager dan Chief Architect. • Chief Programmer adalah developer yang berpengalaman memimpin grup kecil dari sekumpulan developer individual. • Class Owner adalah developer individual yang mendesain, mengkodekan dan menguji dan mendokumentasikan fitur. • 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. c. 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: • Build an Overall Model Ketika fase ini dimulai, Domain Expert telah menyadari scope, konteks dan requirement dari sistem yang akan dibangun. [4] 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.[6] Domain keseluruhan (overal domain) lebih lajut dibagi kedalam area domain yang berbeda sedangkan walkthrough yang lebih detail deberikan oleh anggota domain. Kemudian anggota tim
3
Gambar 3.1 Lima Proses FDD[4]
developer bekerja dalam grup-grup kecil untuk mengerjakan project model dari domain area yang telah diterima.[4] • 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.[6] 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: <nomor akun> untuk . [5] • 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.[7]
Gambar 3.2 Proses Design by Feature dan Build by Feature[7] • Design by Feature dan Build by Feature Sekelompok kecil fitur diambil dari feature 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 iterasi 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. d. 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. e. 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
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. a. 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 kurang dari 10 % dari total waktu, biaya, cakupan, dan kualitas apabila feature tersebut dikemukan setelah proses Build Feature List. Terlihat pada Gambar 3.1., 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. Tetapi dalam 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. b. Studi Komparatif Komparatif yang dimaksud disini adalah membandingakn FDD dengan Agile model yang lain. Paper ini hanya membahas perbandingan FDD dengan RUP dan Extreme Programming (XP). RUP
FDD
XP
Scales To
???
10-250 developers
50 developers
Tools
Rational
TogetherSoft (Borland)
???
Process
Heavy
Medium
Agile
Roles
~30
~6 (9 optional)
~7
Artifacts
25-30
Flexible ~10-15
~30 (Thanks JN)
Tabel 4.1. Komparasi RUP, FDD, XP[5] Dari tabel di atas, dapat disimpulkan bahwa FDD memerlukan lebih banyak pengembang dibanding XP, sedangkan jumlah pengembang untuk RUP tidak diketahui. Untuk lebih jelasnya, Calberg mengkhususkan perbandingan secara langsung antara FDD dan XP, sebagai berikut: [5] FDD
XP
Sifat developer
Menekankan hirarki proses
Peer-to-peer
Kepemilikan proses
Individual, masingmasing memiliki Class owners Didukungan developer yang di atas rata-rata
Kolektif
Perubahan dapat dilakukan pada
Proses 1
Konstant di tiap proses
Jumlah jam kerja
Bebas
40 jam / minggu
Sukses jika
Didukungan developer yang ratarata Peran serta Client Hanya pada proses 1, 2, Client ikut dalam dan 4 pengerjaan
Tabel 4.2. Perbandingan FDD dengan XP Dari tabel di atas dapat disimpulkan bahwa, beberapa kelemahan FDD dibanding XP, adalah sebagai berikut: a. Karena FDD menggukanan sifat individual dari kepemilikan proses, maka dapat terjadi saling tunggu antara feature yang terkait. b. FDD lebih menekankan kepada developer yang mempu skill di atas rata. Sedangkan pada
5
c. d.
e.
kenyataannya, susah untuk mengumpulkan beberapa developer yang mempunyai skill di atas rata-rata. Peran serta client hanya pada beberapa tahapan saja. Perubahan feature hanya dapat dilakukan pada proses 1 saja, apabila dipaksakan melakukan perubahan fitur di tahap yang lain, maka hanya bisa dilakukan dengan prosentasi perubahan kurang dari 10%.[4] Karena jumlah jam kerja dari FDD yang tidak terikat, maka kemungkinan pada saat di tengahtengah jadual, para developer bekerja tidak optimal dan di akhir jadual akan bekerja extra keras. 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.
REFERENSI [1] [2] [3]
[4] [5] [6] [7]
Scott Ambler, ”Survey Says: Agile Works in Practice” , 2006. Philadelphia SPIN, “Agile Methode a Practical Perspective” (Software Process Environtment Network), 2006. David J. Anderson, “Feature-Driven Development: Toward a TOC, Lean and Sigma Solution for Software Engineering”, Microsoft Corporation, 2004. Stephen R. Palmer dan John M. Felsing, Practical Guide to FeatureDriven Development, Prentice Hall, 2001. Reid S. Calberg, Featur Driven Development, SE470, www.fivesticks.com/intoo/fdd Pekka Abrahamsson and Juhani Warsta , Agile Software Development Methods Review and Analysis, Julkaisija-Utgivare-Publisher, 2002. Amith Pulla, Feature Driven Development (FDD), a presentation, NJIT.
