中国住房城乡建设部网站首页,wordpress英文导航模板,wordpress主机pfthost,什么是权重高的网站项目管理沙龙第十次聚会纪要会议一开始#xff0c;就有人跟我们分享了一个名词#xff0c;“分析瘫痪”#xff0c;意思是不断地追求完美#xff0c;结果始终在设计状态#xff0c;无法到下一步去。详细可参考这个 http://hi.baidu.com/parad1se/blog/item/8724472a71b87e…项目管理沙龙第十次聚会纪要会议一开始就有人跟我们分享了一个名词“分析瘫痪”意思是不断地追求完美结果始终在设计状态无法到下一步去。详细可参考这个 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卡来进行跟踪每天下班前主持人会根据看板的进度情况敦促当事人及时更新任务卡片并将任务卡片的进度数据同步到ScrumWorks中大家回忆起了读书时候的“课代表”。每次站立会议都会有一个人记录会议纪要并且将其内容登记在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%沟通的时间安排比例谈到了如何让员工更多思考聪明工作的问题。不过未展开。敏捷其实不是一种新生的事务无论从其指导思想还是各种使用的工具和方法大部分都是敏捷提出之前就已经存在的比如看板就是源自丰田的精益管理方法每日例会则来自于服务行业。现在敏捷已经不仅限于软件开发在市场销售、公司管理都有应用案例。最后有人提出“敏捷管理方法如何在餐厅运用”的问题引起了大家热烈的讨论但是考虑到沙龙的时间讨论在一片欢乐中结束不过我们不排除以后会抽出一个专题来讨论这个问题。转载于:https://www.cnblogs.com/BigTall/archive/2011/12/27/2302726.html
