问自己以下问题：
- 出色的高尔夫俱乐部会让您成为出色的高尔夫球手吗？
- 一级方程式赛车是否会让您成为专业的车手？
- 出色的开发工具会使您成为专家开发人员吗？
除非您有妄想症 ，否则您将知道所有这些问题的答案是否定的 。 使用正确的工具可以大大提高专家的表现，但是如果使用一个好的工具，则初学者的表现不会更好。
无论诸如Version On e和JIRA之类的启用敏捷的工具如何发展，使用这两种工具都不会使您变得敏捷，除非您了解使敏捷开发工作的流程。
我最近在一家大型零售商处完成了一项合同，他们在其中使用JIRA进行企业集成项目。 听到他们使用诸如sprint和back log之类的术语很有趣； 有趣的是，因为没有定期的冲刺周期 ，并且待办事项仅是JIRA系统中的票证 。 JIRA支持用户故事（史诗和故事）的概念，但是没有正确使用它们。
问题不在于JIRA； 问题在于他们认为自己的过程是敏捷的，因为JIRA支持敏捷开发。
敏捷是关于遵循
敏捷软件开发不是非正式的 。 与传统的瀑布式开发相比，敏捷开发的正式实践更少，因此需要遵循那些正式实践（请参阅敏捷不是非正式的 ）。 敏捷开发是轻量级的，因为它避免了生产工作代码所不必要的活动，而不是因为它避免了严格和形式化。
Scrum和XP的一些实现可以工作并且敏捷，因为它们实现了良好的开发过程。 但是，也有许多组织错误地实施了Scrum和XP（请参阅敏捷隐藏开发罪恶吗？ ）
敏捷并不意味着您拥有固定的开发周期 ，但您绝对可以成功。 所需要的是将项目分为多个循环，在这些循环中进行开发。
敏捷并没有决定如何保留需求（待办事项或故事），但是您必须具有有效的需求流程。 如果您的需求流程中断了，那么您将永远无法获得敏捷的成功。
敏捷宣言将对发展至关重要的事情放在首位：
- 个人与互动
- 工作产品
- 客户合作
- 应对变化
但是，敏捷不会拒绝右侧栏中的内容，除非它们妨碍了上述因素：
- 流程和工具
- 综合文件
- 合同谈判
- 遵循计划
特别要注意的是，不要陷入流程和工具中 ，例如Version One和JIRA。 如果您了解敏捷开发的核心原理，那么这些工具可以为您提供帮助。 如果您不这样做，那么这些工具将使您的情况比以前更糟。 不幸的是，敏捷开发的普及使每个工具制造商都争先恐后地改变其产品以支持敏捷。
工具将永远不会提取或综合质量要求并建立质量代码。 正确理解项目的唯一方法是将优先级放在个人和交互上。 人员和沟通是解决问题的唯一途径-工具是次要问题。
个人和互动流程和工具
敏捷开发并不能决定固定的开发周期，但是它确实要求任何周期都必须以有效的产品来完成。 重点始终必须是生产代码，这就是为什么定期演示工作代码至关重要。
为此，无论您有待办事项还是用户案例，您都需要了解您的要求。 在许多情况下，可以使用正确编写的用例。 无论哪种要求都必须正确且一致，它们必须满足客户的需求，即避免隐藏过多的文档 。
工作产品超过过多的文档
除非您与客户建立了牢固的合作关系，否则无法正确地提出要求。 客户经常没有正确地获得初始需求，并且开发常常不理解它们。 专注于客户协作是相互理解的关键。
这是大多数项目失败的地方，因为双方都有将重点放在合同谈判上的倾向。 合同是必要的，但是专注于限制责任和保护自己不会产生导致软件正常运行的关系。
客户合作OVER合同谈判
您必须了解，当需求或技术不确定性导致您由于需要对变更做出响应而改变开发方向时， 遵循计划是没有意义的。
这意味着要在所有要求之前进行可靠的估算，而不仅是要承受来自高层管理人员的压力（请参阅为何高级管理人员宣布的截止日期导致灾难 ）。 这通常意味着在发现新的需求或技术难题迫使解决方案时，要在项目的预计结束时增加时间 。 不幸的是，在这种情况下，许多项目没有重新调整预计的结束日期，这导致了死亡行军项目（请参阅“ 死亡进行曲演算” ）。
根据计划响应OVER
敏捷开发是通过了解敏捷宣言的原理来生产高质量的软件。 敏捷开发并不是仅仅因为使用支持敏捷开发的工具而欺骗自己。 您可以仅使用电子表格来实施非常可靠的轻量级敏捷解决方案。
首先专注于敏捷，然后去寻找工具
与敏捷开发兼容的其他东西：
翻译自: https://www.javacodegeeks.com/2014/05/agile-tools-do-not-make-you-agile.html
扫一扫
796
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
