软件开发（或可能从事的任何工作）中的主要问题是什么？ 当我问同事一个问题时，我得到了不同的答案：需求变化，期望不匹配，代码质量，与其他团队的互动……为我自己总结-沟通是最重要的问题之一。
在交流中，每个人都以自己的方式理解一切，对它们的解释与所讲的有所不同。 客户在他的脑海中保留着他想要转换为文字和图片的特定图像，开发人员在听到这些文字后，将其脑海中的图像转换为自己的图像。 在这个链中可以有很多链接。
为了解决此问题，人们编写了详细的ToR。 但这能解决问题吗？ 在我看来，鲍勃·马丁（Bob Martin）和马丁·福勒（Martin Fowler）以及他的同事在2001年2月撰写《敏捷清单》时也提出了同样的问题。 让我们尝试一起解决这个问题，并在敏捷宣言中体现自己。
故事
在2000年冬季，召开了一次所谓的极限编程的领导人会议，他们讨论了开发方法，结果开始提供一些Light方法。 很少有人对此感兴趣（我不想冒犯任何人），很可能他们在这个话题上开了更多玩笑。 但是，该会议的一些局外人在一年后组织了自己的会议。 一切始于鲍勃·马丁（他撰写了有关代码质量的著名书籍），并向上次会议的领导者发布了时事通讯-让我们聚在一起讨论。 其实没有什么具体的。 他们一段时间以来一直在争论地点和时间。 结果，他们于2001年2月11日聚集在犹他州的一个滑雪胜地。 开发部门的17人，包括鲍勃·马丁，马丁·福勒和其他人。 他们喝了酒，Fowler滑雪了，经过讨论，
Agif Manifest诞生了。
原则上，所有最重要的内容都可以通过一页文字从字面上传达出来，可以在
此处阅读。
但是，就像所有简短而细致的思考一样，仅通过阅读来理解它对于我个人而言并不容易。 因此，让我们详细考虑那些签署敏捷清单的人的想法。
敏捷原则
也就是说，如果不否认正确的重要性，
但是，我们更看重左边的内容。
这是一个非常重要的方面，在阅读宣言时以及工作中的每一天都必须牢记。 让我们讨论主要的清单语句。
人员和互动比流程和工具更重要
乍一看，这似乎是一个要求放弃所有Jira项目，错误跟踪器，时间记录器和其他工具以及所有已配置过程的呼吁。 可能更容易的是与同事进行口头讨论某人在做什么。 如果所有人都开心的话。 但是看起来有点乌托邦，对吧？
该原则表明，在构建任何事物的开发过程时，务必记住为什么要这么做，为谁服务以及出于什么目的。 为了流程本身而创建流程几乎没有意义。 因为工作最终将由人们（您和我）完成。 如果把所有的火花，我们所有的兴趣都替换为Yutrek中的任务或jir中的虫子，将会发生什么？ 一个组织良好的过程毫无价值，它可以在客户面前提供完整的安全性，但不能解决实际的开发问题。 官僚（正式）细节很容易导致项目人员流失。 我倾向于认为规划也是如此。 您上一次进行计划是什么时候？最终结果是至少60-70％是准确的？
我认为清单的原则听起来像这样：
人的流程，而不是人的流程
宣言如何表明我们更接近于实施这一原则？
- 积极进取的专业人员应参与该项目。
- 直接沟通是最实际和有效的。
- 最好的要求和体系结构解决方案来自自组织团队。
- 团队必须不断分析其工作并优化流程。
团队通常会发展什么？ 为客户提供产品。
有效的产品比全面的文档更重要
如果按原样解释，我认为很多人都会同意。 但是您在这里还能看到什么？ 就个人而言，我在这里看到一种可以正常工作并且能够
按时工作的产品比编写完美的代码更为重要。 这些话在很多方面都是残酷而令人恐惧的，所以我不应该这么说。 但是我的整个职业生涯（从不同的人那里学习）越来越相信这种想法-如果我选择一个在代码和体系结构方面很理想的项目，以及一个在内部看起来不是很漂亮但是对世界有益的项目，那么我将选择第二个。 是的，我将尽我所能来改善它。
在这里，您应该考虑一下。 但是，可以采取哪些措施来减少这些问题的普遍性呢？ 这样我们就不必在重构模块和开发新功能之间进行选择？
- 工作产品应尽可能多地发布。
- 有效的产品是进度的关键指标。
- 对技术卓越性和质量的持续关注增强了项目的灵活性。
- 简单和最小化是必要的。
注意技术卓越点。 保持代码良好（必要）和足够的质量，我们更容易容忍需求的变化，并因此而容忍代码的变化。
我提醒您，所有原则都不是负面的。 一个不排除另一个。 这是关于优先级的。 一切都很重要-产品，代码的质量和文档。 但是该选择什么，何时选择？ 在质量和产品之间保持一定的平衡时，在不否认质量的前提下，更容易将产品置于优先位置。
作为我生活中的一个例子，我回想起为俄罗斯客户开展的银行项目。 这项工作是在分析人员的参与下进行的，并且严格按照传统知识的数量进行。 经理每六个月去一次客户总部，并展示工作结果。 很容易猜到，通常，结果与客户的期望明显不同。 客户的会计最初看到了新系统，并大体上知道该系统正在创建中，因此他感到非常恐惧-在新系统中，没有什么比他通常的工作流程更糟糕的了。 这将我们带入下一个主题。
与客户的合作比谈判合同条款更重要
您必须非常小心此声明。 再一次，请记住，声明的右边没有被拒绝。 相反，我们说合同很重要。 当我们权衡合同与合作的条件，正确的长期合作伙伴关系时，这种关系将变得更加重要。 不否认第二。 我之所以如此关注，是因为我们生活在现实世界中，有时我们必须与非常不同的客户一起工作。 在某些情况下，客户出于自己的自私目的可以利用天真的优势，并以牺牲合同为代价击败了开发人员无法接受的条件。
但是，如果我们
在真空中谈论某个抽象的好客户，那么保持长期合作关系（这将导致新项目）更为重要。
在整个项目中如何实现对期望的理解和遵守？
- 在整个项目中，开发人员和定制业务代表必须每天协同工作。
- 直接沟通是最实际和有效的。
同时，当然不应忘记为了自己的安全而确认协议。 顺便说一句（幸运的是，很少有）客户通常在协议签订后拒绝付款。
无论客户是谁，开发人员的活动总是有用的。
我还要自己补充说，这应该同时起作用。
这导致我们在逻辑上得以延续-工作和计划的变化。 很少有人喜欢进行更改，如果您考虑一下，这就是人的本性。 任何系统都在争取平衡和不变性的某个点。 但是，发展总是与运动和变化联系在一起。
进行变更的准备比遵循原始计划更为重要。
这样的计划的存在不会被拒绝。 相反，该计划很重要。 但是，如果在某个时候我们意识到此计划在当前环境中不再有效，那么准备进行更改就显得尤为重要。
我的同事们的一个例子是对一个独联体国家进行税收检查的项目。 从本质上讲，国家项目，传统知识，立法，没有任何关于敏捷的话题。 但是，当客户所在国家/地区的州更改其税收法规时，该团队必须表现出灵活性，以使该项目完全没有计划中的意义。 我不得不更改技术规格并重做几乎完成的项目，以便客户可以使用它。 否则，除非有这样的收益，否则工作将毫无意义。
也许这不是最能说明问题的例子，因为这些变化是由外部因素引起的。 另一方面，再次由于外部因素，客户可能会发现需求不断变化。 否则，他将不会获得竞争优势。
这一切对我来说都是一个痛苦的话题。 但是，如果我们将一个项目进行了整整一年，然后一年后客户说-好吧，您太棒了，现在我们将所有这些都保存在存档中，我们将不再使用它，而是开始一个新项目。 我对此很痛苦，我也有类似的经历。 但是真的-发生了什么？ 完成的工作帮助客户了解所选路径不正确。 还是无效。 为了获得竞争优势，您需要以不同的方式工作，做另一个项目。 在我们的帮助下，他获得了这一知识。
我们工作的哪些方面将有助于平滑这些角落并减少灵活性的恐惧感？
- 定期和早期的软件交付。
- 即使在后期阶段，也欢迎进行更改。
- 变化有助于为客户提供竞争优势。
同时，我们生活在现实世界中，与真实的人生活在一起，在这些世界中，不应包括绝对的判断力。 是的，当更改为最终产品带来附加值时，欢迎进行更改。 但是保持平衡很重要。 如果我们不断做出改变，我们将永远不会发布产品。 因此，在某个时候您应该说-停止，我们发布产品，检查实践中的所有内容，然后开始制作第二版，其中将包含这些更改。 每次与客户澄清-他在此变化中看到的价值。
我最近在Facebook上阅读了该词组，
如果您不以自己的产品为耻，那么您进入市场为时已晚
相当准确地反映了上述实质。 我们需要寻找一个平衡点，在这个平衡点上，该产品将为更改做好足够的准备以用于下一个版本，并且在该平衡点上，我们尚未开始在微小的更改上投入过多的精力。
而不是总结
敏捷宣言的创建者没有规定任何规则，反之亦然。 但是它们在我们的工作中提出了重要的问题-人员，开发人员和客户之间的互动以及为变革做好准备的准备。 这些原则本质上很重要。 毫无疑问，文件，合同，流程和计划的重要性，人与人之间的互动，为有价值的变更做好准备并为世界带来有用的东西变得更加重要。