规模化敏捷读书笔记思维导图模板_ProcessOn思维导图、流程图

案例：惠普打印机

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

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

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

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

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

6-7章

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

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

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

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

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

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

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

宣言背后的原则

采用的敏捷实践

1.减少开支和浪费

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

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

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

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

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

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

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

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

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

敏捷与瀑布模型对比

瀑布

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

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

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

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

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

2.让敏捷辅佐业务目标

业务与价值主张是什么？

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

成本和周期驱动

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

识别所在的业务实体

钱和时间花哪里去了

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

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

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

3.让架构支持业务目标

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

没有清晰的系统接口图

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6.持续集成和质量系统

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

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

7.驯服计划兽

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

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

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

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

11.真实世界的敏捷结果

12.提高企业管理灵活性

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