敏捷项目管理到底怎么实施？

我们使用各种敏捷软件写feature，流转、跟踪任务，言必谈敏捷，然而我们是否真的走对了敏捷？

显而易见，敏捷是绝对的结果导向，去文档化，去流程化，高效沟通和合作是究极奥义。

去文档，敏捷管理者需要维护更为精细的需求池；去流程，口头沟通成为常态，对团队的耦合度要求更高。

1

让我们先来了解一下

敏捷的一些概念

 

Product Backlog:

backlog 即需求池。待办事项列表。

Backlog里面写什么：

1.待开发任务。

2.任务优先级。

敏捷需要维护一份详尽的需求列表。这份列表常常要求scrum持有人（一般是产品经理）对所有待开发事项有深入了解，并且能够把待开发事项分解成更为细致的任务。

story board:

在开发领域，故事版是任务流转的可视化窗口，一般有“待开发”“开发中”“待测试”“返工”“待发布”几个区块，所有任务由任务操作者负责流转至于下一个步骤，这样任何一个人项目成员都能看到任务的完成情况。

 

 

▲在开发中，故事板展现所有需求的工作流

burn down chart（燃尽图）：

一个sprint内，人/时是一个比较固定的值。在这个时间框架充分安排开发任务，每天进行时间结算，绘制时间燃尽图。项目成员通过燃尽图获知时间进展，若项目燃尽所用时间与预期时间契合，则需求时间预估和安排合理，若不契合则需要在下一个sprint进行调整。

这些概念定义了敏捷各个环节的工作，这些流程和节点是敏捷开展的基础和保障。

 

2

离开敏捷工具

我们怎么敏？

 

一个误区：我们用了敏捷管理工具，就敏捷了

随着敏捷在行业内的不断融入，各种工具产品层出不穷。国外jira、redmine，Axosoft ，国内的leangoo、禅道，BAT三大家则都有自研的工具，百度的icafe，阿里的aone，腾讯的tapd。

 

 

（▲数据来源：“中国开发者白皮书”）

我们在敏捷管理工具上建迭代，建需求，研发、测试等着收到需求流转的邮件之后开始干活...任务在测试和研发之间流转，bug提给研发，研发解决bug.....我们宣称：我们敏捷化了！

我们习惯