Pertanyaan Bagaimana Anda menghindari Utang Teknis sambil tetap setia kepada Agile, yaitu: menghindari pelanggaran YAGNI dan menghindari BDUF? [Tutup]


Utang Teknis via Martin Fowler, melalui Steve McConnell

YAGNI (Anda Tidak Akan Membutuhkannya) melalui Wikipedia

BDUF (Big Design Up Front) melalui Wikipedia

PEMBARUAN: Untuk mengklarifikasi pertanyaan, saya pikir saya juga dapat menyatakannya dengan cara ini dan menjaga artinya:

"Dalam hal apa Anda, sebagai seorang Praktisi yang lincah, menemukan keseimbangan yang tepat antara" cepat dan kotor "(tidak sengaja mempertaruhkan Hutang Teknis ketika mencoba untuk mematuhi YAGNI) dan over-engineering (BDUF) dalam setiap iterasi? "


10
2017-09-13 21:26


asal


Jawaban:


Tampaknya jika Anda tetap dengan "rencana, lakukan, adaptasi, rencanakan, lakukan, adaptasikan" gagasan agile (iterasi, ulasan iterasi) Anda akan menghindari hal-hal itu secara default. BDUF sangat bertentangan dengan gagasan estimasi & perencanaan tangkas bahwa jika Anda benar-benar gesit, Anda tidak akan BDUF secara otomatis.

Tujuan dari rapat perencanaan rilis & iterasi adalah untuk memastikan Anda menambahkan fitur yang paling berharga ke proyek untuk iterasi tersebut. Jika Anda mengingatnya, Anda akan menghindari YAGNI secara gratis.

Saya akan sangat menyarankan buku-buku Mike Cohn tentang perencanaan tangkas:

  1. Kisah Pengguna Diterapkan 
  2. Agile Estimating and Planning

Memperbarui:  Setelah klarifikasi Anda tentang menghindari YAGNI dan BDUF dalam iterasi ...

BDUF... Jika saya merasa fitur tidak didefinisikan dengan jelas sebelum saya mulai mengerjakannya, saya akan membuat "fitur" kecil atau cerita untuk menjelaskan bagian tipe desain dari pekerjaan yang diperlukan. Sehingga mungkin cerita yang lebih kecil memiliki titik cerita perkiraan 1 daripada fitur sebenarnya 5. Dengan begitu, desainnya dikotak waktu ke dalam cerita yang lebih kecil, dan Anda akan didorong untuk beralih ke fitur itu sendiri.

Menghindari melanggar YAGNI Saya akan bekerja sangat jelas tentang apa yang diharapkan pelanggan untuk fitur dalam iterasi. Lakukan saja pekerjaan yang memetakan apa yang diharapkan pelanggan. Jika Anda berpikir sesuatu yang ekstra harus ditambahkan, buat fitur baru untuk itu, dan tambahkan ke backlog pekerjaan harus dilakukan. Anda kemudian akan membujuk pelanggan untuk melihat manfaatnya; sama seperti pelanggan akan mendorong fitur yang dilakukan pada titik waktu tertentu.


4
2017-09-16 16:42



Anda sepertinya mengatakan bahwa "YAGNI" mengimplikasikan "cepat dan kotor". Saya tidak melihat itu.

Sebagai programmer tangkas, saya mempraktekkan pengembangan berbasis tes, peninjauan kode, dan integrasi berkelanjutan.

  • Test-driven development (TDD), sebagai proses, adalah cara yang baik untuk menghindari YAGNI. Kode yang ada di sana "dalam kasus ini akan berguna" cenderung belum diuji dan sulit untuk diuji.
  • TDD juga sebagian besar menghilangkan keharusan untuk BDUF: ketika proses Anda mulai dengan duduk dan mulai melakukan sesuatu yang benar-benar memberikan nilai, Anda tidak dapat menikmati BDUF.
  • TDD, sebagai praktik desain berarti bahwa desain besar akan muncul ketika Anda mendapatkan pengalaman dengan masalah, dan kode real refactor.
  • Integrasi berkelanjutan berarti bahwa Anda mendesain proses Anda sehingga produk Anda pada dasarnya dapat dilepas kapan saja. Itu berarti Anda memiliki proses kualitas terintegrasi yang mencoba mencegah kualitas garis utama menurun.

Menurut pengalaman saya, bentuk utama dari hutang teknis adalah:

  • Kode tidak dicakup oleh rangkaian uji otomatis. Jangan biarkan hal itu terjadi, kecuali untuk komponen yang sangat terlokalisasi yang sangat sulit untuk diuji. Kode yang belum teruji adalah kode rusak.
  • Kode jelek yang melanggar standar pengkodean. Jangan biarkan itu terjadi. Itulah salah satu alasan mengapa Anda perlu membangun tinjauan kode ke dalam proses integrasi berkelanjutan.
  • Kode dan tes yang berbau dan perlu refactoring agar lebih mudah dimodifikasi atau dipahami. Ini adalah bentuk hutang teknis yang jinak. Gunakan pengalaman Anda untuk mengetahui kapan harus mengakumulasinya, dan kapan harus membayarnya kembali.

Tidak yakin apakah itu menjawab pertanyaan Anda, tetapi saya senang menulisnya.

Troy DeMonbreun berkomentar:

Tidak, itu bukan maksud saya ... "cepat dan kotor" = (tidak sengaja mempertaruhkan Utang Teknis ketika mencoba untuk mematuhi YAGNI "). Itu tidak berarti YAGNI hanya cepat dan kotor. Ungkapan" cepat dan kotor "adalah apa yang saya mengutip Martin Fowler dalam uraiannya tentang Utang Teknis

Menghindari YAGNI adalah cara lain untuk mengatakannya CIUMAN. YAGNI meningkatkan hutang teknis. Tidak ada ketegangan antara menghindari YAGNI dan menjaga utang teknis tetap rendah.

Saya pikir saya mungkin masih kehilangan inti pertanyaan Anda.


2
2017-09-16 19:31



Ada diskusi menarik tentang Utang Teknis berdasarkan definisi Anda tentang HanselMinutes yang dilakukan beberapa minggu lalu - Apa yang Dikerjakan. Dasar-dasar acara adalah bahwa jika Anda mendefinisikan ulang 'Selesai' untuk meningkatkan kecepatan yang dirasakan, maka Anda akan mengumpulkan Utang Teknis. Konsekuensi dari ini adalah bahwa jika Anda tidak memiliki definisi yang tepat dari 'Selesai' maka kemungkinan besar Anda memperoleh daftar item yang perlu diselesaikan sebelum rilis terlepas dari metodologi desain.


2
2017-09-14 17:02



Saya menemukan Robert Martin Test Driven Development  (TDD) pendekatan membantu dengan masalah ini.

Mengapa?

  • Anda hanya perlu menulis kode yang cukup untuk lulus tes berikutnya.
  • Saya pikir kode yang dapat diuji lebih bersih.
  • Rancangan ini harus dimasukkan ke dalam pengujian yang dapat membantu menjaga desain tetap fokus.
  • Ketika Anda harus mengubah (refactor) Anda memiliki tes untuk jatuh kembali

Terlepas dari kapan tes ditulis (sebelum atau sesudah) saya menemukan tulisan tes membantu Anda membuat keputusan praktis. Misalnya, kami memilih desain A atau B karena A lebih bisa diuji.


1
2017-09-13 21:49



Jawaban XP 'tradisional' adalah refactoring yang dikombinasikan dengan pengujian unit otomatis.

Tapi itu pertanyaan yang sangat menarik secara filosofis. Saya tidak percaya Anda perlu melakukannya menghindari hutang teknis, simpan saja pada tingkat yang dapat dikelola. Artikel Steve McConnell baik untuk keseimbangan ini - alasan analoginya berhasil adalah bahwa hal itu normal dan dapat diterima untuk membangun utang keuangan di perusahaan, selama Anda menerima biaya dan risiko - dan utang teknis juga baik-baik saja.

Mungkin jawabannya sendiri juga terletak pada prinsip YAGNI. Anda Tidak Perlu Membayar hutang teknis sampai Anda melakukannya, dan saat itulah Anda melakukan refactor. Ketika Anda melakukan pekerjaan besar di area sistem dengan utang teknis, lihatlah berapa banyak perbedaan jangka pendek yang akan dilakukan untuk mendesain ulang. Jika itu cukup untuk membuatnya berharga, bayarlah. Saran McConnell untuk mempertahankan daftar hutang akan membantu Anda mengetahui kapan untuk membuat pertimbangan ini.

Saya kira tidak ada jawaban mutlak untuk ini - seperti banyak hal itu adalah penilaian berdasarkan pengalaman, intuisi dan analisis Anda dalam setiap situasi tertentu.


1
2017-09-13 22:01



Lakukan saja hal paling sederhana yang berhasil. Saya setuju dengan Ayende ketika dia mengatakan itu kunci menjadi lincah adalah "kirimkan, sering". Siklus rilis reguler seperti ini akan berarti bahwa tidak ada waktu untuk BDUF dan itu juga akan menghalangi pengembang dari melanggar YAGNI.


1
2017-12-22 23:50



Di mana saya bekerja, saya percaya cara kami menghindari utang adalah dengan memutar melalui siklus dengan cepat, yaitu menunjukkan fungsionalitas kepada pengguna akhir dan mendapatkan tanda bahwa itu harus didorong untuk menguji atau penolakan untuk mengatakan apa yang salah memberikan persyaratan yang diperbarui. Dengan melakukan ini berulang kali dalam suatu iterasi, banyak perubahan dapat ditemukan tentang apa yang diinginkan pengguna dengan mencoba ini dan itu.

Poin utamanya adalah untuk mencoba melakukan apa yang diinginkan oleh pengguna dengan melakukan lebih banyak hal yang melanggar YAGNI dan membawa BDUF sementara gagasan untuk memperbaiki persyaratan berulang kali merupakan inti dari Agile di pikiran saya.


1
2017-10-01 21:08



Itulah mengapa selalu lebih mudah untuk menulis "makalah acadamic" yang bagus yang berbicara tentang bagaimana pengembangan Agile itu baik, apa "praktik terbaik" dan seterusnya.

Itulah mengapa Anda menemukan banyak "insinyur yang cocok" yang membuat teknik rekayasa perangkat lunak baru.

Proses itu penting, menjaga praktik-praktik terbaik itu keren tetapi di atas hal lain, proses desain penggerak akal sehat. Perangkat lunak dikembangkan oleh orang-orang sehingga YAGNI benar-benar harus:

Saya mungkin tidak akan perlu tetapi mungkin saya akan karena dalam bisnis konkrit saya / perusahaan / departemen hal ini memang terjadi atau saya akan membutuhkannya tetapi saya tidak punya waktu yang tepat tidak cepat dan kotor untuk membuat uang tunai dan mempertahankan pekerjaan saya , atau saya mungkin membutuhkannya dan refactoring nanti akan menjadi sakit di pantat seharga 10 kali lebih banyak daripada hanya melakukannya sekarang dari awal, dan saya punya waktu SEKARANG.

Jadi gunakan akal sehat Anda, percayai atau percaya pada akal sehat orang-orang yang bekerja untuk Anda. Jangan mengambil setiap makalah akademis sebagai fakta yang terbukti, pengalaman adalah guru terbaik dan perusahaan Anda harus meningkatkan cara mereka atau membuat sesuatu dengan waktu dan pengalamannya sendiri.

Edit: Kebetulan, TDD adalah kebalikan dari YAGNI Anda sedang membangun tes sebelum bahkan mengetahui apakah Anda akan membutuhkannya. Serius, berhenti mendengarkan para akademisi !! Tidak ada cara ajaib untuk menghasilkan perangkat lunak.


0
2017-09-13 21:50



Tentunya gesit akan membuat TD Anda turun untuk proyek tertentu?

Kenyataan bahwa Anda menerapkan apa yang diinginkan pelanggan, yaitu dengan umpan balik mereka, menjaga TD tetap seminimal mungkin,


0
2017-09-13 22:30



Masalahnya mungkin sebenarnya berada pada tingkat yang lebih tinggi: dengan manajemen dan pemilik produk terkait dengan tenggat waktu yang bertentangan dengan pengembang itu sendiri.

Di tempat kerja terakhir saya, saya bekerja pada kode warisan tetapi berhubungan dengan orang-orang mengembangkan kode baru menggunakan (konon) Agile dan TDD.

Sekarang TDD seharusnya Red - Green - Refactor: menulis tes gagal, lakukan minimum untuk lulus tes, kemudian ulang kode untuk membuatnya lebih dipelihara sambil memastikan masih melewati tes.

Tapi... kemajuan diukur berdasarkan seberapa cepat kisah pengguna diterapkan, yaitu seberapa cepat fungsi baru ditambahkan. Hal tentang refactoring adalah tidak menambahkan fungsi baru apa pun. Ya, itu sangat penting tetapi tidak memiliki dampak langsung yang sama seperti menunjukkan pemilik produk fungsi baru atau bahkan baris kode pengujian untuk menyertainya.

Karena tenggat waktu semakin dekat, dan lembur menjadi standar, ada insentif untuk berhemat pada bagian refactoring. Semakin banyak yang melakukan hal ini, semakin cepat seseorang melalui cerita pengguna, yang sepertinya menjadi perhatian manajemen.

Sekarang ini melakukan menyebabkan hutang teknis karena pada beberapa kesempatan untuk mendapatkan cerita pengguna berikutnya dilakukan ternyata perlu untuk kembali dan refactor - benar-benar menulis ulang - kode untuk kumpulan cerita pengguna sebelumnya. Manajemen menjadi jengkel dalam hal ini karena dari sudut pandang mereka, cerita pengguna yang dipermasalahkan tidak terlihat berbeda dari yang sebelumnya, jadi mengapa perkiraannya 10 kali lebih lama?

(Ada aspek teori permainan yang buruk untuk hal-hal juga. Jika Anda atau tim Anda adalah berhati-hati tentang refactoring yang tidak mencegah Anda terjebak membersihkan setelah tim lain itu tidak. Tentu saja, tim lain itu tampak lebih baik karena mereka mendapatkan lebih banyak cerita pengguna dalam waktu yang sama.)

Maksud saya di sini adalah mungkin TDD tidak mengarah pada hutang teknis jika dilakukan dengan benar. Tetapi untuk itu harus dilakukan dengan benar harus ada pembelian asli dari yang lebih tinggi.


0
2017-08-08 22:39