Computer Programming

It is FUN Programming ^_^

XP

Extreme Programming (XP) adalah metodologi rekayasa perangkat lunak yang dimaksudkan untuk meningkatkan kualitas perangkat lunak dan responsif terhadap perubahan kebutuhan pelanggan. Sebagai jenis gesit pengembangan perangkat lunak, [1] [2] [3] itu para pendukung sering “rilis” dalam siklus pembangunan pendek (timeboxing), yang dimaksudkan untuk meningkatkan produktivitas dan memperkenalkan pos pemeriksaan di mana persyaratan pelanggan baru dapat diadopsi.

Unsur-unsur lain Extreme Programming meliputi: pemrograman berpasangan atau kode ekstensif melakukan peninjauan, pengujian unit semua kode, menghindari fitur-fitur pemrograman sampai mereka benar-benar diperlukan, struktur manajemen yang datar, kesederhanaan dan kejelasan dalam kode, mengharapkan perubahan dalam kebutuhan pelanggan sebagai waktu berlalu dan masalah lebih baik dimengerti, dan sering komunikasi dengan pelanggan dan di antara programer. [2] [3] [4] Metodologi mengambil namanya dari gagasan bahwa unsur menguntungkan rekayasa perangkat lunak tradisional praktik dibawa ke “ekstrem “tingkatan, berdasarkan teori bahwa jika ada yang baik, lebih banyak lebih baik. Hal ini tidak berhubungan dengan “coding koboi”, yang lebih bebas bentuk dan tidak direncanakan. Tidak menganjurkan “kematian march” jadwal kerja, tapi malah bekerja di sebuah langkah berkelanjutan. [5]

Kritikus melihat adanya beberapa potensi kelemahan, [6] termasuk masalah dengan persyaratan yang tidak stabil, tidak ada kompromi pengguna didokumentasikan konflik, dan kurangnya desain keseluruhan spec atau dokumen.

Sejarah

Extreme Programming diciptakan oleh Kent Beck selama bekerja di Chrysler Menyeluruh Sistem Kompensasi (C3) proyek penggajian. [6] Beck C3 menjadi pemimpin proyek Maret 1996 dan mulai untuk memperbaiki metode pengembangan yang digunakan dalam proyek dan menulis sebuah buku tentang metode (pada Oktober 1999, Extreme Programming Explained diterbitkan). [6] Chrysler membatalkan proyek C3 pada Februari 2000, setelah perusahaan diakuisisi oleh Daimler-Benz. [7]

Meskipun Extreme Programming itu sendiri adalah relatif baru, banyak dari praktik sudah ada selama beberapa waktu, metodologi, setelah semua, diperlukan “praktek terbaik” untuk tingkat ekstrem. Sebagai contoh, “tes-praktek pembangunan pertama, perencanaan dan tes tertulis sebelum setiap mikro-increment” digunakan sebagai awal NASA Project Mercury, pada awal 1960-an (Larman 2003). Refactoring, modularitas, bottom-up dan desain inkremental digambarkan oleh Leo Brodie dalam bukunya yang diterbitkan pada tahun 1984 [8].

Asal

Sebagian besar pengembangan perangkat lunak pada 1990-an dibentuk oleh dua pengaruh utama: internal, pemrograman berorientasi objek pemrograman prosedural digantikan sebagai paradigma pemrograman yang disukai oleh beberapa orang dalam industri; eksternal, munculnya internet dan booming dot-com-untuk menekankan kecepatan pasar dan perusahaan-pertumbuhan sebagai faktor bisnis kompetitif. Persyaratan berubah dengan cepat menuntut lebih pendek siklus hidup produk, dan sering tidak sesuai dengan metode tradisional pengembangan perangkat lunak.

Chrysler Menyeluruh Sistem Kompensasi dimulai dalam rangka untuk menentukan cara terbaik untuk menggunakan teknologi obyek, dengan menggunakan sistem penggajian di Chrysler sebagai objek penelitian, dengan sebagai bahasa Smalltalk dan batu permata sebagai lapisan akses data. Mereka dibawa di Kent Beck, [6] Smalltalk praktisi terkemuka, untuk melakukan kinerja tuning pada sistem, tetapi perannya diperluas ketika ia melihat adanya beberapa persoalan yang mereka hadapi dengan proses pembangunan mereka. Dia mengambil kesempatan ini untuk mengusulkan dan mengimplementasikan beberapa perubahan dalam praktik mereka didasarkan pada sering bekerja dengan kolaborator, Ward Cunningham.

Pertama kali saya diminta untuk memimpin sebuah tim, saya meminta mereka untuk melakukan sedikit hal yang saya pikir itu masuk akal, seperti pengujian dan ulasan. Kedua kali ada lebih banyak di telepon. Saya pikir, “Sialan torpedo, setidaknya ini akan membuat artikel yang baik,” [dan] meminta tim untuk mendongkrak semua tombol-tombol untuk 10 pada hal-hal yang saya pikir sangat penting dan meninggalkan segala sesuatu yang lain. -Kent Beck

Ron Jeffries Beck diundang ke proyek untuk membantu mengembangkan dan memperbaiki metode ini. Jeffries kemudian bertindak sebagai pelatih untuk menanamkan praktek-praktek sebagai kebiasaan dalam tim C3.

Informasi tentang prinsip-prinsip dan praktek-praktek di belakang XP ini disebarluaskan ke dunia yang lebih luas melalui diskusi di Wiki asli, WikiWikiWeb Cunningham. Berbagai kontributor dibahas dan dikembangkan atas ide-ide, dan beberapa spin-off metodologi yang mengakibatkan (lihat gesit pengembangan perangkat lunak). Selain itu, konsep XP telah dijelaskan, selama beberapa tahun, menggunakan sistem teks hiper-peta di website XP di “www.extremeprogramming.org” sekitar tahun 1999 (website XPorg).

Beck edited serangkaian buku on XP, mulai dengan dirinya sendiri “Extreme Programming Explained (1999, ISBN 0-201-61641-6)”, menyebarkan ide-idenya ke yang lebih besar, namun sangat reseptif, penonton. Penulis dalam seri melewati berbagai aspek menghadiri XP dan praktik, bahkan sebuah buku kritis terhadap praktek-praktek.

Current state

XP cukup menciptakan buzz di akhir 1990-an dan awal 2000-an, melihat adopsi dalam sejumlah lingkungan yang sangat berbeda dari asal-usulnya.

Disiplin tinggi yang diperlukan oleh praktek-praktek asli sering pergi di pinggir jalan, menyebabkan beberapa praktik yang dianggap terlalu kaku untuk menjadi usang atau kiri dibatalkan di setiap situs. Praktek-praktek pembangunan tangkas tidak berdiri diam, dan XP masih berkembang, asimilasi lebih banyak pelajaran dari pengalaman di lapangan. Dalam edisi kedua Extreme Programming Dijelaskan, Beck menambahkan lebih banyak nilai-nilai dan praktik-praktik dan dibedakan antara primer dan praktek wajar.

Konsep

Tujuan

“Extreme Programming Explained” Extreme Programming menggambarkan sebagai pengembangan perangkat lunak disiplin yang mengatur orang untuk menghasilkan perangkat lunak berkualitas tinggi lebih produktif.

Dalam metode pengembangan sistem tradisional (seperti SSADM atau model air terjun) persyaratan untuk sistem ditentukan pada awal proyek pengembangan dan sering kali tetap dari saat itu. Ini berarti bahwa biaya mengubah persyaratan pada tahap berikutnya (fitur yang umum proyek rekayasa perangkat lunak) akan menjadi tinggi. Seperti metode pengembangan perangkat lunak gesit, XP upaya untuk mengurangi biaya perubahan dengan memiliki banyak siklus pengembangan yang pendek, bukan dari satu panjang. Dalam perubahan doktrin ini adalah alami, tak terhindarkan dan aspek diinginkan proyek-proyek pengembangan perangkat lunak, dan harus direncanakan untuk alih-alih mencoba untuk mendefinisikan sebuah set persyaratan stabil.

Extreme Programming juga memperkenalkan sejumlah nilai-nilai dasar, prinsip dan praktek-praktek di atas kerangka pemrograman lincah.

Kegiatan

XP menggambarkan empat kegiatan dasar yang dilakukan dalam proses pengembangan perangkat lunak.

Coding
Pendukung XP berpendapat bahwa satu-satunya benar-benar produk yang penting dari proses pengembangan sistem kode – instruksi perangkat lunak komputer dapat menafsirkan. Tanpa kode, tidak ada produk kerja.

Coding juga dapat digunakan untuk mengetahui solusi yang paling cocok. Sebagai contoh, XP akan menganjurkan bahwa dihadapkan dengan beberapa alternatif untuk masalah pemrograman, satu kode hanya perlu semua solusi dan menentukan dengan tes yang otomatis solusi yang paling sesuai. [Rujukan?] Coding juga dapat membantu untuk mengkomunikasikan pikiran tentang masalah pemrograman. Seorang pemrogram berurusan dengan masalah pemrograman yang kompleks dan sulit untuk menjelaskan solusi untuk sesama programer mungkin kode ini dan gunakan kode untuk menunjukkan apa yang dia berarti. Kode, mengatakan para pendukung posisi ini, selalu jelas dan ringkas dan tidak dapat ditafsirkan dengan lebih dari satu cara. Pemrogram lain dapat memberikan umpan balik kode ini oleh juga pengkodean pikiran mereka.

Pengujian
Satu tidak bisa memastikan bahwa fungsi bekerja kecuali satu tes itu. Desain bug dan masalah kesalahan yang meresap dalam pengembangan software. Extreme Programming Pendekatan adalah bahwa jika sedikit pengujian dapat menghilangkan beberapa kekurangan, banyak pengujian dapat menghilangkan banyak kelemahan.

* Unit tes menentukan apakah fitur yang diberikan bekerja sebagaimana dimaksud. Seorang pemrogram menulis sebagai banyak tes otomatis mereka bisa memikirkan yang dapat “memecahkan” kode; jika semua tes berjalan dengan sukses, maka pengkodean selesai. Setiap potongan kode yang tertulis diuji sebelum pindah ke fitur berikutnya.
* Tes Penerimaan memverifikasi bahwa persyaratan sebagaimana yang dipahami oleh para programer memenuhi persyaratan pelanggan yang sebenarnya. Ini terjadi pada tahap eksplorasi perencanaan rilis.

Sebuah “testathon” adalah sebuah peristiwa ketika programmer bertemu untuk melakukan tes kolaboratif menulis, semacam brainstorming relatif terhadap pengujian perangkat lunak.

Mendengarkan
Programmer harus mendengarkan apa yang pelanggan membutuhkan sistem untuk melakukan, apa yang “logika bisnis” diperlukan. Mereka harus memahami kebutuhan-kebutuhan ini cukup baik untuk memberikan umpan balik pelanggan tentang aspek teknis bagaimana masalah bisa dipecahkan, atau tidak dapat dipecahkan. Pemahaman masalah nya. Komunikasi antara pelanggan dan pemrogram adalah dibahas lebih lanjut dalam The Perencanaan Game.

Merancang
Dari sudut pandang kesederhanaan, orang bisa mengatakan bahwa pengembangan sistem tidak membutuhkan lebih dari coding, pengujian dan mendengarkan. Jika kegiatan tersebut dilakukan dengan baik, hasilnya harus selalu menjadi sistem yang bekerja. Dalam prakteknya, ini tidak akan bekerja. Satu dapat datang jauh tanpa merancang tetapi pada waktu tertentu seorang pun akan terjebak. Sistem menjadi terlalu kompleks dan dependensinya di dalam sistem berhenti menjadi jelas. Satu dapat menghindari hal ini dengan menciptakan sebuah desain struktur yang mengatur logika dalam sistem. Desain yang baik akan menghindari banyak dependensi dalam sistem ini berarti bahwa mengubah salah satu bagian dari sistem tidak akan mempengaruhi bagian lain dari sistem. [Rujukan?]

Nilai

Extreme Programming awalnya empat nilai diakui pada tahun 1999. Sebuah nilai baru ditambahkan dalam edisi kedua Extreme Programming Explained. Kelima nilai:

Komunikasi
Membangun sistem perangkat lunak mengharuskan persyaratan sistem komunikasi untuk para pengembang sistem. Dalam metodologi pengembangan perangkat lunak formal, tugas ini dilakukan melalui dokumentasi. Extreme Programming teknik dapat dipandang sebagai metode untuk cepat membangun dan menyebarkan pengetahuan kelembagaan di antara anggota suatu tim pengembangan. Tujuannya adalah untuk memberikan semua pengembang pandangan bersama sistem yang cocok dengan pandangan yang dipegang oleh para pengguna sistem. Untuk tujuan ini, Extreme Programming menyukai desain sederhana, Common metafora, kolaborasi antara pengguna dan pemrogram, sering komunikasi verbal, dan umpan balik.

Kesederhanaan
Extreme Programming mendorong dimulai dengan solusi sederhana. Fungsionalitas tambahan kemudian dapat ditambahkan kemudian. Perbedaan antara pendekatan ini dan lebih banyak metode pengembangan sistem konvensional adalah fokus pada perancangan dan coding untuk kebutuhan hari ini daripada orang-orang yang besok, minggu depan, atau bulan depan. Ini kadang-kadang disimpulkan sebagai “Anda tidak akan memerlukannya” pendekatan. [5] Para pendukung XP mengakui kerugian yang terkadang hal ini bisa berarti besok lebih banyak usaha untuk mengubah sistem klaim mereka adalah bahwa ini adalah lebih dari kompensasi untuk oleh keuntungan dari tidak berinvestasi dalam masa depan mungkin persyaratan yang mungkin akan berubah sebelum mereka menjadi relevan. Coding dan merancang untuk kebutuhan masa depan tidak pasti menyiratkan risiko mengeluarkan sumber daya untuk sesuatu yang mungkin tidak diperlukan. Terkait dengan “komunikasi” nilai, kesederhanaan dalam desain dan pengkodean harus meningkatkan kualitas komunikasi. Sebuah desain sederhana dengan kode yang sangat sederhana dapat dengan mudah dipahami oleh sebagian besar programmer dalam tim.

Umpan balik
Dalam Extreme Programming, umpan balik berkaitan dengan dimensi yang berbeda dari pengembangan sistem:

* Saran atau masukan dari sistem: dengan menulis unit test, [6] atau menjalankan tes integrasi periodik, programer umpan balik langsung dari keadaan sistem setelah menerapkan perubahan.
* Umpan balik dari pelanggan: tes fungsional (alias penerimaan tes) yang ditulis oleh pelanggan dan penguji. Mereka akan mendapatkan umpan balik yang konkret tentang keadaan saat ini sistem mereka. Tinjauan ini direncanakan sekali dalam setiap dua atau tiga minggu sehingga pelanggan dapat dengan mudah mengarahkan pembangunan.
* Saran atau masukan dari tim: Ketika pelanggan datang dengan persyaratan baru dalam permainan perencanaan tim langsung memberikan perkiraan waktu yang akan dibutuhkan untuk melaksanakan.

Saran atau masukan sangat erat terkait dengan komunikasi dan kesederhanaan. Kelemahan dalam sistem dengan mudah dikomunikasikan dengan menulis sebuah unit tes yang membuktikan suatu potongan kode tertentu akan pecah. Umpan balik langsung dari sistem recode mengatakan pemrogram untuk bagian ini. Seorang pelanggan dapat menguji sistem secara berkala sesuai dengan persyaratan fungsional, yang dikenal sebagai pengguna cerita. [6] Untuk kutipan Kent Beck, “Optimisme adalah risiko pekerjaan pemrograman, umpan adalah pengobatan.” [Rujukan?]

Keberanian
Beberapa praktek mewujudkan keberanian. Salah satunya adalah perintah untuk selalu desain dan kode untuk hari ini dan tidak untuk besok. Ini adalah upaya untuk menghindari macet dalam desain dan memerlukan banyak upaya untuk menerapkan apa-apa lagi. Keberanian memungkinkan pengembang untuk merasa nyaman dengan refactoring kode mereka bila diperlukan. [6] Ini berarti meninjau sistem yang ada dan memodifikasi sehingga perubahan masa depan dapat dilaksanakan dengan lebih mudah. Contoh lain dari keberanian adalah mengetahui kapan harus membuang kode menjauh: keberanian untuk menghapus kode sumber yang is obsolete, tidak peduli seberapa banyak usaha yang digunakan untuk membuat kode sumber itu. Juga, keberanian berarti ketekunan: Seorang pemrogram mungkin akan terjebak pada masalah yang kompleks untuk satu hari, lalu memecahkan masalah dengan cepat pada hari berikutnya, jika hanya mereka gigih.

Respect
Nilai penghormatan mewujud dalam beberapa cara. Dalam Extreme Programming, anggota tim saling menghormati satu sama lain karena pemrogram tidak boleh melakukan perubahan yang melanggar kompilasi, yang membuat unit-tes yang ada gagal, atau yang lain menunda pekerjaan teman mereka. Anggota menghormati pekerjaan mereka dengan selalu berusaha untuk kualitas tinggi dan mencari desain yang terbaik untuk solusi di tangan melalui refactoring.

Mengadopsi empat sebelumnya mengarah untuk menghormati nilai-nilai yang diperoleh dari orang lain dalam tim. Tak seorang pun di tim harus merasa tidak dihargai atau diabaikan. Hal ini memastikan tingkat tinggi motivasi dan mendorong loyalitas terhadap tim, dan tujuan proyek. Nilai ini sangat tergantung pada nilai-nilai lain, dan sangat banyak berorientasi terhadap orang-orang dalam tim.

Aturan

Versi pertama dari peraturan XP diusulkan oleh Ken Hauer [9] di XP / Agile Universe 2003. Dia merasa XP ditentukan oleh aturan, bukan praktek (yang tunduk pada lebih variasi dan ambiguitas). Dia mendefinisikan dua kategori: “Rules of Engagement” yang mendikte lingkungan di mana pengembangan perangkat lunak dapat berlangsung secara efektif, dan “Rules of Play” yang mendefinisikan menit-demi-menit kegiatan dan aturan dalam rangka Rules of Engagement.

Dalam lokakarya di ICSE Apso 2008 Konferensi, Mehdi mengusulkan Mirakhorli yang baru dan lebih tepat dan komprehensif versi Extreme Programming Aturan, lebih independen dari praktek, dan dimaksudkan untuk menjadi lebih “lincah”.

Aturan keterlibatan

Menurut Mehdi Mirakhorli, ini adalah: [rujukan?]

* Bisnis orang dan pengembang melakukan kerja bersama: Bisnis orang dan pengembang harus bekerja sama setiap hari sepanjang proyek.
* Prioritas tertinggi kami adalah kepuasan pelanggan: Pelanggan harus menetapkan dan terus-menerus menyesuaikan tujuan dan prioritas yang didasarkan pada perkiraan dan informasi lain yang disediakan oleh pengembang atau anggota tim. Tujuan ditetapkan dalam hal apa yang tidak seberapa.
* Memberikan perangkat lunak bekerja sering: Memberikan perangkat lunak bekerja sering, dari beberapa minggu sampai beberapa bulan, dengan preferensi untuk skala waktu yang lebih pendek (timeboxing).
* Bekerja perangkat lunak: perangkat lunak Bekerja ukuran utama kemajuan.
* Global kesadaran: Pada setiap titik, setiap anggota tim harus mampu mengukur kemajuan tim pelanggan tujuan dan tim mencerminkan tentang bagaimana untuk menjadi lebih efektif, maka lagu-lagu dan mengatur perilakunya sesuai.
* Tim harus bertindak sebagai jaringan sosial yang efektif, yang berarti:
o Jujur komunikasi terkemuka untuk terus belajar dan penekanan pada orang-ke-orang interaksi, bukan dokumentasi.
o Minimal derajat pemisahan dari apa yang dibutuhkan oleh tim untuk membuat kemajuan dan orang-orang / sumber daya yang dapat memenuhi kebutuhan tersebut.
o Alignment wewenang dan tanggung jawab.

Prinsip

Prinsip-prinsip yang membentuk dasar XP didasarkan pada nilai-nilai yang baru saja dijelaskan dan ditujukan untuk mendorong keputusan dalam suatu proyek pengembangan sistem. Prinsip-prinsip ini dimaksudkan untuk menjadi lebih konkret daripada nilai-nilai dan lebih mudah diterjemahkan untuk panduan dalam situasi praktis.

Umpan balik
Extreme Programming melihat umpan balik yang paling berguna jika hal itu dilakukan dengan cepat dan mengungkapkan bahwa waktu antara aksi dan umpan balik yang sangat penting untuk belajar dan membuat perubahan. Tidak seperti metode pengembangan sistem tradisional, kontak dengan pelanggan lebih sering terjadi pada iterasi. Pelanggan memiliki pandangan yang jelas ke dalam sistem yang sedang dikembangkan. Ia dapat memberikan umpan balik dan mengarahkan pembangunan sesuai dengan kebutuhan.

Unit test juga berkontribusi terhadap prinsip umpan balik yang cepat. Ketika menulis kode, pengujian unit langsung menyediakan umpan balik tentang bagaimana sistem bereaksi terhadap perubahan yang telah dibuat. Jika, misalnya, perubahan mempengaruhi bagian dari sistem yang tidak dalam lingkup para programmer yang membuat mereka, bahwa programmer tidak akan melihat cacat. Ada kemungkinan besar bug ini akan muncul ketika sistem sedang dalam produksi.

Mengasumsikan kesederhanaan
Ini tentang memperlakukan setiap masalah sebagai jika solusi yang “sangat sederhana”. Metode pengembangan sistem tradisional mengatakan untuk merencanakan masa depan dan untuk kode untuk usabilitas. Extreme pemrograman menolak ide-ide ini.

Pendukung Extreme Programming bilang bahwa membuat perubahan besar sekaligus tidak bekerja. Extreme Programming berlaku perubahan tambahan: misalnya, sistem mungkin rilis kecil setiap tiga minggu. Ketika banyak langkah-langkah kecil yang dibuat, pelanggan memiliki lebih banyak kontrol atas proses pembangunan dan sistem yang sedang dikembangkan.

Merangkul perubahan
Prinsip perubahan merangkul tentang tidak bekerja melawan perubahan tetapi memeluk mereka. Sebagai contoh, jika pada salah satu pertemuan berulang-ulang tampak bahwa persyaratan pelanggan telah berubah secara dramatis, programer adalah untuk merangkul rencana ini dan persyaratan baru untuk iterasi berikutnya.

Praktek
Untuk detail lebih lanjut tentang topik ini, lihat Extreme Programming Praktek.

Extreme Programming telah digambarkan memiliki 12 praktek-praktek, yang dikelompokkan ke dalam empat bidang:

Fine skala umpan

* Pair programming [6]
* Perencanaan permainan
* Test pembangunan berbasis
* Seluruh tim

Proses Continuous

* Continuous integrasi
* Refactoring atau perbaikan desain [6]
* Kecil rilis

Shared pemahaman

* Coding standar
* Kode kepemilikan kolektif [6]
* Wikipedia desain [6]
* Sistem metafora

Programmer kesejahteraan

* Berkelanjutan kecepatan

Coding

* Pelanggan selalu tersedia
* Kode Unit pertama tes
* Hanya satu pasang kode terintegrasi pada satu waktu
* Tinggalkan Optimasi sampai terakhir
* Tidak Lembur

Pengujian

* Semua kode harus memiliki tes Unit
* Semua kode harus lulus semua tes Unit sebelum dapat dilepaskan.
* Ketika sebuah Bug ditemukan tes diciptakan sebelum bug tersebut ditujukan (bug bukan kesalahan dalam logika, itu adalah ujian Anda lupa untuk menulis)
* Tes Penerimaan dijalankan sering dan hasilnya dipublikasikan

kontroversial aspek

Praktik di XP telah sangat diperdebatkan [6] dengan pendapat yang kuat untuk atau melawan menggunakan XP.

Extreme Programming pendukung klaim bahwa dengan memiliki on-site pelanggan [6] perubahan permintaan informal, proses menjadi fleksibel, dan menghemat biaya overhead formal. Kritik terhadap klaim XP ini dapat mengakibatkan proyek mahal mengolah dan scope creep di luar apa yang sebelumnya setuju atau didanai.

Ubah papan pengendalian adalah suatu tanda bahwa ada potensi konflik dalam tujuan proyek dan kendala antara beberapa pengguna. Metodologi yang dipercepat XP agak tergantung pada programmer yang bisa menganggap sudut pandang klien yang bersatu sehingga pemrogram dapat berkonsentrasi pada dokumentasi coding daripada kompromi tujuan dan kendala. Hal ini juga berlaku bila beberapa organisasi pemrograman yang terlibat, terutama organisasi yang bersaing untuk saham proyek. [Rujukan?]

Lain yang mungkin aspek-aspek kontroversial Extreme Programming meliputi:

* Persyaratan otomatis dinyatakan sebagai bukan tes penerimaan dokumen spesifikasi.
* Persyaratan didefinisikan secara bertahap, daripada mencoba untuk mendapatkan mereka semua di muka.
* Software pengembang biasanya diperlukan untuk bekerja berpasangan.
* Ada Big Design Up Front. Sebagian besar kegiatan desain terjadi pada terbang dan secara bertahap, dimulai dengan “hal yang paling sederhana yang bisa bekerja” dan menambahkan kompleksitas hanya ketika itu diperlukan oleh tes gagal. Kritikus bandingkan untuk “debug sistem menjadi penampilan” dan ketakutan ini akan menghasilkan desain yang lebih ulang upaya daripada hanya merancang ulang ketika persyaratan perubahan.
* Seorang pelanggan perwakilan dilampirkan pada proyek. Peran ini dapat menjadi satu-point-of-kegagalan untuk proyek, dan beberapa orang telah menemukan itu untuk menjadi sumber stres. Juga, ada bahaya mikro-manajemen oleh perwakilan non-teknis mencoba mendikte penggunaan fitur-fitur software teknis dan arsitektur.
Dependensi * atas semua aspek lain dari XP: “XP adalah seperti lingkaran ular berbisa, daisy-dirantai bersama-sama. Yang dibutuhkan adalah untuk salah satu dari mereka meronta lepas, dan kau punya sangat marah, ular berbisa menuju jalan . [10]

Skalabilitas

Secara historis, XP hanya bekerja pada tim dari dua belas atau lebih sedikit orang. Salah satu cara untuk menghindari keterbatasan ini adalah untuk memecah proyek ke beberapa bagian dan tim tersebut menjadi kelompok-kelompok kecil. Telah menyatakan bahwa XP telah digunakan dengan sukses di tim yang terdiri dari lebih dari seratus pengembang [rujukan?]. ThoughtWorks telah menyatakan keberhasilan wajar pada proyek XP didistribusikan hingga enam puluh orang [rujukan?].

Pada tahun 2004 Industri Extreme Programming (IXP) [11] diperkenalkan sebagai suatu evolusi dari XP. Hal ini dimaksudkan untuk membawa kemampuan untuk bekerja dalam tim besar dan didistribusikan. Sekarang memiliki 23 praktek-praktek dan nilai-nilai yang fleksibel. Karena ini adalah anggota baru keluarga Agile, tidak ada cukup data untuk membuktikan kegunaan, namun mengklaim sebagai sebuah jawaban untuk XP ketidaksempurnaan.

Pemutusan dan tanggapan

Pada tahun 2003, Matt Stephens dan Doug Rosenberg menerbitkan sebuah buku di bawah disebut Apress Extreme Programming Refactored: Kasus Against XP yang mempertanyakan nilai proses XP dan menyarankan cara-cara yang dapat ditingkatkan. Hal ini memicu perdebatan panjang di artikel, internet newsgroup, dan situs web daerah bercakap-cakap. Argumen inti dari buku ini adalah bahwa praktek XP saling bergantung tetapi hanya sedikit organisasi praktis yang bersedia / mampu mengadopsi semua praktek-praktek sehingga seluruh proses gagal. Buku ini juga membuat kritik lain dan menarik patung XP “kepemilikan kolektif” model untuk sosialisme di cara negatif.

Aspek-aspek tertentu dari XP telah berubah sejak buku Extreme Programming Refactored (2003) diterbitkan; pada khususnya, XP sekarang menampung modifikasi pada praktik selama tujuan yang dibutuhkan masih terpenuhi. Semakin XP juga menggunakan istilah generik untuk proses. Beberapa berpendapat bahwa perubahan ini membatalkan kritik sebelumnya; lain mengklaim bahwa ini hanyalah proses menyiram ke bawah.

RDP Praktek adalah teknik untuk menjahit Extreme Programming. Praktek ini awalnya diusulkan sebagai penelitian panjang kertas ke dalam lokakarya yang diselenggarakan oleh Philippe Kruchten dan Steve Adolph (Lihat Apso lokakarya di ICSE 2008) dan namun adalah satu-satunya metode yang diusulkan dan berlaku untuk mengkustomisasi XP. Berharga RDP konsep di balik praktik, dalam waktu singkat memberikan alasan untuk penerapan dalam industri. RDP Praktek mencoba untuk menyesuaikan XP dengan mengandalkan teknik XP Rules.

Penulis lain telah berusaha untuk mendamaikan XP dengan metode yang lebih tua untuk membentuk metodologi yang bersatu. Beberapa XP ini berusaha untuk menggantikan, seperti metode air terjun; contoh: siklus hidup Proyek: Air Terjun, Rapid Application Development, dan All That. JPMorgan Chase & Co mencoba menggabungkan XP dengan pemrograman komputer metodologi CMMI (CMMI), dan Six Sigma. Mereka menemukan bahwa sistem tiga satu sama lain diperkuat dengan baik, mengarah pada pembangunan yang lebih baik, dan tidak saling bertentangan.

No comments yet»

Tinggalkan Balasan

Isikan data di bawah atau klik salah satu ikon untuk log in:

Logo WordPress.com

You are commenting using your WordPress.com account. Logout / Ubah )

Gambar Twitter

You are commenting using your Twitter account. Logout / Ubah )

Foto Facebook

You are commenting using your Facebook account. Logout / Ubah )

Foto Google+

You are commenting using your Google+ account. Logout / Ubah )

Connecting to %s

%d blogger menyukai ini: