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

书中讲到了四大原则：
四个原则概括下就是要「聚焦」，特别是在时间紧任务重的情况下，更是要聚焦，只有聚焦了，双环模型的周期才会缩短。
最近团队有几个同事在开发一个独立的类邮件模块，功能涉及到收发邮件、删除邮件、收藏等功能。客户第一阶段关注的是，先要有这样一个功能模块，功能可以后面完善。聚焦的做法就是，快速完成邮件的收发功能，在交付期前有多的时间再完善删除邮件、收藏等功能。到了交付期，删除和收藏功能没有完成，不影响我收发功能的发布。
如果一开始将收发、收藏、删除等同时并行在做，可能到了最后时间，每个功能点都完成了一部分，但却不能交付客户。
我们开发的产品是一个功能强大的快速搭建平台，最近一客户使用我们平台来搭建业务功能，上线时间非常紧迫，这时就应该聚焦有哪些必须（阻碍业务）的功能目前还不能实现，利用探索环提交到产品团队，讨论出最小可行解决方案，然后在验证环快速出成果交付客户验证。
这时如果客户关注点在平台的非核心功能（主业务无关），提出各种优化需求和新增需求，这样就本末倒置了，最终上线会有极大的风险。
「Andon」是一个信号灯，丰田公司要求员工，在生产流水线上遇到麻烦，都可以拉这个信号灯，生产线会立即停下来，直到问题解决，流水线才恢复运行，不让问题流到下一个环节。
安灯系统最重要的是让每一个员工都有质量意识，软件开发团队的中的成员往往就缺少这种意识，为了能早点完成任务，常常忘记完成这些任务的最终目的。
在这里分享一个小故事：
从本职工作来说两人都完成的挺好，但没有价值。仔细想想一想，我们有时候是不是就像上面挖坑的人或是填坑的人一样？所以团队的每个人都应该为结果负责，都要能在适当的时候勇敢地拉下这个信号灯。
持续交付在实践过程中离不开自动化工具，大体可以分为自动化构建和自动化测试。
不同大小的公司，或者处于不同阶段的团队，会采取不同的工具，适合自己的才是最好的，之前写过的几篇文章可以给大家参考：
1、GitLab 配合 Jenkins 打造自动化部署 2、在团队中使用 Gitlab 中的 Merge Request 工作模式 3、在 CentOS7 中安装 GitLab 4、敏捷下的需求和代码分支管理 5、不断进化的分支和需求管理
在上面的文章中有介绍我们是采用 GitLab 的 Merge Request 模式，对应到书中的分支策略，就是是主干开发，主干发布，因为每一个 Merge Request 分支的周期非常短，最终还是合并到主分支进行构建发布。但这种方式有一个问题，当同时并行任务过多时，合并时容易混乱。后面会尝试主干开发，分支发布的方式。