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