Senin, 23 Maret 2009

Extreme Programming

Extreme Programming
Extreme programming (XP) merupakan salah satu model proses dari agile proses model. Pertama kali diusulkan oleh Kent Beck dan Ward Cunningham pada bulan Maret 1996, asal mula XP digunakan karena pada saat itu permintaan dari customer yang sering berubah dengan cepat sehingga mengakibatkan putaran kehidupan metode pengembangan perangkat lunak tradisional menjadi lebih pendek dan tidak selaras dengan metode tradisional karena pada umumnya memerlukan desain yang luas dan itu mengakibatkan perubahan desain yang terjadi dan tentu saja memerlukan biaya yang lebih tinggi. Tujuan XP adalah meminimalisir biaya yang diperlukan jika ada perubahan dalam pengembangan perangkat lunak.

Cara Kerja Extreme Progrmamming
  • Perencanaan XP: 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
  • Desain XP 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.
  • Pengkodean XP: siapkan unit test sebelum pengkodean dipakai sebagai fokus pemrogram untuk membuat program. Pair programming dilakukan untuk real time program solving dan real time quality assurance
  • Pengujian XP: menggunakan unit test yang dipersiapkan sebelum pengkodean.

Lima kunci utama Extreme Progrmamming
Ada lima kunci dari XP menurut Kent Beck yaitu:
1. Komunikasi (communication)
2. Kesederhanaan (simplicity)
3. Masukkan (feedback)
4. Keberanian (courage)
5. Menghormati (Respect)


Keuntungan dan Kelebihan Extreme Progrmamming
Keuntungan XP:
  • Menjalin komunikasi yang baik dengan client.
  • Meningkatkan komunikasi dan sifat saling menghargai antar developer.

Kerugian XP:
  • 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).

Dikutip dari: http://adit279.com/?p=71 dan http://lecturer.ukdw.ac.id/othie/agile_model.pdf

Tidak ada komentar:

Posting Komentar