USER STORY
scenario based requirement	

16 May 2014
As an operator, 

I want a verify identity screen	

so that I can see customer details	

and verify his/her identity to pr...
ในฐานะเจ้าหน้าที่	

อิฉันอยากจะได้หน้าVERIFY	

เพื่อที่จะได้เห็นข้อมูลลูกค้า	

และให้ลูกค้ายืนยันตัวตน ก่อนที่ทำสิ่งที่
เค...
ในฐานะ OPERATOR
( As an operator )
อิฉัน อยากจะได้ หน้าจอVERIFY
I want to have verify screen
เพื่อที่จะเอาไว้ใช้ ยืนยันตัวตน
ลูกค้าที่ติดต่อเข้ามา
So that I can verify customer identity
การเขียนเสป็คงาน
Product Requirement
USER STORY
• เพราะเราสนใจ การใช้งานของ User

เวลาเราทำเสป็คงาน จึงไปตั้งต้นที่ การใช้งานตาม
ที่ user จะใช้
องค์ประกอบของ USER STORY
• As a ________	

• I want _______	

• So that_______
รายละเอียดแนบ USER STORY
• Requirement No: ( high level requirement number ) 	

• Sub Requirement No: ( low level requirem...
รายละเอียดส่วนที่เป็น	

อุปกรณ์เป้าหมาย
• Target Device(s):	

• Resolution:	

• Device/ OS Remark:
STAKEHOLDER
• ตามที่ระบุไว้ใน “As a” 	

• หรือมีคำบรรยายเพิ่มเติม
IMPACT
• [ ] กิจกรรมใหม่ New User Activity / Business Activity	

• [ ] ทำให้ของเดิมเร็วขึ้น	

• [ ] ทำไปแทนที่ของเดิมที่เร...
RISK
• ส่วนที่ยังไม่แน่ใจ	

• เช่น อยากใช้การ ลากวาง แทน คลิกๆ หลายครั้ง
PREPARATION
• สิ่งที่เราต้องไปทำการบ้านเพิ่มเติม 

ก่อนเค้าจะเริ่มงาน

แล้วเอากลับมาใส่ข้อมูลเพิ่มเติม
BUSINESSVALUE
• ถ้าเรามีความชัดเจนว่า เกี่ยวกับ BusinessValue 	

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

• หน้านี้ ต้องสะอาด ไม่ scroll เยอะ	

• ไม่ควรต...
บันทึกสำหรับการตรวจงาน
• เวลาตรวจงาน อยากตรวจอะไรบ้าง	

• ให้ออกแบบไว้ก่อน ไม่อย่างนั้นเดี๋ยวตอนตรวจจริง
จะลืม
ตัวอย่างส่วนเสริมของ SPEC
• ความเร็ว	

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

• ยัดเนื้อหา ไม่ให้ต้อง scroll หรือเลื่อนหน้าไปมา	

• มีความสะอาดสะอาด ไม่ดูเลอะเ...
ตัวอย่างส่วนเสริมของ SPEC
• การใช้งานของ user	

• ความสะดวก จำนวนคลิก น้อยที่สุด 	

• ปล่อยมือจากคีย์บอร์ด น้อยที่สุด/ ปล่...
REAL LIFE DATA
No Lorem Ipsum.. and any Bla Bla data
SPECIFICATION TABLE	

(SPECIFICATION BY EXAMPLE)
วาดรูปหน้าจอ ประกอบเสป็ค
• เพื่อระบุ โครงหน้าให้
ชัดเจน 

อยากได้อะไรไว้ตรงไหน
ACCEPTANCE CRITERIA
REQUIREMENT STATUS
• Collect details and define scope	

• Create scenarios	

• Split scenarios (ได้อีกกี่ level ก็ได้)	

• ...
Upcoming SlideShare
Loading in …5
×

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

2,083 views

Published on

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

Published in: Engineering
2 Comments
7 Likes
Statistics
Notes
  • @syingyos ขอบพระคุณสำหรับคำแนะนำค่ะ ข้าช่างอ่อนด๋อยยิ่งนัก อิอิ
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • เสป็ค ต้องเป็น สเป็ค ป่าวครับผม : )
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
2,083
On SlideShare
0
From Embeds
0
Number of Embeds
40
Actions
Shares
0
Downloads
24
Comments
2
Likes
7
Embeds 0
No embeds

No notes for slide

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

  1. 1. USER STORY scenario based requirement 16 May 2014
  2. 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. 3. ในฐานะเจ้าหน้าที่ อิฉันอยากจะได้หน้าVERIFY เพื่อที่จะได้เห็นข้อมูลลูกค้า และให้ลูกค้ายืนยันตัวตน ก่อนที่ทำสิ่งที่ เค้า REQUEST เข้ามา
  4. 4. ในฐานะ OPERATOR ( As an operator )
  5. 5. อิฉัน อยากจะได้ หน้าจอVERIFY I want to have verify screen
  6. 6. เพื่อที่จะเอาไว้ใช้ ยืนยันตัวตน ลูกค้าที่ติดต่อเข้ามา So that I can verify customer identity
  7. 7. การเขียนเสป็คงาน Product Requirement
  8. 8. USER STORY • เพราะเราสนใจ การใช้งานของ User
 เวลาเราทำเสป็คงาน จึงไปตั้งต้นที่ การใช้งานตาม ที่ user จะใช้
  9. 9. องค์ประกอบของ USER STORY • As a ________ • I want _______ • So that_______
  10. 10. รายละเอียดแนบ USER STORY • Requirement No: ( high level requirement number ) • Sub Requirement No: ( low level requirement number) • Category: (if any) • Scenario: • Sub Scenario
  11. 11. รายละเอียดส่วนที่เป็น อุปกรณ์เป้าหมาย • Target Device(s): • Resolution: • Device/ OS Remark:
  12. 12. STAKEHOLDER • ตามที่ระบุไว้ใน “As a” • หรือมีคำบรรยายเพิ่มเติม
  13. 13. IMPACT • [ ] กิจกรรมใหม่ New User Activity / Business Activity • [ ] ทำให้ของเดิมเร็วขึ้น • [ ] ทำไปแทนที่ของเดิมที่เราจะเลิกใช้ • [ ] ลดข้อผิดพลาด • [ ] ผิดพลาดสำคัญ • [ ] ผิดพลาด Minor และมี workaroundแก้ปัญหาเฉพาะหน้าชั่วคราวได้ • [ ] ลดค่าใช้จ่าย เช่นหลีกเลี่ยงค่า license ได้ • [ ] ตอบโจทย์ข้อบังคับทางกฎหมาย • [ ] เพื่อเก็บข้อมูลไปวิเคราะห์ทางธุรกิจ หรือทำความเข้าใจ user
  14. 14. RISK • ส่วนที่ยังไม่แน่ใจ • เช่น อยากใช้การ ลากวาง แทน คลิกๆ หลายครั้ง
  15. 15. PREPARATION • สิ่งที่เราต้องไปทำการบ้านเพิ่มเติม 
 ก่อนเค้าจะเริ่มงาน
 แล้วเอากลับมาใส่ข้อมูลเพิ่มเติม
  16. 16. BUSINESSVALUE • ถ้าเรามีความชัดเจนว่า เกี่ยวกับ BusinessValue • ขอใส่ข้อมูลลงไปด้วย
  17. 17. ส่วนเสริมเรื่องประสิทธิภาพ • เช่น หน้านี้ไม่ควรใช้เวลาโหลดเกิน 10 วินาที • หน้านี้ ต้องสะอาด ไม่ scroll เยอะ • ไม่ควรต้องคลิกออกไปข้างนอกเยอะ
  18. 18. บันทึกสำหรับการตรวจงาน • เวลาตรวจงาน อยากตรวจอะไรบ้าง • ให้ออกแบบไว้ก่อน ไม่อย่างนั้นเดี๋ยวตอนตรวจจริง จะลืม
  19. 19. ตัวอย่างส่วนเสริมของ SPEC • ความเร็ว • ช้าสักนิดก็ไม่เป็นไร ถ้าไม่เกิน 10 วินาที เพราะหน้านี้ ไม่ได้เปิดตอนคุยกับลูกค้า เป็นต้น • หน้าร้องเรียน หรือติชม ต้องทำงานเร็ว เพราะลูกค้า มักติดต่อมาด้วยอารมณ์ขุ่นเคือง ถ้าระบบทำงานช้า ลูกค้าอารู้สึกไม่พึงพอใจมากขึ้นไปอีก
  20. 20. ตัวอย่างส่วนเสริมของ SPEC • ความสวยงาม • ยัดเนื้อหา ไม่ให้ต้อง scroll หรือเลื่อนหน้าไปมา • มีความสะอาดสะอาด ไม่ดูเลอะเทอะ • สีสันสดใส ไม่น่าเบื่อ • เว้นช่องว่างระหว่างบรรทัดเยอะๆ เพื่อจะได้ดูโปร่งตา
  21. 21. ตัวอย่างส่วนเสริมของ SPEC • การใช้งานของ user • ความสะดวก จำนวนคลิก น้อยที่สุด • ปล่อยมือจากคีย์บอร์ด น้อยที่สุด/ ปล่อยมือจาก เมาส์น้อยที่สุด
  22. 22. REAL LIFE DATA No Lorem Ipsum.. and any Bla Bla data
  23. 23. SPECIFICATION TABLE (SPECIFICATION BY EXAMPLE)
  24. 24. วาดรูปหน้าจอ ประกอบเสป็ค • เพื่อระบุ โครงหน้าให้ ชัดเจน 
 อยากได้อะไรไว้ตรงไหน
  25. 25. ACCEPTANCE CRITERIA
  26. 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

×