Complete Agile
-
Upload
robiyah-wahyu-ningsih -
Category
Documents
-
view
20 -
download
2
description
Transcript of Complete Agile
1 | P a g e
Tugas Kelompok Rekayasa Piranti Lunak
- Agile Software Development -
Disusun Oleh:
Kelompok I – 04PQT
`Anggota Kelompok:
• 1401126026 WILLY LAZUARDI
• 1401125276 NICCO
• 1401126266 FEBRIAN NEDSENDA RIZKY
• 1401128082 AFRIYAN GUSTAF
• 1401126726 ADHIKA MAFRAN
• 1401126234 KURNIAWAN
BINUS University Jakarta 2012
2 | P a g e
Agile Development Secara Umum
A. Apa itu Agile Development?
Agile software engineering memadukan filosofi dan sekumpulan aturan dalam pengembangan
software. Filosofi yang lebih menekankan pada kepuasan pelanggan (customer) dan
penyampaian software secara berkala; berskala kecil; team proyek yang bermotivasi tinggi;
langkah pengerjaan proyek yang minimal; dan kesederhanaan. Aturan-aturan pengembangan
software lebih menekankan penyampaian pada pelanggan di atas pendesainan dan analisa
software itu sendiri (walaupun aktifitas ini tidak sepenuhnya disarankan), dan komunikasi yang
aktif dan berkesinambungan antar developer dan pelanggan.
B. Siapa yang melakukannya?
Para software engineer dan para pemangku kepentingan di dalam proyek (manajer, pelanggan,
dan end user) bekerja sama dalam sebuah agile team- sebuah tim yang dapat mengorganisir
dirinya sendiri (self-organizing) dan terkontrol. Sebuah agile team harus saling berkomunikasi
dan bekerja sama antar setiap individu yang ada di dalamnya.
C. Kenapa penting?
Lingkungan bisnis yang modern yang berbasis sistem komputer dan produk piranti lunak
bergerak sangat cepat dan selalu berubah. Agile software engineering merupakan alternatif
yang cocok untuk software engineering konvensional untuk berbagai jenis projek software.
Metode ini telah teruji untuk penyampaian sistem secara cepat.
D. Apa saja tahap-tahap yang ada dalam Agile Development?
Agile development dapat dikatakan sebagai “software engineering lite” – pengembangan
software yang ringan. Tahapannya terdiri dari aktifitas kerangka kerja dasar yang ada pada
metode pengembangan software secara umum, mencakup: tahap komunikasi, perencanaan,
modelng, konstruksi, dan deployment. Tetapi tahapan tersebut telah diubah menjadi kumpulan
pekerjaan yang minimal yang menekankan pekerjaan tim untuk fokus pada tahap konstruksi
dan penyampaian.
E. Apa produk yang dihasilkan?
Baik pelanggan dan software engineer memiliki sudut pandang yang sama – satu-satunya
pengerjaan produk yang paling penting adalah “peningkatan software” secara operasional yang
dapat disampaikan kepada pelanggan tepat waktu.
F. Bagaimana memastikan bahwa apa yang kita lakukan dalam development sudah benar?
Jika agile teamsudah setuju bahwa proses kerja, dan tim dapat memproduksi peningkatan
software yang dapat diterima dan memuaskan pelanggan, maka apa yang kita lakukan sudah
bisa dipastikan benar (berjalan sesuai rencana).
3 | P a g e
G. Manifesto Pengembangan Perangkat Lunak Agile
“Kami menemukan cara yang lebih baik untuk mengembangkan perangkat lunak dengan
melakukan dan membantu sesama untuk menggunakannya.
Melalui usaha ini kami telah dapat menghargai:
• Individu dan interaksi lebih dari proses dan sarana perangkat lunak.
• Perangkat lunak yang bekerja lebih dari dokumentasi yang menyeluruh.
• Kolaborasi dengan klien lebih dari negosiasi kontrak.
• Tanggap terhadap perubahan lebih dari mengikuti rencana.
Demikian, walaupun kami menghargai hal di sisi kanan, kami lebih menghargai hal di sisi kiri.” –
Kent Beck et al.
Individu dan interaksi : Dalam Agile Development, selft-organizartion dan motivasi tinggi sangat
penting, begitu juga dengan interaksi antar anggota tim seperti co-location (penempatan
peranan atau kelompok tertentu di dalam satu area) dan pair-programming (dua programmer
dalam satu grup bekerja yang sama).
Perangkat lunak yang bekerja: Model software yang berjalan lebih berguna dan disambut baik
oleh pelanggan dari pada sekedar mempresentasikan dokumentasi pada saat meeting.
Kolaborasi: Kolaborasi dengan pelanggan, kolaborasi dengan sesama developer. Requirement
dari pelanggan tidak bisa diperoleh dan dikumpulkan secara menyeluruh pada awal siklus
pengembangan software, oleh karena itu, keterlibatan pelanggan dan stakeholders secara
berkelanjutan adalah penting.
Tanggap teradap perubahan: Agile Development fokus kepada respon cepat terhadap
perubahan dan pengembangan secara berkelanjutan.
H. Pengertian Agility dalam Agile Development
Pengertian 1: Agility lebih dari sekedar respon yang efektif (cepat dan adaptif) terhadap
perubahan. Pengertian 2: Agility di sini menekankan struktur tim dan sikap-sikap yang membuat
komunikasi antar anggota (antara orang-orang teknis dan bisnis, antara developer dan manager
mereka) dapat berjalan lancar. Pengertian 3: Pengertian lainnya adalah penekanan terhadap
penyampaian software yang bersifat operasional secara cepat, dan kurang menekankan produk
kerja yang bersifat selingan (tidak selamanya bagus). Pengertian 4: Melibatkan pelanggan ke
dalam tim kerja dan menghilangkan istilah “kami dan mereka.” Pengertian 5: Menyadari bahwa
rencana (planning) dalam dunia yang tidak pasti ini mempunyai keterbatasan, sehingga rencana
proyek harus fleksibel. Walaupun bersifat fleksibel, tetap saja segala bentuk perubahan yang
dilakukan harus didasari dengan alasan yang jelas.
4 | P a g e
I. Pengaruh Agile Development terhadap Biaya
Dalam pengembangan software konvensional, biaya perubahan tidak linear terhadap
perkembangan proyek. Relatif mudah mengakomodir perubahan pada awal siklus
pengembangan software, skenario dapat diubah, fungsi-fungsi dapat dikembangkan lagi, dan
spesifikasi yang sudah tertulis dapat diedit ulang. Proses pengerjaan ini memang minim dan
tidak memakan waktu. Tapi setelah beberapa bulan, jika harus megubah requirement, biaya
yang diperlukan pastilah bertambah karena adanya efek samping dari perubahan yang
dilakukan.
Agile Model yang didesain dengan baik, dapat mengakomodir perubahan selama
pengambangan tanpa perubahan biaya dan penambahan waktu yang dramatis, karena
perubahan dilakukan tidak sekaligus, melainkan bertahap.
J. Prinsip-Prinsip Agility
1. Kepuasan customer melalui penyampaian software secara cepat.
2. Menerima perubahan requirement, bahkan jika development sudah berjalan.
3. Pengerjaan software disampaikan sesering mungkin (bulan, bahkan minggu).
4. Kedekatan; orang bisnis dan developer harus bekerja sama selama proyek.
5. Proyek dibangun dalam individu yang termotivasi, harus percaya satu sama lain.
6. Komunikasi paling efektif: face-to-face.
7. Pengerjaan software adalah ukuran utama kemajuan.
8. Pembangunan berkelanjutan, mampu mempertahankan kecepatan secara konstan.
9. Perhatian yang berkelanjutan terhadap keunggulan teknis dan desain yang baik.
10. Kesederhanaan.
11. Self-organizing team.
12. Beradaptasi rutin terhadap perubahan situasi.
5 | P a g e
K. Kriteria Sumber Daya Manusia dalam Agile Development
1. Kompetensi: Setiap anggota tim yang berkompeten, mencakup: kemampuan bawaan, memiliki kemampuan spesifik dengan software yang terkait, dan pengetahuan proses developmet secara keseluruhan.
2. Satu tujuan: Walaupun memiliki pekerjaan dan kemampuan yg berbeda-beda, seluruh anggota tim harus memiliki tujuan yang sama, yaitu: penyampaian software increment tepat waktu.
3. Kerjasama: Komunikasi dalam sebuah tim development harus dijaga dengan baik, untuk mencapai itu, anggota tim satu sama lain dan seluruh stakeholder harus berkolaborasi.
4. Kemampuan mengambil keputusan: Tim diberikan otonomi pengambilan keputusan entah dari segi teknis maupun masalah-masalah projek.
5. Kemampuan Fuzzy problem-solving: Manager harus sadar, tim agile ini akan selalu berhadapan dengan hal-hal yang ambigu dan perubahan yang terus-menerus. Solusi masalah hari ini belum tentu cocok untuk solusi masalah yang akan datang.
6. Saling percaya & menghormati: Pengerjaan secara kesulurhan lebih baik daripada hanya sebagian.
7. Self-organization: Mampu mengorganisir dirinya sendiri untuk menyelesaikan tugas, mampu mengorganisir proses yang paling tepat untuk mengakomodir lingkungan lokal, mengorganisir jadwal untuk mencapai penyampaian software increment tepat waktu.
6 | P a g e
Model-Model Agile Development
A. Extreme Programming (XP)
XP adalah salah satu pendekatan dalam proses agile. Xp ini paling banyak digunakan dalam proses agile. Xp diusulkan oleh Kent Black Karakteristik Beck membuat five values sebagai pondasi dari pekerjaan yang menggunakan metode xp. 1. Komunikasi
Agar stakeholders dan software engineers dapat berkomunikasi efektif, mereka membentuk kolaborasi informal antara stakeholders dan SE. Hal ini bertujuan untuk membuat customer, programmer, manager dapat mengerti system bekerja sehingga tidak berbeda pendapat ketika membahas konsep yang penting, masukkan yang terus menerus serta penggunaan dokumen yang tebal sebagai medium berkomunikasi
2. Kesederhanaan Xp membatasi developer untuk men-design kebutuhan yang mendesak daripada mempertimbangkan kebutuhan masa depan . tujuannya untuk membuat design yang simple yang dapat dengan mudah diimplementasikan kedalam code. Jika ada design yang yang ingin ditambahkan, dapat di refactored nanti. Refactored adalah memperbaiki struktur design bagian dalam tanpa mengubah fungsi luar atau kegunaannya. Dapat juga digunakan untuk mengubah efisiensi, kemudahan untuk digunakan, atau performa.
3. Feedback Feedback didapat dari 3 sumber. Implementasi software itu sendiri, customer, dan anggota tim. Dengan membuat design dan testing dari software yang kita buat, maka software itu akan memberi masukan kepada kita dimana kekurangannya. Xp membuat unit test sebagai taktik utama tes. Ketika laporan diberikan kepada customer, maka segala fungsi, output dan use case yang telah dibuat menjadi masukkan. Dan yang terakhir sebagai bagian dari tim, tim memberi masukkan kepada customer akan efek biaya dan jadwal.
4. Courage Courage dalam hal ini dapat disamakan dengan kedisiplinan. Sebagai contoh, sering ada tekanan untuk mendisign untuk kebutuhan yang akan datang. Sebagian tim banyak yang menyerah dengan alas an bahwa akan menghemat waktu jika dikerjakan dikemudian hari. Sebuah tim xp yang gesit, harus memiliki disiplin (keberanian) untuk merancangnya saat itu juga meskipun tau bahwa rancangannya nanti aka nada kemungkinan besar untuk diubah
5. Respect Dengan mengikuti setiap nilai-nilai yang ada, tim agile harus memiliki rasa respek antara sesame anggota, stakeholder, dan anggota tim lainnya serta secara tidak langsung softwarenya itu sendiri. Dikarenakan ketika mereka dapat mnyelesaikan tiap tahap software, tim juga mengembangkan respek kepada proses xp itu sendiri.
7 | P a g e
Proses XP
1. Planning
User stories Pertama dimulai dengan mendengarkan. Jadi kita berkumpul agar setiap member dari xp tim mengerti konteks-konteks untuk sotware yang hendak dibuat serta mengerti output, tampilan, dan fungsi serta fitur2 utamanya . dengan mendengarkan, maka akan mengarahkan pada suatu kreasi cerita “stories” yang juga disebut user stories yang menjelaskan output, fitur, dan fungsi software yang akan dibuat.
Cost dan lama pembuatan Anggota dari tim xp menilai tiap story dan menentukkan harga yang diukur dalam setiap minggu perkembangannya. Jika dibutuhkan waktu lebih dari 3 minggu perkembangan untuk story, maka customer diminta untuk membagi menjadi story yang lebih kecil lalu harus dibuat perhitungn harga lagi. Penting juga untuk diperhatikan bahwa story yang baru dapat dibuat sewaktu-waktu.
Commitment Customer dan developers akan bekerja bersama untuk membagi story yang akan diselesaikan dan dikembangkan oleh tim xp. Ketika komitmen dasar (story yang akan dikerjakan, tanggal penyelesaian, dan proyek penting lainnya) dibuat untuk dirilis, xp tim menentukan pengembangan story dari 3 kemungkinan yang ada. 1. Semua cerita akan dikerjakan sekaligus (dalam beberapa minggu) 2. Story yang terpenting akan dikerjakan terlebih dahulu dan di implementasikan
pertama 3. Story yang paling beresiko dikerjakan dan diimplementasikan terlebih dahulu
Project velocity Setelah proyek pertama telah diselesaikan, tim xp menghitung project velocity. Secara simple, project velocity adalah sejumlah story pelanggan yang telah diimplementasikan selama rilis pertama. Project velocity dapat digunakan untuk
o Membantu memperkirakan tanggal penyelesaian serta jadwal rilis berikutnya o Untuk menentukan apakah terjadi overcommitment pada story yang akan
dikembangkan. Jika terjadi, maka isi story harus diubah atau tanggal penyelesaian diganti.
unit t est
cont inuous int egrat ion
accept ance t est ing
pair
programming
Release
user st ories
values
accept ance t est crit eria
it erat ion plan
simple design
CRC cards
spike solut ions
prot ot ypes
refact oring
sof tware increment
project velocit y computed
8 | P a g e
2. Design
KIS principle Design di xp harus menggunakan KIS principle yaitu Keep It Simple. Design yang simple selalu lebih diutamakan daripada presentasi yang kompleks. Sebagai tambahan, story dalam design juga hars sesuai yang ada, tidak kurang juga tidak lebih. Jika ada design ekstra karena kita berpikir bahwa akan dibutuhkan nanti diharuskan untuk tidak dibuat.
CRC card Xp menggunakan crc card sebagai mekanisme efektif untuk membuat software dalam konteks object oriented. Crc card mengidentifikasi dan mengatur class object oriented yang berhubungan dengan proyek yang sedang dikerjakan.
Spike solution Jika terjadi design yang sulit dikerjakan, xp merekomendasikan untuk membuat prototype design tersebut. Ini dinamakan spike solution. Jadi design prototype diimplementasikan dan di evaluasi. Tujuannya untuk mengurangi resiko ketika implementasi yang sebenarnya dijalankan dan untuk menemukan masalah utama yang mungkin akan terjadi.
Refactoring Di tahap selanjutnya, xp mengharapkan untuk melakukan refactoring. Seperti yang sudah dijelaskan sebelumnya bahwa refactoring adalah proses merubah system software tanpa mengubah tampilan luar namun mengubah struktur didalamnya. Tujuan dari refactoring adalah untuk mengkontrol perubahan dengan menyarankan perubahan design yang kecil yang dapat meningkatkan design seluruhnya. Semakin besar aplikasi yang dikembangkan, semakin besar penggunaan refactoring.
3. Coding
Unit test Setelah story dikembangkan dan design awal selesai, tim tidak langsung mengerjakan code tetapi mengembangkan beberapa seri unit test yang akan menjalankan story yang akan dimasukkan dalam rilis saat ini. Ketika unit test sudah dibuat, penting untuk developer untuk memfokuskan code apa yang akan diimplementasikan untuk melewati test. Tidak ada tambahan yang diperlukan (KIS). Ketika kode telah selesai, maka akan di unit tes langsung, sehingga dapat memberikan masukkan instan kepada developer.
Pair programming Xp merekomendasikan untuk 2 orang bekerja bersama dalam satu computer dalam membuat kode untuk story. Hal ini memberikan mekanisme untuk real time problem solving( 2 kepala selalu lebih baik daripada 1 kepala). Hal ini juga membuat developer focus pada kerjaan yang ada. Dalam penerapannya, setiap orang mengambil tugas yang sedikit berbeda. Sebagai contoh satu orang memikirkan rincian coding bagis teertentu dari design sementara yang lain memastikan coding standart digunakan atau apakah story melewati unit test.
4. Testing
Unit tes setiap hari Unit tes dilakukan setiap harinya sehingga memudahkan ketika ada bagian yang dapat menjadi bahaya saat implementasi nanti. Membenarkan masalah kecil dalam beberapa
9 | P a g e
jam memakan waktu lebih sedikit ketika membenarkan masalah besar tepat sebelum deadline
Customer test Customer test ini memfokuskan pada fitur dan fungsi yang dapat dilihat dan di riview oleh customer.
Debat XP
Requirement yang berubah-ubah Customer sebagai member aktif didalam xp tim, dapat merequest perubahan requirement secara informal. Sebagai konsekuensinya, project dapat berubah dan pekerjaan sebelumnya harus diubah sesuai kebutuhan sekarang.
Conflicting customer needs Banyak project memiliki customer yang lebih dari satu. Masing2 dengan keinginan sendiri.
Requirements are expressed informally Kritik mengatakan bahwa model yang formal diharuskan untuk mengurangi inkonsistensi serta error.
Lack of formal design Kritik : design menjadi informal seharusnya struktur menunjukkan sesuatu yang berkualitas. Proponents : simple adalah inti sehingga mengurangi kebutuhan yang luas.
10 | P a g e
B. Adaptive Software Development (ASD)
ASD diusulkanoleh Jim Highsmith
KarakteristikdariASD :
a. Perencanaan Mission-driven
b. FokuspadaComponent-based
c. Menggunakantime-boxing
d. Pertimbanganresiko yang jelas
e. Menekankancollaborationuntukpengumpulanbahan
f. Menekankanlearningselama proses berlangsung
Proses ASD:
ASD Speculation
o Menggunakan adaptive cycle planning.
o Menggunakan user mission statement, project constraints.
o Setelahsikluspertama,rencanadikajiulangdandisesuaikan agar
proyeknyasesuaidenganrealitadimana team ASD bekerja.
ASD Collaboration
o Meliputikomunikasidankerjasamaantar team tetapitetapmenekanindividualis.
o Mengumpulkankebutuhandengan mini specs.
ASD Learning
o MenggunakanFocus group dan Formal Technical Review.
o Melakukanevaluasiulang.
adapt ive cycle planning
uses mission st at ement
project const raint s
basic requirement s
t ime-boxed release plan
Requirement s gat hering
JAD
mini-specs
component s implement ed/ t est ed
focus groups for feedback
formal t echnical reviews
post mort ems
sof tware increment
adjustments for subsequent cycles
Release
11 | P a g e
C. Dynamic System Development Method (DSDM)
Metode Pengembangan Sistem Dinamis (Dynamic System Development Environment)
Diusung oleh DSDM Consortium (www.dsdm.org)
Karakteristik DSDM hampir mirip dengan XP atau ASD
Sembilan prinsip pemandu:
Keterlibatan user secara aktif adalah keharusan.
Tim DSDM harus dilibatkan dalam pengambilan keputusan.
Fokusnya adalah pada penyajian produk sesering mungkin.
Kesesuaian untuk kepentingan bisnis adalah kriteria terpenting untuk penerimaan penyajian.
Pengembangan bertahap dan berulang diperlukan untuk fokus pada solusi bisnis yang akurat.
Seluruh perubahan selama development dapat dibatalkan (reversible).
Requirement adalah baselined (dasar) pada tingkat yang tinggi.
Testing diintegrasikan melalui life-cycle
Proses DSDM
12 | P a g e
Proses DSDM
Kegiatan Sub kegiatan Penjelasan
Studi
Studi kelayakan
Menilai kelayakan pengerjaan suatu proyek, termasuk kecocokan proyek tersebut dengan penggunaan DSDM. Dihasilkan laporan kelayakan, kelayakan prototip, skema global perencanaan berikut rencana pengembangan dan catatan resiko
Studi bisnis
Analisa karakteristik dari sisi bisnis dan teknologi. Pendekatan utama adalah pengadaan lokakarya, di mana pengguna ahli berkumpul dan menghasilkan hal-hal yang relevan dari sistem serta menyetujui skala prioritas dalam pengembangan. Dihasilkan daftar prioritas kebutuhan, definisi dari wilayah bisnis, definisi arsitektur sistem, dan garis besar rencana prototip
Perulangan Model Fungsional
Mengenali prototip fungsional
Menentukan fungsionalitas yang akan dikerjakan pada prototip. Dihasilkan sebuah model fungsional menurut hasil dari tingkat studi bisnis.
Menyetujui jadwal Setuju pada bagaimana dan kapan untuk membangun fungsionalitas tersebut.
Membuat prototip fungsional
Membangun prototip fungsional, sesuai jadwal yang disetujui dan model fungsional.
Meninjau prototip fungsional
Mengecek kebenaran dari prototip yang dibangun. Hal ini dilakukan melalui pengujian oleh pemakai akhir dan / atau melihat dokumentasi. Dihasilkan sebuah dokumen tinjauan prototip model fungsional
13 | P a g e
Perulangan Perancangan dan
Pembuatan
Mengenali prototip rancangan
Mengenali kebutuhan fungsional dan non-fungsional yang diperlukan dalam sistem yang diujikan. Dihasilkan suatu strategi penerapan, yang juga didasari catatan pengujian dari perulangan sebelumnya.
Menyetujui jadwal Setuju pada bagaimana dan kapan memenuhi persyaratan yang ada.
Membuat prototip rancangan
Membuat sebuah sistem (prototip rancangan) yang dapat secara aman diserahkan kepada pengguna akhir untuk penggunaan harian, juga sebagai ujicoba.
Meninjau prototip rancangan
Mengecek kebenaran hasil rancangan sistem, melalui serangkaian teknik ujicoba dan peninjauan. Dokumentasi pengguna maupun catatan pengujian akan dibuat.
Implementasi
Persetujuan pemakai dan garis pedoman
Pengguna akhir menyetujui sistem yang telah diuji untuk diterapkan and sebagai pedoman, dengan mematuhi ketentuan sistem yang telah dibuat.
Melatih pengguna Melatih calon pengguna dalam penggunaan sistem. Dihasilkan sekelompok pengguna yang terlatih
Penerapan Menerapkan sistem yang telah teruji (tested system) di lokasi pengguna akhir, disebut juga sistem yang tersampaikan.
Tinjauan bisnis
Meninjau dampak dari penerapan sistem pada bisnis, dengan isu pokok apakah sistem memenuhi tujuan yang ditentukan pada awal proyek. Berdasarkan hal ini proyek akan menuju tahap selanjutnya, yaitu setelah proyek, atau kembali ke salah satu tahap sebelumnya untuk perbaikan lebih lanjut. Hasil peninjauan ini akan didokumentasikan dalam dokumen tinjauan proyek.
14 | P a g e
D. SCRUM
Scrum adalah sebuah proses agile yang memungkinkan kita untuk memfokuskan diri
guna menghasilkan nilai ekonomi paling tinggi dalam jangka waktu yang sangat singkat.Scrum
memungkinkan kita untuk dapat melihat software yang dapat bekerja (setiap dua minggu hingga
satu bulan) secara cepat dan berulang kali.Bisnis akan menentukan prioritas. Tim akan mengatur
dirinya sendiri untuk menentukan teknik terbaik dalam menghasilkan fitur dengan prioritas
tertinggi.Setiap dua minggu hingga satu bulan sekali semua pihak dapat melihat sebuah software
yang dapat bekerja dan memutuskan untuk merilis software sebagaimana adanya atau
melanjutkan untuk mengembangkannya di sprint berikutnya
Asal Mula Scrum
• Jeff Sutherland • Dimulai di Easel Corp pada tahun 1993 • IDX dan 500+ orang melakukan Scrum
• Ken Schwaber • ADM • Scrum dipresentasikan di OOPSLA pada tahun 96 dengan Sutherland • Penulis 3 buku mengenai Scrum
• Mike Beedle • Scrum patterns di PLOPD4
• Ken Schwaber dan Mike Cohn • Mendirikan Scrum Alliance pada tahun 2002 yang awalnya bagian dari Agile Alliance
Biasanya Scrum Digunakan untuk Software :
• Software komersil
• Pengembangan internal
• Proyek dengan kontrak
• Proyek dengan harga tetap
• Aplikasi keuangan
• Aplikasi yang tersertifikasi ISO 9001
• Sistem embedded
• Sistem yang uptimenya harus 99.999%
• Pengembangan video game
• Sistem kritikal yang harus diuji oleh Depkes
• Software mengendalikan satelit
• Website
• Software untuk PDA
• Telepon genggam
• Aplikasi untuk jaringan listrik
• Aplikasi ISV
• Beberapa aplikasi besar yang sedang anda gunakan
15 | P a g e
Karakteristik
• Pekerjaan dipartisi ke dalam bentuk Paket • Testing dan dokumentasi dilakukan on-going selama produk dikonstruksi • Pengerjaan terjadi dalam Sprint Backlog dan diturunkan dari Product Backlog atas
requirement yang sudah ada • Meeting Singkat Setiap Hari selama 15 Menit • Demo Product disampaikan kepada customer dengan alokasi Time-Box
Proses Scrum
Product Backlog : Fitur-fitur yang di catat sebagai item dan diurutkan berdasarkan pioritasnya
Sprint Backlog : Backlog yang memiliki pioritas lebih tinggi untuk di kerjakan oleh tim scrum
berdasarkan spesialisasi masing-masing.
Sprint : waktu yang di tetapkan oleh product owner dan scrum master dengan alokasi time-
boxing biasanya 2-4 minggu
Daily meeting : Meeting yang wajib dilakukan oleh Scrum master dan di hadiri oleh anggota
tim untuk menjawab pertanyaan sebagai evaluasi hasil kerja per 24 jam.
1. Apa yang telah anda lakukan kemarin?
2. Apa yang akan anda lakukan hari ini?
3. Apakah yang menghambat anda untuk menyelesaikan pekerjaan anda?
Potentially product shipping increment : yaitu setiap backlog atau product yang telah selesai
dikerjakan selama sprint dan di demonstasikan ke product owner.
16 | P a g e
Siapa aja yang terlibat dalam Scrum?
• Product Owner : Orang yang menginginkan product tersebut di buat
• Scrum Master : yaitu leader team yang memanajemen tim scrum
• Team : orang-orang yang terlibat dalam pembuatan product
Kelebihan & Kekurangan Scrum
Strength
• Customer Merasa puas karena product seperti yang di harapkan
• Meningkatkan efisiensi
• Proses Sederhana dan mudah
• Dini dan sering rilis
• Perubahan diperbolehkan untuk berkembang seiring waktu.
Weakness
• Tidak ada usaha desain jelas
• Kurangnya skalabilitas
• Kurangnya formalisme
Perusahaan yang telah menggunakan metode scrum :
• Microsoft
• Nokia
• Yahoo
• IBM
• Adobe
• Intel
• BBC
• Amazon
• Guideware
• Electronic Arts
• Citibank
• Motorolla
• Bank of America,etc.
17 | P a g e
E. CRYSTAL
Cockburn dan Highsmith menciptakan crystal Family(clear,yellow,orange,red) sebagai metode
dari agile development.
Karakteristik :
Sebuah proses model menggunakan “maneuverability” berdasarkan karakteristik masalah
yang dihadapi.
Proyek dikategorikan sesuai dengan kekritisan (Comfort, Discretionary money, Essential
money, life) dari sistem yang diproduksi dan ukuran proyek.
Sangat menekankan pada komunikasi Face-to-Face
Menggunakan “reflectionworkshops” untuk meninjau kebiasaan pada kerja tim.
Kelebihan dan Kelemahan Crystal
Strength
• Cepat dan Sering di rilis
• Skalabilitas
Weakness
• Terbatas skalabilitas
• Sering terjadi proses yang ambigu
• Tergantung pada komunikasi manusia
18 | P a g e
F. Feature Driven Development(FDD)
Dicetuskan oleh Peter Coad et al dan teamnya [Coa99].
FDD mempunyai karakteristik seperti berikut :
1. Sebuah proses model yg menggunakan ‘maneuverability” berdasarkan masalah yg
dihadapi. Maneuverability artinya kemampuan menggerakkan sesuatu.
2. Menekankan pada pendefinisian “feature”.
Dalam FDD, feature berarti nilai/inti yg diinginkan client yang bisa
diimplementasikan dalam waktu 2minggu atau kurang.
3. FDD menggunakan template untuk prosesnya seperti berikut :
<action> the <result><by|for|of|to> a(n)<object>
Contoh dalam aplikasi e-commerce: Add the Product to Shopping Cart, Add =
action, Product = result, dan Shopping Cart = Object.
4. Membuat Feature List dan melakukan perencanaannya
Feature List adalah daftar feature yang digunakan untuk menjelaskan suatu
proses,contoh :
a. Add the Product to Shopping Cart,
b. Display the Specification of the Product,
c. Store the shipping-information for the Customer.
Yang pertama adalah Develop an overall model, yaitu mengembang kan keseluruhan
model.Disini team project membuatu model object dari domain bisnis yg lebih banyak
bentuknya daripada isinya. Model ini belum sepenuhnya didefinisikan dengan semua
atribut dan metode.
Proses FDD
Yangg kedua adalah Built a Feature List, yaitu membuat daftar Feature seperti yg telah
disebutkan tadi. Tetapi dalam membuat feature kita menggunakan bahasa Client
(bahasa yg dimengerti Client) sehingga tidak terjadi kesalahpahaman.
Yang ketiga adalah Plan By Feature, yaitu Perencanaan untuk Feature.
dibagian ini Feature akan di rencanakan proses apa saja yg perlu dilakukan.
Yang keempat adalah Design by Feature, yaitu Perancangan untuk Feature.
Feature tersebut akan di rancang sehingga mencapai Client-Value Function.
dan yg terakhir adalah Built by Feature = yaitu Dikerjakan untuk Feature.
ditahap ini Feature di kerjakan hingga selesai dan mencapai Client-Value Function.
19 | P a g e
Kelebihan dan Kekuragan FDD
Kelebihan:
Karena Feature gampang dimengerti, sehingga user mudah memahami bagaimana
mereka berhubungan antara 1 sama lainnya, dan lebih baik untuk meninjau apakah
mereka ambigu, error, atau kelalaian.
Kerugian :
Harus di kembangkan setiap 2 minggu sekali.
G. Agile Modeling
Agile Modeling diperkenalkan oleh Scott Ambler.
Agile Modeling adalah Metologi berbasis latihan untuk” Modeling and Documentation”
dari system berbasis software.
Keunikan pada Agile Modeling:
1. Seorang developer yg menggunakan AM harus mempunyai tujuan yg spesifik
sebelum membuat sebuah model.
2. Ada banyak Model yang berbeda yg bisa dipakai untuk menjelaskan suatu software.
Dan ada beberapa yg termasuk penting. AM menunjukkan bahwa untuk
memberikan pemahaman yg dibutuhkan setiap model harus memberikan aspek yg
berbeda dari system dan hanya model-model yg menghasilkan nilai yg akan dipakai.
3. Sebagain hasil kerja software engineering , simpan hanya model-model yg
memberikan nilai jangka panjang dan membuang sisanya. Setiap model yg kita
simpan harus dipertahankan saat terjadi perubahan, sehingga memperlambat kerja
tim. Ambler berkata “setiap kali anda menyimpan model untuk kemudahan
memiliki informasi untuk tim anda maka berpotensi meningkatkan komunikasi di
dalam tim”.
4. Model harus memberikan informasi yg diinginkan kepada audience. Sebuah model
sintaksis yg sempurna yg memberikan konten yg bermanfaat kecil tidak
sebermanfaat dibandingkan model dengan notasi jelek yang tetap memberikan
konten yg berharga untuk audience.
5. Kita harus mengerti kegunaan dan kelemahan setiap model dan peralatan yg
digunakan.
6. Kebutuhan harus disesuaikan.
20 | P a g e
Summary
Sekarang ini, kondisi pasar berubah dengan cepat, kebutuhan end-user dan pelanggan pun
berevolusi. Para praktisi software harus menggunakan pendekatan pengembangan software yang
memungkinkan mereka untuk dapat bergerak lincah dan adaptif, melalui Agile Development
Extreme Programming adalah Agile Process yang banyak digunakan. Terdiri dari 4 framework
activities: planning, design, coding, dan testing. XP sangat efektif untuk penyampaian software
feature secara cepat yang diprioritaskan oleh para stakeholder.
ASD, menggunakan proses iterative yang memiliki siklus perencanaan adaptif, customer-focus group,
dan mekanisme real-time feedback. Scrum, menekankan pengerjaan software dengan time-line yang
ketat, perubahan requirement, dan bisnis secara kritis. Dynamic System Development Method
menggunakan time-boxing dalam menyampaikan software increment. Crystal, dapat diadopsi untuk
karakteristik spesifik dalam projek tertentu.
FDD, yang lebih formal, tapi masih dapat mengontrol agility yang bergokus pada tim proyek dan
pengembanganan feature. AM, adalah esensi dari semua model yang ada.