Extreme Programming with Metode Agile

What is Extreme Programming?

Extreme Programming (XP) adalah kerangka pengembangan perangkat lunak tangkas yang bertujuan untuk menghasilkan perangkat lunak berkualitas lebih tinggi dan kualitas hidup lebih tinggi bagi tim pengembangan. XP adalah kerangka kerja tangkas yang paling spesifik mengenai praktik rekayasa yang tepat untuk pengembangan perangkat lunak.

When Applicable

Karakteristik umum dimana XP sesuai dijelaskan oleh Don Wells di www.extremeprogramming.org :

Persyaratan perangkat lunak berubah secara dinamis

Risiko yang disebabkan oleh proyek waktu tetap yang menggunakan teknologi baru

Tim pengembangan tambahan yang kecil dan berlokasi bersama

Teknologi yang Anda gunakan memungkinkan pengujian unit dan fungsional otomatis

Karena kekhususan XP dalam hal praktik rekayasa perangkat lunak yang lengkap, ada beberapa situasi di mana Anda mungkin tidak ingin mempraktikkan XP sepenuhnya. Pos Kapan XP Tidak Sesuai di Wiki C2 mungkin merupakan tempat yang baik untuk mulai menemukan contoh di mana Anda mungkin tidak ingin menggunakan XP.

Meskipun Anda tidak dapat menggunakan seluruh kerangka kerja XP dalam banyak situasi, hal ini tidak akan menghentikan Anda untuk menggunakan sebanyak mungkin praktik sesuai konteks Anda.

Values

Lima nilai XP adalah komunikasi, kesederhanaan, umpan balik, keberanian, dan rasa hormat yang dijelaskan lebih rinci di bawah ini.

Communication

Pengembangan perangkat lunak pada dasarnya adalah olahraga tim yang mengandalkan komunikasi untuk mentransfer pengetahuan dari satu anggota tim ke semua orang di tim. XP menekankan pentingnya jenis komunikasi yang tepat -- diskusi tatap muka dengan bantuan papan tulis atau mekanisme gambar lainnya.

Simplicity

Kesederhanaan berarti "hal paling sederhana apa yang bisa berhasil?" Tujuannya adalah untuk menghindari pemborosan dan hanya melakukan hal-hal yang benar-benar diperlukan seperti menjaga desain sistem sesederhana mungkin sehingga lebih mudah untuk dipelihara, didukung, dan direvisi. Kesederhanaan juga berarti hanya memenuhi persyaratan yang Anda ketahui; jangan mencoba memprediksi masa depan.

Feedback

Melalui umpan balik yang terus-menerus mengenai upaya mereka sebelumnya, tim dapat mengidentifikasi area yang perlu ditingkatkan dan merevisi praktik mereka. Umpan balik juga mendukung desain sederhana. Tim Anda membangun sesuatu, mengumpulkan umpan balik mengenai desain dan implementasi Anda, lalu menyesuaikan produk Anda ke depannya.

Courage

Kent Beck mendefinisikan keberanian sebagai "tindakan efektif dalam menghadapi rasa takut" (Extreme Programming Dijelaskan P. 20). Definisi ini menunjukkan preferensi tindakan berdasarkan prinsip lain agar hasilnya tidak merugikan tim. Anda memerlukan keberanian untuk mengangkat masalah organisasi yang mengurangi efektivitas tim Anda. Anda memerlukan keberanian untuk berhenti melakukan sesuatu yang tidak berhasil dan mencoba hal lain. Anda memerlukan keberanian untuk menerima dan bertindak berdasarkan masukan, meskipun sulit untuk menerimanya.

Respect

Anggota tim Anda perlu menghormati satu sama lain untuk berkomunikasi satu sama lain, memberikan dan menerima umpan balik yang menghormati hubungan Anda, dan bekerja sama untuk mengidentifikasi desain dan solusi sederhana.

Practices

Inti dari XP adalah serangkaian praktik pengembangan perangkat lunak yang saling berhubungan seperti tercantum di bawah ini. Meskipun praktik-praktik ini dapat dilakukan secara terpisah, banyak tim menemukan bahwa beberapa praktik memperkuat praktik lainnya dan harus dilakukan bersamaan untuk sepenuhnya menghilangkan risiko yang sering Anda hadapi dalam pengembangan perangkat lunak.

Praktik XP telah sedikit berubah sejak pertama kali diperkenalkan. Dua belas praktik asli tercantum di bawah ini. Jika Anda ingin informasi lebih lanjut tentang bagaimana praktik ini awalnya dijelaskan.

• The Planning Game
• Small Releases
• Metaphor
• Simple Design
• Testing
• Refactoring
• Pair Programming
• Collective Ownership
• Continuous Integration
• 40-hour week
• On-site Customer
• Coding Standard

Di bawah ini adalah deskripsi praktik seperti yang dijelaskan dalam Penjelasan Pemrograman Ekstrim edisi kedua Merangkul Perubahan. Deskripsi ini mencakup penyempurnaan berdasarkan pengalaman banyak orang yang mempraktikkan pemrograman ekstrem dan mencerminkan serangkaian praktik yang lebih praktis.

Sit Together

Karena komunikasi adalah salah satu dari lima nilai XP, dan kebanyakan orang setuju bahwa percakapan tatap muka adalah bentuk komunikasi terbaik, mintalah tim Anda duduk bersama di ruang yang sama tanpa hambatan komunikasi, seperti dinding bilik.

Whole Team

Sekelompok orang lintas fungsi dengan peran yang diperlukan untuk suatu produk membentuk satu tim. Ini berarti orang-orang yang memiliki suatu kebutuhan serta semua orang yang berperan dalam memenuhi kebutuhan tersebut, semuanya bekerja sama setiap hari untuk mencapai hasil tertentu.

Informative Workspace

Siapkan ruang tim Anda untuk memfasilitasi komunikasi tatap muka, memungkinkan orang memiliki privasi saat mereka membutuhkannya, dan membuat pekerjaan tim transparan satu sama lain dan pihak berkepentingan di luar tim. Memanfaatkan Radiator Informasi untuk secara aktif mengkomunikasikan informasi terkini.

Energized Work

Anda paling efektif dalam pengembangan perangkat lunak dan semua pengetahuan berfungsi ketika Anda fokus dan bebas dari gangguan.

Pekerjaan yang memberi energi berarti mengambil langkah-langkah untuk memastikan Anda mampu secara fisik dan mental mencapai keadaan fokus. Ini berarti jangan membebani diri sendiri secara berlebihan (atau membiarkan orang lain membebani Anda). Ini juga berarti tetap sehat, dan menunjukkan rasa hormat kepada rekan tim Anda agar mereka tetap sehat.

Pair Programming

Pemrograman Berpasangan berarti semua perangkat lunak produksi dikembangkan oleh dua orang yang duduk di mesin yang sama. Gagasan di balik praktik ini adalah bahwa dua otak dan empat mata lebih baik daripada satu otak dan dua mata. Anda secara efektif mendapatkan peninjauan kode berkelanjutan dan respons yang lebih cepat terhadap masalah mengganggu yang mungkin menghentikan seseorang.

Tim yang telah menggunakan pemrograman berpasangan mendapati bahwa hal ini meningkatkan kualitas dan sebenarnya tidak memakan waktu dua kali lebih lama karena mereka mampu mengatasi masalah dengan cepat dan mereka tetap lebih fokus pada tugas yang ada, sehingga menghasilkan lebih sedikit kode untuk menyelesaikan hal yang sama.

Stories

Jelaskan apa yang harus dilakukan produk dalam hal yang bermakna bagi pelanggan dan pengguna. Kisah-kisah ini dimaksudkan sebagai deskripsi singkat tentang hal-hal yang ingin dilakukan pengguna dengan produk yang dapat digunakan untuk perencanaan dan berfungsi sebagai pengingat untuk percakapan yang lebih mendetail saat tim mulai mewujudkan kisah tersebut.

Weekly Cycle

Siklus Mingguan identik dengan iterasi. Dalam kasus XP, tim bertemu pada hari pertama minggu itu untuk merefleksikan kemajuan hingga saat ini, pelanggan memilih cerita yang ingin mereka sampaikan pada minggu itu, dan tim menentukan bagaimana mereka akan mendekati cerita tersebut. Sasarannya pada akhir minggu ini adalah menjalankan fitur-fitur teruji yang merealisasikan cerita yang dipilih.

Maksud di balik periode pengiriman yang dibatasi waktu adalah untuk menghasilkan sesuatu untuk ditunjukkan kepada pelanggan untuk mendapatkan umpan balik.

Quarterly Cycle

Siklus Triwulanan identik dengan rilis. Tujuannya adalah untuk menjaga rincian pekerjaan setiap siklus mingguan dalam konteks proyek secara keseluruhan. Pelanggan menjabarkan rencana keseluruhan untuk tim dalam bentuk fitur yang diinginkan dalam kuartal tertentu, yang memberikan pemandangan hutan kepada tim saat mereka berada di pepohonan, dan juga membantu pelanggan untuk bekerja dengan pemangku kepentingan lain yang mungkin memerlukan gambaran kapan fitur akan tersedia.

Ingatlah ketika merencanakan siklus triwulanan, informasi mengenai berita tertentu berada pada tingkat yang relatif tinggi, urutan penyampaian cerita dalam Siklus Triwulanan dapat berubah dan cerita-cerita yang termasuk dalam Siklus Triwulanan dapat berubah. Jika Anda dapat meninjau kembali rencana tersebut setiap minggu setelah setiap siklus mingguan, Anda dapat terus memberi tahu semua orang segera setelah perubahan tersebut terlihat untuk meminimalkan kejutan.

Slack

Gagasan di balik kelonggaran dalam istilah XP adalah menambahkan beberapa tugas atau cerita berprioritas rendah dalam siklus mingguan dan triwulanan Anda yang dapat dihilangkan jika tim tertinggal dalam tugas atau cerita yang lebih penting. Dengan kata lain, perhitungkan variabilitas inheren dalam perkiraan untuk memastikan Anda keluar dari diri sendiri peluang bagus untuk memenuhi prediksi Anda.

Ten-Minute Build

Tujuan dari Pembuatan Sepuluh Menit adalah membangun keseluruhan sistem secara otomatis dan menjalankan semua pengujian dalam sepuluh menit. Para pendiri XP menyarankan kerangka waktu 10 menit karena jika sebuah tim memiliki pembangunan yang memakan waktu lebih lama dari itu, kecil kemungkinannya untuk dijalankan secara sering, sehingga menimbulkan waktu antar kesalahan yang lebih lama.

Praktik ini mendorong tim Anda untuk mengotomatiskan proses pembangunan sehingga Anda cenderung melakukannya secara rutin dan menggunakan proses pembangunan otomatis tersebut untuk menjalankan semua pengujian Anda.

Praktek ini mendukung praktek Continuous Integration dan didukung oleh praktek Test First Development.

Continuous Integration

Integrasi Berkelanjutan adalah praktik di mana perubahan kode segera diuji ketika ditambahkan ke basis kode yang lebih besar. Manfaat dari praktik ini adalah Anda dapat mengetahui dan memperbaiki masalah integrasi lebih cepat.

Sebagian besar tim takut dengan langkah integrasi kode karena ditemukannya konflik dan masalah yang diakibatkannya. Kebanyakan tim mengambil pendekatan "Jika sakit, hindari selama mungkin".

Praktisi XP menyarankan "jika sakit, lakukan lebih sering".

Alasan di balik pendekatan tersebut adalah jika Anda mengalami masalah setiap kali Anda mengintegrasikan kode, dan memerlukan waktu cukup lama untuk menemukan letak masalahnya, mungkin Anda harus lebih sering mengintegrasikannya sehingga jika ada masalah, masalah tersebut lebih mudah ditemukan karena tidak ada masalah. lebih sedikit perubahan yang dimasukkan ke dalam build.

Praktik ini memerlukan disiplin ekstra dan sangat bergantung pada Pembuatan Sepuluh Menit dan Uji Pengembangan Pertama.

Test-First Programming

Daripada mengikuti jalur normal:

kembangkan kode -> tulis tes -> jalankan tes

Praktik Pemrograman Tes-Pertama mengikuti jalur:

Tulis pengujian otomatis yang gagal -> Jalankan pengujian yang gagal -> kembangkan kode agar pengujian lulus -> jalankan pengujian -> ulangi

Seperti halnya Integrasi Berkelanjutan, Pemrograman Uji-Pertama mengurangi siklus umpan balik bagi pengembang untuk mengidentifikasi dan menyelesaikan masalah, sehingga mengurangi jumlah bug yang masuk ke dalam produksi.

Incremental Design

Praktik Desain Inkremental menyarankan agar Anda melakukan sedikit pekerjaan terlebih dahulu untuk memahami perspektif luas yang tepat dari desain sistem, dan kemudian mendalami detail aspek tertentu dari desain tersebut saat Anda menghadirkan fitur tertentu. Pendekatan ini mengurangi biaya perubahan dan memungkinkan Anda membuat keputusan desain bila diperlukan berdasarkan informasi terkini yang tersedia.

Praktik Refactoring awalnya terdaftar di antara 12 inti tetapi dimasukkan ke dalam praktik Desain Inkremental. Refactoring adalah praktik yang sangat baik untuk menjaga desain tetap sederhana, dan salah satu penggunaan refactoring yang paling direkomendasikan adalah untuk menghilangkan duplikasi proses.

Roles

Meskipun Pemrograman Ekstrim menetapkan praktik tertentu yang harus diikuti oleh tim Anda, Pemrograman Ekstrim tidak benar-benar menetapkan peran khusus bagi 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 Pemrograman Ekstrim. Berikut adalah empat peran paling umum yang terkait dengan Pemrograman Ekstrim:

The Customer

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

Apa yang harus dilakukan sistem (Fitur apa saja yang disertakan dan apa yang dicapainya)?

Bagaimana kita mengetahui kapan sistem telah selesai (apa kriteria penerimaan kita)?

Berapa banyak yang harus kita keluarkan (berapa dana yang tersedia, apa kasus bisnisnya)?

Apa yang harus kami lakukan selanjutnya (dalam urutan apa kami menghadirkan fitur-fitur ini)?

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

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

The Developer

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

The Tracker

Beberapa tim mungkin memiliki pelacak sebagai bagian dari tim mereka. Ini sering kali merupakan salah satu pengembang yang menghabiskan sebagian waktunya setiap minggu untuk mengisi peran tambahan ini. Tujuan utama dari peran ini adalah untuk melacak metrik relevan yang dirasa perlu oleh tim untuk melacak kemajuan mereka dan untuk mengidentifikasi area yang perlu ditingkatkan. Metrik utama yang mungkin dilacak oleh tim Anda mencakup kecepatan, alasan perubahan kecepatan, jumlah kerja lembur, serta kelulusan dan kegagalan dalam tes.

Peran ini bukan merupakan keharusan bagi tim Anda dan umumnya hanya ditetapkan jika tim Anda menentukan kebutuhan sebenarnya untuk melacak beberapa metrik.

The Coach

Jika tim Anda baru saja mulai menerapkan XP, Anda mungkin perlu menyertakan Pelatih di tim Anda. Biasanya ini adalah konsultan luar atau seseorang dari tempat lain di organisasi Anda yang pernah menggunakan XP sebelumnya dan disertakan dalam tim Anda untuk membantu membimbing anggota tim lainnya dalam Praktik XP dan untuk membantu tim Anda mempertahankan disiplin diri.

Nilai utama dari seorang pelatih adalah mereka telah melaluinya sebelumnya dan dapat membantu tim Anda menghindari kesalahan yang dilakukan sebagian besar tim baru.

Lifecycle

Untuk mendeskripsikan XP dalam bentuk siklus hidup, mungkin yang paling tepat adalah meninjau kembali konsep Siklus Mingguan dan Siklus Kuartalan.

Pertama, mulailah dengan mendeskripsikan hasil proyek yang diinginkan dengan meminta pelanggan menjelaskan serangkaian cerita. Saat cerita-cerita ini dibuat, tim memperkirakan ukuran setiap cerita. Perkiraan ukuran ini, bersama dengan manfaat relatif yang diperkirakan oleh pelanggan, dapat memberikan indikasi nilai relatif yang dapat digunakan pelanggan untuk menentukan prioritas cerita.

Jika tim mengidentifikasi beberapa cerita yang tidak dapat mereka perkirakan karena mereka tidak memahami semua pertimbangan teknis yang terlibat, mereka dapat melakukan penelitian terfokus pada cerita tertentu atau aspek umum dari beberapa cerita. Lonjakan adalah kerangka waktu yang pendek dan terbatas yang disisihkan untuk tujuan melakukan penelitian pada aspek tertentu dari proyek. Lonjakan dapat terjadi sebelum iterasi reguler dimulai atau bersamaan dengan iterasi yang sedang berlangsung.

Selanjutnya, seluruh tim berkumpul untuk membuat rencana rilis yang dirasa masuk akal oleh semua orang. Rencana rilis ini merupakan gambaran awal tentang cerita apa yang akan disampaikan pada kuartal atau rilis tertentu. Cerita-cerita yang disampaikan hendaknya didasarkan pada nilai apa yang diberikannya dan pertimbangan bagaimana berbagai cerita saling mendukung.

Kemudian tim meluncurkan serangkaian siklus mingguan. Pada awal setiap siklus mingguan, tim (termasuk pelanggan) berkumpul untuk memutuskan cerita mana yang akan direalisasikan selama minggu tersebut. Tim kemudian membagi cerita-cerita tersebut menjadi tugas-tugas yang harus diselesaikan dalam minggu itu.

Pada akhir minggu, tim dan pelanggan meninjau kemajuan hingga saat ini, dan pelanggan dapat memutuskan apakah proyek harus dilanjutkan, atau apakah nilai yang diberikan sudah mencukupi.

Further Reading

• Extreme Programming: A gentle introduction. By Don Wells
• Extreme Programming Explained -- Embrace Change 2nd Edition by Kent Beck
• Extreme Programming Pocket Guide by Chromatic