Tim Scrum tidak mengikuti prinsip YAGNI

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.

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.

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.

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.

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.

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.

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

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.

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! "