持续交付2.0读后感精选( 二 ) 交付|团队|双环|持续|敏捷|验证「问人人知识网」

除了介绍文化之外，还重点介绍了，如何建立企业文化，这点和团队管理比较像，作者总结的很完善:（1）定义想要做的事情；（2）定义期望的做事方法；（3）提供相应的培训。（4）做些必需的事情来强化那些行为。
读到这里是，心有戚戚焉，也是总结了我在团队管理上的探索：我希望我们团队是一个（1）执行力强又有创造思维；（2）协作高效；（3）有分享精神、有影响力；（4）持续进步的团队。于是我总结出来一套做事方法，并采取一些制度流程：制定需求开发的标准流程、定期每周一次团队分享会议、每周复盘团队OKR、每周复盘个人需求规划&执行情况、鼓励每个负责人自己提炼需求——技术驱动、强制CR制度、强制文档总结、强化导师带人时间投入等等。还提供了一些职业素养的指导文档、新人手册、导师文档以及推荐阅读书籍，并在团队会议、奖项申报、绩效考核中强化团队导向，让符合团队导向的同学拿到更多激励。
接下来有多个章节，主要介绍了软件研发流程中的要点。首先是软件系统架构，可持续交付对系统的架构有要求，常见的是微核架构和微服务架构。作者总结的持续交付架构写得很好：（1）为测试而设计；（2）为部署而设计；（3）为监控而设计；（4）为扩展而设计；（5）为失效而设计。5个小点很精炼，高扩展、容易测试、容易部署、可监控、有容错，仔细思索，影响交付效率的通用的要点就是这些。
然后是需求协作管理，包括从需求产出到需求交付的全流程，其中很重要的点是如何拆分需求，INVEST原则：独立的、可协商的、有价值的、可估算的、规模小且适中的。需求编码完成之后，就是部署，接着介绍了部署流水线原则和工具的设计，这里详细介绍了流水线涉及的每个环节.
再接着，回过头来看开发过程的分支策略，当前推崇的是主干开发，主干发布，注意：只要分支时间存在时间极短（文中有两个数据：不超过1天、不超过3天），及时合回到主干，那么就可以算作这种模式。代码编写过程中怎么能够持续的合入代码、快速编译反馈，依赖基础设施建设、研发流程，以及工程师的素质。要实现持续高效的代码合入，减少人力，在代码质量上需要自动化——自动化测试。为了实现流水线的“一切自动化”——软件配置管理就显得非常重要，软件配置管理是指在整个软件生命周期中，对生产和运行环节中相关产物的管理。接着是低风险发布，指在发布环节如何保证低风险高效率。最后是监测与决策，服务上线之后，监控少不了。
最后三个章节介绍了三个案例。（1）将大团队拆小：feature term模式的实践；（2）小团队从“假”敏捷到“真”敏捷转换的实践；（3）小团队从混乱模式进入到敏捷开发，再进入到持续交付，并形成devops文化的实践；