创新的软件工程方法

时间:2016-10-10 22:34:55

标签: tdd bdd agile methodology

我正在准备演讲。我的主题是创新的软件工程方法。敏捷是现代和创新的方法,但只是敏捷的答案?什么是其他创新和现代方法?测试驱动开发和行为驱动开发是否也是创新方法? eXtreme Programming是传统的方法,如瀑布?

4 个答案:

答案 0 :(得分:2)

我不确定我们是否可以将这些方法或框架归类为创新,传统或其他方式。

选择方法或框架完全取决于产品和客户需求。任何满足产品要求并为您的团队提供效率的人都可以在该范围内进行创新。

大多数软件开发过程都是在当今的开发世界中开发复杂环境中的复杂产品。我完全同意敏捷方法,极限编程,TDD和BDD 与复杂环境中开发复杂产品的前定义非常匹配。因此,大多数敏捷方法都是对开发复杂产品的检查。

敏捷方法

敏捷这个术语是软件开发专业人员使用的一个非常流行的术语。有许多敏捷方法,scrum,kanban或XP等框架。他们建议使用方法使我们变得敏捷。敏捷一词都涵盖了这些方法。其中大多数解决了预测,适应,透明度,检查和经验过程。所有敏捷方法都试图在软件开发过程中解决这些问题。

极限编程

极限编程专注于开发合格的软件产品并采用不断变化的需求和环境。老实说,我真的很喜欢XP。它并不仅仅建议开发方法。它还提出了一些关于客户管理,成本管理等的建议。这是非常基础的,但很难实施。我强烈建议您阅读Kent Beck撰写的极限编程解释书。

另见:

Extreme Programming

Extreme Programming Explained, by Kent Beck

<强>的Scrum

Scrum是基于经验过程控制的另一个软件开发框架:透明度,检查和适应。它非常简单,并在软件开发过程中定义了一些角色和事件。角色是Scrum Master,产品负责人和开发团队。这些活动包括Sprint Planing,Daily Scrum,Sprint评论和Sprint Retrospective。我建议阅读Scrum指南以获取更多信息。

另见

Scrum Guide

测试驱动开发

测试驱动开发是一个软件开发过程。我不能说它本身就是一种敏捷的方法论。它有助于软件开发变得灵活。测试驱动开发支持开发人员在第一阶段进行测试。测试驱动开发还需要在每次开发之前进行思考测试。它不仅是写作单元测试。

另见

Test-driven development

Test-driven development by Martin Fowler

Test Driven Development: By Example, Kent Beck

行为驱动的开发

这是另一个软件开发过程,从测试驱动开发中脱颖而出。它侧重于交叉团队,如开发,管理和客户共享工具和共享流程,以便对需求有相同的理解。 BDD建议业务人员,客户和技术团队对产品应有相同的理解。客户要求,让客户坐下句子,可以通过工具自动测试。

另见

Behavior-driven development

10 Tips for Writing Good User Stories

Cucumber.io

<强>摘要

如果没有XP,Scrum,看板或任何其他方法或框架,敏捷本身就会缺失。如果没有TDD,BDD或持续集成,任何敏捷方法或框架也会丢失。任何这些项目都必须得到公司文化,客户或商业人士的支持。项目中的每个利益相关者都应该对产品超过项目抱有心态。否则,敏捷方法可能没有帮助。

总而言之,我强烈建议您充分了解持续整合。

另见

Continious Integration

Products over projects

The Clean Coder: A Code of Conduct for Professional Programmers

答案 1 :(得分:1)

我认为你正在混合实践,方法和哲学。

为了寻找新的创新软件开发方法,您可以查看大型科技公司以及他们如何做到这一点。

让我们走Facebook,他们按照The hacker way的说明练习“Erik Meijer's GOTO 2015 video”。据Erik说它不敏捷。它专注于编写代码,而不像大多数敏捷框架那样谈论代码。

如果你看看Spotify,他们有自己的本土扩展“敏捷”实现。看起来很有趣,请参阅the Spotify engineering culture video's

但他们真的很有创意吗?还是只是循环的演变?

你所说的东西根本不再创新。大多数都超过10岁。它们是久经考验的概念,有些人喜欢它们,有些人讨厌它们,但创新地狱没有。

最终,软件开发是一个没有一刀切的解决方案。这是因为编码是一个创新过程,难以标准化。每个公司和产品都需要找到自己的路径。

答案 2 :(得分:1)

“敏捷”是2001年由一群人共同创造的一个术语,他们聚在一起研究为什么他们的项目倾向于成功(或快速失败),其他项目失败(有时很昂贵)。

Agile Manifesto来自那次会议。您可以看到下面的人员列表。有许多与原则,方法和实践相关的人都被认为是“敏捷”:Scrum,Crystal,XP,TDD等。

因此,“敏捷”是一系列遵循主要价值和principles的东西的总称。

“方法论”这个词有很多含糊不清的含义,所以我要把它归结为它的起源。它来自“方法”和“ology”。

从etymonline.com,词源包括:

  {p> Method:定期,系统的治疗......教学或去的方式......科学探究......调查......追求,追随......旅行,方式......做事的方式任何东西。

     

-ology:知识,科学的分支

     

-logy:一个说话,话语,论文,学说,理论,科学......一个说话或对待(某个主题)的人的性格或举止

因此,“敏捷方法论”是关于如何更好地进行软件开发的一系列价值观,原则,实践和想法的总称。这些想法的教学;以下这些想法;以及包含该社区的人。

我会很快完成你提到的事情,这样你就可以看到它们是如何成为敏捷的一部分:

  • 测试驱动开发:源自Kent Beck的XP的一部分,由其他签名者推广,就像创建JUnit的Brian Marick一样

  • 行为驱动的发展:起源于Dan North,基本上是TDD而没有“测试”这个词,除了它比听起来更深刻。当然是敏捷方法的衍生物。

  • 极限编程:Kent Beck也介绍了TDD,肯定是敏捷。

  • 瀑布:通过尝试将所有事情都放在前面来代表,绝对敏捷。

但是,有很多东西正在出现,这些东西来自其他学科。源自丰田精益制造的许多精益知识体系,尤其是戴明的工作,正开始在这个领域发挥作用。所以你得到的东西是:

  • Lean Startup - 通过原型和实验快速验证的想法可能不是长期存在的,但可以立即生存或获利
  • 精益用户体验 - 专注于与开发团队合作而不是需求捕获和分析的持续UI改进
  • Lean Product Development - 丰田设计应用于软件领域的新车的方法,包括基于集合的并行工程等。
  • Kanban for Software Development - 平衡需求和能力的管理方法,也基于源自丰田的想法。

还有大量其他知识和想法可能超出了你所寻找的范围,所以我只是抛弃这些术语以提高认识。

  • 产品开发:影响力映射,故事映射,示例映射,A / B测试

  • 技术流程:DevOps,持续集成,持续部署

  • 人与心理学: Dan Pink的“驱动器”,Cynefin,Neurodiversity,Social Capital

  • 扩展敏捷方法:大规模Scrum(LeSS),扩展敏捷框架(SAFe),纪律敏捷交付(DAD)

  • 战略:精益画布,企业服务规划(ESP),Simon Wardley的战略地图。

这里的一些术语确实是紧急的,可能会改变;这些清单绝对不完整。大多数情况下,我已经将它们包含在内,让您了解敏捷开始的范围,社区的范围以及它的发展方向。

我认为将来它不再被称为敏捷,它最终将包括整个业务,而不仅仅是IT,IMO是一个很棒的东西。它已经开始在全球范围内增加合作,超越企业的边界,这是下一步。

如果你的演讲作为一个笔记结束,我会很高兴。

答案 3 :(得分:0)

嗨@Yusuf因为我在开发应用程序时主要研究敏捷和原型方法。在我看来,原型设计是应用软件工程实践的最创新方式,因为客户端和其他堆栈持有者可以自由地建议任何模型,并且该模型可用于开发原型。它一直持续到堆栈持有者获得所需的软件。此外,我喜欢并学习@erencan的答案