《敏捷估计与规划》读书笔记
发布于 2024-10-01
1005
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
麦哲思科技任甲林
扫码关注公众号
扫码阅读
手机扫码阅读
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 成员,中国分部主席
425 篇文章
浏览 642.9K
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
麦哲思科技任甲林的其他文章
不要这样做CMMI
很多公司在做CMMI,很多公司也在重复这种错误:“证书优先,机械照搬,文档泛滥,似严实宽。”!1“证书优先”。CMMI的证书成了一个敲门砖,没有这个证书难以承担国外的项目,没有CMMI的证书就难以在国内一些项目的竞标中获胜,也无法获得政府的补助,于是很多公司都选择了要在短时间内获得CMMI证书。证书只是过程改进的附属物,而过程改进的实效才是其真正的价值。为了尽快拿到证书,企业往往忽略了实效,从形式
如何度量项目的总体进展?
在跟踪项目的总体进展时,传统的方法是采用挣值图进行跟踪,敏捷的方法是采用燃尽图或燃起图进行跟踪,精益的方法是采用累积流量图跟踪总体进展。在一家公司内有采用短周期迭代开发的,有采用传统瀑布模式开发的,有新品开发的项目,也有软件维护的项目,那么有无一种适合于所有类型项目的统一方法跟踪项目的总体进展呢?下面就介绍一种计算简单、易于理解的方法,它可以跟踪总体进展,也可以适合跟踪局部进展。
企业管理软件的需求获取方法
作者:任甲林 来源:希赛网 在需求工程中,需求获取阶段是和用户交往最多的一段时间, 而绝大部分用户是不懂得需求分析方法的,他们不知道怎样全面而又准确无误地表达自己的需求,因而对于需求分析人员来讲,需要掌握很好的方法与技巧,恰当地启发引导用户表达自己的需求,以便为项目的成功提供一个很好的基石。 一 需求获取的2个基本原则 1 深入浅出 对企业的需求调研的要尽可能的全面、细致,调研的需求是个
尽快报告坏消息
项目管理的一个主要原则就是尽早报告坏休息,比如:需求的错误,代码的错误,进度的延期,技术的障碍等等。有哪些手段可以报告坏消息呢? 在上述的手段中,在代码完成之前的措施是属于“尽早”发现坏消息的手段,是修复缺陷成本最低的手段,是我们应该优先落实的。 不同的项目根据自己的实际情况,对这些措施进行裁剪,也可以创造自己新的一些实践,以
控制图典型错误应用一例
有公司在画控制图时,对进度偏差率画了XMR控制图。原始数据如下: 度量日期 开发进度偏差率 05-14 -2% 05-19 0% 05-21 -1% 05-22 -2% 05-23 -2%
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线