我们敏捷了吗？

我读过某个地方，许多软件团队认为他们之所以敏捷，是因为他们从事Daily Scrums。 现在，我不喜欢宗教信仰，我当然不相信您必须遵循“ 十项特定实践 ”的某些清单才能“变得敏捷”。 但是我确实认为，有时公司会有点急于跳上敏捷的潮流，而在我们不知道这一点之前，我们因敏捷项目失败的恐怖故事而备受关注。 但是他们真的很敏捷吗？ 还是他们只是在做每日Scrums？

如果您的公司试图变得敏捷，该怎么办？ 您如何确保–
即使您没有遵循某些教科书的完美定义，实际上您在做足够的正确事情来获得敏捷的收益？

专注于意图，而不是实践

敏捷是一组价值观（请参阅： 敏捷宣言 ）， 而不是实践。 当然，我们在软件中拥有所有这些超级聪明的人，因此我们不断发现新方法来帮助我们实现这些价值。 但是，这是事实：

这些做法是帮助我们的工具，并不是使我们敏捷的原因 。

这意味着，您不能随便选出方便的敏捷操作列表，并挑选出看起来很简单的1或2个（“ 嘿，我敢打赌我们甚至可以处理这些Daily Scrum事情！哦，让我们停下来也是Up Front Design –无论如何我们也不是很擅长设计”），并认为它将使您敏捷。

相反，我们需要专注于敏捷的意图 ，这在《敏捷宣言》背后的原则中进行了定义。 像：

我们的首要任务是通过尽早并持续交付有价值的软件来满足客户。

考虑一下您最希望通过敏捷实现的目标 ，然后选择一些可以帮助您实现敏捷的实践。 这很有用，因为如果您知道要实现的目标，则可以评估进度。

如果您只是想“变得敏捷”，那就有点模糊了。 我们敏捷了吗？ 当然，为什么不呢！

那么，如何衡量自己是否坚持所选择的实践的敏捷意图呢？ 我喜欢将精益视为敏捷的基础-解释其原理的原理。 因此，我发现精益提供了一个很好的指南针，可以帮助我们评估我们选择的实践是否对我们有帮助……或使我们误入歧途。

精益软件开发的7条原则

（改编自Mary＆Tom Poppendieck的《 实施精益软件开发》 ）

以下问题不仅可以（而且应该）应用于您选择的新敏捷实践，还可以应用于您团队遵循的现有实践。 请记住，变得更加敏捷不仅意味着要采用新的敏捷实践，而且还要消除那些使您退缩的旧方法。

1. 消除浪费 – “无所不包，增值”。 您能否阐明您的实践为企业或团队增加的价值？ 奖金问题：这是您的团队现在可以为实现这一价值而采取的最佳实践吗？ 仅仅因为实践会增加价值，并不意味着它是您特定团队创业的正确地方。

例如，每日Scrum旨在帮助团队。 如果团队发现他们浪费时间，那应该是一个危险信号。 也许每日Scrum的运行不正确（提示：它们不是状态会议），所以您需要从学习或辅导开始。 或者，您的项目可能尚未实现每日Scrum 支持的Scrum的其他部分（具有共同目标的团队，带有积压的sprint，“完成”的定义） –因此，您需要从这些开始。

在解决这些问题之前，请先问问自己，《每日Scrums》是否真的有价值？ 还是只是浪费？

»请参阅Martin Fowler的“不仅仅是站起来：每日站立会议的模式以正确运行每日Scrum”。
»有关每日Scrum支持的Scrum构建块，请参阅Mike Cohn的Scrum概述 。

2. 建立质量 – 您最终无法测试质量。 您的实践是否有助于确保团队在第一时间就能构建功能？ 还是通过在开发人员“完成”后确定问题来进行返工？

验收测试驱动开发，例如，抓住客户的需求为可执行的测试，团队可以使用，因为他们建立他们来验证功能。 在“完成”的定义中进行探索性测试意味着可以实时识别问题，以便在进行下一个任务之前可以进行纠正。

或者，让开发人员将其代码移交给测试人员进行验证，以便开发人员可以移至下一个功能，从而导致返工并产生越来越多的错误，因为测试人员会发现开发人员认为已完成工作的错误。

»查看测试人员在哪里敏捷？

3. 创建知识 – “软件开发是一个知识创造过程。” 您的实践是否鼓励系统学习，使团队保持进度并做出正确的决定？ 它是否包括团队快速响应这一新知识的机制？

许多敏捷实践旨在为团队提供经常和定期的反馈，以供他们学习。 这包括在每次冲刺结束时将产品演示给客户，以获取客户的反馈，并定期进行回顾以获取团队的反馈。 此外，可以使用TDD和持续集成实践来运行自动测试，以提供有关软件完整性的快速反馈。

当然，如果没有人检查持续集成测试的结果，或者由于回顾而没有做出任何更改，那么它显然无法满足其意图，因此无法提供价值（请参阅原则1）。

4. 延后承诺 –因为软件是一个创造知识的过程，所以我们建立的越多，我们就越了解。 做出决定的最佳时间是“及时” 。 您的做法是否可以使您推迟决策或澄清细节，直到最后一个负责任的时刻？ 还是有压力让事情尽早解决？

例如，用户故事让我们捕捉到我们想要实现的功能，同时推迟了如何实现它们的细节，直到我们真正准备建立他们。 准备就绪后，我们可能会构建一些应用程序，以便更清楚地了解新功能的外观。 另外，Big Up Front Design会充实所有架构细节，并预先构建它们（因为我们知道我们将需要它们），这通常会导致我们第一次编写应用程序代码以使用该体系结构并发现我们真正需要的东西时会进行返工从中。

5. 快速交付 - “速度就是没有浪费。” 最有趣的是，Poppendiecks将“快速”等同于“质量”。 这并不是要尽快将某些东西一起黑客入侵。 他们说：

“有两种方法可以达到高质量。 您可以放慢脚步并保持谨慎，也可以培养可以持续改进流程，在产品中融入质量并开发出能够比竞争对手更快，多次可靠地响应客户的能力的人员。”

我对你们其他人一无所知，但是第二种方式对我来说听起来更有趣。 所以……我认为这给了我们一些有关实践的问题：

• 它是否使团队能够反复向其客户快速交付工作软件？ （不浪费！）
• 它会提高内部质量，以使团队随着代码库的增长而保持其快速发展的步伐吗？
• 它是否允许团队做他们认为需要做的事情才能有效地响应客户？

6。 尊重人 – Mary Poppendieck在她的论文《精益思维原理》中说：

“有时人们认为，良好的软件工程的好处是允许低技能的程序员
编写代码，同时由一些高技能的建筑师和设计师进行批判性思考。 考虑到这一点，
项目通常分为需求收集，分析，设计，编码，测试等，
大概每个步骤都需要降低技能。 每个步骤都要制定一个“标准流程”，以便
例如，低技能的程序员只需遵循该过程即可将设计转换为代码。

这种思维……是精益思维的对立面，使开发人员的技能贬值 。

以增值人员为中心意味着通过培训和学徒制来提高开发人员的技能。 这意味着组建团队设计自己的流程并解决完整的问题。 这意味着存在员工团队和管理人员来支持开发人员，而不是告诉他们该怎么做。”

这是一个很难抓住的问题，因为有很多感觉却没有看到，但是我认为我们仍然可以在评估我们的实践时收集一些好的问题来考虑：

• 是否创建能够设计自己的流程并解决完整问题的团队？ （或者是否按角色分解事物并声明只有某些人可以执行某些任务）？
• 是否会将责任和决策推到最低水平？ （或者它告诉人们如何工作？）
• 它是否为人们提供了有效的培训，资源和支持？
• 它是否会激发人们对做工的自豪感-建立敬业，有思想的团队成员并不断提高？

按照Poppendiecks的说法，如果您执行除此原则以外的所有原则，您将“仅收获潜在优势的影子”。 但是，如果仅执行此原则，“您将在组织中定位人员以发现并实施其余的精益原则。”

7. 优化整体 -当我们对整体的一个子集进行优化时，我们几乎总是最终对整体进行次优化 。 您的实践会奖励提供实际业务价值的人员吗？ 还是奖励他们中间的过程？

例如，某些项目奖励开发人员代码行，或奖励测试人员发现＃错误。 但是，更多的代码行意味着要维护的代码更多，因此实际上会减慢功能的总体交付速度 。 同样，更多错误显然与组织提供高质量软件的目标背道而驰。 这些类型的度量往往是团队的结果，这些团队被构造为仅提供价值链的一部分（例如，编码或测试），因此可以度量这些团队的输出并奖励那些未充分优化整体交付的事物。 或者，包含提供所需业务价值所需的所有成员/技能的跨职能功能团队不仅可以优化开发和交付每个功能的过程，还可以在这个方面进行衡量和奖励。

您在项目中遵循的做法又如何呢？ 他们是否抓住了敏捷的意图？

参考： 我们还敏捷吗？ 来自The Hacker Chick Blog博客的JCG合作伙伴 Abby Fichtner。

翻译自: https://www.javacodegeeks.com/2013/05/are-we-agile-yet.html