Pemrograman ekstrim adalah disiplin pengembangan software berdasarkan nilai-nilai kesederhanaan, komunikasi, umpan balik, dan keberanian. Kerjanya dengan membawa seluruh tim bersama-sama di hadapan praktek sederhana, cukup dengan masukan agar tim untuk melihat di mana mereka berada dan praktik yang selaras dengan situasi yang unik.
Dalam Extreme Programming, setiap kontributor proyek merupakan bagian integral dari "Seluruh Tim". Tim bentuk usaha perwakilan sekitar disebut "Pelanggan", yang duduk dengan tim dan bekerja dengan mereka sehari-hari.
Praktik inti: Seluruh Tim Ekstrim Pemrograman tim menggunakan sederhana bentuk perencanaan dan pelacakan untuk menentukan apa yang harus dilakukan selanjutnya dan untuk meramalkan kapan proyek ini akan dilakukan.
Difokuskan pada nilai bisnis, tim memproduksi perangkat lunak dalam serangkaian kecil sepenuhnya terpadu-rilis yang lulus tes semua pelanggan yang telah ditetapkan.
Praktik inti: Perencanaan Game, Kecil Releases, Pelanggan Pengujian Ekstrim pemrogram bekerja sama dalam pasangan dan sebagai salah satu grup, dengan desain sederhana dan kode obsessively diuji, memperbaiki desain terus untuk selalu menjaga ini tepat untuk kebutuhan saat ini.
Inti Praktek: Simple Desain, pasangan Pemrograman, Uji-Terutama Pembangunan, Peningkatan Desain Extreme Pemrograman tim yang membuat sistem terpadu dan berjalan setiap saat. Pemrogram yang menulis kode produksi di semua pasangan, dan semua bekerja bersama-sama setiap saat. Kode mereka dalam gaya yang konsisten agar semua orang dapat memahami dan meningkatkan semua kode yang diperlukan.
Praktik inti: Continuous Integration, Collective Kode Kepemilikan, Coding Standar The Extreme Pemrograman saham tim yang umum dan sederhana gambaran tentang apa yang tampak seperti sistem. Setiap orang yang bekerja pada kecepatan yang dapat terus-menerus tanpa batas.
Praktik inti: Metaphor, Pembangunan Pace
Inti Praktik
Seluruh Tim
Semua kontributor untuk sebuah proyek XP duduk bersama, salah satu anggota tim.
Tim ini harus termasuk usaha perwakilan - yang "Pelanggan" - yang menyediakan kebutuhan, menentukan prioritas, dan steers proyek. Ini terbaik jika salah satu atau Pelanggan aides dia adalah pengguna akhir yang tahu domain dan apa yang dibutuhkan. Tim tentunya akan memiliki pemrogram. Tim mungkin termasuk contoh, yang membantu pelanggan menentukan tes penerimaan pelanggan. Analis Mei menjadi penolong kepada Pelanggan, membantu untuk menentukan persyaratan. Biasanya ada pelatih yang membantu tim terus melacak dan memfasilitasi proses. Mungkin ada manajer, menyediakan sumber daya, penanganan eksternal komunikasi, koordinasi kegiatan. Tidak ada peran yang harus yang eksklusif milik masing-masing hanya satu: Semua orang di tim XP kontribusi dalam bentuk apapun yang mereka dapat. Yang tidak memiliki tim ahli, hanya umum kontributor dengan keterampilan khusus.
Perencanaan Game
XP perencanaan alamat dua pertanyaan kunci dalam pengembangan software: predicting apa yang akan dicapai dengan tanggal jatuh tempo, dan menentukan apa yang harus dilakukan berikutnya. Penekanan adalah mengarahkan pada proyek - yang sangat mudah - tepat di daripada prediksi tentang apa yang diperlukan dan berapa lama ia akan mengambil - yang cukup sulit. Ada dua langkah penting dalam perencanaan XP, menangani dua pertanyaan:
Release Perencanaan adalah praktek dimana Nasabah menyajikan fitur yang diinginkan ke pemrogram, dan pemrogram memperkirakan kesulitan. Dengan perkiraan biaya di tangan, dan dengan pengetahuan tentang pentingnya fitur, Pelanggan meletakkan satu rencana untuk proyek tersebut. Rencana awal rilis yang selalu tepat: baik prioritas maupun perkiraan yang benar-benar solid, dan sampai tim mulai bekerja, kita tidak akan tahu bagaimana cepat mereka hanya akan pergi. Bahkan rencana rilis pertama adalah cukup akurat untuk pengambilan keputusan, namun, dan XP tim merevisi rencana rilis secara berkala.
Perulangan Perencanaan adalah praktik di mana arah tim diberikan setiap beberapa bulan. XP tim membangun perangkat lunak dalam dua minggu "Iterasi", perangkat lunak berguna memberikan berjalan di akhir setiap perulangan. Selama perulangan Perencanaan, Pelanggan menyajikan fitur diinginkan selama dua minggu. Pemrogram istirahat yang turun ke dalam tugas-tugas mereka, dan memperkirakan biaya (pada tingkat detail halus dibandingkan Release Perencanaan). Berdasarkan jumlah pekerjaan dicapai dalam perulangan sebelumnya, tim mendaftar untuk apa yang akan dilakukan pada perulangan.
Perencanaan langkah-langkah ini sangat sederhana, namun mereka memberikan informasi yang sangat bagus dan sangat steering kontrol di tangan Nasabah. Setiap beberapa minggu, jumlah seluruhnya adalah kemajuan terlihat. Mereka yang tidak "sembilan puluh persen dilakukan" di XP: fitur cerita itu selesai, atau bukan. Ini berfokus pada visibilitas hasil bagus sekali sedikit paradoks: di satu sisi, dengan begitu banyak visibilitas, Pelanggan yang berada dalam posisi untuk membatalkan proyek berlangsung jika tidak cukup. Di sisi lain, kemajuan sangat terlihat, dan kemampuan untuk memutuskan apa yang akan dilakukan berikutnya sangat lengkap, XP proyek-proyek yang cenderung memberikan lebih dari apa yang dibutuhkan, dengan sedikit tekanan dan stres.
Pelanggan Pengujian
Sebagai bagian dari fitur presentasi setiap dikehendaki, XP Pelanggan yang mendefinisikan satu atau lebih otomatis penerimaan tes untuk menunjukkan bahwa fitur ini bekerja. Tim ini membangun tes dan menggunakan mereka untuk membuktikan diri, dan kepada konsumen, fitur yang dilaksanakan dengan benar. Otomasi sangatlah penting karena di tekan waktu, manual tes yang dilewati. Itu seperti mematikan lampu ketika Anda mendapatkan malam gelap.
Tim yang terbaik XP memperlakukan pelanggan mereka tes dengan cara yang sama mereka lakukan tes programmer: sekali ujian berjalan, tim ini tetap berjalan dengan benar setelahnya. Ini berarti bahwa sistem hanya meningkatkan, selalu tidak ada kemajuan, tidak pernah kembali ke tampilan.
Kecil Releases
XP latihan tim kecil rilis penting dalam dua cara:
Pertama, tim rilis berjalan, perangkat lunak yang diuji, memberikan nilai bisnis yang dipilih oleh Nasabah, setiap perulangan. Pelanggan dapat menggunakan software ini untuk tujuan apapun, evaluasi apakah rilis atau bahkan ke pengguna akhir (sangat dianjurkan). Aspek yang paling penting adalah bahwa perangkat lunak yang terlihat, dan diberikan kepada pelanggan, di akhir setiap perulangan. Ini membuat semuanya jelas dan terbuka.
Kedua, XP rilis tim ke pengguna akhir mereka sering juga. XP Web proyek rilis sesering yang sehari-hari, di rumah proyek bulanan atau lebih sering. Bahkan shrink-wrapped produk dikirimkan sesering triwulan.
Mungkin ini tampaknya tidak mungkin untuk membuat versi ini sering baik, tapi seluruh tim XP yang tepat setiap saat. Lihat integrasi lanjutan untuk mengetahui ini, dan perhatikan bahwa sering rilis dijaga oleh diandalkan XP dari obsesi dengan pengujian, seperti dijelaskan di Pelanggan Pengujian dan Test-Terutama Pembangunan.
Desain sederhana
XP tim membangun perangkat lunak untuk desain yang sederhana. Mereka mulai sederhana, dan melalui pengujian pemrogram dan desain perbaikan, mereka itu tetap jalan. XP membuat sebuah tim yang benar-benar cocok untuk desain yang sekarang fungsionalitas dari sistem. Tidak ada gerakan-siakan, dan perangkat lunak akan selalu siap untuk apa berikutnya.
Desain XP tidak satu kali itu, atau atas hal-depan, semua itu adalah pada waktu hal. Terdapat langkah-langkah dalam desain dan perencanaan rilis perulangan perencanaan, plus cepat tim terlibat dalam desain dan desain sesi melalui revisi refactoring, melalui kursus dari keseluruhan proyek. Dalam sebuah incremental, proses yg berulang seperti Extreme Programming, desain yang baik adalah sangat penting. Itulah mengapa ada begitu banyak berfokus pada desain sepanjang saja dari keseluruhan pembangunan.
Pasangan Pemrograman
Semua perangkat lunak produksi dalam XP dibangun oleh dua pemrogram, duduk berdampingan, di mesin yang sama. Praktik ini akan memastikan bahwa semua produksi kode dikaji oleh minimal satu programmer lainnya, dan hasil yang lebih baik dalam desain, pengujian yang lebih baik, lebih baik dan kode.
Mungkin ini tampaknya tidak efisien untuk memiliki dua pemrogram melakukan "programmer satu tugas", tetapi mundur adalah benar. Penelitian menjadi pasangan pemrograman menunjukkan bahwa pasangan memproduksi lebih baik tentang kode dalam waktu yang sama seperti pemrogram bekerja sendiri. Iya betul : dua kepala benar-benar lebih dari satu!
Beberapa pemrogram objek pemrograman untuk memasangkan tanpa pernah mencoba itu. It does mengambil beberapa praktek untuk melakukan dengan baik, dan Anda harus melakukannya dengan baik selama beberapa minggu untuk melihat hasilnya. Sembilan puluh persen dari pemrogram yang belajar pemrograman lebih memilih pasangan ini, jadi kami sangat merekomendasikan hal ini kepada semua tim.
Pasangan, selain memberikan lebih baik dan kode ujian, juga berfungsi untuk berkomunikasi pengetahuan seluruh tim. Beralih sebagai pasangan, semua orang mendapat manfaat dari semua ilmu khusus. Pemrogram belajar, meningkatkan kemampuan mereka, mereka menjadi lebih bermanfaat bagi tim dan perusahaan. Pasangan, bahkan di luar sendiri XP, yang menang besar bagi semua orang.
Test-Terutama Pembangunan
Pemrograman ekstrim adalah terobsesi dengan umpan balik, dan dalam pengembangan perangkat lunak, baik umpan balik baik memerlukan uji. Atas tim XP praktek "test-driven development", yang bekerja di sangat singkat siklus menambahkan tes, maka sehingga pekerjaan. Hampir effortlessly, tim menghasilkan kode dengan hampir 100 persen tes cakupan, yang merupakan langkah maju dalam banyak toko-toko. (Jika Anda sudah pemrogram melakukan pengujian yang lebih canggih, lebih kuasa kepada Anda. Keep it up, ia hanya dapat membantu!)
Ianya tidak cukup untuk tes tulis: Anda harus menjalankannya. Di sini juga, Extreme Programming is ekstrim. Ini "programmer ujian", atau "tes unit" semua dikumpulkan bersama-sama, dan setiap kali ada rilis programmer setiap kode ke repositori (dan pasangan biasanya rilis dua kali sehari atau lebih), setiap satu dari tes programmer harus dijalankan dengan benar. Seratus persen, setiap saat! Ini berarti pemrogram segera mendapat umpan balik tentang cara mereka lakukan. Selain itu, tes ini memberikan dukungan yang tak ternilai desain adalah perangkat lunak ditingkatkan.
Desain Peningkatan
Ekstrim Pemrograman berfokus pada memberikan nilai bisnis dalam setiap perulangan. Untuk melakukannya selama seluruh proyek perangkat lunak harus dirancang dengan baik. Alternatif yang akan memperlambat dan akhirnya buntu. Jadi XP menggunakan proses perbaikan terus desain disebut Refactoring, dari judul buku Martin Fowler, "Refactoring: Meningkatkan Desain yang ada dari Kode".
Refactoring yang berfokus pada proses penghapusan duplikasi (yakin suatu tanda miskin desain), dan pada peningkatan "kohesi" dari kode, sementara turunkan "kopel". Kohesi tinggi dan rendah kopel telah diakui sebagai hallmarks yang dirancang dengan baik-kode untuk setidaknya tiga puluh tahun. Hasilnya adalah bahwa XP dimulai dengan tim yang bagus, desain sederhana, dan selalu ada yang baik dan sederhana untuk merancang perangkat lunak. Hal ini memungkinkan mereka mempertahankan mereka mempercepat pembangunan, dan bahkan umumnya meningkatkan kecepatan sebagai proyek berjalan maju.
Refactoring adalah, tentu saja sangat didukung oleh pengujian komprehensif untuk memastikan bahwa sebagai perkembangan desain, tidak ada yang rusak. Dengan demikian, pelanggan tes dan tes programmer adalah faktor penting yang memungkinkan. XP praktek yang mendukung satu sama lain, mereka lebih kuat daripada bersama-sama secara terpisah.
Continuous Integration
Ekstrim Pemrograman tim menjaga sistem terintegrasi di semua kali. Kami mengatakan bahwa setiap hari adalah untuk membangun wimps: XP tim membangun beberapa kali per hari. (XP Satu tim yang terdiri dari empat puluh orang membangun sedikitnya delapan atau sepuluh kali per hari!)
Manfaat dari praktek ini dapat dilihat oleh berpikir kembali proyek Anda mungkin telah mendengar tentang (atau bahkan sudah menjadi bagian dari) dimana proses pembangunan itu mingguan atau lebih jarang, dan biasanya menyebabkan "integrasi neraka", dimana semuanya bokek dan tidak ada satu tahu mengapa.
Jarang integrasi mengarah ke masalah serius pada proyek perangkat lunak. Pertama, walaupun sangat penting bagi integrasi pengiriman kode bekerja baik, tim ini tidak dilakukan saat itu, dan sering itu didelegasikan kepada orang-orang yang tidak akrab dengan seluruh sistem. Kedua, kode terpadu jarang sering - Say akan berbicara biasanya - kode buggy. Masalah merayap di integrasi dalam waktu yang tidak terdeteksi oleh salah satu dari tes yang dilakukan pada sebuah sistem unintegrated. Ketiga, lemah integrasi proses panjang mengarah ke kode freezes. Kode freezes berarti Anda memiliki jangka waktu panjang apabila pemrogram dapat bekerja pada shippable fitur penting, tetapi orang-orang yang memiliki harus diadakan kembali. Ini melemahkan posisi Anda di pasar, atau dengan pengguna akhir.
Kepemilikan kolektif Kode
Extreme Pemrograman pada proyek, ada sepasang pemrogram dapat meningkatkan kode apapun kapan saja. Ini berarti bahwa semua kode mendapat manfaat dari perhatian banyak orang, yang akan meningkatkan kualitas dan mengurangi kode cacat. Ada lagi manfaat penting juga apabila kode dimiliki oleh perorangan, diperlukan fitur yang sering dimasukkan ke dalam tempat yang salah, sebagai salah satu programmer menemukan bahwa ia memerlukan suatu fitur dalam kode bahwa ia tidak sendiri. Pemilik terlalu sibuk untuk melakukannya, sehingga pemrogram menempatkan fitur dalam kode sendiri, di mana ia tidak termasuk. Ini mengarah ke jelek, sulit untuk menjaga kode, penuh dengan duplikasi dan rendah (buruk) kohesi.
Kepemilikan kolektif bisa menjadi masalah jika orang yang bekerja pada kode-ambing mereka tidak mengerti. XP untuk menghindari masalah ini melalui dua tombol teknik: the programmer tes menangkap kesalahan, dan pasangan pemrograman berarti bahwa cara terbaik untuk bekerja pada kode asing adalah pasangan dengan ahli. Selain itu untuk memastikan baik modifikasi bila diperlukan, pengetahuan praktik ini menyebar di seluruh tim.
Coding standar
XP tim mengikuti standar umum coding, sehingga semua kode dalam sistem terlihat seperti itu ditulis oleh satu - sangat kompeten - individu. Yang secara khusus dari standar yang tidak penting: apa yang penting adalah bahwa semua kode tampak akrab, mendukung kepemilikan kolektif.
Metaphor
Ekstrim Pemrograman tim mengembangkan visi umum bagaimana program bekerja, yang kita panggil "metaphor". Pada posisi terbaik, metaphor adalah deskripsi sederhana evocative bagaimana program kerjanya, misalnya "program ini bekerja seperti sarang lebah dari lebah, serbuk sari untuk keluar dan membawa kembali ke sarang lebah" sebagai keterangan untuk agen berbasis informasi sistem media.
Kadang-kadang cukup puitis metaphor tidak timbul. Dalam kasus manapun, dengan atau tanpa gambar hidup, XP tim menggunakan nama umum dari sistem untuk memastikan bahwa semua orang mengerti bagaimana sistem bekerja dan di mana untuk melihat untuk mencari fungsi yang Anda cari, atau untuk menemukan tempat yang tepat untuk menempatkan fungsi anda untuk menambahkan.
Berkelanjutan Pace
Pemrograman ekstrim dalam tim untuk jangka panjang. Mereka bekerja keras, dan pada kecepatan yang dapat terus-menerus tanpa batas. Ini berarti mereka bekerja lembur bila efektif, dan bahwa mereka biasanya bekerja dengan cara yang untuk memaksimalkan produktivitas dan minggu pekan. Menarik untuk dipahami bahwa hari-hari ini kematian Maret proyek yang tidak produktif dan tidak menghasilkan kualitas perangkat lunak. XP berada dalam tim untuk menang, tidak mati.
Kesimpulan
Pemrograman ekstrim adalah disiplin pengembangan software berdasarkan nilai-nilai kesederhanaan, komunikasi, umpan balik, dan keberanian. Kerjanya dengan membawa seluruh tim bersama-sama di hadapan praktek sederhana, cukup dengan masukan agar tim untuk melihat di mana mereka berada dan praktik yang selaras dengan situasi yang unik.
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://www.xprogramming.com/xpmag/whatisxp.htm
Dalam Extreme Programming, setiap kontributor proyek merupakan bagian integral dari "Seluruh Tim". Tim bentuk usaha perwakilan sekitar disebut "Pelanggan", yang duduk dengan tim dan bekerja dengan mereka sehari-hari.Praktik inti: Seluruh Tim Ekstrim Pemrograman tim menggunakan sederhana bentuk perencanaan dan pelacakan untuk menentukan apa yang harus dilakukan selanjutnya dan untuk meramalkan kapan proyek ini akan dilakukan.
Difokuskan pada nilai bisnis, tim memproduksi perangkat lunak dalam serangkaian kecil sepenuhnya terpadu-rilis yang lulus tes semua pelanggan yang telah ditetapkan.
Praktik inti: Perencanaan Game, Kecil Releases, Pelanggan Pengujian Ekstrim pemrogram bekerja sama dalam pasangan dan sebagai salah satu grup, dengan desain sederhana dan kode obsessively diuji, memperbaiki desain terus untuk selalu menjaga ini tepat untuk kebutuhan saat ini.
Inti Praktek: Simple Desain, pasangan Pemrograman, Uji-Terutama Pembangunan, Peningkatan Desain Extreme Pemrograman tim yang membuat sistem terpadu dan berjalan setiap saat. Pemrogram yang menulis kode produksi di semua pasangan, dan semua bekerja bersama-sama setiap saat. Kode mereka dalam gaya yang konsisten agar semua orang dapat memahami dan meningkatkan semua kode yang diperlukan.
Praktik inti: Continuous Integration, Collective Kode Kepemilikan, Coding Standar The Extreme Pemrograman saham tim yang umum dan sederhana gambaran tentang apa yang tampak seperti sistem. Setiap orang yang bekerja pada kecepatan yang dapat terus-menerus tanpa batas.
Praktik inti: Metaphor, Pembangunan Pace
Inti Praktik
Seluruh Tim
Semua kontributor untuk sebuah proyek XP duduk bersama, salah satu anggota tim.
Tim ini harus termasuk usaha perwakilan - yang "Pelanggan" - yang menyediakan kebutuhan, menentukan prioritas, dan steers proyek. Ini terbaik jika salah satu atau Pelanggan aides dia adalah pengguna akhir yang tahu domain dan apa yang dibutuhkan. Tim tentunya akan memiliki pemrogram. Tim mungkin termasuk contoh, yang membantu pelanggan menentukan tes penerimaan pelanggan. Analis Mei menjadi penolong kepada Pelanggan, membantu untuk menentukan persyaratan. Biasanya ada pelatih yang membantu tim terus melacak dan memfasilitasi proses. Mungkin ada manajer, menyediakan sumber daya, penanganan eksternal komunikasi, koordinasi kegiatan. Tidak ada peran yang harus yang eksklusif milik masing-masing hanya satu: Semua orang di tim XP kontribusi dalam bentuk apapun yang mereka dapat. Yang tidak memiliki tim ahli, hanya umum kontributor dengan keterampilan khusus.
Perencanaan Game
XP perencanaan alamat dua pertanyaan kunci dalam pengembangan software: predicting apa yang akan dicapai dengan tanggal jatuh tempo, dan menentukan apa yang harus dilakukan berikutnya. Penekanan adalah mengarahkan pada proyek - yang sangat mudah - tepat di daripada prediksi tentang apa yang diperlukan dan berapa lama ia akan mengambil - yang cukup sulit. Ada dua langkah penting dalam perencanaan XP, menangani dua pertanyaan:
Release Perencanaan adalah praktek dimana Nasabah menyajikan fitur yang diinginkan ke pemrogram, dan pemrogram memperkirakan kesulitan. Dengan perkiraan biaya di tangan, dan dengan pengetahuan tentang pentingnya fitur, Pelanggan meletakkan satu rencana untuk proyek tersebut. Rencana awal rilis yang selalu tepat: baik prioritas maupun perkiraan yang benar-benar solid, dan sampai tim mulai bekerja, kita tidak akan tahu bagaimana cepat mereka hanya akan pergi. Bahkan rencana rilis pertama adalah cukup akurat untuk pengambilan keputusan, namun, dan XP tim merevisi rencana rilis secara berkala.
Perulangan Perencanaan adalah praktik di mana arah tim diberikan setiap beberapa bulan. XP tim membangun perangkat lunak dalam dua minggu "Iterasi", perangkat lunak berguna memberikan berjalan di akhir setiap perulangan. Selama perulangan Perencanaan, Pelanggan menyajikan fitur diinginkan selama dua minggu. Pemrogram istirahat yang turun ke dalam tugas-tugas mereka, dan memperkirakan biaya (pada tingkat detail halus dibandingkan Release Perencanaan). Berdasarkan jumlah pekerjaan dicapai dalam perulangan sebelumnya, tim mendaftar untuk apa yang akan dilakukan pada perulangan.
Perencanaan langkah-langkah ini sangat sederhana, namun mereka memberikan informasi yang sangat bagus dan sangat steering kontrol di tangan Nasabah. Setiap beberapa minggu, jumlah seluruhnya adalah kemajuan terlihat. Mereka yang tidak "sembilan puluh persen dilakukan" di XP: fitur cerita itu selesai, atau bukan. Ini berfokus pada visibilitas hasil bagus sekali sedikit paradoks: di satu sisi, dengan begitu banyak visibilitas, Pelanggan yang berada dalam posisi untuk membatalkan proyek berlangsung jika tidak cukup. Di sisi lain, kemajuan sangat terlihat, dan kemampuan untuk memutuskan apa yang akan dilakukan berikutnya sangat lengkap, XP proyek-proyek yang cenderung memberikan lebih dari apa yang dibutuhkan, dengan sedikit tekanan dan stres.
Pelanggan Pengujian
Sebagai bagian dari fitur presentasi setiap dikehendaki, XP Pelanggan yang mendefinisikan satu atau lebih otomatis penerimaan tes untuk menunjukkan bahwa fitur ini bekerja. Tim ini membangun tes dan menggunakan mereka untuk membuktikan diri, dan kepada konsumen, fitur yang dilaksanakan dengan benar. Otomasi sangatlah penting karena di tekan waktu, manual tes yang dilewati. Itu seperti mematikan lampu ketika Anda mendapatkan malam gelap.
Tim yang terbaik XP memperlakukan pelanggan mereka tes dengan cara yang sama mereka lakukan tes programmer: sekali ujian berjalan, tim ini tetap berjalan dengan benar setelahnya. Ini berarti bahwa sistem hanya meningkatkan, selalu tidak ada kemajuan, tidak pernah kembali ke tampilan.
Kecil Releases
XP latihan tim kecil rilis penting dalam dua cara:
Pertama, tim rilis berjalan, perangkat lunak yang diuji, memberikan nilai bisnis yang dipilih oleh Nasabah, setiap perulangan. Pelanggan dapat menggunakan software ini untuk tujuan apapun, evaluasi apakah rilis atau bahkan ke pengguna akhir (sangat dianjurkan). Aspek yang paling penting adalah bahwa perangkat lunak yang terlihat, dan diberikan kepada pelanggan, di akhir setiap perulangan. Ini membuat semuanya jelas dan terbuka.
Kedua, XP rilis tim ke pengguna akhir mereka sering juga. XP Web proyek rilis sesering yang sehari-hari, di rumah proyek bulanan atau lebih sering. Bahkan shrink-wrapped produk dikirimkan sesering triwulan.
Mungkin ini tampaknya tidak mungkin untuk membuat versi ini sering baik, tapi seluruh tim XP yang tepat setiap saat. Lihat integrasi lanjutan untuk mengetahui ini, dan perhatikan bahwa sering rilis dijaga oleh diandalkan XP dari obsesi dengan pengujian, seperti dijelaskan di Pelanggan Pengujian dan Test-Terutama Pembangunan.
Desain sederhana
XP tim membangun perangkat lunak untuk desain yang sederhana. Mereka mulai sederhana, dan melalui pengujian pemrogram dan desain perbaikan, mereka itu tetap jalan. XP membuat sebuah tim yang benar-benar cocok untuk desain yang sekarang fungsionalitas dari sistem. Tidak ada gerakan-siakan, dan perangkat lunak akan selalu siap untuk apa berikutnya.
Desain XP tidak satu kali itu, atau atas hal-depan, semua itu adalah pada waktu hal. Terdapat langkah-langkah dalam desain dan perencanaan rilis perulangan perencanaan, plus cepat tim terlibat dalam desain dan desain sesi melalui revisi refactoring, melalui kursus dari keseluruhan proyek. Dalam sebuah incremental, proses yg berulang seperti Extreme Programming, desain yang baik adalah sangat penting. Itulah mengapa ada begitu banyak berfokus pada desain sepanjang saja dari keseluruhan pembangunan.
Pasangan Pemrograman
Semua perangkat lunak produksi dalam XP dibangun oleh dua pemrogram, duduk berdampingan, di mesin yang sama. Praktik ini akan memastikan bahwa semua produksi kode dikaji oleh minimal satu programmer lainnya, dan hasil yang lebih baik dalam desain, pengujian yang lebih baik, lebih baik dan kode.
Mungkin ini tampaknya tidak efisien untuk memiliki dua pemrogram melakukan "programmer satu tugas", tetapi mundur adalah benar. Penelitian menjadi pasangan pemrograman menunjukkan bahwa pasangan memproduksi lebih baik tentang kode dalam waktu yang sama seperti pemrogram bekerja sendiri. Iya betul : dua kepala benar-benar lebih dari satu!
Beberapa pemrogram objek pemrograman untuk memasangkan tanpa pernah mencoba itu. It does mengambil beberapa praktek untuk melakukan dengan baik, dan Anda harus melakukannya dengan baik selama beberapa minggu untuk melihat hasilnya. Sembilan puluh persen dari pemrogram yang belajar pemrograman lebih memilih pasangan ini, jadi kami sangat merekomendasikan hal ini kepada semua tim.
Pasangan, selain memberikan lebih baik dan kode ujian, juga berfungsi untuk berkomunikasi pengetahuan seluruh tim. Beralih sebagai pasangan, semua orang mendapat manfaat dari semua ilmu khusus. Pemrogram belajar, meningkatkan kemampuan mereka, mereka menjadi lebih bermanfaat bagi tim dan perusahaan. Pasangan, bahkan di luar sendiri XP, yang menang besar bagi semua orang.
Test-Terutama Pembangunan
Pemrograman ekstrim adalah terobsesi dengan umpan balik, dan dalam pengembangan perangkat lunak, baik umpan balik baik memerlukan uji. Atas tim XP praktek "test-driven development", yang bekerja di sangat singkat siklus menambahkan tes, maka sehingga pekerjaan. Hampir effortlessly, tim menghasilkan kode dengan hampir 100 persen tes cakupan, yang merupakan langkah maju dalam banyak toko-toko. (Jika Anda sudah pemrogram melakukan pengujian yang lebih canggih, lebih kuasa kepada Anda. Keep it up, ia hanya dapat membantu!)
Ianya tidak cukup untuk tes tulis: Anda harus menjalankannya. Di sini juga, Extreme Programming is ekstrim. Ini "programmer ujian", atau "tes unit" semua dikumpulkan bersama-sama, dan setiap kali ada rilis programmer setiap kode ke repositori (dan pasangan biasanya rilis dua kali sehari atau lebih), setiap satu dari tes programmer harus dijalankan dengan benar. Seratus persen, setiap saat! Ini berarti pemrogram segera mendapat umpan balik tentang cara mereka lakukan. Selain itu, tes ini memberikan dukungan yang tak ternilai desain adalah perangkat lunak ditingkatkan.
Desain Peningkatan
Ekstrim Pemrograman berfokus pada memberikan nilai bisnis dalam setiap perulangan. Untuk melakukannya selama seluruh proyek perangkat lunak harus dirancang dengan baik. Alternatif yang akan memperlambat dan akhirnya buntu. Jadi XP menggunakan proses perbaikan terus desain disebut Refactoring, dari judul buku Martin Fowler, "Refactoring: Meningkatkan Desain yang ada dari Kode".
Refactoring yang berfokus pada proses penghapusan duplikasi (yakin suatu tanda miskin desain), dan pada peningkatan "kohesi" dari kode, sementara turunkan "kopel". Kohesi tinggi dan rendah kopel telah diakui sebagai hallmarks yang dirancang dengan baik-kode untuk setidaknya tiga puluh tahun. Hasilnya adalah bahwa XP dimulai dengan tim yang bagus, desain sederhana, dan selalu ada yang baik dan sederhana untuk merancang perangkat lunak. Hal ini memungkinkan mereka mempertahankan mereka mempercepat pembangunan, dan bahkan umumnya meningkatkan kecepatan sebagai proyek berjalan maju.
Refactoring adalah, tentu saja sangat didukung oleh pengujian komprehensif untuk memastikan bahwa sebagai perkembangan desain, tidak ada yang rusak. Dengan demikian, pelanggan tes dan tes programmer adalah faktor penting yang memungkinkan. XP praktek yang mendukung satu sama lain, mereka lebih kuat daripada bersama-sama secara terpisah.
Continuous Integration
Ekstrim Pemrograman tim menjaga sistem terintegrasi di semua kali. Kami mengatakan bahwa setiap hari adalah untuk membangun wimps: XP tim membangun beberapa kali per hari. (XP Satu tim yang terdiri dari empat puluh orang membangun sedikitnya delapan atau sepuluh kali per hari!)
Manfaat dari praktek ini dapat dilihat oleh berpikir kembali proyek Anda mungkin telah mendengar tentang (atau bahkan sudah menjadi bagian dari) dimana proses pembangunan itu mingguan atau lebih jarang, dan biasanya menyebabkan "integrasi neraka", dimana semuanya bokek dan tidak ada satu tahu mengapa.
Jarang integrasi mengarah ke masalah serius pada proyek perangkat lunak. Pertama, walaupun sangat penting bagi integrasi pengiriman kode bekerja baik, tim ini tidak dilakukan saat itu, dan sering itu didelegasikan kepada orang-orang yang tidak akrab dengan seluruh sistem. Kedua, kode terpadu jarang sering - Say akan berbicara biasanya - kode buggy. Masalah merayap di integrasi dalam waktu yang tidak terdeteksi oleh salah satu dari tes yang dilakukan pada sebuah sistem unintegrated. Ketiga, lemah integrasi proses panjang mengarah ke kode freezes. Kode freezes berarti Anda memiliki jangka waktu panjang apabila pemrogram dapat bekerja pada shippable fitur penting, tetapi orang-orang yang memiliki harus diadakan kembali. Ini melemahkan posisi Anda di pasar, atau dengan pengguna akhir.
Kepemilikan kolektif Kode
Extreme Pemrograman pada proyek, ada sepasang pemrogram dapat meningkatkan kode apapun kapan saja. Ini berarti bahwa semua kode mendapat manfaat dari perhatian banyak orang, yang akan meningkatkan kualitas dan mengurangi kode cacat. Ada lagi manfaat penting juga apabila kode dimiliki oleh perorangan, diperlukan fitur yang sering dimasukkan ke dalam tempat yang salah, sebagai salah satu programmer menemukan bahwa ia memerlukan suatu fitur dalam kode bahwa ia tidak sendiri. Pemilik terlalu sibuk untuk melakukannya, sehingga pemrogram menempatkan fitur dalam kode sendiri, di mana ia tidak termasuk. Ini mengarah ke jelek, sulit untuk menjaga kode, penuh dengan duplikasi dan rendah (buruk) kohesi.
Kepemilikan kolektif bisa menjadi masalah jika orang yang bekerja pada kode-ambing mereka tidak mengerti. XP untuk menghindari masalah ini melalui dua tombol teknik: the programmer tes menangkap kesalahan, dan pasangan pemrograman berarti bahwa cara terbaik untuk bekerja pada kode asing adalah pasangan dengan ahli. Selain itu untuk memastikan baik modifikasi bila diperlukan, pengetahuan praktik ini menyebar di seluruh tim.
Coding standar
XP tim mengikuti standar umum coding, sehingga semua kode dalam sistem terlihat seperti itu ditulis oleh satu - sangat kompeten - individu. Yang secara khusus dari standar yang tidak penting: apa yang penting adalah bahwa semua kode tampak akrab, mendukung kepemilikan kolektif.
Metaphor
Ekstrim Pemrograman tim mengembangkan visi umum bagaimana program bekerja, yang kita panggil "metaphor". Pada posisi terbaik, metaphor adalah deskripsi sederhana evocative bagaimana program kerjanya, misalnya "program ini bekerja seperti sarang lebah dari lebah, serbuk sari untuk keluar dan membawa kembali ke sarang lebah" sebagai keterangan untuk agen berbasis informasi sistem media.
Kadang-kadang cukup puitis metaphor tidak timbul. Dalam kasus manapun, dengan atau tanpa gambar hidup, XP tim menggunakan nama umum dari sistem untuk memastikan bahwa semua orang mengerti bagaimana sistem bekerja dan di mana untuk melihat untuk mencari fungsi yang Anda cari, atau untuk menemukan tempat yang tepat untuk menempatkan fungsi anda untuk menambahkan.
Berkelanjutan Pace
Pemrograman ekstrim dalam tim untuk jangka panjang. Mereka bekerja keras, dan pada kecepatan yang dapat terus-menerus tanpa batas. Ini berarti mereka bekerja lembur bila efektif, dan bahwa mereka biasanya bekerja dengan cara yang untuk memaksimalkan produktivitas dan minggu pekan. Menarik untuk dipahami bahwa hari-hari ini kematian Maret proyek yang tidak produktif dan tidak menghasilkan kualitas perangkat lunak. XP berada dalam tim untuk menang, tidak mati.
Kesimpulan
Pemrograman ekstrim adalah disiplin pengembangan software berdasarkan nilai-nilai kesederhanaan, komunikasi, umpan balik, dan keberanian. Kerjanya dengan membawa seluruh tim bersama-sama di hadapan praktek sederhana, cukup dengan masukan agar tim untuk melihat di mana mereka berada dan praktik yang selaras dengan situasi yang unik.
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://www.xprogramming.com/xpmag/whatisxp.htm
0 komentar:
Posting Komentar