从明天开始，我们开始以新的方式生活。 我们将拥有Scrum，并且将拥有幸福。 完全民主：没有老板，团队决定做什么，取消官僚主义，主要是为客户做好事。
一位培训师来教我们基本知识。 他谈到即将取得的成功，效率和对客户的关注，让客户参与开发过程所具有的前所未有的灵活性和重要性，以及在莫斯科大剧院进行耕作的太空飞船。
好吧好吧 等一下
我们开始一个新项目。 好吧，感谢上帝！
然后我已经坐在Legacy代码上方，浑身是青苔。 我的力量不再，我无法应付这个伟大的面食怪物。 我以某种方式尝试移动登录表单中的按钮，因此邮件模块出现错误。 想想连接在哪里...
他们向我们介绍了一位新员工，我们将有一个产品负责人，或者用俄语来说是一个客户代表。 我叫丽塔。 有魅力的女人。 喜欢说话。
问她一个简单的问题，所以她开始演讲了半个小时。 你看着她，想：“呃，你不懂该死的东西！”
五分钟后，您开始怀疑：“不，就像是在说。”
最后，您意识到自己尚未收到问题的答案。 所以你离开。
最主要的是无法中断它。 她试图引导语言流向正确的方向，但在那里她知道自己被水淹没了，并再次讲述了船只和莫斯科大剧院。
我们已经不敢问她一个简单的问题。 您可以获得答案，但您可能淹没在言语海洋中。
是的，官僚机构的确减少了。 因为每个人对文档的总体评价都很高。 现在，信息主要通过口耳相传。 当然，我了解一切，我们非常敏捷，但程度不尽相同...
给定任务：在网关中开发客户端接收数据以显示图形的能力。 您需要转到服务，获取原始数据，重新计数并将其提供给客户端。 没有规格说明什么以及如何计数-没有人知道。 只有图表的名称。 好吧，我想知道我应该怎么做？
好的，我在旧项目的某个地方寻找了类似的东西，做了一个模式。 不能确定这是必需的，不是。 奇怪，但没人真正在乎。 最主要的是，我们在演示集会上成功引入了新功能。
我今天来上班，女孩测试人员包围了我们的Scrum大师Kolya，他们要求向他们解释新功能的工作原理。 Kolya用锡的眼睛看着监视器，喃喃地谈论了一些有关型号和不断变化的要求的信息。
您可以理解Kolya：您在一个月前进行了更改，很难记住确切的内容，没有文档。 但是这些女孩不是糖：他们被指示去测试一些东西，我不知道是什么。
半小时后，我在走廊上遇到了他们：科里亚（Kollya）走路，女孩们在跟着他，所有人都c咕着：“新型号...旧型号...客户要求...”。
穷人...
收到请求进行审查的请求。 导出图形时出错：高度和宽度的比例与原始比例不同。 奇怪，因为我曾经解决了这个问题并照顾了所有比例……问题以原始方式解决：一位同事将身高简单地乘以1.25。
我问他：
-这个系数是什么意思？
他说：“这就是我捡起的。” 现在一切都会好起来的。
什么时候 他拾起了...导出其他图表将会发生什么？ 他们开始了解，事实证明，您只需要稍微更改通话顺序即可。 在极少数情况下，会使用画布设置，然后需要重新计算比例。
给人的印象是，有时候人们以任何方式报告他们的工作很重要，而最终结果并没有真正打扰他们...
今天，丽塔说她决定在显示文档列表时使用无限滚动。 我试图说服她，REST服务中的情况正在不断变化：一些用户添加文档，其他用户删除文档。 结果，多余的元素会出现在表单中，或者它们会消失，因此最好使用旧的年龄。 有人告诉我，这种情况很少见，无休止的滚动时尚又性感，用户会很高兴的。
你满意吗 嗯...如果发现列表不符合当前状态，我会很沮丧...
我不明白如何在没有基础的情况下用狗屎和棍棒建造建筑物，同时从四个角度同时开始。 有时我认为，如果按照与现代软件相同的方式来设计飞机，汽船和摩天大楼，那么飞机会立即掉落，船只会颠倒过来，而我们的城市将会一片废墟。 显然，我们的错误价格要低得多。 最后，我们不会创建医疗或太空软件。 但是我们的软件很复杂，它使用许多微服务。 有必要注意细节的初步研究！
我们不建造飞机很好...
他调查了附近的部门，从门槛开始感到有些不对劲。 每个人都坐在那里，疯狂地敲敲键盘，空气中总有一种不幸的感觉。
突然，他们的Scrum主管Vitya跳了起来，如何向某人尖叫：
-你在给我写什么！ 口头说出来！
然后他们突破了。 一下子变得头晕目眩。 口头 喧闹声异常高涨。
我站了一分钟，咳嗽了，所有人都沉默了下来，凝视着我。 我突然感到不舒服。
维克多说：
-您更改了服务的授权？
我回答，“改变了。” 现在，没有权限的用户无法读取资源。 有必要使用其他方式。
-您更改了，-他说，-现在该应用程序已停止为我们工作。
他沉默了一阵子，并补充说：
-您做对了所有事情，这是我们的能力。 但是，您知道我们需要在三个小时后推出该版本，因此我们无法如此迅速地修复错误。
我想告诉他们：“好吧，地狱，您从未进行过测试，因为一周已经过去了！”，但是看着他们的脸，转过身去进行服务的回滚。
酋长今天聚集我们说：
-我们应该有史诗。 我们想引入机器学习来定制搜索结果。
人们当然对含义以及对问题的描述感兴趣。
-尚无完整描述，我将为您提供链接。 现在想想，-答案。 和离开。
然后我通过他的链接查看了该页面：标题和两个段落。 如果不清楚要考虑什么，您认为应该如何订购？
他们发生了什么事，因为有技术人员，他们来自简单的开发人员，而现在好像他们已退化为客户。 我在某处听说人工智能既时尚又酷，让我们开始一部史诗般的影片。 既不是具体的任务，也不是确切的规格说明，所有的东西都是具有剧院的飞船和宇宙飞船……
我今天在走廊遇见Vitya，问：
“好吧，您发现错误了吗？” 一个月过去了。 有必要恢复服务中的授权，否则我们将陷入困境。
Vitya看着别处，说道：
-否，尚未找到。 根本没有足够的时间...
好吧，你来了。 一个月以来，人们无法找到使用错误端点的地方。 显然，他们已经放弃了这一点，从事时事。 很奇怪，因为该程序实际上使用了不正确的数据...
是的，在这里，我们的新门户已变成一团意大利面，现在已经不可能找到目的了。 很快，我们设法做到了！
我试图说服同事与我的上司讨论当前的状况。 从我的角度来看，该项目处于令人沮丧的状态：不同的团队，解决他们的任务，进行增加混乱的编辑，熵在增加。 每次，解决问题变得越来越复杂。
伙计们同意我的观点，但是我的举措很酷。 他们可以理解：每个人都有当前的任务，在冲刺阶段必须解决。 这不取决于哲学，必须完成事情...
我承认：我发明了这本日记。 所有字符都是虚构的，巧合是随机的。 这只是个玩笑。
有时，管理层对敏捷的理解有些粗俗：略微概述任务就足够了，一个好的团队将独自应对所有架构和概念问题。 尽管使用敏捷并不意味着完全拒绝文档，但他们常常忘记了需要详尽的文档。
但是，我不想谈论敏捷或开发技术。 我想推测一下我们创建的软件的质量以及错误的决策如何破坏该软件。
利益冲突
您是开发人员。 您正在从事的项目或项目的一部分是您最喜欢的孩子。 您创建并培育它，希望您拥有完美的创作。 这样您的同事和用户就可以说：“是的，这很酷！”。
但是您为雇用您的公司工作。 企业对您的抱负不感兴趣。 企业的主要目标是利润，这是正确的。 在这里，您与公司同时工作，因为您想要尽可能多的人使用您的项目？
但是由于某种原因，企业可能会做出违反项目协调性的决策。 假设您需要很快收紧东西，否则客户会离开。 没有时间正确解决问题。
怎么办
最有可能的是，您将不得不休息一下，希望以后可以移除当前的拐杖...
但是，并非所有事情都如此悲伤。 从长远来看，除非您是自己的敌人，否则业务是您追求质量的盟友。
尽管有必要采用这样一种方法，使得有时可以忽略对细节和分析的仔细阐述，因为快速而廉价的客户满意度是最重要的。 在这种情况下能否成功？
成功有可能吗？
矛盾的是，至少在第一阶段，此类产品很可能在商业上获得成功。 客户当然会因为系统中的许多缺点和不一致性而感到烦恼，但是总的来说，产品可以解决他们的问题。
客户对支持水平感到满意：他们关注自己的需求并尝试快速满足新的需求。 的确，随着时间的流逝，其中一些人注意到系统的行为变得越来越不一致和不可预测，界面变得越来越复杂，了解内部发生的事情，如何正确解决特定问题，响应时间出现问题等变得越来越困难。 但这是逐渐发生的，起初是潜移默化的。
没有人怀疑这个项目注定要失败。 很快，他将不可避免地因匆忙附上的所有扩展的严重性而崩溃。
产品的内部和谐与消费者品质之间如何联系？ 经常发生的情况是，开发人员对系统的内部状态始终感到恐惧，而客户似乎很满意。 但是，一架丑陋的飞机会好吗？ 产品的内在和谐是否不应该反映在消费者的品质上？
经常将淫秽的内部隐藏在美丽的外表之下已经不是什么秘密了，这不仅适用于小型公司，而且适用于软件行业的巨头。 这只是一个
例子 。
Monster公司有能力聘请成千上万的程序员来支持他们的产品在过去几十年中已经变成的巨大的意大利面条菜，但是对于小型公司来说，这是一种杀手way。 顺便说一句，即使对于怪物来说，低质量的代码也无法避免，并成倍增加了每个新功能的开发和实施时间，更昂贵的过程以及不断降低的支持质量。
更重要的是：产品质量或销售技能？
las，高质量的产品并不能保证成功。
在实践中，我有一个案例需要将一个在俄罗斯行之有效的高度专业化的程序推广到欧洲市场。 该程序使用自己的数据格式，当时转换可用的客户数据并不是特别困难。 如果我们成功签订合同，我们将在欧洲成为垄断者一段时间。 似乎一切都在我们这边：市场需求很大，到目前为止，没有人能提供完整且真正有效的产品，除了我们之外，该程序已经在俄罗斯工作了数百个工作，俄罗斯客户对该产品做出了积极回应。
因此，我们成功了吗？ las，不。 一家欧洲公司赢得了招标，该公司已经与其他地区的客户合作。 那时他们只是在我们已经走过的道路的起点，但是设法击败了我们。 不幸的是，我们在促销和销售方面没有好的专家，我们无法说服人们做出有利于我们公司的选择。 然后，过了一段时间，看到我们在其新产品中组织用户界面方面取得的成就令人非常失望...
错误的决定
高质量的产品是战略目标，明智的业务将永远站在开发者的一边，追求卓越。 但是保持产品内部的和谐并不容易。 随着产品的开发，新的要求到了我们，这可能会破坏概念的原始和谐。 在这种情况下做出的决定对产品的未来命运起决定性作用。
没有人可以避免错误的决定。 如果在设计阶段做出战略决策，随着时间的流逝，很明显这是错误的，那么这将导致项目的失败。 但是，当添加新功能时，在开发过程中常常会做出错误的决定。 首先，这取决于决策的全局性，即决策对整个系统的影响程度，其次，取决于不良决策的数量。 当不良决定的数量及其影响程度超过某个阈值时，就会开始长期痛苦的痛苦。
我想与大家分享一些根据我的经验做出的错误决策的例子。 当然，这些例子绝不要求学术广度和系统化。
宽松的规则
在我们看来，有时为了方便用户，规则应该灵活。
例如，您的系统可以处理用户创建的不同类型的层次结构。 您决定对于其中一种类型，节点密钥仅在级别中而不是在整个层次结构中唯一。 当用户按级别加载层次结构时，这似乎很方便。
结果：现在，代码中的每个地方的程序员都必须准备复合键，这通常会导致错误。 如果用户可以通过密钥访问站点，这也将使他们头疼。
考虑更严格的规则并要求整个层次结构中键的唯一性可能是值得的。 这将使开发人员和用户都受益。
违反规则
您具有用户创建的对象的复杂层次结构。 每个对象都包含Name属性（即键）和Title（具有任意文本）。 名称有一组正式规则，例如，名称不得包含空格或特殊字符。 在某些时候，任务是自动从另一种类型生成一种类型的对象。 名称应基于标题，并且是可识别的。 您决定违反规则，并使用“标题”作为名称：在您看来，这对用户而言将是最方便的。
为系统中意外发生的问题做好准备。
复杂度设定
您输入仅在某些条件下才有效的设置。 当某些安装在包含其他安装的条件下运行时，这是很常见的情况。 但是，如果您具有复杂的态度层次结构，其中一些态度在其他情况下会起作用，而这些情况又是有条件的，那么这就是通往混乱的道路。 经验表明，在这种情况下，没有人愿意预测特定安装的更改将如何影响行为：用户和开发人员都不会。 设置系统应清晰，尽可能明显，并经过深思熟虑。 您应努力减少某些设置对其他设置的依赖性。
缺乏对问题的分析
您的系统允许用户基于DSL创建报告。 首先决定DSL包含报告的所有属性。 一段时间后，其中一个客户端要求您添加单独存储部分安装的功能-这对于解决客户端的一些内部问题是必需的。 在没有先分析问题的情况下在Jira的“添加外部设置”中启动任务是一个错误。 首先，有必要回答这个问题：为什么根本需要它？ 事实证明，客户端只想为某些用户隐藏部分设置。 也许您应该考虑在这些部分的授权下将DSL分成几个部分？ 这个决定不是那么快，但也许在战略上是正确的。
政治决定
有时出于组织原因做出决策。 例如，某些资源存储在为此专门设计的微服务中。 需要几种类似的资源类型。 一个团队参与了该服务，而其他团队则需要新的资源。 为了分担责任，决定不向原始服务添加新类型，而是向其他团队运行的服务添加新类型。
问题在于该服务不仅存储了数据，而且还提供了授权。 现在，您需要以某种方式照顾重用代码。 但这不是主要的事情。 最主要的是，现在不清楚应该使用哪个服务来获取必要的数据。
建立系统的内部证据是出于组织或政治动机而牺牲的。结论
作为开发人员，我想为自己的工作成果感到自豪。对我来说，项目的内在美，优雅与和谐非常重要。但是需求同样重要。我不想为购物篮工作，我希望有尽可能多的人使用该产品并感到满意。我知道有时候您必须付出一些代价，破坏内在的和谐，以取悦个别客户的利益。但是我坚信，美丽的外表背后不应有任何耻辱，丑陋的室内装饰迟早会外出，这与概念的外部混乱或对客户问题的响应时间不断增加无关紧要。产品的美观和和谐至关重要。是的，有时我们会为了业务利益而被迫妥协，并准备为了某些客户的利益而模糊一些方法的清晰度，特别是如果它是一个非常重要的客户，但这是一个滑坡。我不得不不止一次地观察项目的逐渐灭绝和失败，那时人们没有费心去仔细研究细节并漫不经心地引入了新功能，没有在意产品中的不一致之处，也没有关注模块之间新的和不必要的连接的出现。纠正最简单的错误变得越来越困难时，这总是会引起混乱，因为无法确定这种纠正不会对系统中完全无关的组件产生意外的影响。我希望您的项目长寿！