敏捷项目管理-如何从0-1搭建敏捷团队

  

一、从哪里开始？

敏捷是一种方法、工具，和其他方法或者工具一样，在其适用范围内可以返回显著的作用。那么有没有比较直观的判断标准来确定是否合适使用敏捷方法来进行项目管理呢？答案是有的！

1、从做事的对象角度判断

complex部分就是我们实施敏捷项目管理的适用范围。需求和技术都明确的简单问题，可用传统预测方法去处理即可，需求和技术都不明确的混沌问题，由研究院去探索。既不简单又不确定的复杂问题，可以考虑用敏捷方法！

2、从做事的过程角度判断

通过实验性的过程，快速迭代试错，最终得到让客户满意的交付。这种过程适用于敏捷方法。

3、敏捷宣言

只要符合敏捷宣言，即适用于敏捷方法，这是最根本的判断方法。

二、团队做敏捷的团队成员要求

 从0-1搭建的敏捷团队，也就是零基础的团队，一般以scrum团队方式组建。这类团队一般分为三种角色，分别是产品负责人、敏捷教练、开发团队。

1、产品负责人简称PO，是单人角色，其作用是把握方向，把客户需求正确传递给敏捷团队，并代表用户对团队产出进行验证，从而使得团队的产出有实际价值。

2、敏捷教练，是单人角色，作为团队的保护者，规则的维护者出现。

3、开发团队，团体角色，是一个跨职能的团对。

三、零基础团队如何运用敏捷方法

  判断项目是否适用于敏捷方法，以及组建敏捷团队后，我们就开始敏捷项目管理的实施。

 首先，选定敏捷方法。

敏捷方法或者框架很多，其适用的场景有所不同，针对零基础的团队，scrum上手容易，因此给广泛采用。

其次，做好最基础的三件事

第一件事，从基础敏捷开始。确定团队采用scrum框架，并给与团队进行敏捷导入培训，中期按sprint模式进行工作，后期要注意培养敏捷教练，让敏捷方法的群众基础更牢固。

第二件事，做好需求管理。以用户故事的方式进行需求管理，形成产品的backlog。这不需要在sprint开展前完成，属于一个前置的元素。

第三件事，搭建持续集成环境。软件功能是最直观成果呈现，拥有持续集成技术平台的支持，加快开发团队向PO展现成果，并在反馈中快速进行调整。其在sprint之后，属于后置元素。

最后，把三个基础元素，套到sprint，然后跑迭代。

四、团队实施敏捷的典型问题

团队，特别是零基础团队实施敏捷会遇到很多问题，当中有几个最为常见。

1、团队成员抱怨会议太多？

很多成员会不解为啥敏捷项目管理有这么多会要开，很多时候还不如多写几行代码和跑多一轮测试来的实在。其实这可能是敏捷教练未正确传递会议的价值。如果成员知道这些会议的价值，那么会看到当中的好处。其中计划会用于定方向，每日站会看团队进展，评审会看结果，回顾会看过程。

2、初次梳理会和计划会时间偏长。

初次梳理会以及计划会，因为敏捷团队人员之间的信息不对称以及相互了解默契程度不高，要交流、的地方会相对比较多。为了让会议开得更有效率，我们应该做好两点：1、确定会议讨论的粒度（不要过细）；2、会议重点讨论不确定的问题，明确的需求简单掠过。

3、会上出现打酱油的团队成员。首先要审视，是否没有把这些成员的目标与团队目标进行统一，也就是讨论的事情与成员的关系是否紧密。其次，不过早确定成员负责的内容。最后，可以多人处理难点的问题，增加团队成员的相互协助。

五、团队级敏捷实施的参考流程

敏捷实施的流程因各组织自身环境有所不同，不过有可以进行参考的模板。

1、选择敏捷试点项目

对于未实施过敏捷的团队，选择敏捷试点项目有一定的技巧。最重要的是项目的周期适中（3个月左右），项目人员规模在十人以内，项目重要性偏中，业务有一定的参与度（其中PO能经常参与）。另外团队实施敏捷的意愿要较强，并得到高层的支持。

2、敏捷实施，展示结果。

任务板要在显要位置摆放，项目的要求以海报方式展示，回顾的卡片（感谢他人帮助）展示，增强团队的凝聚力。

3、第一个sprint结束后进行阶段总结汇报。

在完成第一次迭代后，要及时进行阶段性的总结，不仅可以让结果给后续sprint进行参考，也给与领导继续支持敏捷实施提供数据依据。

六、结语

敏捷的需求，前期是大纲，然后在具体的迭代中收获用户反馈，不断地进行调整，最后得到关系人满意的结果。同理，0-1搭建的敏捷团队，对敏捷项目管理的认知也是从框架知识的名词开始，在实践中不断深化认知并享受敏捷带来的好处。

最后文中除脑图外，其他图片素材来自李建昊老师，在此深表感谢。