《敏捷估计与规划》读书笔记
发布于 2024-10-01
1707
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
麦哲思科技任甲林
扫码关注公众号
扫码阅读
手机扫码阅读
Summary
Chapter 1:
- 策划过程比计划书本身更为重要。
- 制定计划是必要的,但不应过度投入时间。
- 瀑布模型中存在不确定性,而PMI提供了三种估算偏差率:初步估算(误差范围+75%到-25%),预算估算(误差范围+25%到-10%),确定性估算(误差范围+10%到-5%)。
- 估算应该是渐进准确的,且项目计划中的很多决策都是基于折中。
- “plan”是文档的结果,“planning”是策划过程。
Chapter 2:
- 需求定义了做什么,计划定义了如何做,需求分析关注做正确的事,而策划关注正确地做事。
- 计划应基于功能而不是活动,且应聚焦于遗漏需求而非活动。
- 帕金森定律表明任务总是在最后期限前完成,多任务并行会导致效率低下。
- 迭代是应对不确定性的有效方法。
- 估算不应被视为承诺。
Chapter 3-4:
- 计划服务于价值的实现,响应变化至关重要。
- 敏捷开发小组应作为一个整体工作,进行短周期迭代,并交付成果。
- 敏捷规划是多层的,要区分验收准则的层次。
- 故事点衡量工作量、复杂性和风险,而开发速度由迭代中完成的故事点数度量。
Chapter 5-7:
- 需区分理想时间与耗用时间,确保管理者与成员对时间有统一理解。
- 投入时间的回报遵循渐减法则,估算应合理分配时间资源。
Chapter 8-11:
- 故事点与技术和执行人员无关,主题可划分优先级。
- 优先级划分考虑业务价值、开发成本、知识获取和风险减少。
- 需求优先级调查结果可通过矩阵汇总。
Chapter 12-14:
- 故事可按数据、操作边界等分割,避免按技术层次分割。
- 迭代计划中故事采用故事点估算,任务采用理想小时估算。
- 迭代计划采用速度驱动或承诺驱动方法。
Chapter 15-17:
- 迭代周期宜为2-4周,确定开发速度可依据历史速度、实验或估计。
- 项目应设置功能和进度缓冲区,以应对不可预测性。
Chapter 18-19:
- 多团队估算时需建立共同比较基准和单位,跨团队依赖应留缓冲区。
- 燃尽图和停车场图可展示项目进展。
Chapter 20-22:
- 任务板用于跟踪任务状态,燃尽图跟踪目标距离。
- 沟通估计与计划应频繁、诚实且双向。
- 敏捷规划有效因包括经常重计划和承认不确定性等。
Chapter 23:
- 用户故事workshop要全员参与,故事显然目的可省略。
- 故事估算时可讨论实现方式,定义开发能力时应减去会议时间。
麦哲思科技任甲林
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
471 篇文章
浏览 1063.7K
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
麦哲思科技任甲林的其他文章
案例:建立工作量分布过程性能基线
某应用软件开发公司积累了最近3年的29个项目的工作量分布历史数据,试图建立工作量分布的过程性能基线。在该公司内对项目从3个维度做了项目分类:规模:大,中,小;开发方法:全新开发,修改;类型:常规,紧急,优化,外包。 原始数据如下表: 对工作量分布的数据与项目类型做了方差分析,发现:对这些原始数据采用箱线图的方法进行分析后得到如下的结论:
漫谈敏捷方法中的信任
在实施敏捷的方法中需要组织建立信任的文化,即管理者信任项目组,可以放手让项目组去做事情。 人对其他人都是有信任关系的。你走在大街上,你不会认为你看到的任何人会过来刺杀你,否则你就会穿着一身盔甲上路了,这就是一种信任。 人对其他人的信任都不是无底线的。比如,当有人过来找你问路,找你推销商品时,你可能就避而远之,这就是一种不信任。 无约束的信任只可能是一些短期的、不重要的小事。
软件需求的12条最佳实践
笔者在咨询实践中总结了针对软件需求工程的12条最佳实践,罗列如下。所谓最佳并非严密的逻辑证明,而是经过大量的实践与观察依据经验确定的,智者见智,仁者见仁,有争议在所难免,仅供参考,能够对大家有所启发,足矣。1 成立甲乙双方参与的需求控制组项目的成功不单是乙方的成功,而是甲乙双方的成功,甲乙双方紧密配合,互相理解,互相合作才能成功,需要避免一方独大,一方具有绝对控制权的现象,所以成立甲乙双方参与的需求控制组是避免需求蔓延的有效手段。该组织具有对需求的决策权,对于每项需求的增删改都要平衡了进度、质量、投入后才
Lehman的软件演化定律
自20世纪70年代以来,M. M. Lehman通过对软件系统演化现象的观察,陆续总结了8条定律,称之为定律并非那么严谨,但是对于认识软件维护的规律,改进软件维护的过程具有很好的指导意义。1 (1974年)持续变更定律。系统必须持续调整以适应各种变化,否则这些系统将变得越来越不令人满意。2 (1974年)复杂度增长定律。随着系统的演化,其复杂度会逐渐增加,除非采取措施来降低或保持其复杂度。3 (1974年)自我调整定律。软件演化过程的是自调整的,每次演化版本的度量数据近似正态分布。4 .
流程管理的基本理念
澄清一下关于流程的基本概念与理念。
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线