如何高效地进行敏捷开发管理

[cornerstone]

敏捷开发其实也是企业的一种管理文化。

目前软件行业敏捷开发管理最大的问题在于太看重具体的形式，而忽略了敏捷的初衷。

很多公司请几个敏捷教练建立流程，把会议室的椅子都搬走宣布从今以后大家站着开会了，使用敏捷管理工具建立迭代、建需求、分任务，可是这真的就意味着敏捷了吗？

因为敏捷，老板要求这个功能明天上线，怎么实现我不管，毕竟响应变化高于遵循计划。

因为敏捷，我们希望每天至少发布一个版本，没办法，敏捷要求我们快速地交付可工作的软件。

因为敏捷，虽然需求我们还没想好，但是这个版本要保证本周内上线，敏捷宣言说得好，要欣然面对需求变化。

因为敏捷，我们项目一篇文档也没有，毕竟工作的软件高于详尽的文档。

。。。。

我们不禁要问，这真的是敏捷吗？敏捷的初衷是团队成员能够更加紧密地配合完成工作，敏捷开发强调拥抱变化，但并不意味着可以随心所欲地变更需求。敏捷开发的实质是通过迭代式增量软件开发的方式，防止出现长期闭门造车严重偏离客户需求，达到快速响应市场变化的目的。

下面我想分享下我们公司在近百人的开发团队，同时进行十几个项目开发的过程中，是如何使用CORNERSTONE管理平台进行敏捷项目管理的。

一、角色划分

杰夫·萨瑟兰将 SCRUM 团队中的角色分为三种：

• 开发团队成员，负责开展具体的开发工作；

• Scrum 主管，协助开发团队把事情做得更好；

• 产品负责人，决定应该做什么工作，拟定待办事项清单的内容。

我们根据我们开发中的实际情况将系统中的角色分为以下四种：

• 项目经理：相当于 Scrum 主管，负责协调团队内部合作，召集站立会议，把控项目整体进度。需要明确的是，项目经理并不是一个传统意义上的团队领导。用更流行的话说，项目经理更像是一个仆人式领导。项目经理不应该对团队成员大吼小叫，也不会告诉研发人员该做什么以及如何开发一款产品，而是应该集中精力帮助研发人员清除前进道路上的障碍。

• 产品经理：相当于产品负责人，负责决定应该做什么工作，拟定待办事项清单的内容，确定各个事项的优先顺序。事实上，和很多人理解的不同是，确定各个事项的优先级几乎是敏捷中最重要的工作。为什么？在软件开发领域有一条根据数十年研究工作总结出来的原则，即在任何一款软件中，80%的价值来自 20%的功能。人们总喜欢说每个需求都是重要的，但产品经理需要问一下自己，究竟哪些需求能够给整个项目带来最大的价值？而这些能够带来最大价值的需求就必须优先完成。

• 开发人员：开发人员是项目开发任务具体的实施者。他们负责完成开发任务，及时反馈开发进度。

• 测试人员：测试人员是项目测试任务具体的实施者。他们负责制定测试计划，编写测试用例，创建以及回归缺陷。

在CORNERSTONE中，我们可根据项目成员的具体职能设定不同的角色和权限。

二、收集需求（用户故事）

在项目开始前，产品经理应该基于用户或市场的需求，来编写用户故事，即CORNERSTONE中的需求。一个好的需求（用户故事）一般应该满足 INVEST 标准：

（一） 独立性（ Independent ）——尽可能地使一个需求独立于其他的需求。需求之间的依赖使得制订计划、确定优先级和工作量评估都变得很困难，通常我们可以通过组合需求和分解需求来减少依赖性。

（二）可协商性（ Negotiable ）——需求的内容要是可以协商的，需求不是合同。

（三）有价值（ Valuable ）——每个需求必须对客户具有价值。

（四）可评估（ Estimable ）——开发团队需要衡量需求，以便确定优先级和工作量，并便于安排工作计划。

（五）规模小（ Small ）——一个好的需求要尽量维持小规模，至少要确保在一个迭代周期中能够完成。需求越大，在安排计划、工作量评估等方面的风险就会越大。

（六）可测试（ Testable ）——一个需求要可以测试，以便确定它是可以完成的。如果一个需求不能够测试，那么你就无法知道它什么时候可以完成。

基于以上原则，CORNERSTONE 支持在创建需求时，关联其他需求（这样我们便可以做到组合需求来控制单个需求的粒度！），关联测试用例（确认需求是可以被测试的！），关联迭代（确保需求可以在一个迭代中完成！），设定优先级以及开始截止时间。

三、冲刺规划会议（ Sprint Planning Meeting ）

在每个迭代开发正式开始前，我们都会举行一次规划会议，由产品负责人讲解需求，由所有团队成员一起负责将需求拆解细化成具体的开发任务。开发任务的颗粒度最好足够细，以确保一名开发人员在一个迭代周期内可以开发完成。

一次冲刺规划会议中的产物一般为：

（一）具体分配到每个开发人员的任务列表； （二）会议纪要，CORNERSTONE提供了 WIKI 功能，可以在系统中保存每次会议的会议纪要；

四、每日站会

在迭代开始后，我们团队一般每天上午固定 15 分钟左右进行内部沟通。我们一般会打开CORNERSTONE任务的看板视图：

每个团队成员只需要用三到五句话说明以下三个问题：

• 我昨天做了什么来完成我的任务；

• 我今天打算做什么来完成我的任务；

• 有没有什么可能的阻碍因素会导致我不能按时完成任务。

一般来说，项目负责人需要聚焦于帮助团队成员解决阻碍因素，以帮助所有任务按时完成。

五、随时关注团队进度

在迭代的开发过程中，项目经理需要随时关注项目的开发进度。我们的项目经理一般通过CORNERSTONE提供的项目仪表板来查看项目的整体完成情况；通过燃尽图了解任务的完成情况；通过缺陷分布、缺陷累计来了解迭代完成的质量。

系统自带的甘特图能随时查看迭代的具体进程以及每个项目成员的任务分工情况，做到分配合理。

除了以上统计外，还有一个“报表”功能属于管理员专用，报表功能包含迭代燃尽图、代码提交统计、状态分布统计、每日新增曲线，每日完成曲线、累计数量曲线以及成员工时列表等统计信息。

六、评估总结

在每一次迭代束之前，我们的研发团队成员还要聚在一起开个评估会，向产品负责人演示在这个阶段之内取得的成果，接受评估意见。研发团队成员会评估一下列表上的工作任务已经完成了多少，自己是在这个阶段的冲刺中认领了太多任务以至于没有做完，还是工作任务认领得太少了。CORNERSTONE同样提供了汇总视图，用以在这类会议上展示说明。

最后总结一下，敏捷其实是一种管理方式，敏捷不会告诉我们具体每个项目应该怎么做，杰夫·萨瑟兰有句话说得好，不要猜测，要规划、执行、检查、行动。我认为这句话道出了敏捷的本质。