Pengembangan tangkas: Perbedaan antara revisi

Konten dihapus Konten ditambahkan
k menambahkan Kategori:Perangkat lunak menggunakan HotCat
k clean up, replaced: merubah → mengubah using AWB
Baris 21:
# '''Respon terhadap perubahan''' lebih penting daripada mengikuti rencana.
 
Pengertian dari Agile Alliance's Manifesto<ref name="manifesto>[http:"//agilemanifesto.org/ ''Agile Manifesto'']. Diakses dari situs wikipedia pada 5 November 2013</ref> dijelaskan di bawah ini:
* '''Interaksi dan personel''' lebih penting dari pada proses dan alat, di dalam agile interaksi antar anggota tim sangatlah penting, karena tanpa adanya interaksi yang baik maka proses pembuatan perangkat lunak tidak akan berjalan sesuai rencana.
 
* '''Perangkat lunak yang berfungsi''' lebih penting daripada dokumentasi yang lengkap, saat melakukan proses demonstrasi kepada klien, perangkat lunak yang berfungsi dengan baik akan lebih berguna daripada dokumentasi yang lengkap.
 
* '''Kolaborasi dengan klien''' lebih penting dari pada negosiasi kontrak, salah satu ciri dari agile adalah klien menjadi bagian dari tim pengembangan perangkat lunak. Kolaborasi yang baik dengan klien saat proses pembuatan perangkat lunak sangatlah penting ketika menggunakan agile. Karena fungsi-fungsi dari perangkat lunak yang dikembangkan harus terus menerus dibicarakan dan diimprovisasi disesuaikan dengan keinginan klien.
 
* '''Respon terhadap perubahan''' lebih penting daripada mengikuti rencana, ''agile development methods'' berfokus terhadap kecepatan respon tim ketika klien menginginkan perubahan saat proses pembuatan perangkat lunak.
 
Agar suatu tim berhasil dalam menerapkan ''agile development methods'', maka tim tersebut harus mengikuti dua belas prinsip yang ditetapkan oleh '''Agile Alliance''',<ref name="manifesto>[http:"//agilemanifesto.org/ ''Agile Manifesto'']. Diakses dari situs wikipedia pada 5 November 2013</ref> yaitu :
# Prioritas utama proses ''agile'' adalah memuaskan klien dengan menghasilkan perangkat lunak yang bernilai dengan cepat dan rutin.
# Menyambut perubahan kebutuhan, walaupun terlambat dalam pengembangan perangkat lunak. Proses Agile memanfaatkan perubahan untuk keuntungan kompetitif klien.
Baris 49:
 
==Model proses agile==
[[File:Agile_MethodAgile Method.jpg|thumb|right| Model proses ''agile'']]
Beberapa model dari ''agile development methods'',<ref name="agile>[https:"//en.wikipedia.org/wiki/Agile_software_development ''Agile Software Development'']. Diakses dari situs wikipedia pada 7 November 2013</ref> yaitu :
* Acceptance Test Driven Development (ATDD)
* Agile Modeling
Baris 91:
 
* [[Scrum (development)|Scrum]]
* [[Scrum_Scrum (software_developmentsoftware development)#Scrum-ban|Scrum-ban]]
* [[Story-driven modeling]]
* [[Test-driven development]] (TDD)
* [[Velocity tracking]]
* Software Development Rhythms <ref name="Ambler2012">Ambler, S.W., (2012). Disciplined Agile Delivery (DAD): The Foundation for Scaling Agile ''Presentation Slide'' 15</ref><ref name="Lui2012">Lui, K.M., (2013). Software development rhythms: Searching for Simplicity ''Presentation Slide'' 15</ref>
 
 
==Tujuan agile==
Baris 105 ⟶ 104:
# '''''Cost control & value-driven development''''', salah satu tujuan dari ''agile'' yaitu pengembangan perangkat lunak disesuaikan dengan kebutuhan pengguna, tim bisa dengan cepat merespon kebutuhan yang diinginkan pengguna sehingga waktu dan biaya pembuatan perangkat lunak bisa dikontrol.
# '''''High-quality production''''', walaupun biaya pembuatan perangkat lunak bisa ditekan dan proses pembuatan bisa dipercepat , tetapi kualitas dari perangkat lunak yang dibuat harus tetap dijaga. Dengan melakukan tes setiap fungsionalitas perangkat lunak setelah selesei dibuat berarti ''agile'' juga mengakomodir kebutuhan ini.
# '''''Flexible & risk management''''', jika kita menggunakan metode pembuatan yang biasanya dipakai, jika ingin mengubah fungsionalitas dari ''wireframe'' yang telah dibuat di butuhkan proses yang rumit. Mulai dari pertemuan dengan sistem analis untuk merubahmengubah sistem perangkat lunak, perubahan rencana rilis produk hingga perubahan biaya produksi. Pertemuan dengan klien untuk melakukan tes perangkat lunak juga sering dilakukan sehingga fungsionalitas perangkat lunak mudah diubah dan akhirnya kegagalan perangkat lunakpun bisa diminimalisir.
# '''''Collaboration''''', dengan menggunakan ''agile'', tim pengembang diharuskan sering bertemu untuk membahas perkembangan proyek dan feedback dari klien yang nantinya akan ditambahkan dalam perangkat lunak, sehingga tim bisa berkolaborasi dengan maksimal.
# '''''Self-organizing, self-managing teams''''', rekrut orang terbaik, beri dan dukung kebutuhan mereka lalu biarkan mereka bekerja. Itulah perbedaan ''agile'' dan SDM lainnya. Dengan ''agile'', ''developer'' dapat memanajemen dirinya sendiri, sedangkan manajer tim hanya bertugas mengkolaborasikan ''developer'' perangkat lunak dengan klien. Sehingga terciptalah tim yang solid.
Baris 114 ⟶ 113:
 
===Komposisi tim===
Secara umum komposisi dari sebuah tim pengembang perangkat lunak<ref name="Silverburg,A. 2012">Silverburg,A.(2012).''Agile Analytics in Higher Education''.USA:Phytorion.</ref> yaitu :
* ''Owner'' / Klien, bersama dengan developer sebagai bagian terpenting dalam proyek, tugas dari klien menentukan fungsi dari perangkat lunak yang akan di buat, melakukan testing dan memberikan feedback.
* Manajer / ''Scrum Master'', bertugas mengkolaborasikan developer dengan klien, membuat dan mengevaluasi target pengerjaan perangkat lunak.
Baris 124 ⟶ 123:
Story adalah daftar kebutuhan atau fitur yang nanti akan dibuat. Story berisi apa yang klien kehendaki, dan ditulis dalam bahasa yang dimengerti klien. Dengan kata lain dapat disimpulan Story adalah bagian terpenting dari Scrum.
 
Story terdiri dari kolom-kolom berikut ini<ref name="Kniberg, H. 2007">Kniberg, H.(2007).''Scrum and XP Practice''.USA:C4Media.</ref>:
* ID – Identifikasi unik, biasanya berupa nomor urut. Hal ini untuk menghindari kehilangan jejak story kalau kita mengganti namanya.
* Nama – Nama story bersifat deskriptif, padat, singkat, dan jelas (2-10 kata), sehingga tim dan klien memahami kira-kira story yang dibicarakan.
Baris 133 ⟶ 132:
===Sprint===
 
Sprint (Rapat perencanaan pembuatan perangkat lunak dilakukan 2-8 minggu sekali), yang perlu diperhatikan saat melaksanakan sprint antara lain<ref> name="Kniberg, H.( 2007).''Scrum and XP Practice''.USA:C4Media.<"/ref> :
* Tujuan sprint.
* Daftar anggota tim harus lengkap.
Baris 147 ⟶ 146:
 
===Kelebihan===
Beberapa kelebihan dari ''agile'' diantaranya<ref> name="Silverburg,A.( 2012).''Agile Analytics in Higher Education''.USA:Phytorion.<"/ref> :
* 82% Menambah produktivitas tim.
* 77% Menambah kualitas perangkat lunak.
* 78% Menambah kepuasan klien.
* 37% Menghemat biaya.
 
===Kekurangan===