精华内容
下载资源
问答
  • 软件交付过程的思考与总结
    2022-03-10 21:05:14

    本文是在阅读《软件交付通识》一书的基础上,结合自己的工作实践整理出的读书工作笔记。可能对于初入行的读者并不友好,欢迎提出各种改进意见。

    《软件交付通识 》/ 董越著  电子工业出版社,2021.10

    软件项目开发的全过程是一个很大的范畴,从确定需求,到编码设计,到集成发布,到运维、运营、设计方方面面,而本文所要讨论的内容仅仅限于软件交付部分。

    首先,此处所讨论的软件交付过程(Software Delievery Process)指得是站在交付的角度和思维方式下去看待整个软件项目开发的全过程。也就是说主要指编码、集成、测试、发布四个过程中的后三个过程,但本文所指软件交付并不完全按照项目开发阶段时间划分,如果因为交付遇到问题而产生的编码工作也可以看做是本文所讨论的问题。

    软件项目追求

    软件开发生命周期所有相关活动大致分为两部分内容,需求分析和需求实现,核心目标是追求业务成功。

    需求分析对应着软件定义侧,主要目的在于制定正确的战略方向,抓住市场机会,最后落实到软件产品设计中。

    需求实现对应着软件的实现侧,目的在于软件需求的落地交付。主要包括架构设计、编程实现、软件交付、运维甚至运营等。

    MVP(Minimum Viable Product 最小可行性产品):满足定义侧和实现侧需求的小步快跑要实现的最小单位项目。

    小步快跑的重要性:从定义侧和实现侧协作的角度看,定义侧应该不断的定义小的需求,交给实现侧,然后实现侧尽快实现和交付这些小的需求。这就是小步快跑

    软件实现侧的追求

    多:更高的产能

    快:更快的响应速度

    好:适当的质量。这里所说的质量,是指用户能够感受到的软件服务质量,所以也包括稳定性、可靠性、安全性等。

    省:合理的成本

    软件交付过程追求的目标

    关键是快,快点达到业务所需质量实现交付。

    软件工程管理与实践探索

    软件危机与软件工程

            软件危机诞生于1970年左右,危机主要表现为面对越来越复杂的软件项目,开发进度难以预测,开发成本难以控制,质量无法保证等。

            软件工程是指软件的工程化,即把其他领域和行业的工程化经验借鉴过来,以系统性的、规范化的、可定量的工程化方法来维护和开发软件。

    软件工程思想

    软件工程思想有以下7条基本原则:

    1. 用分阶段的生命周期计划严格管理
    2. 坚持进行阶段评审
    3. 对产品需求变更实行严格的控制
    4. 采用现代程序设计技术
    5. 对中间成果应能清楚的进行审查
    6. 开发人员应该少而精
    7. 承认不断改进软件实践的必要性

    敏捷理念与实践

            今天,我们处在VUCA(vuca是volatility(易变性),uncertainty(不确定性),complexity(复杂性),ambiguity(模糊性)的缩写)时代。与传统工程追求资源效率的思维方式不同,VUCA时代往往更重要的是流动效率。因此软件工程的思想已经不能完全满足今天的时代需求,由此诞生了敏捷开发的思想。

    敏捷开发的价值观

    • 个体和互动高于流程和工具
    • 工作的软件高于详尽的文档
    • 客户合作高于合同谈判
    • 响应变化高于遵循计划

    敏捷开发的核心思路

    敏捷开发的核心思路就是“敏捷软件开发宣言”中遵循的12条原则

    • 我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意
    • 欣然面对需求变化,即使在开发后期也一样。为了客户的竞争优势,敏捷过程掌控变化。
    • 经常的交付可工作的软件,相隔几星期或者一个月,倾向于采取较短的周期。
    • 业务人员和开发人员必须相互合作,项目中的每一天都不例外。
    • 激发个体斗志,以他们为核心大家项目。提供所需的环境和支援,辅以信任,从而达成目标。
    • 不论团队内外,传递信息效果最好、效率最高的方式是面对面的交谈。
    • 可工作的软件是进度的首要度量标准。
    • 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
    • 坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强。
    • 以简洁为本,它是极力减少不必要工作量的艺术。
    • 最好的架构、需求和设计出自自组织团队。
    • 团队定期地反思如何提高成效,并依次调整自身的举止表现。

            总体来说,敏捷是在纠正软件工程过于强调工程化的倾向。当然,如果把敏捷片面的理解为不要流程、不写文档、不做计划,那就矫枉过正了。

    敏捷开发的最佳实践

    在管理实践中,接受度最高的是Scrum。

    工程实践中,接受度最高的是单元测试、持续集成。

    对于XP极限编程、测试驱动开发等并未被广泛采用。

    精益开发

            精益开发起源于丰田的精益制造思想,精益软件开发的核心逻辑是,要想尽办法尽快把产品方向选对,功能要真正能满足用户需求,防止跑偏造成浪费。为此,要把大的需求拆分成小的特性来试探,并且把小的特性在设计--开发--集成--发布这个过程中产生的各种浪费尽力消除,让这个过程尽可能快,让用户尽快看到这个特性,尽快用起来这个特性,加快用户反馈。“小步快跑”其实就在大体反映这个思想。

    持续集成/交付/部署

    做到持续集成的常见方法有版本控制、质量内建、自动化、过程可视化等。

    持续部署是持续交付的极端情况,试将持续交付做到了极致。

    DevOps

    概念:

    DevOps(Development和Operations的组合词)是一种重视“软件开发人员(Dev)”和“IT运维技术人员(Ops)”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程,来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

    目前DevOps还加入了QA和Security。

    DevOps的三大原则:

    • 基础设施即代码(Infrastructure as Code)
    • 持续交付(Continuous Delivery)
    • 协同工作(Culture of Collaboration)

    DevOps三步工作法:

    • 实现开发到运维的工作快速的从左向右流动。
    • 在从右向左的每个阶段中,应用持续、快速的工作反馈机制。
    • 建立具有创意和高可信度的企业文化。

    做好软件交付的10个策略

    做好软件交付的10个策略可以分为以下几部分来总结:

    • 首先是组织结构、系统架构、和交付流程的总体策略,包括
      • 细粒度、低耦合、可复用的架构
      • 小批量持续流动的流程
      • 运行综合手段保证质量和安全
    • 然后是针对具体事情如何做到方便、快捷,包括
      • 自动化与自助化
      • 加速各项活动
      • 及时修复
    • 接下来是一些保障补充性的内容,包括
      • 完备记录,充分展现
      • 标准化
      • 协调完成完整功能
    • 最后是如何改进
      • 基于量度的持续改进

    了解几个概念:

    测试左移:尽量写完代码就测试

    测试右移:跑到线上做测试

    康威定律:你把组织结构做成什么样,那么开发的软件系统架构就会长成什么样子。

    更多相关内容
  • 软件项目交付的模板资源
  • 项目经理手册,项目经理手册(软件交付)
  • 软件工程与计算II-20-软件交付

    20-软件交付

    1. 什么是软件交付

    1. 软件交付是软件项目的结束阶段,标志着软件开发任务的完成
    2. 软件交付是软件开发与软件维护两个既连续又不同的软件产品生存状态的分水岭。
    3. 只有做好软件交付工作,才是真正地完成整个项目。

    2. 安装与部署

    1. 需求阶段:考虑环境约束等
    2. 体系结构设计阶段:进行产品部署的设计决策,包括网络拓扑、库文件、动态链接库、配置文件等
      1. 32位环境还是64位环境等问题
    3. 开发阶段:使用的支持软件也会影响到交付,可能要求客户安装特定支撑软件或者硬件

    2.1. 安装

    1. 安装是软件交付的最常见形式,现在大多数产品都通过安装的形式交付,它要求开发团队创建一个安装包,用户可以通过的执行将软件产品部署到工作环境。
    2. 安装包需要进行仔细的设计,并使用工具(例如Advanced Installer 、Setup Factory 等)帮助进行安装包的创建。一个好软件产品应该简单、健壮、可靠、完全。要创建很容易使用的安装包,让用户可以无需创建安装包的人员的帮助就能使用。

    2.2. 创建安装包的步骤

    2.2.1. 确定安装环境

    1. 确定安装包需要支持的操作系统,这既需要考虑当前用户的工作环境,又需要考虑产品未来的市场规划;
    2. 确定软件产品的语言支撑环境,例如使用Java语言开发的软件产品就需要安装JDK;
    3. 确定软件产品需要的软件支持,例如数据库系统、网络系统等;
    4. 确定硬件等其他要求,例如有些软件产品可能会要求扫描仪、视频卡、通信设备等特殊硬件。
    5. 例如,对超市销售系统MSCS,它的安装环境为:Window XP、 Window Vista、Window 7三种操作系统;Java运行环境JDK;数据库管理系统软件(如果使用了数据库的话)。

    2.2.2. 列举安装清单

    1. 要根据软件产品的实现情况,结合所需的环境支撑,列举需要安装的文件、初始化数据、注册表等清单信息,要清楚标明它们在安装后将会出现的位置
    2. 在考虑安装位置时要遵守一致性,标记名称的使用要意义清楚,让用户能便利地找出相应文件。
    3. 例如,对超市销售系统MSCS,它所有的可执行程序文件都是需要安装的文件,初始化数据有两处,一处是设置默认的管理员用户帐号,另一处是设置数据库管理系统连接数据。

    2.2.3. 设计和建立安装包

    1. 要对安装包进行详细的设计,包括一个渐进的安装步骤,各步骤的人机交互方式等等。完成设计后就可以使用安装工具创建安装包。
    2. 例如,超市销售系统MSCS安装包可以按照下列步骤建立:
      1. 检查操作系统环境
      2. 检查JDK,如果没有合适的JDK,则提醒用户安装JDK
      3. 检查数据库管理系统软件,如果合适的数据库管理系统软件,则提醒用户进行安装
      4. 设置数据库管理系统连接参数
      5. 连接数据库管理系统,创建MSCS的数据库
      6. 拷贝文件
      7. 设置初始化数据,包括数据库系统连接参数和MSCS的默认管理帐号
      8. 安装成功。

    2.2.4. 测试安装包

    1. 安装包需要在目标环境中进行安装测试,以发现可能的问题。
    2. 需要注意的是:必须以用户的工作环境为目标环境进行测试,因为用户使用的机器环境与开发者的机器环境有很大的不同(包括程序环境、操作系统版本、支撑软件版本等等),在开发者机器上可以正确执行的安装包未必能够在用户的机器上运行。

    2.3. 部署

    1. 在软件产品比较复杂时,仅仅通过一个安装包无法完成软件交付任务,这时可以使用另一种常见的软件交付方式——部署。
    2. 部署通常是由开发人员直接操纵软件产品的目标环境,使得软件产品能够在目标环境中正常运行。
    3. 部署的过程中通常需要执行安装任务,但是还有很多比安装复杂得多的其他任务,例如:安装、设置或调整操作系统,尤其是权限管理参数;安装、设置和调整数据库系统,包括新建数据库和设置访问权限;安装和设置库文件、应用服务器等应用环境。

    2.4. 部署的步骤

    2.4.1. 确定部署环境

    1. 和安装一样,软件部署要首先要需要确定部署的目标环境,当然它比安装要求的更高一些。它需要对目标环境进行调查分析,搞清楚部署前的环境细节,然后才能与软件产品需要的环境细节进行比较,才能明确需要执行的部署任务。
    2. 具体来说,软件部署需要了解服务器与网络拓扑、安全控制与权限管理、软硬件系统的配置信息等。

    2.4.2. 确定部署任务

    1. 将软件产品需要的目标环境与部署前的环境进行比较,分析二者之间的差距,并将其确立为部署的任务。
    2. 确定任务之后,还需要以渐进的方式安排任务之间的执行次序。例如,先安装和配置操作系统,然后安装和配置相应的软硬件系统,最后完成软件产品的安装与配置,等等。

    2.4.3. 完成部署准备

    1. 有些部署工作可以完全依靠现场执行,但多数的部署任务需要进行一定的事前准备,尤其是要综合考虑部署工作可能出现的各种情况,制定完备的应对方案。

    2.4.4. 执行部署任务

    1. 按照准备的计划,执行相应的部署任务。

    3. 培训与文档支持

    1. 帮助用户理解产品,并使其能够轻松地使用产品
    2. 不能让用户学会使用软件产品,那么就不算是完成了软件交付任务
    3. 帮助用户学会使用软件产品的两个关键任务:
      1. 培训
      2. 文档支持

    3.1. 培训

    1. 培训主要是教会用户使用软件产品的功能来完成其工作和任务。依据任务的不同,要为不同的用户进行不同类型的培训。
    2. 例如,对超市销售系统MSCS
      1. 培训收银员使用系统进行销售和退货
      2. 培训客户经理使用系统进行库存管理和会员管理
      3. 培训总经理使用系统制定销售策略和进行库存分析
      4. 培训系统管理员进行用户管理。

    3.1.1. 培训的注意点

    1. 尤其不能忽略的是对系统管理员进行培训。要培训系统管理员如何启动和运行新系统、如何配置系统、如何授权或拒绝对系统的访问、如何支持用户、如何处理异常等。
    2. 在培训中,只介绍能够帮助用户完成主要工作和任务的功能,不要把培训当作软件产品所有功能的展示会。对于一些很少会被使用并且不太重要的功能,即使培训也会很快被用户忘记,可以让用户使用文档支持来学会使用。
    3. 培训时,要关注用户的工作和任务,不必涉及系统的内部操作,不必知道系统的存储方式、访问方式和权限控制方式。

    3.2. 文档支持

    1. 文档是软件交付的重要部分
      1. 培训时作为参考材料
      2. 交付完成之后继续帮助用户使用系统
    2. 用户文档
    3. 系统管理员文档
    4. 简单的系统只有用户文档,绝大多数系统都有用户文档和系统管理员文档

    3.2.1. 用户文档

    1. 用户文档是指为用户编写参考指南或者操作教程,常见的如用户使用手册、联机帮助文档等,统称为用户文档。

    3.2.2. 用户文档的形式

    1. 用户文档可以是纸质的,也可以是电子的,可以只有一份文档,也可以是由多份文档组成的集合,具体情况要视用户的特点而定。
    2. 用户文档的写作要考虑用户群体的特点,最好是图文结合的方式,以方便普通用户的使用。用户文档写作应该使用逐层展开和系统化(例如层次编码、列表)的方式描述复杂内容。

    3.2.3. 用户文档的内容组织

    1. 文档内容的组织应当支持其使用模式,常见的是指导模式和参考模式两种。
    2. 指导模式根据用户的任务组织程序规程,相关的软件任务组织在相同的章节或主题。指导模式要先描述简单的、共性的任务,然后再以其为基础组织更加复杂的任务描述。
    3. 参考模式按照方便随机访问独立信息单元的方式组织内容。例如,按字母顺序排列软件的命令或错误消息列表。
    4. 如果文档需要同时包含两种模式,就需要将其清楚地区分成不同的章节或主题,或者在同一个章节或主题内区分为不同的格式。

    3.2.4. 用户文档的要素

    表格描述参加课本339页

    1. 标识信息
      1. 包括文档标题、文档产生的版本和日期、相关的软件 产品和版本
      2. 标识信息应该放在包装袋或者封面,用户可以不用翻阅文档就能看到
    2. 引言
      1. 正文的第一部分,描述文档的预期读者、描述范围,以及对文档目的、功能和操作环境的概要描述
    3. 文档使用信息
      1. 文档使用信息描述了关于文档的使用信息,例如,解释各种图示的含义、介绍如何使用帮助等。
    4. 操作模式
      1. 操作模式是使用用户文档的模式,例如对操作流程的图示或者文字性描述,再例如解释操作的理论、原因、算法或者通用概念。
    5. 操作规程
      1. 指导模式文档应该包括很多软件功能都会涉及的常见活动规程:
        1. 需要由用户执行的软件安装与卸载
        2. 图形用户界面特性的使用指导
        3. 访问、登录或者关闭软件
        4. 通过软件的导航,访问和退出相关功能
        5. 数据操作(输入、保存、读取、打印、更新和删除)
        6. 取消、中断和重启操作的方法
      2. 对于完成用户任务的操作流程,指导模式文档应该从基本信息、指导步骤和结束信息三个方面来描述
      3. 基本信息:
        1. 简要概述操作规程的目的,定义或解释必要的概念
        2. 标明执行任务前需要完成的技术活动
        3. 列举用户完成任务所需要的资源情况,例如数据、文档、密码等
      4. 对于完成用户任务的操作流程,指导模式文档应该从基本信息、指导步骤和结束信息三个方面来描述
      5. 指导步骤:使用祈使语句描述用户行为,并指出预期的结果。指导步骤要说明:
        1. 用户输入数据的域值范围、最大长度和格式
        2. 相应的错误消息和恢复办法
        3. 其它可选的步骤和重复步骤
      6. 对于完成用户任务的操作流程,指导模式文档应该从基本信息、指导步骤和结束信息三个方面来描述
      7. 结束信息:标明操作规程的最后步骤,让用户知道怎样判断整个操作规程的成功完成,告诉用户如何退出操作规程
    6. 软件命令信息
      1. 解释用户输入命令的格式和操作规程,包括必要参数、可选参数、缺省值等,要示例说明命令的使用,说明怎样判断命令是成功完成还是异常中止
    7. 错误信息与问题解决
      1. 文档要详细描述软件使用中的已知问题,让用户清楚如何自行解决问题或者怎样向技术支持人员报告准确的信息
    8. 导航特征
      1. 包括章节、主题、页码、链接、图标等
      2. 提高导航特征和效率

    3.2.5. 系统管理员文档

    1. 与用户文档注重系统使用细节不同,系统管理员文档更注重系统维护方面的内容,例如系统性能调整、访问权限控制、常见故障解决等等。因此,系统管理员文档需要详细介绍软硬件的配置方式、网络连接方式、安全验证与访问授权方法、备份与容灾方法、部件替换方法等等。

    4. 项目评价

    1. 开发者自我反省

    4.1. 为什么要进行项目评价

    1. 设置"项目"是要保证项目中的各种事件与活动能够依照计划顺利进行,项目评价就是检查其事件与活动的实际执行情况。在理论上,项目评价可以发生在项目进行的任何时机,尤其是到达各个里程碑之后。但最重要的项目评价是在项目结束时进行的项目评价,这也是本章节所要描的项目评价。
    2. 虽然从单个项目看,项目已经结束,评价似乎用处不大。但是考虑到一个组织会有很多项目持续进行,那么评价一个已结束项目就可以"以史为鉴",帮助更好地完成后续项目。而且因为项目已经完成,总结和评价就远比项目进行中更加准确。
    3. 项目评价工作也需要仔细组织,不是简单的开个总结会完事,否则就无法获得比较深入的信息。

    4.2. 项目评价的内容

    1. 一个已结束的项目具有各种事件和活动的信息,通过组织对项目的不同方面内容进行评价,就可以获得各种不同方面的经验,就可以搞清楚出现了哪些问题、为什么会出现、怎样解决、有哪些偏差、最终结果与质量、以及(最重要的是)在下个项目中有哪些需要提高。
    2. 常见的项目评价针对四个方面:
      1. 项目管理:可以帮助建立对项目的更准确认知,例如常见的管理问题与偏差、时间与成本耗费分布等。
      2. 产品:可以帮助开发者建立对产品的更准确认知,提高产品的开发经验。
      3. 团队:可以帮助开发者更好地组织分工,也可以帮助团队建立更好的沟通与交流途径。
      4. 个人:可以帮助开发者更准确认知自己的生产力,学习常见问题及其处理方法,了解自己的长处和不足并持续提高。

    4.3. 项目评价方法

    1. 评审
    2. 度量数据分析

    4.3.1. 项目评审

    1. 项目评审通过评审重要项目制品的方法来评价项目,这些重要制品包括项目计划、管理文档、会议记录、历史数据等。
    2. 成功的评审需要评审方法,而不是自由处理。检查列表是最为常用的评审方法。
    3. checkList如下

    4.3.2. 有关项目管理的问题:

    1. 项目所使用的过程是什么?瀑布/迭代开发
    2. 实际的过程与原先确定的过程有什么不同?
    3. 进度表是如何随着时间的变化而改变的?
    4. 有多少个同步点和里程碑按时达到或错失?
    5. 过程的哪些部分运行得好?
    6. 过程的哪些部分本应该能运行得更好?
    7. 工具支持这个过程吗?
    8. 从整体上讲,这个过程运行得有效吗?
    9. 在今后,尤其要对哪些方面进行改进?
    10. 在每个阶段和每项任务上花费的时间是多少?

    4.3.3. 有关产品的问题:

    1. 在项目的生命周期中,产品是如何变化的?
    2. 有没有出现重要的产品返工的情况?如果有,是在什么时候?
    3. 工具支持产品的制造、维护和测量吗?
    4. 产品最后的规模有多大?产品的质量如何?

    4.3.4. 有关团队和个人的问题:

    1. 团队(个人)工作中哪些个风险发生了,其影响又是怎样的?
    2. 在何时做出了哪项重要决定?
    3. 所遇到的主要问题是什么?
    4. 这个决定又是如何影响这个项目的?
    5. 对这些问题的解决方法产生了什么样的效果?
    6. 开发团队成员是如何看待自己的职责的?

    4.4. 度量数据分析

    1. 度量数据可以提供丰富的信息,通过分析这些信息,开发团队可以获取正确和深入的结论。
    2. 例如,通过分析项目活动的任务量,就可以了解每个人的生产力、项目的工作量分布、特殊任务的工作量耗费等。

    4.4.1. 产品信息定量的度量

    1. 一个项目常见的产品信息度量应该包括:
      1. (随着时间而变化的)产品的增长情况和变化历史。
      2. 产品在每个里程碑上的测量。
      3. 产品复杂度和内容的测量。
      4. 过程和工具对产品的影响。

    4.4.2. 定性文件

    1. 在进行度量数据分析时可能会遇到数据贫乏——这意味着没有足够的定量数据来支持项目评价,这时可以用问卷调查表和面谈来补充数据信息。也可以通过检查定性文件来建立数据信息,这些定性文件可能包括:
      1. 对团队会议和子团队会议所做的记录。
      2. 项目电子邮件的存档(来获得问题确定和决策的日期)。
      3. 任务列表、项目决策和行动条目中的信息。

    4.5. 评价的注意事项

    4.5.1. 项目的评价需要仔细的计划

    1. 作为项目管理活动的一部分,项目评价也需要进行计划,计划的内容包括:
      1. 执行项目评价的时间,要在项目结束后,并且不能时间太久导致项目活动细节遗忘
      2. 确定项目评价的关键主题
      3. 确定参与项目评价的人员
      4. 确定需要收集的数据,并将数据收集任务分配给相关人员。

    4.5.2. 评价要客观

    1. 对项目的评价要客观,要保持对项目和过程的关注,不要偏离目标指责和突出个人。如果不能做到客观,列举没有进行分析的测量数据或信息,而仅仅为了表明整个项目是一个巨大成功的话,那就无法得到有益的经验,就是浪费时间。评价不是向高级管理层夸夸其谈的文档,而是团队每个成员和组织通过一个又一个项目来不断获得提高的途径。

    5. 总结

    1. 不要忽视软件交付阶段的任务
      1. 通过安装与部署将软件产品移交给用户
      2. 通过培训与文档支持保障用户能够有效掌握和使用软件
    2. 一个项目的成功或失败都值得总结,以改进将来的项目,即要在项目结束后及时进行项目评价
    展开全文
  • 研发效能嘉年华如何做到高效软件交付PPT
  • 软件项目交付与验收计划
  • 多团队软件交付评估 多团队软件交付评估是一种简单,易于执行的方法,用于评估组织内许多不同团队之间的软件交付。 它是由的的,它被用作的的关键部分,但任何人都可以自由使用(必须遵守以下CC BY-SA许可)。 该...
  • 软件交付方式有哪些Maybe it started out well — but over time it grew stale. Or it was wrong from the very beginning. Despite the common belief that software is an asset — it’s just as easily a ...

    软件交付方式有哪些

    Maybe it started out well — but over time it grew stale. Or it was wrong from the very beginning. Despite the common belief that software is an asset — it’s just as easily a liability.

    中号 aybe它开始了良好-但随着时间的推移变得陈旧。 还是从一开始就错了。 尽管人们普遍认为软件是一种资产,但它也很容易成为负债。

    Let’s start with how do you define “Meaningful” software? Developers know when something they are working on doesn’t matter. Sometimes the indicator is a lack of interest in investing further or it’s heavy investment in something that gets little usage. Either way meaningful software must be a win-win for both creator and consumer.

    让我们从如何定义“有意义的”软件开始? 开发人员知道什么时候他们正在做的事情都没有关系。 有时,指标是缺乏对进一步投资的兴趣,或者是对很少使用的东西的大量投资。 无论哪种方式,有意义的软件都必须对创作者和消费者都是双赢的。

    “Meaningful software delivers value to a substantial segment of the target user group and directly supports the goals and objectives of those delivering the software. “

    “有意义的软件为目标用户群的大部分用户带来了价值,并直接支持那些交付软件的人的目标。

    I’ll argue that any software feature or platform that fulfills this criteria will produce positive results. I’ll also suggest that it can be challenging to achieve and maintain this balance.

    我将争辩说,任何满足此标准的软件功能或平台都将产生积极的结果。 我还将建议实现并保持这种平衡可能是一个挑战。

    Example 1: “Hey — we should build our own shopping cart system”

    示例1: “嘿,我们应该构建自己的购物车系统”

    If you are competing against Amazon in the high volume retail market and need proprietary AI recommendation systems — then it’s a worthy investment. If you are selling flowers at the corner market, probably not. It sounds simple on the surface but the question you always need to ask is: will it give me a competitive advantage and help me directly achieve my goals?

    如果您在大量零售市场上与亚马逊竞争,并且需要专有的AI推荐系统,那么这是值得的投资。 如果您在街市上卖花,可能不会。 从表面上看这听起来很简单,但是您始终需要问的问题是:它会给我带来竞争优势并帮助我直接实现目标吗?

    Example 2: “Hey, power user X says they would love this feature”

    示例2: “嘿,高级用户X说他们会喜欢此功能”

    Power users and early adopters are extremely valuable. But it’s important that you obtain and test feedback against a larger market. Investing in a feature that is utilized by a few users doesn’t contribute to growth. Will it deliver value to a large portion of my target users?

    高级用户和早期采用者极为宝贵。 但是,重要的是要获得和测试针对较大市场的反馈。 投资一些用户使用的功能不会促进增长。 它将为我的大部分目标用户带来价值吗?

    为什么这很重要? (Why is this important?)

    Software that isn’t meaningful isn’t sustainable.If it doesn’t meet the objectives of its creators, they should be building something else. If it doesn’t deliver value to a substantial number of target users then they don’t really need it or should be using something else. When one or both of these conditions have not been met it creates an imbalance that generally results in a slow painful death for the platform.

    没有意义的软件是不可持续的 。如果它不满足创建者的目标,他们应该在开发其他东西。 如果它不能为大量目标用户带来价值,那么他们就不真正需要它,或者应该使用其他东西。 当这些条件中的一个或两个都不满足时,会造成不平衡,通常会导致平台缓慢而痛苦的死亡。

    Software that isn’t meaningful creates unnecessary costs for its creator. This takes many forms — time, opportunity, and financial cost. The long term impact of holding meaningless software with active users is dangerous because its toxic byproducts are usually hidden in the depths of technical teams. If your are interested in learning more about the costs associated with building features, this is a great article that highlights the risks.

    没有意义的软件为其创建者带来了不必要的成本。 这有多种形式-时间,机会和财务成本。 拥有活跃用户的无意义软件的长期影响是危险的,因为其有毒副产品通常隐藏在技术团队的深处。 如果您有兴趣了解有关与建筑物功能相关的成本的更多信息,那么这篇很棒的文章强调了风险。

    Software that isn’t meaningful disrupts focus on key objectives. It creates confusion, takes over meetings, hurts morale, and ultimately can derail strategic direction. The real danger of meaningless software is it appears to be “low hanging fruit” and usually brings a level of comfort that attracts all sorts of “feature requests” and “ideas”. If the creators lose sight of its intended purpose then the strategic objective quickly shifts from whatever it was originally to the ambiguous effort of making the software “better”.

    没有意义的软件破坏了对关键目标的关注。 它造成混乱,接管会议,损害士气,并最终使战略方向脱轨。 无意义软件的真正危险在于它看起来像是“垂头丧气的果实”,通常带来一定程度的舒适感,吸引着各种各样的“功能要求”和“想法”。 如果创建者没有意识到其预期目的,那么战略目标就会从最初的目标Swift转变为使软件“更好”的模棱两可的工作。

    Mastering the ability to distinguish meaningful from meaningless requires discipline. You have to be honest with yourself and objective about what it is you are producing. You cannot fall in love with your creation. You have to be willing to refactor design, listen to concerns, take time to organize, reject tradition, kill exciting (but distracting) ideas, and ignore the urge to “make things” right without purpose. It requires focus and it requires constant re-evaluation. It’s uncomfortable — but once you know you are building something that matters — it all clicks.

    掌握区分有意义和无意义的能力需要纪律。 您必须对自己诚实,并客观地了解所生产的产品。 您无法爱上您的创作。 您必须愿意重构设计,倾听顾虑,花时间组织,拒绝传统,扼杀令人振奋(但分散注意力)的想法,并忽略无目的“正确地制造事物”的冲动。 它需要重点,并且需要不断的重新评估。 这很不舒服-但一旦您知道自己正在构建重要的东西-一切都会点击。

    Shaping software into something meaningful requires thinking holistically. Understanding the goals of stakeholders, needs of target users, cost of building, validation techniques, and methods of promotion are just as important as the mechanics of how the software functions. Alignment and positioning of effort is key to the “meaningful” attribute of the art.

    将软件改造成有意义的东西需要整体思考。 理解利益相关者的目标,目标用户的需求,构建成本,验证技术和升级方法与软件功能机制一样重要。 努力的统一和定位是艺术“有意义”属性的关键。

    Producing meaningful software requires a fundamental understanding of how software is created, tested, and distributed. It’s also not enough to make plans and collaborate with stakeholders — it’s very important to understand capabilities, risks, and mechanics of how software is made and maintained. You don’t have to be a developer to deliver meaningful software, but you do need to know how to communicate with one. Mastering this is how the “delivery” happens.

    生产有意义的软件需要对软件的创建,测试和分发方式有基本的了解。 制定计划并与利益相关者进行协作还远远不够,了解软件的制造和维护能力,风险和机制非常重要。 您不必成为开发人员即可交付有意义的软件,但是您确实需要知道如何与之通信。 掌握了这就是“交付”的过程。

    The end product speaks for itself. If you can’t deliver it or what is shipped doesn’t provide direct value then start over or re-work. Much like an artist would paint over the canvas or toss it away — there is no value (only risk) in maintaining meaningless software. Attachment to sunk cost, “technology” hording, and pet projects are guaranteed ways to fail or prolong the achievement of goals.

    最终产品不言而喻。 如果您无法交付它,或者所运送的物品不提供直接价值,那么请重新开始或进行返工。 就像画家在画布上绘画或扔掉画布一样,维护毫无意义的软件没有任何价值(只有风险)。 对沉没成本,“技术”束缚和宠物项目的依恋是保证失败或延长目标实现的方法。

    If you want to improve your ability to contribute to and drive the delivery of meaningful software I’d encourage you to follow along on this journey — sign up for my weekly newsletter.

    如果您想提高自己的能力,以推动并推动有意义的软件的交付,我鼓励您跟随这一旅程— 注册我的每周时事通讯

    Originally published at https://7samurai.dev.

    最初发布在 https://7samurai.dev

    翻译自: https://productcoalition.com/how-to-deliver-meaningful-software-5eb0abb6d389

    软件交付方式有哪些

    展开全文
  • 工程效能之软件交付

    2020-08-04 08:21:00
    1.问题1、软件开发最终的交付产物是什么?2、代码是如何构建成二进制软件执行包的?3、软件执行包是如何部署的?4、如何搭建一条高效稳定的构建部署流水线?5、如何衡量构建部署的效率?6、不...

    1.问题

    • 1、软件开发最终的交付产物是什么?

    • 2、代码是如何构建成二进制软件执行包的?

    • 3、软件执行包是如何部署的?

    • 4、如何搭建一条高效稳定的构建部署流水线?

    • 5、如何衡量构建部署的效率?

    • 6、不同开发模式的构建部署方式有何差别?

    • 7、构建部署发挥着怎样的作用?

    2.关键词

    编译,打包,部署,仓库搭建,二方/三方库,部署记录,docker ,k8s,开发模式,CI/CD,DevOps,GitOps

    3.全文概要

    在整个工程生命周期中,我们经历了需求分析,业务建模,架构设计,组件设计后,终于把设计稿变成了一行行代码,接下来的就是怎么把代码变成我们想要的软件系统。我们知道计算机是无法识别我们的文本代码的,也就是其实在这个时候我们交付的也只是中间产物,那么就需要把我们文本代码编译成计算机认识的机器码,然后执行才能生成我们要的交付软件,也即是本章我们要介绍的构建部署环节。构建部署才是直接输出软件交付产物的环节,那么如何才能搭建出稳定高效的软件构建部署平台,才是我们所要关心的。

    4.开发模式

    不同开发模式决定不同的构建部署方式。首先我们先来回顾一下史前的开发模式,不同的开发模式决定不同的构建部署方式,传统开发模式有:瀑布开发、迭代开发、螺旋开发、敏捷开发。我们先简单对比下这四种开发模式的区别:

    • 瀑布开发,要求各个阶段都需要完成规范标准,从需求到设计,编码,测试,部署都要完成统一的流程

    • 迭代开发,不要求每一个阶段都最完美的,注重的是把主要功能先部署起来,以最少的时间成本先完成一个半成品然后再逐步优化

    • 螺旋开发,循环地增加系统定义和实现的复杂度而降低风险,主要在风险控制,因此需要在部署上有高的稳定性要求

    • 敏捷开发,敏捷开发要求在短时间内协同好团队成员,形成良好协作基础,构建部署上更加高频

    一开始简单的软件系统,我们可能是一次性编码完成后就直接本地编译成二进制软件包,但是随着软件复杂度的提升和业务变更的频度提升,传统的开发模式已经渐渐退出历史舞台了,取而代之的是新兴的开发模式:CI/CD,DevOps,GitOps等开发模式。

    5.软件构建

    5.1构建定义

    在软件开发中,构建是将源代码文件转换为可以在计算机上运行独立软件的过程,并且产出二进制文件或者可执行文件。

    5.2构建过程

    构建阶段

    构建分为几个阶段:

    • 从代码库获取源代码文件

    • 编译代码并检查依赖项

    • 运行自动化的单元测试

    • 相应的链接库,文件,代码等

    • 成功加载以上文件后,便会构建和存储

    • 输出构建日志

    • 完成构建通知

    构建类型

    软件构建通常第一次开始是全新代码的构建,然后后续持续开发部署会进行迭代式构建,所以也分为全量构建和增量构建

    • 全量构建

    全量构建是从头开始执行构建过程,它将建服务器未执行过所需的资源以整体作为输入,检查依赖关系,编译所有源文件并按顺序构建所有模块,最后将其组装到构建目标软件包中。

    • 增量构建

    增量构建复用已编译好的模块,检查并比较源文件,以及所有与目标文件有关的文件。如果在上次构建之后修改了任何依赖项,则将再次重建,否则,将重新使用上次构建的文件。

    增量构建比全量构建更快,并且使用很少的资源,有多种触发构建的方法:

    • 手动构建触发器

    • 计划构建触发器

    • 源代码库构建触发器

    • 后处理构建触发器

    5.1构建工具

    构建计算机程序的过程通常由构建工具进行管理,生成应用程序通常需要以正确的顺序编译各种文件,如果特定文件中的源代码未更改,则无需重新编译。不同的技术栈有不同的构建工具,这里笼统的列举一些常用的构建工具:

    • Make

    • Ant

    • Maven

    • Gradle

    • Meister

    • Rake

    • SCons

    • Grunt

    • Phing

    6.软件部署

    6.1部署定义

    软件部署是使软件系统启动运行的过程。

    6.2部署原则

    • 发布(或撤销发布)应该可靠且尽可能简单

    • 发布(或撤销发布)应该完全可追溯所有的变更日志

    • 只有授权人员才能参与部署

    • 在大多数组织中,开发人员和部署该版本的团队之间需要区分职责

    • 任何未经授权的线上变更都应立即发现告警

    • 具备完善的程序来检查生产中变更版本及变更部署包

    • 部署流程应需要增加审批环节

    6.3部署流程

    • 部署清单

    随着互联网的盛行,业务不断复杂化,部署软件也是一项复杂的任务。所以部署需要一份部署清单来指导整个部署流程,部署清单会表明在部署之前要完成的关键任务。

    • 部署工具

    借助适当的工具实现部署自动化,可以把控好软件部署的关键环节。比如下文我们要介绍DevOps或者CI/CD等部署模式都是需要应用到一系列不同的工具来实现高效的部署。

    • 部署模式

    目前比较流行的部署模式是CI/CD,CI获取源代码并将其打包到应用程序构件中,持续集成还采用了持续测试的原则,即团队不断收集反馈以尽快发现问题。

    • 交付模式

    集成代码并构建应用程序后,CD涉及打包和准备要部署的代码。应用程序被置于预发环境中,在交付阶段会进行严格的测试,以确保应用程序一旦部署便能正常工作,持续交付的目标是使应用程序始终准备好进行部署。

    • 自动部署

    部署是一个复杂的过程,手工完成部署会留出太多人为错误的空间,部署自动化减少了失误操作而且加快了部署速度,并使流程变得如此简单,部署自动化的最简单形式是使用脚本在特定上下文中在特定环境中部署特定操作,要获得更高级的自动化,则可以使用部署工具来完成。

    • 指标监控

    部署新版本的软件后,需要密切注意关键指标。常见的指标包括服务器利用率,异常率,日志量和数据库性能。如果存在性能问题,则需要了解问题的根源。诸如Retrace之类的APM工具可让监控指标并跟踪部署,以便在出现问题快速排查问题的根源。

    • 回滚策略

    并不是每一次部署都是成功的,即使有了周密的测试也总会发布异常的情况出现。这个时候快速止血采用回滚方式可能是需要优先考虑的。诸如Automic之类的发行自动化工具支持回滚,可以保留最新版本的备份副本或者上一次正常的代码分支,直到确认新版本可以正常工作为止。

    6.3部署工具

    不同技术栈使用不同的部署工具,之类就不一一列举。

    • 0penstack

    • Jenkins

    • Kubernetes

    7.交付方式

    随着DevOps的兴起,出现了持续集成,持续交付(CI / CD)和持续部署的新方法。传统的软件开发和交付方法正在迅速过时。从历史上看,在敏捷时代,大多数公司都会以每月,每季度,每半年甚至每年的版本来部署发行软件。但是,现在,在DevOps时代,每周,每天甚至一天多次都是标准。下面我们简单介绍下这集中不同的交付方式。

    7.1敏捷交付

    上文我们也提过敏捷开发流程,对应的敏捷交付就是在这种开发模式下完成软件交付。敏捷交付专注于消除传统冗长的流程障碍,并且让加速交付方面进行更紧密的协作,其基本原则是迅速生产可运行的软件,与客户紧密协作以及应对新的需求变更。

    7.2持续集成

    传统软件交付会安排在一天内将所有分支源代码合并在一起完成部署,最终可能造成工作繁琐、耗时,而且需要手动完成。持续集成(CI)可以帮助开发人员更加频繁地将代码更改合并到共享分支或“主干”中。一旦开发人员对应用所做的更改被合并,系统就会通过自动构建应用并运行自动化测试来验证这些变更,确保这些变更没有对生产环境造成破坏或者污染。这意味着测试内容涵盖了从类和函数到构成整个应用的不同模块。如果自动化测试发现新代码和现有代码之间存在冲突,CI可以更加轻松地快速修复这些错误。持续集成(CI)是一种软件工程实践,其中团队成员以越来越高的频率集成他们的工作。为了与CI保持一致,团队努力至少每天甚至每小时进行集成,以接近“持续”进行的集成。

    7.3持续交付

    让软件产品的产出过程在一个短周期内完成,以保证软件可以稳定、持续的保持在随时可以释出的状况。它的目标在于让软件的建置、测试与释出变得更快以及更频繁。这种方式可以减少软件开发的成本与时间,减少风险。持续交付的目标是拥有一个可随时部署到生产环境的代码库。在持续交付中,每个阶段都涉及测试自动化和代码发布自动化。

    持续交付与DevOps的含义很相似,所以经常被混淆。但是它们是不同的两个概念。DevOps的范围更广,它以文化变迁为中心,特别是软件交付过程所涉及的多个团队之间的合作(开发、运维、QA、管理部门等),并且将软件交付的过程自动化。另一方面,持续交付是一种自动化交付的手段,关注点在于将不同的过程集中起来,并且更快、更频繁地执行这些过程。因此,DevOps可以是持续交付的一个产物,持续交付直接汇入DevOps。

    7.4持续部署

    指在软件开发流程中,以自动化方式,频繁而且持续性的,将软件部署到生产环境(production environment)中,使软件产品能够快速的发展。持续布署可以被整合到持续整合与持续交付的流程之中。对于一个成熟的 CI/CD 发布流水线来说,最后的阶段是持续部署。持续部署可以自动将应用发布到生产环境。

    有时候,持续交付也与持续部署混淆。持续部署意味着所有的变更都会被自动部署到生产环境中。持续交付意味着所有的变更都可以被部署到生产环境中,但是出于业务考虑,可以选择不部署。如果要实施持续部署,必须先实施持续交付。

    7.5DevOps

    DevOps(Development和Operations的组合词)是一种重视“软件开发人员(Dev)”和“IT运维技术人员(Ops)”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程,来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。DevOps 集文化理念、实践和工具于一身,可以提高组织高速交付应用程序和服务的能力,与使用传统软件开发和基础设施管理流程相比,能够帮助组织更快地发展和改进产品。这种速度使组织能够更好地服务其客户,并在市场上更高效地参与竞争。

    7.6GitOps

    GitOps是一种声明式和云原生方法,用于利用版本控制的代码管理作为配置管理和基础结构。随着越来越多的公司转向基于云的复杂微服务软件体系结构,使用版本控制管理基础架构变得越来越重要。GitOps流程通常与容器化Kubernetes部署一起使用,因为该平台可以将声明性输入作为要争取的所需基础结构状态。通过使用Git,IT团队可以更轻松地处理配置管理和部署,因为GitOps使部署工作流程更接近开发人员。GitOps的主要好处是,通过具有集中的代码和配置,开发人员可以轻松地进行新更改或快速还原到以前的版本。

    8.平台建设

    8.1基础设施

    技术设置是应用的硬件设备,随着云原生的推广,基础设置的云化也是大势所趋,所以目前主要是云上资源的管理,这块众多云平台厂商也提供了服务器管理平台,那么基础设施层面需要聚焦的有如下几点:

    • 机器申请

    • 机器下线

    • 应用扩容

    • 网络变更

    • 域名管理

    • 安全外联

    8.2代码服务

    代码服务可以参考我们之前《代码治理》这一章,有代码全域详细的介绍。而在devops的场景下,代码服务则是提供稳定的代码服务器,这里我们首选gitlab作为我们代码的管理平台。

    8.3配置管理

    维护硬件和软件的最新记录的过程称为配置管理。目前比较主流的是使用诸如Chef,Puppet或Ansible之类的CM工具来进行辅助。

    8.4测试服务

    为了构建高质量的软件,必须在整个交付流程中不断运行自动测试和手动测试。自动测试包括以下各项:

    • 单元测试:此类测试通常是单独测试一个方法、类或函数,让开发者确信自己的代码在按预期运行。为确保代码可以测试且测试易于维护,在编写代码之前先编写测试,这种方法也称为测试驱动开发 (TDD)。

    • 验收测试:此类测试通常是测试整个应用,以确保更高层次的功能按预期运行,并且未引入回归错误。例如,验收测试可以针对某个用户案例检查业务上可接受的标准、某个 API 的正确性,以及原来运行正常的功能是否出错。此类测试的编写应该作为开发过程的一部分。除非已通过自动验收测试,否则任何人都不能达到代码开发完毕的标准。

    8.5构建部署

    DevOps团队将涉及服务生命周期的所有方面,从需求到规划,部署和维护。

    构建部署整体流程如下:

    • 提交给源代码管理系统的代码提交将触发构建服务器上的进程

    • 此过程编译代码,将所需依赖包整合到可部署的程序包中

    • 然后对这些软件包执行自动测试,以确保代码质量符合规范且执行结果没有问题

    • 如果提交阶段成功,则将应用程序部署到测试环境,由质量保证团队对其测试

    • 最后批准了该应用程序,则可以将该版本直接用于生产

    8.6监控服务

    监控告警服务可以参考下一章《监控告警》,梳理了全域的监控告警体系化构建流程。

    9.总结

    最后我们用一张图来概括构建部署的核心流程。

    关注公众号《编程原理》,升级你的编程知识体系

    展开全文
  • 软件类系统项目交付实施方案--优秀模板
  • PypeFitter是一个基于python的软件交付管道生成器。 目标是允许将抽象的软件交付管道转换为Jenkins或AWS之类的提供商的具体的可执行实现。 我为雇主提供了这种方法的原始实现,但是这种方法虽然可维护的POC相对...
  • 互联网圈的小伙伴们都知道,“SaaS”一词在云市场以及互联网媒体平台频繁的出现,我们只知道“SaaS”是Software-as-a-Service(软件即服务)的简称,是一种软件布局模型,其应用专为网络交付而设计,便于用户通过...
  • 衡量软件交付性能的4个指标

    千次阅读 2021-05-11 15:17:27
    软件交付性能指标 部署频率 变更准备时间 变更失败率 平均恢复时间(MTTR) 总结 当你的团队需要通过持续集成和持续交付(CI/CD)流水线将代码部署到生产环境时,衡量这些应用程序交付的速度和稳定性对于...
  • 软件交付的特点与分析

    千次阅读 2020-01-03 20:54:56
    软件交付领域,分角色的精细分工是不利于整体交付效率的,那为什么在DevOps倡导下的全栈工程师、开发运维一体化又会产生新的问题呢?如何解决这些新问题呢? 也许,我们需要认真思考,在整个软件交付过程中,什么...
  • 软件项目交付清单-模板.rar 软件项目交付清单-模板.rar 软件项目交付清单-模板.rar
  • Devtron是一个用go编写的kubernetes开源软件交付工作流程。 ·· · :open_book: 菜单 :light_bulb: 为什么选择Devtron? 它被设计为自助平台,以对开发人员友好的方式在kubernetes上操作和维护应用程序(AppOps...
  • 交付团队管理 开始于:为什么需要构建软件? (Begin With: Why Do You Need To Build Software?) There are a many reasons why an organization needs to build and deliver software. Some examples might be: ...
  • 推动软件交付的24个关键能力

    千次阅读 2020-09-21 07:59:42
    这篇文章摘自Nicole Forsgren博士,Jez Humble和Gene Kim 的Accelereate摘录 。持续交付能力1.对所有生产工件使用版本控制版本控制是将所有生产工件...
  • 软件交付的主要工作是将程序代码和相关文档交给用户 B 用户培训是帮助用户理解产品并掌握系统的使用和操作 C 软件部署是通过配置、安装和激活等活动保证软件系统的正常运行 D 持续集成是频繁持续地将...
  • ibmjazz软件交付平台.pdf
  • 软件交付的演进历程

    千次阅读 2019-08-29 14:58:17
    软件开发刚开始的时候,并没有很好的经验或思想来指导一个开发项目的运行。最开始,人们标识出软件开发的一些关键假设,映射到那时已有的可理解的流程上。 最初的假设如下: 软件开发需要很长的时间 软件...
  • Editor's Notes:如何提高软件交付效能?研发支撑部门 BP 化,项目管理流程精简化,忘掉代码量去构建效能度量模型。一个个富有冲击力的理论不断涌现,细一琢磨,又...
  • 软件交付概述

    千次阅读 2019-04-03 22:54:41
            经过软件设计和软件开发两个阶段之后,基本上大部分工作都已经...软件交付,一方面,开发方会根据项目前期的软件设计展现开发成果,另一方面,客户方也要对开发成...
  • 流动式软件交付方案.pdf
  • [Addison-Wesley Professional] 企业软件交付 敏捷与高效管理精要 (英文版) [Addison-Wesley Professional] Enterprise Software Delivery Bringing Agility and Efficiency to the Global Software Supply Chain ...
  • 使用DNN的勒索软件交付检测 基于Joseph Zadeh和Rod Soto的作品-Aktaion 建筑与工作 使用者介面
  • 用户对交付软件会经常性的提出修改意见和新的需求。 维护困难。 交付困难。 [试题解析] A.用户不参与开发过程 是造成弊端的原因。 [参考答案] 用户对交付软件会经常性的提出修改意见和新的需求。 3.软件的几种...
  • 软件项目全流程文档请查看本人其他资源,概要设计、详细设计、测试计划等等
  • 软件交付性能的四个关键指标

    千次阅读 2019-04-06 19:12:32
    软件交付性能的四个关键指标(FOUR KEY METRICS): 前置时间,部署频率,平均恢复时间(MTTR), 变更失败百分比
  • IBM资深开发经理告诉你如何用敏捷开发技术与敏捷项目管理方法来开发软件,仔细领会后你将掌握如何超越技术、流程、需求管理复杂性的屠龙大技。

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 167,170
精华内容 66,868
关键字:

软件交付