Your SlideShare is downloading. ×
แนวคิดในการเตรียมข้อมูล และหั่น Requirement ก่อนเริ่มงาน - Tips for Product Backlog Refinement จ้า
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

แนวคิดในการเตรียมข้อมูล และหั่น Requirement ก่อนเริ่มงาน - Tips for Product Backlog Refinement จ้า

289
views

Published on

การทำ Product Backlog Refinement …

การทำ Product Backlog Refinement
หรือการกำหนด Spec งานนั้น มีปัจจัยอะไรที่ต้องนำมาพิจารณาบ้าง
โดยเฉพาะ Product Backlog Refinement เป็นการว่าด้วยเรื่องหั่นของเข้า Sprint ให้มีขนาดพอเหมาะที่จะ deliver ได้แล้วเนี่ย...​อืมๆ ลองเอาแนวคิดไปดูนะคะ เพราะเนื้อหาส่วนใหญ่เป็นส่วนบรรยาย

Published in: Engineering

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
289
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
12
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Text Product Backlog Refinement น้ำจิ้มของการทำ Product Backlog Refinement
 เตรียมเสปค ก่อนเริ่มทำงาน
  • 2. Product Ownership user ควรมีส่วนร่วม ในฐานะเจ้าของ
  • 3. App เพื่อเรา ในเมื่อสร้างให้เราใช้ ก็ใส่ไอเดียเราลงไป
  • 4. ให้ข้อมูล เพื่อทำ App ออกมาตรงตามต้องการ
  • 5. Feedback เฝ้าดู ทดลองเล่น และแสดงความคิดเห็น
  • 6. ตรวจ รีวิว และตรวจรับงาน
  • 7. ต่อยอด หลังจากรีวิว และตรวจรับ เราได้ความรู้ไปต่อยอด เสมอ
  • 8. Collaboration
  • 9. Product Backlog Refinement ร่วมกำหนด เสป็ค/ requirement ใน 

  • 10. Sprint Review ทดลองใช้ ตรวจรับ และให้ Feedback
  • 11. ทำ Product Backlog Refinement
  • 12. Terms ที่เราใช้พูดในการทำ requirement ! ! High Level Requirement vs Low Level Requirement
  • 13. Scenario มองชิ้นงานเป็น Scenario มีเรื่องราว มีที่มาที่ไป มีตัวดำเนินเรื่อง
  • 14. ทำ feature ตาม Scenario คิดฟีเจอร์ ตามเหตุการณ์การทำงานจริง
  • 15. การตีโจทย์ Requirement ปัจจัยต่างๆ ในการทำ requirment ก่อนส่งมอบให้ ทีมพัฒนา
  • 16. Scenario Scenario Persona Device Resolution Application
  • 17. Scenario Stakeholder Call Center IT Support Others…
  • 18. Impact [ ] กิจกรรมใหม่ New User Activity / Business Activity [ ] ทำให้ของเดิมเร็วขึ้น [ ] ลดข้อผิดพลาด [ ] ผิดพลาดสำคัญ [ ] ผิดพลาด Minor และมี workaroundแก้ปัญหาเฉพาะหน้าชั่วคราวได้ [ ] ลดค่าใช้จ่าย เช่นหลีกเลี่ยงค่า license ได้ [ ] ตอบโจทย์ข้อบังคับทางกฎหมาย [ ] เพื่อเก็บข้อมูลไปวิเคราะห์ทางธุรกิจ หรือทำความเข้าใจ user
  • 19. Risk เช่นไม่แน่ใจว่าใช้ swype หรือ ลากวาง พอเอามาใช้งาน จริงแล้ว user อาจค้นว่าไม่ชอบ Preparation เตรียมพร้อมข้อมูลหรือ resource สำหรับ Sprint ถัดไป
  • 20. Non Functional งานที่ต้องทำ แต่ user อาจไม่เห็นผลกระทบโดยตรง Measurement กำหนด เสปค ของสิ่งที่ต้องการเพื่อนำไปวัดผลความ สำเร็จ หรือความยากง่ายในการทำงาน
  • 21. กำหนดปัจจัยในสำคัญต่อ ฟีเจอร์ บ้าง ความเร็ว ความสวยงาม ยัดเนื้อหา ไม่ให้ต้อง scroll หรือเลื่อนหน้าไปมา มีความสะอาดสะอาด ไม่ดูเลอะเทอะ สีสันสดใส ไม่น่าเบื่อ เว้นช่องว่างระหว่างบรรทัดเยอะๆ เพื่อจะได้ดูโปร่งตา การใช้งานของ user ความสะดวก จำนวนคลิก น้อยที่สุด ปล่อยมือจากคีย์บอร์ด น้อยที่สุด/ ปล่อยมือจากเมาส์น้อยที่สุด
  • 22. ลงมือทำ สิ่งที่จำเป็น ในเวลาที่จำกัด
  • 23. เลือก Requirement ที่ง่ายและ มี Business Value กำหนด Business Value น้อยที่สุด ที่เรานับว่าเป็น
 Deliverable Feature ! เลือกงานที่ง่ายที่สุด ที่มี Business Value มาทำ SPRINT1st
  • 24. ช่วยให้มีข้อมูลนำไปตัดสิน ใจง่ายขึ้น ใช้ template เป็นตัวช่วย