Tidak dapat memahami poin tertentu dalam Prinsip Agile Manifesto

24

Saya sedang membaca Prinsip Agile Manifesto . Semuanya tampak jelas dan masuk akal kecuali satu hal:

Kesederhanaan - seni memaksimalkan jumlah pekerjaan yang tidak dilakukan - sangat penting.

Saya tidak mengerti ini. Apakah ini berarti bahwa pekerjaan yang tidak dilakukan harus dibesar-besarkan? Jika demikian, itu tidak benar-benar masuk akal.

agile management

— superM
sumber

2

+1 untuk melawan suara turun - Anda memiliki pertanyaan yang sangat menarik di sini.

1

Juga lihat Wu Wei dan bayangkan bagaimana hal itu dapat diterapkan pada pengembangan perangkat lunak secara umum. Ini adalah perkembangan alami dari filosofi yang diungkapkan dalam pertanyaan Anda.

30

Hapus komentar kurung. Yang tersisa adalah "Kesederhanaan itu penting", yang merupakan penerapan prinsip untuk ekspresinya sendiri.

Kesederhanaan sangat penting, karena Anda telah menyaring apa yang benar-benar Anda butuhkan, menghilangkan apa yang membuat tugas lebih berat, kurang elegan: kompleks.

Saya selalu menafsirkan dalam pengertian Pascal tentang singkatnya : " Saya akan menulis surat yang lebih pendek, tetapi saya tidak punya waktu. " Anda harus menghindari apa yang tidak diawasi (dari surat, dari kode) dan ini adalah sebuah tugas aktif , dan tidak mudah. Itu bukan sesuatu yang terjadi dengan sendirinya.

— Francesco
sumber

35

Idenya adalah untuk menghindari melakukan pekerjaan yang tidak perlu, yaitu "memaksimalkan jumlah pekerjaan yang tidak dilakukan".

Jadi, jika dalam proyek tradisional Anda akan merencanakan dan membangun sistem basis abstrak yang bagus untuk memungkinkan semua kebutuhan Anda yang mungkin nanti, Anda hanya melewatkan itu dan membangun hal paling sederhana yang mungkin dapat bekerja untuk persyaratan saat ini . Jangan membuat barang yang tidak Anda butuhkan.

YAGNI adalah konsep terkait.

— Joachim Sauer
sumber

5

Secara kebetulan, ini mungkin prinsip gesit yang paling tidak saya setujui . Diambil ke ekstrem, tinjauan ke masa depan abstrak adalah apa yang memisahkan kita dari hewan lain ... Saya katakan kita perlu menggunakannya kapan saja kita bisa. Tentu saja aku tahu seperti apa kekejaman prinsip harus menjadi reaksi - tapi sedikit sedikit pandangan ke depan tidak akan menyakiti. Kadang-kadang itu YAGNI, tetapi saya telah melihat beberapa pengembang sangat dogmatis sehingga mereka tidak akan berhenti untuk berpikir beberapa jam ke depan (dan menyadari bahwa kesederhanaan yang mereka terapkan sekarang bahkan tidak akan cukup dalam 4-8 jam).

— Maks.

2

@ Max, saya pikir perlu untuk melihat kemungkinan perubahan di masa depan. Di sinilah pandangan jauh ke depan sangat membantu. Dan pengembang yang Anda gambarkan lebih seperti burung unta, yang bersembunyi di pasir.

— superM

7

Pelanggan @Max tidak ingin membayar untuk apa yang Anda pikir mereka mungkin perlu di masa depan, mereka ingin membayar untuk apa yang mereka perlu sekarang karena sesegera mungkin . Ada miliaran $$$ upaya sia-sia setiap bulan dengan niat baik "ini akan menghemat banyak waktu kemudian" dan bahwa "nanti" tidak pernah benar-benar datang, tetapi hal-hal yang kompleks, kereta dan terlambat karena semua itu "pandangan ke depan"

15

@ Max: YAGNI adalah tentang menunda keputusan hingga saat bertanggung jawab terakhir . Yang Anda bicarakan adalah menunda keputusan hingga saat terakhir yang mungkin , yang memang merupakan Ide Buruk ™. Masalahnya adalah: Anda tidak akan pernah memiliki informasi lebih sedikit untuk mendasarkan keputusan daripada yang Anda miliki sekarang. Dalam kasus terburuk, Anda akan memiliki informasi yang sama besok. Tetapi biasanya, Anda akan belajar sesuatu saat itu. Dalam kasus yang Anda sebutkan, Anda tahu bahwa Anda adalah akan membutuhkannya, sehingga YAGNI hanya tidak berlaku. Mencoba menerapkannya memang bodoh dalam hal itu.

— Jörg W Mittag

2

@ Max: Apa yang Anda gambarkan di sini adalah kebalikan dari memaksimalkan jumlah pekerjaan yang tidak dilakukan. Ini melakukan pekerjaan dua kali lebih banyak.

— pdr

5

Kami biasa menyebutnya "pelapisan emas". Persyaratan untuk palu adalah dapat menampar paku ke sepotong kayu. Itu tidak melakukan pekerjaan lebih baik untuk menjadi palu berlapis emas.

Berkali-kali seorang pengembang menyarankan menggunakan kerangka kerja keren baru atau menambahkan fitur yang meskipun tidak diperlukan. Kami akan mencatat ide ini, tetapi untuk versi ini kami tidak akan melakukannya. Kami akan memaksimalkan pekerjaan yang tidak dilakukan. Cukup sulit untuk mengirimkan perangkat lunak tepat waktu, jadi jangan berikan kode lebih dari yang Anda perlukan. Jika perlu dilakukan, pada akhirnya akan masuk dalam rencana dan dilakukan pada waktu yang tepat.

— Stuart Woodward
sumber

4

Gagasan ini sangat mirip dengan konsep dari Toyota Production System (TPS) , yang mengarah pada Lean Manufacturing yang lebih umum dan kemudian penerapan teknik-teknik tersebut untuk Pengembangan Perangkat Lunak Lean . TPS secara signifikan mendahului gerakan lincah, dengan akarnya di bidang manufaktur pada akhir 1950-an.

Konsep memaksimalkan jumlah pekerjaan yang tidak dilakukan mirip dengan menghilangkan limbah. Dalam lingkungan manufaktur, limbah mencakup hal-hal seperti kelebihan produksi barang, menunggu sumber daya, pergerakan orang atau produk yang tidak perlu, terlalu banyak inventaris, dan produk cacat. Dalam Pengembangan Perangkat Lunak Ramping, limbah ini diterjemahkan ke dalam fungsionalitas yang tidak perlu, keterlambatan dalam proses pengembangan, persyaratan tidak jelas yang memperlambat produksi perangkat lunak, kurangnya pengujian, dan keterlambatan komunikasi.

Ide keseluruhan dari kedua konsep adalah sama - hal-hal yang tidak menambah nilai boros dan harus diminimalkan. Tujuan utamanya adalah untuk meningkatkan kualitas sekaligus mengurangi waktu dan biaya untuk memproduksi.

— Thomas Owens
sumber