สร้าง product backlog item หรือ user story...
DESCRIPTION
สร้าง Product backlog item หรือ user story หรือ requirment เริ่มทำกันแบบไหนดี แต่ไสลด์นี้เป็นเนื้อหาย่อ และไม่ครบกระบวนค่ะ เรียกว่าเป็นภาคแรกละกันนะคะTRANSCRIPT
USER STORYscenario 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 process
her request
ในฐานะเจ้าหน้าที่ อิฉันอยากจะได้หน้า VERIFY เพื่อที่จะได้เห็นข้อมูลลูกค้า
และให้ลูกค้ายืนยันตัวตน ก่อนที่ทำสิ่งที่เค้า REQUEST เข้ามา
ในฐานะ OPERATOR( As an operator )
อิฉัน อยากจะได้ หน้าจอ VERIFYI 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 requirement number)
• Category: (if any)
• Scenario:
• Sub Scenario
รายละเอียดส่วนที่เป็น อุปกรณ์เป้าหมาย
• Target Device(s):
• Resolution:
• Device/ OS Remark:
STAKEHOLDER
• ตามที่ระบุไว้ใน “As a”
• หรือมีคำบรรยายเพิ่มเติม
IMPACT• [ ] กิจกรรมใหม่ New User Activity / Business Activity
• [ ] ทำให้ของเดิมเร็วขึ้น
• [ ] ทำไปแทนที่ของเดิมที่เราจะเลิกใช้
• [ ] ลดข้อผิดพลาด
• [ ] ผิดพลาดสำคัญ
• [ ] ผิดพลาด Minor และมี workaroundแก้ปัญหาเฉพาะหน้าชั่วคราวได้
• [ ] ลดค่าใช้จ่าย เช่นหลีกเลี่ยงค่า license ได้
• [ ] ตอบโจทย์ข้อบังคับทางกฎหมาย
• [ ] เพื่อเก็บข้อมูลไปวิเคราะห์ทางธุรกิจ หรือทำความเข้าใจ user
RISK
• ส่วนที่ยังไม่แน่ใจ
• เช่น อยากใช้การ ลากวาง แทน คลิกๆ หลายครั้ง
PREPARATION
• สิ่งที่เราต้องไปทำการบ้านเพิ่มเติม ก่อนเค้าจะเริ่มงานแล้วเอากลับมาใส่ข้อมูลเพิ่มเติม
BUSINESS VALUE
• ถ้าเรามีความชัดเจนว่า เกี่ยวกับ Business Value
• ขอใส่ข้อมูลลงไปด้วย
ส่วนเสริมเรื่องประสิทธิภาพ
• เช่น หน้านี้ไม่ควรใช้เวลาโหลดเกิน 10 วินาที
• หน้านี้ ต้องสะอาด ไม่ scroll เยอะ
• ไม่ควรต้องคลิกออกไปข้างนอกเยอะ
บันทึกสำหรับการตรวจงาน
• เวลาตรวจงาน อยากตรวจอะไรบ้าง
• ให้ออกแบบไว้ก่อน ไม่อย่างนั้นเดี๋ยวตอนตรวจจริงจะลืม
ตัวอย่างส่วนเสริมของ SPEC• ความเร็ว
• ช้าสักนิดก็ไม่เป็นไร ถ้าไม่เกิน 10 วินาที เพราะหน้านี้ไม่ได้เปิดตอนคุยกับลูกค้า เป็นต้น
• หน้าร้องเรียน หรือติชม ต้องทำงานเร็ว เพราะลูกค้ามักติดต่อมาด้วยอารมณ์ขุ่นเคือง ถ้าระบบทำงานช้าลูกค้าอารู้สึกไม่พึงพอใจมากขึ้นไปอีก
ตัวอย่างส่วนเสริมของ SPEC• ความสวยงาม
• ยัดเนื้อหา ไม่ให้ต้อง scroll หรือเลื่อนหน้าไปมา
• มีความสะอาดสะอาด ไม่ดูเลอะเทอะ
• สีสันสดใส ไม่น่าเบื่อ
• เว้นช่องว่างระหว่างบรรทัดเยอะๆ เพื่อจะได้ดูโปร่งตา
ตัวอย่างส่วนเสริมของ SPEC
• การใช้งานของ user
• ความสะดวก จำนวนคลิก น้อยที่สุด
• ปล่อยมือจากคีย์บอร์ด น้อยที่สุด/ ปล่อยมือจากเมาส์น้อยที่สุด
REAL LIFE DATANo 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 ก็ได้)
• Journey breakdown
• Define specs (Specification By Example, Paper Mockup, Acceptance criteria)
• Create User Story
• Rearrange backlog and User stories