Agile pengembangan software

Agile pengembangan software adalah sekelompok metodologi pengembangan software yang didasarkan pada prinsip-prinsip yang sama. Agile metodologi umumnya mempromosikan proyek yang mendorong proses pengelolaan sering inspeksi dan adaptasi, sebuah filosofi yang mendorong kepemimpinan tim, mandiri dan akuntabilitas organisasi, satu set teknik praktek terbaik yang memungkinkan untuk pengiriman cepat dari perangkat lunak yang berkualitas tinggi, dan usaha pendekatan yang aligns pembangunan dengan kebutuhan pelanggan dan tujuan perusahaan. Konseptual kerangka dasar-dasar ini akan ditemukan di modern pendekatan manajemen operasional dan analisis seperti bersandar manufaktur, lunak sistem metodologi, pidato bertindak teori (pendekatan percakapan jaringan), dan Six Sigma.

Pendahuluan

Ada banyak metode pengembangan Agile spesifik. Sebagian besar mempromosikan pembangunan Iterasi, tim, kolaborasi, dan proses adaptasi sepanjang siklus hidup proyek.
Agile metode memilih untuk melakukan hal-hal kecil akan menambahkan dengan sedikit perencanaan, daripada perencanaan jangka panjang. Iterasi bingkai waktu yang singkat (yang dikenal sebagai 'timeboxes') yang terakhir biasanya dari satu sampai empat bulan. Setiap perulangan adalah bekerja dengan tim yang lengkap melalui siklus pengembangan perangkat lunak, termasuk perencanaan, analisis persyaratan, desain, coding, unit testing, dan penerimaan pengujian bila bekerja produk menunjukkan kepada pemangku kepentingan. Ini membantu untuk meminimalkan risiko secara keseluruhan, dan memungkinkan proyek tersebut untuk beradaptasi dengan perubahan yang cepat. Dokumentasi yang dihasilkan seperti yang diminta oleh pihak yang berkepentingan. Perulangan yang mungkin tidak cukup menambahkan fungsi untuk menjamin produk melepaskannya ke pasar, namun tujuan adalah untuk memiliki sebuah rilis yang tersedia (dengan sedikit bug) di akhir setiap perulangan. Iterasi beberapa mungkin diperlukan untuk melepaskan produk atau fitur baru.

Komposisi tim dalam proyek Agile biasanya lintas fungsional dan mengorganisir diri tanpa pertimbangan untuk perusahaan yang ada hirarki korporat atau peran anggota tim. Anggota tim biasanya bertanggung jawab untuk tugas-tugas yang memberikan fungsi yang perulangan. Mereka memutuskan untuk diri mereka sendiri bagaimana mereka akan dijalankan selama perulangan.

Agile menekankan metode tatap muka komunikasi tertulis atas dokumen, ketika bekerja di lokasi yang sama, atau di lokasi yang berbeda namun memiliki video kontak harian, berkomunikasi oleh videoconferencing, suara, e-mail dll

Paling Agile tim berada dalam satu kantor buka untuk memfasilitasi komunikasi seperti itu. Tim biasanya ukuran kecil (5-9 orang) untuk membantu tim komunikasi dan kerjasama tim yang lebih mudah. Pengembangan usaha yang lebih besar dapat diberikan oleh beberapa tim bekerja ke arah tujuan yang berbeda atau bagian dari suatu usaha. Hal ini mungkin juga memerlukan koordinasi prioritas di seluruh tim.

Apapun perkembangan disiplin diperlukan, Agile setiap tim akan berisi perwakilan pelanggan. Orang ini yang ditunjuk oleh para pemangku kepentingan untuk bertindak atas nama mereka dan membuat komitmen untuk menjadi pribadi yang tersedia bagi para pengembang untuk pertengahan perulangan masalah-domain pertanyaan. Pada akhir setiap perulangan, stakeholder dan perwakilan pelanggan meninjau kemajuan dan mengevaluasi kembali prioritas dengan maksud untuk mengoptimalkan laba atas investasi dan menjamin alignment dengan kebutuhan pelanggan dan tujuan perusahaan.

Kebanyakan metodologi Agile termasuk rutin sehari-hari dan formal tatap muka komunikasi antara anggota tim. Ini secara khusus meliputi wakil pelanggan dan stakeholder tertarik sebagai pengamat. Dalam sesi singkat, laporan kepada anggota tim lainnya masing-masing apa yang mereka lakukan kemarin, apa yang mereka ingin lakukan hari ini, dan apa yang mereka roadblocks. Ini berdiri tatap muka komunikasi mencegah masalah yang tersembunyi.

Agile menekankan metode kerja perangkat lunak sebagai dasar mengukur kemajuan. Dikombinasikan dengan pilihan untuk tatap muka komunikasi, Agile metode biasanya menghasilkan dokumentasi tertulis kurang daripada metode lainnya. Agile dalam sebuah proyek, dan dokumentasi lainnya proyek seni semua peringkat bekerja sama dengan produk. Pemangku kepentingan yang mendorong mereka untuk memprioritaskan hasil perulangan dengan lainnya secara eksklusif berbasis pada nilai usaha dirasakan di awal perulangan.

Alat dan teknik khusus seperti integrasi berkesinambungan, otomatis atau xUnit tes, pasangan pemrograman, uji didorong pengembangan, desain pola, domain-driven desain, kode refactoring dan teknik yang sering digunakan untuk memperbaiki dan meningkatkan kualitas proyek agility.

Sejarah

Modern definisi Agile pengembangan software berkembang pada pertengahan tahun 1990-an sebagai bagian dari reaksi terhadap "berat" metode, dikatakan oleh seorang typified berat diatur, regimented, Mikro dikelola menggunakan waterfall model pembangunan. Proses ini berasal dari air terjun menggunakan model yang dianggap sebagai birokrasi, lambat, demeaning, dan tidak konsisten dengan cara yang sebenarnya pengembang perangkat lunak melakukan kerja efektif. Kasus dapat dibuat yang Agile dan pengembangan metode yg berulang adalah pembangunan kembali ke praktek mulai awal dalam sejarah pengembangan piranti lunak. Pada mulanya, Agile metode yang disebut "metode ringan." Pada tahun 2001, anggota tokoh masyarakat bertemu di Snowbird, Utah, dan mengadopsi nama "metode Agile." Nantinya, sebagian dari orang-orang yang membentuk Aliansi Agile, sebuah organisasi nirlaba yang mempromosikan pembangunan Agile.

Suatu proses pengembangan software adaptif diperkenalkan dalam karya oleh Edmonds (1974). terkemuka awal Agile metode mencakup banyak (1995), Crystal Clear, Extreme Programming (1996), adaptive Software Development, Fitur Terutama Pembangunan dan Pengembangan Sistem Dinamis Metode (DSDM) (1995). Ini biasanya disebut sebagai metodologi Agile sejak Agile Manifesto telah diterbitkan pada tahun 2001.


Prinsip belakang metode Agile

Agile metode keluarga proses pembangunan, tidak ada satu pendekatan untuk pengembangan piranti lunak. Pada tahun 2001, angka 17 menonjol [4] di bidang pembangunan Agile (kemudian disebut "light-weight metode") berkumpul di Snowbird resor ski di Utah untuk membahas cara-cara untuk membuat perangkat lunak yang ringan, lebih cepat, lebih banyak orang-centric jalan. Mereka menciptakan Agile Manifesto, secara luas dianggap sebagai kanonik definisi pembangunan dan Agile Agile dengan prinsip-prinsip. Agile Manifesto yang menyatakan:

Kita lebih baik uncovering cara pengembangan perangkat lunak oleh tepat dan membantu orang lain melakukannya. Melalui karya ini kita telah datang ke nilai:
- Individu dan melalui proses interaksi dan alat-alat
- Bekerja lebih komprehensif dokumentasi perangkat lunak
- Pelanggan kolaborasi melalui negosiasi kontrak
- Merespon perubahan atas menyusul rencana
- Itulah sebabnya, saat ada dalam nilai item di sebelah kanan, kami nilai item di sebelah kiri lebih.

Beberapa prinsip-prinsip di belakang Agile Manifesto adalah:
- Kepuasan pelanggan oleh cepat, pengiriman yang berguna dari perangkat lunak
- Bekerja software sering disampaikan (bulan daripada bulan)
- Bekerja software kepala sekolah mengukur kemajuan
- Bahkan akhir perubahan dalam persyaratan yang menyambut
- Dekat, harian bisnis kerjasama antara masyarakat dan pengembang
- Tatap muka percakapan yang bentuk komunikasi (Co-location)
- Proyek yang dibangun sekitar motivasi individu, yang harus dipercaya
- Terus perhatian untuk keunggulan teknis dan desain
- Kesederhanaan
- Cukup mengatur tim
- Regular adaptasi untuk mengubah keadaan

The manifesto spawned gerakan dalam industri perangkat lunak yang dikenal sebagai Agile pengembangan piranti lunak.

Pada tahun 2005, Alistair Cockburn dan Jim Highsmith lain mengumpulkan sekelompok orang-ahli manajemen, kali ini dan menulis sebuah addendum, yang dikenal sebagai PM Deklarasi saling tergantung.
Berfungsinya prinsip Agile dapat ditemukan di bersandar pabrikasi dan Six Sigma. Konsep-konsep ini meliputi pemeriksaan kesalahan, menghilangkan sampah, membuat aliran, menambahkan nilai pelanggan, dan pemberdayaan pekerja. Konsep-konsep yang pertama resmi espoused dalam 14 prinsip yang Toyota Way, dua pilar dari Toyota Production System (Just-in-time dan otomatisasi pintar), maka 5S metodologi, dan Deming dari 14 poin. Ini telah diringkas dalam tujuh poin yang bersandar pengembangan piranti lunak.

Perbandingan dengan metode lain

Agile metode kadang karakteristik sebagai di seberang akhir spektrum dari "rencana-driven" atau "disiplin" metode. Perbezaan ini adalah menyesatkan, karena secara tidak langsung bahwa Agile metode "unplanned" atau "bandel". Perbedaan yang lebih akurat adalah metode yang ada di sebuah kontinum dari "adaptif" untuk "input". [6] metode Agile berbaring di "adaptif" samping ini kontinum.

Adaptive metode fokus beradaptasi dengan cepat untuk mengubah realitas. Bila kebutuhan proyek berubah, perubahan yang adaptif tim juga. Adaptif tim yang akan mengalami kesulitan menjelaskan apa yang akan terjadi di masa depan. Yang jauh tanggal, semakin kabur sebuah metode adaptif akan tentang apa yang akan terjadi pada tanggal tersebut. Sebuah tim adaptif dapat melaporkan apa tugas-tugas yang dilakukan minggu depan, namun hanya merupakan fitur yang direncanakan untuk bulan depan. Ketika ditanyakan tentang rilis enam bulan dari sekarang, sebuah tim adaptif mungkin hanya dapat melaporkan pernyataan misi untuk rilis atau pernyataan diharapkan nilai vs biaya.

Metode input, kontras, fokus pada perencanaan masa depan secara rinci. A input tim dapat melaporkan apa fitur dan tugas-tugas yang direncanakan untuk seluruh panjang dari proses pembangunan. Input tim memiliki kesulitan mengubah arah. Biasanya rencana awal dioptimalkan untuk mengubah arah tujuan dan dapat menyebabkan menyelesaikan pekerjaan yang harus dibuang dan dilakukan atas berbeda. Input tim akan sering lembaga perubahan kontrol papan untuk memastikan bahwa hanya perubahan yang paling dianggap berharga.

Agile ada banyak metode umum dengan "Rapid Application Development" teknik dari 1980/90s sebagai espoused oleh James Martin dan lain-lain.

Contrasted dengan pengembangan metode yg berulang

Agile berbagi metode lainnya yg berulang incremental dan pengembangan metode 'penekanan pada bangunan di releasable jangka waktu singkat. Agile pembangunan lainnya berbeda dari model-model pembangunan: model ini dalam jangka waktu yang diukur dalam bulan daripada bulan dan pekerjaan yang dilakukan dalam cara yang sangat kolaboratif. Metode paling Agile juga berbeda memperlakukan mereka sebagai jangka waktu ketat timebox.

Contrasted dengan model air terjun

Agile pembangunan sedikit memiliki kesamaan dengan model air terjun. Pada 2009, model air terjun yang masih umum dipakai. [7] The waterfall model adalah yang paling terstruktur dari metode, langkah melalui persyaratan-capture, analisis, desain, coding, dan pengujian yang ketat dalam, pra-urutan direncanakan. Kemajuan biasanya diukur dari segi seni deliverable: kebutuhan spesifikasi, desain dokumen, rencana ujian, kode review dan sejenisnya.

Masalah utama dengan model air terjun adalah kejur pembagian proyek menjadi tahap terpisah, sehingga komitmen yang dibuat pada awal, dan sulit untuk bereaksi terhadap perubahan dalam persyaratan. Iterasi yang mahal. Hal ini berarti air terjun model ini mungkin tidak cocok jika persyaratan yang tidak dipahami atau kemungkinan perubahan dalam pelaksanaan proyek. [8]

Agile metode, kontras, menghasilkan sepenuhnya dikembangkan dan diuji fitur (tapi sangat kecil subset dari seluruh) setiap beberapa bulan. Penekanan adalah pada mendapatkan bagian terkecil dari fungsi bekerja untuk memberikan nilai awal bisnis, dan terus memperbaiki dan menambahkan fungsionalitas lebih lanjut sepanjang kehidupan proyek.

Dalam hal ini, kritik Agile Mei menegaskan bahwa fitur ini tidak ditempatkan dalam konteks dari keseluruhan proyek, menyelesaikan itu, jika sponsor dari proyek prihatin tentang menyelesaikan tujuan tertentu dengan waktu yang ditetapkan atau anggaran, Agile mungkin tidak sesuai. Agile Proponents dari pengembangan counter yang adaptasi dari banyak orang [9] menunjukkan bagaimana Agile augmented metode untuk memproduksi dan terus meningkatkan rencana strategis.

Beberapa tim Agile menggunakan model air terjun dalam skala kecil, mengulangi seluruh siklus air terjun dalam setiap perulangan. [10] Tim lain, terutama Extreme Pemrograman tim, bekerja pada kegiatan secara bersamaan.

Contrasted dengan "koboi coding"

Cowboy coding adalah tidak adanya metode yang ditetapkan: anggota tim merasa mereka melakukan apa yang benar. Agile's sering pembangunan kembali rencana evaluasi, pada tatap muka komunikasi, dan relatif jarang menggunakan dokumen terkadang menyebabkan orang untuk merancukan dengan koboi coding. Agile tim Namun, melakukan tindak ditetapkan (dan sering sangat disiplin dan teliti) proses.

Seperti semua metode pembangunan, keahlian dan pengalaman pengguna yang menentukan tingkat keberhasilan dan / atau penyalahgunaan seperti aktivitas. Kaku kontrol yang lebih sistematis tertanam dalam proses menawarkan tingkat akuntabilitas yang lebih kuat dari pengguna. Penurunan yang baik ditujukan prosedur dapat mengakibatkan kegiatan yang dikategorikan koboi sering coding.

Kesesuaian metode Agile

Ada sedikit jika ada konsensus tentang jenis proyek perangkat lunak yang cocok untuk metodologi Agile. Banyak organisasi besar mengalami kesulitan mampu menjembatani kesenjangan antara air terjun yang lebih tradisional dan metode yang Agile satu.

Skala besar Agile pengembangan piranti lunak tetap aktif penelitian daerah.
Beberapa hal yang dapat berdampak negatif terhadap keberhasilan yang Agile proyek adalah:
Pengembangan usaha skala besar (> 20 pengembang), meskipun skala strategi dan bukti yang bertentangan [16] telah dijelaskan.
Didistribusikan pengembangan usaha (non-co-terletak tim). Strategi yang telah dijelaskan dalam Bridging the Distance [17] dan Menggunakan Software Agile Proses dengan Offshore Pembangunan [18]
Perintah dan kontrol budaya perusahaan
Memaksa seorang Agile proses pembangunan di tim

Beberapa berhasil Agile proyek-proyek berskala besar telah didokumentasikan. BT memiliki ratusan pengembang terletak di Inggris, Irlandia dan India yang bekerja pada proyek kolaborasi dan menggunakan metode Agile. Walaupun masih niscaya timbul pertanyaan tentang kesesuaian Agile beberapa metode untuk jenis proyek tertentu, akan muncul bahwa skala atau geografi, dengan sendirinya, tidak perlu hambatan untuk sukses.

Barry Boehm dan Richard Turner menunjukkan bahwa analisa resiko digunakan untuk memilih antara adaptif ( "Agile") dan input ( "rencana-driven") metode. [14] Para penulis menunjukkan bahwa setiap sisi kontinum memiliki rumah tanah sebagai berikut :

Agile rumah tanah:
Rendah criticality
Senior pengembang
Persyaratan terlalu sering berubah
Beberapa pengembang
Budaya yang berkembang pada kekacauan

Rencana-driven rumah tanah:
Tinggi criticality
SMP pengembang
Persyaratan yang tidak berubah terlalu sering
Banyak pengembang
Budaya yang menuntut agar

Agile metode dan metode jahitan

Dalam literatur, istilah yang berbeda merujuk pada gagasan metode adaptasi, termasuk 'metode jahitan', 'metode fragmen adaptasi' dan 'metode rekayasa berubah'. Metode tailor didefinisikan sebagai:

Sebuah proses atau kemampuan manusia yang responsif melalui agen perubahan, dan dinamis interplays antara konteks, tujuan, dan metode fragmen menentukan pendekatan pengembangan sistem yang spesifik untuk proyek situasi. [19]

Potensial, hampir semua Agile metode metode yang sesuai untuk memperbaiki. Bahkan DSDM metode yang digunakan untuk tujuan ini dan telah berhasil dirancang dalam CMM konteks. [20] Situasi-kesesuaian dapat dianggap sebagai ciri-bedakan antara Agile metode tradisional dan metode pengembangan perangkat lunak, dengan yang kedua yang relatif lebih kaku dan menentukan. Implikasinya adalah praktek yang Agile metode membolehkan tim proyek untuk mengadaptasi praktek kerja sesuai dengan kebutuhan masing-masing proyek. Praktek yang konkret kegiatan dan produk yang merupakan bagian dari metode kerangka. Pada tingkat yang lebih ekstrim, filosofi di belakang metode, yang terdiri dari sejumlah prinsip, dapat disesuaikan (Aydin, 2004). [19]

Extreme Programming (XP) menjadikan perlunya adaptasi metode eksplisit. Salah satu dasar pemikiran dari XP adalah satu proses yang tidak sesuai setiap proyek, tetapi praktik yang harus disesuaikan dengan kebutuhan masing-masing proyek. Meskipun sebagian dari adopsi XP praktek, seperti yang diusulkan oleh Beck, telah dilaporkan pada beberapa kesempatan. J tailor praktek yang diusulkan oleh mehdi Mirakhorli yang menyediakan peta jalan yang memadai dan pedoman untuk beradaptasi semua praktek. RDP Praktek dirancang untuk mengubah XP. Praktik ini pertama kali diusulkan sebagai karya yang panjang dalam penelitian APSO lokakarya di konferensi ICSE 2008 dan ia adalah satu-satunya metode yang diusulkan dan berlaku untuk mengubah XP. Walaupun secara khusus solusi untuk XP, praktik ini memiliki kemampuan untuk memperluas metodologi lainnya. Pada awalnya sekilas, praktik ini nampaknya dalam kategori statis metode adaptasi tetapi pengalaman dengan RDP Practice mengatakan bahwa hal itu dapat diperlakukan seperti metode adaptasi dinamis. Perbedaan antara metode adaptasi statis dan dinamis metode adaptasi yang halus. [22] Kunci asumsi statis metode adaptasi di belakang adalah bahwa proyek konteks yang diberikan di awal proyek dan masih tetap selama pelaksanaan proyek. Hasilnya adalah definisi statik dari proyek konteks. Dengan definisi seperti ini, peta rute dapat digunakan untuk menentukan struktur fragmen metode harus digunakan untuk proyek tertentu, berdasarkan kriteria standar set. Dinamis metode adaptasi, kontras, menganggap bahwa proyek-proyek yang terletak di dalam konteks baru. Konteks baru yang menunjukkan bahwa proyek harus berurusan dengan tiba-tiba faktor-faktor yang mempengaruhi kondisi relevan tetapi tidak predictable. Ini juga berarti bahwa konteks proyek yang tidak tetap, tetapi berubah selama pelaksanaan proyek. Dalam kasus menentukan rute peta tidak sesuai. Praktek implikasi dinamis metode adaptasi adalah manajer proyek yang seringkali harus mengubah struktur fragmen atau bahkan perubahan fragmen baru, selama pelaksanaan proyek (Aydin dkk, 2005). [22]

Agile dan metode manajemen proyek

Agile metode yang berbeda untuk gelar besar dalam cara mereka meliputi manajemen proyek. Beberapa metode supplemented dengan pedoman tentang manajemen proyek, tetapi pada umumnya tidak mendukung komprehensif.
PRINCE2 telah diusulkan sebagai cocok, melengkapi sistem manajemen proyek.

Project management tool untuk pengembangan tim Agile

Sejumlah alat-alat manajemen proyek secara khusus ditujukan untuk pengembangan Agile. Mereka dirancang untuk membantu merencanakan, melacak, menganalisa dan mengintegrasikan bekerja. Alat ini memainkan peran penting dalam pengembangan Agile, sebagai alat Manajemen Pengetahuan.

Fitur umum adalah: Versi kontrol integrasi, kemajuan pelacakan, alokasi pekerjaan mudah, dan terpadu rilis perulangan perencanaan, forum diskusi, dan pelaporan dan pelacakan software cacat.

Populer Agile pengembangan alat meliputi:
AccuRev J komersial Agile SCM, kontrol versi dan mengganti alat manajemen
Anthill Pro: A komersial membangun manajemen dan berkesinambungan integrasi alat
Bugzilla An open source mengubah manajemen alat
CruiseControl An open source terus integrasi alat
Listrik Cloud J komersial membangun manajemen dan berkesinambungan integrasi alat
Rally: Sebuah proyek komersial Agile alat manajemen
Subversi An open source versi alat kontrol
VersionOne: J komersial Agile proyek alat manajemen

Nilai yang diperoleh Manajemen adalah PMI (Project Management Institute) yang telah disetujui oleh manajemen proyek teknik obyektif untuk mengukur keberhasilan proyek.

Metode Agile

Beberapa dikenal Agile metode pengembangan perangkat lunak:
Agile Modeling
Agile Unified Process (AUP)
Agile Data Metode
DSDM
Penting Unified Process (EssUP)
Extreme programming (XP)
Terutama fitur Development (FDD)
Mendapatkan Real
Buka Unified Process (OpenUP)
Banyak

Agile praktek

Terutama ujian Development (TDD)
Terutama perilaku Development (BDD)
Continuous Integration
Pasangan Pemrograman
Perencanaan poker

Catatan: Walaupun ini sering dianggap metodologi dan dalam diri mereka, mereka hanya praktek-praktek yang digunakan dalam berbagai metodologi.

Agile melebihi pengembangan software

Agile pengembangan software tergantung pada beberapa karakteristik kesurupan hanya oleh perangkat lunak, seperti obyek teknologi dan kemampuan untuk menguji otomatis. Namun, terkait teknik telah dibuat untuk mengembangkan non-produk perangkat lunak, seperti Semikonduktor, kendaraan bermotor, atau bahan kimia. Untuk lebih pada mereka, lihat Fleksibel pengembangan produk.

Mengukur agility

Meskipun banyak [yang] lihat agility sebagai alat untuk diakhiri, sejumlah pendekatan telah diusulkan untuk mengukur agility. Pengukuran Indeks Agility (AIM) nilai proyek terhadap sejumlah faktor agility untuk mencapai total. Yang mirip-bernama Agility Pengukuran Indeks, skor perkembangan terhadap lima dimensi dari software proyek (durasi, risiko, baru, usaha, dan interaksi). Teknik lainnya yang diukur berdasarkan tujuan . Studi lain menggunakan fuzzy matematika [24] telah menyatakan bahwa proyek kecepatan dapat digunakan sebagai metrik dari agility.

Meskipun demikian pendekatan telah diusulkan untuk mengukur agility, praktek aplikasi seperti metrik belum terlihat.

Kritik

Pemrograman ekstrim 's buzz awal dan tenets kontroversial, seperti pasangan pemrograman dan berkesinambungan desain, ada kritikan tertarik tertentu, seperti McBreen [25] dan Boehm dan Turner. [14] Banyak kritik Namun, yang diyakini oleh praktisi untuk Agile kesalahpahaman yang akan Agile pembangunan. [26]

Secara khusus, Extreme Pemrograman dikaji dan critiqued oleh Matt Stephens dan Doug Rosenberg's Extreme Pemrograman Refactored. [27]

Kritik termasuk:
Sering digunakan sebagai alat untuk berkorban uang dari pelanggan melalui kurangnya mendefinisikan sebuah deliverable
Kurangnya struktur dan dokumentasi yang diperlukan
Hanya bekerja sama dengan para pengembang tingkat
Desain juga cukup perangkat lunak
Memerlukan pertemuan di interval sering di besar biaya untuk pelanggan
Memerlukan terlalu banyak perubahan budaya untuk mengadopsi
Dapat mengakibatkan lebih sulit negosiasi kontrak
Dapat menjadi sangat tidak efisien-jika persyaratan untuk satu kode area perubahan melalui berbagai Iterasi, pemrograman yang sama mungkin perlu dilakukan beberapa kali atas. Sedangkan jika telah ada rencana untuk diikuti, satu kode area yang diharapkan dapat ditulis sekali.
Mustahil untuk mengembangkan perkiraan realistis kerja diperlukan upaya untuk memberikan penawaran, karena pada awal proyek tidak seorangpun yang tahu seluruh lingkup / persyaratan
Dapat meningkatkan risiko lingkup merayap karena kurangnya rinci persyaratan dokumentasi
Agile adalah fitur driven, non-fungsional kualitas atribut sulit untuk ditempatkan sebagai pengguna cerita

Kritik yang cukup mengenai perangkat lunak desain dan kurangnya dokumentasi yang dialamatkan oleh Agile Modeling metode yang mudah disesuaikan ke dalam proses Agile.

Agile pengembangan software telah dikritik karena tidak dapat menghasilkan semua yang mengklaim manfaat ketika pemrogram dari rata-rata kemampuan menggunakan metode ini. [28]

Pasca-Agilism

Dalam rekayasa perangkat lunak, pasca Agilism adalah gerakan informal praktisi yang lebih memilih untuk menghindari yang dibikin oleh apa yang dianggap sebagai "Agile Dogma" (atau "Agile dengan modal 'A'")

Beberapa berpendapat bahwa ada maksud Agile adalah ambiguitas dan telah diterapkan yang sangat tidak tepat untuk berbagai macam pendekatan seperti Six Sigma dan CMMi (meskipun proponents Agile dari beberapa metode, seperti banyak orang, menunjukkan bahwa ada metode dapat nyaman dalam lingkungan CMMi .) [29] Beberapa ada juga berpendapat bahwa "Agile", "evolusi", dan "bersandar" (seperti dalam Lean pengembangan software) tidak berarti hal yang sama, dalam prakteknya, meskipun mereka semua di bawah lumped banner dari "Agile "dan sering digunakan oleh praktisi interchangeably.

Proponents juga menyatakan bahwa proses-berorientasi metode, khususnya metode yang bergantung pada hasil repeatable dan secara bertahap mengurangi limbah dan proses variasi seperti Six Sigma, ada kecenderungan untuk membatasi sebuah organisasi adaptif kapasitas (mereka "kendor"), membuat mereka kurang mampu untuk merespon untuk mengubah terputus-putus - iaitu, kurang Agile. It is proposed that "agile", "lean" and "evolutionary" are strategies that need to be properly understood and appropriately applied to any specific context. Diusulkan bahwa "Agile", "kurus" dan "evolusi" adalah strategi yang perlu dipahami dengan baik dan tepat diterapkan pada konteks yang spesifik. That is, there is a time to be "agile", a time to be "lean" and a time to be "evolutionary." Artinya, ada waktu untuk menjadi "Agile", waktu untuk menjadi "lean" dan waktu untuk menjadi "evolusi." Some agilists agree with this position, promoting the concept of agile methods as one set of tools that should be available to managers for use in appropriate situations, not as one-size-fits-all methods that should be forced onto all organizations. [ 30 ] Beberapa agilists setuju dengan posisi ini, mempromosikan konsep Agile metode sebagai satu set alat-alat yang harus tersedia bagi manajer untuk digunakan dalam situasi yang tepat, bukan sebagai satu-ukuran-cocok-semua metode yang terpaksa harus ke semua organisasi. [30 ]

Banyak dari pos-Agile berpikir sekitar pusat Nonlinear Manajemen, sebuah superset dari manajemen teknik yang meliputi Agile praktek.
Beberapa komentar mengusulkan sebuah model pasca Agilism yang efektif konstruktif anarki, dalam tim yang seharusnya mengorganisasikan diri ke titik dimana bahkan nilai-nilai inti dari Agile gerakan dianggap terlalu menentukan, dan bahwa tim seharusnya hanya "melakukan apapun untuk bekerja mereka. " This position is controversial in the agile community and breaks from the trend of later agile methods being more structured (fitting better within CMMi environments) than earlier agile methods. Posisi ini adalah kontroversial di masyarakat dan Agile istirahat dari kecenderungan nanti Agile metode yang lebih terstruktur (lebih tepat dalam lingkungan CMMi) dibandingkan sebelumnya Agile metode.