Fixing Your Own Scrum the Series

Software Requirements Development

รุ่น Beta version

รุ่น Beta version

• รับมอบประสบการณ์โดยไม่มีค่าใช้จ่ายใด ๆ
• ขอเพียง ความคิดความเห็น เพื่อนำมาปรับปรุง รายละเอียดของการส่งมอบประสบการณ์

จาก Product Owner in Scrum Framework (July 2016)

อ้างอิงจากเอกสาร Scrum Guide ฉบับกรกฎาคม ค.ศ. 2016 ความรับผิดชอบของ Product Owner ได้กำหนดไว้ว่า

The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:

• Clearly expressing Product Backlog items;
• Ordering the items in the Product Backlog to best achieve goals and missions;
• Optimizing the value of the work the Development Team performs;
• Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
• Ensuring the Development Team understands items in the Product Backlog to the level needed.

The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.

จาก Product Owner in Scrum Framework (November 2020)

อ้างอิงจากเอกสาร Scrum Guide ฉบับพฤศจิกายน ค.ศ. 2020 ความรับผิดชอบของ Product Owner ได้กำหนดไว้ว่า

The Product Owner is also accountable for effective Product Backlog management, which includes:

• Developing and explicitly communicating the Product Goal;
• Creating and clearly communicating Product Backlog items;
• Ordering Product Backlog items; and,
• Ensuring that the Product Backlog is transparent, visible and understood.

The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable.

การปฏิบัติจริงที่หน้างานของ [บริษัท] Product Owner *

ตลอดระยะเวลา 10 ปี มีเสียงบ่น มีคำถาม และได้เห็นปัญหาของ ผู้ดำรงตำแหน่งเป็น [บริษัท] Product Owner หลาย ๆ แบบ ที่มีปัญหาเรื่อง

• แยกไม่ออกระหว่าง ที่อยากได้ (Needs) กับ ความต้องการ (Software Requirements)
• ขาดประสบการณ์ในการ สกัดหา Software Requirements จาก Needs
• ขาดประสบการณ์ในการ พัฒนาความต้องการ กลุ่ม Functional Requirements
• ไม่มีการ พัฒนาความต้องการ กลุ่ม Non-Functional Requirements
• ไม่รู้ว่ารูปแบบของ Software Requirements Specification ใด ที่เหมาะสมกับ การสื่อความออกไปให้กับทุก ๆ คนที่เกี่ยวข้อง
• อะไรใช้เป็นข้อตกลงในการตรวจรับ และตรวจสอบ ว่า Software Requirements ถูกพัฒนาออกมาเป็น Features/Functions ใน Product หรือ Services
• [บริษัท] Product Owner โดนสั่ง และถูกกำหนดหน้าที่ให้มีหน้าที่ เขียนความต้องการ แต่เพียงคนเดียว
• รูปแบบของการเขียนความต้องการ คือ User Story แบบ As a ...<Roles>... I want ...<Feature/Function>... So that ...<Benefits>...
• Acceptance Criteria ถูกหยิบมาใช้แบบขาดประสบการณ์

* [บริษัท] Product Owner คือ ปัจจุบัน แต่ละ บริษัท มีการกำหนดหน้าที่ความรับผิดชอบของ ผู้ดำรงตำแหน่ง Product Owner ว่าจะต้องทำอะไรบ้าง ซึ่งน้อยมากที่จะยึดโยงไปยัง Product Owner ของ Scrum Framework

ประสบการณ์ที่จะได้รับมอบตลอดระยะเวลา 2 วัน

ตลอดระยะเวลา 2 วัน ผู้เข้าร่วมรับมอบประสบการณ์ จะได้รับมอบประสบการณ์จาก ผู้ส่งมอบประสบการณ์ ที่มีประสบการณ์ซ้ำซ้ำซากซาก ที่ ผสมผสาน ระหว่าง

Software Product Development

• Software Requirements
• Software Requirements Development
• Business Analyst
• Software Project Management
• User Experience

Product Management

• Software Product Management
• Software Product Goal
• Service Design Blueprint

Scrum Framework (1996, July 2016, November 2017 and November 2020)

• The Element of Product Backlog Item
• Clearly expressing Product Backlog items.
• Ensuring the Development Team understands items in the Product Backlog to the level needed.
• Creating and clearly communicating Product Backlog items.
• Ensuring that the Product Backlog is transparent, visible and understood.

ประสบการณ์ซ้ำซ้ำซากซาก จะถูกส่งมอบผ่าน กรณีศึกษา

• ECommerce Platform
• Mobile Banking Feature
• Document Management Platform

เพื่อ

ก่อร่าง สร้าง เสริม เพิ่ม เติม ปรับ และลด องค์ความรู้ และประสบการณ์ เพื่อนำกลับไปปรับประยุกต์ใช้ที่หน้างานอย่างค่อยเป็นค่อยไป กับ ปัญหาเหล่านี้

• แยกแยะได้ ระหว่าง ที่อยากได้ (Needs) กับ ความต้องการ (Software Requirements)
• เพิ่มประสบการณ์ ในการ สกัดหา Software Requirements จาก Needs
• เพิ่มประสบการณ์ ในการ พัฒนาความต้องการ กลุ่ม Functional Requirements
• เพิ่มประสบการณ์ พัฒนาความต้องการ กลุ่ม Non-Functional Requirements
• สะสมรูปแบบ ของ Software Requirements Specification ใด ที่เหมาะสมกับ การสื่อความออกไปให้กับทุก ๆ คนที่เกี่ยวข้อง
• สะสมรูปแบบ อะไรใช้เป็นข้อตกลงในการตรวจรับ และตรวจสอบ ว่า Software Requirements ถูกพัฒนาออกมาเป็น Features/Functions ใน Product หรือ Services
• ลด ละ เลิก รูปแบบของการเขียนความต้องการ คือ User Story แบบ As a ...<Roles>... I want ...<Feature/Function>... So that ...<Benefits>...
• ลด ละ เลิก Acceptance Criteria ถูกหยิบมาใช้แบบขาดประสบการณ์