腾讯云开发者社区-腾讯云

开发者社区

文档建议反馈控制台

文章/答案/技术大牛

发布

综合排序丨最热优先丨最新优先

【敏捷3.4】增量交付与敏捷合同

增量交付与敏捷合同在学习了评估价值和为需求排定价值优先级的一些方法之后，我们接下来就看看在迭代或者冲刺中应该注意些什么才能不枉费之前的努力。增量交付从最早我们接触到敏捷概念开始，就知道敏捷最大的特点是迭代、增量式的开发。在这里，我们再具体的说一说增量到底增的是什么。其实你也应该猜到了，我们增量增的就是最有价值的那一部分。因此，敏捷提倡的客户合作并不是空穴来风。频繁交付、随时变化、客户合作，似乎我们又重温了一遍敏捷宣言。敏捷合同管理对于敏捷项目来说，怎么签合同其实是一个挺棘手的问题。总结这下我们算是搞清楚增量交付到底是交付的什么，以及真实的客户价值其实就是在一次次的迭代中通过增量的价值交付所找到的。最后我们简单地了解了下敏捷合同以及如何核实和验证交付的价值。可以看到，价值是敏捷中非常重要的东西，而交付价值则是贯穿敏捷原则的一条主线。说白了，敏捷定的宣言、原则，各种框架工具，最终的目的是什么呢？就是为了向客户交付价值。

硬核项目经理

2023-03-03

6880

标签:

腾讯云测试服务

远程项目交付的敏捷管理

这种情形下，常见的敏捷实践活动也都是适用的。敏捷和精益关注的是价值观和原则。价值观也是文化的一部分，因此需要和离岸团队交谈并学习如何共同工作才能建立。本文内容也适用于任何远程项目的敏捷管理。稳定的远程Scrum团队管理层需要意识到尽量把团队保留在一起的价值，不管是长项目还是短项目，理想情况下长期稳定的团队有利于保障交付和学习。基于敏捷来甄选外包公司外包公司有可能号称自己支持各种敏捷研发模式，实际上将其变异成自己能够重新定义，控制的东西，兜售逐利的商业工具，但是有些敏捷原则可能在该外包公司根本无法支持。把编码和测试工作比喻成“工厂”的外包公司，没有理解反馈循环的意义，“工厂”强化了长队列上的大批量工作，把“半成品”交付给其他团队。大型外包公司和工程师才能似乎有反向关系。如果你选定了一家外包公司，就要鼓励他们和你一起采用精益和敏捷，共同提升。结论某些尝试过远程交付，而且还是跨国外包交付的人，可能感到泄气，感到项目浪费巨大。

2023-03-22

1.7K0

标签:

敏捷交付的工程效能治理

在敏捷交付中，大家可能会遇到各种各样的问题，从而会影响最终的交付效果，甚至可能导致交付的失败。因此，如何在交付过程中进行有效的治理，提高交付效能，对于交付的最终效果会起到至关重要的作用。这种思考是持续性的，在不同的项目中，大家遇到的交付情况和挑战通常会有一定的区别，甚至较大的不同，但是无论项目如何变化，最终的目的是要成功地交付，因此持续性地思考，复盘，改进交付能力，从而提高交付竞争力，基于多年的在敏捷交付领域的探索和实践，我们逐步沉淀了一些方法，经验和教训，从而形成了本文中介绍的针对交付工程效能和治理的框架。尤其是针对分布式敏捷交付中，对齐目的和价值会对在不同地点工作的员工能够更有效地协作具有更积极的意义。 )，也可以是客户侧的商业价值工程卓越和文化 - 通过不断追求工程卓越以及形成的工程文化来从侧面影响客户你可以根据组织的目的和愿景，来设定真正符合组织需要的终极目标，但是商业价值应该是在以价值驱动的敏捷交付中比较通用的目标

2022-08-26

7170

标签:

当敏捷开发遇上固定交付……

“三重约束”只关注了项目的交付交互，而忽略了项目的价值交付。如果我们所提供的解决方案不能增加价值，那项目按时、按预算交付的意义是什么呢？二、敏捷是否适用于固定交付项目？但不得不承认在固定交付项目中使用敏捷方法可能会有一些优势。三、使用敏捷进行固定交付的优势 1.适用不断变化的需求在项目进行过程中，项目需求随时会发生变化。敏捷开发方式能灵活应对这些变化，让团队快速响应新的反馈和需求，以确保最终产品满足客户的需求。 2.早期交付价值敏捷开发方式强调定期交付产品的工作增量，而不是等到项目接近尾声时才爆炸式交付。四、使用敏捷进行固定交付的缺点 1.管理范围敏捷开发能够轻松适应需求的变化，但前提是必须与客户仔细协商。假设固定范围与交付时间表和预算完全匹配，那范围的增加会破坏平衡。五、写在最后在固定交付的项目中使用敏捷开发方式是一把双刃剑。虽然敏捷开发方式具有适应性、早期价值交付等好处，但范围、预算管理以及与合同相关的问题等挑战可能成为项目进行过程中的重大问题。

2023-11-10

5790

标签:

（四）如何在敏捷环境中交付？

使项目敏捷的一个基本要素是频繁的交付工作产品，一个没有展示或发布的团队，其学习的速度不会快，并且很可能并未采用敏捷技术。团队可能需要额外的引导来保证频繁的交付。在能力降低的情况下，团队只会激化相应能力能够完成的工作；团队不能100%的确定自己能交付什么，因为他们无法知道意外情况。敏捷团队在一个工作块中不只会计划一次。相反敏捷团队会开始计划一点，交付，学习，然后在一个持续的循环中重新规划更多的东西。 2.7帮助团队交付价值的执行实践如果团队不重视质量，很快就会无法快速发布任何东西。下面的技术实践中，很多都来自极限编程，他们可以帮助团队以最快速度交付：持续集成。敏捷团队非常偏爱自动化测试，因此他们可以借此构建和保持交付的势头。验收测试驱动开发（ATDD）。在ATDD中，整个团队聚集一堂讨论工作产品的验收标准。

2019-12-17

1.4K0

标签:

【敏捷3.1】价值与价值驱动交付

价值与价值驱动交付上一大篇的敏捷框架怎么样，有没有意犹未尽的感觉？敏捷框架只是敏捷的一部分，而且是偏实践的部分。所有的教材都喜欢把这些敏捷框架写在前面也是因为这部分非常吸引人。但是，真正的敏捷还有许多理论等着我们来探索，不要着急，在学习完后面的内容之后，再回来看敏捷框架，或许你会理解得更加深入。什么是价值其实在敏捷框架中，我们不只一次的提过要交付价值。什么是价值？所以，敏捷提倡的是尽早交付有价值的产品。然而，敏捷是迭代、增量的开发的，而一个项目产品中，也一定有一些功能或者内容是会产生更高的价值的，我们要做的就是尽早的交付这一部分的功能。在迭代开始时，PO 或者是其他类型的敏捷团队会优先选择价值最高的部分来优先实现。这也是对需求进行排序的一个重要参考值。尽早交付价值有什么好处呢？当然是为了让客户尽早尝到甜头。而价值驱动交付这块，我们更关注的是评估价值优先级方面和增量开发方面的内容。总结今天的内容不多，也总算是从敏捷框架的长篇大论中解脱出来了。不过，从现在开始，我们才是进入了敏捷中最核心部分的学习。

硬核项目经理

2021-12-26

1.2K0

标签:

持续交付与传统敏捷的矛盾

我在采用持续交付的组织中和开发团队工作一起工作，发现很多开发者认为的正确的敏捷团队的工作方式，在这里跑得不是很顺畅。我认为传统敏捷与持续交付的矛盾的根本在于，二者是采用不同的方式把软件变得“可以发布“（ready to release）的。 03 持续交付：持续交付是敏捷的一个子集，在持续交付中团队会保持软件在开发过程的所有时间内都可以发布。它和传统敏捷不同之处在于，持续交付在开发过程中不会有停下来然后创建发布版本的过程。持续性交付不是指更短的周期从传统的敏捷开发流程变成可持续性交付，不是指把软件发布的周期变短。每天晚上做发布版本仍然不是可持续性交付。持续交付和传统敏捷的冲突点我前面讲过，有时候持续交付和开发团队所认为是“正确”的敏捷实践流程有一些矛盾。

2018-08-01

1.2K0

标签:

什么是交付项目的敏捷之道？

这种似曾相识的困境，正揭示着传统项目交付的致命伤——当我们试图用装修思维做软件开发，交付延期早已被写入基因。，此时变更成本已是天文数字二、敏捷交付的"乐高哲学" 真正的敏捷交付不是简单的站立会议和看板工具，而是一种建筑理念的革新：模块化构建就像乐高积木，每个迭代周期（Sprint）都产出可运行的组件（示例：，如同业主实时参与房屋改造（案例：某SaaS产品通过340次用户故事调整，最终留存率提升至行业TOP3）三、敏捷工具箱的重构法则破除工具堆砌迷思，构建真正的敏捷基础设施：传统工具困境敏捷工具链设计价值实现多系统数据孤岛统一、敏捷交付的量子态演进当某物联网企业将交付单元从"项目"拆解为"特性"，奇迹发生了：交付周期标准差从±22天降至±3天客户需求采纳率从41%跃升至89%紧急变更成本降低92%这背后是三个维度的升维：时间折叠：通过特性分支+主干开发，实现多版本并行交付空间重构：建立跨职能的"特种作战小队"，消除部门墙损耗质量跃迁：实施自动化测试左移，让缺陷在量子态就被观测捕获站在第四次工业革命的潮头，交付项目的终极敏捷之道

2025-03-13

6270

标签:

Offshore敏捷交付团队QA生存指南 | 洞见

序跨地域性的offshore敏捷交付一直以来都是一个充满挑战的工作，对于需要与各种角色进行交互的QA而言更是如此。我在2016年初进ThoughtWorks时就经历了这样一个项目。项目背景客户：澳洲大型电信公司Digital部门,我所在的电商产品部门下有3个交付团队和1个Devops团队，每个交付团队有3-4个开发，1-2个QA，1个IM，BA则是按项目分配且全部都在Onshore 同时由于不在一个地方工作，几乎没有比如团建活动，茶歇等能够促进团队成员互相了解、建立良好团队关系的机会，这对于敏捷团队的建立是非常不利的。虽然敏捷团队提倡“工作的软件高于详尽的文档”，但是对于分隔两地的团队来说，有时候详尽的文档恰恰是提高沟通效率的必要手段。作为QA，在离岸交付团队中，我们更需要注重测试的文档化。

2018-04-17

1.2K0

标签:

聊聊我对敏捷项目交付的理解

尽快的交付和获得用户反馈，并进行快速响应迭代，比按部就班的交付更容易拿到好结果。 2）构建完善的项目文档我负责的这个项目，选择了敏捷的交付模式，但敏捷不代表不需要文档或者轻文档了。选择了敏捷迭代模式，不意味着要牺牲质量。但从另一方面来讲，选择了敏捷迭代交付，势必要在某些方面做一些牺牲。我个人的经验，是可以容忍带着一些问题上线，但前提是不影响用户正常使用。 3）复盘归因是提高交付质量的秘诀这点可以参考我前面写过一篇文章：《复盘归因，提高交付质量的秘诀》项目交付的四大要点关于项目交付的要点，我试着从下面四点来聊聊我的一些看法。交付效率除了按期交付和保障质量可控，在有限时间和资源投入背景下，提高交付效率就很有必要了。

2022-04-01

1.5K0

标签: