Tugas Kelompok Rekayasa Piranti Lunak - Agile Software Development -

Disusun Oleh: Kelompok I 04PQT

`Anggota Kelompok: 1401126026 1401125276 1401126266 1401128082 1401126726 1401126234 WILLY LAZUARDI NICCO FEBRIAN NEDSENDA RIZKY AFRIYAN GUSTAF ADHIKA MAFRAN KURNIAWAN

BINUS University Jakarta 2012

1|Page

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

2|Page

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.

3|Page

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. 4|Page

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.

5|Page

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.

6|Page

Proses XP
simple design CRC cards user st ories values accept ance t est crit eria it erat ion plan spike solut ions prot ot ypes

ref act oring pair programming

Release
sof t w are increment proj ect v elocit y comput ed

unit t est cont inuous int egrat ion accept ance t est ing

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

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 8|Page

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.

9|Page

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 m issio n st at em ent pro ject co nst raint s b asic requirem ent s

Requirement s gat hering JAD mini-specs

t ime-boxed release plan

Release
sof t w are increment adj ust ment s f or subsequent cy cles

component s implement ed/ t est ed f ocus groups f or f eedback f ormal t echnical reviews post mort ems

10 | 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

11 | P a g e

Proses DSDM

Kegiatan

Sub kegiatan

Penjelasan
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 kelayakan

Studi

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

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 membangun fungsionalitas tersebut.

untuk

Perulangan Model Fungsional 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

12 | P a g e

Mengenali prototip rancangan

Mengenali kebutuhan fungsional dan nonfungsional yang diperlukan dalam sistem yang diujikan. Dihasilkan suatu strategi penerapan, yang juga didasari catatan pengujian dari perulangan sebelumnya. Setuju pada bagaimana dan kapan memenuhi persyaratan yang ada. Membuat sebuah sistem (prototip rancangan) yang dapat secara aman diserahkan kepada pengguna akhir untuk penggunaan harian, juga sebagai ujicoba. Mengecek kebenaran hasil rancangan sistem, melalui serangkaian teknik ujicoba dan peninjauan. Dokumentasi pengguna maupun catatan pengujian akan dibuat. Pengguna akhir menyetujui sistem yang telah diuji untuk diterapkan and sebagai pedoman, dengan mematuhi ketentuan sistem yang telah dibuat. Melatih calon pengguna dalam penggunaan sistem. Dihasilkan sekelompok pengguna yang terlatih Menerapkan sistem yang telah teruji (tested system) di lokasi pengguna akhir, disebut juga sistem yang tersampaikan. 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.

Menyetujui jadwal Perulangan Perancangan dan Pembuatan

Membuat prototip rancangan

Meninjau prototip rancangan

Persetujuan pemakai dan garis pedoman

Melatih pengguna

Penerapan Implementasi

Tinjauan bisnis

13 | 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

14 | 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 timeboxing 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. 15 | 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 16 | P a g e Motorolla Bank of America,etc.

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

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

18 | 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 2.

3.

4.

5. 6.

sebelum membuat sebuah model. 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. 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. 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. Kita harus mengerti kegunaan dan kelemahan setiap model dan peralatan yg digunakan. Kebutuhan harus disesuaikan.

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

20 | P a g e