AGILE DEVELOPMENT METHODS

LAPORAN TUGAS APSI

Oleh :

1.
2.
3.
4.
5.
6.

NIM

Nama

1312500380
1312500406
1312500422
1312500661
1312500794
1312501065

Imam Halim Mursyidin

Intan Shavana
Mochamad Jati Seno
I Made Sukresna
Refo Ratna Sari
Aldi Yudha Pradipta

UNIVERSITAS BUDI LUHUR

FAKULTAS TEKNOLOGI INFORMASI
JAKARTA

SEMESTER GASAL
2015/2016

AGILE DEVELOPMENT METHODS

1.

Definisi
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 pengembangan 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.

Gambar 1.1: Metodologi Agile.

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.

Pro & Kontra Agile Development

Pro :

Lebih Flesibel dibandingkan dengan metodologi Waterfall

Memberikan tanggapan iterasi dengan segera

Lebih sedikit kerusakan pada produk akhir

Kontra :

Tanggapan yang terlalu cepat ngekibatkan scope yang meluas

dokumentasi yang akan tertinggal

Cara kerja

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.

2.

Rincian Methods
1. Acceptance Test Driven Development (ATDD)
Acceptance Test-Driven Development (ATDD) adalah metode pengembangan perangkat
lunak yang membawa orang-orang teknis dan non-teknis bersama-sama untuk
menciptakan produk bernilai tinggi bekerja sama dengan pelanggan. Hal ini terkait dengan
Test-Driven Development (TDD) tapi sementara TDD adalah kode-sentris dan berfokus

pada bagian perangkat lunak (bagaimana kode memecahkan masalah) ATDD dapat
digambarkan sebagai luar-dalam nya dengan fokus pada perilaku perangkat lunak.

Cara kerja
Tes penerimaan driven, atau ATDD, adalah praktek kolaboratif dimana
pengembang aplikasi, pengguna perangkat lunak, dan analis bisnis menentukan
kriteria penerimaan otomatis sangat awal dalam proses pengembangan aplikasi.
Mereka kemudian menggunakan kriteria penerimaan untuk memandu
pembangunan selanjutnya.
Keuntungan
ATDD berfungsi meningkatkan pemahaman tentang persyaratan karena
termasuk prodak dari interaksi langsung antara client dan developers.
Menjelaskan persyaratan dan menjaga developers tetap fokus pada
keinginan client.
menghilangkan keambiguan jika perilaku tertentu menyebabkan terlalu
banyak bug (perilaku melanggar persyaratan atau tes atau keduanya) atau
perubahan permintaan (Perilaku yang dapat diterima dalam lingkup
persyaratan dan penerimaan tes tapi akhirnya tidak diinginkan).
Pengiriman software sekarang tergantung pada semua tes penerimaan
yang dilewati dan itu menyatakan bahwa project itu telah selesai.
Kelemahan
interaksi klien yang dibutuhkan untuk membuktikan kesulitan karena
adanya kendala waktu.
Bekerja lebih untuk pengembangan jika test terotomatis.
Kemajuan proyek mungkin akan lebih lambat karena upaya tambahan
2. Metodologi Extreme Programming (XP)
Secara umum Extreme Programming (XP) dapat dijabarkan sebagai sebuah
pendekatan pengembangan perangkat lunak yang mencoba meningkatkan
efisiensi dan fleksibilitas dari sebuah proyek pengembangan perangkat lunak
dengan mengkombinasikan berbagai ide simpel/sederhana tanpa mengurangi
kualitas software yang akan dibagun. XP dikembangkan oleh Beck, Cunningham,
dan Jeffries dan ini merupakan lightweight discipline pengembangan perangkat
lunak berdasarkan empat core value.
Cara kerja

Planning

Aktivitas planning dimulai dengan membentuk user stories. Anggota

XP team kemudian menilai setiap story dan menentukan cost
diukur dalam development week. Customer dan XP team bekerja
bersama untuk memutuskan bagaimana grup story untuk release
berikutnya (software increment berikutnya) untuk dibangun oleh XP
team. Jika komitmen telah dibuat, XP team akan membangun storystory dengan cara :
1) Semua story segera diimplemetasikan (dalam beberapa minggu)
2) Story dengan value tertinggi akan dipindahkan dari jadwal dan
dimplementasikan pertama.
3) Story dengan resiko paling tinggi akan diimplemetasikan lebih
dulu. Setelah project pertama direlease dan didelivery, XP team
memperhitungkan kecepatan project. Selama development,
customer dapat menambah story, merubah value, membagi story
atau menghapusnya.

Design
XP menggunakan CRC card, untuk mengenali dan mengatur object
oriented class yang sesuai dengan software increment.

Coding
Sebelum membuat code, lebih baik membuat unit test tiap story
untuk dimasukkan dalam software increment. XP menyarankan agar
dua orang bekerja bersama pada satu komputer workstation untuk
membuat code dari satu story (pair programming), untuk
menyediakan real time problem solving dan jaminan real time
quality. Setelah pair programming selesai, code diintegrasikan
dengan kerja laiinnya (continuous integration).

Testing
Unit test yang telah dibuat harus diimplementasikan menggunakan
suatu framework dan diatur ke dalam universal testing suite, integrasi
dan validasi sistem dapat dilakukan setiap hari. Customer test
(acceptance test) dilakukan oleh customer dan fokus pada

keseluruhan fitur dan fungsional sistem. Acceptance test diperoleh

dari customer stories yang telah diimplemetasikan sebagai bagian dari
software release.
Kelebihan

Meningkatkan kepuasan kepada klien

Pembangunan system dibuat lebih cepat

Menjalin komunikasi yang baik dengan client.

Meningkatkan komunikasi dan sifat saling menghargai antar developer.

Kekurangan

User story kemungkinan besar tidak lengkap sehingga Developer harus

selalu siap dengan perubahan karena perubahan akan selalu diterima.

Tidak bisa membuat kode yang detail di awal (prinsip simplicity dan
juga anjuran untuk melakukan apa yang diperlukan hari itu juga).

XP tidak

memiliki

dokumentasi

formal

yang

dibuat

selama

pengembangan. Satu-satunya dokumentasi adalah dokumentasi awal

yang dilakukan oleh user.

3. Agile Modeling
Agile Model adalah suatu metode konvensional untuk membangun berbagai jenis
perangkat lunak dan berbagai macam tipe proyek pengembangan perangkat lunak,
yang dapat melakukan pengiriman atau penyampaian hasil dari implementasi sistem
melalui perangkat lunak dengan cepat.
Cara Kerja

Perencanaan

Requirements analysis

Design

Coding

Testing

Dokumentasi

Kelebihan

Meningkatkan rasio kepuasan pelanggan

Bisa melakukan review pelanggan mengenai software yang

dibuat lebih awal

Mengurangi resiko kegagalan implementasi software dari nonTeknis

Besar kerugian baik secara material atau imaterial tidak terlalu

besar jiak terjadi kegagalan

Kelemahan

Dokumentasi harus cukup detail agar fase selanjutnya dapat

berjalan dengan baik

4. RUP
RUP singkatan dari Rational Unified Process, adalah suatu kerangka kerja proses
pengembangan perangkat lunak iteratif yang dibuat oleh Rational Software, suatu divisi
dari IBM sejak 2003. RUP bukanlah suatu proses tunggal dengan aturan yang konkrit,
melainkan suatu kerangka proses yang dapat diadaptasi dan dimaksudkan untuk

disesuaikan oleh organisasi pengembang dan tim proyek perangkat lunak yang
akan memilih elemen proses sesuai dengan kebutuhan mereka.
Cara Kerja

Pemodelan bisnis (business modeling)

Analisis dan perancangan (analysis and design)

Implementasi (implementation)

Pengujian (testing)

Mendeskripsikan struktur dan proses-proses bisnis organisasi.

Kebutuhan (requirements)
Mendefinisikan kebutuhan perangkat lunak dengan menggunakan
metode use case.
Mendeskripsikan berbagai arsitektur perangkat lunak dari berbagai
sudut pandang.
Menulis kode-kode program, menguji, dan mengintegrasikan unit-unit
programnya.
Mendeskripsikan kasus uji, prosedur, dan alat ukur pengujian.
Deployment
Menangani konfigurasi sistem yang akan diserahkan.

Keuntungan

Menyediakan akses yang mudah terhadap pengetahuan dasar bagi

anggota tim.

Menyediakan petunjuk bagaimana menggunakan UML secara

efektif.

Mendukung proses pengulangan dalam pengembangan software.

Memungkinkan adanya penambahan-penambahan pada proses.

Memungkinkan untuk secara sistematis mengontrol perubahanperubahan

yang

terjadi

pada

software

selama

proses

pengembangannya.

Memungkinkan untuk menjalankan test case dengan menggunakan

Rational Test Manager Tool

Kekurangan

Metodologi ini hanya dapat digunakan pada pengembangan

perangkat lunak yang berorientasi objek dengan berfokus pada UML
(Unified Modeling Language).

Membutuhkan waktu yang cukup lama dibandingkan XP dan Scrum

5. SCRUM
Pertama kali diperkenalkan oleh Jeff Sutherland tahun awal tahun 1990an, dan
dikembangkan selanjutnya dilakukan oleh Schwaber dan Beedle. Pada dasarnya
Scrum merupakan salah satu komponen dari metodologi pengembangan Agile
mengenai pertemuan harian untuk membahas kemajuan sedangkan XP adalah
menekankan metodologi yang berbeda yaitu ujian, pemrograman dan
pembangunan. Scrum menguraikan proses untuk mengidentifikasi dan
katalogisasi pekerjaan yang perlu dilakukan, memprioritaskan yang bekerja
dengan berkomunikasi dengan pelanggan atau wakil pelanggan, dan pelaksanaan
yang bekerja menggunakan rilis iterative dan memiliki tujuan utama untuk
mendapatkan perkiraan berapa lama akan pembangunan.
Cara kerja

First meeting
o

Proses scrum diawli dengan pebuatan tujuan yang akan dicapai dan product
backlog.

Product backlog dikuantisasi waktu dengan satuan hari (antara 1-20 hari)
Product backlog merupakan ombinasi antara story-based work (pekerjaan
yang berbasis use case/product feature) dan task-based work misalnya
"Tambahkan

validasi

pada

semua

form"

Product backlog diprioritaskan oleh product owner.

o

Product backlog yang berisi list yang diprioritaskan dari fitur-fitur atau
perubahan yang akan ada pada produk.

Sprint planning meeting

o

Meeting untuk product owner, scrum team dan orang-orang yg

berkepentingan.

Menentukan sprint goal yaitu tujuan yang ingin dicapai pada scrum sprint
berikutnya

(30

hari

kedepan).

Sprint goal biasa adalah minimum fungsinalitas yang harus dicapai.

Jika sprint goal tidak dicapai maka dilakukan abnormal termination
o

Membuat sprint backlog yaitu list dari pekerjaan yang akan dilakukan selama
sprint.
Sprint backlog merupakan bagian produck backlog yang didetailkan.
Sprint backlog dikuantisasi waktu berdasarkan jam (bukan hari yaitu antara 116).
Sprint backlog harus tranparan untuk semua orang dalam tim

Meeting

yang

tidak

lebih

dari

jam

saja.

Dengan 4 jam pertama adalah waktu yang digunakan untuk Product Owner
menjelaskan atau presentasi tentang prioritas dari product backlog.
Kemudian tanya jawab dari tim tetang isi, maksud, tujuan dari item yang ada
di product backlog.
o

Empat jam berikutnya adalah sesi untuk tim merencanakan Sprint.

Fokus pada melakukan pekerjaan bukan berfikir mengenai bagaimana

mengerjakannya.

Daily Scrum meeting (Inspect and adapt cycle)

o

Meeting harian selama tidak lebih dari 15 menit

Yang boleh bicara dalam tim ini adalah scrum master dan anggota tim (pigs)

Orang lain yang bekepentingan (chickens) dapat ikut dalam tim tetapi tidak
boleh berkomunikasi (berbicara)

Scrum master menanyakan 3 pertanyaan dari kepada anggota tim:

Apa yang sudah kamu lakukan kemarin (selama 24 jam kebelakang)?

Apa yang akan dikerjakan pada esok hari (24 jam mendatang)?

Hal apa yang bisa menghentikan pekerjaan besok hari (kendala)?

Sprint review meeting

o

Meeting setelah aktivitas selama 2 minggu atau 1 bulanan (Sprint) berakhir,

yang kemudian diikuti oleh sprint planning meeting untuk Sprint berikutnya.

Meeting sebagai review atas Sprint yang sudah dilaksanakan.

Memperbarui (update) sprint backlog yang merefleksikan berapa lama waktu

yg dibutuhkan untuk menyelesaikan pekerjaan (task)

Sprint retrospective meeting

o

Meeting setelah sprint review meeting dan sprint planning meeting

ScrumMaster dengan tim untuk merevisi proses dan cara kerja Scrum, proses
development agar Sprint berikutnya lebih efektif dan enjoyable.

Meeting ini sebaiknya tidak lebih dari 3 jam.

Kelebihan

Keperluan berubah dengan cepat

Tim berukuran kecil sehingga melancarkan komunikasi,

mengurangi biaya dan memberdayakan satu sama lain

Pekerjaan terbagi-bagi sehingga dapat diselesaikan dengan cepat

Dokumentasi dan pengujian terus menerus dilakukan setelah

software dibangun

Proses Scrum mampu menyatakan bahwa produk selesai kapanpun

diperlukan

Kelemahan

Developer harus selalu siap dengan perubahan karena perubahan

akan selalu diterima.

6. Continuous Integration (CI)

CI merupakan metodologi untuk pengembangan perangkat lunak, di mana

anggota tim diwajibkan untuk sesering mungkin mengintegrasikan kerjaannya
dengan developer yang lain. Biasanya ritmenya per hari atau sering disebut daily
build. Setiap proses integrasi tersebut akan dilakukan pengujian secara otomatis
untuk mendapatkan defect atau problem secepat mungkin dan selanjutnya
diperbaiki. Banyak anggota tim menemukan bahwa pendekatan ini menyebabkan
masalah integrasi berkurang secara signifikan dan memungkinkan anggota tim
untuk

mengembangkan

perangkat

lunak

kohesif

lebih

cepat.

Dengan menggunakan metodologi pengembangan perangkat lunak (software

development methodology) ini, maka para pengembang (developer) punya fasefase yang lebih terstruktur sehingga proses manajerial dan kontrol dalam
pembuatan perangkat lunak menjadi lebih baik.
Cara Kerja

Kelebihan

Mengurangi proses manual yang berulang.

Mengurangi resiko karena mendeteksi & memperbaiki masalah

integrasi yang terus menerus.

Membuat proyek lebih baik dan jelas.

Menghasilkan perangkat lunak yang dapat di-deploy kapan saja dan

dimana saja.

Menghemat waktu dan biaya selama proyek berlangsung.

kelemahan

Memerlukan pengaturan awal terlebih dahulu tahap demi tahap.

Memerlukan test kode untuk mencapai pengujian secara otomatis.

Refactoring (melakukan perubahan pada kode program dari

perangkat lunak dengan tujuan meningkatkan kualitas dari struktur
program tersebut tanpa mengubah cara program tersebut bekerja)

[5] dalam skala besar dapat menggangu karena dapat merubah

basis kode.

Membutuhkan biaya perangkat keras yang besar untuk membangun

mesin yang mendukung.

7. Crystal Clear
Crystal clear merupakan methodology agile atau lightweight. Crystal
Clear diaplikasikan pada team dengan kapasitas 6-8 developer yang berkerja
pada SUATU system. Crystal Clear berfokus pada manusia bukan pada proses
atau arfifak. Crystal Clear merupakan anggota dari keluarga Kristal metodologi
seperti yang dijelaskan oleh Alistair Cockburn dan dianggap contoh dari
metodologi tangkas atau ringan. Crystal Clear dapat diterapkan untuk tim
hingga 6 atau 8 pengembang sistem yang sedang tidak kritis.
Cara kerja
Metodologi Crystal Clear berfokus pada efisiensi dan kelayak
hunian sebagai komponen keselamatan proyek atau berfokus pada
orang, bukan proses atau artefak.
Kelebihan

Dapat digunakan untuk system yang sering melakukan perintah

pengiriman data.

Dapat melakukan perbaikan reflektif agar dapat memperbaiki

error pada system secara menyeluruh.

Dapat melakukan komunikasi osmotik, yaitu komunikasi terbuka.

Memiliki Scurity yang tinggi.

Mudah untuk fokus pada pengguna system.

Akses mudah ke pengguna ahli.

Tes otomatis, manajemen konfigurasi, dan integrasi

Secara aktual menjadi sebuah model proses (keluarga Crystal)

yang

memungkinkan

manuver

berdasar

karakteristik

permasalahan.

Menyarankan penggunaan untuk review kebiasaan kerja tim.

Selalu murah dan cepat karena berkomunikasi secara langsung.

Proyek berkembang sesuai ukuran team menjadi lebih atau luas

dan metodologi akan menjadi lebih tinggi.

Kekurangan

Metodologi ini tidak cocok digunakan untuk system yang berfokus

pada proses atau pun teknologi yang digunakan (artifak).

Metodologi ini kurang cocok digunakan oleh awam karena

metodologi ini dapat dikuasai oleh perancang system yang telah
memiliki pengalaman banyak dalam membuat system sehingga
dapat memenuhi kebutuhan pengguna dan sistemnya.

Metodologi ini sangat bergantung pada kerja tim yang telah

memiliki tugas dan tanggung jawab masing-masing karena
metodologi ini kompleks.

8. Feature Driven Development (FDD)

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.
Cara Kerja
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.

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

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.

Design by Feature dan Build by Feature

Tahapan ini adalah pembuatan program sesuai fitur fitur yang
telah disusun.
feature

ada

Proses
proses

design by eature dan

build by

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

Kelebihan

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.

Kekurangan

Pengubahan feature hanya dapat dilakukan hanya pada proses pertama

dan secara keseluruhan hanya mampu memberikan penambahan kurang
dari 10%.

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.

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.

Peran serta client hanya pada beberapa tahapan saja.

Karena jumlah jam kerja dari FDD yang tidak terikat, maka kemungkinan
pada saat di tengah - tengah jadual, para developer bekerja tidak
optimal dan di akhir jadual akan bekerja extra keras.

9. Kanban
Kanban adalah sebuah sistem komunikasi yang mengontrol aliran aktifitas di area
produksi, dan berfungsi untuk menselaraskan level produksi agar sesuai dengan
permintaan pelanggan. Kanban hadir dalam bentuk sistem visual yang memungkinkan
semua orang melihat aliran aktifitas dan menyesuaikan level aktifitas tersebut sesuai

kebutuhan.
Cara Kerja

Penerapan 5S
5S adalah dasar dari Lean Thinking. Jadi, tidak bisa ditawar lagi, 5S harus
dilakukan sebelum Lean Thinking diterapkan. Tanpa penerapan 5S, Lean
Thinking tak dapat dilakukan dengan baik.

Menentukan Satuan Kebutuhan

Setiap barang mempunyai satuan kebutuhan masing-masing. Yang
dimaksud satuan kebutuhan adalah jumlah barang yang dibutuhkan untuk
suatu waktu tertentu. Cara mendapatkannya adalah dengan melakukan
penghitungan rata-rata pemakaian dalam suatu kurun waktu tertentu.

Menentukan Supply Time

Supply Time adalah waktu yang dibutuhkan oleh supplier untuk memasok
barang sejak dipesan sampai dengan barang tiba di gudang. Makin cepat
supply time, pengelolaan inventory makin baik. Dan makin lama supply
time, pengelolaan inventory makin buruk.

Menentukan Buffer/Safety Stock

Buffer stock adalah persediaan tambahan yang digunakan sebagai
cadangan untuk keadaan yang diluar kebiasaan

Menentukan Periode Stock

Periode stock adalah jangka waktu yang ditentukan untuk menyimpan
stock.

Menetukan Reorder Point

Reorder point adalah suatu kondisi jumlah stock tertentu dimana kita
harus melakukan pemesanan berikutnya.

Menentukan Order Quantity

Order quantity adalah jumlah barang yang akan dipesan. Caranya adalah
dengan mengalikan antara satuan kebutuhan dengan periode stock. Nah,
pada contoh di atas, satuan kebutuhannya adalah satu dus per hari, dan
periode stocknya adalah satu minggu. Jadi, order quantity nya adalah
tujuh dus.

Membuat Kartu Kanban

Membuat Kotak Kartu Kanban Pemesanan

Kotak kanban berguna untuk meletakkan kartu kanban yang muncul.

Membuat Kotak Kartu Kanban yang Sudah Dipesan

Setelah barang dipesan, kartu kanban diletakkan di kotak kartu kanban
yang sudah dipesan.

Kelebihan

Menentukan level produksi

Dengan mengatur kuantitas Kanban yang berbasis kepada permintaan
pelanggan, keseluruhan area produksi akan teratur menurut kuantitas
output yang diperlukan.

Mengurangi WIP (Work-In-Process)

Dengan mengkoordinir level produksi dari setiap lini sesuai dengan
permintaan, inventori WIP akan dibatasi oleh sistem Kanban. Hasilnya
adalah inventori yang seminim mungkin.

Kualitas meningkat
Salah satu prinsip Kanban adalah tidak boleh membiarkan lini
produksi memproses sesuatu yang kualitasnya rendah. Prinsip ini, bila
digabungkan dengan rendahnya WIP, akan meminimalisir terciptanya
produk yang cacat atau yang berkualitas buruk. Makin baik kualitas
output, makin rendah biaya yang harus dikeluarkan untuk rework
atau pembuangan.

Optimasi aliran kerja

Penataan aliran kerja akan lebuh mudah dengan demand yang stabil.
Setiap aktifitas produksi dapat dilakukan untuk memenuhi jumlah
tertentu, dan di-optimasi menurut jumlah tersebut.

Akurasi inventori dan menghindari produk menjadi usang

ketika produksi dilakukan berdasarkan permintaan, maka makin
sedikit inventori yang menumpuk. Hal ini juga akan meminimalisir
pemborosan berupa produk yang usang karena terlalu lama disimpan.

Penghematan
Tingkat inventori yang rendah akan memangkas biaya penanganan
inventori.

Keteraturan
Ketika kita dapat mengatur area produksi sesuai dengan kebutuhan,
kita juga dapat merencanakan tata letak area tersebut untuk
memaksimalkan produktifitas dan membuat segalanya lebih teratur.

Fokus kepada target bersama

Salah satu keuntungan yang tak disangka dari penggunaan Kanban
adalah terciptanya target-target yang akan dikejar oleh semua orang
yang terlibat di area Kanban. Target-target ini merupakan target
bersama yang menyedot fokus dari segala pihak; karyawan akan

dapat melihat seberapa jauh kontribusi mereka dalam memenuhi

permintaan pelanggan, dan akan mengarahkan fokus untuk
memenuhi permintaan tersebut.

Lebih dari itu, sistem Kanban juga dapat digunakan sebagai sarana
untuk mengungkapkan berbagai masalah yang terselubung di
lapangan. Dengan kata lain, Kanban adalah alat untuk mengungkapkan
potensi improvement.

mengurangi over-production, pemborosan yang paling berbahaya

diantara 7 pemborosan di pabrik.

Kelemahan

Kanban melahirkan informasi yang tidak akurat, kurang efisien dalam

pengiriman jauh, tidak ada visibilitas dikejauhan, membatasi dan
kemampuan pemantauan.

Dukungan terbatas untuk kinerja pengukuran

10. 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.
Cara Kerja

Pada tahap Speculation, proyek dimulai dan adaptive cycle planning diselenggarakan.
Pada tahapan ini, didefinisikan visi dan misi pengguna terhadap sistem yang akan
dibuat, selanjutnya mendefinisikan project constraints, misalnya: waktu deliver. dan
selanjutnya mendefinisikan satu set dari requirements yang akan dikerjakan dalam
suatu cycle.
Pada tahap Collaboration, pada tahap ini diorganisasikan tim kerja untuk membangun
sistem. Direkomendasikan menggunakan model Joint Application Development
(JAD). Collaboration : orang-orang yang bermotivasi tinggi bekerja sama: saling
melengkapi, rela membantu, kerja keras, trampil di bidangnya, dan komunikasikan
masalah untuk hasilkan penyelesaian yang efektif.
Pada tahap Learning, terdapat tiga aktifitas yaitu: pelanggan atau end-user
menyediakan feedback terhadap hasil incremental delivery, tim ASD melakukan
review terhadap komponen perangkat lunak untuk memperbaiki dan meningkatkan
kualitas perangkat lunak yang sedang dibuat. Learning: tim pembangun sering merasa
sudah tahu semua hal tentang proyek,

padahal tidak selamanya begitu. Karena itu proses ini membuat mereka belajar lebih
tentang proyek melalui 3 cara:
Focus group: klien dan pengguna memberi masukan terhadap software
Formal Technique Reviews: Tim ASD lengkap melakukan review
Postmortems: Tim ASD lakukan instrospeksi pada kinerja dan proses

Kelebihan

Fokus grup, klien dan pengguna memberi masukan terhadap perangkat

lunak.

Formal Technique Reviews, tim ASD lengkap melakukan review.

Postmortems, tim ASD melakukan instrospeksi pada kinerja dan proses.

Kelemahan

tidak terukur,

lebih ketergantungan pada komunikasi manusia antar

perlu

untuk

pemantauan

proyek

intensif

dan

pengendalian

untuk

mempertahankan antara tim dalam dan tim luar untuk collaboartion selama
pengembangan komponen

ada model khusus yang ditentukan

11. Dynamic Systems Development Method (DSDM)

Dynamic Software Development Method (DSDM) pada dasarnya merupakan suatu metodelogi
pengembangan perangkat lunak yang didasarkan pada metodelogi RAD.

Cara Kerja
o Feasibility study
o Business study prioritized requirements
o Functional model iteration

Risk analysis

Time-box plan

o Design and build iteration

o Implementation
Kelebihan

Menyajikan kerangka kerja (framework) untuk membangun dan

memelihara sistem dalam waktu yang terbatas melalui penggunaan
prototyping yang incremental dalam lingkungan yang terkondisikan.

Membangun software dengan cepat.

DSDM dapat dikombinasikan dengan XP menghasilkan kombinasi

model proses yang mengikuti DSDM dan praktek yang sejalan dengan
XP.

Kelemahan

Setiap iterasi bergantung pada prototype sebelumya

Menentukan scope dari suatu prototype proyek tidak pernah selesai

Dokumentasi sering kali tidak lengkap fokus pada pembuatan

prototype

Isu-isu mengenai system backup and recovery, system performance

dan system security kurang/tidak diperhatikan dan sering terlupakan

12. Graphical system design (GSD)

adalah pendekatan modern untuk merancang pengukuran dan sistem kontrol
yang mengintegrasikan sistem software desain dengan hardware COTS untuk
secara

dramatis

menyederhanakan

pengembangan.

Pendekatan

ini

menggabungkan antarmuka pengguna, model komputasi, matematika dan

analisis, Input / output sinyal, abstraksi teknologi, dan berbagai sasaran
penyebaran. Hal ini memungkinkan ahli domain, atau ahli pelaksanaan non, akses
untuk merancang kemampuan di mana mereka akan tradisional perlu untuk
melakukan outsourcing ahli desain sistem.
13. Test-driven development (TDD)
TDD (Test Driven Development) adalah suatu konsep pengembangan aplikasi
dimana script untuk melakukan testing aplikasi dibuat lebih dulu dibandingkan
kode program utamanya. Script yang dimaksud disini adalah suatu kode program
yang melakukan test untuk menguji parameter, nilai keluaran yang dihasilkan oleh
suatu fungsi.
Cara Kerja
Cara kerja TDD ada 3 proses penting yaitu red, green, refactor :

Red, mengindikasikan test yang gagal, karena memang pada TDD tes akan
di setup ke gagal, untuk mengindikasikan bahwa kita baru membuat
sebuah skema testing dan belum membuat implementasi dari testingya

Green mengindikasikan kita sudah membuat code yang concrete dan

sudah melewati berhasil melewati fase testing.

Refactor merupakan proses mengubah internal code tanpa mengubah

behaviour dari code tersebut, Refactor bertujuan agar code yang di tulis
lebih efisien, tidak berulang-ulang dan dinamis. Dengan kata lain refactor
membuat code menjadi lebih mudah di gunakan dan di modifikasi

Kelebihan

mengurangi waktu debugging

meningkatkan kualitas software

kemungkinan-kemungkinan kesalahan software lebih cepat terdeteksi

Kekurangan

untuk scope software yang lebih besar, akan memerlukan lebih banyak
waktu

ika terjadi perubahan business logic, maka test case yang saling
berhubungan harus dimaintenance atau di pastikan sesuai dengan
business logic yang baru

14. Crystal Methods

Metode Kristal adalah sebuah keluarga metodologi (keluarga kristal) yang
dikembangkan oleh Alistair Cockburn pada pertengahan 1990-an.
Metode dalam kristal difokuskan pada :
1. Orang - orang
2. Interaksi
3. Masyarakat
4. Ketrampilan
5. Bakat
6. Komunikasi
Sifat Metodologi Crystal:

Pengiriman Sering

Perbaikan reflektif

Tutup atau osmotik komunikasi

Keselamatan pribadi

Fokus

Akses mudah ke pengguna ahli

Teknis lingkungan dengan tes otomatis, manajemen konfigurasi, dan integrasi

sering.

15. Lean software development

Lean software development adalah suatu proses engineering yang digunakan
untuk mengembangkan dan menghasilkan suatu software berkualitas tinggi yang
telah terjamin kehandalannya sehingga tidak terjadi kegagalan dalam penggunaan
software tersebut. Lean software development ini berpedoman pada pemahaman
lapangan dan kesesuaian pelaksanaan prinsip lean disepanjang seluruh proses
pengembangan software. Slogan yang dipakai yaitu berpikir besar, bertindak kecil,
gagal

cepat,

belajar

cepat.

Lean dapat mereduksi waktu pengembangan software karena waktu

pengembangan software dapat direduksi dengan cara mengurangi error
pengerjaan software yaitu menggunakan tujuh prinsip Lean, yaitu: Eliminate

Waste, Amplifying Learning, Decide As Late As Possible, Deliver As Fast As Possible,

Empower The Team, Built Integrity, See The Whole.
Kelebihan

Mengeliminasi Ketidak Effisienan membantu mempercepat proses, menghemat

sumberdaya dan efisiensi

Membantu memberikan produk lebih awal

Kekuatan tim membantu dalam membuat keputusan antara tim dan memotivasi tim

Proyek sangat bergantung pada tim yang saling bekerjasama dan berkomitmen pada
proyek

Customer harus mengetahui apa yang mereka butuhkan dan tidak bisa mengubah
setelah mereka membuat sebuah keputusan

Kita membutuhkan sebuah tim yang kemampuannya saling melengkapi

Kekurangan
Banyak perusahaan software development memakai agile development lifecycles dan
menggunakan prinsip lean

Xerox

Rally software

Patient keeper

Helphire

Corbis

16. Scrum-ban
Scrum ban adalah sebuah metodologi manajemen proyek tangkas. Juga disebut
sebagai scrumban atau scrum-larangan itu adalah campuran dari manajemen
proyek Scrum dan Kanban dengan aspek kedua metodologi disatukan. Scrum ban
dimaksudkan untuk lingkungan kerja yang tak terduga, di mana rencana dan
persyaratan mengubah sering. Menawarkan manajemen proyek yang fleksibel
bagi perusahaan yang

mendukung

dan

manufaktur produk

terfokus.

Metodology
Dalam scrum ban, kerja sama tim yang terorganisir dalam iterasi kecil dan
dimonitor dengan bantuan papan visual, mirip dengan scrum dan papan kanban.

Pertemuan Perencanaan diadakan untuk menentukan apa tugas untuk

menyelesaikan dalam iterasi berikutnya. Tugas tersebut kemudian ditambahkan
ke papan dan tim selesai mereka, setiap anggota tim bekerja pada satu tugas pada
satu waktu. Untuk menjaga iterasi pendek, batas tugas ditambahkan dan pemicu
perencanaan diatur di tempat bagi tim untuk mengetahui kapan harus
merencanakan ke depan. Tidak ada peran yang telah ditetapkan dalam scrum ban;
Tim terus peran yang telah mereka miliki.

17. Story-driven modeling

18. Velocity tracking
Velocity tracking adalah tindakan mengukur kecepatan kata. Kecepatan dihitung
dengan menghitung jumlah unit kerja selesai pada interval tertentu, panjang
yang ditentukan pada awal proyek.
Principle
Ide utama di balik kecepatan adalah untuk membantu tim memperkirakan
berapa banyak pekerjaan yang mereka dapat menyelesaikan dalam jangka waktu
tertentu berdasarkan seberapa cepat pekerjaan serupa sebelumnya selesai.
19. Software Development Rhythms

Daftar Pustaka

1.

http://id.wikipedia.org/wiki/Agile_Development_Methods (Metode Agiel)

2.

http://johenry72gar.blogspot.com/2013/12/feature-driven-developmentfdd.html (FDD)

3.

https://agusarimbawa.files.wordpress.com/2013/02/fdd-agile-disadvantages.pdf.

(FDD)
4.

http://www.christianozora.com/2014/02/continuous-integration-ci.html (CI)

5.

www.slideshare.net/fahmihamdani148/agile-modeling-26526835(Agile
Modelling)

6.

http://dhiekalantana.blog.unas.ac.id/2012/10/perbandingan-up-xp-scrumagile/ (Agile Modelling)

7.

http://dwixuty.blogspot.com/2013/10/kelebihan-dan-kekuranganmetode.html (Agile Modelling)

8.

https://keinatralala.wordpress.com/2013/12/13/metodologi-extremeprogramming/ (XP)

9.

https://ardhibeniyanto.wordpress.com/tag/scrum/ (Scrum)

10.

http://multimedia.telos.com/blog/pros-and-cons-of-agile-development (Pro &

Kontra Agile Development)

11.

http://www.kaizenconsulting.co.id/production-control-with-kanban.html
(KANBAN)

12.

http://shiftindonesia.com/kanban-hindarkan-penumpukan-inventoriciptakan-keteraturan-di-lini-produksi/ (KANBAN)

13.

http://myblogtriyasyifa.blogspot.com/ (Kelebihan ASD)

14.

sharif.edu/~ramsin/index_files/sdmlecture11.pdf (kelemahan asd)

15.

http://dwixuty.blogspot.com/2013/10/kelebihan-dan-kekuranganmetode.html (DSDM)

16.

http://www.academia.edu/6786913/TestDriven_Development_TDD_dengan
_PHPUnit (TDD)

17.

http://Mariosalexandrou.com (Crystal method)

20. http://lpbd.si.fti.unand.ac.id/tag/kelebihan/ (Lean software development)