สร้าง Product backlog item หรือ user story หรือ requirment เริ่มทำกันแบบไหนดี แต่ไสลด์นี้เป็นเนื้อหาย่อ และไม่ครบกระบวนค่ะ เรียกว่าเป็นภาคแรกละกันนะคะ

1. USER STORY
scenario based requirement
16 May 2014

2. As an operator,
I want a verify identity screen
so that I can see customer details
and verify his/her identity to process
her request

3. ในฐานะเจ้าหน้าที่
อิฉันอยากจะได้หน้าVERIFY
เพื่อที่จะได้เห็นข้อมูลลูกค้า
และให้ลูกค้ายืนยันตัวตน ก่อนที่ทำสิ่งที่
เค้า REQUEST เข้ามา

4. ในฐานะ OPERATOR
( As an operator )

5. อิฉัน อยากจะได้ หน้าจอVERIFY
I want to have verify screen

6. เพื่อที่จะเอาไว้ใช้ ยืนยันตัวตน
ลูกค้าที่ติดต่อเข้ามา
So that I can verify customer identity

7. การเขียนเสป็คงาน
Product Requirement

8. USER STORY
• เพราะเราสนใจ การใช้งานของ User
เวลาเราทำเสป็คงาน จึงไปตั้งต้นที่ การใช้งานตาม
ที่ user จะใช้

9. องค์ประกอบของ USER STORY
• As a ________
• I want _______
• So that_______

10. รายละเอียดแนบ USER STORY
• Requirement No: ( high level requirement number )
• Sub Requirement No: ( low level requirement number)
• Category: (if any)
• Scenario:
• Sub Scenario

11. รายละเอียดส่วนที่เป็น
อุปกรณ์เป้าหมาย
• Target Device(s):
• Resolution:
• Device/ OS Remark:

12. STAKEHOLDER
• ตามที่ระบุไว้ใน “As a”
• หรือมีคำบรรยายเพิ่มเติม

13. IMPACT
• [ ] กิจกรรมใหม่ New User Activity / Business Activity
• [ ] ทำให้ของเดิมเร็วขึ้น
• [ ] ทำไปแทนที่ของเดิมที่เราจะเลิกใช้
• [ ] ลดข้อผิดพลาด
•
[ ] ผิดพลาดสำคัญ
•
[ ] ผิดพลาด Minor และมี workaroundแก้ปัญหาเฉพาะหน้าชั่วคราวได้
• [ ] ลดค่าใช้จ่าย เช่นหลีกเลี่ยงค่า license ได้
• [ ] ตอบโจทย์ข้อบังคับทางกฎหมาย
• [ ] เพื่อเก็บข้อมูลไปวิเคราะห์ทางธุรกิจ หรือทำความเข้าใจ user

14. RISK
• ส่วนที่ยังไม่แน่ใจ
• เช่น อยากใช้การ ลากวาง แทน คลิกๆ หลายครั้ง

15. PREPARATION
• สิ่งที่เราต้องไปทำการบ้านเพิ่มเติม
ก่อนเค้าจะเริ่มงาน
แล้วเอากลับมาใส่ข้อมูลเพิ่มเติม

16. BUSINESSVALUE
• ถ้าเรามีความชัดเจนว่า เกี่ยวกับ BusinessValue
• ขอใส่ข้อมูลลงไปด้วย

17. ส่วนเสริมเรื่องประสิทธิภาพ
• เช่น หน้านี้ไม่ควรใช้เวลาโหลดเกิน 10 วินาที
• หน้านี้ ต้องสะอาด ไม่ scroll เยอะ
• ไม่ควรต้องคลิกออกไปข้างนอกเยอะ

18. บันทึกสำหรับการตรวจงาน
• เวลาตรวจงาน อยากตรวจอะไรบ้าง
• ให้ออกแบบไว้ก่อน ไม่อย่างนั้นเดี๋ยวตอนตรวจจริง
จะลืม

19. ตัวอย่างส่วนเสริมของ SPEC
• ความเร็ว
• ช้าสักนิดก็ไม่เป็นไร ถ้าไม่เกิน 10 วินาที เพราะหน้านี้
ไม่ได้เปิดตอนคุยกับลูกค้า เป็นต้น
• หน้าร้องเรียน หรือติชม ต้องทำงานเร็ว เพราะลูกค้า
มักติดต่อมาด้วยอารมณ์ขุ่นเคือง ถ้าระบบทำงานช้า
ลูกค้าอารู้สึกไม่พึงพอใจมากขึ้นไปอีก

20. ตัวอย่างส่วนเสริมของ SPEC
• ความสวยงาม
• ยัดเนื้อหา ไม่ให้ต้อง scroll หรือเลื่อนหน้าไปมา
• มีความสะอาดสะอาด ไม่ดูเลอะเทอะ
• สีสันสดใส ไม่น่าเบื่อ
• เว้นช่องว่างระหว่างบรรทัดเยอะๆ เพื่อจะได้ดูโปร่งตา

21. ตัวอย่างส่วนเสริมของ SPEC
• การใช้งานของ user
• ความสะดวก จำนวนคลิก น้อยที่สุด
• ปล่อยมือจากคีย์บอร์ด น้อยที่สุด/ ปล่อยมือจาก
เมาส์น้อยที่สุด

22. REAL LIFE DATA
No Lorem Ipsum.. and any Bla Bla data

23. SPECIFICATION TABLE
(SPECIFICATION BY EXAMPLE)

24. วาดรูปหน้าจอ ประกอบเสป็ค
• เพื่อระบุ โครงหน้าให้
ชัดเจน
อยากได้อะไรไว้ตรงไหน

25. ACCEPTANCE CRITERIA

26. REQUIREMENT STATUS
• Collect details and define scope
• Create scenarios
• Split scenarios (ได้อีกกี่ level ก็ได้)
• Journey breakdown
• Define specs (Specification By Example, Paper Mockup,Acceptance criteria)
• Create User Story
• Rearrange backlog and User stories