敏捷方法的理解和实践（含团队架构）

1. 背景（Situation）

项目组属于新成立的软件部门，结构是1个项目组下有多个开发小组，每个开发小组负责独立的业务模块。
对于整个软件开发的过程，项目组成员都有一个共识，那就是使用基于scrum模型的敏捷迭代。但是，整个项目组对于scrum模型的认知不统一，小组事务和项目组事务未统一定义，例如没有月度回顾会议，rat会议变成了技术评审会议等，导致整个开发过程的效率和感受都不太好。

2. 任务（Task）

基于这个背景，作为1个开发小组的小组长，团队最多人数时也有5人。
当前任务有2个：

• 需要梳理并实施适合小组的运作流程；
• 提出项目组运作流程的建议；

3. 行动（Action）

• 学习软件全生命周期：结果软件全生命周期视角，看待项目组存在什么问题
• 学习scrum模型：什么是scrum，角色，事务有哪些？scrum相比于极限编程的优势是什么？
• 基于scrum模型模拟制定项目组运作流程

软件全生命周期

1. 可行性分析：初步决定软件的目标、技术可行性、成本等
2. 需求分析：确认需求实现的目标，避免后续需求实现偏差。输出软件需求规范说明书（或者原型图）
3. 概要设计和详细设计：对需求的实现进行技术选型、接口设计、数据库设计；输出需求概要设计文档和需求详细设计文档
4. 实现：编码 + 单元测试
5. 集成测试
6. 确认测试
7. 使用和维护

从整个项目组的迭代流程来说，也就是如上所说，需求分析、设计、实现、测试、运维。但是运作流程，存在很多问题。站在PL的角度看流程，存在如下的问题：
问题汇总：

1. 没有设计文档：开发人员自行设计，质量无法保证，且耗时。因为没有设计，导致很多问题引入到了编码以及测试阶段。
2. 迭代的时间节点有问题：开发时间不应该从迭代的第一天计算；转测后不应该继续开发特性；整个迭代周期没有明确的时间节点。
3. 工作量评估不准确：SE人员对工作量的评估不够准确，没有1个具体的评估标准，都是SE想当然的拍1个时间，没有考虑过开发是否认同该时间，误差较大。
4. 经常存在需求延期交付：工作量的评估不准确，间接导致了需求延期。但是从开发到交付的阶段，并没有识别出需求延期风险。
5. 问题屡犯：迭代周期中，团队中每个人遇到的问题没有进行汇总，导致流程没有向一个良性的方向发展。即使问题抛出来了，也没有监管对应的问题。
6. 需求分析的会议十分低效：需求描述没有统一语言，导致需要多次复述；需求优先级没有1个制定标准；
7. 流程自动化率太低，大部分流程需要人为来管理：需求没有借助devops工具来管理，而是通过excel来管理，低效；自动化测试覆盖率低，质量管控只能通过开发人员的自测，不可信；国际化词条翻译没有自动化，需要单人投入大量人天去处理，且在能力上存在单点问题，如果离职了无法快速承接该工作；

scrum模型

问：为什么我会首先想到SCRUM模型

答：因为在入职转正前，学习过公司敏捷方法的课程；公司主推的开发流程施救SCRUM模型，算得上公司的最佳实践吧；

问：敏捷方法是什么

答：是面向高频变化需求的一种软件开发方法。 现在的互联网产品，需求都是千变万化的，一个产品的需求，并不是在开发前就将产品需求100%设计好，而是通过迭代的方式，逐步的达到产品的目标。在迭代周期中，用户诉求变化会导致需求变化，又需要对需求评估、设计、开发。

问：scrum的定义是什么

答：Scrum是一个用于开发和维护复杂产品的敏捷方法框架（类似的还有极限编程框架等），是一个增量的、迭代的开发过程，目的是让开发人员像打橄榄球一样迅猛并充满激情，通过团队合作，提高工作效率

问：scrum的内容是什么

答：3个角色、5个会议、12项原则。

以下内容都是我从https://www.cnblogs.com/xichji/p/12164740.html这里复制过来的，我认为是SCRUM中比较核心的内容，对于我后续的小组开发流程设计有很大的帮助。

不同于瀑布模型将开发过程划分为需求、设计、编码、测试等阶段，Scrum将整个开发过程分为多次迭代（称为Sprint，冲刺），一般为期2～4周，最常见的为2周。Scrum并非以一段时间集中完成一个过程，而是将所有过程中必须的每一部分集中在这段时间内完成。需求、设计、编码、测试、上线都必须在一个迭代中完成，每个迭代必须产生一个可以工作的软件。

3个角色

Scrum中的人员分为3个角色：产品所有者（Product Owner）, Scrum Master，开发团队(Team)。

• 产品所有者：定义所有产品功能，决定产品发布的内容以及日期，对产品的投入产出负责，根据市场变化对需要开发的功能排列优先顺序，合理地调整产品功能和迭代顺序，认同或者拒绝迭代的交付。
• ScrumMaster ：ScrumMaster不是项目经理，他没有分配任务的权力，没有考核的权力，没有下命令的权力，他指导项目组的成员按照Scrum的原则、方法做事情，领导团队完成Scrum的实践以及体现其价值，排除团队遇到的困难，确保团队胜任其工作，并保持高效的生产率，使得团队紧密合作，使得团队个人具有多方面职能的工作能力，保护团队不受到外来无端影响。
• 开发团队：经典团队拥有 5-9 人，团队成员包含程序员、测试员、用户体验设计等等，团队关系在一个迭代中应该是固定的，个人的职能可以在新迭代开始时发生调整，团队自我组织和管理（自组织，自驱动），团队成员都全职工作。

5个会议

Scrum 整个开发过程分为五个会议:

1）待办事项整理会议（Backlog Grooming Meeting）

迭代计划会议开始之前3天召开，Product Owner与Scrum Master必须参加，关键开发者或架构师需要参加；时间控制在30分钟到1小时。

由Product Owner将一批希望团队在下次迭代时实现的用户故事，按照实现顺序描述给在场的团队成员，Scrum Master与在场成员分析用户故事，明确指出团队认为需求不明确的地方，Product Owner现场记录，会后补全，Scrum Master与架构师，还有在场成员分析用户故事需要包含哪些技术任务，Scrum Master先把子任务建立，方便迭代计划会议的时候团队可以更准确地预估任务故事点。

会议结束时，Product Owner确保在迭代计划会议开始之前团队提出的问题都能被解决，会议重点如果团队发现需要加强或是完善的地方，Product Owner还有两到三天的时间可以补强，而不是浪费迭代计划会议的时间去做这件事情。

2）迭代计划会议（Sprint Planning Meeting）

产品负责人建立产品功能列表（Product Backlog）。产品功能列表是一组条目化需求，它必须从客户价值角度描述，并按优先级排序。

Scrum Master召集相关人员召开迭代计划会，迭代计划会在每个迭代第一天召开，目的是选择本次迭代的Backlog和估算本次迭代的工作量。

产品负责人逐条讲解最重要的产品功能，开发团队共同估算Backlog所需工作量，直到本迭代工作量达到饱和。产品负责人参与讨论并回答和需求相关的问题，但不干扰估算结果。队员认领任务（或由组长协商分发），独立或与别人一起完成任务；会议时间控制在1-2小时内。

3）每日站会（Standup Meeting）

团队内部利用每日立会来沟通进度，15分钟结束，开发团队利用燃尽图来展示整体进度；如无特殊原因，迭代期内无变更，在每日站会上团队成员需要回答以下3个问题：

• 昨天你做了什么?
• 今天你将要做什么?
• 你有需要帮助的地方吗?

这些都是团队成员的彼此承诺。

4）评审会（Retrospective Meeting）

小组向产品负责人展示迭代工作结果，产品负责人给出评价和反馈。以用户故事是否能成功交付来评价任务完成情况。整个团队都需要参加，ScrumMaster、产品所有者、团队，可能还有客户，时间控制在1-2小时内。

5）迭代反思会（Retrospective Meeting）

在每个迭代后召开简短的反思会，总结哪些事情做得好，哪些事情做得不好。做得好的保留，不好的摒弃。会议得出这样的结论：开始做什么、继续做什么、停止做什么，一般控制在15-30分钟。

Scrum是一套开发流程，是敏捷的一种，实施主要还是看人，强调是自组织、自驱动的，只有不断的在实际应用中仔细体会，才能理解Scrum的真谛，把Scrum用好。

项目组角色

职责为我个人理解，当前我的角色为SE，但我个人的工作为SE和DEV

角色缩写	角色全称	职责
SL	Service Leader（云服务主管）
PM	Project Manager（项目经理）
SA	架构师
RDPM	研发项目经理？？版本经理？？	把控研发进度，管理研发团队重要事务，保证项目的迭代质量
SE	SoftWare Engineer（版本架构师）	根据需求，进行特性详细设计（含背景、UserStory、UI、接口、数据库、用例测试点梳理、可靠性checklist、周边影响checklist、安全checklist等），可选输出方案评审文档进行方案决策，把控组内研发进度，按迭代上线交付特性，保证质量
TSE	Test SoftWare	根据特性设计，指定用例设计的计划，指导TE设计用例，保证用例质量
安全SE		负责项目的整体安全，指定安全计划，定期检测项目是否存在安全漏洞，并制定解决方案和计划
TE	测试工程师	参与部分用例设计工作；主要工作为根据测试用例，执行用例，输出执行报告
Dev	软件开发工程师	根据特性设计文档，输出代码
SRE	站点可靠性工程师（运维）	变更过程质量保证，解决运维问题
UCD	UI	根据需求设计，设计UI，输出UI图

项目组运作流程

会议活动

术语
RAT：Requirement Analysis Team（需求分析团队）
CCB：Change Control Board（变更控制委员会）

名称	主题	参与人员	输入	输出
RAT会议	判断需求价值，过滤无用需求；澄清需求；决策需求优先级；	SL、PM、RDPM、SE、TSE、核心TE、核心DEV	Feature-story清单，包含初步的特性分析、价值分析、工作量分析、迭代计划	调整特性分析、价值分析、工作量分析，输出迭代计划
需求串讲会/反串讲	SE对小组内进行需求澄清和串讲；DEV对需求进行反串讲，避免理解偏差；	SE、TSE、TE、DEV	迭代特性清单	对特性遗漏设计的地方进行补全，输出迭代特性&责任人矩阵
每日站会	SE识别组内进度风险，解决阻塞性问题	SE、DEV	昨天你做了什么？今天你准备做什么？你有没有解决不了的问题？
技术评审会	SE/DEV对复杂特性需要设计评审方案	SL、SA、RDPM、SE、DEV	方案评审稿件，方案决策项	方案决策结果
用例评审会	对迭代用例进行评审	TSE、TE、SE、DEV	输入迭代用例	输出用例清单和用例修改点
CCB会议	迭代中，对项目中所有存量BUG单、漏洞单进行决策	SL、RDPM、安全SE、TSE、SE	输入BUG单、漏洞单	输出BUG单、漏洞单的状态决策结果，具体参照下方表1
变更评审会	评审迭代的变更指南，输出变更指导操作	SL、RDPM、SE、安全SE、TSE、SE、DEV	输入变更指南（迭代中，让DEV、SE编写，含SQL、主数据、流水线等）	输出变更指南
月度总结会	对团队整个迭代进行复盘总结，提出优化点，在下个迭代进行执行。全员组织发散性讨论，汇总不同视角发现的问题并制定解决方案和计划	ALL	输入各模块SE复盘内容（自测、bate测试、预发测试问题分析）、TSE复盘内容（现网问题分析）	公共事项&问题纪要

表1-bug单状态是否支持当前此结论

状态	遗留	降级	退回	挂起
待提交	❌	❌	❌	❌
待确认
待定位
修复中-修复中
修复中-修复中
修复中-修复测试			❌
修复中-测试完成			❌
待验收			❌
已完成	❌	❌	❌	❌

4. 结果（Result）

初步梳理制定了项目组的运作流程，并得以实施，使得迭代事务变得清晰，迭代过程的风险和进度变得可控，各成员能清楚自己的角色和职责