SCRUM敏捷设计&开发

Posted 2021-04-25 monica的心得

最近看了一些关于“SCRUM敏捷开发”的相关书籍，工作中，大家也是身体力行SCRUM敏捷开发，所以，就记录一些敏捷开发相关的一些感悟吧。

首先，敏捷开发的组成：

SCRUM角色

产品负责人

数量：1人；

职责：清晰的表述PB（产品待办项列表）；给出PB的排序；确保信息对所有成员是可见、透明和清晰的；确保团队成员对PB足够的了解。

敏捷教练

数量：1人；

职责：服务型领导，帮助团队中每个人理解SCRUM理论、实践、价值；帮助团队成员理解目标、范围和产品域；帮助团队之外的人如何与团队交互，最大化SCRUM团队所创造的价值；找到有效管理PB的技巧等；服务于产品负责人、服务于开发团队、服务于组织。

开发团队

数量：多名

职责：包含各种专业人员，负责在每个 Sprint 结束时交付潜在可发布并且“完成”的 产品增量；开发团队中的每个成员也许有特长和专注的领域，但是责任属于整个开发团队；

团队的组建，完全通过成员的自主自愿形成。团队成员是跨职能、跨部门的，具备最佳的灵活性、创造力和生产力。

SCRUM事件

事件是带有时间盒限定的，用来达成信息的透明和检视目的；Sprint是最典型的SCRUM中用来承载事件的容器。这段时间内构建 一个“完成”、可用的和潜在可发布的产品增量。Sprint由计划会议、每日站会、开发工作、sprint评审会议和sprint回顾会议构成。

SCRUM工件

Scrum 的工件以不同的方式表现工作任务和价值，可以用来提供透明以及检视和适应的机 会。为了给关键信息提供最大透明化，因此，每个人对工件都要有一致的理解。

SCRUM工件：PB、SB、监控目标实现的进度（燃尽图）、增量。在工件层面，Master需要确保每一个增量描述清晰，增量的“完成”定义，以及每个成员对工件的“完成”理解一致。

SCRUM原则：

Scrum 采纳一种迭代和增量式的方法来优化对未来的预测和控制风险。透明、检视和适应是经验过程控制的三大支柱，支撑起每一个经验过程的实施。他与PDCA（Plan→Do→Check→Action）管理是一脉相承的，就是结合实践经验和当下发展情况为输入，以实际动态变化、发展为导线，指导实践过程中不断调整适应去靠近目标。

SCRUM方法优越于传统的瀑布式开发，就是真正做到了拥抱变化，持续交付，持续确认，最终实现了最大化的完成可用的、满足动态需求的产品。在执行SCRUM的过程中，启发最大的就是对于UET team在整个过程中的优化、协作思维的变化，打破了传统的“串联式”协作模式、“改改改”的命运，实现了“并行”模式、“输入有理有据、输出可追踪溯源”的工作流程。

UET team基于SCRUM优化

传统的UET设计过程中，不可避免经常会出现以下情况：需求变更响应不及时、交付延期、质量没有保证，需求满足度不够，验收满意度不够等情况。

借鉴SCRUM通过sprint迭代实现，逐步完成产品整体开发，持续交付验收的思路，UET设计也采用将大的设计拆解为迭代量大小的小块设计、验证、下发的实现思路。拆解小块的大小基于几点考虑：基于当前的用户可用性测试验证了的features；基于当前资源可实现的features；基于用户可评估、可验证的workflow；

在整个sprint过程中，开发负责评估、实现以及QA测试。设计在此过程中除了回答本迭代的设计问题，相对而言没有太多的工作量需要输出。为了使得开发与设计两条路径并行，在此期间，设计需要设计下一个迭代的设计，开展下下个迭代的可用性测试数据收集与分析。由于每次的迭代设计都是叠加性质的。因此，基础的迭代设计一定的稳定、可扩展，不会因为后续的迭代叠加就改变。协作流程如下图所示

借鉴SCRUM的Sprint开展基于To do list → doing list → done,UET设计工作也可以如此开展。通过usability investigation/Contextual inquiry获取usability issues，然后经过分析,筛选出部分usability issues放入Fixed prototype列表中，接下来就是Fixed&works列表了。基于SCRUM的透明、检视原则，我们的User Experince白板也是公开展示，待办/进行中/完成进度一目了然。User Experince白板与开发的进度白板对接的就是Feature Requests呈现，最终通过用户故事板呈现。需要强调的一点就是，可用性标准一定是验收标准的组成部分。SCRUM设计过程如下图所示：

相比较传统的UET实现UCD过程，SCRUM过程中，文档少了很多，通过daily communication实现设计与开发的信息交流。但，UET还需要适当的编写一些文档。

主要包含以下信息：

设计目标；

设计要解决的问题的简单描述；

设计的重点描述，包含草图原型、指向最后一个设计原型的指针；

相关历史设计文档的访问链接；

设计迭代描述；

设计迭代描述包含以下信息：

1. 设计修改的原因；

2. 设计的限制和局限（可用性调研中获取的信息）：

3. 技术的限制；

4. 关联功能卡的名称；

5. 设计包含更多的实际使用流程的信息，相关的bug（与设计变更的相关的）的链接，超出预期的操作等。

这些文档主要是写给UET内部成员查看的，主要有几个目的：

1. 避免出现设计冲突；

2. 新加入的设计成员，能够快速的掌握设计情况与背景；

3. 对于设计迭代，尤其是设计变更，能够追踪溯源；

4. 设计更加的理性、更快速的响应需求变更、更加的适应市场需求、更全面的解决问题，创在价值、更加的有创新。