Extreme Programming

Extreme Programming (XP) adalah sebuah pendekatan atau model pengembangan perangkat lunak yang mencoba menyederhanakan berbagai tahapan dalam proses pengembangan tersebut sehingga menjadi lebih adaptif dan fleksibel. XP bukan hanya berfokus pada coding tetapi meliputi seluruh area pengembangan perangkat lunak. XP mengambil pendekatan ‘ekstrim’ dalam iterative development.

XP 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 extreme programming dalam meningkatkan proyek perangkat lunak :

Komunikasi (Communication)

Kurangnya komunikasi merupakan penyebab utama kegagalan pengembangan software. Oleh karena itu Extreme Programming(XP) memfokuskan diri pada hubungan komunikasi yang baik antar tim-klien, anggota tim, dan manajer proyek.Komunikasi dalam XP dibangun dengan melakukan pemrograman berpasangan (pair programming).Klien harus dilibatkan dalam proses pengembangan perangkat lunaknya dengan tujuannya untuk memberikan pandangan pengembang sesuai dengan pandangan pengguna sistem yang dibangun.

Kesederhanaan (Simplicity)

Extreme Programming (XP) melakukan semua pekerjaan dengan sederhana dan praktis tanpa mengurangi fungsi utamanya. Dalam pengerjaan, metode yang dipilih adalah metode yang pendek dan simpel. Jangan terlalu rumit dalam membuat desain, hilangkan fitur yang tidak ada gunanya atau hapus fungsi yang tidak terpakai. Dengan kata lain lebih baik melakukan hal yang sederhana saat sekarang (sesuai kebutuhan) dan mengembangkannya nanti jika diperlukan.

Umpan balik (Feedback)

Selalu evaluasi perkembangan perangkat lunak yang sedang dikerjakan. Segala informasi harus dikumpulkan setiap interval waktu yang konsisten dan kesalahan-kesalahan yang muncul selama proses pengembangan harus dibahas dan dicari solusinya. Umpan balik tersebut berfungsi sebagai indikator kemajuan proyek dan menginformasikan pemimpin proyek apabila perubahan perlu dibuat.

Menghargai (Respect)

Menghargai merupakan sebuah nilai yang dalam, satu hal yang berada dibawah permukaan dari empat nilai lainnya dalam extreme programming. Alasannya yaitu :

Semua orang menghargai / menghormati orang lain sebagai member tim yang berharga
Semua orang memberikan nilai sebagai sebuah antusiasme
Developers menghargai keahlian dari customers dan begitu pun sebaliknya
Pihak manajemen menghormati hak dari pengembang untuk menerima tanggung jawab dan menerima otoritas atas pekerjaan mereka

Keberanian (Courage)

Programmer Extreme Programming (XP) didorong untuk berani bereksperimen dan menulis ulang kode jika mereka tidak puas dengan kode atau desain yang sudah ada. Hal ini membantu mempertahankan moral serta intgritas para pengembang proyek dan dapat mendukung lebih lanjut komunikasi dengan anggota proyek lainnya.

Peraturan dalam exteme programming :

Perencanaan

Pengalaman user ditulis
Perencanaan rilis membuat jadwal rilis
Membuat rilis kecil sesering mungkin
Proyek tersebut dibagi ke dalam iterasi
Rencana iterasi memulai setiap iterasi

Pengelolaan

Memberikan ruang kerja kepada tim secara terbuka
Mengatur kecepatan yang berkelanjutan
Rapat dimulai setiap harinya
Kecepatan proyek harus diukur
Pemindahan orang
Memperbaiki XP ketika rusak

Mendesain

Kesederhanaan
Pilih metafora sistem
Menggunakan kartu CRC pada sesi desain
Buat lonjakan solusi untuk mengurangi risiko
Tidak ada fungsi yang ditambahkan lebih awal
Refactor kapanpun dan dimanapun memungkinkan

Pengkodean

Pelanggan selalu tersedia
Kode dibuat dengan standar yang disepakati
Lakukan kode pada unit tes terlebih dahulu
Semua kode produksi diprogram berpasangan
Hanya satu pasang kode yg terintegrasi pada satu waktu
Sering seringlah berintegrasi
Menyiapkan komputer integrasi khusus
Menggunakan kepemilikan kolektif

Percobaan

Semua kode harus memiliki tes unit
Semua kode harus lulus semua tes unit sebelum digunakan
Ketika bug ditemukan, maka tes akan dibuat
Tes penerimaan lebih sering dijalankan dan skor dipublikasikan

Kelebihan Extreme Programming, yaitu :

Meningkatkan kepuasan kepada klien
Pembangunan system dibuat lebih cepat
Menjalin komunikasi yang baik dengan client.
Meningkatkan komunikasi dan sifat saling menghargai antar developer.

Kelemahan Extreme Programming, yaitu :

Cerita-cerita yang menunjukkan requirements dari pelanggan kemungkinan besar tidak lengkap sehingga 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).
XP tidak memiliki dokumentasi formal yang dibuat selama pengembangan. Satu-satunya dokumentasi adalah dokumentasi awal yang dilakukan oleh user.

Peran

Meskipun XP menetapkan praktik tertentu untuk diikuti tim Anda, itu tidak benar-benar menetapkan peran khusus untuk orang-orang di tim Anda.

Bergantung pada sumber mana yang Anda baca, tidak ada panduan, atau ada deskripsi tentang bagaimana peran yang biasanya ditemukan dalam proyek yang lebih tradisional berperilaku pada proyek XP. Berikut empat peran paling umum yang terkait dengan XP :

Pelanggan

Peran Pelanggan bertanggung jawab untuk membuat semua keputusan bisnis terkait proyek termasuk:

Apa yang harus dilakukan sistem (Fitur apa yang disertakan dan apa yang mereka capai)?
Bagaimana kita tahu kapan sistem selesai (apa kriteria penerimaan kita)?
Berapa yang harus kita keluarkan (berapa dana yang tersedia, bagaimana kasus bisnisnya)?
Apa yang harus kami lakukan selanjutnya (dalam urutan apa kami memberikan fitur-fitur ini)?

Pelanggan XP diharapkan terlibat secara aktif dalam proyek dan idealnya menjadi bagian dari tim.

Pelanggan XP dianggap sebagai satu orang, namun pengalaman menunjukkan bahwa satu orang tidak dapat memberikan semua informasi terkait bisnis secara memadai tentang suatu proyek. Tim Anda perlu memastikan bahwa Anda mendapatkan gambaran lengkap tentang perspektif bisnis, tetapi memiliki beberapa cara untuk menangani konflik dalam informasi tersebut sehingga Anda bisa mendapatkan arahan yang jelas.

Pengembang

Karena XP tidak terlalu membutuhkan definisi peran, setiap orang di tim (dengan pengecualian pelanggan dan beberapa peran sekunder yang tercantum di bawah) diberi label pengembang. Pengembang bertanggung jawab untuk mewujudkan cerita yang diidentifikasi oleh Pelanggan. Karena proyek yang berbeda memerlukan campuran keterampilan yang berbeda, dan karena metode XP bergantung pada tim lintas fungsi yang menyediakan campuran keterampilan yang sesuai, pencipta XP merasa tidak perlu untuk definisi peran lebih lanjut.

Pelacak

Beberapa tim mungkin memiliki pelacak sebagai bagian dari tim mereka. Ini sering kali merupakan salah satu pengembang yang menghabiskan sebagian waktu mereka setiap minggu untuk mengisi peran tambahan ini. Tujuan utama dari peran ini adalah untuk melacak metrik yang relevan yang dirasa perlu oleh tim untuk melacak kemajuan mereka dan untuk mengidentifikasi area untuk perbaikan. Metrik utama yang dapat dilacak tim Anda termasuk kecepatan, alasan perubahan kecepatan, jumlah kerja lembur, dan tes yang lulus dan gagal.

Ini bukan peran wajib untuk tim Anda, dan umumnya hanya ditetapkan jika tim Anda benar-benar menentukan kebutuhan untuk melacak beberapa metrik.

Pelatih

Jika tim Anda baru saja mulai menerapkan XP, mungkin akan membantu jika Anda menyertakan Pelatih dalam tim Anda. Ini biasanya adalah konsultan luar atau seseorang dari tempat lain di organisasi Anda yang telah menggunakan XP sebelumnya dan termasuk dalam tim Anda untuk membantu membimbing anggota tim lain di Praktik XP dan untuk membantu tim Anda mempertahankan disiplin diri Anda.

Nilai utama dari pelatih adalah bahwa mereka telah mengalaminya sebelumnya dan dapat membantu tim Anda menghindari kesalahan yang dibuat oleh kebanyakan tim baru.

Acceptance Test Driven Development (ATDD)

ATDD merupakan bagian dari metode agile software development, secara garis besar ATDD melibatkan proses acceptance testing sebelum implementasi kode program yang dapat meningkatkan produktivitas waktu pengembangan perangkat lunak serta kesesuaian requirement dari perangkat lunak yang dibangun (Pugh, 2010).

ATDD merupakan perkembangan dari metode Test Driven Development (TDD). TDD bisa dikatakan melakukan pengujian sebelum pengkodean, bertujuan untuk mengevaluasi hasil tes tersebut untuk menentukan kecacatan atau kesalahan yang mungkin terjadi pada perangkat lunak kepada tim pengembang perangkat lunak tersebut (Hendrickson, 2008).

Serupa dengan TDD, ATDD juga melakukan pengujian sebelum implementasi kode, dimana hasil tes tersebut mempresentasikan Espektasi dari perangkat lunak yang harus dimiliki (Hendrickson, 2008), namun ATDD memperluas aplikasi dari teknik TDD untuk tingkatan acceptance testing, menggunakan user-level black box Tests sebagai pengganti unit tests (Sauvé, Abath Neto, & Cirne, 2006).

ATDD juga bisa disebut sebagai Story Test Driven Development (SDD), Specification by Example atau Behavior Driven Development (BDD). Istilah yang berbeda ini ada untuk menekankan beberapa perbedaan dalam pendekatan yang mengarah pada hasil yang serupa.

Sama seperti hasil TDD dalam aplikasi yang dirancang agar lebih mudah untuk pengujian unit, ATDD mendukung pembuatan antarmuka yang khusus untuk pengujian fungsional. (Menguji melalui UI aplikasi yang sebenarnya dianggap kurang efektif.)

Bahkan lebih dari penggunaan tes penerimaan otomatis, praktik ini sangat terkait dengan penggunaan alat khusus seperti Fit / FitNess, Cucumber atau lainnya.

Oleh karena itu, satu risiko utama adalah bahwa alat yang dipilih akan menghalangi daripada memajukan tujuan utama praktik ini: memfasilitasi percakapan antara pengembang dan pemilik produk tentang persyaratan produk. Alat harus diadaptasi untuk memenuhi kebutuhan pemilik produk daripada sebaliknya.

Berikut adalah beberapa praktik utama dalam ATDD :

Menganalisis dan mendiskusikan skenario dunia nyata
Menentukan kriteria penerimaan untuk skenario tersebut
Mengotomatiskan kasus uji penerimaan
Berfokus pada pengembangan kasus persyaratan tersebut

Manfaat ATDD

Persyaratan dianalisis dengan sangat jelas tanpa ambiguitas
Mendorong kolaborasi di antara anggota lintas tim
Tes penerimaan berfungsi sebagai panduan untuk seluruh proses pengembangan

Key Differences: TDD vs BDD vs ATDD

Crystal

Ketika pada tahun 1991, IBM meminta Alistair Cockburn untuk mengembangkan metodologi untuk proyek berorientasi objek, dia tahu itu akan menjadi tantangan nyata karena dia tidak tahu banyak tentang metodologi proyek pada saat itu. Jadi, dia memutuskan untuk mewawancarai tim proyek dan mencari tahu pandangan mereka tentang proyek tersebut.

Setelah melakukan penelitian ekstensif, dia sampai pada kesimpulan bahwa tim tinggi yang sukses berbagi pola dan teknik yang sama bahkan tanpa menggunakan metodologi proyek tertentu. Dengan kata lain, mereka menambahkan nilai pada aspek-aspek seperti komunikasi yang erat, moralitas, akses ke pengguna, dan lainnya, yang tidak dapat Anda temukan dalam metodologi tertentu.

Akhirnya, dia menggunakan temuannya untuk membangun sebuah keluarga metodologi dan menamakannya Crystal.

Metode kristal adalah pendekatan pengembangan perangkat lunak tangkas yang berfokus terutama pada orang dan interaksi mereka saat mengerjakan proyek daripada pada proses dan alat. Alistair percaya bahwa keterampilan dan bakat orang serta cara mereka berkomunikasi memiliki pengaruh terbesar pada hasil proyek.

Metode Kristal didasarkan pada dua asumsi mendasar :

Tim dapat menyederhanakan proses mereka sebagai pekerjaan mereka dan menjadi tim yang lebih optimal
Proyek itu unik dan dinamis dan membutuhkan metode khusus

Menurut Cockburn, pengembangan produk harus dilihat sebagai permainan yang merangsang setiap orang untuk berinteraksi, berkreasi, dan menghasilkan ide-ide cemerlang. Dia mengatakan bahwa alih-alih berfokus pada pertanyaan seperti "apakah model kami akurat?" kita harus mencari jawaban untuk pertanyaan seperti "Apakah produk kita memenuhi kebutuhan pelanggan? Atau "Apakah tujuan kita selaras sebagai sebuah tim?"

Salah satu hal yang ditemukan Cockburn adalah bahwa properti proyek berubah tergantung pada jumlah orang yang terlibat dalam proyek dan tingkat kekritisan proyek yang sedang ditangani.

Sementara tim yang lebih kecil dapat menangani dan membangun produk tanpa banyak pelaporan status dan dokumen, jumlah "artefak komunikasi" meningkat dengan tim yang lebih besar yang mengerjakan proyek skala besar.

Dengan kata lain, semakin banyak orang yang Anda miliki di tim, semakin penting proyek tersebut dan semakin kompleks pendekatan yang dibutuhkan. Oleh karena itu, tidak ada satu metode Crystal; ada metodologi Crystal yang berbeda untuk berbagai jenis proyek.

Untuk membuat kategorisasi ini mudah dipahami, Cockburn menamai metodologi Crystal dan mengkategorikannya dalam dua dimensi - ukuran dan kekritisan - yang cocok dengan mineral - warna dan kekerasan.

Pada dasarnya, Cockburn mengembangkan keluarga-keluarga ini untuk menunjukkan bahwa setiap proyek mungkin memerlukan serangkaian kebijakan, praktik, dan proses tertentu untuk memenuhi karakteristik unik proyek. Cockburn mencoba menjelaskan hal ini dengan menyebut Crystal "sekumpulan sampel yang Anda sesuaikan dengan keadaan Anda".

Pendekatan mana yang paling cocok untuk proyek Anda bergantung pada tiga dimensi:

Ukuran tim
Kekritisan
Apa prioritas proyek tersebut

Umumnya, mereka dicirikan oleh warna, sesuai dengan jumlah orang yang terlibat dalam proyek:

Clear - untuk tim yang terdiri dari 8 orang atau kurang

Yellow - untuk tim yang terdiri dari 10-20 orang

Orange - untuk tim yang terdiri dari 20-50 orang

Red - untuk tim yang terdiri dari 50-100 orang

Karakteristik metode kristal

Bertenaga manusia

Ini berarti bahwa orang-orang yang terlibat dalam proyek sangat penting dan prosesnya harus disesuaikan untuk memenuhi kebutuhan masyarakat. Ini juga menekankan bahwa orang mampu mengatur diri mereka sendiri dan bahwa mereka dapat menjadi lebih terorganisir dan kompeten seiring berkembangnya proses.

Adaptif

Crystal adalah metodologi peregangan agar sesuai yang berarti bahwa proses dan alat tidak tetap, tetapi harus disesuaikan untuk memenuhi persyaratan tim dan proyek yang dihadapi.

Sangat ringan

Crystal tidak melibatkan terlalu banyak dokumentasi, manajemen dan pelaporan. Itu membuat segala sesuatunya ringan dengan berfokus pada alur kerja yang transparan antara tim dan klien dan dengan mempraktikkan komunikasi terbuka antara anggota tim.

7 sifat metode Crystal

Pengiriman yang sering

Ini memungkinkan Anda untuk sering mengirim kode yang berfungsi dan diuji ke pengguna nyata. Dengan cara ini, Anda tidak harus menghadapi kenyataan bahwa Anda telah menginvestasikan energi dan waktu Anda untuk produk yang tidak ingin dibeli oleh siapa pun.

Perbaikan reflektif

Tidak peduli seberapa buruk atau baik produk tersebut, selalu ada area di mana produk dapat ditingkatkan. Selain itu, selalu ada teknik dan metode baru yang dapat diterapkan tim Anda untuk meningkatkan praktik masa depan mereka

Komunikasi osmotik

Dengan tim yang bekerja di lokasi yang sama, informasi mengalir di sekitar tim. Itu memungkinkan mereka untuk mengambil informasi berharga bahkan tanpa terlibat langsung dalam diskusi tentang masalah tertentu. Penyerapan ide secara bertahap ini disebut komunikasi osmotik. Cockburn yakin bahwa atmosfer kerja seperti ini dapat beroperasi dengan struktur yang sangat sedikit.

Keamanan Pribadi

Satu-satunya cara untuk membangun suasana kerja yang sehat dan budaya tim yang sejati adalah dengan mempraktikkan komunikasi yang terbuka dan jujur. Anggota tim harus dapat berbicara tanpa rasa takut, tidak peduli apakah mereka menyampaikan ide baru atau membicarakan masalah potensial.

Fokus

Setiap anggota tim tahu persis apa yang harus dikerjakan yang memungkinkan mereka memusatkan perhatian dan menghindari peralihan dari satu tugas ke tugas lain. Selain itu, ini meningkatkan komunikasi tim dan membantu tim memprioritaskan dan bekerja menuju tujuan yang sama.

Akses mudah ke pengguna ahli

Crystal memungkinkan tim Anda untuk menjaga komunikasi dan mendapatkan umpan balik rutin dari pengguna yang sebenarnya.

Lingkungan teknis dengan pengujian otomatis, manajemen konfigurasi, dan integrasi yang sering

Alat yang sangat spesifik untuk tim perangkat lunak dengan penekanan pada integrasi berkelanjutan sehingga kesalahan dapat diketahui dalam beberapa menit.

Mengapa metode Crystal berguna

Fakta bahwa Crystal menggunakan fokus pada orang dan komunikasi sebagai prinsip pengorganisasiannya I yang membedakannya dari metode pengembangan perangkat lunak lainnya.

Tidak seperti metodologi agile lainnya, Crystal berfokus pada penyesuaian teknik yang digunakan dalam sebuah proyek dengan tujuan untuk memperkuat proses komunikasi tim. Selain itu, Crystal memungkinkan:

Integrasi berkelanjutan
Proses yang fleksibel dan dapat dikonfigurasi
Keterlibatan pengguna aktif

Ingatlah bahwa Crystal terutama dibuat untuk mengingatkan Anda bagaimana tetap terpusat dan fokus pada pekerjaan Anda selama pengembangan proyek.

Ini berarti Anda harus memiliki pengetahuan yang luas dan pengalaman yang luas dalam pengembangan perangkat lunak jika Anda ingin berhasil mengimplementasikannya dan menang dalam proyek masa depan Anda.

Terimakasih telah membaca tulisan pada blog ini. Semoga dapat bermanfaat bagi para pembaca. Penulis meminta maaf jika ditemukan kesalahan kata maupun penulisan. Penulis sangat terbuka dengan kritik maupun saran dari teman-teman pembaca untuk meningkatkan kualitas penulisan yang lebih baik kedepannya.

My social media :

Instagram : @g.alfarizi

Twitter : @giovanni_fariz

Reference :

Extreme Programming

https://medium.com/@mikesebastian/extreme-programming-c715e6b8e0e9

https://www.it-jurnal.com/apa-itu-extreme-programming/

http://www.extremeprogramming.org/

https://www.agilealliance.org/glossary/xp/

Acceptance Test Driven Development

https://www.agilealliance.org/glossary/atdd/

https://medium.com/@dickyeka/tdd-adalah-b8da753aba4b