敏捷软件开发宣言
个体与交互 胜过 流程和工具
可用的软件 胜过 完备的文档
客户合作 胜过 合同谈判
响应变化 胜过 遵循计划
敏捷宣言遵循的原则
- 我们的最高目标是通过尽早、持续地交付有价值的软件来满足客户
- 即使到了开发后期也欢迎改变需求，敏捷过程利用变化来为客户创造竞争优势
- 不断交付可用的软件，周期越短越好
- 在整个项目开发期间，业务人员与开发人员必须天天都在一起工作
- 善于激励项目成员，给他们提供所需的环境和支持，并相信他们能够完成任务
- 无论是团队内还是团队间，最有效的沟通方法是面对面的交谈
- 可用的软件是衡量进度的主要指标
- 责任人、开发者和用户应保持恒久稳定的开发速度
- 对技术的精益求精以及对设计的不断完善将提升敏捷性
- 简洁是一门艺术，要尽最大可能减少不必要的工作
- 最佳的架构、需求和设计出自于自组织的团队
- 团队要定期反省并调整团队行为以便更高效地工作
Scrum 最佳实践
承诺 勇气 专注 开放 尊重
- 具备清晰且好记的愿景
- 拥有维护良好的产品代办列表
- 产品代办列表依照业务价值进行排序
- 产品代办列表中故事的大小由团队决定
- 举行每日站立会议
- 使用燃尽图
- Sprint 不能受到管理层以及客户的干扰
- 团队交付的软件必须符合“完成的定义”
- 举办协作式的评审会议
- 回顾会议的重点要放在改进团队和组织的工作流程上
十大典型障碍
- 会议规则没能被遵循
- 产品远景和 Sprint 目标不清晰
- 没有产品负责人负责回答提问
- 产品待办列表未能按商业价值区分优先级
- 并不是所有负责交付产品的人员都是团队里的成员
- Scrum Master 还要处理其他任务，不能集中精力
- 团队人数过多（多于7人）
- 团队没有能坐在一起工作的空间
- 团队的 Sprint 待办列表混乱
极限编程最佳实践
沟通 简单 回馈 勇气 尊重
- 结对编程
所有的产品软件都是由两个程序员、并排坐在一起在同一台机器上构建的。 - 计划游戏
计划是持续的、循序渐进的。每2周，开发人员就为下2周估算候选特性的成本，而客户则根据成本和商务价值来选择要实现的特性。 - 测试驱动开发
程序员以非常短的循环周期工作，他们先增加一个失败的测试，然后使之通过。 - 完整团队
开发人员、业务分析师、测试人员等一起工作在一个开放的场所中，他们是同一个团队的成员。这个场所的墙壁上随意悬挂着大幅的、显著的图表以及其他一些显示他们进度的东西。 - 持续集成
团队总是使系统完整地被集成。 - 改进设计
随时改进糟糕的代码。保持代码尽可能的干净、具有表达力。 - 客户测试
作为选择每个所期望的特性的一部分，客户定义出自动验收测试来表明该特性可以工作。 - 编码标准
系统中所有的代码看起来就好像是被单独一个非常值得胜任的人编写的。 - 集体代码所有权
任何结对的程序员都可以在任何时候改进任何代码。 - 简单设计
团队保持设计恰好和当前的系统功能相匹配。它通过了所有的测试，不包含任何重复，表达出了编写者想表达的所有东西，并且包含尽可能少的代码。 - 系统隐喻
团队提出一个程序工作原理的公共景像。 - 可持续的速度
团队只有持久才有获胜的希望。他们以能够长期维持的速度努力工作。他们保存精力，他们把项目看作是马拉松长跑，而不是全速短跑。
敏捷开发最佳实践
面向对象设计原则
- SRP 单一职责原则
就一个类而言，应该仅有一个引起它变化的原因。 - OCP 开放－封闭原则
软件实体（类、模块、函数等）应该是可以扩展的，但是不可修改。 - LSP 里斯科夫替换原则
子类型必须能够替换掉它们的基类型。 - DIP 依赖倒置原则
抽象不应该依赖于细节。细节应该依赖于抽象。 - ISP 接口隔离原则
不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。 - REP 重用发布等价原则
重用的粒度就是发布的粒度。 - CCP 共同封闭原则
包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包产生影响，则将对该包中的所有类产生影响，而对于其他的包不造成任何影响。 - CRP 共同重用原则
一个包中的所有类应该是共同重用的。如果重用了包中的一个类，那么就要重用包中的所有类。 - ADP 无环依赖原则
在包的依赖关系图中不允许存在环。 - SDP 稳定依赖原则
朝着稳定的方向进行依赖。 - SAP 稳定抽象原则
包的抽象程度应该和其稳定程度一致。
通用会议规则
缩写词：
- PB = Product Backlog/产品待办列表
- SB = Sprint Backlog/Sprint 待办列表
- SM = Scrum Master
- PO = Product Owner/产品负责人
基本要求
- 每次会议都要准时开始、准时结束
- 每次会议都采取开放形式，所有人都可以参加
会前准备
- 提前邀请所有必须参会的人，让他们有时间准备
- 发送带有会议目标和意图的会议纲要
- 预订会议所需的全部资源：房间、投影仪、挂图、主持设备，以及此次会议需要的其他东西
- 会前 24 小时发送提醒
- 准备带有会议规则的挂图
会议推进
- 展开讨论时会议的推进人必须在场。他不能参与到具体讨论中，但是他需要注意讨论进程，如果讨论参与者失去重点，他还要将讨论带回正轨
- 推进人展示会议的目标和意图
- 必要时推进人可以商定由某个人撰写会议记录
- 推进人可以记录团队的意见或教授团队如何自己记录文档；而且推进人可能会在挂图上进行记录，将对话可视化
- 推进人会使用类似“停车位”之类的工具来记录与会议无关的议题供后续讨论，从而保证会议围绕重点进行
- 推进人会对会议进行收尾，并进行非常简短的回顾以传达会议上所达成的共识(不超过 5 分钟)
估算会议
- 与会者 = 团队 + SM + PO + 用户
- 时间 < 90 分钟
会议目的
- 估算 PB 中的故事便于后续计划 Sprint
- 让团队成员知道项目接下来会有哪些事情要做
- 让团队通过估算更深入地理解 PB 中的故事
会议输入
- PO 根据业务价值排列好优先级的 PB
会议过程
- PO 依次展示 PB 中的故事
- 每展示一个团队就对该故事进行估算并记录平均故事点数
- 如果其中两个人的估算点数超过两倍则分别说明原因，然后重新估算
- 如果某个故事过大应将其划分为较小的故事然后进行估算
注意：
- 只有团队能估算 PB 中的故事，PO 不参与估算
- 上一个 Sprint 遗留下来的故事需要重新估算
- 不要讨论技术细节
会议输出
- 经过估算和调整的 PB
计划会议
- 与会者 = 团队 + SM + PO + 用户
- 时间 < 60 分钟
会议目的
- 让团队详细了解最终用户的真实需要
- 团队承诺他们本次 Sprint 能够交付哪些内容
会议输入
- 经过估算和排序的 PB
会议过程
- 团队依次讨论 PB 中的故事
- 找出验收条件
- 找出非功能性需求（性能、安全……）
- 确定每个故事的验收测试用例
- 确定每个故事完成的定义
- SM 向团队正式提问“是否能在本 Sprint 周期内完成该故事”，如果是则放入本次 SB 中
- 确定本次 Sprint 要达成的目标
注意：
- 只有团队能够决定 SB 中可以包含哪些故事
会议输出
- 选择好的 SB
- 各个故事的验收测试用例
任务分解会议
- 与会者 = 团队 + SM
- 时间 < 60 分钟
会议目的
- 确定 SB 中各个故事的设计方案
- 会议结束后团队成员都知道如何完成每个故事
会议输入
- 选择好的 SB
会议过程
- 团队依次讨 SB 中的故事
- 针对每个故事讨论需要创建什么样的架构，需要编写什么样的接口、类、组件，需要新增或修改哪些数据表等
- 根据讨论的结果创建任务
- 为每个任务估算时间（可选）
- 将故事和任务整理到任务板上并宣布本次 Sprint 正式开始
注意：
- 不要分配任务
会议输出
- 一些方案设计图表
- 整理好的任务板
每日例会
- 与会者 = 团队 + SM
- 时间 < 15 分钟
会议目的
- 为每天的工作做计划和调整
- 解决团队开发过程中遇到的障碍
- 通过任务板帮助团队聚焦于每日活动之上
- 让团队成员彼此清楚各自的工作
会议输入
- 任务板和燃尽图
会议过程
- 团队在任务板旁站成一个圈
- 从左边第一个人开始，从任务板上取下其当前的任务并向其他成员说明目前的情况
- 如果没有完成则放回进行列并做好标记
- 如果该任务已经完成则将其放入完成列，然后领取新的任务并承诺完成时间
- 如果在完成该任务过程中遇到障碍则报告给 SM，同时在任务卡上做好标记
- 和其他成员预约结对编程
- 其他成员对该任务有疑问可随时提出
注意：
- SM 站在圈外，团队不是向 SM 汇报工作
- SM 不要提问题、不要移动任务卡或更新燃尽图
- 不要讨论技术细节问题，可以会后单独讨论
- 不要在没有准备的情况下参会
- 进行中的任务不要过多（一般不超过 4 个）
会议输出
- 更新后的任务板和燃尽图
评审会议
- 与会者 = 团队 + SM + PO + 用户
- 时间 < 90 分钟
会议目的
- 团队通过展示工作成果获取反馈
- PO 验收团队的工作成果
会议输入
- 已完成的故事列表
- 可演示的工作成果
会议过程
- PO 欢迎大家来参加本次评审会议
- PO 提醒大家本次 Sprint 要达成的目标
- 团队根据已完成的故事列表依次展示新功能并让大家尝试新功能
- PO 或 SM 在卡片上记录会议过程中的反馈
注意：
- 不要展示还不能发布的产品增量
- SM 不要负责展示结果
- 团队不要针对 PO 展示
会议输出
- 根据会上的反馈新增的待办列表
回顾会议
- 与会者 = 团队 + SM
- 时间 < 90 分钟
会议目的
- 发现哪些方面需要改进
会议输入
- 燃尽图，PB，SB
会议过程
- 宣布本次 Sprint 结束
- 准备一张写着“做得好”标题和一张写着“可改进”标题的挂图
- 在每张挂图上绘制一条带有开始和结束日期的时间线
- 从“做得好”开始，团队成员依次（包括 SM）在时间线上写上认为做得不错的事件并说明
- 以同样的方式完成“可改进”议题
- 讨论如何改进并记录在卡片上，如果是障碍则做好标记
会议输出
- 为了改进而新增的待办列表
用户故事
用户故事是从用户的角度来描述用户渴望得到的功能
故事三要素
- 角色：谁要使用这个功能
- 活动：需要完成什么样的功能
- 商业价值：为什么需要这个功能，这个功能带来什么样的价值
用户故事模板
- 英文：As a
, I want to , so that - 中文：作为一个 <角色>, 我想要 <活动>, 以便于 <商业价值>
注意:
- 用户故事不能够使用技术语言来描述，要使用用户可以理解的业务语言来描述
Ron Jeffries 的 3 个 C
- 卡片（Card）：用户故事一般写在小的记事卡片上。卡片上可能会写上故事的简短描述，工作量估算等。
- 交谈（Conversation）：用户故事背后的细节来源于和客户或者产品负责人的交流沟通。
- 确认（Confirmation）：通过验收测试确认用户故事被正确完成。
用户故事的六个特性（INVEST原则）
- 独立性（Independent）：要尽可能的让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划，确定优先级，工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。
- 可协商性（Negotiable）：一个用户故事的内容要是可以协商的，用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述，不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通。
- 有价值（Valuable）：每个故事必须对客户具有价值（无论是用户还是购买方）。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。
- 可以估算性（Estimable）：开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。但是让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。
- 短小（Small）：一个好的故事在工作量上要尽量短小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。
- 可测试性（Testable）：一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子：软件应该是易于使用的。
任务板
任务板以可视化的方式展示团队的工作
- 任务板只能由团队维护
- 尽量使用实体大白板
任务板有 3 列
- 准备做
- 要完成一个故事，你得完成一些任务。在计划会议上创建的任务以及后续添加的任务都应该放在该列
- 进行中
- 当团队成员领取某个任务时将任务挪到该列
- 每日站会上会对该列中没有完成的任务做一个标记（如一个圆点）
- 如果该列中的任务是因为过大而不能在一天内完成则可以考虑将其分解为多个任务重新安排
- 如果一个任务因为障碍无法完成应该做一个标记（如一个红点）
- 已完成
- 当一个任务完成后，着手该任务的团队成员就可以将其放入该列并领取下一个任务
燃尽图
记住：跟踪进度要由团队来完成。
- 你必须要有一个 Sprint 燃尽图！
- 燃尽图展示“燃尽”（即开发完成）的故事点数，而不是工作小时数
- 纵轴展示故事点数，横轴展示当前 Sprint 的天数
- 团队每天更新燃尽图
- 燃尽图要便于团队更新，没必要让它看起来很炫，也不要过于复杂、难以维护
角色
隐喻：我们是在拍电影！
Scrum Master = 电影导演
- Scrum Master 保护团队不受外界干扰
- 他不是团队的一部分，但是是团队的领导和推进者
- 他提升 Scrum 团队的工作效率，控制 Scrum 中的“检视和适应”周期过程
- 他保护团队，并与 Product Owner 一起将投资产出最大化
- 他确保所有的利益相关者都可以理解敏捷和尊重敏捷的理念
- 然而，他不负责交付产品
团队 = 演员
- 团队交付产品并对其质量负责
- 团队与所有提出产品请求的人一起工作，包括客户和最终用户，并共同创建 Product Backlog
- 团队分析 Product Backlog 的条目，藉此获得足够的信息以构建产品
- 团队按照大家的共识来创建功能，开发、测试 Backlog 条目并交付产品
- 团队自愿做出承诺，它对其工作产出负责，并且需要考虑其所属组织和项目本身的实际情况
- 团队还会一直和 Product Owner 一起工作，以制定产品的战略方向
管理层 = 制片厂老板
- Scrum 组织中的管理层非常重要，管理层要为 Scrum 团队搭建良好的环境，以确保团队能够出色工作
- 管理层创建结构和稳定性，必要的时候，他们也会与 Scrum Master 一起重组组织结构和指导原则
客户 = 制片人
- 客户是为 Scrum 团队提出产品需求的人，她会与组织签订合同，以开发产品
- 一般来说，这些人是组织中的高级管理人员，负责从外部软件开发公司购买软件开发能力
- 在为内部开发产品的公司中，负责批准项目预算的人就是客户
Product Owner = 故事作者
- Product Owner 从业务角度驱动项目，她传播产品的明确愿景，并定义其主要特性，她也会在 Sprint 结束时接收产品
- Product Owner 的主要职责是确保团队只开发对于组织最重要的 Backlog 条目
- 她与团队的目标相同，并在 Sprint 中帮助团队完成工作，不干扰团队成员，并迅速提供团队需要的所有信息
- Product Owner 对投资回报负责
最终用户 = 观众
- 很多人都可能成为最终用户，比如市场部人员、领域专家，也可能是因其专业知识而被雇佣的咨询顾问
- 最终用户会根据自己的业务知识定义产品，并告知团队自己的期望，提出请求
产品负责人工作检查清单
- 产品待办列表是根据产品负责人最新的想法按优先级排序的吗？
- 来自所有利益相关人对产品的需求和愿望都被放到产品待办列表了吗？
- 产品待办列表是涌现的吗？
- 产品待办列表的规模可管理吗？
- 产品待办列表中的故事（特别是优先级靠前的）符合 INVEST 原则吗？
- 产品待办列表中有技术债务相关的内容吗？
- 产品待办列表作为信息辐射体，对所有利益相关人立即可见吗？
- 如果是电子版待办列表，每个人都知道如何方便地使用它吗？
- 评审会议后发布计划是跟着调整的吗？
团队工作检查清单
- 团队成员大多数时间处在流畅状态吗？（目标明确、全神贯注、及时反馈、工作轻松、不断学习……）
- 团队成员经常在一起庆祝各自的成功吗？
- 团队成员相互以高标准监督、相互挑战以促进成长吗？
- 有没有一些话题因为大家感觉难受，所以在团队里没有进行讨论？
- 尝试过用不同的形式和地点开回顾会议吗？
- 团队在开发过程中一直关注验收标准吗？
- 任务板和燃尽图方便可见吗？易于使用吗？
- 任务板和燃尽图能反映团队的真实情况吗？
- 任务板和燃尽图被团队外部用于微观管理了吗？
- 团队成员是自己选择并领取任务吗？
- 团队有和产品负责人沟通将技术债务的内容包含在待办列表中了吗？
- 团队成员能否抛开各自的岗位定义，对约定工作的所有方面（开发、测试、文档等）集体负责？
- 管理层是否以集体的成功来衡量团队？
工程实践检查清单
- 正在开发的系统有没有一个类似“按下测试”的按钮，从而每个人（同一团队或不同团队的）都能方便地检测到系统是否被破坏了？
- 自动化的端到端系统测试（或功能测试）与自动化的单元测试之间有适当的平衡吗？
- 系统功能测试和单元测试代码是团队自己维护的吗？（还是说由其他团队单独编写和维护）
- 团队已经发现在系统测试和单元测试之间存在有用的灰色区域了吗？
- 当有人引起回归失败时，是否有个持续集成服务器会在一小时甚至几分钟内自动发出警报？
- 所有的测试都会在持续集成服务器上运行吗？
- 团队成员已经发现重构的乐趣和成功了吗？
- 重构是随时在进行吗？有自动化测试的保障吗？
- 故事的“完成”定义或验收标准中包含自动化化测试和重构了吗？
- 团队成员大多数时间都结对编程吗？