《敏捷估计与规划》读书笔记
发布于 2024-10-01
1277
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
麦哲思科技任甲林
扫码关注公众号
扫码阅读
手机扫码阅读
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 篇文章
浏览 829.8K
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
麦哲思科技任甲林的其他文章
文档恐惧症的分析
一、为什么不愿意写文档?大部分开发人员不愿意编写文档,为什么呢?1.写文档需要花费很多时间。2.不愿意暴露自己的思想被别人评判。3.文档编写得不好、没有充分发挥作用。4.根据实践经验,并非不写文档,项目就干不下去。有很多客户也这样对我讲:“我们原来没有那么多文档,项目照样干,客户也一样验收付款啊!”。5.如果写文档,很容易造成文档与实现不一致,文档的价值大大降低。6.如果写文档,就不能只写一份文档
实例:评审速度与缺陷密度之间的相关性
某公司的项目分为两类:MIS类软件开发与嵌入式软件开发,对这两类项目的需求评审的速率与需求评审发现的缺陷密度分别积累了度量数据,分别见表一和表二,共计52次的需求评审数据。 表一:MIS软件开发项目的需求评审度量数据 表二:嵌入式软件开发项目的需求评审度量数据 对这两类项目的需求评审的速率与缺陷密度分别画散点图如图一和图二所示。 图一:MIS软件开发项目需求评审的缺陷密度
PMO、EPG与QAG职责分工
PMO、EPG与QAG职责分工 有很多人对PMO、EPG与QAG的关系理解比较混乱,因此整理此文以澄清一些误解。 1 PMOPMO(Project Management Office)是项目管理办公室的简写,是在PMBOK中建议的一种组织机构,其主要职责是:Ø 定义项目管理流程;Ø 培养项目经理团队;Ø 建立项目管理信息系统;Ø 对项目提供顾问式指导;Ø 监督项目进展情况;Ø 开展多项
一个敏捷项目的咨询记录
近日对一个敏捷项目进行了2小时的简单访谈,对他们的一些实践点评如下:综述: 1 敏捷的实践看着简单做着难,实践少,但是实践的很多细节要做到位。 2 要让团队的成员知其然知其所以然,才能够进行经验化过程控制。 3 要在团队内建立承诺的文化,说到一定要做到。 4 目标、需求、任务、任务状态、问题、团队规则都要可视化! 5 牺牲质量追求速度,是
例解:集成测试用例与单元测试用例的区别
函数一: getMaxInTwo(int a,int b) { if a>=b return a; else return b; } 函数二: getMaxInThree(int a,int b,int c) { a=a+1; int max=getMaxInTwo(a,b); max=getMaxInTwo(max,c); } 单元测试用例的设计: getMaxInTwo的UT用例: (3,2)
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线