敏捷药方

最近我们和一些朋友在讨论如何在团队没有达成敏捷共识的条件下如何实施敏捷的项目管理。

 

这个团队的情况简要描述如下：这是一个不足10人的产品研发团队，首先团队成员的积极性非常高，但是由于长期以来被各种产品研发之外的原因困扰，产品的研发极为无序。由于市场压力，产品过早的推入市场，之后一直对产品是修修补补，补丁摞补丁。产品的市场前景到还好，可是由于长期到现在产品已经欠下了许多技术债务，难以维护，难以扩展，为了修复一个小bug竟需要半天，代码写得就像是迷宫。团队深为困扰，很想去改变现状，可是不知道如何下手。团队虽然听过敏捷，不过他们也听说敏捷有很多的形式化的东西，他们可不喜欢一下子增加太多的形式。团队的技术负责人想采用敏捷的研发方式把团队带入一个有序的轨道，可是他的直接上级对敏捷不置可否，甚至还认为敏捷过于形式化。

 

在深入探讨具体情况后，我们给这个团队开出了一张敏捷药方。

 

1。该团队的积极性很高，这就具备了实施敏捷管理的一个必备条件，可以尝试实施敏捷。

2。团队不喜欢太多形式化的东西，部分听说过敏捷的成员觉得敏捷有很多的条条框框，担心会增加他们的负担，而该团队技术负责人的上级对敏捷不置可否，这就是掉了实施敏捷的一个很重要的条件：上级的支持。针对这一情况，我们觉得如果先试图靠完整的敏捷理论去让团队先达成敏捷共识有些困难，不如“明修栈道，暗度陈仓”：不树敏捷的旗帜，但用敏捷的方法去管理。为此我们抽出了我们认为敏捷中的最核心的部分，形成了以下的建议：

1）严格的执行敏捷中的四部曲：计划（plan）、执行（do）、检查（check）、改进（adjust），结束无序的研发状态。建议在下一个版本开始时，由产品经理规划出该版本要做的事项，以一个月为单位（相当于一个月度sprint）。在计划被所有团队成员认可后，开始坚定的执行。每天实行站立晨会对任务进行跟踪，让大家知晓其它团队成员在干什么以及整个项目的情况。每周举行一次项目回顾会议，对重要的里程碑进行检查，同时根据现实的情况做出适当的调整。在每个月的迭代完成之后，进行一个回顾改进会议，大家一起对已有的问题提出改进意见。通过严格的执行这四部，首先让团队建立一个行军的节奏（且不管速度怎样），改变以前研发无序的状态。

 

2）使用用户故事对产品的设计过程进行管理，。敏捷实施步骤中的三个核心概念非常适用于管理产品的设计过程。第一个是epic（史诗），用户描述产品的愿景，例如要解决用户的什么问题，由产品经理负责撰写；第二个是backlog（任务列表）。有了epic之后，组织大家进行讨论，讨论之后由技术负责人将或者产品经理将epic分解成一个个的backlog，backlog需要由QA和需求人员共同评审。最后由技术负责人分配给相应的组员。第三个是task（任务），这是针对开发人员的一个概念，一个backlog是业务需求的描述，定义了产品要满足的需求和相应的验收条件，一个backlog实现时可能需要分解成几个具体的开发任务，这就是task。在刚实施敏捷的阶段，task的分解由技术负责人和开发人员共同确定，然后确定时间。为了避免形式话，这里不采用集体表决的方式，而是由技术负责人和开发人员共同商定。

 

至于epic和backlog的管理，由于团队成员不希望过多的形式，因此不采用scrum等工具进行管理，而是采用wiki的方式记录，因为大家都已经接受了wiki的形式。

 

 

3。其它建议：

1）技术负责人在分配backlog时，必须与开发人员共同商定，大部分情况下让开发人员决定所需时间。因为经由开发人员的口说出来，就相当于他的一个承诺。我想没有人会让自己总是失信的，这样他会非常的努力。当然作为技术负责人，要灵活处理。如果开发人员估算时间过短（怕拖慢进度而给自己过大的压力，不敢实话实说）要适当延长，避免器陷入焦虑。

 

2）作为技术负责人，要在平时多搜集大家反馈的问题，以便能在回顾会议和改进会议的时候大家有话可说。

 

3）无论如何，都要保证节奏。节奏非常重要，如果在计划的迭代时间内没有完成任务，宁可砍掉一些功能也要结束改迭代。因为没有人喜欢做一个看上去没有结束日期的任务。适当的结束，可以让给大家一个心里暗示：努力告一段落，我们可以喘口气了，虽然我们做得不是很好。这样团队成员不会陷于焦虑从而可以保持高昂的情绪。

 

 

以上的建议只是非常初级的一个敏捷建议，但我们相信这些措施可以把这个团队拖出焦油坑！或者最起码，不会让事情变得更坏。