Complete Agile

20
1 | Page 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

description

Impelentasi Agile

Transcript of Complete Agile

Page 1: 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

Page 2: Complete Agile

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

Page 3: Complete Agile

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.

Page 4: Complete Agile

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.

Page 5: Complete Agile

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.

Page 6: Complete Agile

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.

Page 7: Complete Agile

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

Page 8: Complete Agile

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

Page 9: Complete Agile

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.

Page 10: Complete Agile

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

Page 11: Complete Agile

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

Page 12: Complete Agile

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

Page 13: Complete Agile

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.

Page 14: Complete Agile

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

Page 15: Complete Agile

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.

Page 16: Complete Agile

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

• Google

• Yahoo

• IBM

• Adobe

• Intel

• BBC

• Amazon

• Guideware

• Electronic Arts

• Citibank

• Motorolla

• Bank of America,etc.

Page 17: Complete Agile

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

Page 18: Complete Agile

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.

Page 19: Complete Agile

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.

Page 20: Complete Agile

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.