敏捷分析。 神话与现实

我介绍

展位必须移动！ 没有季节，所以几个人不愿参拜。
现在与厕所，然后与海滩小屋混淆...
（x / f国家捕鱼的特点）

年底，总结，填写调查问卷和其他IT工作人员的节前活动。 在无数次我关注了IT公司的最终调查表时，这些调查表旨在确定产品开发方法的趋势。 每当您回答诸如“您仍然使用瀑布方法（瀑布模型），或者您仍然（像所有高级人类一样）练习敏捷（灵活的方法论）之类的问题时，都会有种把戏的感觉。” 当您开始从该民意调查的作者那里了解到他对敏捷的理解时，他的解释在某种程度上与宣言（敏捷宣言）的轮廓不太吻合。 他确实是第一次真正考虑许多原则，而这些原则直接使他处于停滞状态。 但是经过一番混乱之后，我们使用了重型火炮并用钢筋混凝土证实了我们的立场：“我们不是在瀑布上工作，所以敏捷。”

“灵活的方法论”这一论点听起来是如此疯狂，以至于许多人试图将任何对他们最有利的东西都挤进去。 逐渐地，它成为一种时尚的屏幕，它可以覆盖制造IT产品的过程中的各种缺陷甚至草率，同时似乎又是一种潮流。 就像我们不是那样-而是这样的技术。

让我们在一起，再次就“灵活方法论”这一主题进行“罢工与分析”，尝试理清货架上的主要人工制品和原则，并从该概念中将最初定义的神圣含义与各个过失的民粹主义者将其转化成的东西分开。 我们还将敏捷方法与其他方法进行比较，以更准确地了解将它们分开的线，反之亦然-将它们结合起来。 同时，让我们尝试找出哪些地方最适合使用敏捷原则，哪些地方不完全适合？

II软件产品开发技术出现的背景

历史就像肉酱：最好不要凝视它的烹饪方式。
阿尔多斯·赫x黎

为了客观起见，让我们进入历史，感受一下各种环境，这些环境构成了开发包括Flexible在内的软件产品的各种原理和方法成熟的基础。

1.关于瀑布的神话与现实

正如导言中已经提到的那样，敏捷（1）的对抗性（牺牲品）被选为瀑布技术，它的纯净形式在上个世纪，即打孔卡和磁带驱动器时很重要，并在W.W. Royce（罗伊斯（WW Royce），出版于1970年。

毫无疑问，这样的比较有助于任何其他方法与之相比看起来新颖而创新。 一些发言者出于更大的信念，提出了瀑布模型，而不是作为迭代，而是作为一个连续的阶段的一次性整体工作流：需求分析，设计，实现，测试，集成和支持。 在文章中观察到的直到阿贾伊尔时期为止一直提到的关于开发方法的短语使我印象深刻： 为此，我们遵循了以下链条：想法→职权范围→设计→编程→测试→发布。” 对不起，Royce在他的方法中使用了迭代开发模型。 以愤世嫉俗的方式简化想法已不再符合道德规范，尤其是考虑到Waterfall和Agile之间没有真空，而是一条相当长的进化链。

尽管是公平的，但我必须承认，关于瀑布的大多数说法通常与事实相距不远。 如果团队在某个阶段意识到结果不符合预期，那么他们要么“完成”不正确的产品，要么将大部分工作都投入了篮筐，并且几乎从一开始就开始了这一过程，实际上是在创造新产品。 为什么尽管今天这种方法的标准有些荒谬，但该技术长期以来一直是软件开发领域的流行旗舰？

为了理解这种现象，我们将陷入当时的计算中心（CC）的氛围。 让我提醒您，在那个遥远的时代，从开发人员的设计到执行计算机的道路漫长而棘手。 他浏览了已经被人们遗忘的数据准备设备，这些设备对打孔的卡片进行机械打孔，并被亲切地称为“男管家”。 此操作不是由开发人员自己执行，而是由经过专门培训的人员执行。 考虑到计算机的可操作性，按优先顺序收到了珍贵的穿孔纸板箱，将这些打孔卡放入特殊的设备（再次由受过专门培训的人员）中，可以读取代码，然后他才有机会被处理器执行。 但是，如果在读取过程中卡座中的一张打孔卡被卡住，则应重复此步骤以再次读取整个卡座。 上帝禁止，代码中出现了错误，有必要再次借助“ barmaley”，打断部分打孔的卡，并且在不将其与甲板上的位置混淆的情况下，从头开始再次重复整个过程。 有了这样的魅力，当时的程序员的工作一直无休止。 自然，采用这种方法在开发产品的实施过程中，需求的快速变化是不可能的。 所有当时的团队都对正在开发的产品提出高质量的要求，并严格控制生产过程。

2.如果不是瀑布怎么办？

但是时间过去了，一切都改变了。 个人计算机逐渐成为数字世界的胶囊，取代了后院里巨大的嘎嘎作响的怪物。 处理器每单位时间执行的操作数量增加了几个数量级，并且信息输入/输出操作的速度似乎简直是“空间”。 程序员可以直接而即时地访问刚刚从键盘键入的代码的执行-计算资源，而无需离开现场。 现在，对软件进行更改变得更加容易，并且已经想象到有人继续按照纯净形式的Waterfall方法工作是荒谬的。

自然选择和适应的需要迫使技术发生了变化。 而且，他们中的大多数人都从他们的前辈那里借来了迭代开发模型。 简而言之，执行周期已大大减少和改善。

但是随后又出现了不幸。 迄今为止前所未有的机遇使生产的各个部分的自动化得以继续应用于整个企业的自动化，甚至席卷整个行业。 有了如此大量的操作和所涉及的大量资源，就不可能简单地简化软件开发方法。 相反，它们变得更加广泛和形式化。

使用迭代开发模型的最著名技术之一是Rational Unified Process（RUP）。 它是在1990年代下半叶由Rational Software开发和实施的。

RUP术语不仅隐藏了软件开发方法，而且还隐藏了允许您管理开发过程的一组工具。 在本主题的框架内，特别有趣的是，RUP方法（2）描述了一个抽象的通用过程，组织或项目团队可以在此基础上根据自己的需求创建自己的独特软件开发过程。 您怎么说这种方法不灵活？

通过进一步的分析和比较，可以注意到RUP的某些关键功能也部分地从Waterfall技术继承下来。

1. 软件生产的循环方法 。 RUP项目的生命周期分为4个阶段和9个工作流程。
2. 迭代开发过程 。 RUP项目由一系列迭代组成，建议持续时间为2到6周。
3. 强制开发需求 。 RUP使用用例或用例来描述需求。 每个用例都是对用户与完全执行特定用户任务的系统进行交互的场景的描述。
4. 一种旨在逐步增加产品功能的增量方法 。 迭代计划的主要单元是用例，它使您可以在项目期间对需求，设计决策和实现进行必要的更改。

我们特别注意最后一点。 它指出，存在以特定形式草拟的详细要求，只是提供了在项目过程中有效更改设计决策和产品实施的能力。 包括项目后期。

RUP通常被错误地认为是具有高度形式主义的重量级过程。 但这不是完全正确的，因为RUP流程可以（并且应该）针对特定组织和项目的具体情况进行定制。 即使团队采用的小型软件产品需要进一步开发，扩展或与其他系统集成，RUP仍将使其轻松地应对所有出现的挑战。

3.推翻基金会

然后更多。 跳过了个人计算机进入我们世界的时期，我们转向各种工具工作室，可视化和建模工具，自动应用程序构建器等的出现。 在所有各种各样的助手中，例如，允许使用鼠标在图表上拖动元素并获得最终产品的自动更改的应用程序代码，它开始贬低软件开发技术的作用。 拥有如此先进的工具，而又没有时间或资源，您就可以放弃该方法的某些工作流程，而实际上却什么也没有损失。 至少在短期内。 事实证明，这些自由和有罪不罚的现象以及表演者应有的敬业精神，导致最绝望的领导者宣布了新的IT趋势-“灵活的开发方法”。

在这里，从红线开始，我再次强调非常重要的论文，也许是关键的论文-“具有适当的专业精神”！ 也就是说，拥有数十个大型已完成项目的高级专家，他们能够在20分钟内在脑海中勾勒出一个小模块的类图，立即估算出更改其状态的过程，建议关键的依存关系等。 决定在某些情况下，他们可以在不强制通过所采用法规的情况下采取措施。 同时，在相当短的时间内，该项目仍将以可接受的质量达到预期的结果。 是好是坏？ 乍一看，这真是太好了。 第二，并非一切都那么简单。 稍后我们将分析优缺点。

绝对不好，这是另一个。 年轻又大胆，从侧面看，问一个问题：“但是，那有可能吗？” 他们从来没有见过质量要求，看不懂图表，但是现在他们不需要了。 仅此而已！ 现在要求已取消！ 图表，建模过程-在炉中。 仅代码，代码和通讯。 另外，他们可以将自己的注释留在代码中，以供后代使用。

在此基础上，历史之旅可以完成并移动，以便更贴近身体...

III灵活方法论现象分析

在将每个实体放入您的嘴里之前，应该对它们进行逻辑分析。
伍迪·艾伦。

1.灵活方法的定义

由于Adjayl已经存在了很多年，所以让我们利用可用的信息，并首先回顾网络中最重要的定义和观点。 并且已经脱离了它们，我们将转到主要工件-灵活软件开发的宣言。

术语“敏捷”在搜索引擎中发现的第一件事：

灵活的开发方法 （敏捷软件开发，敏捷方法）是一系列软件开发方法，这些方法的重点是迭代开发的使用，需求的动态形成以及由于在由不同领域的专家组成的自组织工作组中不断互动而确保其实现的方法。

可以从此定义中区分出以下要点：

1. 使用迭代方法 。 这里没有什么新鲜事物，我还没有听说过否认该原理的软件开发方法。
2. 需求的形成是在产品开发过程中分阶段进行的 。 这是与许多其他技术的主要区别。 在某些方面，它提供了优势，在某些方面，它引入了基本限制。 我们将在后面讨论。
3. 使用所有团队成员 （包括客户） 的持续密切互动 。 当然，大多数其他方法都注重团队合作，包括与客户的合作，但是将这种交流定位为具有绝对优势的额外项目资源则更为排他；
4. 自组织团队 。 假定每次迭代都以过程的汇报和建设性的更改而结束，这有助于团队的不断发展。 类似的技术很可能是从较早的技术中借用的。 例如，它实践RUP。

原则上，我们无法从描述中找到太多内容，因此让我们继续进行说明：

大多数灵活的方法旨在通过将开发减少到一系列称为迭代的短周期（通常持续两到三周）来最大程度地降低风险。 每次迭代本身看起来都像是一个微型软件项目，并且包括产生微增益的所有必要任务：计划，需求分析，设计，编程，测试和文档编制。

但是我们已经在旧的RUP中考虑了相同的方法。 也就是说，这里也没有什么新的。

我发现的大多数定义都是抽象的和模糊的，几乎没有什么信息可以让您立即采用并开始使用灵活性。 但是，这里打开了该方法的另一个同样重要的方面，这使所讨论的整个主题贯穿的表面性变得清晰。 这是一个例子：

敏捷不包括实践，而是定义了指导团队的价值观和原则。 敏捷是开发过程的一个家族，不是唯一的软件开发方法，由敏捷宣言定义。

敏捷是一种具有自身价值体系的思维方式。 它类似于哲学，宗教或文化-人们相信并影响其行为的同一组态度。

显然由于这个原因，围绕灵活方法论存在无数争议。 您真正感觉不到的想法。 显然正因为如此，您可以调用自己的（几乎任何一种）非常规方法-灵活的方法，而不会陷入非专业主义的境地。 我认为这是可以接受的，如果您希望保持流行趋势，并且只要不影响开发过程和最终产品本身，就可以尽可能以新颖的方式命名您的开发方法。

我回想起一个案例，当时有一家大型IT公司在一个新的大型项目之前决定改善其技术流程。 为此（根据建议），邀请了灵活方法学的专家，这个负责任的任务由他担当。 在阅读了关于思维方式和敏捷价值体系的简短演讲后，他开始了解企业软件生产的实际情况。 为了发现现有流程中的缺陷和矛盾之处，我们与企业团队一起，选择了最合适的方法和方法来解决它们。 幸运的是，这些缺点对任何人都不是秘密，而且有许多原因使它们无法克服。 例如：缺乏时间，隶属于不同管理层的团队之间的矛盾，害怕承担责任等。 由于整个活动都是由公司高层管理人员赞助的，并且邀请的专家是一位真正的高级IT专业人员，因此开发的创新几乎可以按时实施，并且非常敏感，积极。 这只是他们无关的灵活方法论的宣言。 结果，公司的大多数员工仍然对现在完全转向敏捷而放弃其他一切充满信心。 这一切都非常像一个童话，讲述一个士兵如何用斧头煮粥，狡猾地从主人那里拿出他需要的食材并改善菜的味道。 那只是斧头没有煮。

但是，由于我们在这里公正地分析了敏捷现象，因此我们将继续进行研究。 让我们继续阅读原始资料-Ajail宣言：

2.让我们分析敏捷宣言的主要思想

关键思想：

1. 人员和交互比流程和工具更重要；
2. 有效的产品比全面的文档更重要。
3. 与客户的合作比谈判合同条款更为重要。
4. 改变意愿比遵循原始计划更为重要。

让我们从美中不足开始。就我个人而言，所有观点都是有争议的。让我们按顺序进行：

点1。在我看来，如我在上文所述，出现Ajail的主要原因之一是用于软件开发过程的自动化系统的快速开发，这使得可以忽略法规。就是说，正是通过机器人过程挤掉了单调的人工，才使我们能够产生更可靠和可预测的结果，包括保持过程本身的高质量交互。因此，在我看来，关于“人们-最重要的事情”，这只是一个口号，它有助于娱乐最感伤的团队成员的虚荣心。

但是公平地讲，我注意到这些口号，回想起来和对年轻员工的其他情感拍手，是很有效的，甚至在开始时就提高了团队合作精神。重要的是，对假期的了解消失后，不要空虚和失望。

点2。开发只是自动化系统生命周期中的一小段时间，然后就开始了苛刻的日常操作，现代化和机遇扩展。您是否曾经尝试过维护一款完全没有文档的优质软件产品？其中发生了什么？为什么要准确地（最重要的是，如何更正它）以使其开始有所不同？并且，如果它与其他软件进行交互，那么通常可以在其中进行哪些更改，而不能更改哪些内容？所有这些都类似于在雷场上行走。

在这里，我们添加了分阶段开发的原理。没有文档，因为仍然有必要确定产品通常位于开发的哪个阶段。

但是为了客观起见，应该注意的是，当团队向客户交付成品时，是由一堆模块组装而成的，安装在各种设备的堆上，甚至是在“非子代”负载下，那么很有可能需要修改或更改代码。有时变化可能是巨大而深刻的。这里绝对不是形式主义，有必要挽救团队的面子。在此期间，您可以将文档推迟到更好的时间，然后紧急编辑代码。我想指出的是，当在开发阶段准备好体面的文档时，进行此操作会更加方便，并在介绍时说明所有工作原理。

点3。好吧，对于初学者来说，这一点并不能理解对方的反对。但是，合同条款协议不是与客户的合作吗？如果客户与开发团队明确了合同条款后能够理解工作量，大致实现了实施成本，并且最重要的是可以想象他可以在一些真正切实的指标（自动化业务功能，布局模型等）中得到的结果。 ）。毕竟，对于他而言，做出决定将变得更加容易：他是否需要该特定产品，是否准备为其产品提供资金等。那不是合作吗？

但是合作呢？只是为了生活而进行的热情对话，没有任何义务？不管是否喜欢，如果项目是商业性的，所有各方首先需要实现他们在项目中的目标。合同条款-只需确定这些目标和实现这些目标的方法即可。在拟定和批准合同时，双方都开始意识到，如果未能达成协议的结果，他们有望获得合作伙伴和责任等级。在这种情况下，合同是双方的动力和解决分歧的手段。毕竟，最可怕的不是极端，而是不确定性。

没有合同-没有责任，对项目完成应产生的结果没有完全的了解。这种方法适合您-祝您好运。

第4点。我们在上面已经说过，如果有用于设计和开发软件的现代工具，那么专业的开发团队几乎在任何阶段都不会对产品的实现进行更改就特别困难。这是一个正常的过程，很大程度上取决于团队对他们正在开发的产品的理解深度。因此，在这种情况下，问题不仅仅在于团队做出改变的意愿，而是关于谁将为所有这些超出支付费用。在这方面，定性拟定的合同才是最重要的地方，它决定了谁以及在何种情况下因改革而遭受重大损失。开发人员是否需要自费重新制作他们误解的内容或未正确解释其需求的客户。

3.讨论敏捷宣言的原则

由于我们想对此话题持开放态度，因此让我们至少简要地谈谈敏捷宣言所解释的原则：

• 尽早提供有价值的软件，从而使客户满意；
• 即使在开发结束时也欢迎需求变更（这可以提高最终产品的竞争力）；
• 频繁交付工作软件（每月或每周或更频繁）；
• 在整个项目中，客户与开发人员进行密切的日常沟通；
• 该项目是由积极进取的个人执行的，这些个人被提供了必要的工作条件，支持和信任；
• 推荐的信息传输方式是个人对话（面对面）；
• 运行软件是进度的最佳衡量标准；
• , ;
• ;
• — ;
• , ;
• . .

以上大多数与其他方法都没有矛盾，因此非常可取。

但并非总是可以在实践中真正使用这些原则。例如，客户远不能总是能够与团队合作讨论解决方案。他常常没有时间，有时没有特殊的愿望。然后，您需要一位专业人士-一位分析师，能够以简洁明了的态度，自信地使用自己的心理“小事”，从中汲取有用的信息并将其平稳，平稳地组合起来，以最适合于实施的形式传达给开发团队。如果发生这种情况很有趣，团队的工作不再被认为是灵活的？

由于相同的原因，并非总是能够组织频繁的交货。这个过程可能会受到不同团队开发的许多可集成模块的严重影响，而这些模块可以在同一设备上同时组装（模块），这是非常成问题的。是的，对于特定的设备，它的交付时间恰好接近交付时间。还必须考虑到这一点。

尽管“敏捷原则”原则上不欢迎文档和所有爵士乐，但关于“最佳技术要求，设计和体系结构”的声明中仍然存在分歧。如果您“冒犯”正式的文档编制方法，那么就不可能证明是最好的（民间智慧）。

而且，从我的角度来看，它引起了人们的不满，即“个人对话（面对面）”，这是传递信息的最佳方法。我认为，例如，使用任务跟踪器或Wiki系统，在项目中传输信息要高效得多，而当然不排除个人交流。

IV敏捷方法论的应用

在创新中，您必须既固执又灵活。
如果您不固执，您将拒绝过早尝试。
如果您不灵活，则将头撞在墙上，将看不到要解决的问题的另一种解决方案。
杰弗里·普雷斯顿

如果在审核过程中出现了如此多的关键评估，那么它们如何运作？
敏捷的成功显然有助于在小型项目中使用该技术的有效性以及上述所有项目的通用性（同时性）。

1.使用敏捷的好处

通过使用用户故事，开发团队可以在与客户的讨论中达到必要的理解水平。对于客户而言，降低输入主题的门槛，使他更容易操作项目的内容，设置优先级，纠正不准确之处等。而且，即使项目，产品和其他团队经理都非常了解基于简单用户故事的需求规范，也有机会轻松地处理项目中的任务并了解客户的期望。

由于原型的频繁交付，有可能避免客户的期望与解决方案执行者提供的选项之间的巨大差异。随着每个新版本的发布，它们之间的距离越来越近。执行时间的减少以及相应的财务损失也不大且不可预测，可以将其放入项目计划中。

看起来像这样：客户希望获得一些新功能，而他本人并不能完全体现这些功能。存在“紧密合作”，承包商向承包商提供了一个试点解决方案，该解决方案通常不能完全满足客户的期望，而团队会被告知。这一事件鼓励了新的“密切合作”，因此承包商对原型进行了调整，并再次向客户展示了产品。这样一圈，直到某个功能完全赢得了客户的青睐，或者直到合作变得“拥挤”，以致留在其中并不舒服。如果产品的复杂性和自动化功能的数量使您能够执行3到6个这样的周期，以使客户完全无条件地满意，那么为什么不这样做，相当可行的方案。

我要重点关注的是一个基本点，而这个基本点经常没有得到应有的重视-需要修复文档（至少在事实之后），其技术解决方案是通过反复试验而获得的。这对于客户（随后可以聘请新团队完成或扩展产品）以及团队本身都很重要，首先，客户将能够复制解决方案或其部分，其次，如果招募了客户来升级产品，则能够更快更好地加入流程。

2.小​​型项目-敏捷的舒适环境

对于小型项目，使用用户故事而不是开发产品的全部要求，可以使我们简化并与客户进行更舒适的交流。由于与客户的频繁互动和沟通形式的简单性，团队不会洗手，因此滑冰对产品的功能提出了可接受的要求。在没有复杂算法和与其他软件集成的情况下，这不会造成太大损失。问题域级别-关闭用户案例，解决方案域-代码注释。

使用一支专业团队，您无需费心设计解决方案的体系结构和产品要求的规格。当然，像团队或其成员这样的人已经决定了，他们拥有适当的模板和最佳实践。

如果该产品是一次性的，并且不打算开发它，那么这就足够了。

3.如何在中型项目中使用敏捷

在中型项目中使用敏捷也可能非常有效。

在较大的项目中，可以使用各种自动化平台，这些平台配备了现成的模板，最佳实践，自文档工具等。 这大大简化了正式流程，包括设计，建模和文档编制。 在这种情况下提供的解决方案通常是重复的，并且改进和更改的数量有限。

如果将以前的类似决定记录在案，则可以获得最大的效果。 在此基础上，您可以将更多的时间花在设计和建模上，而不是与客户一起选择所需的原型。 “试穿，穿上去。 不要按？”。 重要的是，新的，已实施的解决方案也要有充分的文档记录。 在这种情况下，团队会从中收到一组用于组装各种模型的模块和说明，可以将其提供给将来的客户以供选择。

在这种工作模型中，重要的是要理解敏捷并不会否认文档编制过程的重要性，它只是允许您延迟其形成，从而优先考虑构建产品本身（如果在当前情况下，可能的话）。 在收到可持续产品，巩固所取得的成果之后，就已经可以形成文档，并且如上所述，这有助于将来避免失去对系统规则的理解。

4.如何在大型集成项目中有效使用敏捷

在维护高质量文档的大型复杂项目中，存在产品及其生产过程的体系结构构想，可以将产品的“零件”外包给小型团队。 在对通用体系结构进行了详细研究并准备了新子系统的高级需求之后，才进行这种转换。 现在，使用敏捷可以非常有效地实现这些相对较小的部分。

相同的方案适用于大型复杂系统的细微改进或逐步开发，尤其是在您需要进行一些研究工作的情况下。

在将产品紧急交付给客户的情况下，可以在大型项目中有效使用敏捷的另一种选择。 鉴于其完善和纠正工作严重缺乏时间和资源，因此在方法上的灵活性恰恰可以帮助防止惨败。 在我看来，在这种情况下，这种特定方法是最佳的。

在本节中，值得一提的是基于敏捷的现有方法，但倾向于解决大规模问题。

敏捷统一过程（AUP）是Scott Ambler开发的统一过程（UP）的简化版本。 这种软件开发方法论结合了灵活方法论和统一过程的要素。 特别是，AUP涉及通过测试进行开发（TDD），使用灵活的建模（英语敏捷建模）和数据库重构，灵活的变更管理。

OpenUP是一种迭代的软件开发增量方法。 定位为轻量级且灵活的RUP版本。 OpenUP将项目生命周期分为四个阶段：初始阶段，完善，设计和转移阶段。 项目的生命周期可确保在整个项目中为利益相关者和团队成员提供熟悉点和决策点。 这使您可以有效地监视情况并及时决定结果的可接受性。 项目计划定义了生命周期，最终结果是最终的应用程序。

5.如何不使用敏捷

一个同等重要的部分，也许因此考虑了整个分析。

1. 我反对评级的领导者是这样一种情况，即他们尝试使用敏捷，或者更确切地说，是某些原则，而不是为了实现可以实现的任何特定目标，而只是简单地#CRAFT。 因为这是一种趋势，所以它在每个人的唇上都响起。 例如，某人在IT派对上获得了积极的评价，有些短暂而狂妄，但有传言说，随行人员出现了。 现在，他们已经称自己是敏捷的追随者，他们与其余的-属于某个精英俱乐部的成员-保持沟通。 所有这些都有助于简化方法论及其边界的模糊轮廓。 对此原则的实现是漫不经心和正式的。 人们正式无原则地执行旨在减少形式主义的原则。
   
   例如，最近的一种情况。 在一家进行回顾展的公司中，蒂姆利德人禁止进行回顾展。 这是这种芯片。 没想到 首先想想：好吧，也许它们是对的，这样在讨论问题时，团队就不会受到主管部门的压力，等等。 但是蒂姆利德人得罪了，他们无所适从，想弄清楚。 我试图说服我，他们说这可能会更好，主要是您获得了愿望清单，其中列出了需要更改的内容，需要改进的内容等。 这是一个可怕的秘密。 这些聚会并没有结果和改善流程的希望。 先生们IT_shniki，为什么要进行这样的回顾？ 只是互相称赞并增强团队合作精神？ 毕竟，这种方法论过程的主要目的是：“团队应该系统地分析可能的方法来提高效率并相应地调整工作方式。”
2. 在我的排名中，第二种情况是团队决定节省具有复杂行为或逻辑算法的项目的准备要求。 也就是说，当用户故事只是问题的冰山一角而其主要部分不可见时，需要进行详细，透彻的分析和设计才能实现。 这会发生什么？
   
   在开始工作之前，客户和开发人员甚至都无法大致了解他们需要做的工作量。 相应地：客户要么付款，要么付款，然后每次向他解释说一切都变得更加困难，而现在工作仍不可见并结束。 毕竟，这将是一个可惜的放弃，并且将逐渐开始对这种“黄金”产品永远不会得到回报的严厉理解感到。 同意在一定数量/时间内完成工作的开发人员将自费完成并重新制作产品（免费），直到客户超出想象力为止，或者他怜悯灵活方法的受害者。
3. 当在大型多功能项目（突然也是集成项目）中，团队决定节省制定解决方案体系结构并开始在短迭代中实施单个用户案例时，该情况名列第三。 极有可能在3-5次迭代后，尝试创建一个新功能时，由于没有考虑该功能应基于的基本原理，因此您需要重做整个前一个功能。 更糟糕的是，如果在第10次迭代后发现所选技术不能满足客户的所有需求，则必须重新开始。 也许通过更改命令。
4. 一家敏锐而令人难以置信的灵活创业公司正在进入低迷的细分市场的开放空间的情况并没有进入前三名。 一家初创公司，也是一家初创公司，它没有任何基础，纽带，附件，同时也没有稳定性和稳定性。 简而言之，几乎没有文档，团队不和谐，经常变化。 市场实际上是在撕裂团队，要求在有风险的领域中提供越来越多的新解决方案，而所有后续项目都在我们眼前崩溃了。 多数情况下，这是由团队对工业软件生产 ，交付组织和产品支持的过程不了解的事实来解释的。

总结一下

在准备本文时，我试图帮助对敏捷方法感兴趣的团队以一种或另一种方式突出并正式化他们应该面对的挑战，并找到克服这些挑战的可能解决方案。 对于试图向该小组介绍一种或多种方法的辩护律师，以及想要揭穿灵活性光环并合理地拒绝使用它的反对者，我都试图认为该主题尽可能宽容。

我希望该分析将在必要时帮助使用其他方法的团队利用敏捷方法。