Kanban ในชีวิตจริง — แบ่ง User Story ด้วย Error Handling Method
Kanban in Real Life — Splitting a User Story Using Error Handling Method
ศิริพงษ์: “เคยได้ยินคำว่า Positive Case (Happy Path) กับ Negative Case มั้ยครับ? Feature ที่เราทำทั้งหมดมีสองคำนี้เป็นส่วนประกอบ คำว่า Positive Case ก็คือการที่ผู้ใช้ใช้งาน Feature นี้ได้อย่างถูกต้องและบรรลุวัตถุประสงค์ที่เค้าต้องการ ส่วน Negative Case ก็ตรงกันข้ามถ้าเค้าจะพยายามใช้ Feature ด้วยวิธีการที่ไม่ถูกต้องซึ่งระบบเราก็ต้องป้องกันไม่ให้ Case เหล่านี้เกิดขึ้นหรือส่งผลกระทบต่อระบบโดยรวม … อันนี้แหละที่เรียกว่า Error Handling ครับ”
ศิริพงษ์: “เราสามารถแบ่ง User Story โดยพิจารณาที่ Error Handling Method ได้”
Error Handling Method
ศิริพงษ์: “พี่ไม่ได้สนับสนุนให้ปล่อยปะละเลยนะแต่เราเลือกวิธีการจัดการ Error ได้ครับ เช่น ระบบเราจองตั๋วหนัง ถ้ามองงานนี้ให้เป็น Workflow เราควรต้องเขียน Workflow หลักขึ้นมาก่อนนั่นคือ
- As a user, I want to book movie tickets, …
แต่เรารู้แล้วหละว่าการที่จะให้ลูกค้าจองตั๋วหนังเรื่องใดหรือรอบใดได้ต้องมี Business Rules แบบนี้
- หนังต้องเปิดฉายแล้ว
- รอบที่ต้องการดูมีที่นั่งเหลือเพียงพอ
- จองก่อนหนังฉาย 20 นาที
ซึ่งถ้าทำทั้งส่วนที่เป็น Positive Case (จองตั๋วสำเร็จ) และ Negative Case (จองตั๋วไม่สำเร็จ) มันก็จะเป็น User Story ที่ใหญ่เกินไป ดังนั้นเราแบ่งมันได้แบบนี้ครับ
- As a user, I want to successfully book movie tickets, …
- As a user, I want to be notified if something bad happens while I am booking movie tickets, …
ที่น่าสนใจคือ User Story ที่สอง ถ้าการที่จะแจ้งเตือนในรายละเอียดทุกขั้นตอนมันอาจจะเยอะไป เราเลือกที่จะแจ้งเตือนเป็นข้อมูลกลางๆที่ตัดรายละเอียดของ Error นั้นออกไปก่อน
หลังจากนั้นค่อยมาทำให้ Error Handling มันฉลาดขึ้น เช่น
- ระบุรายละเอียดใน Error Message ให้มากขึ้น
- อาศัยการ Enable/Disable ปุ่ม ช่องว่าง หรือส่วนประกอบอื่นๆบนหน้าเวปไปเลย
- เพิ่มการเขียน Error Message และรายละเอียดทางเทคนิคอื่นๆลงใน Log File ครับ”