Di Scrum / Agile, bagaimana cara memberikan mesin validasi / aturan secara bertahap?

8

Katakanlah Anda memiliki mesin validasi yang perlu mencakup 100 aturan agar bermanfaat.

Anggap saja tim hanya dapat memberikan sekitar 10 aturan per iterasi.

Bagaimana Anda akan membuat "peningkatan produk yang berpotensi dirilis" pada akhir iterasi pertama, ketika mesin aturan masih kehilangan 90 aturan inti?

Apakah Anda, misalnya, menambahkan kegagalan / peringatan sementara yang selalu terjadi berdasarkan fakta bahwa tidak semua aturan telah diterapkan?

Sunting untuk konteks: Saya sedang mengembangkan middleware untuk proses bisnis yang kompleks dengan banyak kasus penggunaan lama, yang dimaksudkan untuk mereplikasi dan mengganti monolit besar. Sangat sulit untuk ditayangkan tanpa cakupan 100%, karena kami memiliki kemampuan terbatas untuk memutuskan atau membatasi kasus penggunaan rumit yang akan muncul dalam produksi yang meminta untuk dilayani.

agile scrum

— James Daily
sumber

Apakah Anda membuat "mesin validasi", atau hanya menulis 100 aturan untuk mesin yang ada?

— Bryan Oakley

@BryanOakley: Dalam kasus saya ini adalah pengaturan dasar spreadsheet Drools, di mana setiap cerita lincah akan menambah / memodifikasi definisi aturan atau hanya menambahkan aturan baru dalam aturan yang ada.

— James Daily

Anda harus mencoba Kanban daripada scrum di sini ...

— user666

7

Bagaimana Anda akan membuat "peningkatan produk yang berpotensi dirilis" pada akhir iterasi pertama, ketika mesin aturan masih kehilangan 90 aturan inti?

Anda melepaskan sepuluh pertama dalam sprint pertama. Hanya karena "berpotensi dapat dirilis" bukan berarti itu harus dapat digunakan oleh pelanggan. Ini hanya berarti bahwa fungsionalitas apa yang ada telah diuji dan berperilaku seperti yang dirancang, dan tidak menyebabkan regresi pada produk.

Pikirkan "berpotensi dapat dirilis" sebagai "kami tidak memiliki pekerjaan lagi untuk fitur ini. Kode ini selesai dan telah diuji dan didokumentasikan dengan baik".

Apakah Anda, misalnya, menambahkan kegagalan / peringatan sementara yang selalu terjadi berdasarkan fakta bahwa tidak semua aturan telah diterapkan?

Itu pasti sesuatu yang mungkin ingin Anda pertimbangkan, jika Anda ingin pelanggan benar-benar menguji fitur tersebut.

— Bryan Oakley
sumber

Saya mengerti, jadi ada perbedaan yang bermakna antara "berpotensi dapat dirilis" dan "cukup untuk kebutuhan pengguna" (di mana pengguna mungkin pengguna UI, atau klien layanan web yang berharap untuk memanggil API, atau apa pun)

— James Daily

Saya menyadari bahwa pertanyaan saya bukan tentang lincah (konsep "Selesai" menjawab dengan mudah), melainkan pertanyaan desain - bagaimana seharusnya API mendeteksi dan merespons skenario yang tidak didukung dengan baik saat memberikan rilis bertahap yang bermakna?

— James Daily

6

Dari Panduan Scrum, definisi Increment mengatakan :

Di akhir Sprint, Peningkatan baru harus “Selesai,” yang berarti harus dalam kondisi dapat digunakan dan memenuhi definisi Tim Scrum tentang “Selesai.” Itu harus dalam kondisi dapat digunakan terlepas dari apakah Pemilik Produk memutuskan untuk benar-benar melepaskannya.

Jika Anda tidak memiliki cukup peraturan yang lengkap, kemungkinan Pemilik Produk akan memilih untuk tidak benar-benar merilisnya. Namun, Peningkatan harus "Dilakukan". Setiap aturan yang telah Anda terapkan harus sudah diselesaikan sesuai Definisi Selesai tim Anda.

Keputusan yang Anda buat bergantung pada apa yang akan dilakukan dengan Peningkatan. Dalam pertanyaan Anda, Anda menyebutkan melemparkan pengecualian untuk aturan yang tidak diterapkan. Ini bisa berhasil, tetapi jika seseorang akan mengintegrasikan dengan mesin aturan Anda, itu mungkin membuat overhead bagi mereka untuk menangani kasus kesalahan ini, terutama jika itu tidak akan ada dalam produk jadi. Atau mungkin itu yang akan membuat hidup mereka lebih mudah. Pertimbangkan apa maksud increment itu, siapa yang mungkin menggunakannya, dan pergi dari sana.

— Thomas Owens
sumber

"tetapi jika seseorang akan berintegrasi dengan mesin aturan Anda, itu mungkin membuat overhead bagi mereka untuk menangani kasus kesalahan ini" Benar sekali, tetapi kejahatan yang diperlukan dalam skenario perusahaan atau kita tidak akan pernah mendapatkan apa pun dari pintu :)

— James Daily

@JamesDaily Tidak, ini bukan kejahatan yang perlu. Anda dapat mengurangi dengan tidak membuang pengecualian bahwa sistem yang sudah selesai tidak akan membuang atau dengan mengembalikan nilai. Apa pun itu berarti bahwa sistem lain tidak perlu menambahkan kode penanganan kesalahan hanya untuk menangani fakta bahwa sistem Anda belum selesai untuk dapat menunjukkan fungsionalitas minimum.

— Thomas Owens

Mungkin melempar pengecualian terlalu keras. Peringatan lunak atau bahkan indikator Validasi Penuh vs. Parsial lebih masuk akal dan lebih mudah bagi klien untuk bereaksi. Dalam komentar lain, saya perhatikan pemikiran saya bergerak menuju: bagaimana seharusnya API mendeteksi dan merespons skenario yang tidak didukung dengan baik ketika memberikan rilis tambahan yang bermakna?

— James Daily

3

Anda telah menentukan situasi tanpa melarikan diri.

Saya yakin ada situasi kehidupan nyata di mana Anda memiliki blok fungsi yang rumit yang tidak dapat dipisahkan. Tetapi kasus yang biasa adalah bahwa Anda dapat memecah suatu persyaratan menjadi sub persyaratan yang memang memiliki beberapa manfaat dari diri mereka sendiri.

Katakan misalnya persyaratan saya untuk memvalidasi alamat penagihan kartu kredit Inggris. Ini cukup rumit, kami ingin memastikan bahwa alamat tersebut adalah alamat tempat tinggal orang yang disebutkan dalam kartu sehingga jika mereka default dalam pembayaran, kami dapat mengejar mereka.

Ada ratusan kemungkinan validasi dan pemeriksaan yang dapat kita lakukan untuk meningkatkan keandalan pemeriksaan, tetapi masing-masing secara individual dapat diuji dan menawarkan penurunan nyata dalam risiko penipuan.

alamat memiliki nomor rumah dan kode pos
kode pos adalah format yang valid
pencarian kode pos dengan api eksternal berhasil
kode pos adalah kode pos geografis
alamat divalidasi dengan pemasok kartu kredit dll

Jika dorongan datang untuk mendorong, pelanggan akan dapat menghasilkan uang dengan hanya sebagian dari aturan yang diterapkan. Baik risiko tambahan dapat diterima atau kerja manual di sekitarnya dapat ditambahkan ke alur kerja untuk mengurangi situasi.

Metodologi scrum dan gesit dirancang dengan pemikiran ini. Mereka mencoba untuk menghindari kegagalan seluruh proyek dengan memastikan bahwa beberapa persyaratan yang hilang tidak menyebabkan seluruh solusi menjadi tidak berharga.

Tapi mereka tidak bisa mengubah kenyataan, jika Anda memiliki roket ruang angkasa yang pasti membutuhkan X, Y dan Z untuk terbang. Maka Anda membutuhkan ketiganya!

Kuncinya adalah mengenali bahwa umumnya dalam jalur aplikasi bisnis, ini tidak terjadi, terlepas dari apa yang pelanggan katakan.

— Ewan
sumber

Ya, saya bisa membayangkan pendekatan berulang dengan peringatan informasi sementara yang dikembalikan ketika validasi diketahui tidak lengkap untuk input yang diberikan. Misalnya, Anda meminta saya untuk memvalidasi alamat tempat tinggal lokal Anda dan alamat perbankan asing Anda, tetapi mesin harus melewati alamat asing karena belum didukung. PO dapat memutuskan bahwa itu tidak cukup lengkap untuk benar-benar ditayangkan, tetapi setidaknya API jujur tentang apa yang telah atau belum divalidasi.

— James Daily