1.1 敏捷原则
原则是宣言的拆解
自组织：技术可以请求外援，非技术问题自组织解决；自组织是后期，不是一上来什么问题就用自组织解决
1.2 敏捷实践：Scrum
Scrum中的角色
PO：
PO是对团队内，不是指的产品线对外
PO是重要角色之一，所有会议都必须参加，或有代理人参加
PO决定发布时间，不是以技术的评估时间做发布，不是对功能的发布，是对价值的发布
PM和SM：
早期相对统一，对项目各知识领域进行管理
SM不做决策，鼓励言论自由，保证仪式，团队有问题有限内部讨论解决，保护团队一个整体
SM要懂团队，帮助团队提高生产效率（如相关工具）
Dev Team：
除了PO和SM都属于Dev Team
自主选择、全职能（对所有人一致都有全面能力）、跨团队本身不进行解决（不关注别的团队事情）、决策在团队内、平级（可以结对完成，但不能分配任务）
全职（全情投入）和全职能
三种工件
Product Backlog：
排了序的需求池，技术类需求也得PO同意，遇到事情找PO，除了上线后发生了故障可以自行决定（如hotfix）
DEEP：被估算的，每次评估的量多少是合理的；涌现的，逐步提出可持续性
Sprint Backlog：站会看状态以故事的维度而非任务维度看
DOD（完成的定义）：做成什么样就是完成了，通过流程或者本身交付物来界定
Product Increment：开发分支完成不叫完成，要集成到以往的交付物中，目标是交付可用，是否上线（发布）PO决定
5个仪式会议
5个会议：产品梳理会、P迭代计划会、D每日站会、C迭代评审会、A迭代回顾会
3355中的5：指的是PDCA的部分，P、D、C、迭代、A
1）待办事项梳理会：
PO梳理Product Backlog（DEEP）
增删改查用户故事、估算规模、故事优先级排序、拆解用户故事、可以邀请利益相关者来进行参与和评审、可以有技术相关的讨论
外部人员可以参与的会
梳理会也是故事会，所有需求以用户故事维度来讲述
Small：适度的小，不是越小越好
用户故事的分层
用户故事地图，所有用户故事铺开，罗列每个用户故事，从横向的角度，界定范围，作为发布计划
用户故事->用户故事地图-发布计划
2）Plan迭代计划会
确认做什么：团队承诺
确认怎么做：拆分任务
时间分配：
2周的迭代，2小时选择故事（确认做什么）、2小时决定怎么做（拆分任务），计划会不超过4小时
1个月的迭代，4个小时选择故事，4个小时决定怎么做
输出：燃尽图，燃尽图在迭代计划会后可以画出第一版
3）Do 每日站会
鸡和猪可以参加，但只有猪（三个角色）可以说话
用来做每日承诺，可以暴露问题，而不是讨论会议
4）Check 迭代评审会
和外部交互的会议（评审会可以提意见）
时间是计划会议时间的一半，2周2个小时，1个月4个小时
输出：修订版产品代办事项列表（根据大家的意见，对最初的ProductBacklog对修订）
迭代开始的标志是计划会，结束的标志是回顾会，而不是评审会
该会议为了和利益相关方步调保持一致，如果相关方对人员、需求、交付有疑惑，可以来参加评审
4）A 回顾会
时间：2周迭代40分钟以内，除了每日站会最短的会
迭代的最后执行，结束后可以开始新的迭代
三个角色都可以参与，外部人员不要参加回顾会，开始最好dev team参加，有需要在拉PO参加
1.3 精益、极限编程
精益思想
原则：
客户角度交付价值（JIT，just in time，准时、零库存、客户有需要在下单）
杜绝浪费（one piece flow，避免多任务）
持续改进（Takt 节奏感）
零缺陷（Zero defect，就地发现就地解决）
看板（看板实战）
Scrum中的看板就是一个透明展现平台
精益中的是Kanban系统
三个简单原则
可视化、限制在制品、管理流动
三个原则->六个实践
1 可视化
2 限制在制品（找到瓶颈，最先饱和的阶段，从全流程而非局部进行优化）
3 管理流动
4 显示化流程规则- 通过明确的规则，对整个流程展开讨论，讨论基于客观数据而不是假想、感觉、传闻（作者认为是可视化的一部分）
5 建立反馈环路- 关注从流程中获得的反馈（作者认为是管理流动的一部分）
6 协作式改进、试验中演进（使用模型和科学方法）- 鼓励人们使用模型（如约束理论、精益思想）来推动整个团队持续改进(作者认为这一观念深植于看板所基于的精益原理之中，而非看板本身的原则，是看板发源的环境和生态)
极限编程
核心实践
由内而外，技术->技术管理->技术向管理过渡
重点实践：持续集成、TDD、结对编程、代码集体所有、小型发布
TDD：本质是开发技术，（先写测试程序，然后编码实现功能）测试先行开发和重构
结对编程：老带新、技能复制（有人会有人不会）、攻坚（两个水平差不多的人，合理解决）、彼此遍历；一个电脑一个键盘，不在乎时间和人员角色；并非double 工作量；好处：代码共有、保障质量，缺点：成本高
代码集体所有：所有人的代码所有人都能看和修改
持续集成CI：尽早的做集成操作（DDTR，design develop test release）
CI的工作流：提交代码到代码库、CI server监听代码库的变更、CI server出发自动化构建、CI server触发自动化测试、通知相关方
累计流程图
度量整体项目状态
利特尔法则
减少等待时间，减少LT队列长度，或增加产能
产能一般短期很难改变，因此要限制LT
前置时间LT：等待时间+制造时间，等待时间一般远远超过制造时间
