TEK B TUGAS DARI OM BEAR"1. Jelaskan kembali mengenai sejarah Agile 2. Jelaskan metodologi Agile 3. Jelaskan perbedaan antara Agile dengan model tradisional 4. Jelaskan tentang XP Life Cycle (Gambar, penjelasan gambar, kelebihan, keurangan) 5. Jelaskan kapan XP cocok digunakan? 6. Jelaskan tentang peranan Product Owner, Developer team, Master Scrum 7. Jelaskan kelebihan & kekurangan Scrum! 8. Jelaskan kapan Scrum cocok digunakan? 9. Jelaskan tentang alur Scrum (sertakan gambar), termasuk penjelasan 7 istilah berikut : backlog, sprint backlog, Burndown chart, sprint, sprint planning, sprint review, Sprint restropective (setiap istilah diberikan contoh kasus dan tambahkan gambar jika perlu)"

PENDAHULUAN

http://dwijaantara.wordpress.com/

Metodologi dalam perangkat lunak digunakan untuk merancang atau membangun suatu perangkat lunak,dengan perkembangan teknologi yang sangat pesat metodologi perangkat lunak juga terjadi perubahan atau penambahan requirements. Dari model waterfall sampai dengan model-model incremental. Semua metodologi yang berkembang sebelumnya tidak mampu menangani kemungkinan perubahan atau penambahan requirements. Metode pengembangan perangkat lunak telah dilacak kembali pada tahun 1957. Pada tahun tersebut EA Edmonds telah memperkenalkan proses pengembangan perangkat lunak adaptif. “Lightwight” merupakan metode pengembangan perangkat lunak yang berkembang pada tahun 1990, sebagai reaksi terhadap apa yang disebut metode “heavyweight”. Yang ditandai dengan kritik mereka terhadap metode waterfall

Pada tahun 90-an diperkenalkan dengan metodologi baru yang dikenal dengan nama agile methods,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.

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.

1. 1. Pengertian

Agile methods merupakan salah satu dari beberapa metode yang digunakan dalam pengembangan sooftware. Agile method adalah jenis pegembangan sistem jangka pendek yang memerlukan adaptasi cepat dan pengembang terhadap perubahan dalam bentuk apapun.

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 klien lebih penting dari pada negosiasi kontrak, dan sikap tanggap terhadap perubahan lebih penting daripada mengikuti rencana.

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

1.1. Prinsip Agile Software Development

Agile Software Development juga melihat pentingnya komunikasi antara anggota tim, antara orang-orang teknis dan businessmen, antara developer dan managernya. Ciri lain adalah klien menjadi bagian dari tim pembangun software. Ciri-ciri ini didukung oleh 12 prinsip yang ditetapkan oleh Agile Alliance. Menurut Agile Alliance, 12 prinsip ini adalah bagi mereka yang ingin berhasil dalam penerapan Agile Software Development:

1.   Kepuasan klien adalah prioritas utama dengan menghasilkan produk lebih awal dan terus menerus.

2.   Menerima perubahan kebutuhan, sekalipun diakhir pengembangan.

3.   Penyerahan hasil/software dalam hitungan waktu beberapa minggu sampai beberapa bulan.

4.   Pihak bisnis dan pengembang harus bekerja sama setiap hari selama pengembangan berjalan.

5.   Membangun proyek dilingkungan orang-orang yang bermotivasi tinggi yang bekerja dalam lingkungan yang mendukun dan yang dipercaya untuk dapat menyelesaikan proyek.

6.   Komunikasi dengan berhadapan langsung adalah komunikasi yang efektif dan efisien

7.   Software yang berfungsi adalah ukuran utama dari kemajuan proyek

8.   Dukungan yang stabil dari sponsor, pembangun, dan pengguna diperlukan untuk menjaga perkembangan yang berkesinambungan

9.   Perhatian kepada kehebatan teknis dan desain yang bagus meningkatkan sifat agile

10. Kesederhanaan penting

11. Arsitektur, kebutuhan dan desain yang bagus muncuk dari tim yang mengatur dirinya sendiri

12. Secara periodik tim evaluasi diri dan mencari cara untuk lebih efektif dan segera melakukannya.

Dua belas prinsip tersebut menjadi suatu dasar bagi model-model proses yang punya sifat agile. Dengan prinsip-prinsip tersebur Agile Process Model berusaha untuk menyiasati 3 asumsi penting tentang proyek software pada umumnya:

1. Kebutuhan software sulit diprediksi dari awal dan selalu akan berubah. Selain itu, prioritas klien juga sering berubah seiring berjalannya proyek.

2. Desain dan pembangunan sering tumpang tindih. Sulit diperkirakan seberapa jauh desain yang diperlukan sebelum pembangunan.

3. Analisis, desain, pembangunan dan testing tidak dapat diperkirakan seperti yang diinginkan.

Kelebihan dari Agile Method

1. Meningkatkan kepuasan kepada klien2. Pembangunan system dibuat lebih cepat3. Mengurangi resiko kegagalan implementasi software dari segi non-teknis4. Jika pada saat pembangunan system terjadi kegagalan,kerugian dar segi materi

relative kecil.

1.2. Model-model Agile method

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

1.2.1. Extreme Programmning (XP)

Proyek Pemrograman Extreme pertama dimulai 6 Maret 1996. Extreme Programming adalah salah satu dari beberapa Proses Agile populer. Sudah terbukti sangat sukses di banyak perusahaan dari berbagai ukuran dan industri di seluruh dunia.

Extreme Pemrograman berhasil karena menekankan kepuasan pelanggan. Alih-alih memberikan semua yang anda mungkin inginkan pada tanggal beberapa jauh di masa depan proses ini memberikan perangkat lunak yang Anda butuhkan saat Anda membutuhkannya. Extreme Pemrograman memberdayakan pengembang Anda untuk percaya diri menanggapi perubahan kebutuhan pelanggan, bahkan terlambat dalam siklus hidup.

Extreme Pemrograman menekankan kerja sama tim. Pengelola, pelanggan, dan pengembang semua mitra setara dalam sebuah tim kolaboratif. Extreme Pemrograman menerapkan,

sederhana namun efektif yang memungkinkan tim lingkungan menjadi sangat produktif. Tim mengorganisir diri mengatasi masalah untuk menyelesaikannya seefisien mungkin.

Extreme Pemrograman meningkatkan proyek perangkat lunak dalam lima cara penting; komunikasi, kesederhanaan, umpan balik, rasa hormat, dan keberanian. Extreme Programmer selalu berkomunikasi dengan pelanggan mereka dan programer sesama. Mereka terus desain mereka yang sederhana dan bersih. Mereka mendapatkan umpan balik dengan menguji perangkat lunak mereka dimulai pada hari pertama. Mereka memberikan sistem ke pelanggan sebagai perubahan sedini mungkin dan melaksanakan seperti yang disarankan. Setiap keberhasilan kecil memperdalam rasa hormat mereka atas kontribusi yang unik dari masing-masing dan setiap anggota tim. Dengan dasar Extreme pemrogram dapat berani merespon perubahan kebutuhan dan teknologi.

Aspek yang paling mengejutkan dari Extreme Programming adalah aturan sederhana. Extreme Pemrograman sangat mirip jig gergaji teka-teki. Ada banyak potongan-potongan kecil. Individual potongan

Extreme Programming adalah metode pengembangan perangkat lunak yang ringan dan termasuk salah satu agile methods yang dipelopori oleh Kent Beck, Ron Jeffries, dan Ward Cunningham. Extreme Programming merupakan agile methods yang paling banyak digunakan dan menjadi sebuah pendekatan yang sangat terkenal. Sasaran Extreme Programming adalah tim yang dibentuk berukuran antara kecil sampai medium saja, tidak perlu menggunakan sebuah tim yang besar. Hal ini dimaksudkan untuk menghadapi requirements yang tidak jelas maupun terjadinya perubahan-perubahan requirements yang sangat cepat.

Extreme Programming sebagai sebuah metode yang dinamis diperlihatkan dalam empat values yang dimilikinya dan keempatnya merupakan dasar-dasar yang diperlukan dalam Extreme Programming. Kent Beck menyatakan bahwa tujuan jangka pendek individu sering berbenturan dengan tujuan sosial jangka panjang. Karena itu dibuatlah values yang menjadi aturan, hukuman, dan juga penghargaan. Keempat values tersebut adalah :

1. Komunikasi (Communication)

Tugas utama developer dalam membangun suatu sistem perangkat lunak adalah mengkomunikasikan kebutuhan sistem kepada pengembang perangkat lunak. Komunikasi dalam Extreme Programmning dibangun dengan melakukan pemrograman berpasangan (pair programming). Developer didampingi oleh pihak klien dalam melakukan coding dan unit testing sehingga klien bisa terlibat langsung dalam pemrograman sambil berkomunikasi dengan developer. Tujuannya untuk memberikan pandangan pengembang sesuai dengan pandangan pengguna sistem.

1. Kesederhanaan (Simplicity)

XP mencoba untuk mencari solusi paling sederhana dan praktis. Perbedaan metode ini dengan metodologi pengembangan sistem konvensional lainnya terletak pada proses desain dan coding yang terfokus pada kebutuhan saat ini daripada kebutuhan besok, seminggu lagi atau sebulan lagi. Lebih baik melakukan hal yang sederhana dan mengembangkannya besok jika diperlukan.

1. Umpan Balik (Feedback)

Hal ini diperlukan untuk mengetahui kemajuan dari proses dan kualitas dari aplikasi yang dibangun. Informasi ini harus dikumpulkan setiap interval waktu yang singkat secara konsisten. Ini dimaksudkan agar hal-hal yang menjadi masalah dalam proses pengembangan dapat diketahui sedini mungkin. Setiap feed back ditanggapi dengan melakukan tes, unit test atau system integration dan jangan menunda karena biaya akan membengkak (uang, tenaga, waktu).

1. Keberanian (Courage)

Berani mencoba ide baru. Berani mengerjakan kembali dan setiap kali kesalahan ditemukan, langsung diperbaiki. Contoh dari courage adalah komitmen untuk selalu melakukan design dan coding untuk saat ini dan bukan untuk esok. Ketika ada kode yang terlalu rumit, sulit dibaca dan dipahami, tidak sesuai dengan kemauan pelanggan, dll maka seharusnya kode program seperti itu di refactor (kalau perlu dibangun ulang). Hal ini menjadikan pengembang merasa nyaman dengan refactoring program ketika diperlukan.

Extreme Programming menggunakan pendekatan berorientasi objek. Pada aktifitas Perencanaan terjadi pengumpulan user stories dari klien yang klien tetapkan prioritasnya. Setiap story ditetapkan harga dan lama pembangunan, jika terlalu besar, story dapat dipecah menjadi beberapa story yang lebih kecil. Terjadi pemeriksaan dan pertimbangkan resiko dan aktifitas Desain kegiatannya sederhana yaitu memanfaatkan kartu CRC (Class-Responsibility-Collaborator) untuk identifikasi dan mengatur class-class di konsep OO. Jika temuikan kesulitan, prototype dibangun [ini namanya spike solution].

Dilakukannya refactoring, yaitu mengembangkan desain dari program setelah ditulis. Pada aktifitas Pengkodean adalah penyiapan unit test sebelum pengkodean dipakai sebagai focus pemrogram untuk membuat program. Pair programming dilakukan untuk real time program solving dan real time quality assurance. Proses pengujiannya menggunakan unit test yang dipersiapkan sebelum pengkodean Menggunakan pendekatan berorientasi objek

Gambar 1. Proses Extreme Programming (XP)

Sebagai sebuah metodologi untuk mengembangkan peragkat lunak Extreme Programming tentu memiliki siklus hidup. Siklus hidup pada Extreme Programming ini terdapat lima fase yaitu :

1. Exploration Phase2. Planning Phase3. Iteration to Release Phase4. Productionizing Phase5. Maintenance Phase6. Death Phase

Gambar 2. Fase Extreme Programming (XP) sebelum dimodifikasi

Pada bagian ini akan dilakukan penambahan fase pada Extreme Programmning yaitu dengan menyisipkan sebuah fase yang disebut requirements management phase. Fase ini disisipkan tidak sekuensial tapi paralel dengan fase planning. Tujuan penyisipan secara paralel ini adalah mengurangi kemungkinan Extreme Programmning keluar dari lingkup agile. Tiga hal yang dilakukan yaitu:

1. Requirements Management2. Pendokumentasian sederhana (simple documenting)

1. Mempertahankan index card yang telah diimplementasi dengan baik

Gambar 3: Fase pada Extreme Programming (XP) setelah modifikasi

Setelah dilakukan modifikasi terdapat beberapa pengaruh pada practice-nya. Dari dua belas practice yang terdapat pada Extreme Programmning, ada empat buah practice yang mempunyai singgungan kuat dengan requirements management yaitu planning game, metaphor, 40-hour week, On-site customer. Dari keempatnya planning game-lah yang paling besar keterkaitannya dengan requirements. Pada bagian ini akan dipaparkan yang terjadi pada

keempat practice tersebut setelah dilakukan modifikasi pada Extreme Programmning tersebut.

1. Planning Game

Berikut ini adalah tabel setelah dilakukan perubahan pada siklus:

NO

PHASE BUSINESS

DEVELOPMENT

I Exploration phase

Write story -- Estimate storySplit story -

-Summarize stories (simple documenting)

II Commitment phase

Sort by value

-

- Sort by risk- Sort by velocityChoose scope

-

III Steering phase

Iteration -- RecoveryNew story Re-estimate

-Summarize stories (update simple document)

Tabel 1: Fase pada planning game (setelah modifikasi)

Sebelum modifikasi, pada exploration phase terdapat tiga kegiatan yaitu write story, estimate story, dan split story. Setelah dilakukan modifikasi satu kegiatan lagi yang dikerjakan oleh pihak development adalah summarize stories into simple document.

Demikian juga pada steering phase yang pada awalnya hanya terdiri atas kegiatan-kegiatan iteration, recovery, new story, dan re-estimate, setelah modifikasi ditambah satu lagi yaitu update simple document. Proses ini sebenarnya sama dengan summarize stories pada exploration phase, perbedaannya pada steering phase adalah untuk mengantisipasi adanya new story yang dikerjakan oleh pihak bisnis.

1. Metaphor

Metaphor merupakan panduan (guidance) dalam melakukan pengembangan secara keseluruhan. Metaphor di sini memerlukan penjelasan rinci. Requirements yang diperoleh melalui proses summarize stories tersebut berperan sebagai metaphor, sedangkan penjelasan rincinya ada pada story awal.

1. 40-hour week

Story yang telah selesai ditulis oleh customer langsung dirangkum ke dalam simple document pada fase requirements management. Terjadi penambahan waktu secara signifikan.

1. On-site Customer

Komunikasi dengan on-site customer tetap dilakukan terus, termasuk dalam melakukan summarize stories. Sifatnya hanya merangkum story ke dalam requirements yang akan menjadi feature pada sistem yang dibuat.

Penerapan Extreme Programmning

Beberapa hal yang harus dipertimbangkan sebelum seseorang masuk dalam dunia Extreme Programmning  adalah sebagai berikut:

1. User harus memahami konteks bisnis yang akan dikembangkan sistemnya, sehingga developer dapat menangkap sistem secara aplikatif dan dapat mengusulkan teknologi apa yang dapat dikembangkan dalam sistem barunya.

2. Akan lebih efektif apabila developer pernah menangani proyek pengembangan sistem yang sejenis sehingga dapat memberikan usulan model sistem baru, di samping alasan bahwa developer telah memiliki template aplikasi sistem tersebut untuk dijadikan prototype sistem baru. Hal ini akan berimplikasi kepada kemudahan dalam konstruksi sistem karena dikembangkan berdasarkan template yang sudah ada.

3. Extreme programming menuntut komunikasi antar developer dan user secara intensif dan komunikasi internal antar developer secara komprehensif, sehingga akan lebih representatif apabila tahap pengembangan sistem dilakukan di lokal yang mendukung proses komunikasi tersebut.

Extreme Programmning  adalah suatu bentuk pembangunan perangkat lunak yang berbasis nilai kemudahan, komunikasi, umpan balik, dan keberanian. Bekerja dalam whole team bersama-sama dengan praktek yang mudah. Dalam Extreme Programming terdapat 12 practices utama yaitu :

1. Planning Game

Hubungan antara Customer dengan Programer untuk memperkirakan kenbutuhan –kebutuhan dari Custumer dalam implementasinya.

1. Small, frequent releases

Memproduksi dengan cepat.

1. System metaphors

System metaphors antara Customer dengan Programeruntuk menunjukkan semua perkembangan dengan menjelaskan bagaimana cara kerja system.

1. Simple design

Perhatiannya pada pendisainnan atau perancngan solusi yang sederhana

1. Testing (unit testing & TDD)

Pelaksanaan pengujian atau testing keseluruhan

1. Frequent refactoring

Penyusunan system kembali dengan cara duplikat atau salinan,memperbaiki komunikasi, menambahkan kelenturan

1. Pair programming

Dua orang menulis kode pada 1 komputer

1. Collective code ownership

Siapapun dapat merubah bagian pada pengkodean setiap saat.

1. Continuous integration

Bagian baru code di gabungkan ke dalam kode dasar

1. 40-hour weak

Max 40 jam kerja seminggu,

1. On-site customer

Customer harus hadir dan ada setiap saat untuk teamnya.

1. Coding standards

Terdapat aturan pengkodean dan di ikuti oleh programmer.

Keuntungan dan Kerugian

Keuntungan Extreme Programmning:

Menjalin komunikasi yang baik dengan client. Meningkatkan komunikasi dan sifat saling menghargai antar developer.

Kerugian Extreme Programmning:

Developer harus selalu siap dengan perubahan karena perubahan akan selalu diterima. Tidak bisa membuat kode yang detail di awal (prinsip simplicity dan juga anjuran untuk melakukan apa yang diperlukan hari itu juga).

1.2.2. Adaptive Software Development (ASD)

Adaptive Software Development (ASD) diajukan oleh Jim Highsmith sebagai teknik untuk membangun software dan sistem yang kompleks. Filosofi yang mendasari Adaptive Software Development (ASD) adalah kolaborasi manusia dan tim yang mengatur diri sendiri.

System kerja adaptive software development : Collaboration dan Learning

Adaptive cycle planning yaitu menggunakan informasi awal seperti misi dari klien, batasan proyek dan kebutuhan dasar untuk definisikan rangkaian software increment (produk software yang secara berkala diserahkan)

1. Collaboration : orang-orang yang bermotivasi tinggi bekerja sama: saling

melengkapi, rela membantu, kerja keras, trampil di bidangnya, dan komunikasikan masalah untuk hasilkan penyelesaian yang efektif.

1. Learning: tim pembangun sering merasa sudah tahu semua hal tentang proyek,

padahal tidak selamanya begitu. Karena itu proses ini membuat mereka belajar lebih tentang proyek melalui 3 cara:

-          Focus group: klien dan pengguna memberi masukan terhadap software

-          Formal Technique Reviews: Tim ASD lengkap melakukan review

-          Postmortems: Tim ASD lakukan instrospeksi pada kinerja dan proses.

Gambar 4. Proses Adaptive Software Development (ASD)

1.2.3. Dynamic Systems Development Method (DSDM)

Pada Dynamic System Development Method menyajikan kerangka kerja (framework) untuk membangun dan memelihara sistem dalam waktu yang terbatas melalui penggunaan prototyping yang incremental dalam lingkungan yang terkondisikan. Metode ini akan membangun software dengan cepat: 80% dari proyek diserahkan dalam 20% dari waktu total untuk menyerahkan proyek secara utuh.

Dynamic System Development Method dapat dikombinasikan dengan Extreme Programmning menghasilkan kombinasi model proses yang mengikuti Dynamic System Development Method dan praktek yang sejalan dengan Extreme Programmning.

Dynamic System Development Method memiliki beberapa aaktifitas seperti :

-       Feasibility study : siapkan requirement, dan batasan, lalu uji apakah sesuai gunakan proses DSDM

-       Business Study: susun kebutuhan fungsional dan informasi, tentukan arsitektur aplikasi dan identifikasi kebutuhan pemeliharaan untuk aplikasi

-       Functional model iteration : hasilkan incremental prototype yang perlihatkan fungsi software ke klien untuk dapatkan kebutuhan lebih jelas dan konfirmasi

-       Design and Build Iteration : cek ulang prototype yang dibangun untuk pastikan bahwa prototype dibangun dengan cara yang memungkinkan fungsi tersebut benar-benar bekerja

-       Implementation: menempatkan software pada lingkungan sebenar sekalipun belum lengkap, atau masih ada perubahan.

1.2.4. Scrum Methodology

Pertama kali diperkenalkan oleh Jeff Sutherland tahun awal tahun 1990an, dan dikembangkan selanjutnya dilakukan oleh Schwaber dan Beedle. Pada dasarnya Scrum merupakan salah satu komponen dari metodologi pengembangan Agile mengenai pertemuan harian untuk membahas kemajuan dan XP adalah menekankan metodologi yang berbeda sepasang ujian dulu pemrograman dan pembangunan.

Scrum menguraikan proses untuk mengidentifikasi dan katalogisasi pekerjaan yang perlu dilakukan, memprioritaskan yang bekerja dengan berkomunikasi dengan pelanggan atau wakil pelanggan, dan pelaksanaan yang bekerja menggunakan rilis iterative dan memiliki tujuan utama untuk mendapatkan perkiraan berapa lama akan pembangunan. XP lebih lanjut tentang pengembang membantu menyelesaikan pekerjaan secepat dan maintainably mungkin

Scrum memiliki prinsip yaitu:

-         Ukuran tim yang kecil melancarkan komunikasi, mengurangi biaya, dan memberdayakan satu sama lain

-               Proses dapat beradaptasi terhadap perubahan teknis dan bisnis

-               Proses menghasilkan beberapa software increment

-               Pembangunan dan orang yang membangun dibagi dalam tim yang kecil

-         Dokumentasi dan pengujian terus menerus dilakukan setelah software dibangun

-         Proses scrum mampu menyatakan bahwa produk selesai kapanpun diperlukan

Scrum memiliki aktifitas yang meliputi :

1.1. Backlog

Backlog adalah daftar kebutuhan yang jadi prioritas klien, dan daftar yang dibuat  dapat bertambah

1.1. Sprints

Aktifitas Sprints merupakanunit pekerjaan yang diperlukan untuk memenuhi kebutuhan yang ditetapkan dalam backlog sesuai dengan waktu yang ditetapkan dalam time-box (biasanya 30hari). Selama proses ini berlangsung backlog tidak ada penambahan.

1.1. Scrum Meetings

Aktifitas Scrum Meeting merupakan pertemuan yang rutin dilakukan perhari untuk evaluasi apa yang dikerjakan, hambatan yang ada, dan target penyelesaian untuk bahan meeting selanjutnya.

1.1. Demo

Aktifitas Demo adalah penyerahan software increment ke klien didemonstrasikan dan dievaluasi oleh klien.

1.2.5. Crystal

Crystal diperkenalkan oleh Cockburn dan Highsmith, Development yang tidak pada jalur kritis, dapat menghabikan waktu lebih, mereka yang memperbaiki produk atau membantu oaring yang ada di jalur proyek kritis.

Karakteristik Crystal :

1.1. Secara aktual sebuah model proses keluarga yang memungkinkan manuver

berdasar karakteristik permasalahan2. Menyarankan penggunaan workshop refleksi untuk review kebiasaan kerja tim3. Selalu murah dan cepat berkomunikasi secara langsung.4. Proyek berkembang sesuai ukuran team menjadi lebih atau luas dan metologi

akan menjadi lebih tinggi.

1.2.6. Feature Driven Development

Feature Driven Development merupakan model proses praktis untuk keahlian proses software engineering, Feature merupakan sebuah fungsi  yang berharga dimana dapat dilaksanakan.

Keuntungan dari metode feature :

1. User dapat menggambarkan dengan mudah bentuk system.2. Dapat di organisasikan atau diatur ke dallamkelompok bisnis yang hirarki.3. Desain dank ode lebih mudah diperiksa secara efektif.4. Merancang proyek, penjadwalan dan jalur diarahkan oleh feature.

1.2.7. Agile Modeling

Dalam situasi pembangunan software harus membangun sistem bisnis yang besar dan penting. Jangkauan dan kompleksitas sistem harus dimodelkan sehingga dapat dimengerti, masalah dapat dibagi menjadi lebih kecil dan kualitas dapat dijaga pada tiap langkah pembangunan

software. Agile Modeling adalah suatu metodologi yang praktis untuk dokumentasi dan pemodelan system software. Agile Modeling adalah kumpulan nilai-nilai, prinsip dan

praktek-praktek untuk memodelkan software agar dapat diaplikasian pada software development proyek secara efektif.

Prinsip dalam Agile Modeling :

-       Membuat model dengan tujuan: tentukan tujuan sebelum membuat model

-       Mengunakan multiple models: tiap model mewakili aspek yang berbeda dari model lain.

-       Travel light: simpan model-model yang bersifat jangka panjang saja

-       Isi lebih penting dari pada penampilan: modeling menyajikan informasi kepada audiens yang tepat.

-       Memahami model dan alat yang yang digunakan untuk membuat software

-       Adaptasi secara local

1.2.8. Rational Unified Process

Rational Unified Process, adalah suatu kerangka kerja proses pengembangan perangkat lunak iteratif yang dibuat oleh Rational Software, suatu divisi dari IBM sejak 2003. RUP bukanlah suatu proses tunggal dengan aturan yang konkrit, melainkan suatu kerangka proses yang dapat diadaptasi dan dimaksudkan untuk disesuaikan oleh organisasi pengembang dan tim proyek perangkat lunak yang akan memilih elemen proses sesuai dengan kebutuhan mereka.

Model ini membagi suatu sistem aplikasi menjadi beberapa komponen sistem dan memungkinkan para developer aplikasi untuk menerapkan metoda iterative (analisis, disain, implementasi dan pengujian) pada tiap komponen. Dengan menggunakan model ini, RUP membagi tahapan pengembangan perangkat lunaknya ke dalam 4 fase sebagai berikut.

-       Inception, merupakan tahap untuk mengidentifikasi sistem yang akan dikembangkan. Aktivitas yang dilakukan pada tahap ini antara lain mencakup analisis sistem eksisting, perumusan sistem target, penentuan arsitektur global target, identifikasi kebutuhan, perumusan persyaratan perumusan kebutuhan pengujian, pemodelan diagram UML, dan pembuatan dokumentasi.

-       Elaboration, merupakan tahap untuk melakukan disain secara lengkap berdasarkan hasil analisis di tahap inception. Aktivitas yang dilakukan pada tahap ini antara lain mencakup pembuatan disain arsitektur subsistem), disain komponen sistem, disain format data disain database, disain antarmuka/tampilan, disain peta aliran tampilan, penentuan design pattern yang digunakan, pemodelan diagram UML, dan pembuatan dokumentasi.

-       Construction, merupakan tahap untuk mengimplementasikan hasil disain dan melakukan pengujian hasil implementasi. Pada tahap awal construction, ada baiknya dilakukan pemeriksaan ulang hasil analisis dan disain, terutama disain pada domain perilaku (diagram sequence) dan domain struktural (diagram class, component, deployment). Apabila disain yang dibuat telah sesuai dengan analisis sistem, maka implementasi dengan bahasa pemrogramanan tertentu dapat dilakukan. Aktivitas yang dilakukan pada tahap ini antara lain mencakup pengujian hasil analisis dan disain (misal menggunakan Class Responsibility

Collaborator untuk kasus pemrograman berorientasi obyek), pendataan kebutuhan implementasi lengkap (berpedoman pada identifikasi kebutuhan di tahap analisis), penentuan coding pattern yang digunakan, pembuatan program, pengujian, optimasi program, pendataan berbagai kemungkinan pengembangan / perbaikan lebih lanjut, dan pembuatan dokumentasi.

-       Transition, merupakan tahap untuk menyerahkan sistem aplikasi ke konsumen (roll-out), yang umumnya mencakup pelaksanaan pelatihan kepada pengguna dan testing beta aplikasi terhadap ekspetasi pengguna.

Metode Pengembangan Perangkat Lunak AGILEPosted by celulux on 29/08/2010  http://cicink.wordpress.com/2010/08/29/metode-pengembangan-perangkat-lunak-agile/     Rate This

PENGANTAR

Akhir-akhir ini perkembangan perangkat lunak semakin hari semakin pesat, permintaan akan pengadaan perangkat lunak di setiap organisasi perusahaan maupun instansi-instansi pemerintahan semakin meningkat. Hal tersebut dikarenakan tumbuhnya kesadaran dari para pihak pengelola perusaaan atau pejabat tinggi di suatu instansi akan pentingnya penerapan perangkat lunak dalam membantu proses bisnis yang ada. Dengan adanya perangkat lunak ini, maka akan semakin meningkatkan kinerja, mempercepat proses bisnis serta dapat mengurangi biaya (cost) yang harus dikeluarkan oleh pihak perusahaan atau sebuah instansi.

Untuk pembuatan atau pengembangan suatu perangkat lunak terdapat beberapa hal yang harus di perhatikan, mulai dari sumber daya manusia (resources) yang menangani proyek tersebut, sampai dengan metode apa yang harus diterapkan dalam proses pengembangan perangkat lunaknya. Terdapat banyak metode dalam proses pengembangan perangkat lunak salah satunya yaitu metode Agile Sofware Development.

Agile Software development adalah salah satu metodelogi dalam pengembangan sebuah perangkat lunak (software). Kata Agile berarti bersifat cepat, ringan, bebas bergerak, waspada. Kata ini digunakan sebagai kata yang menggambarkan konsep model proses yang berbeda dari konsep model-model proses yang sudah ada. 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.

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

PRINSIP AGILE SOFTWARE DEVELOPMENT

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. Ciri-ciri ini didukung oleh 12 prinsip yang diterapkan oleh Agile Alliance. Menurut Agile Alliance, 12 prinsip ini adalah bagi mereka yang ingin berhasil dalam penerapan Agile Software Development :

Kepuasan klien adalah prioritas utama dengan menghasilkan produk lebih awal dan terus menerus

Menerima perubahan kebutuhan, sekalipun diakhir pengembangan Penyerahan hasil/software dalam hitungan waktu dua minggi sampai dua bulan Bagian bisnis dan pembangun kerja sama tiap hari selama proyek berlangsung Membangun proyek dilingkungan orang-orang yang bermotivasi tinggi yang bekerja

dalam lingkungan yang mendukung dan yang dipercaya untuk dapat menyelesaikan proyek.

Komunikasi dengan berhadapan langsung adalah komunikasi yang efektis dan efisien Software yang berfungsi adalah ukuran utama dari kemajuan proyek Dukungan yang stabil dari sponsor, pembangun, dan pengguna diperlukan untuk

menjaga perkembangan yang berkesinambungan. Perhatian kepada kehebatan teknis dan desain yang bagus meningkatkan sifat agile Kesederhanaan penting Arsitek. Kebutuhan dan desain yang bagus muncul dari tim yang mengatur dirinya

sendiri Secara periodic tim evaluasi diri dan mencari cara untuk lebih efektif dan segera

melakukannya.

Kedua belas prinsip tersebut menjadi suatu dasar bagi model-model proses yang punya sifat agile. Dengan prinsip-prinsip tersebut agile process model berusaha untuk menyiasati 3 asumsi penting tentang proyek software pada umumnya :

Kebutuhan software sulit diprediksi dari awal dan selalu akan berubah. Selain itu, prioritas klien juga sering berjalannya proyek.

Desain dan pembangunan sering tumpang tindih. Sulit diperkirakan seberapa jauh desain yang diperlukan sebelum pembangunan

Analisis, desain, pembangunan dan testing tidak dapat diperkirakan seperti yang diinginkan.

FAKTOR MANUSIA PADA AGILE PROCESS MODEL

Kunci faktor manusia pada model ini adalah proses didasari pada kebutuhan orang dan tim bukan sebaliknya, Untuk dapat sukses menerapkan model proses ini, pada faktor manusia ada beberapa kunci penting:

1. kompetensi: ketrampilan dalam membangun dan pengetahuan tentang proses membangun

2. Fokus: memiliki fokus yang sama sekalipun peran dalam tim berbeda3. Kolaborasi : kerja sama dengan klien, anggota tim dan manajer.4. Kemampuan ambil keputusan : tim pembangun memiliki otonomi dalam pengambilan

keputusan terkait teknis dan proyek5. Kemampuan fuzzy problem-solving: mampu menyelesaikan memilah masalah yang

penting untuk dipecahkan segera atau nanti.6. Saling percaya dan hormat: kekompakan tim yang didukung oleh rasa percaya dan

saling menghargai satu sama lain.7. Manajemen diri: tim mengatur diri untuk selesaikan proyek, mengatur proses untuk

disesuaikan dengan lingkungannya, tim menjadwal dirinya untuk menyerahkan hasil.

AGILE PROCESS MODEL

Berikut ini adalah model-model proses yang termasuk agile process model :

1. XP(Extreme Programming)

a)      Dipublikasikan oleh Kent Beck tahun 1999

b)      Menggunakan pendekatan berorientasi objek

c)      Aktifitas Perencanaan : pengumpulan user stories dari klien yang klien tetapkan prioritasnya. Setiap story ditetapkan harga dan lama pembangunan, jika terlalu besar, story dapat dipecah menjadi beberapa story yang lebih kecil. Periksa dan pertimbangkan resiko

d)      Aktifitas Desain: berprinsip: sederhana.Memanfaatkan kartu CRC (Class-Responsibility-Collaborator) untuk identifikasi dan mengatur class-class di konsep OO. Jika temui kesulitan, prototype dibangun [ini namanya spike solution]. Lakukan refactoring, yaitu mengembangkan desain dari program setelah ditulis

e)      Aktifitas Pengkodean: siapkan unit test sebelum pengkodean dipakai sebagai focus pemrogram untuk membuat program. Pair programming dilakukan untuk real time program solving dan real time quality assurance

f)       Aktifitas Pengujian: menggunakan unit test yang dipersiapkan sebelum pengkodean.

2. Adaptive Software Development (ASD)

a)      Diajukan oleh Jim Highsmith sebagai teknik untuk membangun software dan sistem yang kompleks.

b)      Filosofi yang mendasari adalah kolaborasi manusia dan tim yang mengatur diri sendiri.

c)      Aktifitas: Speculation, Collaboration dan Learning

d)      Aktifitas Speculation : Adaptive cycle planning yaitu menggunakan informasi awal seperti misi dari klien, batasan proyek dan kebutuhan dasar untuk definisikan rangkaian software increment (produk software yang secara berkala diserahkan)

e)      Aktifitas Collaboration : orang-orang yang bermotivasi tinggi bekerja sama: saling melengkapi, rela membantu, kerja keras, trampil di bidangnya, dan komunikasikan masalah untuk hasilkan penyelesaian yang efektif.

f)       Aktifitas Learning: tim pembangun sering merasa sudah tahu semua hal tentang proyek, padahal tidak selamanya begitu. Karena itu proses ini membuat mereka belajar lebih tentang proyek melalui 3 cara:

Focus group: klien dan pengguna memberi masukan terhadap software Formal Technique Reviews: Tim ASD lengkap melakukan review Postmortems: Tim ASD lakukan instrospeksi pada kinerja dan proses.

3. Dynamic Systems Development Method

a)      menyajikan kerangka kerja (framework) untuk membangun dan memelihara sistem dalam waktu yang terbatas melalui penggunaan prototyping yang incremental dalam lingkungan yang terkondisikan.

b)      Membangun software dengan cepat: 80% dari proyek diserahkan dalam 20% dari waktu total untuk menyerahkan proyek secara utuh.

c)      Aktifitas: feasibility study : siapkan requirement, dan batasan, lalu uji apakah sesuai gunakan proses DSDM

d)      Aktifitas: Business Study: susun kebutuhan fungsional dan informasi, tentukan arsitektur aplikasi dan identifikasi kebutuhan pemeliharaan untuk aplikasi

e)      Aktifitas: Functional model iteration : hasilkan incremental prototype yang perlihatkan fungsi software ke klien untuk dapatkan kebutuhan lebih jelas dan konfirmasi

f)       Aktifitas: Design and Build Iteration : cek ulang prototype yang dibangun untuk pastikan bahwa prototype dibangun dengan cara yang memungkinkan fungsi tersebut benar-benar bekerja

g)      Aktifitas: Implementation: menempatkan software pada lingkungan sebenar sekalipun belum lengkap, atau masih ada perubahan.

h)      DSDM dapat dikombinasikan dengan XP menghasilkan kombinasi model proses yang mengikuti DSDM dan praktek yang sejalan dengan XP.

4. Scrum

a.   Diperkenalkan oleh Jeff Sutherland tahun awal tahun 1990an

b.   Pengembangan berikutnya dilakukan oleh Schwaber dan Beedle

c.   Scrum memiliki prinsip :

ukuran tim yang kecil melancarkan komunikasi, mengurangi biaya, dan memberdayakan satu sama lain

proses dapat beradaptasi terhadap perubahan teknis dan bisnis proses menghasilkan beberapa software increment pembangunan dan orang yang membangun dibagi dalam tim yang kecil dokumentasi dan pengujian terus menerus dilakukan setelah software dibangun proses scrum mampu menyatakan bahwa produk selesai kapanpun diperlukan

d.   Aktifitas Scrum : Backlog, Sprints, Scrum Meetings, Demo

e.   Aktifitas Backlog : Backlog adalah daftar kebutuhan yang jadi prioritas klien. Daftar dapat bertambah.

f.   Aktifitas Sprints: unit pekerjaan yang diperlukan untuk memenuhi kebutuhan yang ditetapkan dalam backlog sesuai dengan waktu yang ditetapkan dalam time-box (biasanya 30hari). Selama proses ini berlangsung backlog tidak ada penambahan.

g.   Aktifitas Scrum Meeting: pertemuan 15 menit perhari untuk evaluasi apa yang dikerjakan, hambatan yang ada, dan target penyelesaian untuk bahan meeting selanjutnya.

h.   Aktifitas Demo:penyerahan software increment ke klien didemonstrasikan dan dievaluasi oleh klien.

5. Agile Modeling

a)      Banyak situasi pembangun software harus membangun sistem bisnis yang besar dan penting.Jangkauan dan kompleksitas sistem harus dimodelkan sehingga dapat dimengerti, masalah dapat dibagi menjadi lebih kecil dan kualitas dapat dijaga pada tiap langkah pembangunan software.

b)      AM adalah suatu metodologi yang praktis untuk dokumentasi dan pemodelan sistem software.

c)      AM adalah kumpulan nilai-nilai, prinsip dan praktek-praktek untuk memodelkan software agar dapat diaplikasian pada software development proyek secara efektif.

d)      Prinsip dalam AM;

membuat model dengan tujuan: tentukan tujuan sebelum membuat model mengunakan multiple models: tiap model mewakili aspek yang berbeda dari model

lain. travel light: simpan model-model yang bersifat jangka panjang saja isi lebih penting dari pada penampilan: modeling menyajikan informasi kepada

audiens yang tepat. memahami model dan alat yang yang digunakan untuk membuat software adaptasi secara lokal

PENUTUP

Dari model-model proses di atas dapat diambil beberapa poin penting:

1. komunikasi mempunyai peran penting dalam pembanguna software2. kebutuhan software tidak mudah untuk diidentifikasikan secara lengkap3. kerja sama dalam tim menentukan kelancaran pembangunan software

Aktifitas yang terjadi di dalam Agile Model Process tetap mengandung aktifitas-aktifitas yang ada pada model proses generasi sebelumnya seperti waterfall, incremental, spiral dan RAD. Selain itu, model-model proses di atas tetaplah bukan model proses yang cocok untuk setiap jenis software.

Dengan menerapkan metode agile ini diharapkan pembangunan atau pengembangan perangkat lunak bisa terkontrol dengan baik dan selesai tepat pada waktu yang telah ditetapkan.

Metodologi dalam Rekayasa Perangkat Lunak (RPL) http://philipdarmawan.blogspot.com/2011/09/blog-post.html

Software Development Methodology

Apa itu metodologi ? Metodologi menyusun pendekatan untuk melaksanakan System Development Life Cycle (SDLC), metodologi akan berubah tergantung pada apakah perhatian pada proses bisnis / pada data tersebut mendukung bisnis. Dalam SDLC menyusun 4 pokok fase : planning, analysis, design, dan implementation. Menulis kode tanpa mengetahui secara benar permintaan system maka hanya dapat bekerja untuk program kecil, tetapi jarang bekerja untuk suatu program besar. Metodologi secara umum dibagi menjadi 3 yaitu structure design, rapid Application development (RAD), dan agile development.

>> Dalam metodologi structure design proyek berjalan secara urut dari tahap pertama lalu ke tahap selanjutnya. Intinya, sebuah tahap selesai sebelum tahap selanjutnya dimulai. Pada metodologi structure design ada 2 model yaitu waterfall model dan parallel development.

Contoh gambar waterfall model

> waterfall model

Model ini berurutan dari satu tahap ke tahap selanjutnya. Model ini sesuai bila kebutuhan telah dimengerti

Kelebihan

- Mengidentifikasi kebutuhan system jauh sebelum mulai programming sehingga perubahan kebutuhan diminimalkan

Kekurangan

- Mengerjakannya sangat sulit

- Membutuhkan waktu yang lama antara system proposal dan mengirim system baru

- Design harus selesai sebelum mulai programming

Contoh gambar parallel development

> parallel development

Model ini percobaan ke alamat yang jangka waktunya panjang antara fase analysis dan mengirim system, design umumnya untuk keseluruhan system dilakukan lalu proyek dibagi dalam beberapa subproject

>> Dalam metodologi rapid Application development (RAD) ada 3 model yaitu phased development (versi seri), prototyping (system prototyping), dan throw-away prototyping (design prototyping).

Contoh gambar RAD : phased development

> RAD : phased development

Kelebihan

- Mendapatkan system yang berguna untuk pemakai dengan cepat.

- Sebagian besar fungsi yang penting diuji

Kekurangan

- Inisial system disengaja tidak lengkap

- Kebutuhan sistem mengembangkan sama dengan versi yang dilihat pemakai

Contoh gambar RAD : prototyping

> RAD : prototyping

Model ini diulang-ulang sampai sistemnya lengkap.

Kelebihan

- Mendapatkan working system untuk pemakai dengan cepat

- Menenangkan pemakai saat proyek berjalan / dibuat

- Dengan cepat mencari kebutuhan yang sesungguhnya

Kekurangan

- Langkahnya cepat sehingga sulit untuk menyalurkan dengan hati-hati, methodical analysis

- Masalah dapat dating karena keterangan terlambat di design, sehingga membutuhkan design ulang

Contoh gambar RAD : throw-away prototyping

> RAD : throw-away prototyping

Menggunakan prototypes hanya untuk memahami kebutuhan, prototype tidak mengerjakan design, setiap kebutuhan dimengerti, prototypes tersebut dibuang, system dibuat menggunakan SDLC

>> Dalam metodologi agile development hanya sedikit peraturan yang memudahkan untuk belajar dan diikuti. Mempersingkat SDLC karena menghapuskan banyak model dan dokumentasi; mudah menegaskan, iterative application development. Contoh yang termasuk dalam metodologi ini : Extreme Programming (XP), Scrum, dan dynamic systems development model (DSDM).

> Extreme Programming (XP)

Contoh gambar Extreme Programming (XP)

Pemakai menceritakan tentang system lakukan, kode program kecil, user feedback, diulang-ulang, standart itu penting (naming conventions, dan latihan coding)

Kemudian ada model yang evolusioner yaitu spiral model

Contoh gambar spiral model

Perputaran produk software ini adalah proyek perkembangan konsep, proyek perkembangan produk baru, proyek perbaikan produk, dan proyek ongkos produk. Ada analisa resiko yang berbeda dengan yang lain. Model ini biasanya digunakan untuk proyek yang besar

Kelebihan

- Aplikasi di system dan software besar

- Baik digunakan selama ada mekanisme pengurangan resiko

Kekurangan

- Dalam mengontrol (menuntut resiko tinggi dalam penilaian dan keahlian)

Cara memilih metodologi yang tepat:

1. Kejelasan kebutuhan pemakai

Berdasarkan ketidakjelasan kebutuhan pemakai metodologi yang paling baik RAD : prototyping, RAD : throw-away prototyping dan Extreme Programming (XP) lalu yang paling buruk waterfall model dan parallel development

2. terbiasa dengan teknologi

Berdasarkan ketidakbiasaan dengan teknologi metodologi yang paling baik RAD : throw-away prototyping lalu yang paling buruk waterfall model, parallel development, RAD : prototyping dan Extreme Programming (XP)

3. kompleksitas system

Berdasarkan komplesitas metodologi yang paling baik RAD : throw-away prototyping lalu yang paling buruk RAD : prototyping dan Extreme Programming (XP)

4. system dapat dipercaya

Berdasarkan kepercayaan metodologi yang paling baik RAD : throw-away prototyping lalu yang paling buruk RAD : prototyping

5. jadwal waktu terpendek/tercepat

Berdasarkan waktu yang terpendek/tercepat metodologi yang paling baik RAD : phased development, RAD : prototyping dan Extreme Programming (XP) lalu yang paling buruk waterfall model

6. schedule visibility

Berdasarkan schedule visibility metodologi yang paling baik RAD : phased development dan RAD : prototyping lalu yang paling buruk waterfall model dan parallel development

Scrum Development

10/05/2010 by brianreynaldo

http://brianreynaldo.wordpress.com/2010/05/10/scrum-development/

Pada tulisan ini, saya akan membahas salah satu metodologi dalam Agile Software Development yang cukup populer.  Yaitu Scrum.

Dari penjelasan diatas telah kita ketahui bahwa scrum merupakan salah satu metodologi yang dapat digunakan untuk mengatur (manage) proses pembuatan software menggunakan pendekatan Agile.

Lalu, Kenapa harus memilih scrum?

Nah, menurut saya scrum menarik karena scrum lebih condong pada cara me-manage proyek secara praktikal (practical process model). Lebih menuntun tim untuk melakukan hal-hal yang perlu dan menyarankan hal-hal yang tidak perlu dalam menginspeksi proses dan melakukan adaptasi terus meneus untuk menyetir arah dari proses. Tidak seperti metodologi manajemen proyek lain yang cenderung deskriptif dan heavyweight.Proses eksekusi proyek dengan menggunakan scrum, kira – kira dapat dilakukan seperti dibawah ini :

First meeting o Proses scrum diawli dengan pebuatan tujuan yang akan dicapai dan product backlog.

Product backlog dikuantisasi waktu dengan satuan hari (antara 1-20 hari)Product backlog merupakan ombinasi antara story-based work (pekerjaan yang berbasis use case/product feature) dan task-based work misalnya “Tambahkan validasi pada semua form”Product backlog diprioritaskan oleh product owner.

o Product backlog yang berisi list yang diprioritaskan dari fitur-fitur atau perubahan yang akan ada pada produk.

Sprint planning meeting o Meeting untuk product owner, scrum team dan orang-orang yg berkepentingan.o Menentukan sprint goal yaitu tujuan yang ingin dicapai pada scrum sprint berikutnya

(30 hari kedepan).Sprint goal biasa adalah minimum fungsinalitas yang harus dicapai.Jika sprint goal tidak dicapai maka dilakukan abnormal termination

o Membuat sprint backlog yaitu list dari pekerjaan yang akan dilakukan selama sprint.Sprint backlog merupakan bagian produck backlog yang didetailkan.Sprint backlog dikuantisasi waktu berdasarkan jam (bukan hari yaitu antara 1-16).Sprint backlog harus tranparan untuk semua orang dalam tim

o Meeting yang tidak lebih dari 8 jam saja.Dengan 4 jam pertama adalah waktu yang digunakan untuk Product Owner menjelaskan atau presentasi tentang prioritas dari product backlog.Kemudian tanya jawab dari tim tetang isi, maksud, tujuan dari item yang ada di product backlog.

o Empat jam berikutnya adalah sesi untuk tim merencanakan Sprint.o Fokus pada melakukan pekerjaan bukan berfikir mengenai bagaimana

mengerjakannya.

Daily Scrum meeting (Inspect and adapt cycle) o Meeting harian selama tidak lebih dari 15 menito Yang boleh bicara dalam tim ini adalah scrum master dan anggota tim (pigs)o Orang lain yang bekepentingan (chickens) dapat ikut dalam tim tetapi tidak boleh

berkomunikasi (berbicara)o Scrum master menanyakan 3 pertanyaan dari kepada anggota tim:

Apa yang sudah kamu lakukan kemarin (selama 24 jam kebelakang)? Apa yang akan dikerjakan pada esok hari (24 jam mendatang)? Hal apa yang bisa menghentikan pekerjaan besok hari (kendala)?

Sprint review meeting o Meeting setelah aktivitas selama 2 minggu atau 1 bulanan (Sprint) berakhir, yang

kemudian diikuti oleh sprint planning meeting untuk Sprint berikutnya.o Meeting sebagai review atas Sprint yang sudah dilaksanakan.o Memperbarui (update) sprint backlog yang merefleksikan berapa lama waktu yg

dibutuhkan untuk menyelesaikan pekerjaan (task)

Sprint retrospective meeting o Meeting setelah sprint review meeting dan sprint planning meeting ScrumMaster

dengan tim untuk merevisi proses dan cara kerja Scrum, proses development agar Sprint berikutnya lebih efektif dan enjoyable.

o Meeting ini sebaiknya tidak lebih dari 3 jam.

** Burndown charts

http://ejlp.blogspot.com/2006_04_01_archive.html

Burndown charts adalah grafik yang menunjukan seberapa banyak waktu yang dibutuhkan untuk menyelesaikan proyek. Grafik ini merefleksikan progress dari proyek.

Y-axis: Sisa waktu yang diperlukan untuk menyelesaikan pekerjaan (dalam jam)atau jumlah item pekerjaan yang masih harus diselesaikanX-Axis: Tanggal

Orang yang terlibat dalam proses scrum dibagi menjadi 3 jenis peran (role), yaitu:

Product Owner yaitu orang yang menentukan spesifikasi atau feature dari software yang akan di-deliver.

ScrumMaster yang bertanggung jawab untuk mengatur scrum process selama proyek berjalan. Oleh karena itu ScrumMaster harus menguasai Scrum process. ScrumMaster adalah fasilitator, yang mempersiapkan dan memimpin pertemuan (meeting)

Project Team (tim 7 plus minus 2) yang merupakan self-organizing team yang menjalankan project, seperti business analyst, software architect, developer, tester dan lain-lain.

Dalam Kondisi apa XP dapat digunakan ?http://id.scribd.com/doc/84897571/RUP-XP-dan-SCRUMXP tepat digunakan saat kondisi :•Keperluan berubah dengan cepat•Resiko tinggi dan ada proyek dengan tantangan yang baru•Tim programmer sedikit, yaitu antara 2-10 orang•Mampu mengotomatiskan tes•Ada peran serta pelanggan secara langsung

Tujuan XPTujuan u t ama XP ada l ah menurunkan b i aya da r i adanya pe rubahan software. Da l am me todo log i  pengembangan sistem tradisional, kebutuhan sistem ditentukan pada tahap awal pengembangan proyek dan bersifat fixed. Hal ini berarti biaya terhadap adanya perubahan kebutuhan yang terjadi pada tahapselanjutnya akan menjadi mahal. XP diarahkan untuk menurunkan biaya dari adanya perubahan denganmemperkenalkan nilai-nilai basis dasar, prinsip dan praktis. Dengan menerapkan XP, pengembangansuatu sistem haruslah lebih fleksibel terhadap perubahan.Variabel XPTerdapat 4 variabel XP, yaitu antara lain :1 . C o s t ( b i a y a ) D e n g a n m e n i n g k a t k a n b i a y a , k i t a b i s a m e n c i p t a k a n p r o g r a m y a n g l e b i h b a i k . Sebaliknya mengurangi biaya untuk proyek tidak akan menyelesaikan masalah customer. Tetapi, biaya yang tiak terbatas juga akan menimbulkan kerusakan.

4. SCRUM

http://dhiekalantana.blog.unas.ac.id/2012/10/perbandingan-up-xp-scrum-agile/

Pertama kali diperkenalkan oleh Jeff Sutherland tahun awal tahun 1990an, dan dikembangkan selanjutnya dilakukan oleh Schwaber dan Beedle. Pada dasarnya Scrum merupakan salah satu komponen dari metodologi pengembangan Agile mengenai pertemuan harian untuk membahas kemajuan sedangkan XP adalah menekankan metodologi yang berbeda yaitu ujian, pemrograman dan pembangunan. Scrum menguraikan proses untuk mengidentifikasi dan katalogisasi pekerjaan yang perlu dilakukan, memprioritaskan yang bekerja dengan berkomunikasi dengan pelanggan atau wakil pelanggan, dan pelaksanaan yang bekerja menggunakan rilis iterative dan memiliki tujuan utama untuk mendapatkan perkiraan berapa lama akan pembangunan. XP lebih lanjut tentang pengembang membantu menyelesaikan pekerjaan secepat dan maintainably mungkin

Scrum merupakan suatu kerangka kerja. Jadi, bukannya menyediakan deskripsi rinci tentang bagaimana segala sesuatu yang harus dilakukan pada proyek seperti diserahkan kepada tim pengembangan perangkat lunak pada umumnya. Hal ini dilakukan supaya tim akan tahu bagaimana cara terbaik untuk memecahkan masalah yang mereka disajikan. Ada 3 elemen organisasi utama pada scrum yaitu product owner, Scrum master, dan the Scrum team. Scrum Master dapat dianggap sebagai pelatih bagi tim, membantu anggota tim menggunakan kerangka Scrum untuk tampil di tingkat tertinggi. Product Owner mewakili bisnis, pelanggan atau pengguna dan memandu tim ke arah pegembangan produk yang tepat. Sedangkan The Scrum Team merupakan grup pengembang kecil biasanya terdiri dari 5-9 orang. Untuk projek yang sangat besar, pekerjaan biasanya dibagi dan didelegasikan ke grup-grup kecil. Jika sangat dibutuhkan the scrum master juga dapat ikut membantu dalam koordinasi team.

Scrum tepat digunakan saat kondisi:

Keperluan berubah dengan cepat Tim programmer sedikit, yaitu 5-9 orang Pelanggan tidak terlalu paham dengan apa yang diinginkan

Scrum memiliki prinsip yaitu:

Ukuran tim yang kecil melancarkan komunikasi, mengurangi biaya, dan memberdayakan satu sama lainProses dapat beradaptasi terhadap perubahan teknis dan bisnis

Proses menghasilkan beberapa software increment Pembangunan dan orang yang membangun dibagi dalam tim yang kecil Dokumentasi dan pengujian terus menerus dilakukan setelah software dibangun Proses scrum mampu menyatakan bahwa produk selesai kapanpun diperlukan

Kelebihan Scrum antara lain:

Keperluan berubah dengan cepat Tim berukuran kecil sehingga melancarkan komunikasi, mengurangi biaya dan

memberdayakan satu sama lain Pekerjaan terbagi-bagi sehingga dapat diselesaikan dengan cepat Dokumentasi dan pengujian terus menerus dilakukan setelah software dibangun Proses Scrum mampu menyatakan bahwa produk selesai kapanpun diperlukan

Kelemahan Scrum antara lain:

Developer harus selalu siap dengan perubahan karena perubahan akan selalu diterima.