Tim Scrum tidak mengikuti prinsip YAGNI


13

Pada pertemuan SCRUM, tim produk berdebat tentang fitur pada API yang akan dikonsumsi oleh aplikasi seluler. Kami memiliki mock up yang menunjukkan bagaimana tampilan layar dan elemen kunci apa yang harus dikandungnya ("tata letak").

Berdasarkan hal ini dan diskusi yang saya lakukan dengan pemilik produk, saya membuat prototipe untuk respons API (HAL + JSON). Itu sangat sederhana, JSON-compliant-HAL yang tidak lebih dari mewakili hal-hal yang ada di maket. Saya tidak terpengaruh oleh ide-ide masa depan yang diramalkan oleh para pebisnis karena mereka cenderung sering mengubah ide-ide mereka dan saya memutuskan untuk mengambil pendekatan minimalis. Proposal saya ditolak oleh tim dan saya kalah suara 7 banding 1.

Tim memutuskan untuk menggunakan struktur json abstrak non-semantik yang lebih kompleks, yang memungkinkan lebih banyak fleksibilitas dalam mengatur tata letak. Kelemahan dari pendekatan itu adalah kita berakhir dengan satu set objek seragam yang mungkin memiliki sifat nol dan kosong berdasarkan desain. Mereka juga berpikir akan lebih baik untuk membuat pengujian A / B menjadi mungkin, namun itu didasarkan pada prediksi mereka hanya karena kami tidak memiliki persyaratan seperti itu.

Sebagian besar waktu kami berdebat tentang hal-hal yang bukan bagian dari sprint atau disebutkan di maket. Masalah yang dijelaskan adalah "bagaimana jika pemasaran di masa depan akan ...", "bagaimana jika bisnis mungkin ingin kita ...".

Saya dan pemilik produk adalah programmer berpengalaman dan kami telah melihat masalah seperti ini di masa lalu. Kami mencoba mengikuti prinsip YAGNI dan KISS . Anggota tim lainnya kurang berpengalaman dan meskipun mereka tahu prinsip-prinsip ini, mereka tampaknya tidak memahaminya.

Kami menyetujui solusi mereka karena tim secara keseluruhan lebih penting bagi kami dan kami tidak ingin memperebutkan sesuatu yang tidak terlalu penting. Tapi saya khawatir jika hal seperti itu bisa menjadi preseden untuk debat yang lebih rumit dan lebih rumit? Bagaimana cara menghadapi perilaku seperti itu? Adakah sesuatu yang saya, sebagai pemimpin tim, dapat lakukan lebih baik?

Perlu disebutkan bahwa produk tersebut adalah MVP tahap awal.


11
I'm afraid if such thing can become a precedence for upcoming, more complicated debates?- Itu juga melanggar YAGNI: mengkhawatirkan masa depan yang mungkin tidak terjadi. Jika Anda akan berdiri tegak, Anda seharusnya sudah melakukannya.
Robert Harvey

@gnat: Ini sepertinya bukan tentang batasan waktu.
Robert Harvey

Apakah menjadi HAL-Compliant tidak tunduk pada YAGNI?
Matius

@Matthew semuanya memakan waktu satu minggu dan saya juga menyiapkan prototipe lain menggunakan JSON polos hanya untuk menyingkirkan HAL, tetapi juga ditolak dilihat sebagai "tidak cukup fleksibel". Tim memodifikasinya dan versi modifikasi akhirnya digunakan. HAL bekerja untuk kita sebagai standar, seperangkat pedoman, dan lebih mudah bagi saya untuk menegakkan struktur yang seragam di semua titik akhir. API sebelumnya tidak menggunakan standar apa pun dan itu tidak berakhir dengan baik.
Jacek Kobus

5
Fleksibilitas menambah kompleksitas. Selama tim memahami itu, seseorang dapat bergerak maju.
Jon Raynor

Jawaban:


10

Saya merasakan sakit Anda, telah ada di sana. IMHO masalah semacam ini disebabkan oleh fakta bahwa Anda memiliki tim yang terdiri dari 8 orang, yang sudah terlalu besar untuk membiarkan Anda selalu mengambil keputusan strategis terbaik.

Dalam tim dengan ukuran 8 atau lebih peluang tinggi jumlah programmer biasa-biasa saja lebih tinggi dari jumlah yang berpengalaman. Itu sering akan mengarah pada situasi di mana keputusan yang lebih baik dikalahkan oleh yang biasa-biasa saja. Kedengarannya tidak memuaskan, terutama ketika Anda (atau berpikir Anda) salah satu dari orang-orang yang lebih berpengalaman, tetapi setidaknya hal yang sama sering benar untuk keputusan yang benar-benar buruk.

Faktanya adalah, tidak banyak yang dapat Anda lakukan tentang hal itu selama tim tidak berubah , setidaknya jika semuanya tetap demokratis, jadi

  • belajar untuk hidup dengannya
  • bekerja dengan tim selama satu atau dua tahun, berbagi keahlian Anda sendiri dan berharap mereka mengetahui nilai YAGNI dan KISS dari waktu ke waktu
  • kerjakan keahlian Anda sendiri dalam desain "penjualan" atau keputusan strategis kepada tim
  • cobalah untuk beralih ke tim yang berbeda (mungkin lebih kecil) di mana tingkat keahlian Anda lebih dekat dengan rata-rata seluruh tim

Saya pikir satu-satunya cara untuk belajar dan memahami nilai nyata dari pendekatan minimalis dan YAGNI adalah dengan membuat beberapa pengalaman secara langsung. Misalnya, dengan terlibat dalam pemeliharaan sistem warisan dengan banyak prediksi "bagaimana jika" yang salah, keputusan desain yang salah dimotivasi oleh argumen "berjaga-jaga", atau mengandung banyak kode kerangka kerja yang digeneralisasikan secara luas yang sebenarnya tidak pernah diperlukan. Tapi itu bukan apa-apa yang bisa Anda ajarkan kepada anggota tim Anda dalam dua hari, beberapa pengalaman yang orang harus buat sendiri.


5
Kebanyakan orang harus menyentuh kompor untuk mengetahui bahwa kompor itu panas dan bukan untuk menyentuhnya. Perangkat lunaknya hampir sama. ++
RubberDuck

2
Menyimpan log proyek / buku harian adalah kunci untuk hal semacam ini. Setelah Anda mencatat berbagai diskusi yang telah terjadi, mereka jauh lebih konkret daripada ingatan orang akan percakapan berbulan-bulan atau bertahun-tahun kemudian. Ada pertanyaan bagus tentang latihan di sini .
Robbie Dee

@RobbieDee: tentu, jika itu membantu tim untuk belajar tentang YAGNI dan KISS.
Doc Brown

3
Peluru ke-3 (mengerjakan keterampilan Anda sendiri dalam "menjual" suatu desain) tidak mendapatkan perhatian yang cukup. Itu sebabnya pengembang masih perlu memiliki (atau mengerjakan) keterampilan komunikasi yang baik.
Randall Stewart

@RallallStewart: tentu saja. Tetapi bahkan dengan keterampilan komunikasi terbaik sekalipun, sulit untuk menjual YAGNI kepada orang-orang yang belum membuat pengalaman sendiri, atau mengacaukannya dengan "cepat dan kotor", atau dididik bahwa "abstraksi itu (selalu) baik" dan jadi cobalah untuk hal-hal abstrak demi abstraksi alih-alih demi penyederhanaan. Komunikasi membutuhkan dua sisi - satu yang dapat menjelaskan hal-hal dengan baik, dan satu yang mau mendengarkan dan memahami.
Doc Brown

8

Kompatibilitas ke depan adalah masalah yang sah

Jika salah satu dari tujuh pengembang yang mengungguli Anda adalah arsitek, itu adalah haknya untuk memperkenalkan NFR sesuai kebutuhan, dan salah satu dari NFR tersebut dapat menjadi "kompatibilitas maju," terutama ketika Anda mendukung komponen sistem jarak jauh yang mungkin memiliki komponen yang jauh lebih jarang. jadwal rilis. Anda tidak ingin pengguna harus menginstal versi baru aplikasi karena Anda tidak berpikir ke depan.

Seperti persyaratan lain, Anda memerlukan kriteria penerimaan

Karena itu, setiap NFR harus didokumentasikan sebagai persyaratan dan harus memiliki kriteria penerimaan yang ditentukan . Selain itu, Anda harus menemukan cara untuk mengujinya . Itulah sebabnya YAGNI penting - Anda tidak ingin menulis kode yang tidak dapat diuji, dan jika satu-satunya tujuan kode adalah untuk mendukung fitur yang tidak digunakan oleh siapa pun, sulit untuk menguji.

Seharusnya bukan panggilan penilaian

Saya akan menyarankan Anda meminta tim untuk menyetujui persyaratan tak terucapkan yang tampaknya Anda lewatkan dan tuliskan. Setelah Anda menentukan cara mengujinya, implementasi Anda harus gagal setidaknya satu tes dan karena itu seharusnya tidak menjadi masalah pemungutan suara.


1
Di mana dalam pertanyaan yang Anda baca bahwa tim OP meninggalkan jalur YAGNI karena persyaratan kompatibilitas ke depan?
Doc Brown

Maju kompatibilitas untuk apa Content-Typeheader
Jack

2
Saya bersedia menyebutnya sesuatu yang lain jika Anda mau, mungkin diperpanjang. Intinya sama; itu masih merupakan NFR.
John Wu

1
Ada dua cara untuk membuat sistem bisa diperluas. Cara pertama adalah mencoba meramalkan banyak kemungkinan perubahan persyaratan dan membuat banyak hal dapat dikonfigurasi "untuk berjaga-jaga". Saya yakin orang dapat menciptakan banyak tes penerimaan untuk jenis diperpanjang ini. Atau, menjaga hal-hal sesederhana mungkin, sehingga basis kode tetap kecil, mudah dipahami, dan poin ekstensi atau abstraksi dapat ditambahkan kemudian ketika mereka benar-benar dibutuhkan. Yang terakhir bukanlah apa-apa yang dapat Anda (atau perlu) tulis untuk tes. Jadi saya tidak berpikir ini bisa diselesaikan dengan mudah dengan "menulis NFR tak terucapkan" ...
Doc Brown

... jadi ini lebih lanjut tentang bagaimana menahan tim yang mungkin merupakan pengembang kreatif dari membuat asumsi tentang NFR dan menciptakan beberapa.
Doc Brown

3

Sepertinya tim pengembangan Anda sedang berusaha memfasilitasi tim produk dengan menciptakan kerangka kerja yang memungkinkan mereka melakukan uji coba cepat, yang tampaknya benar-benar ingin dimiliki oleh tim produk. Pendekatan Anda lebih seperti "benar-benar memberi mereka apa yang mereka minta dan tidak berpikir untuk mereka".

Jika saya adalah pemilik produk, saya bertaruh saya akan jauh lebih bahagia dengan tim pengembangan mengambil pendekatan pertama daripada yang terakhir.


3
+1 mengantisipasi dan merencanakan perubahan bukanlah hal yang sama dengan pergi astronot arsitektur penuh dan menciptakan platform batin . Sedikit pekerjaan dasar saat ini dapat mencegah banyak pekerjaan di masa depan. Sementara tim OP mungkin condong terlalu banyak ke arah hipotesis, pendekatan YAGNI fundamentalis tentu saja kurang optimal.
amon

4
Kedengarannya lebih Anda akan dengan senang hati mengungguli OP dan membuat kesalahan yang sama dalam perencanaan untuk "bagaimana jika pemasaran di masa depan akan .." daripada tim lainnya. Ketika orang mulai membangun kerangka kerja alih-alih perangkat lunak aplikasi ketika tugasnya adalah membangun perangkat lunak aplikasi, mereka hampir selalu melakukan kesalahan.
Doc Brown

@DocBrown Secara teknis saya setuju. Namun kasus ini tampaknya tentang kesediaan untuk memfasilitasi versus menuntut rasa hormat pribadi. Menjadi "benar" di satu sisi versus berguna atau membantu di sisi lain. Apa yang saya baca di sela-sela adalah bahwa OP kehilangan arah dan memilih untuk meningkatkan egonya dengan menggarisbawahi pengalamannya kepada khalayak daring alih-alih berkontribusi dalam lingkungan yang tidak nyaman baginya lagi. Dinamika ini tipikal untuk pengenalan scrum.
Martin Maat

@ MartinMaat saya sedikit kecewa dengan fakta bahwa mereka tidak setuju dengan saya. Saya tidak mengerti mengapa itu terjadi. Selama pekerjaan sehari-hari saya membantu mereka dengan ulasan kode dll. Kami sering berdebat tetapi saya menyukainya, karena hasil akhirnya lebih baik; Saya tahu mereka menghargai pendapat saya; Saya selalu mencoba menggunakan argumen yang valid yang mendukung teori saya. Pada akhirnya mereka memilih opsi terbaik dan juga bertanggung jawab untuk itu. Tim melakukan apa yang seharusnya dilakukan - mereka memecahkan masalah. Adalah kesalahan saya dan pemilik produk, bahwa masalah itu terlalu luas dan tidak dijelaskan dengan baik sejak awal.
Jacek Kobus

2

Nah, pendapat saya adalah demokrasi tidak berfungsi dengan baik - baik dalam sistem politik, maupun dalam tim di mana kebanyakan programmer adalah junior atau biasa-biasa saja.

Kata-kata Anda, sebagai pemimpin tim, dan salah satu orang paling berpengalaman dalam sebuah tim, harus memiliki dampak yang lebih tinggi daripada anggota tim lainnya. Jika YAGNI penting bagi Anda, maka Anda harus membuat presentasi tentang itu. Diskusikan tentang hal itu, dan tunjukkan kepada mereka mengapa itu baik.

Lagi pula, tanggung jawab Anda lebih tinggi daripada orang lain. Bukan hanya menulis kode, tetapi juga membimbing orang.


3
Demokrasi mungkin merupakan penyebab masalah di sini, tetapi tidak menjadi demokratis adalah IMHO bukan solusi, karena dapat dengan mudah memperkenalkan masalah yang lebih besar daripada yang dijelaskan dalam pertanyaan - itu sebenarnya dapat merusak tim.
Doc Brown

@DocBrown Anda baru saja berkontradiksi dengan kalimat yang sama. IMO beberapa keputusan tidak terserah orang untuk memutuskan. Yang dijelaskan OP adalah salah satunya. Mengutip Armstrong untuk orang yang tidak menggunakan YAGNI: Anda menginginkan pisang, tetapi yang Anda dapatkan adalah gorila yang memegang pisang dan seluruh hutan
BЈовић

2
Tidak, ini bukan kontradiksi (mungkin saya tidak menyatakan maksud saya dengan baik). Segala sesuatu tidak selalu "hitam dan putih". Hanya karena demokrasi tidak berfungsi dengan baik dalam beberapa situasi, menjadi tidak demokratis bukanlah jaminan untuk memperbaiki situasi dan membuat segalanya menjadi lebih baik. Seringkali tidak sesederhana itu.
Doc Brown

1
Dengan demokrasi Anda tidak perlu mendapatkan hal yang "benar" yang Anda dapatkan dari hal yang disetujui sebagian besar orang. Dan ini bisa salah. Dan seringkali hal yang "benar" memiliki masalah dengan penerimaan sosial. YAGNI seharusnya tidak menjadi borgol yang akan menghalangi Anda untuk memperkenalkan abstraksi yang tepat yang akan memungkinkan Anda untuk dengan mudah menambahkan "gorila" atau "seluruh hutan" jika diperlukan.
oopexpert

@oopexpert Masalahnya adalah: Anda mungkin membutuhkannya. YAGNI berbicara menentang lebih dari rekayasa. Abstraksi yang tepat adalah satu hal, menambahkan hal-hal yang mungkin tidak Anda perlukan adalah masalah yang berbeda.
BЈовић

2

Menurutnya ada sedikit kebingungan tentang YAGNI.

Pengembang sering berpikir mereka mengikuti YAGNI ketika mereka menghilangkan abstraksi yang akan membuat sistem "tertutup untuk modifikasi dan terbuka untuk ekstensi".

Kecuali Anda tidak "memperluas" sistem dengan fungsionalitas yang "jelas" tidak diminta, Anda tidak berurusan dengan YAGNI. Memperkenalkan abstraksi di mana perluasan mungkin terjadi adalah "kompatibilitas maju" yang telah disebutkan.

Pendapat pribadi saya adalah bahwa hanya pengetahuan mendalam tentang domain yang akan membantu membuat keputusan abstraksi dan di mana menemukannya.


2

Masalah dengan YAGNI DAN CIUMAN adalah bahwa mereka sepenuhnya subjektif dan tidak jelas.

json ?? YAGNI! cukup kirim string csv!

benda ?? KISSTUPID !!! gunakan saja goto !!

Peran 'Pemimpin Tim' tidak terdefinisi dengan baik, tetapi saya menyarankan agar Anda menjauhkan diri dari mengekspresikan pendapat subjektif pada pilihan teknis tim Anda. Bahkan jika Anda merasa mereka salah. Menempel daftar singkat persyaratan yang jelas.

  • unit test untuk kode
  • tes integrasi untuk apis
  • tes UI otomatis untuk produk akhir
  • persyaratan kinerja dan penskalaan

jika tim dapat mencapai lulus ujian untuk semua persyaratan bisnis dan kinerja dasar pada skala persyaratan teknis Anda memiliki produk yang berfungsi.

Setelah itu hanya mendorong untuk melakukan hal yang sama tetapi lebih cepat


1

Setiap orang dalam tim harus menyetujui definisi yang dilakukan . Tanpa ini, Anda cenderung merayap dalam jumlah besar, sudut pandang, dan bastardisasi persyaratan inti.

Apa pun yang dikirim di atas dan di atas ini harus ada di dalam simpanan yang dengan sendirinya juga akan memiliki definisi sendiri.

Adapun prioritas, metode MoSCoW selalu melayani kami dengan baik - YMMV.


1

Pikiran pertama saya tentang ini adalah ... Mengapa tim prihatin tentang perubahan? Apakah mereka memiliki pemahaman historis tentang Pemilik Produk yang membuat mereka merasa perlu membangun solusi pertama agar sedikit lebih dapat dikonfigurasi untuk membuat peningkatan di masa mendatang lebih mudah? Jika solusi Anda akan memakan waktu 2 hari, dan mereka 5 hari, ya, itu sudah dua kali lebih lama. Tetapi jika perubahan rencana Anda akan memakan waktu 2 hari setiap kali, tetapi peningkatan untuk mereka akan memakan waktu 1 hari, rencana mereka tampaknya lebih efisien dalam jangka panjang. Saya tidak berpikir ada keputusan yang BENAR atau SALAH dalam pertanyaan ini. Itu tergantung pada faktor-faktor lain, IMHO. Namun, Anda BENAR tentang pola pikir ini jika pada solusi lain mereka menggandakan LOE tanpa bimbingan langsung untuk melakukan itu (beberapa bukti bahwa kompleksitas tambahan diperlukan untuk skalabilitas, ketahanan, dll). Saran saya adalah untuk membawa pemilik produk ke dalam percakapan ini, karena mereka perlu membantu memprioritaskan. Jika solusi Anda adalah 5 poin, dan itu akan memenuhi kebutuhan sekarang, tetapi apa yang ingin mereka lakukan akan membutuhkan 50 poin dan dua sprint atau lebih, PO dapat mengatakan "tunggu, kami memiliki rilis prioritas tinggi dari MVP ini yang direncanakan dan tidak dapat menghabiskan 2 minggu untuk membangun fungsionalitas yang tidak ada dalam peta jalan! "

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.