马鞍山建设局网站,东莞科技网站建设,从化做网站开发,月嫂网站建设方案文章目录 软件工程pipeline梳理为什么需要梳理软件工程的pipeline软件工程pipeline的概念与注意点软件工程pipeline中的最大挑战rethink相关资料 软件工程pipeline梳理
为什么需要梳理软件工程的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大类人工智能软件本身就是之一。
相关资料
流程图drawio原始文件见https://upload.csdn.net/creation/uploadResources?spm1011.2124.3001.5646
