Pada tahun 1990-an banyak pengembang perangkat lunak mulai mencari pilihan alternatif untuk sebuah metodologi pengembangan perangkat lunak tradisional, yang sebagai aturan yang didasarkan pada model air terjun. Pada awal tahun 2001 sekelompok ahli telah merumuskan prinsip-prinsip dasar teknologi ringan, yang sekarang dikenal sebagai pengembangan perangkat lunak tangkas. Elemen-elemen kunci dari filosofi pembangunan cerdas adalah sebagai berikut:
• Fokus pada sumber daya manusia yang terlibat dalam proyek, termasuk pembeli dan penyedia. Keberhasilan tim spesialis benar dipilih dianggap sebagai jaminan keberhasilan proyek masa depan.
• Shift dari spesifikasi formal untuk komunikasi yang efektif. Diskusi dan umpan balik membuat garis dasar dalam komunikasi antara tim dan pembeli, serta di dalam tim
• Iterative pembangunan dengan durasi maksimal singkat setiap iterasi tunggal, masing-masing menghasilkan rilis versi produk berfungsi secara penuh.
• Fleksibilitas terhadap perubahan - pada tahap pertama bekerja pada tim proyek tidak mengatur seperangkat persyaratan yang berat untuk mengikuti rencana yang ketat. Dalam perkembangan gesit perubahan lingkungan dapat dilakukan pada setiap tahap proyek.
Pemrograman Extreme adalah salah satu yang paling luas metodologi pengembangan perangkat lunak tangkas. prinsip utamanya dirumuskan pada tahun 1996 oleh Kent Beck sebagai upaya untuk memulihkan sebuah proyek gagal dari sistem akuntansi untuk salah satu raksasa industri otomotif. Hal itu tidak membantu proyek, namun metodologi XP telah mendapatkan popularitas dan banyak dari tim pengembangan perangkat lunak yang telah memilih sebagai metodologi terkemuka.
metodologi pemrograman Extreme mewarisi semua prinsip-prinsip dasar pengembangan perangkat lunak tangkas. Tetapi ada beberapa praktik tertentu yang termasuk dalam metodologi pengembangan perangkat lunak Agile:
1. Seorang wakil dari pembeli bekerja sebagai bagian dari tim proyek. Dia memiliki semua informasi yang diperlukan tentang fungsi kunci produk, ia menetapkan prioritas di antara persyaratan dan mengevaluasi kualitas produk.
2. cerita Pengguna adalah deskripsi informal singkat kasus menggunakan sistem. Untuk cerita pemrograman Extreme pengguna yang bersama, dengan tes penerimaan, satu-satunya cara untuk menentukan persyaratan. Semua informasi lainnya diperoleh langsung dari pembeli.
3. Uji didorong pengembangan - unit tes dari kunci penting bagi proyek yang dikembangkan atas dasar pengembangan perangkat lunak tangkas. Sebagian baru dari kode dapat dikembangkan hanya untuk meningkatkan jumlah unit test sukses. Bahkan, itu berarti bahwa sebelum mengembangkan fungsi baru tes yang sesuai harus disiapkan, dan pengembangan dari bagian tertentu dari kode harus diselesaikan hanya setelah awal lulus baru dan semua tes sudah ada.
4. Sistem arsitektur harus sesederhana mungkin. Ide pemrograman Extreme tidak merekomendasikan perencanaan dalam hal kemungkinan upgrade di masa mendatang. Idealnya, hanya harus mendukung fungsi yang ada.
5. Kode refactoring diperlukan dalam hal perubahan konstan dalam arsitektur sistem. bekerja Kolektif pada kode didorong oleh Extreme pemrograman. bug Kemungkinan disebabkan oleh refactoring terdeteksi oleh unit test.
6. Semua perubahan dalam kode harus masuk ke dalam repositori utama segera setelah lulus ujian, yang memungkinkan menghindari tahap integrasi.
7. Pasangan pemrograman adalah salah satu praktek yang paling kontradiktif pemrograman Extreme. Hal ini seharusnya untuk meningkatkan efektivitas umum proses dan untuk mengurangi jumlah bug.
8. Sebuah waktu kerja mingguan tidak boleh melebihi 40 jam. Praktek ini dimaksudkan untuk meningkatkan kinerja tim proyek karena stres menurun dan kelelahan.
Setelah tim pengembangan perangkat lunak yang dipilih tangkas beralih ke skala yang lebih besar dari fleksibilitas dan komunikasi. Untuk yang besar memperpanjang, Extreme pemrograman diciptakan sebagai upaya untuk menggambarkan proses dan praktek-praktek yang muncul sendiri dalam pengembang efektif dan konsolidasi.
