Scrum Development Experience Sharing: Insights, Roles, and Practices

In this presentation, the speaker introduces Scrum from a practical perspective, emphasizing that DevOps without an agile foundation is ineffective.

The current development mode faces pain points such as long coordination chains in large systems, shifting team sizes due to micro‑services and containers, and rapid delivery demands from customers.

Scrum is defined and its relationship with SRE and DevOps is illustrated, noting that DevOps can adopt agile principles but is not strictly dependent on them.

Key challenges include the difficulty of applying agile at scale, the need for clear product and architecture ownership, and the importance of aligning communication directly from product to the whole team.

Team composition is presented as a simple 1‑1‑3‑2 model involving product owners, architects, developers, and testers, with emphasis on product defining "what" and architects defining "how".

Role responsibilities are detailed: the Product Owner drives roadmap, iteration scope, and feature prioritization; architects design solutions and guide the team; developers deliver code quickly; testers design tests early and avoid being isolated at the end of the pipeline.

Daily activities include the Planning Game (using GitLab instead of poker cards), Stand‑up meetings (prefer physical boards for small teams), Review meetings (design, code, and test reviews), End‑to‑End demos, Definition‑of‑Done meetings, and Retrospect meetings (using sticky notes to share three points per participant).

Product operation tasks such as customer support, data analysis, and internal/external sharing are also highlighted.

Practical tools for the PO are discussed, including principles for selecting iteration scope, versioning conventions (three‑digit version numbers with optional RC tags), and visual aids like fishbone diagrams for version details.

Backlog and PRD management is recommended to be kept in a Wiki, allowing clear prioritization without tying directly to code.

The article concludes that Scrum processes should be continuously adapted to the team's reality, reminding that people are dynamic while processes are static, and everything not explicitly prohibited can be modified.