เพิ่มประสิทธิภาพการทำ Backlog refinement ด้วย Specification Workshops

สำหรับเพื่อนๆที่ใช้ Scrum อาจจะเคยประสบปัญหาใน session backlog refinement กันมาบ้าง สำหรับเพื่อนๆที่ไม่คุ้นเคย Backlog refinement เป็น session ที่ทีม(Dev & QA) จะพูดคุยกับ Business user เพื่อสอบถามและทำความเข้าใจ requirement ก่อนที่จะนำไปพัฒนาจริง

ปัญหาที่เรามักจะเจอคือ Team กับ Business user เห็นภาพไม่ตรงกัน หลังจากจบ session แล้ว หรือบางครั้งมีเคสหลายเคสที่ทีมลืมที่จะถามกับ Business user ไป ทำให้ต้องนัดหมายมาคุยกันอีกหลายรอบ อีกทั้งยังมีปัญหาทีมคุย Deep technology ที่ใช้ ทำให้ Business user รู้สึกเสียเวลา ก็อาจทำให้การนัดหมายครั้งหน้าเป็นไปได้ยาก

Specification Workshops คืออะไร

Specification Workshops เป็นเทคนิคส่วนหนึ่งของ Acceptance Test Driven Development (ATDD) เป็นแนวคิดของการให้ทีม สอบถามความต้องการของลูกค้าได้อย่างมีประสิทธิภาพ และ ได้เอกสารอ้างอิงคือ Scenario Example

ใครควรเข้าร่วมใน Session บ้าง

1. Business User – เป็นคนให้ข้อมูลของ Requirement ในมุมมองของ Business
2. Developer – สอบถามคำถามในมุมมองของ Technical Perspective
3. QA or Tester – สอบถามคำถามในมุมมองของ QA Perspective และทำหน้าที่เป็นตัวเชื่อมผสาน Business User และ Developer เข้าด้วยกัน เพราะ QA ควรจะมีมุมมองของ business แต่ก็เข้าใจ Developer ด้วย

ตัวอย่าง Specification Workshop

1. เริ่มจาก Business user อธิบาย Requirement
2. Team สอบถามคำถาม
3. QA ทำการ Summary และสร้าง Scenario Example ขึ้นมาเพื่อใช้ในการยืนยันข้อมูล
4. ทุกคนร่วมกันตรวจสอบ Scenario Example ครบถ้วนถูกต้อง

แนวทางในการทำ Specification Workshop

1. กำหนด และใช้ Ubiquitous language คือการใช้ภาษาที่เข้าใจง่าย เพียงภาษาเดียวเพื่อให้การพัฒนา Software เป็นไปอย่างถูกต้อง เช่น เราเรียกผงซักฟอก ว่า แฟ้บ หรือ ที่เป็นแบบ เฉพาะทีม เช่น Back end อาจหมายถึงระบบหลังบ้านที่ให้ลูกค้าใช้เพื่อตรวจเช็คสถานะการจัดส่งสินค้าโดยปกติ Ubiquitous ควรจะมาจากมุมมองของ Business เสมอ เพื่อให้สัมพันธ์กับ Requirement ที่ได้รับ และสะดวกเวลาที่ทีมต้องมีการสอบถามข้องมูลจาก Business User
   1. ข้อควรระวัง หากเราไม่มีการกำหนด Ubiquitous language อาจทำให้การ Confirm Requirement คลาดเคลื่อนได้ เช่น Business User อาจต้องการให้เพิ่มเมนุในการ cancel order ไปที่ Back end แต่ทีมอาจเข้าใจผิดว่า เพิ่ม Cancel order ไปที่ หลังบ้างสำหรับ Service Desk ก็เป็นได้ครับ
2. ทุกคนควรพุ่งทำความเข้าใจกับ Requirement ในมุมมองของ Business
3. ทุก requirement ควรมีการทำสิ่งที่เรียกว่า Scenario Example ครับ หน้าตาก็ประมาณนี้เลย เป็นตารางง่ายๆ เพื่ออธิบายถึง Scenario ต่างๆที่จะเกิดขึ้นจริง และทุกคนสามารถเข้าใจได้รวมถึง Business User ด้วย
   
4. ต้องให้เกียรติ เวลาของ Business User
   1. ไม่ควรถกเถียงกันเรื่อง Technology ที่จะใช้ แนวทางการพัฒนา หรืออะไรก็ตามที่ไม่เกี่ยวข้องกับ Business
   2. มุ่งเน้นการทำความเข้าใจกับ Business Requirement
   3. อาจใช้วิธีเชิญ Business User เข้าประชุม เฉพาะช่วงแรกของ Session
   4. ส่งรายละเอียด Topic ให้กับ ทีม และ Business User ทราบเพื่อเตรียมตัวก่อนเข้าประชุม

โดยรวมแล้ว จะเห็นว่ารูปแบบจะคล้ายกับการทำ Backlog refinement ของ Scrum มาก เพียงแค่มีแนวทาง และ practice ที่ช่วยให้ทีมสามารถ สื่อสารกับ Business User ได้อย่างมีประสิทธิภาพมากขึ้นนั่นเอง

Refs: หนังสือ ATDD by Example: A Practical Guide to Acceptance Test-Driven Development