估算是经久不衰的管理话题,大致分为两种流派。
第一种是领导指派,领导说这是10天的活,就必须当是10天的活来干,如果干不完,可以用加班、损失质量、功能缩水等各种方法曲线救场。另一个变种是大家自己估算,但是交给领导审批;领导审批其实就是砍一半的过程,还好大家之前就已经加了一倍,所以不怕。
第二种是自我管理派(偏敏捷),就是由具体开发的人员自己说开发工作量,领导和他人不干预。尽管“自组织”了,但是领导深以为这种方法留下了偷懒的种子,而队员也觉得某人的估算很不靠谱(太长或太短),到底怎么办呢?
共同估算吧。
--------------------------------------------
基本概念
假设现在是一个计划会上,PO(产品经理,策划组长,项目经理,某销售……)刚刚讲完需求,下一步不是交给某人做估算,而是交给某个潜在的组(师傅+1~3徒弟)。
由师傅带头打牌,对,在计划会上玩扑克:
1. 大家各自思考可能要花多久时间完成任务,扣一张牌出来;
2. 师傅喊开牌,大家亮牌,比较大小;
3. 一般最小和最大的两个人PK,说出自己的观点,大家一起讨论;
4. 差异无非来自于两个方面:做什么,怎么做;PO参与讨论回答做什么的问题,师傅和徒弟们讨论解决怎么做的问题;
5. 讨论过后再来几轮,直到大家觉得结果差不多了。
扑克牌估算的匿名性和开放性保证了大家不会人云亦云,也不会因为缺少沟通而难以达成一致。
笔者的经验是一局扑克牌估算大约持续1~5分钟,还是很快的。偶然有黄庄的,一般都是因为PO那里回答不了做成什么样子,某某附加功能是否也要做……等等问题时。
几个问题
1. 为什么分给组而不是个人?
不分个人就打牌使得每个人都不得不思考,因为怕出错了牌又说不出所以然。这样即使日后他不做这个功能,也对这个功能很了解。
2. 为什么不让最后领任务的人自己估算?
因为他很可能因为不知道某代码可用、不知道某软件不行、不懂template(我们因此扔过1个人月代码)……而选择了错误的实现方法。
3. 为什么不让师傅估算大家采纳,他不是最厉害吗?
师傅的想法常常是徒弟们理解不了的——比如为什么不留在女儿国而偏偏去西天取经之类的,呵呵——共同估算就是让大家在思考中对照自己的实现方法和师傅差异的过程。
4. PO怎么还参加?不是不让别人干预吗?
很多问题比如在游戏中“显示武林排行榜”,具体工作量可能不在于怎么做而在于做什么:凭什么排名?排多少名?实时排名还是每周排名?怎么显示排名?……因此PO不能写出一堆文档,然后以不便干预估算为名不参加敏捷计划会议。
PO可以挑战估算,比如:“这真的要这么久吗?我记得上次……”但要有理有据。其实实践中更容易看到的是,团队往往过于激进乐观,PO反而要让他们意识到完整的需求和要求,做出更现实的估算。估算不准确,PO也有责。
5. 一直无法达成一致怎么办?
其实估算不是为了最后那个数字,而是弄清楚做什么和怎么做的问题,如果这两件事情清楚了,但结果却是偏偏有人说4天有人说6天,随便取个数就可以了(事实是应该按墨菲定理取6天)。有师傅在,一般很少会就实现方法争执不下;有PO在,一般很少会就要实现什么争执不下。
不排除有特殊情况比如PO发现自己也没想过排行榜凭什么排行,那么就应该搁置此用户故事;又比如大家觉得如果数据库给力可能实时排名也行但又拿不准,可以暂时搁置到开发的时候再说,但把故事上标注一下“若需要每周自动排名+1天”。如果经常黄庄,Scrum Master要分析总结避免。
6. 四个人出牌不同,师傅先说还是徒弟先说?
想起个脑筋急转弯:科学家 医生 士兵 护士 ……等等一群人在飞机上,飞机结冰快坠落了需要有人(可能不止一个)跳下去,问谁跳?答案是从体重最重的人开始跳,因为可以少跳几个。
因此我们是出牌数字最小的先说,和师徒无关。因为他极有可能掌握最佳实现方法。如果后来发现不是如此,请参考下一条。
7. 都有什么理由可陈述?
按下面的顺序,越靠前的越接近真理,感觉自己接近真理的就一定要举手先说,马后炮招人嫌:
经验事实:我以前做过……咱们有个类库……那个方法我试过不可行……
蛛丝马迹:谁还记得上次……听说隔壁……与上回相比……你以前不是……
逻辑推理:理论上说……我觉得……
几个注意事项
1. 小组内不要有强分工,否则大家会缺省认为肯定是某人的工作。
2. 师傅不要太抢眼,要通过估算鼓励徒弟思考,同时也掌握徒弟的真实水平。
3. 师傅不要太较真,编程规范、易用性、易维护性这些纪律不能放松,但如果徒弟想尝试一种不同但工作量也差不多的方法,可以适当鼓励。
4. Scrum Master监控整个过程,防止太细/争执……等问题。
5. PO必须参加。
----------------------------------------------------------
共同估算依靠PO的参与解决了做什么的问题,依靠师傅的带动解决了怎么做的问题。
共同估算是“跨职能团队”的基础活动之一,之后他们之所以能在每日立会上分享当前进展与困难,就是因为当初是他们一起思考这一任务的,因此对这一任务后来的实际情况非常关心。在发生问题的时候,大家也更可以互相帮助,而不是毫不所知。
ref:http://blog.csdn.net/cheny_com/article/details/6587277
分享到:
相关推荐
此外,还会涉及敏捷估算技术,如故事点和计划扑克,以及敏捷质量管理工具,如测试驱动开发(TDD)和结对编程。 最后,"轻松Scrum之旅.pdf"可能是对Scrum框架的一个全面指南。Scrum通常由产品负责人、Scrum Master和...
其关键实践包括结对编程、测试驱动开发、重构、简单设计和规划游戏等。 Kanban方法则更注重流程可视化和限制工作在制品(WIP),通过优化流程来提升效率和响应速度。 总的来说,敏捷开发不仅是一种开发技术,更是...
5. **XP(极限编程)**:XP注重编码和测试的质量,推崇持续集成、测试驱动开发(TDD)、结对编程和简短的发布周期,以实现快速反馈和高质量代码。 6. **敏捷团队**:敏捷团队通常小而自组织,具备所有必要的技能,...
XP通过持续集成、结对编程、单元测试等实践来确保软件质量,并且鼓励客户参与开发过程,以便及时调整需求。 PSP(个人软件过程)是敏捷开发中的一种自我改进工具,它强调高品质、测试过的、完整的以及应该做到的都...
3. **极限编程(XP)**:XP是一种强调团队协作、持续集成和测试驱动开发的敏捷方法,书中可能涵盖其核心实践,如结对编程、持续集成、用户故事等。 4. **看板系统**:看板作为一种可视化工具,帮助团队管理工作流程...
XP注重编程实践,如结对编程、持续集成和测试驱动开发。 3. 用户故事与敏捷规划 用户故事是从用户角度描述功能需求的小型叙述,通常采用“作为一个<角色>,我想要<功能>,以便于<价值>”的格式。敏捷项目规划围绕...
4. **结对编程**:两个开发人员共享一个工作区,一起编写和测试代码,提高代码质量,及时发现错误。 5. **自动化测试**:利用工具创建和维护一套自动化测试套件,包括单元测试、集成测试和验收测试,以支持频繁的...
极限编程是另一个重要的敏捷框架,包括测试驱动开发(TDD)、结对编程、持续集成等实践,这些方法旨在提高代码质量,减少缺陷,并促进团队协作。 5. **设计模式**: 在敏捷开发中,设计模式是解决常见问题的有效...
其关键实践包括测试驱动开发(TDD)、结对编程、持续集成、简单设计、重构和客户参与。XP的核心目标是提高软件的质量和生产力,同时降低风险。 4. **精益开发**:借鉴了精益生产的思想,精益开发强调减少浪费、增加...
【敏捷开发修炼之道】 在软件开发领域,敏捷开发是一种强调迭代、快速响应变化和高度协作的方法论。它提倡灵活应对需求变化,通过短周期的迭代和增量式交付,以提高团队效率和客户满意度。"敏捷开发修炼之道"这一...
在每个阶段,团队会进行一系列敏捷活动,如站立会议、结对编程、故事点估算、头脑风暴会议、需求分析、测试用例编写、持续集成(虽然本次培训未实现)等。在整个过程中,团队通过回顾会议来识别问题,制定改进措施,...
6. **质量保证**:敏捷开发认为质量是每个人的责任,书中可能涉及测试驱动开发(TDD)、结对编程等实践,以确保软件的质量。 7. **度量与改进**:敏捷方法鼓励持续改进,书中可能介绍如何通过度量团队性能、客户...
在模式部分,Uncle Bob阐述了一系列适用于敏捷开发的实践模式,包括短期迭代、持续集成、结对编程、测试驱动开发(TDD)等。短期迭代允许团队在短时间内交付可用的软件,通过频繁的反馈进行调整;持续集成确保代码库...
- XP(极限编程):XP注重编码质量和团队协作,包含结对编程、测试驱动开发、持续集成等实践,以减少缺陷,提高代码质量。 - 敏捷估算和规划:使用故事点进行相对估算是敏捷开发中的常见做法,帮助团队预测工作量,...
6. **结对编程**:这是一种敏捷实践,两个程序员共享一个工作站,一起编写代码。这有助于减少错误,提高代码质量,并促进知识共享。 7. **持续集成**:持续集成强调频繁地将代码集成到主分支,每次集成都通过自动化...
XP则注重代码质量,提倡测试驱动开发(TDD)、结对编程等实践。Kanban则关注流程可视化和持续改进,以实现工作流的顺畅。 在实际操作中,敏捷开发强调规划的迭代性。每个迭代开始时,团队会确定本次迭代要完成的...