规模化敏捷读书笔记

1.我们需要遵循的敏捷核心原则什么

2.想优化的业务驱动是什么？你可以借用敏捷来让你的业务取得成功，而不是被他束缚知道所有人项放弃敏捷为止，

3.如何实现一个可以覆盖所有功能的架构，以及如果和用敏捷的方法实现它

4.创建设什么样的管理风格

使我们产生 10 倍以上效率的流程细节（Nuts and Bolts） - 持续集成，

自动化多层次的质量保障，

用户故事定义以及轻量级的开发能力预测。

把敏捷引入到交付产品和功能的过程中时，非常有必要对敏捷流程做调整以适应我们的环境

分布的组织环境中大规模敏捷碰到的一些调整，包括如何做项目管理，如何组织团队（职能型还是业务型）以及如何处理跨文化的团队协作。

，收集了使用敏捷后我们获得的业务成就，以及介绍什么是企业级敏捷这个新名词，同时还是描述了我们如何定义和Firmware/软件部门之外的合作伙伴之间的接口方式。最后还讨论了我们所推广敏捷的方法和行业内推行的敏捷有哪些不同之处。

6-7章

我们从建立什么样的基础来推行敏捷实施

案例：惠普打印机

宣言背后的原则

1.如何减少编译时间提高竭诚次数

1.减少开支和浪费

交付日期， 并行项，依赖项影响工作效率

2.量力而为：WIP 工作进行项

3.敏捷计划的关键是能不能和市场、业务的领导的方向相一致，同时也需要重点引导他们对产品的预期。

3.作为管理层，需要经常俯瞰系统全局， 理解瓶颈所在并及时优化团队， 建立亦庄文化， 并让团队有意愿提出问题，并解决

1.多次提交少量功能的代码，并做增量的测试

4.我们在做主代码变更的时候，可以通过树立严格的代码规范来保障代码质量。

5.让计划有规律可循：在固定的时间盒子内

6.让参与者定义敏捷和精益实践：也只有让流程制定者参与流程实践，知道了利弊之后，他们就会对其他参与者问：”流程那里有问题？“以及”我们怎么样做才可以做的更好呢？“

采用的敏捷实践

敏捷捷方法在其实践上证实了他可以很好的解决瀑布模型的几大缺陷。第一，遵循 JIT（Just in Time）原则，从最重要的功能开始，并实现客户的基本需求，而不是等到所有功能都详细分析清楚了。这样所带来的好处是，

问题：一是需求会随着团队对项目了解的深入，随时可能被扩散，刚开始认为重要的功能，之后可能会被放在

这样做的原因是可以确保项目在任何时间点上都可以交付一个可工作的高质量的软件。

开发，集成和测试周期在瀑布模型中会显得特别长，有时候会一拖再拖没有终点。

广泛收集需求阶段：在这个阶段，项目开发的细节都被记载在文档里，使得开发人员可以清楚的了解到他们想要做什么样的东西，什么时候完成。

瀑布

敏捷与瀑布模型对比

1.推行敏捷原则还是敏捷实践

最终能给客户，用户带来什么成就

业务与价值主张是什么？

是什么消耗你所拥有的资源，以及阻碍你及时完工？

成本和周期驱动

钱和时间花哪里去了

战略目标（将要吧业务发展花钱到哪里去）

识别所在的业务实体

 创建一个稳定的可以随时发布的应用程序代码集 建立自动化测试机制，并在每天晚上可以自动做回归测试 自动化集成，包括自动回滚不匹配的代码 极大程度的减少新产品从研发到投放市场的研发投入，同时保障产品质量 重构产品架构，提取公共产品工作作为分支，从而减少产品之间功能的差异性（即使已经发布的产品也可以获得更新） 数十倍的提高生产效率（编译次数和线性开发流程时间） 创建一个公共的开发平台，所有开发人员可以很轻松的获得需要的帮助 重新考虑产品的发展目标，并减少需求估算等活动的时间（承诺交付的时间估算）

业务目标转换到 Firmware 开发目标

2.让敏捷辅佐业务目标

组织获得一个清晰的组织目标和产品线路图。如果现在不搞清楚，未来很可能在每天或者每个冲刺（sprint）的过程中又迷失方向。

没有清晰的系统接口图

为开发的时候不得不考虑对外设的影响

如何面对先前陈旧的架构的困难

3.让架构支持业务目标

代码可以自动识别运行在什么样的硬件上，并自动进行硬件配置 MFP 设计中心（以前的架构是只关注在简单功能的打印机上；新架构专注在支持多功能的打印机，功能包括：任务队列管理，性能，并发登陆/远程用户操作） 功能可开关的架构设计理念（是一次建立全新业务模式的机会，可以支持将新的功能应用到整个产品线；例如，用户在 1 年前买的打印机，如果授权了更新，那么他的打印机将始终拥有最新的功能，而且跟其他所有 HP 的打印机产品的功能是一样的）。

开发出一个解决方案，减少不必要的分支创建，真正需要的就是在一个主干上开发一套代码，可以支持现在所有新产品和已有产品。

必须具备一个强力的架构师，可以纵观全局，推进计划，方法和决定的落实。如果架构师本身也参与落实这些活动就更好了。任何架构在没有被实现之前都是虚构的，所以架构师需要进入真正的实施过程，亲手去编写代码才能真正对架构带来改进。此外架构师还必须深刻理解实现过程中的技术难点，在团队需要帮助的时候，积极的提供技术援助。

经过频繁的对原型小组进行审查，部门上下对于架构责任感和信心变强了。也正是这么多轮的审查，

敏捷周期或者小里程碑 MM（Mini-Milestone）

每 4个星期一次的演示功能的会中，我们会和开发人员一起展示最近实现的一些薄片

确保团队遵循敏捷的原则和实践冲刺回顾的人

想推广的文化是确保开发人员演示的内容是已经集成到了我们的主干上了，而不是本地的一个开发版。因为在此之前，开发人员往往会打开本地刚刚调试过的代码来演示。

询问演示的功能是否执行过自动化测试

回顾老架构的实现方式，并决定采用完全不同的方式进行开发新架构的敏捷实践

支撑业务的架构：动态演进以及向下兼容

review Adjust

Prove with Prototype

Informal Review

define a thin Slice

如何创建新的架构的特性需要支撑我们的业务需求以及解决原有架构存在的问题

4.如何用敏捷理念稳固新架构

我们组建起一个真正的团队，因为“所有人做是因为这样要求的”而不是“我这样做是因为这样有价值

一堆开发人员理解以及坚信敏捷的好处，但是要么没人真正引导他们去实践，要么没有管理层支持。

所有的事都跟人和如何管理有关。

跟如何协调一大群人交付相互关联的代码有关。

跟在一个组织里，探索哪些改变是可行的，哪些是需要调整，这样我们可以用敏捷方式来做我们的计划我持续改进我们的生产率。

我们如何创建一个敏捷的系统可以将这些概念和人整合在一起，既可以做到快速高质量的反馈，又不用担心不管接下来要实现什么样的需求，产品或者是创意?

如何让敏捷在大型组织中落地

根据群众意愿而改变

需要一个好的工具来跟踪实际工作进度，哪些完成了，哪些还没完成。

我们不是通过度量项来管理，而是用度量来发现哪些地方还没做好，如果有问题可以讨论一下

沟通从度量开始

Agile Adjusments

Learnings

Conversations

cascading Objectives to Track Progress

Mini-milestone objectives

敏捷迭代模型

想要实现敏捷，特别是在大型组织中推行敏捷，必须有创新和冒险精神，要有像一名企业家一样的眼光。而成功企业家的一个特性就是乐观。善于冒险的企业家往往能产生一些创意，使得企业向前发展

我们每天早上都会自动发一封目标和度量结果总结的邮件，邮件会附带一个链接，打开链接可以获得每小时在线历史数据。

将目标关联起来跟踪（工具）

迷你里程碑目标

前提：价值主张明确和稳定前沿的架构基础

5.大型组织敏捷的真正秘密

敏捷持续集成的基本思想其实就是任何时候都拥有可以符合发布要求的代码。

我们将进入敏捷开发的细节部分（持续集成能力，质量系统，最大化输出及最优化的预测的流线型的计划）

6.持续集成和质量系统

我们先前制定了 4 星期一个周期的冲刺（MM），基于这个长度，我们把用户故事的颗粒度拆分到一个开放人员大概 2 个星期能够完成的大小。这样就能追踪每个冲刺完成了多少用户故事，根据这个开发能力（velocity），就能预测大概什么时候可以完成 1-N 的功能列表，当然我们对于低优先级的功能我们不承诺会按时完成。

7.驯服计划兽

8.在大型创新组织中估算难点

9.横跨美国和印度文化的敏捷高效开发模式

10.正确的工具：对生产效率有量级提升

11.真实世界的敏捷结果

12.提高企业管理灵活性

13.规模化敏捷结果和我们预期不同之处

规模化敏捷读书笔记

各个角色

识别成本和周期驱动的第一步是理解我们所拥有的人力资源都被投放到了哪里？他们在做什么工作，研发成本都投放到了哪里？

如何在保障产品质量的同时让发布做的更为频繁和提前发布。

我们应该做的是提高开发人员的生产效率和组织的灵活性，让我们设计的产品的功能和特点能够引导市场，我们真正需要的是一个开发这样一个解决方案。

技术曲线的特定点，就是用户已经满足了足够快的打印机速度和打印质量，再高的速度和质量已经不能满足他们在产品差异上的要求。

接下来就是去弄清楚的理解我们产品的价值主张是什么。是减少对现有产品的维护成本？还是在有限资源的情况下去发布更多的产品出来？又或者是趁此机会向客户说明我们的产品的差异性？完全取决于各个公司的商业主张和成本驱动。

如果这些作业成本可以从开发，系统中用自动化，或者工程实践替代，那么这些释放出来人力可以投入到创新和价值开发中去了。

以此拉进我们在投资和产品价值增值之间的差距。