软件工程pipeline梳理

文章目录

软件工程pipeline梳理
- 为什么需要梳理软件工程的pipeline
- 软件工程pipeline的概念与注意点
- 软件工程pipeline中的最大挑战
- rethink
- 相关资料

软件工程pipeline梳理

为什么需要梳理软件工程的pipeline

反思自己日常工作中的认知和行为。以算法/软件工程师为代表的技术工种往往会存在以下的“误区”（可能也仅仅是大家戏虐的段子）：“需求沟通是扯皮”，“开会是浪费时间”，“代码review就是走个过场”。上述认知的获得，很大程度上是因为对一个完整的软件/项目周期的不了解，从而有点拘泥于“写代码”这一“有技术含量”的点上。成熟的算法/软件工程师尽量不要被一叶遮目，而不见泰山。
梳理软件工程的pipeline可以强化自己的全局意识，更接近事物的真实面貌。

软件工程pipeline的概念与注意点

在这里插入图片描述
软件工程领域针对流程建模兴起不同的流派，例如瀑布模型、V模型、增量过程模型、演化过程模型、螺旋模型、协同模型、演化模型等。上图左上角是一种保留各流派模型基本要素并吸纳众多模型思想的一种流派，称之为统一过程（Unified Process）。其阐释为：“用例驱动，以架构为核心，迭代并且增量”。
Unified Process的概念一般与UML配合使用。实际开发中，有供方便使用的流程管理软件：国外的如Jira，国内的如Pingcode（这个目前也没太使用过，要尝试起来）。
关于Unified Process中具体的步骤，在实际的工作中有以下的注意点：

沟通、策划阶段：如果某个“故事”的成本超过了3个开发周（这里的3是一个概数，可以根据实际情况进行调整），则最好请客户把该故事做进一步细分，重新赋予权值并计算成本，否则增量就过大，不利于风险控制。
建模阶段：建模阶段的设计应注重接口设计，而弱于内部的设计，因为可以随时重构（注：重构指改进设计的内部结构，但并未改变其外部功能）。
构建：在编码的初期，建议团队不是直接开始编码，而是开发一系列用于检测本次（软件增量）发布的包的单元测试。因为一旦建立了单元测试，开发者就能够集中精力于必须实现的内容以通过单元测试。对于测试应可以做到自动实施，易于执行并可重复。另外一个建议是如果有条件建议可以尝试结对编程（Pair Programming），有点类似于电影乘风破浪中的驾驶员沈腾和领航员尹正共同配合完成比赛。

软件工程pipeline中的最大挑战

在一个软件的生命周期中，目前我个人认为（需求）沟通是最具有挑战性的一个步骤。自己的现实体会可能需要不断的思考以下几点的答案：

（需求）沟通参与者不积极甚至有一定的抵触心理，如何处理。
（需求）沟通的核心关键要素有哪些。
（需求）沟通中有不一致的意见和看法，如何处理。
（需求）沟通的收尾应注意些什么。

针对第一点，需求沟通应该和利益相关者召开。通常一个项目组里面不同参与者的利益相关程度是不同的，如果发现沟通的对象，存在消极甚至抵触的心理，可能是没有找到合适利益相关者或者利益相关者沟通的顺序不对。例如某一C端需求，产品侧总监，C端产品经理，自己直属的算法leader是第一层利益相关者；后端开发同事、数据标定资源和运维同事是第二层利益相关者；同团队的技术伙伴和B端产品经理是第三层利益相关者。如果想从技术的角度推动某一特性的资源支持。最先沟通达成共识的应该是自己的直属技术leader，然后是产品经理，然后是产品总监。在第一层利益相关者达成共识（或知晓）情况下，再与第二层利益相关者进行沟通，否则直接与后者进行沟通，因为从某种层面来讲，第二层利益相关者属于具体支持类的同事，从公利层面，这些同事的工作内容没有被leader层面知晓，对其不合适；从私利的层面，支持类的同事需要配合做事情，但身为同级的自己直接去提需求，也不合适。B端产品经理、和自己同组的技术伙伴身为第三层级的参与者，对诸如涉及到该特性的需求沟通仅仅起到一定的建议作用，如果没有特别上心也应理解。
针对第二点，需求沟通至少应该要包含的四个要素：

谁是这项工作的最初请求者？
谁将使用该解决方案？
成功的解决方案将带来什么样的经济效益？
对于这个解决方案你还需要其他的资源吗？

一方面要逐步积累、建立自己的需求文档模板，另外一方面要注意的是，上述内容要自己思考收集出来，写出文档初稿和选项，让参与者付出尽可能小的思考和精力。
针对第三点，在日常情况中在一线的工作中遇到不同的意见（尤其是不同组）是极有可能遇到的。这是一个协商的过程，最好的协商是多赢的结果。有以下指导的原则：

认识到这不是竞争。为了成功，为了获得多赢，多方不得不妥协。（Make it才是最重要的）
制定战略。（协商前，要提醒自己保持理智。想好自己希望得到，设想对方希望得到什么，你将如何行动以使得这两方面的希望都能实现。）
主动地听。听，是为了获取信息，这些信息有助于在磋商中更好地说明你的立场。
关注对方的兴趣。如果想避开冲突，就不要太过于坚持自己的立场。
不要进行人身攻击。应集中于需要解决的问题。
要有创新性。当处于僵局时不要害怕而应考虑如何摆脱困境。

如果是需求会议，如果担心造成1v1的对立局面，可以纳入协调人。并且为了速战速决，需求会议尽量不要考虑（1）技术细节（2）极端case. 需求可以以开发用例的方式呈现
针对第四点，协商前，想好自己希望得到，设想对方希望得到什么，你将如何行动以使得这两方面的希望都能实现。随时准备做出承诺。一旦已经达成一致，不要闲聊胡扯，马上做出承诺。

rethink

成型公司流程应该来讲是相对较完善的，有的时候大家认为存在流程僵化现象，可能是因为身处其中不知为何，没有经历过流程形成的过程。创业公司的员工会不知流程为何物，同样他们面对的是另外一种迷茫。但无论身处何种环境，常常留心、用心思考。
需求沟通之后，软件工程pipeline中的第二大头可能是建模那一块中的设计，这部分感觉应该可以再单开几篇文章。总之，要有一个认知，在整个pipeline中，具体的构建（俗称码农的工作）无论是从时间还是从重要性来讲，其权重事实上都是一个较低的位置。
本文的内容虽然是针对软件工程领域而讲，但其内容适用于软件工程师和算法工程师。因为一方面从现实意义上来讲，一些外企（例如微软）是将算法应用相关的工作纳入软件工程师之说，统称为SD(Software Development)，当然researcher应该例外；另外一方面从概念上来讲，早在（至少）十几年前，《软件工程—实践者的研究方法》这本书中就提到：计算机软件被划分为7大类，人工智能软件本身就是之一。