敏捷中8项技术实践_在敏捷中引入新技术

敏捷中8项技术实践

通常，敏捷项目的持续时间很短。 因此，在如此短的时间内引入新技术总是有风险的。 如果您打算引入任何新技术而导致其失败，那么设置基础架构的时间和成本以及sprint的失败将使您失望。

适应性

在为应用选择技术时要牢记的重要事项之一是其适合于应用，而不是其在市场上获得的普及。 在决策过程中，应权衡考虑任何技术对所需解决方案的适用性，而不是市场趋势。

在我们的一个项目中，需要进行非结构化的文本分析； UIMA看起来确实在做所需的工作。 但是UIMA使用外部化进行序列化，而不是使用可序列化的接口，这使它的对象变得庞大，并且需要大量工作来序列化数据。 因此，此功能是在内部而不是使用UIMA开发的。

如何不选择技术也至关重要。 仅因其受欢迎程度，易用性或价格而选择一项技术可能不会使您获得该技术类型中的最佳选择。

Ellyssa Kroski讨论了选择/不选择技术的五个原因 。

“ 每个团队都已经建立了一套成熟的技能，因此他们倾向于使用自己喜欢的技术。 首先要考虑的是功能和特性，而不是技能。 确保与您的技术人员合作，以便他们了解他们将扩展自己的技能并获得所需的培训。

您的老板在杂志上读到它，在火车上听到它，在梦中传到了他/她。如何在不减少或贬低他们发现的情况下告诉老板其他选择？ 这需要轻巧，并且需要轻踩一下。 自愿通过扩大您正在研究的工作范围使他/她了解更多信息，当然是应他/她的要求！

您的朋友告诉您这是“炸弹”！ 在我们的本性中，我们接受来自非个人来源的原始数据的熟人进行生动的转述。 但是，在选择技术解决方案时，轶事证据无法为我们提供对该软件，其功能，功能或公司生存能力的全面评估。

它很贵，它很便宜，它是免费的。 可以很容易地假设，因为产品最昂贵，因此它必须比竞争产品更好。 同样，我们许多预算有限的人总是在讨价还价。 在评估技术解决方案时，有许多因素需要考虑，不要仅仅将价格视为价值的指标。 ”

权限

另一个重要的事情是团队研究引入的新技术的能力/能力。 如果您发现有人连续几天困扰于单个问题也就不足为奇了。

当引入新事物时，这很常见。 因此，在研究新技术时必须配对程序。 对于某些问题，所需的思维带宽不仅仅是一个开发人员的思维范围，因此，配对肯定会在这里有所帮助。

在敏捷开发中，团队规模很小，因此，如果只有一个人继续研究新技术，那么团队就会依赖他。 在结对编程时，有关新技术的知识也会在团队中分发，并且团队的卡车数量保持平衡。

对新技术进行配对编程的另一个好处是团队的学习。

每个人的学习都是必要的。 程序员必须装备和增强自己以使用最新技术，以提高效率。 它不仅可以帮助项目，而且可以满足程序员对知识的追求。 学习会使他们对工作感到满意，从而提高个人和团队的生产力。

安德鲁谈到在工作中学习的重要性 。

“ 为了找到合适的平衡点，重要的是，所有工程师都必须知道他们在整个冲刺中正在做什么。 如果出现粘滞点，例如。 在这种情况下，您会注意到工程师连续低着头呆了几个小时，经过了两次混乱，他们说还剩1或2个小时，他们会在当天完成，但他们永远不会做，那么您就知道了有一个问题。

有时这可以通过配对来解决，但这可能是团队未完成足够的作业的标志。 ”

稳定性，支持和文档

需要注意的其他事项将是该技术可用的支持/文档​​。 我经历过，没有，很少或有错误文档的API很难探索。 如果您是该技术的较早采用者之一，那么它将变得更加困难，因为通过博客/文章/论坛的形式提供的支持将非常少。 但是，除非您花费大量时间进行彻底的研究，否则记录得不好的东西几乎是无用的。

我尝试在我的一个项目中使用Apache Batik，但是文档和支持并没有那么繁琐。 我时不时地遇到问题，发现Internet上没有多少关于该技术使用的信息。 相反，JavaFX也可以达到相同的目的，但是它已被很好地记录和支持。

在一个项目中，需要一个用户界面，该界面既可以作为桌面应用程序运行，也可以在Web浏览器中运行。 为此选择了可伸缩矢量图形（使用Apache Batik）。

由于面临问题，Apache Batik的任职期很快结束。 但是，Apache Batik在团队中进行了讨论，探讨，甚至在建立基础结构之前就被拒绝作为解决方案。 然后搜索了其他技术，JavaFX成为赢家。 JavaFX看起来很有前途，易于使用，并且是一种新兴技术，因此，它的基础结构是在sprint中设置的，其中创建了一个外观简单的UI，然后在JavaFX上进行了进一步的开发。

新技术与项目中已实施技术的兼容性也非常重要。 就像在前面提到的项目中一样，一些挥杆组件已经到位，并且JavaFX提供了嵌入挥杆组件的功能，该功能使那些挥杆组件可重复使用并节省了一些返工。

对特定技术的支持也非常重要，因为您可能会陷入僵局并需要解决之道。 开源产品在这里得分很高，即使您对该技术没有任何支持，您也可以查看代码并进行更改。 如果它不是开源的，那么如果该技术没有足够的支持，您可能会发现自己在某些地方受阻。 对于开源技术，如果您没有内部能力，也可以找到可以为您修改和定制产品的公司。

大多数流行的开源解决方案都有非常详尽的文档记录，并且提供了多种免费和商业技术支持选项。 由于社区发展的性质，文档和说明通常是从各种角度编写的-创建了全面的信息，说明和教程。 此外，由于代码的免费提供，开放源代码项目无法隐藏使用技巧。 免费的技术支持通常以邮件列表或新闻组讨论的形式提供； 但是，经常需要一些背景研究，知识或经验。

耶稣·冈萨雷斯（M. Gonzalez-Barahona）谈到了开源技术的优势 。

“ 源代码的可用性以及对其进行修改的权利非常重要。它使软件产品可以无限地进行调整和改进。

以任何方式使用软件的权利。 这反过来有助于建立支持和定制软件的市场，这只能吸引越来越多的开发人员从事该项目。

没有哪个实体可以依赖软件的未来。 如果发起代码的小组或公司决定停止开发，则总是有可能资助另一个软件小组继续进行维护和改进，而没有法律或实际限制。

无需索取每份修改版本的费用。 尝试新技术的人们能够立即集成并采用它们，而不必担心商业或非公开许可协议的障碍。 ”

弄清自上市以来的时间及其预期的使用期限。 使用即将过时的技术毫无意义。 如今，技术飞速发展，因此，经常检查技术的竞争对手，您可能会得到一些惊喜。

迭代技术

为了介绍新技术/框架，每次采取一些小步骤总是好的。 稍微探索一下该技术，然后分析它是否适合作为解决方案，这是很好的。 然后尝试使用新技术/框架解决最小/琐碎的业务问题。 在一开始时不要完全依赖它，只需让一小部分应用程序使用该技术，看看它是否有效。

这有助于习惯技术/框架的语法和其他功能。 用这种方式做事的另一个大优点是，您无需花费时间专门用于设置基础架构来使用所有新事物。

在我的一个项目中，选择Drools 5作为解决某些问题的方法。 但是，使用Drools 5的适用性和可行性尚不明确。 除此之外，Drools 5对于团队中的所有成员都是新的。 因此，一个冲刺旨在仅消耗Drools5。一个简单的问题被认为可以在Drools的帮助下解决。 这样就可以确定Drools将在此sprint中设置为基础结构。 除此之外，团队成员将有时间阅读有关内容。

使用Drools解决一个简单的问题提供了动手实践的机会，这增强了人们对该技术的信心。

作为Drools 5的Java项目，依赖项已添加到pom中。 定义了Spring bean创建会话，并编写了一个简单的drl文件。 drl文件具有Drools特定的语法，在该语法中编写了规则。 该代码对使用会话bean传递给它的对象执行了一些规则。 冲刺之后，Drools基础架构就位，团队意识到了它的语法和其他技术。 最重要的是，有一个使用Drools 5的解决方案。因此，对技术的信心增加了。

Robert McIlree谈论了技术的迭代归纳 ：

“ 随着时间的推移，逐步引入一种新的软件技术，并获得足够的成功，从而使该技术从进入点到组织的其余部分都越来越受欢迎。 如果介绍由于某种原因而没有成功，则对组织的总体风险和成本将很低。”

在此阶段，已实施解决方案的问题不应那么重要。 主要目的是建立新技术的基础架构。 一旦项目的基础架构完全设置好，看起来足够舒适就可以进行，那么实施它的风险就会降低。

性能

一旦应用程序采用/接受了新技术并获得了预期的结果，就可以达到其功能接受标准。 但是，一旦您开始深入研究更复杂的案例并且该技术成为应用程序的一部分，那么功能卓越并不是您想要的唯一内容。 这是与性能相关的问题可能会开始困扰您的地方。

如果您从一开始就不关注新技术对性能的影响，那么现在可能会成为开销，这可能会导致丧失采用新技术的全部精力。 因此，在引入该技术时，请跟踪严重的性能下降。 如果该技术将成为瓶颈，请尝试找出并尽快将其丢弃。

冒险能力

在当前项目状态下，团队的风险承担能力可能是决定是否应引入该技术的另一个因素。 如果项目不是那么稳定，并且团队即使在当前实施的技术和其他问题下仍在挣扎，那么添加新任务来应对新技术就不合逻辑。 在此阶段引入新技术可能会对团队造成严重影响。 他们将不得不在错误的时间处理掌握新技术的额外任务。 但是，如果团队表现良好且产品稳定，则必死无疑。

Dave Nicolette撰写了有关管理和计算风险因素的文章。

“ 当提议的解决方案涉及IT组织支持的标准技术基础结构中尚未建立的技术或产品时，就会出现高感知风险和低实际风险的结合。 寻找一个机会介绍一种新技术，该技术在技术上并不难实施，但是您的公司以前从未使用过。

这将使传统的项目估算更高，而不会增加项目的实际难度。 “

相信

最后，在接受该技术后，您只需要技术中的“信任”即可。 这是个人现象。 但是，您对所接受技术的信任程度将推动您轻松使用它。 正如Bahmanziari所说，它高度依赖于个人， Tammy在《计算机信息系统杂志》上发表了有关信任的文章。

收养者的个性在信任陌生人的倾向中起着重要作用。 这种人格特征通常称为信任倾向。 有些人表现出很高的信任度，而没有任何特定的理由，而其他人表现出的信任度低，这是可以合理预期的。 ”

技术适配器必须进行本文前面提到的一些分析，以形成对技术的理解。 使用分析中收集的信息来增强您对技术的信任。 您需要信任，因为该技术尚未经过尝试和测试。 如果它是一种久经考验的技术，则无需信任，因为您已经知道它的点点滴滴。

《计算机信息系统杂志》还谈到了信任对采用技术的重要性 。

大多数信任理论家可能会同意，尽管没有人能够制定出一种在所有情况下都有用的信任定义，但对于存在信任而言，不确定性和某种程度的脆弱性都是必要的。 毕竟，毫无疑问，没有信任是必要的。 由于存在这种不确定性，因此会创建漏洞。 技术采用者在不确定的环境中运作； 因此，他们的评估必须包括对新技术和该技术提供者的看法和不完全的知识。 ”

结论

引入的技术应该能够解决业务问题。 不应根据其受欢迎程度来选择它。 如果项目处于不良状态，则不应尽早采用技术。 开发人员不应担心学习曲线，因为它会增强他们的知识。 该技术应迭代引入。 一次迭代中成功/失败应该控制下一个迭代步骤。 配对编程应在新技术上进行，以在团队中分发知识。 完全接受之前，请先留意它。 对这项技术充满信心，您将获得无与伦比的色彩。

翻译自: https://www.infoq.com/articles/agile-casestudy-paritosh/?topicPageSponsorship=c1246725-b0a7-43a6-9ef9-68102c8d48e1

敏捷中8项技术实践