我相信大部分都知道“敏捷管理”，且都会喊一下它的口号“敏捷迭代，小步快跑”，那我们除了喊口号之外，还做了什么呢？或者说，对于我们的项目管理，又带来了什么不同的点呢？
试想一个场景，公司目前要引入“敏捷管理“，开始用两周一个迭代的周期进行。
接着我们常规情况下可能会这样做，简单排个需求优先级，然后对于紧急又重要的出原型和需求，写需求文档进行评审，最后开发抓紧去做，偶尔追问一下开发的进度，接着开发完了进行测试，然后吭哧吭哧到了第二周的周五晚上上线。
请问这是敏捷吗？
这样只是用传统的“瀑布型“去套“敏捷型”，仅此而已。
到最后你发现，两周一个版本，所有成员疯狂加班，简直要人命，一上线发现又全都是问题，还能怎么办？回滚吧…
那真正的敏捷型项目管理，到底是怎么做的，它有什么方法论吗？
我会尝试从“规划”“需求”“拆解”“跟进”“回顾”五个方面讲解，我们要如何做敏捷管理。
敏捷管理的一些概念
项目管理有很多类型，如预测性、敏捷型等等，不能说哪个更好。具体根据自身的项目出发，找到最合适自己的那条路，才是最好的。
所以我们得理清楚，敏捷并不是神，它只是众多项目管理的一种。
敏捷本身也有很多方法论，其中我要讲的是“Scrum”，主要有4条宣言：
- 个体和互动高于流程和工具
- 工作的软件高于详细的文档
- 客户合作高于合同谈判
- 响应变化高于遵循计划
这4条宣言一定程度上涵盖了我接下来要讲的内容，当然这些宣言记不记住都没啥关系，最重要的是从实践找到方法，而不是在方法里面找到方法。
所以我们开始从传统的瀑布型开发转成敏捷型开发，首先要做的是——规划。
规划
项目假定采用2周1迭代的小步快跑形式，那么最核心最重要的其实是规划。
规划我认为主要有两个最重要的点，一则团队，二则关键时间点。
在团队的规划中，每个团队的人数需控制在十个人以内，因为人数一多，交流的信息会越复杂，这不适合敏捷的“个体和互动”的宣言。
如果团队超过10人，则需要进行团队拆分，每个团队需要设定一个“Scrum Master（团队负责人）”。
有了团队后，并且对团队进行具体的分工后，则需要开始规划关键时间点。
在具体的规划中，我们需要在两周的时间规划出关键的时间节点；我们可以采用倒推的形式去思考到底有什么关键节点。
如上线前，我们需要具体的“上线时间”，再往前我们需要具体的“测试时间”，测试之前我们需要知道具体“开发完结时间”，再继续往前我们需要知道具体“评审时间”。
这里的关键点在于“具体”，直接通过甘特图的形式标识出具体的关键时间，和每个职位在各自环节下的处理时间。
图片只是示例，并不代表具体情况
接着我们每次版本都根据规划的时间节点，按部就班的进行，有了指向标，才能让项目更清晰。
我们只有规划好整个盘子，才能往里面加东西，不会造成自己和团队的混乱。
需求
有了规划后，我们需要知道这期做什么，而做什么则是“需求”决定的，即设定“Sprint Backlog（当前冲刺需要解决的事情）”
本期需求迭代的内容需要进行详尽的分析，根据产品对需求的优先级来确定本期迭代的内容，这里优先级的排列可根据“紧急且重要”、“紧急但不重要”、“不紧急但重要”、“不紧急且不重要”四象限进行分析。
如发现某个需求涉及的内容非常广大，则需要我们产品经理对这个需求再进一步的细化，从整体拆成局部进行重新排列，以“天”为单位。
最后，我们确定好本期的“Sprint Backlog”后，则开始策划需求吧！
拆解
假设我们经过了需求评审，在评审中，我们可以提前和开发负责人沟通这些需求对应的开发人员，这样他们在评审的过程中参与度才是最高的，不过在评审后，按照平常的情况，可能我们直接让他们进行开发了。
但是先别着急，也请先别让开发的小伙伴直接进入开发，让他们首先对自己的开发任务进行“拆解”。
假设一个开发的任务是“筛选列表项”功能，按照一般的开发逻辑，可能从页面的元素、JS、接口、数据库索引、前后端联调等步骤进行开发。
这里面其实对于开发来说是可以详细拆解的。
所以我们需要让开发把具体的开发的功能项，按照“小时”进行拆分，确定好每个开发的步骤和工时，我们才能做到实际的跟进，从每个工作项着手跟进具体的完成度，才能做到有的放矢。
这整个拆解的最后的内容，称之为“SBI（和WBS同理，只是会更加细化开发工作项的内容）”。
有了“SBI”后，我们就可以实时跟进开发进度，当某个事项没有完成时，可以随时通过任务项反映出这个功能是否有风险。
因为前一个工作项和后一个工作项，相互之间大概率是耦合的，缺少这一点，可能也会导致整个功能无法上线。
跟进
有了具体的工作项后，则需要进行跟进了，当然这一节虽然说的是跟进，但是更注重“工具的使用”，这个工具是——看板。
看板主要呈现工作项的流转和完结情况，通过小卡片的形式，实时跟进每个开发工作项对应泳道下的情况，如这个工作项在“开发中”，过了几天工作项可以流转到“测试中”，每个工作项都是流动状态的！
举个例子：A开发者正在开发“A工作项”，此时对应的状态是“开发中”，开发完成后 ，则流转到“已完成”，等到工作项上到测试环境，此时工作项流转到“测试中”，最后上线，任务流转到“已完成”。
这个看板可以是实际的黑板，用线条画出来，也可通过网上的工具，如TAPD的网络看板进行管理，关键在于呈现任务项的流动状态，和当前节点状态。
看板完成后，还需要完成任务项卡片的制作，卡片主要描述具体的任务项，完成时间和工时，描述清楚即可。
此时有了看板和卡片，则这个管理项目的工具已经完成了。
但是有了看板还不够，我们还需要通过“每日站会”来面对面沟通任务情况，每日会议的时间不能超过10分钟，每个成员时间控制在一分钟内。
每个团队成员都需要说三点：
1.我昨天做了什么
2.我今天做了什么
3.当前有什么风险，需要谁进行协助
通过站会，我们才能做到真正跟进开发任务项的完成情况，才知道这个任务项是否有风险；有风险的情况下，是加班解决，还是这个功能只能延期等等的解决方案。
我们通过看板和每日站会这两个工具，实时跟进了每个冲刺的具体情况，才能做到心中有数，把风险下降到最低。
需要项目管理资料合集的同学可先关注然后私信我哦
更多精彩内容请点击“了解更多”
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。