项目管理沙龙第十方总结的敏捷实践——AOM项目-研发项目管理

>>项目管理沙龙第十方总结的敏捷实践——AOM项目-研发项目管理

项目管理沙龙第十方总结的敏捷实践——AOM项目-研发项目管理

引言:当今社会市场竞争激烈,软件开发企业想要占据前列需要在研发管理上下功夫,“向管理要效益”已经成为软件开发企业的共识,研发项目管理在软件企业中的普及也是大势所趋。国内做软件项目管理工具的开发商翼发云近几年发展十分迅速,越来越多的软件开发企业认识到研发项目管理的重要性,能切实有效降低成本,规范软件开发流程,提高软件产品质量。国内研发项目管理系统、敏捷开发管理工具的领导品牌翼发云敏捷项目管理系统采用可视化业务流程技术,支持瀑布模型等传统软件研发项目管理,同时也支持scrum等敏捷开发流程,是理想的敏捷开发管理工具,涵盖软件项目管理工作的整个生命周期。为提高国内软件开发企业的项目管理水平,分享一篇企业管理相关的知识文章。

项目管理沙龙第十次聚会纪要

会议一开始,就有人跟我们分享了一个名词,”分析瘫痪”,意思是不断地追求完美,结果始终在设计状态,无法到下一步去。详细可参考这个 http://hi.baidu.com/parad1se/blog/item/8724472a71b87e25d52af1a3.html 和 google。与会者都有同感。而破解”分析瘫痪”的诀窍,就是”敢于行动”,因为人就是在不断的错误中学习并改进的,不犯错,当然也就谈不上改进了。如果用沙龙常用的术语说,那就是”敏捷”。

今天的敏捷话题是分享AOM的敏捷过程。AOM是一个基础平台产品,在实施敏捷之前,采用周计划的模式来管理,即每周定制计划,组员按照计划完成工作,并且更新自己的工作状态。这种管理模式在需求控制,角色分工,任务分配和团队激励上,都存在较大的问题,所以AOM团队想到了利用敏捷方法来改进项目管理。所以这一点上AOM和NSEC最大的不同,就是AOM是主动”拥抱敏捷”,而NSEC是”被敏捷”。

AOM有产品经理(PO)的角色,负责需求的最终拍板。敏捷教练(SM)负责团队敏捷过程的正确性和改进,但是和一般 scrum 规则不同的是,SM是项目组之外的人,且不负责项目的进度,项目的进度由项目组自己来管理。项目组依然有项目经理(PM)的角色,但是在实行过程中,这个角色的作用被弱化了,变成了一些关键事务的协调人和PO的代理人。日常的进度监控工作,则由轮换的”主持人”完成。

在产品的计划会议上,AOM使用纸牌游戏的方式来对每一个任务评估point数。并且根据团队的能力,设置sprint计划的point总数。和NSEC不同,AOM不会在每一个sprint中预留point,而是将一些项目之外的事务变成backlog放到sprint中一起进行跟踪。如果外部干扰太大,就要及时调整sprint中未开始的backlog,删掉一些优先级较低的backlog,并且用更小的backlog弥补进来,并保持sprint总的point数不变。就像长跑的时候呼吸和脚步的频率要非常一致才能跑得很好一样,敏捷过程也很重视”节奏”。所以AOM的sprint时间长度也基本是稳定的,目前是两周一个sprint,部分为三周。

在产品的回顾会议上,所有的问题都会被分析一遍,对于投票最多的前三项问题,会在下一个sprint中生成backlog并分配专人跟踪和完成。其他问题,如果是规则性的,就会去更新规则。

每日站立会议上,主持人会先向大家通报一下上一个工作日的task完成情况和进度的预测,然后团队每个人再回答一下三个问题:昨天做了什么,今天做了什么,遇到什么困难。在日常任务的跟踪上,AOM通过纸质的任务看板和纸质的backlog卡来进行跟踪,每天下班前,主持人会根据看板的进度情况,敦促当事人及时更新任务卡片,并将任务卡片的进度数据同步到 scrum Works中(大家回忆起了读书时候的”课代表”)。每次站立会议都会有一个人记录会议纪要,并且将其内容登记在wiki上,以便全体成员(包括缺席人员)备查。

主持人机制在AOM敏捷过程中占据十分重要的地位,它负责对团队每个成员进行敏捷管理意识和能力的培养,通过角色轮换的方式,让团队成员获得一种比本职角色更高的角度去看待软件开发和管理,尝试他们以前不太有机会去尝试的团队管理或设计方面的工作。在AOM团队中,主持人按周轮换,除了跟进项目进度之外,还要负责控制会议的时间。

不同的会议,控制时间的基准也是不一样的。对于计划会议,则每个backlog的讨论时间=会议计划长度/sprint中backlog数目。对于每日例会,每个人发言时间=15分钟/发言人数,最长没人发言时间不超过(30分钟/发言人数)。回顾会议上,每个问题的讨论时间=会议计划长度/问题总数。另外,对于讨论和辩论,控制时间是每项讨论和辩论不超过1分钟。只要超过时间,主持人就会主动打断,维持会议效率。

AOM同时也引入了”结对”的机制。组员自由结对,分主副手。所有的任务要两个人同时签名才有效,主程序员负责编码,副手负责单元测试,并且在sprint结束之后,主副手角色调换,副手负责维护该部分代码,包括修改bug和增强功能。这种结对延伸到项目组的每一个方面,所以每天站立会议会议纪要,也是会议主持人的结对伙伴来记录的。

AOM的敏捷过程中,大家发现使用纸牌、看板、任务卡片的方式,使整个过程充满了”游戏性”,具有很强的”参与感”。组员之间互相关心,在任务分配上更公平,工作效率更高,每项任务中的职责分工更明确,当然产品的质量也更高了。而且轮换主持机制让每个人都有更多的角色体验,可以让PM空出来思考更深层的问题。

目前AOM尚未在每个sprint结束之前进行show case。

与会者在讲述过程中插入了很多的讨论和分析,大致有如下几个话题:

与会者首先关心的是”需求来源”问题。因为项目的特殊性,AOM的需求更多来自于团队的拍脑袋,其次是公司内其他项目提出的要求。与会者一致认为,不管怎样,”有目的的手机用户需求”是肯定的,但是需求的筛选也是值得注意的方面,要结合项目的目标来进行。比如iPhone多半可以肯定不会去实现什么”双卡双待”和”收音机”的功能。但是有时候的”拍脑袋”和”摸着石头过河”也是不可避免的。这就要求PO充分担负起责任来,PM也要担当一下,比如某些需要预研才能确定做不做的技术,就要先动起来。

关于showcase,有人发现公司的一个怪现象:”产品的名字大家都听过,但是长相大多都不知道”。仅从这个意义上去看,showcase的重要性也是不言而喻的。大家一致的意思是要用起来,因为它可以让团队充分感受到目标和时间的压力。但是初期不一定非要每个sprint都show,在掌握方法之后慢慢提高,最终达到每个sprint都show的程度。但是一定要注意showcase是要求不要做特别的准备的,也就意味着showcase的成果就是日常工作成果。

“到底有多敏捷”是与会者提出的一个问题,有人觉得公司内部的过程改进组织就应该来回答这种问题,通过对项目组敏捷过程的观察,给出一个敏捷的级别,并且以此来逐步指导和提高项目组的敏捷程度。

有人关心”任务没有人领”的问题,经过讨论,我们发现虽然有部分任务会存在只有某人能够完成的情况,但是只要经过细分,大部分任务的难度都会降下来,并降到其他人也可以认领的程度。有人发现如果能够将”个人学习计划和任务结合起来”,是可以降低某些任务对人的依赖性的。

“如果团队中有破坏者怎么办”,这是有人用”六顶思考帽”的思考方式提出的问题。但是大家在讨论中发现,利用每日例会和看板,我们很容易发现那些虚假的进度汇报,并且敏捷中持续的沟通,让谎言在其中生存的难度变得极大。一旦”破坏者”被发现,要么被清除出团队,要么自动离开,或者痛改前非,融入团队。

在分析”轮换支持”机制的时候,有人举例了IBM的60%工作,40%沟通的时间安排比例,谈到了如何让员工更多思考,聪明工作的问题。不过未展开。

敏捷其实不是一种新生的事务,无论从其指导思想,还是各种使用的工具和方法,大部分都是敏捷提出之前就已经存在的,比如看板就是源自丰田的精益管理方法,每日例会则来自于服务行业。现在敏捷已经不仅限于软件开发,在市场销售、公司管理都有应用案例。

最后,有人提出”敏捷管理方法如何在餐厅运用”的问题,引起了大家热烈的讨论,但是考虑到沙龙的时间,讨论在一片欢乐中结束,不过我们不排除以后会抽出一个专题来讨论这个问题。

文章从互联网整理而来,旨在传播scrum、软件项目管理、研发项目管理、敏捷开发管理工具的知识与应用,帮助软件开发企业真正了解研发项目管理的价值和意义,如果本文侵犯了您的权益或者您需要具体了解更多国内做研发项目管理系统的公司翼发云敏捷项目管理系统的相关信息,欢迎和我们联络:

【网址】www.effapp.com

2018-03-01T17:59:44+08:002018-03-01 17:59:44|Categories: scrum项目管理|