Una presentación compactada de los testing aplicados a métodos agiles. Explica los principales métodos utilizados para llevar a cabo un buen testeo durante la creación de un proyecto de sof…Descripción completa
Descripción: Agile para niños
Full description
Agile questions.docx
Guide to realistic Agile Project estimation.Full description
Full description
Agile Testing
Agile FAQFull description
Full description
Full description
hand book for agile
Agile adalah sebuah kondisi, sebuah tujuan. Scrum adalah kendaraan untuk mencapai tujuan tersebut. Untuk menjadi Agile dengan Scrum, setiap organisasi perlu memahami Scrum Framework secara utuh aga...
A detailed overview of Spotify's innovative strategy for scaling its team by building numerous autonomous squads that function as independent mini-startups.Descripción completa
agile
manual manutenção agile 1.4Descrição completa
agileDescripción completa
chessDescrição completa
Agile Scrum TrainingFull description
motivation writing
Tugas Kelompok Rekayasa Piranti Lunak - Agile Software Development 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
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 ti dak 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 c epat. 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 sta keholders 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 ko nstan. 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 ya ng 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
spike solut ions p r o t o t y p es
user st ories values acceptance test crit eria it erat ion plan
refacto ring pair programming
Release software increment project v elocity computed
unit t est cont inuous integrat 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 t erlebih 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 Untuk menentukan apakah terjadi overcommitment pada story yang ak an o 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 m engatur 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 m engubah 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 mission st at ement project const raints basic requirement s
Requirement s gat hering JAD mini-specs
t ime-boxed release plan
Release software increment adjustments f or subsequent cycles
component s implement ed/ t est ed focus groups for feedback 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
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
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.
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
Studi
untuk
Perulangan Model Fungsional
12 | P a g e
Perulangan Perancangan dan Pembuatan
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.
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.
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.
Implementasi
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 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. 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
•
Motorolla
•
Nokia
•
Bank of America,etc.
•
Google
•
Yahoo
•
IBM
•
Adobe
•
Intel
•
BBC
•
Amazon
•
Guideware
•
Electronic Arts
•
Citibank 16 | 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
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 pend efinisian “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 : the a(n)