agile

56
AGILE

Upload: damar-aji

Post on 14-Dec-2014

412 views

Category:

Documents


5 download

DESCRIPTION

Kumpulan Algoritma Agile

TRANSCRIPT

Page 1: AGILE

AGILE

Page 2: AGILE

2

AGILE ><

TeamAGILE

Page 3: AGILE

3

AGILE ><

AboutAGILE@

Agile Software development adalah salah satu metodologi dalam pengembangan sebuah perangkat lunak (software). Kata Agile berarti bersifat cepat, ringan, bebas bergerak, waspada.

Metodologi yang dikenal sebagai agile methods ini mengutamakan fleksibilitas terhadap perubahan-perubahan yang terjadi selama pengembangan. Bahkan perubahan ataupun penambahan pada saat fase terakhir pun teratasi apabila menggunakan metodologi ini.

Page 4: AGILE

4

AGILE ><

Agile Methods dikembangkan karena pada metodologi tradisional terdapat banyak hal yang membuat proses pengembangan tidak dapat berhasil dengan baik sesuai tuntutan user.

Konsep Agile software development dicetuskan oleh Kent Beck dan 16 rekannya dengan menyatakan bahwa Agile Software Development adalah cara membangun software dengan melakukannya dan membantu orang lain membangunnya sekaligus.

Page 5: AGILE

5

AGILE ><

Agile method adalah jenis pegembangan sistem jangka pendek yang memerlukan adaptasi cepat dan pengembang terhadap perubahan dalam bentuk apapun.

Agile Method juga dapat diartikan sekelompok metodologi pengembangan software yang didasarkan pada prinsip-prinsip yang sama atau pengembangan system jangka pendek yang memerlukan adaptasi cepat dari pengembang terhadap perubahan dalam bentuk apapun

Page 6: AGILE

6

AGILE ><

Dalam Agile Software Development • interaksi dan personel lebih penting dari pada proses dan alat,• software yang berfungsi lebih penting daripada dokumentasi yang

lengkap, • kolaborasi dengan klient lebih penting daripada negosiasi kontrak,

dan • sikap tanggap terhadap perubahan lebih penting daripada mengikuti

rencana.

Page 7: AGILE

7

AGILE ><

Salah satu cirri dari Agile Software Development adalah tim yang tanggap terhadap perubahan. Mengapa? Karena perubahan adalah hal yang utama dalam membangun software: perubahan kebutuhan software, perubahan anggota tim, perubahan teknologi dll.

Selain itu Agile Software Development juga melihat pentingnya komunikasi antara anggota tim, antara orang- orang teknis dan businessmen, anatara developer dan managernya.

Cirri lain adalah klien menjadi bagian dari tim pembangun software.

Page 8: AGILE

8

AGILE ><

Namun demikian, sama seperti model proses yang lain, agile software development memiliki kelebihan dan tidak cocok untuk semua jenis proyek, produk, orang dan situasi.

Agile Software Development memungkinkan model proses yang toleransi terhadap perubahan kebutuhan sehingga perubahan dapat cepat ditanggapi. Namun di sisi lain menyebabkan produktiitas menurun.

Page 9: AGILE

TujuanAGILE

Page 10: AGILE

10

AGILE ><

TUJUAN DARI AGILE MODELING

1. mendefinisikan dan menunjukkan bagaimana mempraktekkan, sekumpulan nilai, prinsip prinsip dan praktek yang lebih efektif, suatu modeling yang ringan.

2. menempatkan persoalan bagaimana cara untuk mengaplikasikan teknik modeling pada suatu proyek software yang menggunakan pendekatan agile

3. menempatkan permasalaha bagaimana memodelkan sesuatu dengan lebih efektif pada suatu proyek

Page 11: AGILE

PrinsipUTAMA

Page 12: AGILE

12

AGILE ><

Assume Simplicity

Saat merancang sebuah software maka kita harus mengasumsikan bahwa solusi yang kita tawarkan untuk memecahkan permasalahan yang akan dieksekusi oleh software buatan kita adalah solusi yang sangat sederhana yang mudah dipahami oleh pengguna, karna bisa jadi solusi yang paling sederhana adalah solusi yang terbaik. Jangan membuat software sampai overbuild dengan kata lain jangan memodelkan sistem secara berlebihan, karena permasalahan yang dinamis maka buatlah software yang sesuai dengan permintaan, karena kita akan dapat membangun kembali sistem yang lebih kompleks saat permintaan bertambah.

Page 13: AGILE

13

AGILE ><

Embrace Change

Requirement atau permintaan akan semakin meningkat sewaktu waktu. Yang perlu kita lakukan adalah dengan cara mengembangkan atau menambah fasilitas dari software yang telah kita buat tanpa perlu membuat ulang dari awal. Stakeholder proyek dapat merubah sudut pandang, merubah tujuan dan menambahkan kriteria pada yang diinginkan. Maksudnya adalah bahwa project environment kita berubah sesuai dengan efforts, dan hasil pendekatan kita pada pengembangan ini harus merefleksikan realita yang diminta.

Page 14: AGILE

14

AGILE ><

Enabling The Next Effort Is Your Secondary GoalProyek kita masih dapat mengalami kegagalan meskipun kita telah memberikan suatu working system atau sistem yang sudah bekerja dan dapat digunakan pada user, bagian dari melengkapi kebutuhan dari stakeholder proyek adalah untuk memastikan bahwa sistem kita cukup kuat jadi bisa ditambahkan sewaktu waktu. Usaha kita selanjutnya mungkin menjadi pengembangan dari dikeluarkannya rilis selanjutnya dari sistem kita atau bisa juga menyederhanakan operasi dan mendukung versi yang telah ada yang kita bangun. Untuk memfungsikannya kita tidak hanya ingin membangun kualitas software tapi juga membuat dokumentasi yang cukup dan materi pendukung sehingga orang selanjutnya yang mengerjakan bisa lebih efektif. Kesimpulannya, ketika kita bekerja pada sistem, kita harus memperhatikan masa depan pembuatan sistem ini.

Page 15: AGILE

15

AGILE ><

Incremental Change

Suatu konsep yang penting untuk mengerti suatu pemodelan adalah bahwa kita tidak harus membuat benar pada pertama kalinya, kenyataanya tidak seperti yang diinginkan meskipun kita sudah berusaha. Terlebih lagi kita tidak harus merekam setiap detil pada model kita, kita hanya harus mengusahakan yang terbaik pada waktunya. Karena kita bisa melakukan perubahan secara bertahap jika dibutuhkan.

Page 16: AGILE

16

AGILE ><

Maximize Stakeholder InvestmentStakeholder proyek kita menanamkan resource resource seperti waktu, uang, fasilitas dan sebagainya untuk mendapatkan software yang dikembangkan sesuai dengan keinginannya. Karenanya kita harus bisa memanfaatkan resource tersebut secara maksimal untuk kepuasan semua pihak.

Page 17: AGILE

PrinsipUTAMA II

Page 18: AGILE

18

AGILE ><

Model With A Purpose

• Model With A Purpose. Tentukan tujuan pembuatan dan sasaran dibuatnya sebuah software untuk menghindari pertanyaan-pertanyaan berikut,

• “Mengapa membuat software ini??”• “Untuk siapa software ini dibuat?”

• Karena biasanya pertanyaan-pertanyaan tersebut keluar dari benak sendri saat software telah selesai dibuat/dikembangkan.

Page 19: AGILE

19

AGILE ><

Multiple models

• Multiple models. Menggunakan beragam model dalam membangun software.• “Meski dalam membangun sebuah software kita menggunakan beragam moled,

tapi kita tidak harus membangun semua model yang diberikan, kita cukup mempertimbangkan kompleksitas software sekarang ini maka kita bisa tahu cakupan luas dari teknik peralatan intelektual modeling kita sehingga lebih efektif.”

Page 20: AGILE

20

AGILE ><

Quality work

• Quality work. Kualitas Pekerjaan. Perhatikan juga kualitas dari pekerjaan karena tak ada orang yang menyukai pekerjaan yang sembarangan. Seseorang akan menyukai pekerjaan jika itu bisa dibanggakan dan ada hasil yang akan dicapai, tidak lemah dan sesuai dengan yang diinginkan.

Page 21: AGILE

21

AGILE ><

Rapid feedback

• Rapid feedback. Cara kerja dari model ini adalah bekerja dekat dengan customer, maksudnya adalah selalu melakukan komunikasi dengan pelanggan untuk mengetahui requirement, menganalisa atau membangun suatu interfice yang sesuai keinginan akan membuat umpan balik yang lebih cepat.

• “Komunikasi dengan berhadapan langsung adalah komunikasi yang efektif dan efisien”

Page 22: AGILE

22

AGILE ><

Software is your primary goal

• Software Is Your Primary Goal. Tujuan dari pengembangan software adalah untuk menghasilkan software yang sesuai dengan keinginan dari pemesan proyek dengan cara yang efektif, bukan dengan dokumentasi atau model model yang berlebihan.

Page 23: AGILE

23

AGILE ><

Travel light

• Travel Light. Setiap artifak yang dibuat, dan diputuskan untuk dipertahankan, akan membutuhkan untuk di maintain sewaktu waktu. Kompleksitas dan detil yang kita buat diawal akan memberatkan sehingga jika kita membuat model awal harus yang mudah dimengerti dan efektif sehingga akan meringankan perjalanan menuju akhir pembuatan software.

Page 24: AGILE

PrinsipPENDUKUNG

Page 25: AGILE

25

AGILE ><

Prinsip prinsip pendukung

• Content Is More Important Than Representation. Model yang diberikan mempunyai banyak cara merepresentasikannya. Tetapi isi dari model dan software yang dikerjakan lebih penting daripada representasinya.• Everyone Can Learn From Everyone Else. Kita tidak bisa benar benar

mencontoh sesuatu, tetapi kita bisa belajar dari orang lain termasuk teknik melaui berbagai cara misalnya training, education, mentoring, reading dan lain lain.

Page 26: AGILE

26

AGILE ><

Prinsip prinsip pendukung

• Know Your Models. Karena kita mempunyai multiple model yang harus diaplikasikan maka kita harus tahu kekuatan dan kelemahan untuk penggunaan yang efektif.• Know Your Tools. Kita harus memahami peralatan, software,

modeling tools, diagramming tools untuk menggunakannya dengan baik.• Local Adaptation. Pendekatan pada software development harus

merefleksikan lingkungan kita, termasuk organisasi kita, keadaan stakeholder proyek dan lingkungan proyek itu sendiri.

Page 27: AGILE

27

AGILE ><

Prinsip prinsip pendukung

• Open And Honest Communication. Kita harus terbuka dan berkomunikasi dengan jujur pada pengembang dan stakeholder proyek, pengguna dan semua yang terlibat pada pembuatan proyek.• Work With People's Instincts. Bekerja pada bidang ini bukan berarti

tidak mempertimbangkan perasaan dan insting. Kita juga harus bekerja dengan insting manusia.

Page 28: AGILE

RuanglingkupAGILE

Page 29: AGILE

29

AGILE ><

• Konsep yang penting untuk dimengerti dari suatu Agile Modeling adalah bahwa ini bukanlah proses software yang lengkap. Agile Modeling berkonsentrasi pada modeling dan dokumentasi yang efektif. Tidak meliputi aktifitas pemrograman, meskipun mengatakan untuk membuktikan model kita dengan suatu code (coding). Tidak meliputi aktifitas testing juga,

Page 30: AGILE

30

AGILE ><

• Tidak meliputi aktifitas pemrograman, meskipun mengatakan untuk membuktikan model kita dengan suatu code (coding). Tidak meliputi aktifitas testing juga, meskipun mengatakan untuk mempertimbangkan model yang bisa lolos testing. Tidak mencakup manajemen proyek, system deployment, system operasi, system support, dan sebagainya.

Page 31: AGILE

31

AGILE ><

• Karena Agile Modeling fokus pada suatu porsi dari semua proses software yang harus memakai yang lain, proses full-fledged seperti eXtreme Programming (XP), Dynamic Systems Development Method (DSDM), SCRUM atau Unified Process (UP) seperti yang telah disebutkan pada tujuan dari Agile Modeling.

Page 32: AGILE

NilaiAGILE

Page 33: AGILE

33

AGILE ><

CommunicationModel meningkatkan komunikasi tim kita dengan stakeholder proyek kita sebaik Antara developer dan tim kita

Page 34: AGILE

34

AGILE ><

SimplicityPenting bahwa developer mengerti bahwa model mudah untuk disederhanakan baik software dan proses software, lebih mudah untuk mengeskplorasi ide, dan meningkatkannya sesuai dengan peningkatan pemahaman, dengan menggambar diagram atau menulis puluhan bahkan ribuan baris kode

Page 35: AGILE

35

AGILE ><

Feedback“Optimis adalah suatu resiko dalam

pekerjaan pemograman, dan feedback adalah pengobatannya”

Kent Beck

Page 36: AGILE

36

AGILE ><

Courage (keberanian)Courage penting karena kita harus membuat keputusan yang penting dan bisa untuk merubah perintah dengan pembuangan atau pembuatan kembali pekerjaan kita ketika beberapa dari keputusan kita terbukti tidak mencukupi

Page 37: AGILE

37

AGILE ><

Humility (kerendahan hati)Developer terbaik mempunyai kerendahan hati untuk mengenali bahwa mereka tidak tahu semuanya

Semua orang terlibat dengan proyek kita mempuyai nilai sama dan harus dihormati.

Page 38: AGILE

PraktekUtamaAGILE

Page 39: AGILE

39

AGILE ><

Partisipasi Aktif Stakeholderstakeholder adalah orang yang merupakan pengguna langsung, pengguna tidak langsung, manajer pengguna, manajer senior, anggota staf operasi, "emas pemilik" yang mendanai proyek, dukungan (help desk) anggota staf, auditor, program Anda / portofolio manajer, pengembang yang bekerja pada sistem lain yang mengintegrasikan atau berinteraksi dengan yang sedang dikembangkan, atau profesional perawatan berpotensi terkena pengembangan dan / atau penyebaran proyek perangkat lunak.

Menggunakan Barang-Barang yang TepatImplikasinya adalah bahwa Anda perlu mengetahui kekuatan dan kelemahan masing-masing jenis artefak sehingga Anda tahu kapan dan kapan tidak menggunakannya. Perhatikan bahwa ini bisa sangat sulit karena Anda harus Beberapa Model tersedia untuk Anda, bahkan Model Agile daftar halaman suling lebih dari 35 jenis model dan itu tidak berarti definitif.

Page 40: AGILE

40

AGILE ><

Collective Ownership• Kepemilikan kolektif. Setiap orang dapat bekerja pada model apapun,

dan bahkan setiap artefak pada proyek, jika mereka perlu.

Mempertimbangkan Kemampuan Tes

Ketika Anda pemodelan Anda harus selalu mengajukan pertanyaan "Apakah saya perlu untuk mempertahankan informasi ini permanen?", "Jika demikian, di mana adalah tempat terbaik untuk menyimpan informasi ini?" dan "Apakah informasi ini sudah ditangkap tempat lain bahwa saya hanya bisa referensi?". Kadang-kadang tempat terbaik untuk menyimpan informasi dalam dokumen tangkas, sering itu dalam kode sumber

Page 41: AGILE

41

AGILE ><

Membuat Beberapa Model Secara ParalelKarena setiap jenis model memiliki kekuatan dan kelemahan ada model tunggal sudah cukup untuk kebutuhan pemodelan Anda. Misalnya ketika Anda menjelajahi persyaratan Anda mungkin perlu untuk mengembangkan beberapa kasus penting penggunaan atau cerita pengguna, prototipe UI penting, dan beberapa aturan bisnis. Dalam kombinasi dengan praktek iterasi untuk artefak lain tangkas pemodel akan sering menemukan bahwa mereka jauh lebih produktif bekerja pada beberapa model secara bersamaan daripada jika mereka terpaku pada satu di waktu tertentu.

Page 42: AGILE

42

AGILE ><

Membuat Kandungan SederhanaImplikasinya adalah bahwa Anda tidak harus menambahkan aspek tambahan untuk model Anda kecuali mereka dibenarkan - jika Anda tidak memiliki persyaratan untuk menambahkan fitur sistem audit maka jangan menambahkan bahwa fitur untuk model Anda. Milikilah keberanian untuk percaya bahwa Anda sebenarnya bisa menambahkan fitur ini ketika, dan jika, itu pernah meminta dari Anda. Ini adalah sepanjang baris praktik XP Desain Simple.

Sebuah model sederhana yang menunjukkan fitur utama yang Anda mencoba untuk memahami, mungkin kelas model yang menggambarkan tanggung jawab utama dari kelas dan hubungan antara mereka, sering terbukti cukup. Ya, Anda dapat model semua kode perancah yang akan Anda butuhkan untuk menulis, semua operasi pengambil dan penyetel yang standar pengkodean Anda memberitahu Anda untuk menggunakan, tapi nilai apa yang akan yang menambahkan? Sangat sedikit.

Menggambarkan Kesederhanaan Model

Page 43: AGILE

PraktekUtamaAGILE II

Page 44: AGILE

44

AGILE ><

• Menggambarkan Kesederhanaan Model• Memperlihatkan Model di Depan Umum• Mengiterasi Artefak lainnya• Model in Small Increments• Modelkanlah Dengan Yang Lainnya• Percayakan Dengan Kode• Gunakan Alat Paling Sederhana

Page 45: AGILE

45

AGILE ><

ModelAGILE METHOD

• 1. Extreme Programmning (XP)• 2. Adaptive Software Development (ASD)• 3. Dynamic Systems Development Method (DSDM)• 4. Scrum Methodology• 5. Crystal• 6. Feature Driven Development (FDD)• 7. Agile Modeling (AM)• 8. Rational Unified Process

Page 46: AGILE

46

AGILE ><

KelebihanAGILE METHOD

1. Meningkatkan kepuasan client2. Pengerjaan yang relative cepat3. Mengurangi kegagalan non teknis 4. Mengurangi kegagalan dari segi materi atau5. pemanfaat biaya akan sangat efektif

Page 47: AGILE

PraktekPendukungAGILE

Page 48: AGILE

48

AGILE ><

Buang Model Sementara

• Sebagian besar model-model yang Anda buat bersifat sementara• Contoh: sketsa desain, prototipe.• Membuat keputusan untuk menyinkronkan

Page 49: AGILE

49

AGILE ><

Gunakan Permodelan Standar

• ide dasarnya adalah bahwa pengembang harus setuju dan mengikuti seperangkat pemodelan standar pada proyek perangkat lunak. • Ada berbagai standar pemodelan yang umum tersedia untuk Anda,

termasuk Management Group Object Unified Modeling Language (UML)

Page 50: AGILE

50

AGILE ><

Bentuklah Kontrak Model

• sering diperlukan ketika kelompok eksternal mengontrol sumber informasi.• Sumber Informasi: database, aplikasi warisan atau layanan informasi.• Sebuah model kontrak adalah bentuk kesepakatan yang kedua belah

pihak harus saling setuju dan dapat berubah jika diperlukan.

Page 51: AGILE

51

AGILE ><

• Gunakan Contoh dengan Hati-Hati• Model Untuk Berkomunikasi• Model Untuk Dimengerti• Gunakan Kembali Artefak yang Ada• Update Hanya Ketika Rusak

Anda harus memperbarui model hanya ketika Anda benar-benar perlu.

Page 52: AGILE

DokumentasiAGILE

Page 53: AGILE

53

AGILE ><

Hubungan antara model, dokumen, source code, dan dokumentasi

Page 54: AGILE

54

AGILE ><

Alasan membuat dokumentasi

• Stakeholder proyek membutuhkannya. • Untuk menentukan model kontrak• Untuk mendukung komunikasi dengan kelompok eksternal. • Untuk mendukung memori organisasi• Untuk tujuan audit. • Untuk berpikir sesuatu

Page 55: AGILE

55

AGILE ><

Kriteria sebuah dokumen

• Dokumen Agile memaksimalkan ROI pemangku kepentingan .• Stakeholder tahu TCO dokumen. • Dokumen Agile memenuhi tujuan.• Dokumen Agile menjelaskan dengan baik hal untuk diketahui• Dokumen Agile memiliki pelanggan tertentu dan memfasilitasi upaya

kerja pelanggan itu. • Dokumen Agile cukup akurat , konsisten , dan rinci .

Page 56: AGILE

56

AGILE ><

Masalah-malasah yang harus diatasi

• Pengembangan perangkat lunak dibandingkan pengembangan dokumentasi . • Spesifikasi executable menawarkan nilai yang jauh lebih dari dokumentasi statis. • Pengembang perangkat lunak memiliki pengetahuan, penulis teknis memiliki

keterampilan . • Apa yang diperlukan selama pengembangan sering berbeda dari apa yang dibutuhkan

setelah pembangunan. • Apakah Anda dokumen saat Anda bekerja atau ketika Anda sudah selesai?• Bisakah Anda menunggu sampai informasi telah stabil? • Dokumentasi kode dibandingkan dokumentasi eksternal.• Tingkat proyek dibandingkan dokumentasi tingkat perusahaan .• Kuantitas dibandingkan kualitas.