软件团队如何落地敏捷开发（Scrum）

软件团队如何落地敏捷开发（Scrum）的步骤：1、确定产品负责人；2、组建敏捷小组；3、确定敏捷教练；4、拟定产品需求；5、评估产品需求；6、冲刺规划会；7、工作透明化等。确定产品负责人要求，产品负责人必须知道自己带领的团队需要做什么产品以及取得什么成果。

1、确定产品负责人

产品负责人必须知道自己带领的团队需要做什么产品以及取得什么成果。一个项目团队中可以有多个产品经理，每个负责产品中一个模块的功能，但产品负责人只能有一个，作为所有产品经理的代表，决定产品的发展方向。

2、组建敏捷小组

一个项目团队可以有多个敏捷小组，负责产品中一个功能模块的开发，比如这个组开发前端界面，这个组开发支付功能，再有一个组开发社交功能。同时，一个小组的人数较好控制在3-9个人，超过9人的话人数越多沟通路径越多，不利于团队间的沟通，降低工作效率。

3、确定敏捷教练

敏捷教练的作用是对成员进行敏捷培训，做好工作进度的管控，优化项目流程，解决成员遇到的阻碍，最终目的是提高整个敏捷小组的工作效率，保证顺利交付。如果团队只有一个敏捷小组，那么由项目经理作为敏捷教练；如果有多个小组则有多个Scrum Master ，简称SM，项目经理对每个敏捷小组和SM统筹管理。

比如，一个软件研发团队中可能有三个敏捷小组，分别是前端开发、后端开发、测试，小组中高级工程师或者技术专家作为SM，而项目经理需要对SM进行敏捷培训，SM再给小组成员做培训，形成整个敏捷团队

4、拟定产品需求

这一项主要由产品负责人负责，首先，他权衡各个需求后排列出需求的优先顺序；其次，负责向团队清楚地表达产品待办列表；第三点，确保产品待办列表是可见的、透明的，所有人都清楚下一步该做什么工作；最后，在创建产品待办列表的同时，还需要包括测试描述，这些测试描述将在“完成”时验证产品的完整性。

同时PO也会听取团队对列表的建议，适当的进行调整，例如在描述需求后如果开发团队表示工作太多或太少，可以与PO重新协商，开发团队也可以邀请技术专家参加。产品待办列表代表的是各方的业务需求，当发生变更时，或利益相关者如果想要改变产品待办列表的优先级，必须向PO提出请求。产品待办列表的内容和顺序中是透明可见的，没有人可以强迫开发团队做列表范围以外的需求工作。

5、评估产品需求

团队会通过需求评审会来对产品负责人提的需求进行评审，产品负责人和团队中的技术专家一起参与，评估每一个需求需要什么技术、多少人、时间来完成，对于不合理的需求提出改进意见或者直接驳回，会探讨以下问题：

该需求是否细分到了可以评估的程度？
需求文件的信息足够么，是否描述清楚？
这个需求是否有价值？等等

最终目的是保证每个需求切实可行。另外，Scrum用点数代替人天和人时评估需求的工作量，对应的数字采用斐波那契数列，这个数列的规律是前两个数的和是下个数的值，从而更好地比较需求之间的差异，再通过对比来评估出较为准确的工作量。

6、冲刺规划会

每个迭代周期就是一个Sprint，也就是冲刺。冲刺周期都是固定的，一般是1-3周。在冲刺规划会上，团队成员、敏捷教练和产品负责人坐在一起，规划冲刺的内容。

7、工作透明化

Scrum提倡工作透明化，团队外的人员可以参加内部会议，每个成员的工作都是公开透明，最常见的做法是准备一块白板，上面分成三栏：待办事项、在办事项、完成事项。把待办事项写到便笺纸上，随着进度的推进，将相应的便笺纸转移到其他栏目。也可以用PingCode、Jira等不错的项目管理软件来记录事项，起到跟白板一样的效果。

8、每日站会

会议要求全员参加，时间地点固定，时长一般不超过15分钟，且站立进行，每个团队成员只回答以下问题：

你昨天做了什么去帮助团队完成冲刺？
今天你打算做什么来帮助团队完成冲刺？
什么因素阻碍了团队效率？

成员只反馈进度、规划、问题，提高会议的效率，不占用大家的过多时间，具体的事项会后讨论。通过反馈，敏捷教练把控好项目进度，帮成员解决阻碍。

9、冲刺评估

在冲刺结束前，团队成员给产品负责人展示项目成果，接受评价。这是一场公开的会议，任何人都可以是参与者，不仅仅包括产品负责人、敏捷教练和开发团队，还包括利益相关者、管理人员与客户。

10、冲刺回顾

通过举行回顾会议来盘点本次冲刺中所存在的问题、遇到的阻碍、做得好与不好的地方、提出建议和整改方法，对流程规范进行优化，提高下次冲刺的工作效率。

延伸阅读

敏捷开发的原则

快速迭代：相对那种半年一次的大版本发布来说，小版本的需求、开发和测试更加简单快速。一些公司，一年发布仅2~3个版本，发布流程缓慢，它们仍采用瀑布开发模式，更严重的是对敏捷开发模式存在误解。
让测试人员和开发者参与需求讨论：需求讨论以研讨组的形式展开最有效率。研讨组，需要包括测试人员和开发者，这样可以更加轻松定义可测试的需求，将需求分组并确定优先级。同时，该种方式也可以充分利用团队成员间的互补特性。如此确定的需求往往比开需求讨论大会的形式效率更高，大家更活跃，参与感更强。
编写可测试的需求文档：开始就要用“用户故事”（User Story）的方法来编写需求文档。这种方法，可以让我们将注意力放在需求上，而不是解决方法和实施技术上。过早的提及技术实施方案，会降低对需求的注意力。
多沟通，尽量减少文档：任何项目中，沟通都是一个常见的问题。好的沟通，是敏捷开发的先决条件。在圈子里面混得越久，越会强调良好高效的沟通的重要性。
团队要确保日常的交流，面对面沟通比邮件强得多。
做好产品原型：建议使用草图和模型来阐明用户界面。并不是所有人都可以理解一份复杂的文档，但人人都会看图。
及早考虑测试：及早地考虑测试在敏捷开发中很重要。传统的软件开发，测试用例很晚才开始写，这导致过晚发现需求中存在的问题，使得改进成本过高。较早地开始编写测试用例，当需求完成时，可以接受的测试用例也基本一块完成了。