瑕不掩瑜:《大规模敏捷开发实践》
Posted 正见正思
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了瑕不掩瑜:《大规模敏捷开发实践》相关的知识，希望对你有一定的参考价值。
这是一本被严重低估的书，比我读过的大部分书，干货与精华更多。在网上下单后，老板说只有影印版（图片是黑白的），买回来读完后，我觉得真的超值了。介绍了HP LaserJet产品线敏捷转型的成功经验。如果你正为此困惑，并认为推荐理由合适，墙裂建议一读。
推荐理由如下：
典型传统组织的通病、各种研发常见的顽疾都有剖析。
团队参与者编写的，翻译者也是参与者，深刻独到。
400人的规模，小团队到中型组织数字化进程中的障碍多有涉及，可预见未来。
给他们服务的咨询师是业界顶级牛人：Jim Highsmith、Jez Humble。
极致的务实接地气，不是scrum但非常接近。
架构演进、持续集成、自动化测试、持续交付的实际落地。
四年的周期揭示了做到优秀需要付出的投入。
涉及分布式团队。
涉及硬件。
--------以下是部分精华摘录--------
采用的敏捷\精益原则：
减少开支和浪费（保持简洁）：分析日常活动是否合理，改善所有事的效率。
量力而为：限制WIP，少承诺、多出活。
打开瓶颈：愿意暴露问题以打开瓶颈。
越早越多地集成：多次提交少量功能的代码，并做增量测试，简单/自动化。
让计划有规律：四周一迭代。
让参与者定义敏捷/精益实践：制定流程的人跟着流程走一遍。
达成的共识：
【起点】需求在不同阶段应该有不同的粒度，不可能面面俱到。
【终点】代码经常性地集成，确保任何时间点都可交付可工作、高质量的软件。
【过程】时刻遵循原则，不停回顾原则是否过界了，这是成功的一个关键点。
整体思路：
让架构支撑业务目标。
用敏捷的理念稳固新架构。
持续集成：减少编译资源和时间。
质量系统：自动化分层测试。
自动化发布流水线：带来生产率的提升。
最优化预测的流线型计划。
识别并管理劣势项。
关于架构：
代码可自动识别运行在什么样的硬件上并自动进行硬件配置。
架构专注于支持多功能打印机，嵌入了基础功能（任务队列管理、性能、并发登录/运程用户操作）。
功能可开关，支持将新的功能被授权后，直接应用到整个产品线。
一旦架构确定下来，就不惜一切代价保持它的方向性。
创建一些标准、工具和团队来长期维护架构：没有自动化的单元测试会非常难以维护。
迭代地重构架构，4周一次架构演示，持续了两年。
有一个强力的架构师、原型小组频繁审查以增强部门对架构的责任感和信心。
关于计划与跟踪：
用初略预测和趋势观察预测：预测每周期有多少请求，有多少交付力量。
清晰的优先级：由PO维护，应考虑计划外工作，变更分三级响应，冲刺目标就是高优先级任务。
及时的用户故事定义：新的、已筛选、已分配、已研究、审核过、开发中、已实现、测试中、已验证。
让业务也支持敏捷计划：仍有长周期承诺、业务决定哪个功能先做、接受任何时间的变更、用交付而非计划做承诺、交付前尊重开发团队的权利。
路线探索：
自上而下：“被敏捷”永远无法组建起一个真正的团队。
自下而上：开发人员理解并坚信敏捷的好处，但没人引导或者没有管理层支持。
真正的秘密：关注群众，所有的事，都与人以及如何管理有关，流程是第二位的。
尽可能减少指定业务目标的人数，以帮助大家将注意力集中到生产率上来。
根据群众意愿而改变：人的感受以及感受的程度更有影响力。
沟通始于度量，探求事实，终于行动。
小里程碑目标。
将目标关联起来跟踪。
学习并按节奏调整。
研发改进效果：
最初每天执行1次构建，最终实现每天执行10-15次构建。
最初每天由总构建人进行大约20次代码提交，到每天所有开发人员有超过100次的代码提交。
开发人员每天更改和添加的代码行数达到了7.5-10万行（400人团队）。
回归测试的周期从6周缩短为1天。
最终业务收益：
开发人员用于创新和新特性开发的时间从5%增加到40%。
总开发成本降低约40%。
处于开发状态的项目增加了约140%。
每个项目的开发成本降低了78%。
以上是关于瑕不掩瑜:《大规模敏捷开发实践》的主要内容，如果未能解决你的问题，请参考以下文章