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

我正好在职业生涯中参与过类似案例1和3的团队。2011年毕业工作，遇到的第一个团队便是采取敏捷开发模式，没有猜错的话，也正好是和案例3是同一家公司，我参与的是PC客户端研发团队，当时还将我们团队的敏捷实践作为学习案例贴在宣传栏上——男厕所坑位宣传栏:) 。2016年到T厂，正好是某APP团队按feature term模式拆分之后，没机会见识一个超级大团队的混乱。
身在其中，有时并不懂得其中的幸福，刚毕业以为所有的软件研发团队都该是敏捷的，有story、有需求拉通PMRDQA评审、有jenkins...等等，后来到了公司的深圳研发中心，才见识到石器时代的开发模式，一时震惊。越往后见识过不同的研发模式、不同的人，越觉得那些年在B厂呆过的第一个团队，无论人员战斗力、研发模式、氛围，都是难得再见的。好的研发模式，必须要有优秀的执行者，粗放的研发模式下呆了三年多之后，见到T厂某BG终于重视研发效能，重视工程师素养培养，真实可喜，如今新入职的小同学们，是否能够意识到，你们正处在前所未有的幸福之中？
附录：一些比较新的名词：测试左移、质量内建。
《持续交付2.0》读后感(二)：价值做指引，不断探索发现自己走向成功的路径
今天，分享的内容取自这本偏技术的图书，不过其中有些部分还是可以给我们一些关于工作和生活的启发。
- 1 -
持续交付的双环模型
书中最重要的一个概念，就是持续交付的双环模型。
这个模型，描述的是互联网产品从用户需求提出，到确定解决方案、验证解决方案的完整过程。其中所谓的双环，即指价值探索环（简称「探索环」）和快速验证环（简称「验证环」）。
探索环的目标，在于识别和定义业务问题，并制订出最小可行解决方案，进入第二个环。
而验证环的目标，是以最快速度交付最小可行方案，可靠的收集真实反馈，并分析和验证业务问题的解决效果，以便决定下一步行动。
通过这个概念，我们看到一个产品概念的形成，首先，需要对问题进行定义（提问），对结果目标进行描述（锚定），在此基础上探索和提出具有可行性的多种解决方案（共创），最后，针对提出的方案进行选择，找到接下来进行实践的解决方案（精炼）。
在这个过程中，我们不能看到用户的问题后，就匆匆忙忙给出一个想当然的解决方案，而是要从问题背后，找到其真正的诉求，深挖用户需求背后的痛点，在此基础上提出可能的解决方案，形成最小可验证模型（MVP）进行验证。
而验证的过程，需要的是「快」，毕竟「天下武功，唯快不破」。通过快速的将方案转换成符合质量要求的软件包（构建），交付给用户，为用户提供服务（运行）。在用户使用的过程中，收集相关使用和反馈数据，确保服务的正常运行（监测），对其数据进行分析对比，确定接下来近一步解决方案的完善（决策）。