在之前有关精益软件开发的文章中,我解释了 精益原则1– 消除浪费.

质量问题导致各种浪费。那’s a fact. There’在测试代​​码上不止一次的浪费。浪费在测井缺陷中。浪费在修复它们上。结果,精益原则专门试图解决这一点。

第二原则 精益软件开发的7个关键原则建立质量

在敏捷方法中,例如Scrum和Extreme Programming(XP)–我个人认为这是精益思想在行动中的典范–有多种实践可以帮助您做到这一点…

首先,首先设计了避免质量问题的质量保证流程。这两个例子是 配对编程 和测试驱动开发。

配对编程 通过将两个开发人员的思想应用于每个任务来避免质量问题。这项任务得益于两个开发人员(而不是一个)的集体,综合经验,通常会提高生产率,因为他们看到了自己可能无法完成的解决方案。结对编程的另一个积极成果是提高了质量,因为一个人可以比其他人先行思考,在问题发生之前就发现问题。

测试驱动开发 通过在编写代码之前编写测试来避免质量问题。以最简单的形式,考虑一下由测试分析师/质量保证人员写下每个功能的测试条件’的开发。如果开发人员知道如何’要进行测试,他们更有可能编写解决所有情况的代码。至尊编程以更复杂的形式提倡在实际编写代码之前先对代码进行测试并针对每个测试条件编写自动化的单元测试。然后,开发人员编写代码以通过测试。

这两种做法都来自极限编程,并且都试图防止发生质量问题。

持续的反馈– Inspect and Adapt

Scrum和XP都以另一种方式将质量提高到流程中,这是许多 敏捷软件开发的10个关键原则。通过以较小的增量步骤进行开发,紧密合作以及以较小的迭代进行开发,这些敏捷方法为产品所有者和团队之间提供持续的双向反馈提供了机会。这种反馈非常有价值,每天检查和调整产品以确保正确的质量水平–最重要的是– the right product.

当然,XP和Scrum的做法是完全互补的,因此它’可以同时使用两者。

缩短阶段之间的时间

在开发过程中提高质量的另一项重要技术是最小化开发,测试和错误修复之间的时间。与其记录错误,不如立即对其进行处理。在很多情况下,记录错误实际上是浪费的。测试人员是否可以尽快测试代码’,并且开发人员可以在发现任何错误后立即对其进行修复,将它们记录下来有什么价值?另一方面,在生成代码,对其进行测试之间以及在修复错误之前,两者之间的长时间差距导致失去了连续性。连续性的损失会导致任务切换延迟,知识缺口以及缺乏重点。

频繁整合

大多数敏捷方法还主张定期进行频繁构建。至少每天一次,如果不是每小时一次。 Extreme Programming提倡持续集成,将代码集成到整个系统中,并在签入后立即构建并自动进行单元测试。最小化构建之间的差距还减少了另一种浪费,即集成。在大型瀑布式项目上,项目的集成和回归测试阶段可能会非常漫长。定期构建和频繁集成可以避免该问题。

自动化

敏捷 development methods also encourage automated regression testing. Of course this 是 a practice that 是 not unique to agile development, but 是 another way to reduce the effort associated with finding quality 是sues before they occur in a live environment. This 是 admittedly the last stage, but quality assurance 是 built into every step in the process.

这就是Scrum和XP如何将精益原则转化为软件开发的实践,以及它们如何在流程中建立质量的方式。根据您自己的情况,您可能还会看到其他提高质量的机会。

管理权衡

一句话警告。质量只是项目的一个维度–其他是时间,成本和范围。有时出于商业原因,需要在质量与其他因素之间进行权衡,或者要注意那些对质量的关注超过了您要避免的问题的情况。

敏捷方法原则上承认这一点的一个例子是接受返工(‘refactoring’),因为没有详细的规范和预先完整的设计。在传统方法中,这些实践旨在在项目生命周期的早期提高质量。但是,多年来,许多人发现它们适得其反,因此诞生了敏捷方法。

同样,如果您正在处理影响力很低的相当低复杂度的视觉组件,则可能值得花更少的时间在质量保证上,因为发生质量问题的风险以及造成的影响要低得多。自然地,这是一个判断决定,不幸的是,要划清界限很难。

综上所述…

质量显然非常重要,否则您不可避免地会进一步产生各种废物。内建质量。在过程中尽早内建质量,以避免出现质量问题。并将其构建在整个开发过程中,而不仅仅是在最后。

凯莉

精益软件开发的7个关键原则:

1. 消除浪费
2. 建立质量
3. 创造知识
4. 推迟承诺
5. 快速交付
6. 尊重人
7. 优化整体

 

在脸书上分享
Facebook
分享到Twitter
Twitter
在linkedin上分享
LinkedIn

发表评论

您的电子邮件地址不会被公开。 必需的地方已做标记 *

最近的帖子

文化,技能和能力//如何成为数据驱动型组织

在我们的白皮书“如何成为一个由数据驱动的组织中”,我们写了一个组织需要采取的五个步骤,它们是:成果:定义目标和指标以确保获得清晰和可衡量的结果分析:实施和共享分析,以改善数据驱动型决策创新:通过假设测试和学习来测试假设数据平台:获得新见解

Read More »

数据平台//如何成为更具数据驱动力的组织

这是我们关于“如何成为一个由数据驱动的更多组织”系列文章中的第四篇,我们将专注于数据平台。在这一点上,大多数人开始深入研究Data Lakes vs Data Warehouse的技术方面,但是我们想让我们回到一个更高的水平,并要求

Read More »

创新//如何成为更具数据驱动力的组织

在我们的白皮书“如何成为一个由数据驱动的组织中”,我们写了一个组织需要采取的五个步骤,它们是:成果:定义目标和指标以确保获得清晰和可衡量的结果分析:实施和共享分析以改善以数据为依据的决策制定创新:通过假设检验和学习来检验假设数据平台:获得新

Read More »

搜索博客

敏捷 Management Made Easy!

All About 敏捷

凯利·沃特斯(Kelly Waters)

“’Agile’ 是 one of the biggest buzzwords of the last decade. 敏捷 methods often come across as rather more complicated than they really are. This book 是 an attempt to unravel that complexity. To simplify the concepts. This book breaks the concepts into small bite-sized pieces that are easy to understand and easy to implement and delivers the message in a friendly and conversational style. Allaboutagile.com 是 one of the most popular blogs about agile on the web. ”

凯利·沃特斯

敏捷 101 是 available to purchase. GAME ON!

敏捷 101

艾玛·霍普金森火花

“尽管有很多方法可以根据您拥有的团队和想要的学习成果来改变游戏,但是游戏的基本流程是所有人共有的。”
艾玛·霍普金森火花

我们为什么制作游戏?

怎么玩游戏?

伦敦

101种方式Limited
城市路145号
伦敦
EC1V 1AZ
英国

阿姆斯特丹

101种方式BV
Weesperstraat 61-105
1018 VN阿姆斯特丹
荷兰

联系我们

如果您想与101 Ways的团队之一联系,请填写以下表格或给我们发送电子邮件: contact-us@101ways.com.