敏捷项目管理
2023-12-11 10:17:44 0 举报AI智能生成
登录查看完整内容
敏捷项目管理是一种以人为核心、迭代、循序渐进的项目管理方法。它强调在项目开发过程中，不断与客户沟通反馈，及时调整项目方向和进度，以达到最终目标。敏捷项目管理通常采用团队协作的方式，通过每日站会、迭代计划会议、回顾会议等手段来保证项目的顺利进行。与传统项目管理相比，敏捷项目管理更加注重灵活性和适应性，能够更好地应对需求变更和技术风险。同时，它也能够帮助团队成员更好地发挥自己的创造力和想象力，提高项目的质量和效率。
作者其他创作
大纲/内容
8.1 发布（项目）计划
8.2 基于愿望做计划（平衡能力和需求）
8.3 多层计划
8.4.1 性能用例
8.4.2 创建产品功能清单和路线图
8.4.3 最有计划结构
8.4 性能
8.5.1 价值点确定：角色和时机
8.5.2 计算相对价值点
8.5.3 计算货币价值点
8.5.4 不面向客户地故事
8.5.5 价值和优先级
8.5 价值点分析
8.6.1 计划主题和优先级
8.6.2 提高生产率
8.6.3 风险分析和降低
8.6.4 计划和扫描
8.6.5 时间框定规律
8.6.6 其它故事类型
8.6.7 在制品与制成品
8.6 发布计划主题
8.7.1 看板
8.7.2 联合开发
8.7.3 超开发和发布
8.7 新做法
8.8 结束语
第8章 改进发布计划
9.1 敏捷项目领导
9.2.1 迭代计划
9.2.2 工作量管理
9.2.3 监督迭代进程
9.2 迭代计划和监督
9.3.1 技术债务
9.3.2 简单设计
9.3.3 不断集成
9.3.4 无情测试
9.3.5 不失时机地重构
9.3 技术做法
9.4.1 是团队精力集中
9.4.2 将一群人塑造成一个团队
9.4.3 开发每个人地能力
9.4.4 移山引水
9.45 教导客户
9.4.6 是团队地节奏保持一致
9.4 提倡和团队开发
9.5.1 决策形式
9.5.2 做决策
9.5.3 决策回顾
9.5.4 领导力和决策
9.5.5 基于组和基于延期的决策
9.5 参与式决策
9.6.1 每日站立会议
9.6.2 与产品团队的日常交互
9.6.3 协调利益相关方
9.6 合作与协调
9.7 结束语
第9章 探索阶段
10.1 适应
10.2.1 客户中心组
10.2.2 技术评审
10.2.3 团队绩效评估
10.2.4 项目进度报告
10.2.5 适应措施
10.2 产品、项目和团队评审即适应措施
10.3 结束阶段
10.4 结束语
第10章 适应和结束阶段
11.1.1 规模扩展要素
11.1.2 向上和向外
11.1.3 不确定性和复杂性
11.1 规模扩展的挑战
11.2 敏捷扩展模型
11.3.1 组织设计
11.3.2 协作/协调设计
11.3.3 决策设计
11.3.4 知识共享和文档
11.3.5 团队中的自我组织团队
11.3.6 团队自律
11.3.7 流程纪律
11.3 组件大型敏捷团队
11.4.1 产品体系结构
11.4.2 路线图和功能清单
11.4.3 多级发布计划
11.4.4 维护可发布产品
11.4.5 团队间职责协议
11.4.6 工具
11.4 向上扩展-敏捷做法
11.5 向外扩展-分布式项目
11.6 结束语
第11章 敏捷项目扩展
12.1.1 投资和风险
12.1.2 主管级的信息要求
12.1.3 工程级信息的产生
12.1.4 企业级治理模型
12.1.5 使用敏捷治理模型
12.1 投资组合治理
12.2.1 设计敏捷投资组合
12.2.2 敏捷方法”拟合“
12.2 投资组合管理主题
12.3 结束语
第12章 治理敏捷项目
13.1 质量是什么
13.2.1 适应性绩效-结果和产出
13.2.2 评估问题
13.2 计划与评估
13.3.1 超越预算
13.3.2 评估组织绩效
13.3.3 适应性绩效管理系统（APMS）设计指南
13.3 评估概念
13.4.1 约束
13.4.2 社区责任
13.4.3 提高决策
13.4.4 以计划为指导
13.4 结果绩效的衡量指标
13.5.1 五项核心度量指标
13.5.2 结果和产出
13.5 产出绩效的衡量指标
13.6 缩短尾巴
13.7 结束语
第13章 超越范围、进度和成本：评估敏捷绩效
14.1 新产品开发的新趋势
14.2 敏捷人员和流程交付敏捷产品
14.3 可靠的创新
14.4 不断增值的项目经理
14.5 结束语
第14章 可靠的创新
最终客户价值是在销售时交付，不是在计划时交付
客户价值
商业软件产品
带嵌入式软件的工业产品（从电子设备到汽车）
内部开发 IT 项目
包含的领域
第1章 敏捷革命
新产品
新服务
新意识
提供价值
满足当前客户的需要
1.1.1 持续创新
销售市场
技术
特殊要求
每周都变
数月甚至几年
产品背景
变化加速
反应时间缩短
why？
提高适应能力
现在提供客户价值的能力
创造适应性产品的能力
卓越技术判定
减少技术债务
满足未来客户的需要
1.1.2 产品适应性
突出重点
简化流程
培养技能
满足市场，提高投资回报率
1.1.3 缩短交付进度
乐于变革
鼓励学习和适应
项目管理
一支适应能力强的队伍
对产品和企业变化做出迅速反应
1.1.4 人员和流程适应性
重复的流程是指按照同样的方式做同样的事情并产生同样的结果
可靠是指无论在生产过程中遇到什么障碍，都能达到目标，他意味着为达到一个目标而不断改变
支持业务增长和盈利能力
1.1.5 可靠的结果
1.1 敏捷商业目标
敏捷是制造并响应变化从而在动荡的商业环境中创造利润的能力
敏捷是平衡灵活性和稳定性的能力
1.2 敏捷的定义
是态度不是流程
是氛围不是方法
在业绩优良的团队中，领导管理原则，而原则管理团队
个体和互动高于流程和工具；
工作的软件高于详细的文档
客户合作高于合同谈判；
响应变化高于遵循计划
4大敏捷宣言
我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意
欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
业务人员和开发人员必须互相合作，项目中的每一天都不例外。
激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
可工作的软件是进度的首要度量标准。
敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
以简洁为本，它是极力减少不必要工作量的艺术。
最好的架构、需求和设计出自自组织团队。
团队定期地反思如何提高成效，并依此调整自身的举止表现。
12大敏捷原则
1.3 敏捷领导价值观
提高可交付的产品
价值
提高可靠的、适应性强的可交付产品
质量
在可接受的约束内，实现价值和质量目标
约束
3个目标
1.4 敏捷绩效评估
4个管理层面的敏捷组织架构
构想
推测
探索
适应
结束
敏捷项目管理交付方法的5个阶段
1.5 敏捷项目管理架构
通过持续创造客户价值来提高投资回报率
成功的秘笈很简单，今天交付明天适应
不同于产品微小改进
想象不到的产品
帮助探索看似不可能的额事情
探索型项目
新产品/新服务
新商业模式
新流程
新业绩
不拘泥于形式
2.1.1 创新
交付活动增加价值
计划和控制增加管理费用
精力
项目经理
促进产品构想的构思
指导团队实现构想
而不是保证”计划得以施行“
执行模型
2.1.2 执行
分析项目活动保证在交付活动上的时间最多
分析团队成员活动，确定从事交付活动还是合规活动
2.1.3 精益思维
2.1 持续创造客户价值
如果想创新，必须迭代
建造版本
短期开发
评审
修改
扩展
迭代
模拟
模型
设计团队建造产品功能
基于功能
1~4个星期
有结果
强制迭代结束
制造出部分实体
时间狂
增量
组成部分
2.2 迭代、基于功能的交付
可交付客户价值
技术债务
低质量
问题积累
高品质确保未来交付价值
团队从卓越技术到完美之间的平衡转换点
产品经理在紧盯速度和功能时，忽略了适应能力
必须知道
不必权威
足够的知识
适应能力和低成本迭代的关键
卓越技术的拥护者
讨论和决定开发的技术方法
不忘企业目标
确保团队重复消化吸收项目资料
避免不良技术决策导致流程问题
具有技术背景
项目领导
执行说过要做的事情
支持纪律
反对形式化
流程、过程和文档
反对大量直观设计
新兴设计
频繁反馈
支持
技术质量未忽略设计
敏捷方法权宜之计？无纪律？技术低下？
2.3 卓越技术
如果想让船走得更快，那么割断锚绳比加大马力要来得容易。--- 卢克。霍
简化非常关键，它是最大程度地减少不必要工作地艺术。 --- 《敏捷宣言》
一套简单正确地规则，应用到一个高度相互作用地群体中，然后产生诸如创新和创造力之类地复杂行为
非常高地价值
适用于几乎每个项目
一个系统在一起正常运转地最小单元。
总是将 IT 活动与商业活动保持一致
云用良好地经济学判断
灵活变通
对组织地其他人产生共鸣
4条规则确保共同奋斗目标
2.4.1 再生规则
迅速但不仓促
复杂问题简单化
制定刚刚足够地流程
找到快速和仓促之间地分界线
无疑有更高地成功几率
领导者
2.4.2 刚刚足够的方法论
交付价值
首要任务
减少错误、欺骗、劣迹和财务透支地风险
合规活动
2.4.3 交付活动与合规活动
2.4 简化
子主题
2.5 结束语
第2章 价值胜过约束
在战斗中，你管不了人，你只能管事情，并领导别人。---- 海军上将格雷斯。霍珀
领导者真正的权力不是自上而下委派的，而是自下而上赢得的。
指挥者知道目标，领导者把握方向；指挥者发号施令，领导者施加影响；控制者提出要求，协作者加以促进；控制者事事管理，协作者不断鼓励。支持领导-协作模式的经理非常清楚他们的主要角色是设定方向、提高指导以及促进人们与团队之间的联系。
在混沌时代，成功较少取决于生搬硬套而更多的是依赖于理智；较少取决于少数人的权力而更多的是依赖于多数人的判断；较少取决于强制而更多的是依赖于鼓励；较少取决于外部控制而更多的是依赖于内部纪律。--- 迪。霍克
3.1 领导团队
自我组织的团队的特征不是缺乏领导，而是一种领导风格。
找到合适的人员
清楚表述产品构想、界限和团队角色
鼓励协作
坚持负责
培养自律
引导而不是控制
创建自我组织的团队需要
人员比流程重要
产品是由能干的、技术熟练的人员制造的，不是由流程控制的
没有合适的人员，不能建造任何产品
精力不在产品上，无关系活动会渗入
没有最低限度流程框架，会效率低下，甚至混乱
重点依次是人员、产品、流程
3.2.1 找到合适的人员
激发成员使命感和责任感
每个团队成员都有责任提高团队协作
3.2.2 坚持负责
自律是自由和授权的前提
对结果负责
用严谨的思维对抗现实
参与激烈的交流和争辩
愿意在自我组织框架内工作
尊重同事
自律的个人
建立在能力、坚持和愿意程度结果的责任之上
才干不仅是技能和能力，是态度和经验
自律
3.2.3 培养自律
3.2 建立自我组织（自律）团队
决策是协作的心脏和灵魂
妥协造成两极分化，重新构思导致联合
3.3.1 参与式决策
演示、原型、模拟和模型是相互交流的催化剂
开发、市场、客户、经理做重大意义的相互交流
需求文档缺乏质量
讨论原型、致力于功能
直观化
原型得到所有利益相关方的理解
公共性
要求
3.3.2 共享空间
创造并管理功能清单
确定发布和迭代计划的优先级
辨别并定义功能
定义接受标准
审核并接受完整的功能
和开发团队持续交流
为结果和调整约束负责
客户参与敏捷项目的部分责任
3.3.3 客户合作
3.3 鼓励协作
改变领导方式
敏捷项目无领导或者谁是领导却决于不同的情境
摆脱观点
适宜的领导保留适当的决策权与授权给团队结合的方式
授权型自我组织团队的支持者已经过时
授权型过时
问题
3.4 不再需要自我组织团队
第3章 团队胜过任务
传统项目管理者注重按计划行事，尽量做到和计划没有出入；而敏捷项目领导这关注如何成功的去适应不可避免出现的变化。
预测不确定性，并设法通过迭代、预防、适应来应对不确定性；
通过使用根据具体情况而定的策略、流程和实践来提高效率和可靠性
响应变化胜过遵循计划
即使在开发后期，也乐于接受变化的需求，敏捷流程重复利用变化以增加客户竞争优势
团队定期反省如何做到更有效，然后相应调整团队行为
《敏捷宣言》和《相互依赖声明》
预测变化（不确定性），然后做相应调整，而不是遵循国企计划
根据需要调整流程和做法
在发布产品得同时，是否交付了价值？
是否实现了创造可靠的、具有适应性得产品质量目标？
项目进度是否满足可接受得要素范围？
团队是否在有效地适应管理、客户和技术等方面的变化？
评估流程得4个问题
适应可以看作是对变化做出的深思熟虑的回应
概括
适应性原则
4.1 适应学
4.2 探索
4.3 响应变化
4.4 产品、流程和人员
4.5 障碍还是机会
4.6 可靠但不重复
4.7 反思和回顾
4.8 从原则到做法
4.9 结束语
第4章 适应胜过遵循
主管们需要一个通用的而架构，评估所有的项目
项目的价值
投资
获取该价值的确定性和不确定性
风险
解决
一套管理机制
5.1.1 投资组合治理层
构建产品
团队构想
开发项目范围
设定边界
制定全面的功能发布计划
项目发布计划
与核心小组外围利益相关者合作
与供应商合作
全面的项目/发布活动
每个团队一个迭代经理
整个项目一个项目经理
4个团队的大项目可能
项目管理和迭代管理可以是同一个领导者也可以是不同领导者，取决于项目大小
5.1.2 项目管理层
计划
执行
团队领导
短期迭代
5.1.3 迭代管理层
持续集成
自动化测试
敏捷软件的核心
变革技术实践
5.1.4 技术实践层
5.1 敏捷企业架构
企业目标
构想、探索、适应文化
自我组织、自律的团队
根据项目的不确定性程度，尽量提高可靠性和连贯性
保持灵活的易于适应
流程透明化
合并知识
囊括支持各阶段的做法
提供管理检查点
图片
产品及项目范围构想
项目目标
控制要素
提供什么
产品构想
客户
产品经理
项目团队成员
利益相关方
构想参与者都有谁
项目社团
团队如何工作
5.2.1 阶段：构想
发布计划
确保交付构想的产品
收集初始的、广泛的产品要求
将工作量定义为一个产品功能清单
制定一个迭代、基于功能的交付计划
将风险策略纳入计划
估计项目成本，并生成其它必须要的行政管理和财务信息
推测阶段
5.2.2 阶段：推测
短期内计划
经测试的功能
减少项目风险
减少不确定性
探索交付产品功能
通过管理工作量和使用适当的家属方法和风险降低策略，按计划交付产品功能
建立协作的、自我组织的项目社团，是每个人的责任但需要项目经理和迭代领导者推动
管理团队与客户、产品经理和其他利益相关方的相互交流
3个关键的活动区域
5.2.3 阶段：探索
审核提交的结果
审核当前情况
审核团队绩效
必要时做出调整
控制和纠正
5.2.4 阶段：适应
终止项目
融入下一次迭代
传递给下一个项目团队
交流主要的学习成功
庆祝
5.2.5 阶段：结束
早期概念构想阶段
晚期配置阶段
未包含
5.2.6 不是完整地生命周期
没有最好的做法，只有更适合具体情况的做法
简单的
再生的而非常规性的
与敏捷价值观和原则一致的
关注交付活动（增值）和非合规活动
刚好可以完成工作的
最少数量的
做法系统
相互支持的
指导原则
5.2.7 选择和整合做法
一切工作都应该是循序渐进的，即使是架构开发。序列开发中前期架构出错通常意味着长期适应性较差，因为没有人能够承受得起在项目晚期再改变架构
5.2.8 需要具备地判断力
无论规模大小均适用
5.2 敏捷交付架构
扩展的 APM 交付架构图片
项目章程
项目范围和界限
准确性评估
骨架结构
构想阶段
故事 ID
1-4 周一次
需求
开发
需求估计
迭代计划
准备和计划
编程
需求测试 TOO
演变设计
重组
结对
需求对话
系统和集成测试
客户接受测试
用途测试
质量评估和接受测试
客户关注小组
技术评审
项目状态
迭代反思
更新发布计划
评审和适应
架构设计演变
持续构建和集成
日常站立会议
文档
变化协调
迁移和集成
持续
故事部署
第 1~N 次迭代
迭代交付
探索阶段
最终评审和接受
最终质量评估和文档
增量交付和最终产品部署
产品开始阶段
项目反思
最终项目、产品文档
清理余下问题
结束阶段
扩展的 APM 交付架构
5.3 扩展地敏捷交付架构
第5章 敏捷项目管理模式
项目计划演变图
产品构想框
项目目标声明
性能
性能价值
项目数据表
创建可交付产品
价值目标
质量目标
创建交付可靠的、适应性强的产品
范围
进度
成本
均衡矩阵
约束目标
敏捷项目成功定义
什么是可发布的产品？
今天是什么阻止我们发布这个产品？
每次迭代末回答的问题
可发布产品
定义
6.1 可发布地产品
客户的产品构想是什么？
该产品主要性能是什么？
项目的商业目标是什么？
项目的质量目标是什么？
项目的约束是什么（范围、进度、成本）
谁属项目社团的合适参与者？
团队将如何交付产品（方法）？
章程
需求收集
额外培训
资源采购
体系结构
第 0 次迭代
辩论
讨论
产品构想达成一致
大型项目
随新信息不断演变
可行性研究
营销研究
项目启动
定期审核
确保持续理解
构想阶段后
描述项目内部沟通渠道
促进探索
指导正在进行的产品开发的设计
敏捷开发中，体系结构是引导而不是紧箍咒
产品体系结构
协助开发团队塑造产品，满足客户需求
敏捷 12 大原则
产品体系结构和指导原则
用一页纸概况主要商业和质量目标、产品功能和项目管理信息。是一个简单却有重要影响力的文档。它简介的格式，对整个项目社区呼吁并不断提醒他们哪些是项目的战略方向。
举例图片
主要顾客/客户一览表
顾客/客户
项目经理名称
产品经理名称/产品拥有者
负责决策项目计划和约束的人
高级主管
明确而简短的声明
做这个项目的总金额和商业原因
商业目标
当项目启动的时候，项目计划保持在价值、质量和约束三者之间的健康平衡非常重要。当这个平衡被打破的时候，权衡矩阵就开始发挥作用。--- 肯。克利尔
权衡矩阵图片
相关方面优先级最高
该方面的执行不允许被影响
固定
该方面非常重要
仅次于固定
灵活
容许度比较广
可接受
行
如果优先级最高的是范围，其它两项只能是较低优先级
只能选择一项
列
确立项目范围、进度和成本的相对优先次序的表格
权衡矩阵
阐明项目的探索系数有助于管理客户和主管的期望值
表示项目的不确定性和风险的指标
问题领域咦探索为主
高风险
10
比较稳定
1
举例
探索系数图片
虽然了解产品构想，但商业或产品需求仍很模糊
无规律的
波动的
常规的
稳定的
4种类别需求易变性
技术非常新，几乎每人尝试过
摸着石头过河
风险不较大
及其尖端的
比较新但又很多专家可以依赖
获取这些专家的成本问题
得到这样的专家问题
风险比较大
尖端de
常见的
熟知的
4种技术方面的探索系数
如果没有人属到不同的问题领域，整齐划一的项目流程和做法也许还要利益；而一旦有了这样的认识，按具体的问题量身定制适合的流程和做法将会使项目团队取得成功
衡量项目风险和不确定性的度量标准
探索系数
项目延误所造成的每日、每周或者每月成本（进度被列为最优先次序时尤其有用）
延误成本
主要功能一览表
功能
一个可发布的产品的定量、定性质量目标
产品主要性能/质量属性青岛那
性能/质量属性
修正设计决定的主要体系结构指导方针
体系结构指导方针
对项目要负面影响的因素
问题/风险
举例说明
项目目标和约束
具备适当的技术能力（专业技术）
能力
内部动机
发现或培养有自律行为的人
组织的专制和告诫，带有恐惧色彩
非强加的纪律
最具天赋
经验最丰富
并不是
效率
速度
资历过高的人
含义
了解各自和其他人的角色
了解决策结构
理解和管理期望目标
有助于提高协作
项目社团的任何个人和群体
影响项目并决定需求的产品客户
提供资金并对项目承担一些管理监察的高级主管
交付产品的核心项目团队成员
包括
使产品为自己或他们的组织创造价值的参与者
最终用户
他们的经理
产品专员
积极从事产品交付的开发人员和管理者
开发团队成员
提供监督、约束、合规活动要求和资源
产品直接客户的经理
内部参与者
供应商
外部参与者
3 类
产品团队-客户界面图片
无论实施之前还是之后，这些参与者都可以组织项目成功
关键的
围绕他们工作
拖延项目成功
必需的
没有直接影响
对项目感兴趣
若不关注，可能会变成关键的或者重要的
非必需的
3 个级别
支持产品
对产品目标和限制做关键决策的人
关注外围利益相关者
关注发布问题多余迭代问题的领导者
负责交付项目结果
项目领导者
领导团队负责确定交付什么结果的人
主要问题专家
分析师
支持产品经理
带领开发团队
迭代活动
团队动态
关注
迭代经理
指导团队交付技术方面的人
总工程师（开发人员、架构师）
负责参与者的组织
有预算和技术决策权力
对项目结果有影响力
高层管理
全职/或兼职
确定需要建造的功能
排列功能优先级
接受结果
产品团队
负责交付结果的产品
项目团队
开发和测试产品的个体或者群体
开发团队
提高服务或产品不见得外部公司或个人
要求得到信息、报告、认证等得管理机构
政府
具体包括
确定参与者
建造什么
项目经理自己决定优先级
无法确定优先次序
营销占据太多时间
同时扮演营销和开发两个角色
产品专员做项目内部得工作
如何建造
IT 项目中的某个人
错误理解产品经理和项目经理角色的本质
组织内部 IT 项目失败或者表现不佳的其中一个关键原因：错误理解项目经i和产品经理这两个角色的本质，产品经理必须来自 IT 部门外部
失败原因
没有客户提供的产品经理就是没有项目
IT 项目规则
人员不仅比流程重要，也比角色重要
客户团队-开发团队见面
根据自己的需要进行裁剪
流程和做法的裁取
方法与构想和目标同等重要
我们如何与客户协作？
来自不同功能团队的项目成员如何相互协作？
远程虚拟团队如何协作？
授权对我们团队来说意味着什么？
谁需要在何时与谁交锋？
相互交谈的这些人如何决策？
谁负责什么？
他们打算用那些做法来推动上面提出的问题？
必须遵循分段式周期架构
详细见第 12 章
流程架构裁剪
按照团队自身特点，塑造流程和做法
那些做法是必需的？
还需要哪些辅助性做法？
需要对选择的做法做哪些修改？
做法的便当、批准和更改需要什么手续和形式？
4个基本问题
不是文档的问题，而是理解的问题
做法的选择和裁剪
自我组织策略
交付方法
流程
6.2 构想做法
6.6 结束语
第6章 构想阶段
确定产品及其功能在当前版本种如何演变
随着项目的开展，平衡预期和适应
在项目早期将重点放在价值最高的功能上
考虑项目、企业目标和客户期望值
为管理层提供必要的预算和进度信息
为权衡决策建立优先级
协调团队之间的相关活动和功能
考虑其它选择和应变措施
为分析项目期间出现的事件提供基准
敏捷项目推测
7.1 推测产品和项目
通过一个演变的产品需求定义过程，将产品构想扩充成产品功能清单
对构想阶段制定的清单的扩充和提炼，列出哪些经过可行性分析或市场研究、初步需求收集工作和产品构想等工作收集起来得产品功能。
对于现有产品，客户、开发人员、产品经理和客户服务人员不断地提出其改进建议，并添加到产品功能清单上。
构想阶段功能清单
软件是最有可塑性地产品。公司需要利用这个特点来增加竞争优势。坚持传统地瀑布式开发方法则减少这个优势
范例
故事是一个小的可交付地有用功能，但构不成完整的功能。
区别
7.2.1 功能、故事地概念
业务重点分解
用户界面
业务对象
中间件
数据库
技术重点分解
7.2.2 故事地重点
一个索引卡
基本信息
记录高层次的需求
开发工作估计
定义验收测试
收集有关故事的
列出功能而非详细定义功能
故事 ID 和名称
用一两个句子，从客户的角度描述功能
故事描述
C = 客户领域
T = 技术领域
故事类型
设计
编码
测试
文档编制
交付故事所需的工作量估计
估计工作量
见第 8 章
估计价值点
每个特点故事采用一个“探索系数”
需求不确定性
可能影响实时顺序的依赖关系
故事依赖关系
客户团队用于接收/拒绝该故事的标准
验收测试
故事卡片信息
7.2.3 故事卡片
ID
名称
简要描述
优先级别
估算等
一个确定的产品性能、功能和故事的列表
谁做
确定和定义做法
包含
7.2.4 创建功能清单
7.2 产品功能清单
7.3.1 范围演变
7.3.2 第 0 次迭代
7.3.2 第 1~N 次迭代
7.3.3 第一个可行地部署
7.3.5 估计
7.3.6 其他卡片类型
7.3 发布计划
7.4 结束语
第7章 推测阶段
敏捷项目管理
职业：本科
0 条评论
回复 删除
下一页
