敏捷开发产生的原因
互联网产品逐渐失去客户的概念，随之带来需求的模糊
如果项目型开发还可以怪客户需求模糊的话，多数互联网软件却连这个借口都找不到了，由于没有特定的客户，自己摸索需求，拥抱变化，也就成为必然，只关注最重要的需求，拥抱变化的互联网企业得以逐步摸索自己产品的实际功能。
没有特定的交付期，只是越快越好，越快越好
以往从来没有一个产品像互联网产品一样对尽早交付产品有如此的追求。
在项目模式下或传统的生产-销售模式下，时间点不是最关键的，word曾经跳票4年，从原定一年完成推迟到五年，但仍然没有影响其霸主地位，但是互联网行业就截然不同了，谁也不敢比别人晚5年推出更好的功能，实际上无论迟到者有多好，多数用户都会选择留在原有网站或产品上，互联两个字是用户群本身成为产品的一部分，而功能则退居其次，尽早获得用户群成为互联网行业成功的不二法门。
开发人员参与需求和设计，对工作主动性要求更高
在大型项目中，开发人员参与需求和设计的概率和数量都很低，或者说开发人员不是项目成功的关键，即使换了另外一批程序员，只需要需求和设计做的好，项目依然能够成功，在这类项目中，很多问题遗留给了一线的工作人员，而且由于互联网软件的平面化，也就是开发者往往是自己产品的用户，比如QQ，微信，微博，开发人员往往能更好的捕捉和定义新需求，在这类项目中创新和快速的迭代是最高的价值观。
什么是敏捷
敏捷不是方法论，不是开发框架，不是开发过程；是一种思想。
从产出来看：频密的交付可见，可用的成果（软件）
从团队来看：持续主动的学习和改进的状态即为敏捷
敏捷价值观
- 个体与互动高于流程和工具
- 工作的软件高于详尽的文档
- 客户合作高于合同谈判
- 响应变化高于遵循计划
敏捷开发原则
- 尽早、持续的交付有价值的软件来使客户满意是最高优先级的工作
- 即使到了开发的后期，也欢迎改变需求，敏捷过程适应变化来为客户创造竞争优势。
- 以几周到几月的间隔频繁的交付可工作的软件，交付间隔越短越好
- 在整个项目开发期间业务人员和开发人员一起工作
- 激励团队成员建设项目。提供所需的环境和支持并信任他们能完成工作。
- 在团队内部以及团队之间最有效，最高效的传递信息的方式是面对面的沟通
- 可工作的软件是首要的进度度量
- 持续性的开发。开发者与用户应保持长期的、恒定的工作速率
- 持续追求技术卓越和优良设计能提高敏捷性
- 敏捷的根本在于简单，使不用做的工作最大化的艺术
- 最好的架构、需求和设计出自于自组织的团队
- 每隔一定的时间，团队应当反思更有效的工作，然后响应的做出调整。
scrum敏捷开发
scrum是一种灵活的敏捷软件开发管理过程，来源于英式橄榄球，将软件开发比作橄榄球队，全队有明确的最高目标--发布产品重要性高于一切，团队高度自制，成员们熟悉开发过程中涉及的各种技术，紧密合作，确保每个迭代（Srpint）都朝着最高目标推进，而且每隔2-4周，每个团队成员都能看到实际工作的软件，并据此决定是否发布这个版本还是继续加强它的功能。
scrum信条
- 勇气
- 开放
- 专注
- 承诺
- 尊重
scrum关注于角色（roles），资产（artifacts）,事件（events），价值观(values)
scrum开发团队
团队特征：
- 跨职能：团队成员具备不同领域的必须技能；成员遵循T模型人才构成，在不同层面具备不同的成熟度。
- 全职：每个迭代（sprints）之间可以换人
- 自组织：团队中没有管理者的头衔；整个团队决定如何去工作；团队全员责任制；团队承担大部分微观管理工作。
团队使命：
- 团队交付产品增量
- 团队对怎样做和交付质量负责
- 团队参与sprint中的所有会议
- 管理迭代待办任务（sprint backlog）并跟踪进度
- 找到团队内部合作的最佳方法
- 与其他团队及相关方进行协作
- 团队持续自我改进
角色之产品负责人（product owner）
特征：
- 被授予产品（做什么）决策权的一个人
- 驱动产品走向成功
- 具备产品的领导力
- 面向干系人（甲方，老板）代表团队
- 面向团队代表干系人
- 需要与所有人合作
使命：
- 建立产品愿景，产品最终要实现的功能，达成的效果
- 从“为什么”开始
- 定义产品功能，产品都是要做什么
- 负责最大化的投资汇报
- 为最好的实现业务目标将产品backlog排定顺序/优先级
- 决定产品版本发布日期及每个版本实现内容功能
- 根据反馈调整产品backlog或优先级
- 参与sprint所有的事件
- 愿意投入到合作中并且在需要的时候被找到
- 接受和退回工作成果。
角色之能手（scrum master）
特征：
- 面向管理层代表团队
- 面向团队代表管理层
- master不是一个项目经理或团队经理
- master不是管理头衔，不代表团队做出决定
- 是一位为人民服务的仆人式的领导者
- 或者是一头牧羊犬
- 对职业技能有非凡成就的教练
- 开发团队或组织谋求变化的代理
- 具备良好的引导团队建设的技能
- 倾听各方的意见多于说
- 思路开放，精通业务与技术
使命：
- 负责将scrum价值观、原则和规则被各方采纳和彰显
- 为团队开发移除所有的障碍
- 为po和团队服务
- 帮助培养开发团队
- 保护团队开发积极性
- 辅助团队高效协作开发（有点像游戏中的辅助）
- 想办法提升scrum在整个开发团队中的效果。
scrum中各个角色类似于中国传统竞技项目划龙舟，你细品，仔细品
资产之 product backlog
- 一个动态的列表，其中包含了产品中可能具备的功能
- 列表中包含为用户带来价值的工作
- 一个健康的product backlog应具备deep原则：恰当的星系程度，整个任务已被估算，列表任务为涌现式，列表任务按照任务优先级进行有序排列。
- 所有任务对团队成员开放但是由产品PO负责维护
- 关注产品“什么”能给用户带来最大的价值
资产之 user stories 用户故事
为用户的每个需求编一个故事，例：作为【用户角色】，我想【实现一个结果】，因为【商业价值】；每一个用户故事都是从“为什么”开始，使用简单的书面描述，定义一小片用户可以评估、验证的功能。
用户故事粒度
用户故事及验收标准
INVEST原则
I independent 独立的，一个用户故事相对于另外的用户故事应该是独立的。故事之间的依赖性使得增加了计划编制，确立优先及，故事估计这些工作非常困难。通常通过用户故事或分割用户故事来减少依赖性。
N negotiable（便于沟通的）用户故事式便于沟通的。一个故事的卡片包含了故事详情的简短描述，通过讨论阶段来完成，卡片在实际上减少了和客户的会谈。
V valuable（有价值的）每隔故事必须对客户具有价值，最好用户来书写用户故事，但是最好让用户意识到用户故事非合同式的锲约，而是可以进行多次协商的，相信用户会乐意写下用户故事。
E estimable 可预估的，开发者需要根据用户故事内容确定每个backlog的优先级，并对每个故事进行规划，但是用户对业务知识缺乏（这个时候需要与客户进行反复沟通），用户故事太大（需要分解用户故事）
S small 短小，一个好的用户故事在工作量上应该是短小的，描述具有代表性，尽量不超过2-3人周的工作量
T testable可测试的，一个用户故事，可以通过测试来确认完成，
资产之迭代任务 sprint backlog
产品backlog的延申和子集
- 为实现sprint目标所要完成的工作集合
- 涵盖恰到好处的设计
- 将大块的工作分解成更小的任务单元 PBI>SBI
- 关注于“怎么做”的问题，如何从一个sprint内完成工作以交付价值
被开发团队所拥有
- 团队从product backlog中选取他们可以承诺完成的项目并创建响应的sprint backlog
- 团队协作完成，不是由scrum master负责完成
- 借助一个可视化的工作让团队在sprint内部实现自我管理
管理sprint backlog
- 任务板是一个常见用于管理sprint backlog 的可视化工具
- 自组织：团队成员和分组成员自己领取工作；团队一起将PBI分解成SBI，团队确立合适的SBI颗粒度，团队中没有一个人来主导任务的分配（团队成员自领取），完成一项任务后才认领另外一项任务，按照优先级努力使PBI 尽早完全完成
- 团队每天跟踪sprint中剩余的工作
- 团队中所有成员可以添加，删除和变更sprint backlog事项（SBI）
- spint内的工作是可以动态涌现
资产之增量 increment
特征
- 当前sprint以及所有完成sprint内，已完成的product backlog项的总和
- 潜在可交付，并符合完成的定义
- 必须是可用的产品，不管PO是否决定对外发布
完成的定义
为当前的项目列出至少八项DOD,可以覆盖质量，过程，功能和其他能想到的方面
sprint燃尽图
- 每天都要更新，通常在每天站立早会之后
- 用于度量sprint剩余工作的总量
- 燃尽图具有不同思路
- 可用于估算剩余工作量
- 可跟踪已完成项
任务看板 task boards
- 任务看板是对所有人可见，对团队研发，对需求，对市场，对客户均是可见
- 任务看板是要随时更新
- 用于直观展示sprint目标完成的进展
- 任务看板是团队工作可视化管理的工具
资产之敏捷估算
绝对值估算
用带有单位的数字 ，人天/小时，代码行数进行任务估算，可量化评估
相对值估算
没有单位的数字，一个数字与另一个数字的对比，可根据经验进行评估
速率
速率是团队可以在一个spring中交付多少个故事点，速率是一个历史数据，速率在第一个sprint开始时估算的速率时最佳猜测
速率只用来估算已完成项
速率使用与估算BACKLOG时一样的度量
计划扑克
- 计划扑克用户计划排定优先级
- 用于团队估算用户故事
- 计划做到什么程度，刚刚好或者用计划洋葱
玩法：
参加游戏的每个人各拿一叠扑克牌
客户或产品责任人挑选一个用户故事（backlog），并解释功能由大家讨论。
每个游戏玩家按照自己的理解来估计完成这个story所需要的时间，从自己手中的牌里面挑选一张合适的数字，并给大家看，玩家需要解释选择这个数字的原因，尤其是最大和最小的人。
然后根据解释确定重新估计事件并再次出牌，直到出现估计值比较平均。
意义在于合理预估开发时间，同时能保证开发人员准确理解用户需求。
事件之迭代（sprint）
特征定义
- scrum项目由一系列的sprint迭代组成，借鉴了极限编程的迭代
- 通常2-4周时间，最多一个月时间或者更短时间完成一次迭代
- 迭代的周期通常是定长的，这样有利于产生更好的交付节奏
- 当时间盒子到期时，迭代sprint结束
- 根据DOD定义，全部相关工作在迭代周期内完成
不可变更
- 项目成员不去变更sprint迭代的目标
- 不去改变当前已运行中的sprint迭代长度
sprint可以被终止
- 出于业务需要PO可以取消迭代
- 如果无法完成任何东西，团队可以和PO协商来终止迭代
- 终止后需要重新做sprint计划，所有未完成的工作放回产品BACKLOG
迭代sprint约定
- 在第一个迭代开始前，团队的工作约定协议时什么
- 讨论确定会使用的工具和工作过程
- 进行一次backlog梳理，DOR/验收标准/怎样演示
- 团队成员定义迭代完成的标准定义
迭代计划会议
开会是不可避免的，在迭代会议中需要指定相关的目标
- 定义sprint目标
- 选择团队可以承诺完成的product backlog项
- 决定如何实现sprint目标
- 创建sprint backlog
- 估算sprint backlog项
- 一个月的sprint迭代最长8个小时
事件之站立早会
- 站立早会需要在同一时间，同一地点每天开15分钟
- 参与者整个研发团队
- 目的：为达到sprint目标检视进展调整计划，注不讨论和解决具体问题，其他人可以受邀来旁听，只要团队成员，master和PO可以说话
- 为了避免其他不必要的会议，让研发从开会扯淡中解决出来
站立早会内容
- 昨天我完成了什么？为昨天的工作付出了多少努力
- 今天我要完成什么？今天的规划是什么
- 有什么障碍影响我的进度，有什么可以和大家分享
- 关键，不是项master汇报工作，是向项目组所有成员广播，属于自我管理。
事件之迭代sprint评审
- 评审用于检视和调整产品和产品backlog
- 团队成员展示相应的成果
- 产品负责人PO接受完成的工作及退回的工作
- 以DEMO新功能及其依赖的架构的形式，获取反馈和讨论要做的调整
- 非正式会议，不要用PPT，哈哈，最长不超过4个小时
- 全scrum团队成员参与
- 邀请所有的干系人及感兴趣的人士参加
事件之迭代sprint回顾
内容
- 对我们如何工作进行检视和调整
- 对迭代过程进行车徐的改进
- 时间盒子：一个月的迭代回顾不要超过3个小时
- 通常30-60分钟
- 全scrum团队成员参与
- 热烈欢迎其他感兴趣的人士进行参加
- 解决三个问题：开始做什么，停止做什么，继续做什么
- 输出下一个迭代的改进行动计划
quality敏捷质量文化
- 我们最高优先任务是通过持续的交付有价值的软件来使客户满意
- 持续的注重技术的优秀性及好的设计增强敏捷能力
- 破窗原理
测试Testing
- 敏捷过程异常强调通过测试来保证质量
- 质量，以及测试，从需求开始
- 在敏捷过程中，测试是一种持续性的活动，不是项目末尾才有的阶段
- 没有通过相应测试任何一个活动都不能称为完成
敏捷测试思维
- 预防胜于事后检验
- 尽早测试
- 全员负责
- 自动化胜于手动
迭代价值观
勇气，开放，专注，承诺，尊重
自我组织团队 并让其发生
如何实现自我管理
- 授权，不干扰，观察，支持，创造环境，先要不管
- 忍受错误及阵痛学习期
- 把问题带给团队
- 培养积极主动的行动文化，员工，你为什么来这里工作
- 从招聘开始寻找愿意不断学习，对公司及技术充满热情，充满好起信及愿意做不同事情的人
- 打造多面手或专才多用，实现任务分配的拉动系统
- 团队共同对目标做出承诺，从实现目标中获取成就感
- 没有一个人的失败，有的是团队的失败
- 简单的可视，即时更新的工具
- 充分利用团队内部互相汇报机制
- 简单的团队约定规则，多做结对
- 不断审视团队有没有机能障碍
- 引导团队充分利用回顾回意来做持续改进
- 避免人员经常更换
一个master
- 首先要了解自己
- 做团队的榜样，好的榜样
- 设立高的期望，期望一定要高于所预见的困难
- 指导不同的角色，团队，团队成员，PO管理者
- 考量自己作为教练的绩效
- 为创造价值而工作
- 活跃的“不做事”
- 善于提问
由招熟而渐悟懂劲，由懂劲而阶及神明
