Pengembangan tangkas: Perbedaan antara revisi
Fitur saranan suntingan: 2 pranala ditambahkan. Tag: VisualEditor Suntingan perangkat seluler Suntingan peramban seluler Tugas pengguna baru Disarankan: tambahkan pranala |
|||
(40 revisi perantara oleh 14 pengguna tidak ditampilkan) | |||
Baris 1: | Baris 1: | ||
{{Orphan|date=Oktober 2016}} |
|||
{{ref improve|date=November 2013}} |
{{ref improve|date=November 2013}} |
||
{{Rapikan|Artikel}} |
|||
'''''Agile Development Methods''''' adalah sekelompok metodologi pengembangan perangkat lunak yang didasarkan pada prinsip-prinsip yang sama atau pengembangan sistem jangka pendek yang memerlukan adaptasi cepat dari pengembang terhadap perubahan dalam bentuk apapun. |
|||
''Agile development methods'' merupakan salah satu dari [[Metodologi pengembangan perangkat lunak]] yang digunakan dalam pengembangan perangkat lunak. Agile memiliki pengertian bersifat cepat, ringan, bebas bergerak, dan waspada |
'''Pengembangan tangkas''' ({{Lang-en|Agile development}}) adalah sekelompok metodologi pengembangan perangkat lunak yang didasarkan pada prinsip-prinsip yang sama atau pengembangan sistem jangka pendek yang memerlukan adaptasi cepat dari pengembang terhadap perubahan dalam bentuk apapun. ''Agile development methods'' merupakan salah satu dari [[Metodologi pengembangan perangkat lunak]] yang digunakan dalam pengembangan perangkat lunak. ''Agile'' memiliki pengertian bersifat cepat, ringan, bebas bergerak, dan waspada,<ref>Proboyekti, U. ''Bahan Ajar Rekayasa Perangkat Lunak Agile Software Development''. Indonesia</ref> Sehingga saat membuat perangkat lunak dengan menggunakan ''agile development methods'', diperlukan inovasi dan tanggung jawab yang baik antara tim pengembang dan klien agar kualitas dari perangkat lunak yang dihasilkan bagus dan kelincahan dari tim seimbang. |
||
⚫ | |||
⚫ | |||
== Pendahuluan == |
== Pendahuluan == |
||
Saat bekerja dalam tim untuk mengerjakan suatu proyek sangatlah penting menentukan [[ |
Saat bekerja dalam tim untuk mengerjakan suatu proyek sangatlah penting menentukan [[metodologi pengembangan perangkat lunak]] dan [[proses pengembangan perangkat lunak]] yang akan digunakan. [[Metodologi pengembangan perangkat lunak]] sendiri adalah sebuah metodologi yang digunakan untuk membuat struktur, rencana, dan kontrol pengerjaan suatu proyek, sedangkan [[proses pengembangan perangkat lunak]] adalah model-model dan metodologi yang digunakan untuk mengembangkan suatu perangkat lunak. Ada beberapa model [[metodologi pengembangan perangkat lunak]] diantaranya: ''waterfall'', ''fountain'', ''spiral'', ''rapid'', ''prototyping'', ''incremental'', ''build & fix'', dan ''synchronize & stabilize''.<ref name=agile>[https://en.wiki-indonesia.club/wiki/Agile_software_development ''Agile Software Development'']. Diakses dari situs wikipedia pada 7 November 2013</ref> Terdapat enam langkah yang digunakan dalam [[metodologi pengembangan perangkat lunak]],<ref name=sdlc>[https://en.wiki-indonesia.club/wiki/Software_development_process ''Software Development Process'']. Diakses dari situs wikipedia pada 7 November 2013</ref> yaitu: |
||
* Perencanaan, pada langkah ini pengembang dan klien membuat rencana tentang kebutuhan dari perangkat lunak yang akan dibuat. |
* Perencanaan, pada langkah ini pengembang dan klien membuat rencana tentang kebutuhan dari perangkat lunak yang akan dibuat. |
||
* Implementasi, bagian dari proses |
* Implementasi, bagian dari proses di mana pemrogram melakukan pengodean perangkat lunak. |
||
* Tes perangkat lunak, |
* Tes perangkat lunak, di sini perangkat lunak yang telah dibuat di tes oleh bagian kontrol kualitas agar ''bug'' yang ditemukan bisa segera diperbaiki dan kualitas perangkat lunak terjaga. |
||
* Dokumentasi, setelah dilakukan tes perangkat lunak langkah selanjutnya yaitu proses dokumentasi perangkat lunak untuk mempermudah proses |
* Dokumentasi, setelah dilakukan tes perangkat lunak langkah selanjutnya yaitu proses dokumentasi perangkat lunak untuk mempermudah proses pemeliharaan (''maintenance'') ke depannya. |
||
* ''Deployment'', yaitu proses yang dilakukan oleh penjamin kualitas untuk menguji kualitas sistem. Setelah sistem memenuhi syarat maka perangkat lunak siap di'' |
* ''Deployment'', yaitu proses yang dilakukan oleh penjamin kualitas untuk menguji kualitas sistem. Setelah sistem memenuhi syarat maka perangkat lunak siap di-''deploy''. |
||
* Pemeliharaan |
* Pemeliharaan yaitu proses pada langkah terakhir. Tidak ada perangkat lunak yang 100% bebas dari ''bug'', oleh karena itu sangatlah penting agar perangkat lunak dipelihara secara berkala. |
||
== Agile manifesto == |
== ''Agile manifesto'' == |
||
[[Berkas:Martin Fowler (2008).jpg| |
[[Berkas:Martin Fowler (2008).jpg|jmpl|ka|[[Martin Fowler]], salah satu pencetus ide ''agile development methods'']] |
||
''Agile development methods'' atau Metode Pengembangan Tangkas terdefinisi dalam empat nilai, biasa di sebut Agile Alliance’s Manifesto,<ref name="AgileManifesto">{{cite web|author=Kent Beck|author-link=Kent Beck|author2=James Grenning|author3=Robert C. Martin|author3-link=Robert Cecil Martin|author4=Mike Beedle|author5=Jim Highsmith|author5-link=Jim Highsmith|author6=Steve Mellor|author6-link=Stephen J. Mellor|author7=Arie van Bennekum|author8=Andrew Hunt|author8-link=Andy Hunt (author)|author9=Ken Schwaber|author9-link=Ken Schwaber|year=2001|title=Manifesto for Agile Software Development|url=http://agilemanifesto.org/|url-status=live|archive-url=|archive-date=|access-date=14 June 2010|website=|publisher=Agile Alliance|author12=Jeff Sutherland|author10-link=Alistair Cockburn|author10=Alistair Cockburn|author11-link=Ron Jeffries|author11=Ron Jeffries|author13-link=Ward Cunningham|author17=Brian Marick|author16=Martin Fowler|author16-link=Martin Fowler (software engineer)|author15=Dave Thomas|author15-link=David A. Thomas (software developer)|author14=Jon Kern|author13=Ward Cunningham|author12-link=Jeff Sutherland}}</ref> di antaranya: |
|||
''Agile development methods'' terdefinisi dalam empat nilai, biasa di sebut Agile Alliance’s Manifesto,<ref name=manifesto>[http://agilemanifesto.org/ ''Agile Manifesto'']. Diakses dari situs wikipedia pada 5 November 2013</ref> diantaranya : |
|||
# '''Interaksi dan personel''' lebih penting daripada proses dan alat. |
# '''Interaksi dan personel''' lebih penting daripada '''proses dan alat'''. |
||
# '''Perangkat lunak yang berfungsi''' lebih penting daripada dokumentasi yang lengkap. |
# '''Perangkat lunak yang berfungsi''' lebih penting daripada '''dokumentasi yang lengkap'''. |
||
# '''Kolaborasi dengan klien''' lebih penting daripada negosiasi kontrak. |
# '''Kolaborasi dengan klien''' lebih penting daripada '''negosiasi kontrak'''. |
||
# ''' |
# '''Respons terhadap perubahan''' lebih penting daripada '''mengikuti rencana'''. |
||
Pengertian dari Agile Alliance's Manifesto<ref name="manifesto"/> dijelaskan di bawah ini: |
Pengertian dari Agile Alliance's Manifesto<ref name="manifesto"/> dijelaskan di bawah ini: |
||
* '''Interaksi dan personel''' lebih penting daripada proses dan alat |
* '''Interaksi dan personel''' lebih penting daripada 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 |
* '''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 daripada negosiasi kontrak |
* '''Kolaborasi dengan klien''' lebih penting daripada 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. |
||
* ''' |
* '''Respons terhadap perubahan''' lebih penting daripada mengikuti rencana. ''Agile development methods'' berfokus terhadap kecepatan respons 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"/> yaitu |
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"/> yaitu: |
||
# Prioritas utama proses ''agile'' adalah memuaskan klien dengan menghasilkan perangkat lunak yang bernilai dengan cepat dan rutin. |
# 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. |
# Menyambut perubahan kebutuhan, walaupun terlambat dalam pengembangan perangkat lunak. Proses Agile memanfaatkan perubahan untuk keuntungan kompetitif klien. |
||
Baris 40: | Baris 40: | ||
# Perhatian yang berkesinambungan terhadap keunggulan teknis dan rancangan yang baik meningkatkan ''Agility''. |
# Perhatian yang berkesinambungan terhadap keunggulan teknis dan rancangan yang baik meningkatkan ''Agility''. |
||
# Kesederhanaan (memaksimalkan sumber daya yang tersedia) adalah hal yang amat penting. |
# Kesederhanaan (memaksimalkan sumber daya yang tersedia) adalah hal yang amat penting. |
||
# Arsitektur, kebutuhan, dan rancangan perangkat lunak terbaik muncul dari tim |
# Arsitektur, kebutuhan, dan rancangan perangkat lunak terbaik muncul dari tim yang dapat mengorganisir diri sendiri. |
||
# Secara berkala, tim pengembang berefleksi tentang bagaimana untuk menjadi lebih efektif, kemudian menyesuaikan dan menyelaraskan kebiasaan bekerja mereka. |
# Secara berkala, tim pengembang berefleksi tentang bagaimana untuk menjadi lebih efektif, kemudian menyesuaikan dan menyelaraskan kebiasaan bekerja mereka. |
||
Dua belas prinsip tersebut menjadi suatu dasar bagi tim agar sukses menerapkan ''agile development methods''. Dengan prinsip-prinsip tersebut ''agile'' berusaha untuk menyiasati tiga masalah yang biasanya dihadapi saat proses pembuatan perangkat lunak, yaitu: |
Dua belas prinsip tersebut menjadi suatu dasar bagi tim agar sukses menerapkan ''agile development methods''. Dengan prinsip-prinsip tersebut ''agile'' berusaha untuk menyiasati tiga masalah yang biasanya dihadapi saat proses pembuatan perangkat lunak, yaitu: |
||
Baris 47: | Baris 47: | ||
* Analisis, desain, pembangunan dan testing tidak dapat diperkirakan seperti yang diinginkan. |
* Analisis, desain, pembangunan dan testing tidak dapat diperkirakan seperti yang diinginkan. |
||
== Model proses agile == |
== Model proses ''agile'' == |
||
[[Berkas:Agile Method.jpg| |
[[Berkas:Agile Method.jpg|jmpl|ka| Model proses ''agile'']] |
||
Beberapa model dari ''agile development methods'',<ref name="agile"/> yaitu |
Beberapa model dari ''agile development methods'',<ref name="agile"/> yaitu: |
||
* Acceptance Test Driven Development (ATDD) |
* Acceptance Test Driven Development (ATDD) |
||
* Agile Modeling |
* [[Agile Modelling (AM)|Agile Modeling]] |
||
* Adaptive Software Development (ASD) |
* [[Adaptive Software Development|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'' adalah kolaborasi manusia dan tim yang mengatur diri sendiri. Sistem kerja ''adaptive software development'' |
:Adaptive software development (ASD) diajukan oleh Jim Highsmith sebagai teknik untuk membangun software dan sistem yang kompleks. Filosofi yang mendasari ''adaptive software development'' adalah kolaborasi manusia dan tim yang mengatur diri sendiri. Sistem kerja ''adaptive software development'': collaboration dan learning. ' |
||
:# Collaboration |
:# Collaboration: orang-orang yang bermotivasi tinggi bekerja sama, saling melengkapi, rela membantu, kerja keras, terampil di bidangnya, dan komunikasikan masalah untuk menyelesaikan masalah secara efektif. |
||
:# Learning: tim developer sering merasa sudah tahu semua hal tentang proyek, padahal tidak selamanya begitu. Karena itu proses ini membuat mereka belajar lebih tentang proyek melalui tiga cara: |
:# Learning: tim developer sering merasa sudah tahu semua hal tentang proyek, padahal tidak selamanya begitu. Karena itu proses ini membuat mereka belajar lebih tentang proyek melalui tiga cara: |
||
:# Fokus grup, klien dan pengguna memberi masukan terhadap perangkat lunak. |
:# Fokus grup, klien dan pengguna memberi masukan terhadap perangkat lunak. |
||
:# Formal Technique Reviews, tim ASD lengkap melakukan review. |
:# Formal Technique Reviews, tim ASD lengkap melakukan review. |
||
:# Postmortems, tim ASD melakukan |
:# Postmortems, tim ASD melakukan introspeksi pada kinerja dan proses |
||
* [[Agile Unified Process]] (AUP) |
* [[Agile Unified Process (AUP)|Agile Unified Process]] (AUP) |
||
* [[Continuous integration]] (CI) |
* [[Continuous integration]] (CI) |
||
* [[Crystal Clear (software development)|Crystal Clear]] |
* [[Crystal Clear (software development)|Crystal Clear]] |
||
* Crystal Methods |
* Crystal Methods |
||
* Dynamic Systems Development Method (DSDM) |
* [[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 prototip yang incremental dalam lingkungan yang terkondisikan. Metode ini bisa membuat pengerjaan software lebih cepat 80%.Hal -hal yang perlu diperhatikan jika menggunakan ''dynamic system development method'': |
:Pada Dynamic System Development Method menyajikan kerangka kerja (framework) untuk membangun dan memelihara sistem dalam waktu yang terbatas melalui penggunaan prototip yang incremental dalam lingkungan yang terkondisikan. Metode ini bisa membuat pengerjaan software lebih cepat 80%.Hal -hal yang perlu diperhatikan jika menggunakan ''dynamic system development method'': |
||
:# Feasibility study, siapkan requirement, dan batasan, lalu uji apakah sesuai gunakan proses DSDM. |
:# ''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. |
:# ''Business Study'', susun kebutuhan fungsional dan informasi, tentukan arsitektur aplikasi dan identifikasi kebutuhan pemeliharaan untuk aplikasi. |
||
:# Functional model iteration, perlihatkan fungsi perangkat lunak ke klien untuk mendapatkan ''feedback'' |
:# ''Functional model iteration'', perlihatkan fungsi perangkat lunak ke klien untuk mendapatkan ''feedback'' |
||
:# Design and Build Iteration, cek ulang |
:# ''Design and Build Iteration'', cek ulang prototipe yang dibangun dan pastikan bahwa prototipe dibangun dengan cara yang memungkinkan fungsi tersebut benar-benar bekerja. |
||
:# Implementation: buat perangkat lunak sesuai |
:# ''Implementation'': buat perangkat lunak sesuai prototipe yang ada dan terus tambah fungsionalitasnya. |
||
* [[Extreme Programming]] (XP) |
* [[Extreme programming|Extreme Programming]] (XP) |
||
* [[Feature Driven Development]] (FDD) |
* [[Feature-driven Development (FDD)|Feature Driven Development]] (FDD) |
||
:Feature driven development merupakan sebuah model pengembangan perangkat lunak yang berdasarkan pada fitur yang akan dibuat. Keuntungan dari metode ''feature driven development'' |
:''Feature driven development'' merupakan sebuah model pengembangan perangkat lunak yang berdasarkan pada fitur yang akan dibuat. Keuntungan dari metode ''feature driven development'': |
||
:# |
:# Pengguna dapat menggambarkan dengan mudah bentuk sistem yang akan dibuat. |
||
:# Dapat diorganisasikan atau diatur ke dalam kelompok bisnis sesuai hierarki yang ada. |
:# Dapat diorganisasikan atau diatur ke dalam kelompok bisnis sesuai hierarki yang ada. |
||
:# Desain dan kode lebih mudah diperiksa secara efektif. |
:# Desain dan kode lebih mudah diperiksa secara efektif. |
||
Baris 83: | Baris 85: | ||
* [[Kanban (development)|Kanban]] |
* [[Kanban (development)|Kanban]] |
||
* [[Lean software development]] |
* [[Lean software development]] |
||
* Rational Unified Process (RUP) |
* [[Rational Unified Process]] (RUP) |
||
:''Rational unified process'', adalah suatu kerangka pengembangan perangkat lunak iteratif yang dibuat oleh '''Rational Software''', suatu divisi dari IBM sejak 2003. ''Rational unified process'' bukanlah suatu proses dengan aturan yang konkrit, melainkan suatu kerangka proses yang dapat diadaptasi dan dimaksudkan untuk disesuaikan oleh tim pengembang perangkat lunak yang akan memilih elemen proses disesuaikan dengan kebutuhan mereka.Model ini membagi suatu sistem aplikasi menjadi beberapa komponen sistem dan memungkinkan para developer aplikasi untuk menerapkan |
:''Rational unified process'', adalah suatu kerangka pengembangan perangkat lunak iteratif yang dibuat oleh '''Rational Software''', suatu divisi dari [[IBM]] sejak 2003. ''Rational unified process'' bukanlah suatu proses dengan aturan yang konkrit, melainkan suatu kerangka proses yang dapat diadaptasi dan dimaksudkan untuk disesuaikan oleh tim pengembang perangkat lunak yang akan memilih elemen proses disesuaikan dengan kebutuhan mereka.Model ini membagi suatu sistem aplikasi menjadi beberapa komponen sistem dan memungkinkan para developer aplikasi untuk menerapkan metode iterative (analisis, disain, implementasi dan pengujian) pada tiap komponen. Dengan menggunakan model ini, ''Rational unified process'' 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, perumusan target dari sistem yang dibuat, identifikasi kebutuhan, perumusan kebutuhan pengujian, pemodelan diagram UML, dan pembuatan dokumentasi. |
:# ''Inception'', merupakan tahap untuk mengidentifikasi sistem yang akan dikembangkan. Aktivitas yang dilakukan pada tahap ini antara lain mencakup analisis sistem, perumusan target dari sistem yang dibuat, identifikasi kebutuhan, 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 tampilan, penentuan ''design pattern'' yang digunakan, 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]] tampilan, penentuan ''design pattern'' yang digunakan, pemodelan diagram UML, dan pembuatan dokumentasi. |
||
:# Construction, merupakan tahap untuk mengimplementasikan hasil |
:# ''Construction'', merupakan tahap untuk mengimplementasikan hasil desain dan melakukan pengujian hasil implementasi. Pada tahap awal ''construction'', ada baiknya dilakukan pemeriksaan ulang hasil analisis dan desain, terutama disain pada diagram ''sequence,class, component, dan deployment''. Apabila disain yang dibuat telah sesuai dengan analisis sistem, maka implementasi dengan [[bahasa pemrograman]] 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 objek]]), 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 |
:# ''Transition'', merupakan tahap untuk menyerahkan sistem aplikasi ke konsumen (''roll-out''), yang umumnya mencakup pelaksanaan pelatihan kepada pengguna dan testing beta aplikasi terhadap ekspektasi pengguna. |
||
* [[ |
* [[Scrum]] |
||
* [[Scrum (software development)#Scrum-ban|Scrum-ban]] |
* [[Scrum (software development)#Scrum-ban|Scrum-ban]] |
||
* [[Story-driven modeling]] |
* [[Story-driven modeling]] |
||
* [[Test-driven development]] (TDD) |
* [[Test-driven development]] (TDD) |
||
* [[Velocity tracking]] |
* [[Velocity tracking]] |
||
* Software Development Rhythms |
* 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 == |
== Tujuan ''agile'' == |
||
Secara garis besar tujuan dirumuskannya ''agile development methods'',<ref>Collier, K.(2011).''Agile Analytics: A Value-Driven Approach to Business Intelligence and Data Warehousing''.USA:Addison-Wesley.</ref> yaitu |
Secara garis besar tujuan dirumuskannya ''agile development methods'',<ref>Collier, K.(2011).''Agile Analytics: A Value-Driven Approach to Business Intelligence and Data Warehousing''.USA:Addison-Wesley.</ref> yaitu: |
||
# '''''High-value & working |
# '''''High-value & working app system''''', diharapkan dengan memakai ''agile development methods'' dapat dihasilkan perangkat lunak yang mempunyai nilai jual yang tinggi, biaya pembuatan bisa di tekan dan perangkat lunak bisa berjalan dengan baik. |
||
# '''''Iterative, incremental, evolutionary''''', ''agile'' adalah metode pengembangan perangkat lunak yang iteratif, selalu mengalami perubahan, dan evolusioner. Tim harus bekerja dalam waktu yang singkat(biasanya 1-3 minggu) dan juga selalu menambah fungsionalitas dari perangkat lunak sesuai dengan kebutuhan klien. ''Agile'' dapat dianalogikan ketika seseorang ingin pergi ke suatu kota dan dia tidak tahu jalannya. Lalu bagaimana dia bisa sampai tujuan? Dengan sering bertanya kepada orang yang dia temui |
# '''''Iterative, incremental, evolutionary''''', ''agile'' adalah metode pengembangan perangkat lunak yang iteratif, selalu mengalami perubahan, dan evolusioner. Tim harus bekerja dalam waktu yang singkat(biasanya 1-3 minggu) dan juga selalu menambah fungsionalitas dari perangkat lunak sesuai dengan kebutuhan klien. ''Agile'' dapat dianalogikan ketika seseorang ingin pergi ke suatu kota dan dia tidak tahu jalannya. Lalu bagaimana dia bisa sampai tujuan? Dengan sering bertanya kepada orang yang dia temui di jalan hingga dia sampai di tempat tujuan. |
||
# '''''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. |
# '''''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 |
# '''''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 selesai dibuat berarti ''agile'' juga mengakomodasi 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 mengubah 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 |
# '''''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 mengubah 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 lunak pun bisa diminimalkan. |
||
# '''''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. |
# '''''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 |
# '''''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 mengolaborasikan ''developer'' perangkat lunak dengan klien. Sehingga terciptalah tim yang solid. |
||
== Bagaimana agile bekerja == |
== Bagaimana ''agile'' bekerja == |
||
Topik selanjutnya yaitu tentang cara kerja ''agile development methods''. |
Topik selanjutnya yaitu tentang cara kerja ''agile development methods''. Di bagian ini akan dijelaskan bagaimana ''agile development methods'' diterapkan menggunakan model proses ''[[scrum|scrum]]'' dalam [[manajemen proyek]]. |
||
=== Komposisi tim === |
=== 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 |
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. |
* ''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 |
* Manajer / ''Scrum Master'', bertugas mengolaborasikan developer dengan klien, membuat dan mengevaluasi target pengerjaan perangkat lunak. |
||
* Sistem Analis, membuat arsitektur sistem dari perangkat lunak yang akan dibuat. |
* Sistem Analis, membuat arsitektur sistem dari perangkat lunak yang akan dibuat. |
||
* Developer, merupakan titik vital dalam tim, tanpa developer perangkat lunak tidak akan bisa dibuat. |
* Developer, merupakan titik vital dalam tim, tanpa developer perangkat lunak tidak akan bisa dibuat. |
||
=== Story === |
=== ''Story'' === |
||
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 |
''Story atau User 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 disimpulkan 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> |
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. |
* 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. |
* Nama – Nama ''story'' bersifat deskriptif, padat, singkat, dan jelas (2-10 kata), sehingga tim dan klien memahami kira-kira ''story'' yang dibicarakan. |
||
* Kepentingan – Derajat kepentingan yang diberikan oleh klien terhadap story. Pemberian derajat kepentingan biasanya menggunakan deret fibonacci (1,1,2,3,5,dst). Semakin tinggi nilainya maka semakin tinggi pula prioritas pengerjaannya. |
* Kepentingan – Derajat kepentingan yang diberikan oleh klien terhadap ''story''. Pemberian derajat kepentingan biasanya menggunakan deret fibonacci (1,1,2,3,5,dst). Semakin tinggi nilainya maka semakin tinggi pula prioritas pengerjaannya. |
||
* Perkiraan awal – Perkiraan awal tim tentang berapa banyak kerja yang diperlukan untuk mengimplementasikan sebuah story. |
* Perkiraan awal – Perkiraan awal tim tentang berapa banyak kerja yang diperlukan untuk mengimplementasikan sebuah ''story''. |
||
* Demo – deskripsi umum bagaimana cara story ini didemokan pada waktu sprint demo (lakukan ini, klik itu, lalu ini akan muncul,dll). |
* Demo – deskripsi umum bagaimana cara ''story'' ini didemokan pada waktu sprint demo (lakukan ini, klik itu, lalu ini akan muncul, dll.). |
||
=== Sprint === |
=== ''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"/> |
''Sprint'' (Rapat perencanaan pembuatan perangkat lunak dilakukan 2-8 minggu sekali), yang perlu diperhatikan saat melaksanakan sprint antara lain:<ref name="Kniberg, H. 2007"/> |
||
* Tujuan sprint. |
* Tujuan ''sprint''. |
||
* Daftar anggota tim harus lengkap. |
* Daftar anggota tim harus lengkap. |
||
* Sprint backlog (daftar story yang akan diikutkan dalam sprint). |
* ''Sprint backlog'' (daftar ''story'' yang akan diikutkan dalam ''sprint''). |
||
* Tanggal demo yang pasti. |
* Tanggal demo yang pasti. |
||
* Tempat dan waktu yang jelas untuk pelaksanaan sprint berikutnya. |
* Tempat dan waktu yang jelas untuk pelaksanaan ''sprint'' berikutnya. |
||
Tim akan melakukan sprint secara simultan sampai perangkat lunak |
Tim akan melakukan ''sprint'' secara simultan sampai perangkat lunak selesai dikerjakan, sebagai contoh: |
||
Sprint 1, tim membuat fungsi login,logout dan demo perangkat lunak akan dilakukan 3 minggu kemudian. Setelah dilakukan demo untuk mengevaluasi kerja yang dilakukan tim pada Sprint 1, maka Sprint 1 dianggap |
Sprint 1, tim membuat fungsi ''login'', ''logout'' dan demo perangkat lunak akan dilakukan 3 minggu kemudian. Setelah dilakukan demo untuk mengevaluasi kerja yang dilakukan tim pada Sprint 1, maka Sprint 1 dianggap selesai. Bahan evaluasi dari Sprint 1 akan dibawa ke Sprint 2 begitu seterusnya sampai aplikasi selesai dikerjakan. |
||
== Kelebihan dan Kekurangan == |
== Kelebihan dan Kekurangan == |
||
=== Kelebihan === |
=== Kelebihan === |
||
Beberapa kelebihan dari ''agile'' |
Beberapa kelebihan dari ''agile'', di antaranya:<ref name="Silverburg,A. 2012"/> |
||
* 82% Menambah produktivitas tim. |
* 82% Menambah produktivitas tim. |
||
* 77% Menambah kualitas perangkat lunak. |
* 77% Menambah kualitas perangkat lunak. |
||
* 78% Menambah kepuasan klien. |
* 78% Menambah kepuasan klien. |
||
* 37% Menghemat biaya. |
* 37% Menghemat biaya. |
||
=== Kekurangan === |
=== Kekurangan === |
||
Sedangkan kekurangan dari ''agile'' antara lain |
Sedangkan kekurangan dari ''agile'' antara lain: |
||
* Agile tidak akan berjalan dengan baik jika komitmen tim kurang. |
* ''Agile'' tidak akan berjalan dengan baik jika komitmen tim kurang. |
||
* Tidak cocok dalam skala tim yang besar (>20 orang). |
* Tidak cocok dalam skala tim yang besar (>20 orang). Walaupun demikian dalam perkembangan zaman, beberapa metode baru telah dicetuskan untuk meningkatkan skalabilitas dari metode ini. |
||
* Perkiraan waktu release dan harga perangkat lunak sulit ditentukan. |
* Perkiraan waktu ''release'' dan harga perangkat lunak sulit ditentukan. |
||
== Sumber (''Resources'') == |
== Sumber (''Resources'') == |
||
Untuk memperdalam pengetahuan tentang ''agile development methods'', anda bisa mengunjungi website di bawah ini<ref>Taymor, E.''Agile Handbook''.USA:Philosophie.</ref> |
Untuk memperdalam pengetahuan tentang ''agile development methods'', anda bisa mengunjungi website di bawah ini:<ref>Taymor, E.''Agile Handbook''.USA:Philosophie.</ref> |
||
* [http://pragprog.com/book/jtrap/the-agile-samurai The agile samurai] |
* [http://pragprog.com/book/jtrap/the-agile-samurai The agile samurai] |
||
: Secara garis besar buku ini menjelaskan tentang |
: Secara garis besar buku ini menjelaskan tentang: |
||
:* Cara membuat perencanaan dan jadwal pembuatan aplikasi. |
:* Cara membuat perencanaan dan jadwal pembuatan aplikasi. |
||
:* Karakteristik untuk membuat tim yang tangkas dan bisa memanajemen dirinya sendiri. |
:* Karakteristik untuk membuat tim yang tangkas dan bisa memanajemen dirinya sendiri. |
||
Baris 168: | Baris 170: | ||
:* Bagaimana mengeksekusi rencana yang ada dengan sumber daya yang tersedia dengan tepat. |
:* Bagaimana mengeksekusi rencana yang ada dengan sumber daya yang tersedia dengan tepat. |
||
* [http://agilemanifesto.org The agile manifesto] |
* [http://agilemanifesto.org The agile manifesto] |
||
: Merupakan salah situs yang wajib dibaca bila anda ingin belajar tentang ''agile development methods'', didalamnya anda dapat menemukan informasi diantaranya |
: Merupakan salah situs yang wajib dibaca bila anda ingin belajar tentang ''agile development methods'', didalamnya anda dapat menemukan informasi diantaranya: |
||
:* Cara untuk mengembangkan perangkat dengan menggunakan prinsip-prinsip dari agile. |
:* Cara untuk mengembangkan perangkat dengan menggunakan prinsip-prinsip dari agile. |
||
:* Bagaimana tim berinteraksi selama proses pembuatan perangkat lunak. |
:* Bagaimana tim berinteraksi selama proses pembuatan perangkat lunak. |
||
:* 12 prinsip ''agile manifesto''. |
:* 12 prinsip ''agile manifesto''. |
||
* [http://linkedin.com/groups/Agile-Lean-Software-Development-37631 Agile and lean software development linkedin group] |
* [http://linkedin.com/groups/Agile-Lean-Software-Development-37631 Agile and lean software development linkedin group] |
Revisi terkini sejak 16 Juli 2024 10.54
Artikel ini membutuhkan rujukan tambahan agar kualitasnya dapat dipastikan. (November 2013) |
![]() | Artikel ini perlu dirapikan agar memenuhi standar Wikipedia. |
Pengembangan tangkas (bahasa Inggris: Agile development) adalah sekelompok metodologi pengembangan perangkat lunak yang didasarkan pada prinsip-prinsip yang sama atau pengembangan sistem jangka pendek yang memerlukan adaptasi cepat dari pengembang terhadap perubahan dalam bentuk apapun. Agile development methods merupakan salah satu dari Metodologi pengembangan perangkat lunak yang digunakan dalam pengembangan perangkat lunak. Agile memiliki pengertian bersifat cepat, ringan, bebas bergerak, dan waspada,[1] Sehingga saat membuat perangkat lunak dengan menggunakan agile development methods, diperlukan inovasi dan tanggung jawab yang baik antara tim pengembang dan klien agar kualitas dari perangkat lunak yang dihasilkan bagus dan kelincahan dari tim seimbang.
![](http://upload.wikimedia.org/wikipedia/commons/thumb/f/ff/Generic_diagram_of_an_agile_methodology_for_software_development.png/220px-Generic_diagram_of_an_agile_methodology_for_software_development.png)
Pendahuluan
[sunting | sunting sumber]Saat bekerja dalam tim untuk mengerjakan suatu proyek sangatlah penting menentukan metodologi pengembangan perangkat lunak dan proses pengembangan perangkat lunak yang akan digunakan. Metodologi pengembangan perangkat lunak sendiri adalah sebuah metodologi yang digunakan untuk membuat struktur, rencana, dan kontrol pengerjaan suatu proyek, sedangkan proses pengembangan perangkat lunak adalah model-model dan metodologi yang digunakan untuk mengembangkan suatu perangkat lunak. Ada beberapa model metodologi pengembangan perangkat lunak diantaranya: waterfall, fountain, spiral, rapid, prototyping, incremental, build & fix, dan synchronize & stabilize.[2] Terdapat enam langkah yang digunakan dalam metodologi pengembangan perangkat lunak,[3] yaitu:
- Perencanaan, pada langkah ini pengembang dan klien membuat rencana tentang kebutuhan dari perangkat lunak yang akan dibuat.
- Implementasi, bagian dari proses di mana pemrogram melakukan pengodean perangkat lunak.
- Tes perangkat lunak, di sini perangkat lunak yang telah dibuat di tes oleh bagian kontrol kualitas agar bug yang ditemukan bisa segera diperbaiki dan kualitas perangkat lunak terjaga.
- Dokumentasi, setelah dilakukan tes perangkat lunak langkah selanjutnya yaitu proses dokumentasi perangkat lunak untuk mempermudah proses pemeliharaan (maintenance) ke depannya.
- Deployment, yaitu proses yang dilakukan oleh penjamin kualitas untuk menguji kualitas sistem. Setelah sistem memenuhi syarat maka perangkat lunak siap di-deploy.
- Pemeliharaan yaitu proses pada langkah terakhir. Tidak ada perangkat lunak yang 100% bebas dari bug, oleh karena itu sangatlah penting agar perangkat lunak dipelihara secara berkala.
Agile manifesto
[sunting | sunting sumber]![](http://upload.wikimedia.org/wikipedia/commons/thumb/f/f8/Martin_Fowler_%282008%29.jpg/220px-Martin_Fowler_%282008%29.jpg)
Agile development methods atau Metode Pengembangan Tangkas terdefinisi dalam empat nilai, biasa di sebut Agile Alliance’s Manifesto,[4] di antaranya:
- Interaksi dan personel lebih penting daripada proses dan alat.
- Perangkat lunak yang berfungsi lebih penting daripada dokumentasi yang lengkap.
- Kolaborasi dengan klien lebih penting daripada negosiasi kontrak.
- Respons terhadap perubahan lebih penting daripada mengikuti rencana.
Pengertian dari Agile Alliance's Manifesto[5] dijelaskan di bawah ini:
- Interaksi dan personel lebih penting daripada 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 daripada 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.
- Respons terhadap perubahan lebih penting daripada mengikuti rencana. Agile development methods berfokus terhadap kecepatan respons 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,[5] 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.
- Menghasilkan perangkat lunak yang bekerja secara rutin, dari jangka waktu beberapa minggu sampai beberapa bulan, dengan preferensi kepada jangka waktu yang lebih pendek.
- Rekan bisnis dan pengembang perangkat lunak harus bekerja sama tiap hari sepanjang proyek.
- Kembangkan proyek di sekitar individual yang termotivasi. Berikan mereka lingkungan dan dukungan yang mereka butuhkan, dan percayai mereka untuk menyelesaikan pekerjaan dengan baik.
- Metode yang paling efisien dan efektif untuk menyampaikan informasi dari dan dalam tim pengembang perangkat lunak adalah dengan komunikasi secara langsung.
- Perangkat lunak yang bekerja adalah ukuran utama kemajuan.
- Proses agile menggalakkan pengembangan berkelanjutan. Sponsor-sponsor, pengembang-pengembang, dan pengguna-pengguna dapat mempertahankan kecepatan tetap secara berkelanjutan.
- Perhatian yang berkesinambungan terhadap keunggulan teknis dan rancangan yang baik meningkatkan Agility.
- Kesederhanaan (memaksimalkan sumber daya yang tersedia) adalah hal yang amat penting.
- Arsitektur, kebutuhan, dan rancangan perangkat lunak terbaik muncul dari tim yang dapat mengorganisir diri sendiri.
- Secara berkala, tim pengembang berefleksi tentang bagaimana untuk menjadi lebih efektif, kemudian menyesuaikan dan menyelaraskan kebiasaan bekerja mereka.
Dua belas prinsip tersebut menjadi suatu dasar bagi tim agar sukses menerapkan agile development methods. Dengan prinsip-prinsip tersebut agile berusaha untuk menyiasati tiga masalah yang biasanya dihadapi saat proses pembuatan perangkat lunak, yaitu:
- Kebutuhan perangkat lunak sulit diprediksi dari awal dan selalu akan berubah. Selain itu, prioritas klien juga sering berubah seiring 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.
Model proses agile
[sunting | sunting sumber]![](http://upload.wikimedia.org/wikipedia/id/thumb/8/83/Agile_Method.jpg/220px-Agile_Method.jpg)
Beberapa model dari agile development methods,[2] yaitu:
- Acceptance Test Driven Development (ATDD)
- Agile Modeling
- 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 adalah kolaborasi manusia dan tim yang mengatur diri sendiri. Sistem kerja adaptive software development: collaboration dan learning. '
- Collaboration: orang-orang yang bermotivasi tinggi bekerja sama, saling melengkapi, rela membantu, kerja keras, terampil di bidangnya, dan komunikasikan masalah untuk menyelesaikan masalah secara efektif.
- Learning: tim developer sering merasa sudah tahu semua hal tentang proyek, padahal tidak selamanya begitu. Karena itu proses ini membuat mereka belajar lebih tentang proyek melalui tiga cara:
- Fokus grup, klien dan pengguna memberi masukan terhadap perangkat lunak.
- Formal Technique Reviews, tim ASD lengkap melakukan review.
- Postmortems, tim ASD melakukan introspeksi pada kinerja dan proses
- Agile Unified Process (AUP)
- Continuous integration (CI)
- Crystal Clear
- Crystal Methods
- 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 prototip yang incremental dalam lingkungan yang terkondisikan. Metode ini bisa membuat pengerjaan software lebih cepat 80%.Hal -hal yang perlu diperhatikan jika menggunakan dynamic system development method:
- 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, perlihatkan fungsi perangkat lunak ke klien untuk mendapatkan feedback
- Design and Build Iteration, cek ulang prototipe yang dibangun dan pastikan bahwa prototipe dibangun dengan cara yang memungkinkan fungsi tersebut benar-benar bekerja.
- Implementation: buat perangkat lunak sesuai prototipe yang ada dan terus tambah fungsionalitasnya.
- Extreme Programming (XP)
- Feature Driven Development (FDD)
- Feature driven development merupakan sebuah model pengembangan perangkat lunak yang berdasarkan pada fitur yang akan dibuat. Keuntungan dari metode feature driven development:
- Pengguna dapat menggambarkan dengan mudah bentuk sistem yang akan dibuat.
- Dapat diorganisasikan atau diatur ke dalam kelompok bisnis sesuai hierarki yang ada.
- Desain dan kode lebih mudah diperiksa secara efektif.
- Perancangan proyek, biaya pembuatan dan jadwal rilis ditentukan oleh fiturnya.
- Rational unified process, adalah suatu kerangka pengembangan perangkat lunak iteratif yang dibuat oleh Rational Software, suatu divisi dari IBM sejak 2003. Rational unified process bukanlah suatu proses dengan aturan yang konkrit, melainkan suatu kerangka proses yang dapat diadaptasi dan dimaksudkan untuk disesuaikan oleh tim pengembang perangkat lunak yang akan memilih elemen proses disesuaikan dengan kebutuhan mereka.Model ini membagi suatu sistem aplikasi menjadi beberapa komponen sistem dan memungkinkan para developer aplikasi untuk menerapkan metode iterative (analisis, disain, implementasi dan pengujian) pada tiap komponen. Dengan menggunakan model ini, Rational unified process 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, perumusan target dari sistem yang dibuat, identifikasi kebutuhan, 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 tampilan, penentuan design pattern yang digunakan, pemodelan diagram UML, dan pembuatan dokumentasi.
- Construction, merupakan tahap untuk mengimplementasikan hasil desain dan melakukan pengujian hasil implementasi. Pada tahap awal construction, ada baiknya dilakukan pemeriksaan ulang hasil analisis dan desain, terutama disain pada diagram sequence,class, component, dan deployment. Apabila disain yang dibuat telah sesuai dengan analisis sistem, maka implementasi dengan bahasa pemrograman 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 objek), 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 ekspektasi pengguna.
- Scrum
- Scrum-ban
- Story-driven modeling
- Test-driven development (TDD)
- Velocity tracking
- Software Development Rhythms[6][7]
Tujuan agile
[sunting | sunting sumber]Secara garis besar tujuan dirumuskannya agile development methods,[8] yaitu:
- High-value & working app system, diharapkan dengan memakai agile development methods dapat dihasilkan perangkat lunak yang mempunyai nilai jual yang tinggi, biaya pembuatan bisa di tekan dan perangkat lunak bisa berjalan dengan baik.
- Iterative, incremental, evolutionary, agile adalah metode pengembangan perangkat lunak yang iteratif, selalu mengalami perubahan, dan evolusioner. Tim harus bekerja dalam waktu yang singkat(biasanya 1-3 minggu) dan juga selalu menambah fungsionalitas dari perangkat lunak sesuai dengan kebutuhan klien. Agile dapat dianalogikan ketika seseorang ingin pergi ke suatu kota dan dia tidak tahu jalannya. Lalu bagaimana dia bisa sampai tujuan? Dengan sering bertanya kepada orang yang dia temui di jalan hingga dia sampai di tempat tujuan.
- 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 selesai dibuat berarti agile juga mengakomodasi 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 mengubah 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 lunak pun bisa diminimalkan.
- 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 mengolaborasikan developer perangkat lunak dengan klien. Sehingga terciptalah tim yang solid.
Bagaimana agile bekerja
[sunting | sunting sumber]Topik selanjutnya yaitu tentang cara kerja agile development methods. Di bagian ini akan dijelaskan bagaimana agile development methods diterapkan menggunakan model proses scrum dalam manajemen proyek.
Komposisi tim
[sunting | sunting sumber]Secara umum komposisi dari sebuah tim pengembang perangkat lunak[9] 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 mengolaborasikan developer dengan klien, membuat dan mengevaluasi target pengerjaan perangkat lunak.
- Sistem Analis, membuat arsitektur sistem dari perangkat lunak yang akan dibuat.
- Developer, merupakan titik vital dalam tim, tanpa developer perangkat lunak tidak akan bisa dibuat.
Story
[sunting | sunting sumber]Story atau User 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 disimpulkan Story adalah bagian terpenting dari Scrum.
Story terdiri dari kolom-kolom berikut ini:[10]
- 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.
- Kepentingan – Derajat kepentingan yang diberikan oleh klien terhadap story. Pemberian derajat kepentingan biasanya menggunakan deret fibonacci (1,1,2,3,5,dst). Semakin tinggi nilainya maka semakin tinggi pula prioritas pengerjaannya.
- Perkiraan awal – Perkiraan awal tim tentang berapa banyak kerja yang diperlukan untuk mengimplementasikan sebuah story.
- Demo – deskripsi umum bagaimana cara story ini didemokan pada waktu sprint demo (lakukan ini, klik itu, lalu ini akan muncul, dll.).
Sprint
[sunting | sunting sumber]Sprint (Rapat perencanaan pembuatan perangkat lunak dilakukan 2-8 minggu sekali), yang perlu diperhatikan saat melaksanakan sprint antara lain:[10]
- Tujuan sprint.
- Daftar anggota tim harus lengkap.
- Sprint backlog (daftar story yang akan diikutkan dalam sprint).
- Tanggal demo yang pasti.
- Tempat dan waktu yang jelas untuk pelaksanaan sprint berikutnya.
Tim akan melakukan sprint secara simultan sampai perangkat lunak selesai dikerjakan, sebagai contoh:
Sprint 1, tim membuat fungsi login, logout dan demo perangkat lunak akan dilakukan 3 minggu kemudian. Setelah dilakukan demo untuk mengevaluasi kerja yang dilakukan tim pada Sprint 1, maka Sprint 1 dianggap selesai. Bahan evaluasi dari Sprint 1 akan dibawa ke Sprint 2 begitu seterusnya sampai aplikasi selesai dikerjakan.
Kelebihan dan Kekurangan
[sunting | sunting sumber]Kelebihan
[sunting | sunting sumber]Beberapa kelebihan dari agile, di antaranya:[9]
- 82% Menambah produktivitas tim.
- 77% Menambah kualitas perangkat lunak.
- 78% Menambah kepuasan klien.
- 37% Menghemat biaya.
Kekurangan
[sunting | sunting sumber]Sedangkan kekurangan dari agile antara lain:
- Agile tidak akan berjalan dengan baik jika komitmen tim kurang.
- Tidak cocok dalam skala tim yang besar (>20 orang). Walaupun demikian dalam perkembangan zaman, beberapa metode baru telah dicetuskan untuk meningkatkan skalabilitas dari metode ini.
- Perkiraan waktu release dan harga perangkat lunak sulit ditentukan.
Sumber (Resources)
[sunting | sunting sumber]Untuk memperdalam pengetahuan tentang agile development methods, anda bisa mengunjungi website di bawah ini:[11]
- Secara garis besar buku ini menjelaskan tentang:
- Cara membuat perencanaan dan jadwal pembuatan aplikasi.
- Karakteristik untuk membuat tim yang tangkas dan bisa memanajemen dirinya sendiri.
- Bagaimana cara mengumpulkan persyaratan yang dibutuhkan dengan lebih cepat.
- Apa yang harus dilakukan ketika menemukan perencanaan yang tidak sesuai, dan bagaimana dapat mengoreksinya dengan benar.
- Bagaimana mengeksekusi rencana yang ada dengan sumber daya yang tersedia dengan tepat.
- Merupakan salah situs yang wajib dibaca bila anda ingin belajar tentang agile development methods, didalamnya anda dapat menemukan informasi diantaranya:
- Cara untuk mengembangkan perangkat dengan menggunakan prinsip-prinsip dari agile.
- Bagaimana tim berinteraksi selama proses pembuatan perangkat lunak.
- 12 prinsip agile manifesto.
- Pivotal tracker merupakan perangkat lunak agile project management dari Pivotal Lab.Di dalam perangkat lunak ini terdapat berbagi file dan fungsionalitas manajemen tugas, pelacakan kecepatan dan perencanaan iterasi, penanda rilis, dan grafik kemajuan.
- Trello merupakan layanan berbasis web yang bisa membantu kita dalam memanajemen proyek yang sedang dikembangkan baik sendiri atau dalam suatu tim. Di Trello kita dapat membuat pekerjaan lebih fokus dan terarah.
- Asana merupakan aplikasi alternatif yang sederhana dan intuitif untuk manajemen kerja, baik dalam tim maupun sendiri.
- Salah satu model pengembangan perangkat lunak dimana pada model ini berawal dari suatu proses perencanaan dan berakhir pada proses deployment
Referensi
[sunting | sunting sumber]- ^ Proboyekti, U. Bahan Ajar Rekayasa Perangkat Lunak Agile Software Development. Indonesia
- ^ a b Agile Software Development. Diakses dari situs wikipedia pada 7 November 2013
- ^ Software Development Process. Diakses dari situs wikipedia pada 7 November 2013
- ^ Kent Beck; James Grenning; Robert C. Martin; Mike Beedle; Jim Highsmith; Steve Mellor; Arie van Bennekum; Andrew Hunt; Ken Schwaber; Alistair Cockburn; Ron Jeffries; Jeff Sutherland; Ward Cunningham; Jon Kern; Dave Thomas; Martin Fowler; Brian Marick (2001). "Manifesto for Agile Software Development". Agile Alliance. Diakses tanggal 14 June 2010.
- ^ a b Kesalahan pengutipan: Tag
<ref>
tidak sah; tidak ditemukan teks untuk ref bernamamanifesto
- ^ Ambler, S.W., (2012). Disciplined Agile Delivery (DAD): The Foundation for Scaling Agile Presentation Slide 15
- ^ Lui, K.M., (2013). Software development rhythms: Searching for Simplicity Presentation Slide 15
- ^ Collier, K.(2011).Agile Analytics: A Value-Driven Approach to Business Intelligence and Data Warehousing.USA:Addison-Wesley.
- ^ a b Silverburg,A.(2012).Agile Analytics in Higher Education.USA:Phytorion.
- ^ a b Kniberg, H.(2007).Scrum and XP Practice.USA:C4Media.
- ^ Taymor, E.Agile Handbook.USA:Philosophie.