Apakah mungkin menyebut diri Anda (atau tim Anda) dengan benar "Agile" jika Anda tidak melakukan TDD (Test-Driven Development)?

Ya, ya, ya, jutaan kali ya.

Agile adalah filosofi, TDD adalah metodologi khusus.

Jika saya ingin benar - benar pilih - pilih, saya hanya bisa menunjukkan bahwa ada beberapa variasi xDD - yang akan dijelaskan oleh advokat mereka secara mendalam bukan TDD - tetapi mereka masih terikat dengan tes terlebih dahulu sehingga akan curang.

Jadi mari kita katakan ini - Anda bisa gesit tanpa melakukan pengembangan "test first" (lihat cara scrum bekerja - tidak ada tempat di mana ada spesifik tentang bagaimana Anda menulis kode). Lihatlah papan kanban, lihat segala macam metodologi tangkas.

Apakah Anda ingin tes unit? Tentu saja Anda lakukan, untuk semua jenis alasan - dan Anda mungkin membuat argumen bahwa Anda tidak bisa gesit tanpa unit test (walaupun saya curiga Anda bisa) - tetapi Anda tidak harus menuliskannya terlebih dahulu untuk menjadi tangkas.

Dan akhirnya, sama-sama benar bahwa Anda bisa melakukan Tes Pertama tanpa menjadi Agile dan argumen yang kuat untuk melakukan tes pertama terlepas dari keseluruhan filosofi dev Anda.

Tampaknya orang lain (dengan rep yang lebih SOLID) memiliki pendapat yang sama ...

http://www.twitter.com/unclebobmartin/status/208621409663070208

@unclebobmartin: http://t.co/huxAP5cS Meskipun bukan tidak mungkin untuk melakukan Agile tanpa TDD dan OOD, itu sulit. Tanpa TDD, tingkat iterasi ...

(Tautan dalam tweet ini adalah jawaban lengkap di LinkedIn)

"Menjadi gesit" hanya berarti mengikuti nilai-nilai dan prinsip-prinsip manifesto tangkas . Tidak ada dalam dokumen yang menyebutkan TDD, atau bahkan pengujian unit untuk masalah ini.

Jadi ya, Anda bisa gesit tanpa melakukan TDD atau pengujian unit.

Saya tidak akan merekomendasikan ...

Ya ,

Lihatlah salah satu nilai lincah:

Individu dan interaksi atas proses dan alat

Itu seharusnya sudah menjawabnya. TDD adalah metodologi tertentu, suatu proses. Memang suatu proses yang mungkin bisa digunakan dalam proses pembangunan lincah, tetapi tidak lebih. Saya pikir mungkin TDD canggih sekarang ketika menjadi gesit. Tapi saya pikir konsep lincah masih akan bisa bertahan, bahkan jika mungkin TDD telah digantikan oleh praktik lain.

Saya akan menyimpulkannya seperti:

• Hari ini TDD adalah standar de facto untuk menjadi gesit

• Mungkin ada cara menjadi gesit tanpa TDD

Saya katakan

Tidak ada [semacam]

Jika Anda kembali ke sumber aslinya http://en.wikipedia.org/wiki/Extreme_Programming TDD adalah hal mendasar dalam prosesnya; tes menggantikan spesifikasi persyaratan dan kasus penggunaan air terjun, berfungsi sebagai dokumentasi hidup dan contoh berfungsi, dll. Mereka sangat diperlukan.

Namun, ada begitu banyak rasa 'lincah' yang beredar sekarang sehingga sangat mungkin bahwa salah satu dari mereka menghindari TDD

EDIT: @ interpretasi Murph tentang pertanyaan tampaknya menjadi yang disukai. Heck, saya bahkan mengangkatnya, itu jawaban yang bagus. Namun , saya mempertahankan posisi saya bahwa Agile Manifesto adalah seperangkat prinsip, bukan metodologi pengembangan. Saya melihat tidak ada gunanya mengatakan "oh ya saya gesit" tanpa benar-benar menerapkan praktik yang membawa manfaat. Khususnya:

Perangkat lunak yang berfungsi adalah ukuran utama dari kemajuan.

dan

Proses lincah mempromosikan pembangunan berkelanjutan. Sponsor, pengembang, dan pengguna harus dapat mempertahankan kecepatan konstan tanpa batas.

Bagi saya, kedua prinsip ini menyiratkan jika tidak memerlukan TDD - setidaknya saya tahu tidak ada cara lain untuk mencapainya tanpa itu!

EDIT 2: ya, secara teknis Anda dapat menulis tes sesudahnya; tapi saya masih menganggap test-first / TDD sebagai hal mendasar. Bukan karena Anda tidak bisa "gesit" tanpanya, tetapi karena Anda akan lebih gesit dengannya. Test-first / test-driven adalah pendekatan yang jauh lebih efisien daripada test-later / test-afterthought. Deskripsi tes adalah persyaratannya . Jangan menunda sampai nanti ;-)

EDIT 3: Saya akhirnya menemukan apa yang mengganggu saya tentang jawaban Murph yang ditulis dengan sangat baik. Gagasan bahwa seseorang bisa "gesit" tanpa benar - benar melakukannya . Dan "melakukannya" (seperti yang ditunjukkan di atas) cukup banyak membutuhkan TDD.

Ketat, Anda gesit dengan mengikuti manifesto tangkas . Dalam praktiknya, basis kode tidak gesit kecuali memiliki cakupan pengujian yang baik. Anda dapat melakukan TDD dan menulis tes sebelum / selama pengembangan fungsionalitas atau menulis tes untuk fungsionalitas setelah dikembangkan. Biasanya lebih mudah dan lebih efektif untuk melakukannya dengan cara TDD.

Anda bisa gesit, tetapi mungkin ada ruang untuk perbaikan.

Salah satu prinsip gesit adalah bahwa Anda harus mampu merespons perubahan. Ini berarti tidak tahu sebelumnya apa yang harus Anda bangun. Jika Anda mengikuti proses air terjun, Anda akan tahu x bulan sebelumnya apa yang Anda butuhkan untuk membangun, dan Anda dapat merancang komponen perangkat lunak individual sehingga mereka masing-masing mengambil bagian dalam skema yang lebih besar, mencapai produk akhir (setidaknya Anda akan berpikir bahwa begitu). Tetapi karena agile menentukan bahwa Anda tidak tahu apa produk akhirnya, Anda tidak pernah tahu untuk apa kode Anda akan digunakan, dan yang lebih penting, kapan akan diubah.

Oleh karena itu Anda memerlukan rangkaian uji menyeluruh untuk memastikan bahwa fitur yang sudah Anda buat terus berfungsi ketika basis kode dimodifikasi.

Tapi itu sendiri bukan TDD. Jika Anda menulis tes setelah Anda menulis kode, itu bukan TDD. Tapi TDD membantu dengan aspek lain, itu mencegah kelebihan produksi.

Dalam tim tangkas saya sendiri, saya telah berjuang dengan pengembang menulis kode yang mereka percaya akan berguna nantinya dalam proyek. Seandainya itu pengembangan air terjun yang mungkin akan baik-baik saja, karena mereka menambahkan dukungan untuk sesuatu dalam rencana proyek untuk x bulan berikutnya.

Tetapi jika Anda mengikuti prinsip-prinsip lincah Anda tidak boleh menulis kode ini, karena Anda tidak tahu apakah itu akan diperlukan. Fitur yang direncanakan untuk minggu depan tiba-tiba dapat ditunda tanpa batas waktu.

Jika Anda mengikuti prinsip TDD dengan benar, maka satu baris kode tidak dapat ada sebelum tes menentukan baris kode ini (secara pribadi saya dapat menulis beberapa kode sepele tanpa pengujian), dan jika Anda mulai dengan menulis tes penerimaan, maka Anda hanya menerapkan persis apa yang dibutuhkan untuk menghadirkan fitur yang diperlukan.

Jadi TDD membantu menghindari kelebihan produksi, memungkinkan tim menjadi seefektif mungkin, yang juga merupakan prinsip lincah inti.

Perangkat lunak yang berfungsi adalah ukuran utama dari kemajuan

Bisakah Anda gesit tanpa melakukan TDD (test driven development)?

Jawaban singkat: Ya.

Jawaban yang lebih panjang: Sudah ada banyak jawaban yang sangat bagus untuk pertanyaan ini dan referensi yang sangat bagus. Saya tidak akan mencoba memperdebatkan poin-poin itu.

Dalam pengalaman saya, Agile adalah tentang memilih tingkat Lean-ness yang tepat untuk proyek yang sedang dikerjakan. Apa yang saya maksud dengan Lean-ness? Dan, mengapa saya membawanya ke jawaban ini?

Lean tidak berarti memotong segala sesuatu yang mungkin dari metode Anda. Seperti yang dicatat oleh salah satu rekan kami, Anda tidak harus memasukkan TDD atau Tes Unit ke dalam perilaku Anda. Namun, dalam konteks proyek Anda menemukan diri Anda, itu mungkin bermanfaat atau tidak.

Mari kita pikirkan rantai pasokan untuk pengecer besar tanpa nama yang berlokasi di AK. Ada konsumennya. Mereka pergi ke toko. Toko menerima berbagai produk melalui truk. Truk-truk itu, mungkin, mengambil produk-produk itu dari gudang. Gudang diisi oleh pengiriman dari berbagai produsen. Pabrikan pada gilirannya memiliki seluruh rantai pasokan sendiri.

Apa yang terjadi ketika manajer umum untuk pengiriman dalam rantai pasokan di atas diberitahu bahwa ia akan mendapat bonus tahunan $ 1 juta untuk setiap tahun bahwa ia memiliki kurang dari 10 truk dalam armada? Dia akan segera memotong armada menjadi 9 truk. Dalam skenario "mengerikan" ini, ini akan menaikkan jumlah barang yang disimpan di gudang (menaikkan biaya di simpul itu). Dan, itu akan "kelaparan" bagian depan toko.

Jadi, keseluruhan rantai pasokan menderita jika optimisasi lokal diizinkan tanpa pertimbangan keseluruhan.

Kembali ke TDD dan UT. TDD adalah mekanisme ekspresi persyaratan. Sistem HARUS melakukan kendala tersebut. Cukup adil. TDD dapat mengganti perilaku persyaratan Use Case Drive Development atau perilaku persyaratan User Story Driven Development. Ini memiliki "condong" manfaat menggabungkan Uji Unit dan Persyaratan beban kerja. Merupakan keuntungan jika beban kerja keseluruhan dikurangi. Tidak, jika beban kerja keseluruhan rantai pasokan meningkat (mari kita perbaiki kualitas).

Jadi, Anda bertanya: Bisakah Anda Agile tanpa melakukan TDD (test driven development)?

Tentu kamu bisa. Sebuah pertanyaan yang berbeda, dan mungkin lebih baik, adalah: - Jika saya menerapkan TDD pada proyek ini, apakah ini akan menghasilkan pengiriman perangkat lunak yang lebih efisien secara keseluruhan atau kurang efisien?

Mengutip penulis favorit ... JRR Tolkien

Lord of the Rings. Persekutuan Cincin. Hal 94 'Dan juga dikatakan', jawab Frodo, 'Jangan pergi ke peri untuk meminta nasihat, karena mereka berdua tidak akan dan ya.'

Jadi, pada akhirnya, ... itu tergantung. Anda harus menjawab pertanyaan itu. Jalur mana yang paling efisien akan mengarahkan Anda ke tujuan yang Anda inginkan.

Ke TDD atau tidak ke TDD. Itu tetap menjadi pertanyaan. :-)

PS - Saya memposting ulang jawaban ini di situs lain juga. https://www.ibm.com/developerworks/mydeveloperworks/blogs/c914709e-8097-4537-92ef-8982fc416138/?maxresults=15&sortby=4&lang=en

Dibandingkan dengan rekayasa kastil.

Kastil Agile

Jika Anda seorang insinyur kastil menggunakan Agile. Anda akan menulis bagian-bagian yang memiliki fungsi spesifik dan mendorong pengguna untuk menggunakan bagian-bagian fungsional, menyesuaikan desain masa depan dengan reaksi-reaksi pengguna. Jadi, Anda membangun penjara bawah tanah, dan berkomunikasi dengan penjaga penjara bawah tanah, Anda akan menguji fondasi yang disediakan oleh tanah dan penjara bawah tanah. Anda akan membangun tembok pembatas dan bertanya kepada penjaga malam apakah itu bagus. Anda akan membangun tembok dan meminta tentara menguji nilai pertahanan. Anda akan membangun dapur dan meminta koki memeriksanya. Dan selama proses ini, setiap bagian hingga saat ini akan berfungsi di samping struktur saat ini. Jadi, ketika Anda selesai di ruang bawah tanah, Anda bisa memindahkan para tahanan. Dan seterusnya. Tetapi ketika Anda akhirnya menyelesaikan kastil, Anda menemukan para tahanan melarikan diri.

Kastil TDD

Dengan TDD, Anda muncul bersama para tahanan, dan melihat apakah mereka melarikan diri. Kemudian Anda menulis sel penjara sampai mereka tidak bisa melarikan diri. Kemudian, Anda akan melakukan refactor kode dengan bersih menghapus sel yang tidak dibutuhkan, dan menghapus bar yang berada di lokasi yang salah, dan menguji lagi. Tahanan tidak melarikan diri. Anda tidak harus berkomunikasi dengan kepala penjara. Dan Anda bisa mengirimkan seluruh kastil setelah Anda menyelesaikan semuanya. Pada saat itu kepala penjara mengatakan bahwa penjara bawah tanah membutuhkan lebih banyak sel, dan sekarang Anda harus menggali lebih banyak fondasinya.

Kastil TDD Agile

Jika Anda menggabungkan Agile dan TDD. Anda akan melihat apakah para tahanan melarikan diri, lalu bertanya kepada kepala penjara apa yang dibutuhkan. Dia mengatakan kamu membutuhkan lebih banyak sel. Anda akan mengambil beberapa orang acak untuk berpura-pura menjadi tahanan dan melihat apakah mereka melarikan diri. Jika tidak, maka Anda menunjukkannya ke kepala penjara, dan dia senang dengan itu. Kemudian Anda mulai membangun tembok pembatas.

Kesimpulan

Jadi keduanya memecahkan masalah yang berbeda. Agile membantu dengan mengubah persyaratan berdasarkan penemuan kebutuhan pengguna karena mereka melihat produk berkembang pada titik dalam proses yang paling mudah untuk beradaptasi. Ini melibatkan melepaskan penambahan stabil yang dipecah dari desain keseluruhan.

TDD memecahkan masalah mengantisipasi kegagalan. Menemukan dan memperbaiki kegagalan saat terjadi pada suatu titik dalam proses yang paling mudah untuk diperbaiki. Ini melibatkan pengujian unit de-coupled yang stabil dari kode yang dipecah dari desain keseluruhan.

Sangat mudah untuk melihat TDD sebagai ekstensi untuk Agile, karena keduanya mengikuti pola yang sama, kemajuan unit didorong dan ulasan. Perbedaannya adalah bahwa unit-unit dalam Agile berfungsi secara eksternal hingga saat ini secara keseluruhan, sedangkan unit-unit dalam TDD berfungsi sebagai bagian, dan mungkin tidak menghasilkan produk yang berfungsi untuk peninjauan eksternal. Dan kedua proses mengatur kebutuhan yang berbeda (kegunaan vs kebenaran). Karena keduanya berfungsi atas proses pengembangan dalam unit, kedua proses peninjauan dapat terjadi pada titik yang sama, dengan TDD yang lebih halus dibagi.

Catatan

• Memiliki unit test saja tidak berarti Anda menggunakan TDD. TDD berarti melakukan tes sebelum unit yang diproduksi, dan menggunakan tes saat Anda mengembangkan untuk mengkonfirmasi unit. Pengujian unit tanpa TDD dapat digunakan untuk memastikan Anda tidak membatalkan fungsi yang dibangun sebelumnya.
• Memiliki sprint dan rapat lainnya tidak membuat Anda gesit. Tujuan dari manifes membuat Anda lincah. Anda dapat memecah tujuan air terjun menjadi sprint dengan unit-of-work, tanpa memenuhi komitmen untuk mendukung orang-orang dari proses.
• Secara definisi TDD dan Agile. Unit-tes Anda akan mengatur unit yang tidak dapat dikirim, dan TDD akan berputar lebih cepat daripada Agile. Dan jika Anda menggunakan keduanya, siklus Agile Anda akan mengandung satu atau lebih siklus TDD (jika setiap unit diuji).
• Dari apa yang saya mengerti: Anda gagal Agile dengan gagal mengembangkan unit yang dapat disampaikan / bermakna bagi pengguna. Unit dapat bermakna bahkan jika itu mempercepat produk. Tetapi bagaimana Agile menjelaskan refactoring untuk perawatan yang lebih mudah? Saya belum cukup membahasnya untuk menjawab itu.
• Anda gagal TDD dengan gagal tes unit. Memproduksi kode yang tidak menghasilkan fitur dengan benar.

Agile memaksa Anda untuk mengatasi dan mengurangi jadwal dan risiko kualitas di setiap iterasi. yaitu TDD tidak perlu dianggap Agile .

Namun, TDD adalah teknik luar biasa untuk mengurangi risiko kualitas, terutama untuk proyek dengan sejumlah besar pengulangan atau orang. Dalam proyek semacam itu, TDD akan menambahkan beberapa risiko jadwal dalam iterasi awal, karena Anda juga harus menulis kasus uji. Namun, TDD menghasilkan penghematan biaya besar dalam iterasi selanjutnya karena terus mengurangi risiko kualitas. yaitu TDD direkomendasikan.