agile-user-story
วันนี้ได้อ่านหนังสือ Extreme Programming Installed
ได้ทำการอธิบายเกี่ยวกับ 4 ส่วนสำคัญของ Extreme Programming ประกอบไปด้วย

  1. On-site customer
  2. Working with programmer
  3. ใช้ planning game สำหรับการเลือก user story ที่มีคุณค่าขึ้นมาทำ
  4. Small release

แต่ส่วนที่สำคัญ และ มักจะผิดพลาดกันอย่างมาก ก็คือ ส่วนของ “User Story”
ดังนั้นมาทำการแก้ไข และ ปรับปรุงกันเถอะ

User Story คือ รูปแบบหนึ่งของการนำเสนอ requirement/feature
แต่ยังมีรูปแบบอื่น ๆ อีก เช่น use case และ product backlog item เป็นต้น
ดังนั้นอย่าไปยึดติดกันมากนะ

เมื่อสิ่งที่เริ่มต้น หรือ User Story มันผิด

การสร้าง product ขึ้นมามันก็ผิดเช่นเดียวกัน
ดังนั้นเรื่องของ Acceptance Test มันสำคัญมาก ๆ

ปัญหาการสร้างสิ่งที่ลูกค้าไม่ต้องการ
เกิดขึ้นมาจากการพูดคุยของคนที่เกี่ยวข้อง และ ในทีมมันแย่ หรือไม่คุยกันเลย
โดยเฉพาะระหว่างลูกค้า กับ ทีมพัฒนา
สุดท้ายมันก็เกิดปัญหาขึ้นมาเสมอ

ใน Extreme Programming มีวิธีการช่วยเหลือสำหรับการสร้าง User Story

ซึ่วเรียกว่า 3C ประกอบไปด้วย

  1. Card
  2. Conversation
  3. Confirmation

ดังนั้นแต่ละ User Story ต้องผ่านกระบวนการทั้งสามเสมอ
มาดูรายละเอียดกันว่ามันเป็นอย่างไร ?

1. Card

แน่นอนว่า User Story นั้นจะถูกเขียนลงบน card ที่เป็นกระดาษ หรือ physical
โดยไม่ได้มีข้อมูล และ รายละเอียดที่ครบถ้วนนะ
มีเพียงคำ หรือ ประโยคสั้น ๆ เพื่ออธิบายว่ามันคืออะไร
มันคือ requirement เกี่ยวกับอะไร กันแน่
เพื่อใช้ในการวางแผนงานของทีมพัฒนา
ทั้งการเรียงลำดับความสำคัญ และ ค่าใช้จ่าย

2. Conversation

ทุก ๆ requirement ที่นำเสนอในรูปแบบ User Story นั้น
จะต้องถูกพูดคุย ถกเถียง
ทั้งลูกค้า และ ทีมพัฒนา รวมไปถึงการทดสอบ
เพื่อให้เกิดความเข้าใจตรงกัน
เพื่อแลกเปลี่ยนความคิดเห็นซึ่งกันและกัน
เพื่อสัมผัสอารมณ์ และ ความรู้สึกของแต่ละคน

แน่นอนว่ามันใช้เวลาเยอะมาก ๆ
ดังนั้นในการพูดคุยควรมีกรอบเวลาไม่ยาวนาน (Timebox)
และให้คุยกันบ่อย ๆ เช่น

  • Release planning
  • การวางแผนงานในแต่ละรอบการทำงาน เช่น ทุก ๆ 5 หรือ 10 วันเป็นต้น

โดยการพูดคุยที่ดี ควรจะมีการบันทึก หรือ สร้างเอกสารเพิ่มเติมขึ้นมา
เอกสารอย่างหนึ่งที่ดีมาก ๆ คือ Example หรือตัวอย่างของข้อมูล
โดย Example ที่ดีมาก ๆ คือ Example ที่สามารถ execute ได้
ซึ่งจะเรียกว่า “Example confirmation” นั่นเอง

เทคนิค วิธีการมีเยอะมาก ๆ เช่น

  • Impact mapping
  • Story mapping
  • Refinement
  • Planning
  • Specification by Example (SbE)

3. Confirmation

ในส่วนนี้มันคือ Acceptance Test นั่นเอง
มันเป็นการบอกว่า User Story นั้น ๆ จะต้องผ่านการตรวจสอบ ทดสอบ อะไรบ้าง
จึงจะถูกเรียกว่า เสร็จ จริง ๆ นะ ไม่ใช่คิด หรือ มโนไปเอง
และสุดท้ายจะนำ Example confirmation ไปสร้างระบบแบบอัตโนมัติต่อไป

รูปแบบของ confirmation มีหลายรูปแบบ เช่น

  • Specification by Example (SbE)
  • Behaviour Driven Development (BDD)
  • Acceptance Test-Driven Development (ATDD)

ดังนั้นลองกลับไปดู User Story ของคุณหน่อยสิว่า มี 3C หรือไม่ ?

และได้ข้อมูลต่าง ๆ ออกมาหรือไม่ ?
และมันช่วยทำให้การพัฒนามีประสิทธิภาพขึ้นหรือไม่ ?
และยังสร้าง product ที่ลูกค้าไม่ต้องการหรือไม่ ?

ถ้ายังแล้วละก็ ให้ลองนำ 3C ไปใช้งาน เพื่อปรับปรุงกระบวนการดูได้ครับ

สุดท้ายแล้ว

ลองเลือกดูว่า คุณชอบเส้นไหน ?
นั่นคือสิ่งที่คุณเป็น และ ลูกค้าได้รับกลับไป

Screen Shot 2558-09-29 at 12.18.41 PM

Reference Websites
http://ronjeffries.com/xprog/articles/expcardconversationconfirmation/
https://www.linkedin.com/pulse/20141026233229-25825330-user-stories-fast-agile-skills