精华内容
下载资源
问答
  • 现代软件交付成熟度指数:一种资源,可帮助团队评估和改善其软件交付
  • 此功能将支持您的软件交付过程的人员,实践,技术和信息结合在一起。 DevOps:IBM方法 IBM白皮书DevOps:IBM方法解释了为什么持续交付软件是企业必备的功能。 本文概述了在组织中采用或改进连续软件交付的...

    IBM DevOps引入了用于持续交付软件的企业功能,使组织能够抓住市场机会并减少获得客户反馈的时间。 此功能将支持您的软件交付过程的人员,实践,技术和信息结合在一起。

    本文概述了在组织中采用或改进连续软件交付的四种途径。 这些采用路径重点在于:规划和测量,开发和测试,发布和部署以及监视和优化。 除了采用途径之外,本文还提供了一个基于实践的框架,称为IBM DevOps成熟度模型,它可以帮助您评估当前的实践,定义路线图并在采用IBM DevOps的过程中评估您的改进情况。方法。

    采用框架

    IBM DevOps成熟度模型是您的沟通工具,可将您的改进策略告知您的企业。 该模型超越了组织,业务领域和技术。 我们基于实践的模型反映了企业采用框架的更广泛上下文。 它定义了执行策略的最佳实践,该策略以迭代方式采用新解决方案,并使您的组织能够评估,计划,定义和部署可为您的企业带来可衡量结果的改进。 采用框架规定了准备,试验和将改进发布到企业中的步骤。

    如图1和表1所示,采用框架的第一步之一是评估您的当前成熟度水平,并决定采用或改进企业DevOps功能的范围,体系结构和路线图。

    图1.采用框架
    表1.采纳框架中的活动
    活动 描述
    评估并决定 评估当前的成熟度,并确定采用或改进企业DevOps功能的范围,体系结构和路线图。
    建立核心团队 建立领导和指导小组以推动改进/采用并支持更广泛的虚拟主题专家团队。
    定义工作模型 定义一个使用模型,以解决每个角色的流程和活动,以及针对试验中计划的功能的工具配置和支持体系结构。 然后,这将用于解决方案的用户接受测试,并由试点团队在试点期间使用。
    为飞行员做准备 定义用于验证目标的试验结果/目标和度量。 使用使用模型,产生资产以支持将解决方案引入试点团队。 资产可能包括培训,工作帮助,插件,报告和查询。
    试点项目 在生产项目或计划中将定义的改进与真实数据一起使用。 衡量目标,验证使用模型,然后为下一个试用版/发行版改进解决方案。
    执行采用策略 在试验之后,根据路线图在组织,技术和应用程序之间部署试验的能力。
    释放 该版本是定义明确的改进,可以为用户,团队,项目,程序,部门和企业产生可衡量的结果。

    采用路径

    该表源自白皮书《 DevOps:IBM方法》 ,定义了DevOps功能,这些功能用于解释在定义当前成熟度以及定义改进路线图时应考虑哪些人员,实践和技术。

    表2.采用路径
    采用路径 描述
    计划和衡量 包括业务计划实践。

    业务计划和度量采用精益原则,从识别测试业务远景/价值,持续调整和调整,衡量实际进度,了解客户真正想要的内容以及敏捷性转向和更新计划所需的结果和资源入手。 。

    开发和测试 由协作开发和测试实践组成。

    协作开发使业务,开发和质量保证组织之间的协作(包括跨时区的外包项目中的承包商和供应商)能够持续交付创新的优质软件。 这包括对多语言编程的支持和对多平台开发的支持,思想的阐述以及跨团队生命周期管理的用户故事的创建。 协作开发包括持续集成的实践,这促进了频繁的团队集成和自动构建。 通过更频繁地集成系统,可以在更易于修复时及早发现集成问题,并通过不断的反馈减少整体集成工作,因为该项目显示出持续而可证明的进展。

    连续测试可以降低测试成本,同时可以帮助开发团队平衡质量和速度。 它消除了通过虚拟化相关服务产生的测试瓶颈,并且简化了虚拟化测试环境的创建,可以随着系统的变化轻松地进行部署,共享和更新。 这些功能通过允许在生命周期的早期进行集成测试,从而降低了配置和维护测试环境的成本,并缩短了测试周期。

    发布和部署 包括发行和部署实践。

    发布和部署提供了连续的交付管道,可自动部署到测试和生产环境。 它通过按钮部署减少了手工劳动,资源等待时间和返工,从而提高了发布频率,减少了错误以及端到端的合规透明性。

    监控和优化 包括监视,客户反馈和优化实践。

    监视提供了易于访问和消耗的报告,可帮助开发人员和测试人员了解其应用程序在生产中以及部署到生产之前的性能和可用性。 持续监控提供的早期反馈对于降低错误和变更的成本以及指导项目成功完成至关重要。

    持续的客户反馈提供了可视的证据和完整的上下文,可用于分析客户行为并查明客户的痛点。 可以在生产前和生产后两个阶段都应用反馈,以最大程度地提高每次客户拜访的价值,并确保成功完成更多交易。 这样就可以立即查看影响其行为并影响业务的客户争斗的根源。

    DevOps成熟度

    IBM在帮助组织成功采用IBM DevOps方法方面的经验为采用或改善DevOps功能和成果的业务驱动战略提供了支持。 制定以业务为导向的战略包括:确定一组可衡量的业务目标的优先级,以您的当前实践为基准,并制定一个渐进的采用路线图,以保持与您的目标保持一致。 路线图应提供功能改进的指南,并确定实现业务目标的增量步骤。 定义路线图的最好的第一步是从评估当前的成熟度级别并定义支持目标的目标开始。

    使用IBM的基于实践的成熟度模型并开发以下各节所述的优先级热图,可以提供定义和实现您的结果的框架,以及衡量改进的计划和方法。

    优先进行功能改进

    IBM建议通过评估与每个采用途径相关的每个高级功能来定义整个组织的改进优先级。 还可以确定组织或角色之间的潜在依存关系,以显示协作在哪里破裂或减弱。 可以针对组织中已经在进行的特定计划定制评估,以将重点缩小到特定的关注领域。 如图2所示,通过高级功能模型对改进进行优先级排序,可帮助您定义以通用方式对所有涉众采用DevOps所需的范围和关键功能。

    图2.样本能力改进热图

    基于实践的成熟度模型

    IBM DevOps基于实践的成熟度模型定义了四个成熟度级别,这些级别与您的组织当前如何执行与每个采用路径一致的实践相关。 随着您从练习 过渡按比例缩放 ,成熟度级别会增加。 该模型包括每种采用途径的实践成熟度。

    成熟度

    IBM DevOps成熟度模型定义了四个成熟度级别,这些级别描述了组织执行与每个采用路径一致的实践的程度。 这些级别考虑:一致性,标准化,使用模型,定义的实践,导师团队或卓越中心(COE),自动化,持续改进以及组织或技术变更管理。

    表3.成熟度级别
    成熟度 描述
    练过 一些团队可能会进行与练习相关的活动,但并不一致。 未定义企业标准。 可能已经实现了自动化,但是没有一致的使用模型。
    一致的 定义了企业实践标准。 一些团队进行与练习相关的活动并遵循标准。 没有核心团队或COE来协助实践。 自动化(如果使用)遵循企业标准。
    可靠 存在一些机制来协助采用并确保遵循标准。 一个核心的导师团队可为您提供最佳实践,教育和改进方面的帮助。
    缩放比例 在整个企业范围内,对实践的采用已被制度化。 COE是持续改进和实现的成熟且不可或缺的部分。 实践在整个企业中已成为主流。 制定了反馈流程以提高标准。

    成熟度模型

    图3显示了IBM DevOps成熟度模型。 垂直列与采用路径对齐,水平行指示随着您从下到上移动而增加的成熟度级别,其中实践级别是最低的可测量级别规模 级别 是最高的 每列代表特定采用路径的一组实践和成熟度级别。 该模型提供了一种评估和查看整个DevOps连续性的成熟度的方法,旨在与其他专业模型(如敏捷,SOA和CMMI)的目标和结果保持一致。

    图3. DevOps成熟度模型

    成熟进度

    以下各节介绍了每种采用路径的成熟度等级进度。 他们描述了组织如何通过采用新的实践和支持技术来在采用过程中走向成熟。 重要的是要了解,要在采用路径上达到一定程度的成熟度,组织可能还必须在其他依赖的实践中成熟。 例如,为了有效地实现真正的连续测试功能,组织将需要具有连续集成和构建应用程序的功能,以及将构建程序连续部署到测试环境中的功能。

    计划和衡量

    在实践级别,组织在每个项目的文档中捕获业务案例或目标,以定义策略的范围,但是项目的资源管理在部门级别进行。 一旦执行了项目,就可以在项目或计划的上下文中管理变更和范围,以在预算内按计划实现目标。 随着组织的成熟,业务需求会记录在企业环境中,并进行测量以满足客户价值指标。 然后,将这些需求确定优先级,使其与发布保持一致,并与计划或项目需求相关联。 项目变更和范围在项目组合级别进行管理。

    开发和测试

    在实践级别,项目和程序团队以文档和电子表格的形式生产多个软件开发生命周期产品,以解释其需求,设计和测试计划。 代码更改和应用程序级构建按正式的定期计划执行,以确保有足够的资源来克服挑战。 在大多数(如果不是全部)构建完成之后,在将应用程序构建正式交付给QA团队之后,执行除单元级别之外的测试。 随着组织的成熟,软件开发中的敏捷性不断提高,以改善业务一致性,从而推动了对持续不断的反馈的需求。 例行执行软件交付,集成和构建,然后针对单个开发人员,团队,应用程序和产品连续进行。 向早期反馈和持续交付的转变通过利用自动化测试和虚拟化来鼓励测试的成熟。 集中的测试功能提供跨项目的服务,以连续运行回归和其他自动化测试,前提是基础架构和应用程序部署也可以支持这些测试。 链接的生命周期信息开始在跨功能信息的背景下支持改进的协作。 这最终为开发智能提供了基础,该智能用于评估连续过程和技术改进的影响。

    发布和部署

    在实践级别,每年计划为新功能和维护团队发布版本。 必要时会出现重要的维修和非周期发布。 所有发布都通过通过面对面会议更新的电子表格进行管理。 变化的影响分析是在事件发生时手动执行的。 使用手动或手动暂存和启动的脚本可以跨部门一致地执行应用程序部署和中间件配置。 基础设施和中间件的配置类似。 随着组织的成熟,将在协作环境中集中管理发布,该环境利用自动化来维护各个应用程序的状态。 部署和中间件配置是自动化的,然后成熟为自助服务模型,该模型为单个开发人员,团队,测试人员和部署管理人员提供了持续构建,配置,部署,测试和升级的功能。 基础架构和中间件配置已发展为类似于应用程序部署的自动化然后自助服务的功能。 运营工程师停止手动更改环境; 相反,他们专注于优化自动化。

    监控和优化

    在实践级别,将监视部署的资源,并在事件或问题发生时加以解决,而无需受影响的业务应用程序的上下文。 开发和运营组织进行非正式协调,通常由特定事件或问题驱动。 用户对业务应用程序的体验的反馈是有限的,并且只能通过正式的缺陷程序来获得。 随着组织的成熟,监视将在业务应用程序的上下文中执行,并且优化将在QA环境中开始,以提高稳定性,可用性和整体性能。 监视客户体验以优化业务应用程序中的体验。 反映业务价值实现的客户关键绩效指标的优化是持续改进计划的一部分。

    DevOps评估和计划

    如何开始您的DevOps旅程? 最困难的部分是确定正确的第一步,然后在整个采用过程中保持支持。 我们发现,伟大的第一步是通过实现成熟度改进的计划来概述组织的DevOps投资策略。 这些措施构成了从您当前的实践成熟度水平开始逐步改进的基础。 进行跨职能的讨论,以定义计划目标,确定路线图的优先改进并确定组织可以实现的快速胜利。 然后,利用前90天可实现的快速胜利来建立势头,并保持基层的精力和管理层的支持。

    定义计划或确定并执行这些快速目标的一种方法是利用IBM的DevOps评估和计划研讨会 它旨在加快您对DevOps改进和采用的入门工作。 使用基于实践的方法,我们利用DevOps成熟度模型对您当前的成熟度进行基准测试,并提出逐步改进的建议。 在研讨会期间,我们的专家顾问会与您的团队进行协作讨论,以优先制定一组DevOps改进计划,定义结果并制定总体策略。 然后,我们可以帮助您定义一系列优先的实践改进,这些改进构成了支持每个计划的可执行路线图和体系结构的基础。 我们将审查您当前的能力,并探索每个实践领域的改进(例如需求,构建,部署,管理等),从而为迭代的DevOps改进制定优先的规范性路线图。 该讲习班侧重于整个软件交付连续性的特定领域,以交付可执行策略,以实施一系列增量计划来改善您的DevOps功能。 该研讨会加快了您在DevOps旅程中的第一步,并提供了一套已定义的计划,策略以及详细的改进路线图和体系结构。


    翻译自: https://www.ibm.com/developerworks/library/d-adoption-paths/index.html

    展开全文
  • 软件交付概述

    千次阅读 2019-04-03 22:54:41
            经过软件设计和软件开发两个阶段之后,基本上大部分工作都已经...软件交付,一方面,开发方会根据项目前期的软件设计展现开发成果,另一方面,客户方也要对开发成...

            经过软件设计和软件开发两个阶段之后,基本上大部分工作都已经做完了,剩下的就是交付软件,给客户一个可以正常使用的系统。

            软件交付,一方面,开发方会根据项目前期的软件设计展现开发成果,另一方面,客户方也要对开发成果进行最终的项目验收。概括来说,软件交付主要包含系统演示(用户培训)、系统部署、后期维护三方面内容。

    系统演示(用户培训)交付物

            1、培训材料

            2、系统演示(模拟操作)

            3、用户答疑

    系统部署交付物

            1、部署文档

            2、系统部署(现场或者远程支持)

            3、系统可用测试、清理测试数据(可选)

    后期维护交付物

            1、需求变更评估

            2、系统升级(新需求开发、漏洞修复)

            3、维护支持(现场或者远程支持)

    展开全文
  • 研发效能嘉年华如何做到高效软件交付PPT
  • 衡量软件交付性能的4个指标

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

    目录

    软件交付性能指标

    部署频率

    变更准备时间

    变更失败率

    平均恢复时间(MTTR)

    总结


     

    当你的团队需要通过持续集成和持续交付(CI/CD)流水线将代码部署到生产环境时,衡量这些应用程序交付的速度和稳定性对于确保软件的高质量具有至关重要的意义。

    Nicole Forsgren博士的《Accelerate》一书中介绍了四个软件交付性能指标,来衡量和可视化我们应用程序交付的速度和稳定性。eBay公司据此做出了尝试。

    软件交付性能指标

    以下是四个软件交付性能指标:

    1. 部署频率–你的组织多久一次将代码部署到生产环境?
    2. 变更准备时间–从提交代码,到在生产环境中成功运行要花多长时间?
    3. 变更失败率–部署中有多少次回滚,修补等?
    4. 平均恢复时间–出现问题时,需要多长时间恢复正常?

    eBay公司据此,构建了一个可以实时跟踪和可视化所有这些指标的系统,并能够深查看该组织内所有团队的这些指标的信息。

    此外,该系统还允许访问历史趋势,以识别每个级别上四个指标的改进或降低。团队还可以使用过滤器来查看特定时间段内的指标。

    部署频率

    为了跟踪该指标,我们从构建和部署系统中查找部署事件。在新版本的应用程序被部署到生产环境后,部署计数器会递增。这包括好和坏的应用程序版本。

    变更准备时间

    准备时间,指的是从变更创建时间到部署第一个服务实例过程中耗费的时间。

    部署到生产环境中的单个功能修改,可能有多个提交,从而导致要计算多个交付周期。为了计算单个变更准备时间的总体指标,我们将这些准备时间的中值用作该部署的“变更准备时间”。

    该组织,团队或应用程序的所有部署的“变更准备时间”的平均值,就是我们想要的“变更准备时间”。

    变更失败率

    应用程序在部署生产环境后,由于某些原因影响用户使用,我们需要修正(例如修补程序,回滚,正向修复或修补程序等),这些系统修补次数在所有部署中所占的百分比,就是变更失败率。

    当前,我们将变更失败率衡量为给定时间段内所有部署中的回滚百分比。如果实例正在为流量提供服务,即使来自单个实例的回滚也算作失败。

    平均恢复时间(MTTR)

    平均恢复时间(MTTR)表示系统发生故障时,恢复正常所需的时间。

    例如,如果将构建N(不良构建)部署到生产中,然后团队发现了一个问题,要求他们通过部署N-1(最新已知的良好构建)来回滚N,直到将N-1部署到生产环境为止的时间花费就是恢复时间(TTR)。所有TTR的平均值为MTTR。

    总结

    作为eBay内“ Velocity Initiative ”的一部分,eBay的各种平台和产品团队正在共同努力以实现一个共同目标:提高所有团队更快地交付高质量软件的能力。

    同时,测量和可视化这些指标,有助于团队了解交付速度和稳定性方面的优势,还有助于确定整个团队在软件交付过程中需要改进的地方。

    译文链接:https://thenewstack.io/4-ways-to-measure-your-software-delivery-performance/

    展开全文
  • 项目经理手册,项目经理手册(软件交付)
  • [IBM Press] 规范敏捷交付 企业级敏捷软件交付的方法与实践 (英文版) [IBM Press] Disciplined Agile Delivery A Practitioner's Guide to Agile Software Delivery in the Enterprise (E-Book) ☆ 出版信息:☆ ...
  • 多团队软件交付评估 多团队软件交付评估是一种简单,易于执行的方法,用于评估组织内许多不同团队之间的软件交付。 它是由的的,它被用作的的关键部分,但任何人都可以自由使用(必须遵守以下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

    软件交付方式有哪些

    展开全文
  • 软件交付的主要工作是将程序代码和相关文档交给用户 B 用户培训是帮助用户理解产品并掌握系统的使用和操作 C 软件部署是通过配置、安装和激活等活动保证软件系统的正常运行 D 持续集成是频繁持续地将...
  • [Addison-Wesley Professional] 企业软件交付 敏捷与高效管理精要 (英文版) [Addison-Wesley Professional] Enterprise Software Delivery Bringing Agility and Efficiency to the Global Software Supply Chain ...
  • Wave-Game:自动化软件交付项目
  • 软件交付Rubbish software is produced when we try to do everything at once. 当我们尝试一次做所有事情时,就会产生垃圾软件。 Principles, guidelines, best practices, and rules of thumb — they all make ...
  • Devtron是一个用go编写的kubernetes开源软件交付工作流程。 ·· · :open_book: 菜单 :light_bulb: 为什么选择Devtron? 它被设计为自助平台,以对开发人员友好的方式在kubernetes上操作和维护应用程序(AppOps...
  • 软件交付领域,分角色的精细分工是不利于整体交付效率的,那为什么在DevOps倡导下的全栈工程师、开发运维一体化又会产生新的问题呢?如何解决这些新问题呢? 也许,我们需要认真思考,在整个软件交付过程中,什么...
  • 第 1 章 企业软件交付为什么这么难 本章概要本章介绍了本书的主要议题:企业全球化、交付的成本效率,以及在满足新的市场需求和期望方面的敏捷性。为了阐述这些议题,我将讨论当今企业系统交付中面临的挑战,回顾...
  • PypeFitter是一个基于python的软件交付管道生成器。 目标是允许将抽象的软件交付管道转换为Jenkins或AWS之类的提供商的具体的可执行实现。 我为雇主提供了这种方法的原始实现,但是这种方法虽然可维护的POC相对...
  • 3.4 企业软件交付的软件工厂方法 正如我们前面讨论的,今天的机构面对的商业环境正以前所未有的速度发生变化。与此同时,这些机构还要管理和降低整个机构的运营成本。这就直接意味着,他们不仅要最大限度地减少浪费...
  • 第 2 章 企业软件交付项目解析 本章概要本章中,我会给出一个企业软件交付项目的典型例子,并讨论它的主要特点,分析可以改进的地方。在这个例子里,我会探讨企业和项目两个层面的问题,最后得出以下结论:无论从...
  • 持续交付之一——软件交付的问题

    千次阅读 2016-05-07 07:30:23
    第一章 软件交付的问题1. 引言本书的核心模式是部署流水线,以持续集成理论作为其理论基石部署流水线有三个目标 让软件构建,部署,测试和发布过程对所有人可见,促进合作 改善反馈,能在整个过程中更早的发现和解决...
  • 2.2 MyCo公司和MyProj企业软件交付项目 这个案例取材自真实的项目,可以说明很多实际情况。有一个跨国公用事业公司,依赖一家企业软件交付机构来为业务提供IT服务,而后者承受着很大的成本和效率压力。为了简便起见...
  • 1.4 企业软件交付机构关注什么 一般来说,企业的软件交付机构进行的工作可分为三类补救和修复现有系统。目前,大量资源都致力于修复和升级现有系统,以延长其使用寿命。这些工作的策略都是旨在满足必须解决的短期...
  • 第三方软件交付要注意啥 总览 在当今瞬息万变的软件世界中,公司和个人提出了许多方法来最大程度地缩短产品上市时间,即,您的想法在生产中付诸实践的时间。 特别是在竞争激烈的移动和Web应用程序世界中。 许多公司...
  • 2019 年,全世界的开发人员都开始习惯用容器来...时至今日,容器镜像已经成为了现代软件交付与分发的事实标准。我们知道,Kubernetes 是一个“重 API 层” 的项目,但我们还应该理解的是,Kubernetes 是一个“以 ...
  • 使用DNN的勒索软件交付检测 基于Joseph Zadeh和Rod Soto的作品-Aktaion 建筑与工作 使用者介面
  • 软件交付平台提供商CloudBees希望建立软件交付管理类别,以解决孤立的开发流程,并使开源Jenkins CI / CD系统作为软件即服务(SaaS)产品提供。 通过SaaS进行软件交付管理 CloudBees计划中的基于SaaS的SDM平台会...
  • 根据 2017 年的 DevOps 发展报告,高效能组织和低效能组织在软件交付的效率上有数量级上的差异。技术组织的软件交付能力是一种综合能力,涉及众多环节,其中发布是尤为重要的环节。 作为技术人员,大家可能听说过...
  • 软件交付性能的四个关键指标

    千次阅读 2019-04-06 19:12:32
    软件交付性能的四个关键指标(FOUR KEY METRICS): 前置时间,部署频率,平均恢复时间(MTTR), 变更失败百分比
  • 3.3 企业软件交付的产业化:打个比方 随着需求激增,手工技术已经不再能够满足消费者的需求—企业软件交付不是面临这些挑战的唯一行业。我们可以借鉴的工业行业的发展历程:20世纪之前,大多数产品的生产都是采用...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 12,833
精华内容 5,133
关键字:

软件交付