作者：李宏喜 IDCF研发效能（DevOps）工程师（中级）认证学员
在软件研发效能（DevOps）的学习过程中，我认识到诸位老师从软件全生命周期的不同角度，讲述着研发效能的提升。
敏捷宣言从2001年诞生到现在，已经有很多年了。敏捷逐渐地融合精益等思想发展延续至DevOps，而DevOps又在和软件领域的多个方面融合，产生着不同的分支。在这个发展的过程中，数据产业也在不断地发展之中，人们开始从数据的角度思考生活之中的方方面面。那么是否可以从数据的角度思考系统，进而思考数据系统在软件研发效能（DevOps）提升过程中的变化和发展呢？本文将对此做一个初步的思考。
我认为DevOps是一个基于广义流水线的以价值流交付为特征的理念、方法、工具的系统性的结构。而数据价值通过迭代式的构建、通过系统性的持续交付不断得到体现。
在课程的【开发与交付】这一章中，徐磊老师讲到：广义流水线的起点是一个idea。让我想起了《持续交付2.0 业务引领的DevOps精要》（作者：乔梁）这本书中讲的："持续交付2.0双环模型涉及企业内多个部门与角色的合作，而且其目标是缩短端对端（即从idea到idea）的闭环周期，这必然会影响到内部合作方式与流程"，而在吴军的《数学之美》中讲到："信息是消除系统不确定性的唯一办法"。彼得•德鲁克也说："成果存在于企业的外部，在企业的内部只有成本"。我个人认为软件研发的过程是一个从提出假设到验证假设的过程，也就是假设驱动的过程。而信息可以看作是数据的业务概念。我个人的理解，如下图所示：
01过程
徐磊老师在讲【开发与交付】时讲到了"研发过程全景图"，其中设计的过程是由架构模型树和条目化需求，在持续交互中形成不同版本的开发任务而体现的,如下图所示：
研发过程全景图局部
这也让我想起问题域和方案域的概念，在问题域和方案域之间，通过联想、特征的触发，在交互之中，不断地认识。
问题和方案的交互
在学习杜伟忠老师的【产品设计】的课程中，我认识到："整体的体验交互设计是软件开发中的非常重要的一环。整体的概念一致性是一个重要的原则。在与用户的迭代式的交互过程中，原型逐渐明确,概念一致性得到体现"。我也想到通过设计树和原型设计的连接，又使得设计具体化，为迭代式开发的进行做出准备。而这个具体的过程可以通过Scrum中的PBL的梳理会这类的会议来达成。
在【测试与安全】这一章中，陈晓鹏老师讲到了三种测试用例的设计技术：错误猜测法、等价类分析法、边界值分析法。其中MECE原则是指相互独立、完全穷尽。这使我想起了数据分类的思维模型，进而对于数据的系统，有了一个认识。我们的软件系统可以看作是一个数据的系统，这让我可以从数据的不同的视角，去看系统、去理解系统。在实践中, 结合三种测试技术，去设计测试用例，从不同的视角去思考系统的行为，而测试的过程就像是解一个方程式。当然，我们可以不仅仅在测试这一个角度，去理解数据系统这个概念。
赵舜东老师在讲解【运维与监控】这一章时，讲到了微服务的拆分："应先基于数据库隔离维度进行拆分，再基于服务关联和耦合维度进行拆分"。而KentBeck在《实现模式》中讲到4个原则，节选如下：
- Local Consequences
It can be understood gradually without first having to assemble an understanding of the whole.
- Minimize Repetition
Duplication isn't evil, it just raises the cost of making changes
- Logic and Data together
To make a change, the logic and data are likely to have to change at the same time.
4 Symmery
If a similar thought exists in several places in the code, making them symmetrical to each other is a good first step towards unifying them.
我认为这四个原则与"应先基于数据库隔离维度进行拆分，再基于服务关联和耦合维度进行拆分"在原理上是相通的。而这种拆分的方式也减少了出错的可能。数据总是与逻辑在一起，构成着系统。这也和《持续交付2.0 业务引领的DevOps精要》（作者：乔梁）中讲到的"大系统小做"的原则一致。
我在《实现模式》（作者：KentBeck）这本书中，看到这样的代码:
void process() { input(); tally(); output();}
我有了一个新的认识，下图所示：
DevOps所倡导的迭代式开发过程，将原有的瀑布式的过程，拆分成多个迭代的过程，将复杂问题的管理简单化。
反之，数据系统的一个个的端到端的对称，在DevOps这个迭代的过程中持续得到体现，犹如图1所示的价值交付的过程。
徐磊老师在【开发与交付】这一章中，讲到"微服务立方体"这个概念，在单体架构向微服务架构逐步演进的动态过程中，在三维交互的过程中，数据的一致性是否可以理解为数据系统的对称呢？
也因为数据在三维空间中的位置的确定性，是否可以通过数据来反向思考系统在某一个位置上的特征呢？从而对于价值交付的过程，做出反向的思考，做出整体的结构化的优化呢？这里的整体是否可以涵盖软件的系统和组织的结构呢？徐磊老师说:"管理属性和工程属性的衔接点就是版本管理"，这又与系统在三维空间中的位置，又有什么样的关系呢？我初步的理解，如下图所示：
正如《奇特的一生》（作者：格拉宁）这本书中所讲："复活"要容易、准确，因为数据很多，空间和时间坐标都可以复制。
在软件研发过程中，在空间中复盘、复制，我的认识，如下图所示：
从数据系统的角度去思考微服务的构建或者拆分、思考敏捷测试之中的测试用例的设计、思考"大系统小做"的原则、思考KentBeck的实现模式四个原则、思考"微服务立方体"的概念。多角度的思考带来了认识的提升。
02实施
在项目的实施过程中，通过迭代式的过程管理，使风险可控、使团队能够迅速学习和改进。而在这个过程中， 采用正确的诸如scrum的方法则是关键。
在自组织的团队中，应发挥每一位团队成员的特长，根据具体的开发工作，组合不同特点的团队成员，考虑团队成员的工作状态，合理分配工作。
敏捷开发中倡导代码集体所有制，我个人认为团队的核心技术人员应对架构的合理及稳定负责，也应对版本的发布和功能的交付负责。而开发人员在协作和讨论中可以做局部和细节的设计做出调整。我认为基于Git的版本管理策略是符合代码集体所有制这一原则的。
在课程中，王立杰老师也讲到"如何有效地落地DevOps"，讲述了以用户为中心，坚持自动化、协作化的概念。彼得•德鲁克在《卓有成效的管理者》中讲到"唯有从事对的工作，才能使工作有效"。价值是由用户决定的。我个人认为：在软件的实施过程中，通过Show case的这种形式向用户展示可以运行的、关键的、简单的业务功能，得到用户的反馈，并且在持续的迭代中使用户的 idea得到持续实现，这是做"对的事情"的过程。而这个过程离不开自动化和协作化，通过快速、稳定地部署正确的版本，用户和开发团队都将会得到积极的反馈，这是行之有效，这是正确地做事的过程。这个过程离不开理念、方法、工具的组合。
在实施的过程中，如何处理团队间、客户之间的协作的问题呢？我个人认为，应建立组织级的沟通机制。在实践中，广义流水线的建立离不开组织之间的信任与沟通，离不开思想的转变。
《数学之美》 (作者：吴军) "信息是消除系统不确定性的唯一办法"。在迭代式的开发过程中，用清单等形式采集产品研发所需要的信息，持续消除需求的不确定性。通过假设驱动的方式得到反馈，持续系统化地消除系统的不确定性，拥抱变化。数据系统在不确定到确定中，持续地变化着。
在实施的过程中，正如陈晓鹏老师所讲敏捷测试有自身的特点，需要和迭代式的敏捷开发相结合，拥抱变化。我认为：敏捷测试不应该是瀑布式的，先设计完成所有的测试用例，再来测试。而应该在PBL之后，根据实际的情况，运用错误猜测法、等价类分析法、边界值分析法等不同的测试技术，快速设计迭代开发所需要的测试用例，在适应变化中，正确地做事。
通过学习庄俊乾老师的【安全领域】的课程中，我认识到价值的交付，不可避免地会面对安全的问题，数据的安全是一个不能忽视的问题，而DevSecOps则是DevOps在安全领域的发展。
最后，在动态的迭代中，持续地不断认识数据系统的变化，认识价值的交付。从数据系统的这一角度，对研发效能（DevOps）的这个process，做初步的思考和学习。我也认识到，在数据的时代，DevOps将会得到更加广泛的应用。
参考文献：
《持续交付2.0 业务引领的DevOps精要》 （作者：乔梁）
《数学之美》 (作者：吴军)
《暗时间》 （作者：刘未鹏）
《Implementation Patterns》 (作者：[美] KentBeck)
《卓有成效的管理者》（作者：[美] 彼得•德鲁克）
《奇特的一生》（作者：[俄] 格拉宁）