- 看板是一个及时的库存控制调度系统。产品流程只有在收到命令信号时才执行。
- 所有任务都必须经过测试或验证流程，来确保质量已介入开发流程中。完成的任务通常移动到“准备测试”目录下，然后由测试者和客户执行测试。任务板上部分任务没有详细的验证或测试标准，这些任务不会移入”准备测试“下，但仍要进行验证，并通常移至”准备验证“目录下
- ”项目章程“是重要的管理文件，需要所有干系人参与。”项目章程“包含三个重要信息：前景、任务、成功标准
优先级技术：
- MoSCow Must Should Could Won't
- Kanon模型 基本需求（必须），性能需求（越多越好），愉悦需要
- 相对量级 基于成本、风险和处罚后能提供最大益处的特征应用拥有最高优先级
XP极限编程强调以下原则：
- 结对编程
- 可持续速度
- 不断自动测试
- 有效沟通
- 简单性
- 反馈
- 勇气
- 集体所有权
- 持续整合
- 激励工作
- 共享工作空间
- 现场客户代表
- 使用隐喻说明概念
- 产品待办事项是一列所有需要在迭代中开发的产品特性综合清单，它是不断变化的，以适应客户需求。
- 产品负责人的主要职责之一是：return on investment 投资回报率
常见的敏捷架构/方法论包括：
- scrum
- xp极限编程
- 精益软件开发
- 水晶
- 特性驱动开发 fdd
- 动态系统开发方法 dsdm
- 敏捷统一过程 aup
- 敏捷中，故事地图本质上等同于项目计划，它将用户故事/产品特性按逻辑主题排列，作为开发的计划。
计划扑克是基于宽带德尔菲估算技能、也是以共识为基础的工作量估算技能。也称scrum扑克。运行步骤：
- 一名调停人主持会议，不参与估算
- 产品负责人/管理人员对用户故事做概述，并回答开发者提出的澄清问题，往往产品负责人不参与投票
- 每一位估算师抽取一张卡片来估算工作量
- 每人抽取一张卡片后，同时将他们的卡片翻转
- 持高和低估算的估算师各有一个机会做立场辩护
- 达成共识前不断重复以上流程。持有用户故事的开发者往往具有较高的可信度
敏捷的4个宣言
- 个体和交互胜过过程和工具
- 客户合作胜过合同谈判
- 可执行的软件胜过完备的文档
- 响应变化重于遵循计划
敏捷12原则
- 我们的最高目标是，通过尽早和持续的交付有价值的软件来满足客户
- 欢迎对需求提出变更，即使是在项目开发后期。要善于利用变更，帮助客户获得竞争优势
- 不断交付可用软件，周期从几周到几个月不等，且越短越好
- 项目过程中，业务人员与开发人员必须在一起工作
- 要善于激励项目人员，给他们提供需要的环境和支持，并相信他们能够完成任务
- 无论是团队内还是团队间，最有效的沟通是面对面交谈
- 可用的软件是衡量进度的主要指标
- 敏捷过程提倡可持续的开发。项目方、开发人员和用户应该保持恒久稳定的进展速度
- 对技术精益求精以及对技术的不断完善将提升敏捷性
- 做到简洁，即尽最大可能减少不必要的工作。这是一门艺术
- 最佳的架构、需求和设计出自于自组织的团队
- 团队要定期反省如何能够做到更有效，并相应的调整团队的行为
- 一般来说，敏捷项目是自上而下估算的
- 敏捷团队应约定试用一种估算方法，故事点或者理想时间，因为这两种方法使用不同的测量单位，会造成混乱
- 开发一个用户故事的理想持续时长是2-5天
- 用户故事是基于顾客价值去优先排序的。价值有投资效益、团队知识增长，风险减少决定
价值流程图是敏捷采用的精益生产分析技能，用于对形成客户产品或服务的原料和信息（即价值）的流动分析。执行价值流程的5个步骤
- 确认产品、客户和范围（即流程的始末）
- 地图作为团队或者个人现时价值流，确认流程步骤，延时和信息需求。估算流程步骤的持续时长和前置期持续时长。前置期是指在发生前一项流程或事件需要等待的时长
- 分析价值流程图来确认浪费存在的地方和流程可完善的地方（流程时间通常认为是价值增加时间，但是应尽量减少整个流程的时间，由此来缩短向客户交付价值流的时间）
- 通过分析，总结出一份展示价值流努力达到的前景或目标的未来价值流程图
- 通过流程完善活动或者其他方法来达到目标的一些工作
- 解聚是指将大的用户故事分解为小的更易于处理的小故事，类似分解
以价值为基础的分解：将用户故事分解为任务，这将反过来被价值优化 - 故事点代表成本，价值点代表利益
- 项目的燃尽图是一个常用来展示迭代进度的信息发射源。它记录两项序列：剩余的实际工作和剩余的理想/预估工作。实际工作序列往往是非线性的，反映开发的起伏
一个健全的站立会议的重点特征：
- 同辈压力，因为团队靠大家，所以同辈的期望可带动进步
- 密切的配合，团队应当理解专注的重要性并独立工作
- 细节在专注，团队应当理解每日站立会中简洁的重要性，由此团队才有效益
- 每日承诺，团队应当理解每人每日承诺的价值所在，并兑现这些承诺
- 辨别障碍，团队应当集体意识到每个人的困难，由此团队可集体尝试解决
- 价值、成本、风险是优先考虑处理用户故事的重点因素
3C
- card
- conversation
- confirmation
- 敏捷开发的基石是增量交付。增量交付是指为及时反馈和接纳，频繁向客户交付连续有效的工作产品
invest
- independent 独立的
- negotiable 可协商的
- valuable 有价值的
- estimable 可估算的
- small 小的
- testable 可测试的
- 在使用负责项目的滚动波或滚动预测未来计划时，敏捷团队计划在下几个迭代中是工作
计划扑克
- 计划扑克的参照点用户故事是中码或者均码
- 进行计划扑克时，每一个用户故事分配的时间应当是2到3分钟
- 计划扑克用来评估开发中用户故事的相关付出
- 额外收益是指向现有客户销售新产品特性或服务期间实现的额外收益
- 投资回报率roi：用来评估一项投资的效益或者对比若干投资的效益的指标。一般来说，产品负责人对投资回报率负责。
- scrum框架的基石是“一直存在一个理论上可传输的产品”，所以对于对于团队和产品负责人来说以下两点非常重要：定义“完成”，或终结状态下要以何标准考虑用户的特性和功能
产品负责人所拥有的产品路线图，是产品需求的高层次概述，常用作特性优先处理，特性归类和粗略时间框架确定的工具。创建产品路线的步骤：
- 确认需求
- 将需求分类或分定主题
- 评估相对工作量
- 评估粗略时间框架
- 敏捷计划的三个主要层级为：发布计划、迭代计划、每日计划
敏捷领导需要做到：
- 授权团队成员决定敏捷实践和方法的标准
- 允许团队进行自主管理和自我约束
- 授权团队成员和客户合作决策
- 激励团队创造和探索新思想和技术的才能
- 成为倡导者，向团队成员阐释产品前景，以此激励完成整体目标
- 移除并解决团队工作可能遇到的障碍和问题
- 向可能不熟悉敏捷的干系人沟通和宣传敏捷项目管理的价值和原则
- 确保包括商业管理人员和开发者在内的所有干系人有效协作
- 能够依据工作环境改变领导风格，以此确保有力支持敏捷价值和原则
- 敏捷铁三角：价值、质量、约束
根据亚伦·桑德斯所说，敏捷失败的前12条是：
- 承诺没有产生组织变化或获得支持
- 文化不支持变化
- 文化没有反思，或者执行反思不足
- 在项目收尾过程中丢失标准和质量
- 计划中缺乏协作
- 缺乏或者过多产品负责人
- 项目领导力不足，或者scurm主管不信任团队并不允许团队自主管理和自我约束
- 没有现场的敏捷支持者或者教练
- 缺乏一支完善，高绩效的团队
- 不维持严格的测试标准的情况下，技术债务会增加
- 文化维持传统的绩效评估，即推崇个人时丢失团队方面
- 因为变化难以进行，所以传统或旧式是经营方式出现
敏捷项目管理的重点特征：
- 持续完善
- 多功能团队
- 短迭代
- 增量方法
- 商业优先权
- 客户价值
- 最小可售功能MMF是一个最小和可市场化的软件特性或者产品特征
验收测试驱动开发atdd迭代的4个步骤4d：
- discuss 讨论
- distill 提取
- develop 开发
- demo 示范
测试驱动开发tdd的4个步骤
- 编写测试
- 核对和确认测试
- 编写产品代码，接着采用测试
- 重构产品代码
r·e·freeman的干系人管理10原则：
- 干系人的利益点需要随着时间而趋于一致
- 我们需要一个制原则原则——联合干系人并经营关系，而不是留给政府
- 我们需要找到同时让各个顾客满意的方法
- 我们所做都是为服务顾客，我们从不以一个人的利益换取他人利益
- 我们充满目标完成对干系人的承诺，我们充满抱负实现我们和他人的梦想
- 我们需要和所有干系人彻底沟通
- 干系人包括有姓名和样貌的人和小孩，错综复杂
- 需要概括市场营销方法
- 我们与首要和次要干系人接洽
- 我们不断的监督和重新设计过程变得更好的去服务干系人
- 敏捷开发合同类型：初始阶段用固定总价合同；成本报销/工料合同；不超过固定费用合同
敏捷项目中，典型的信息发射器包括：
- 项目燃尽图
- 任务板
- 燃起图
- 缺陷图表
- 《PMI敏捷社区实践章程》提出的社区价值包括：前景、仆人式领导、信任、协作、诚实、好学、勇气、开放、适应力、领导变革、透明化
影响项目的5个核心风险：
- 生产率变化（计划和实际操作之间的差距）
- 范围渐变（初始协议以为的大量附加的需求）
- 规格故障（干系人对需求的共识缺失）
- 内部日程缺陷（对任务工期的错误评估）
- 人才流失（人力资源的流失）
统一敏捷流程aup的4个阶段：
- 创始
- 细化
- 建立
- 转变
浪费的形式 widetom：
- waiting等待
- inventory库存
- defects缺陷
- extra processing额外流程
- transportation运输
- over-production过度生产
- motion动态
提高动力的简单步骤：
- 共度黄金时间，团队成员可在个人层面上了解他人以此营造社区氛围
提供反馈，指导和训练，赞扬和感谢团队成员的出色工作，同时为技能和能力提升提供指导和训练 - 授权，授权团队成员关键决策，在此期间，建立信任并显示领导对团队能力的信任
构建良好敏捷团队氛围的指导包括：
- 团队成员协作
- 减少非必要的干扰/分心
- 为信息发射源专用白板和墙面空间
- 为每日站立会议和其他会议提供空间
- 结对工作站
- 其他任性的措施如植入和舒适的家具
吉姆·海史密斯敏捷企业架构的4个层次：
- 投资管理分层
- 项目管理分层
- 迭代管理分层
- 技术实践分层
吉姆·海史密斯项目管理模型的5个阶段：
- 构想
- 推测
- 探索
- 适应
- 结束
- 敏捷项目推荐的合同类型：初始阶段的一般服务协议和为迭代和用户故事分开设置的固定价合同；工料合同；不超过固定费用合同；最后奖励性合同（固定加激励；成本加酬金及奖励合同）
- scrum中迭代计划会议不应该超过8小时
- 敏捷团队的基本准则不是教练编写的，而是由所有项目成员编写的，往往也是非正式
- 力场分析是寻找推动和阻碍变化的因素并给因素编号以了解两边力量的综合
- 只有规定时间内通过验收的功能包含在时间盒内
- 持续集成的意思所有代码变化要每天提交和测试
- 挣值管理分析在迭代时被获取和用于沟通
- XP项目中定义的角色：教练、客户、程序员、测试员、跟踪员
- 累计流量图显示的是任务的工作流而不是过程的工作流
- 精益支持减少浪费。达到此目的一种方式是将未开展的工作最大化
- 正确的测试驱动开发方法是：测试、编码、重构、交付
- 在零迭代期，团队通常做计划，没有可用的软件可交付。在敏捷中计划不能产生内在价值，只有可用的软件才能转化价值
- 敏捷中分布式团队没有集中式团队有效。
- 修剪产品树是一种用于需求收集的创新游戏
- 敏捷宣言于2001年在犹他州瓦萨其山雪鸟滑雪胜地发表
- 停车场图用来抓住可能重要的但应该以后再关注的偏离主题的信息
- 计划扑克应该在开发用户故事之后和创建故事点之前使用
冲突管理和解决
- 级别1：解决问题。协作：寻求双赢的局面；共识：学习每位团队成员对这个问题的看法，并及时达成一致
- 级别2：争执。支持：允许对方解决问题；安全：任何事情都要以安全为基础
- 级别3：争辩。容纳：为了建立关系，退让；谈判：许诺工作和资源
- 级别4：讨伐。外交手段：在各方之间传送信息
- 级别5：世界大战。保护：做任何必要的事情来防止大家彼此伤害
Keip三步干预法：
- 1.你有没有跟他提到过你的顾虑和感受？
- 2.他应该知道你的顾虑。如果我跟你一起去找他会有帮助吗？
- 3.我可以告诉他，你们有这些顾虑吗？
- 产品负责人对产品中所有功能负责，在干系人出现不同意见时，产品负责人要进行讲解直到所有人都清楚的了解功能
- 产品路线图是产品发布和主要组件的整体虚拟概述。它为项目干系人提供了沟通工具
- 风险燃烧图实际上是累积的项目风险的严重性的堆叠图
- 回顾会议的步骤：开场、收集数据、生成灵感、决定要做什么、关闭回顾
- 敏捷团队是自组织的，他们为项目承诺时间而非SM
- 看板上没有角色
- kaizen是日本关于持续改善的术语，能通过微小的改变来实现
产品待办项有4大特性deep：
- 详略得当 detailed appropriately
- 紧急涌入 emergent
- 估算过的 estimated
- 排好顺序 prioritized
敏捷教练的风格
- teaching 教学型
- coaching 指导型
- advising 顾问型
- 项目数据表是用一页纸概括主要商业和质量目标、产品功能和项目管理信息，这是一个简单却有重要影响力的文档。
收入来源
- new revenue新收入——新客户带来的收入
- incremental revenue增量收入——现有客户增加的收入
- retained revenue留存收入——如果不开发项目或者主题，公司会损失的收入
- operational efficiency操作效率
- 敏捷关注定性风险分析
sprint评审会的目标
- 真实展现
- 展示和说明
- 获取直接反馈
- 提供内部情况
- 寻求帮助
绘制燃尽图的4条原则：
- 只要完成了工作，就要降低顶部
- 对工作重估时，顶部可能上升，也可能向下移动
- 添加新工作时，底部降低
- 去掉工作时，底部升高
- 产品路线图勾画出了多个版本演化过程。该图表示的时限可以历时几年，是对产品性能进行的一种概括总会
- 代码重构是完善工作源代码的方法，以提高源代码的有效性、可读性、扩展性、可维护性和降低复杂性。通过重构，可在不改变外部行为的情况下，重构源代码来改良内部代码
Kano模型
- must have 作为阈值的功能（必须的功能）。产品要成功就必须具备的功能
- 线性功能。越多越好的状态的功能
- 兴奋点和惊喜点
- 分割用户故事
- 按照用户故事所支持的数据边界来分割大型用户故事
- 按照操作边界分割
- 去除横切考虑
- 不用满足性能限制
- 分割具有混合优先级的用户故事
- 不要把故事分割成任务
- 避免相关变化的诱惑
- 发布计划重要的原因
- 发布计划可以帮助产品所有者和开发小组判断他们获得一个可发布的产品之前，必须花多长时间开发多少东西
- 发布计划传递了对于多长时间内可能开发什么内容的期望
- 发布计划可以作为项目小组前进的路标
发布规划的步骤（发布计划通常在每次迭代开始时更新）
- 确定满意条件
- 估计用户故事的规模
- 选择迭代周期长度
- 估计速度
- 确定用户故事优先级
- 选择用户故事和发布日期
- 发布计划提供了要构建产品的高层次视图
- 迭代计划在迭代规划会议上制定
- 迭代规划时不分配任务
- 发布计划是对整个产品发布过程的展望，通常是聪哥新项目启动开始3-6个月的时间；迭代计划只是对一次迭代的展望，通常是2-4周的时间。
- 迭代计划的主要目标是对粒度较粗的发布规划中建立的假定进行细化
迭代规划方法分类：
- 速度驱动 velocity driven
- 承若驱动 commitment driven
- 优先级会议通常安排在一次迭代结束前2天的时间
选择迭代长度应考虑的因素：
- 正在处理的发布时间的长度
- 不确定性的多少
- 获得反馈的难易程度
- 优先级可以保持多久不变
- 不用外部反馈自行工作的意愿的强弱
- 迭代的系统开销
- 紧迫感的产生有多快
缓冲区：
- 功能缓冲区
- 进度缓冲区
DSDM dynamic system development method 动态系统开发方法把需求分为4类 及 MoSCoW
- must have
- should have
- could have
- won't have
类似SCRUM，dsdm有三个主要阶段
- 初始项目活动
- 项目周期活动
- 结束项目活动
类似scrum的赛前、赛中、赛后，dsdm生命周期有5个阶段
- 可能性研究
- 交易研究
- 功能模型迭代
- 设计和建立迭代
- 安装启用
- 特征驱动开发 fdd使用一个规范的模型计划、管理，并从个别软件特征方面跟踪软件开发流程。fdd使用两周或更短时长短迭代来开发一定的特征。
fdd的五个步骤：
- 开发整体模型
- 建立特征清单
- 依特征做规划
- 依特征做设计
- 依特征进行建立
在迭代计划中，团队根据三步曲去设计迭代代办事项：
- 团队分解大的或复杂用户故事为多元的，小的故事
- 团队把每个用户故事分解为开发任务
- 团队估计任务功力或周期，通常用理想时间
常见敏捷框架/方法论
- scrum
- xp
- 精益软件开发
- crystal
- 特性驱动开发 fdd
- 动态系统开发 dsdm
- 敏捷统一过程 aup
- crystal的一个首要原则是渗透沟通
- 反思提高研讨会是crystal方法论的基石
- crystal水晶是软件开发灵活轻便方法的方法家族。方法家族是区分成员的颜色代码，例如透明、黄色、红色。颜色选择取决于成果水平的要求。在光谱一端是完全透明的。
不考虑颜色，crystal的三个基本过程：
- 章程（几天到几周）
- 交付迭代
- 项目总结
crystal纲领：
- 建设团队
- 做探索的360
- 为团队定义实践标准
- 建立项目初始计划
精益软件开发的原则
- 清除浪费
- 强化学习
- 尽可能晚决策
- 尽可能早交付
- 授权团队
- 构建完整性
- 全盘检视
精益软件中存在的两种完整（integrity）类型
- 概念性的。概念上的完整性由开发者决定，如果产品集成良好和功能详细，那么完整性大体上会非常高。
- 感知性的。感知上的完整性是有客户观察得出的，如果客户最初对产品满意和在之后产品满足需求，那么完整性会很高。
- 信息发射源是指项目数据状态的可视化展示
- 发布耗散图显示了在每次迭代开始时剩余的工作量。它是一个强大的、关于小组朝目标的前进有多快的可视化指示器。
- 发布耗散条形图
- 停车场图。提供了一个有用的高层次视图，体现了小组在实现项目中所规划的不同主题的进度
- 规划是对价值的追求。
可以通过以下活动来支持对价值的追求：
- 减少风险
- 降低不确定性
- 提供更好的决策支持
- 建立信任
- 传递信息
- 规划通过对风险的认识来提高项目取得成功的可能性
- 经常性地、可靠地交付承若的功能可以在产品的开发人员和该产品的客户之间建立信任。可靠的估计使得可靠的交付成为可能。
- 计划可以传递对项目的期待，并说明在项目的进程中发生某些事情的可能性
- 敏捷规划不是敏捷计划。计划是文档或者图表；它们是我们认为一个项目在不确定的将来会如何展开的快照。规划是一项快照。敏捷规划将重点从作为结果的计划转向了规划过程。
敏捷规划
- 更关注规划而不是计划
- 鼓励修改
- 产生易于修改的计划
- 延续到整个项目过程
敏捷的4大价值
- 个人与交互重于开发过程与工具
- 可用的软件重于复杂的文档
- 寻求客户的合作重于对合同的谈判
- 对变化的响应重于始终遵循固定的计划
敏捷开发小组的主要工作方式
- 作为一个整体工作
- 按短迭代周期工作
- 每次迭代交付一些成果
- 关注业务优先级
- 检查与调整
敏捷小组使用3个层次上规划：
- 发布规划（3-6个月）
- 迭代规划（2-4周）
- 每日规划
规模估计
- 敏捷估计与规划的一个关键原则是先估计出规模然后推算出时间。
- 敏捷开发小组并不是依靠某一位专家来进行估计。
- 打规划扑克的时间
- 项目正式启动前或在它的第一次迭代中
- 开发过程中对迭代中发现的新用户故事
- 故事点和理想日是对规模的估计
- 有利于故事点的考虑因素
- 故事点有助于驱动跨功能的行为
- 故事点估计不会过期
- 故事点是纯粹对规模的度量
- 故事点估计通常更快
- 我的理想日不等于您的理想日
确定优先级的因素
- 获得这些功能带来的经济价值
- 开发（可能还包含支持）新功能所需要的成本
- 开发新功能所产生的学习和知识的量以及重要性
- 开发这些功能所能减少的风险
敏捷估计和规划的12条原则
- 让整个小组参与
- 在不同层次上规划
- 使用不同度量单位，让对规模和持续时间的估计保持独立
- 用功能和日期来体现不确定性
- 经常重规划
- 跟踪进度并沟通
- 成人学习的重要性
- 规划具有适当规模的功能
- 确定功能优先级
- 把估计和计划建立在事实上
- 保留一些松弛度
- 通过前瞻规划协调多个小组
scrum会议及参与人
- 用户故事工作坊。SM、PO、团队
- product backlog。PO
- 估算会议。团队、PO、SM
- sprint planning。team po sm
- dayly meeting。 sm team
- review meeting。sm team po customer
- restore meeting。sm team
- sprint验收。po
网友评论