敏捷的初始条件是什么？

首先，我认为由于以下基本原则，敏捷过程可以奏效：

• 它带来焦点
• 限制真正带来焦点的噪音

其次，我想知道敏捷流程能否成功需要哪些初始条件？例如我们是否需要：

• 没有现有的错误
• 全自动测试过程或至少高度自动化的测试过程
• 致力于项目的人
• 更明确定义的新发展
• 不能使其更快或更稳定的发展
• ？

那么，您需要什么来使其成功？是否有其他敏捷实现可以更好地处理没有某些初始条件的情况？

真正，完全相信敏捷宣言的各个业务阶层的人

我们正在探索通过开发和帮助他人来开发软件的更好方法。通过这项工作，我们开始重视：

• 个人与流程和工具之间的互动
• 工作软件超过全面的文档
• 客户合作而非合同谈判
• 响应计划变更

也就是说，尽管右侧的项目有价值，但我们更重视左侧的项目。

当我说相信敏捷宣言时，我的意思是所有敏捷宣言。您不能忽略最后一部分。还有就是仍然在右边的项目价值。

如果您拥有像程序员，经理，客户这样的人，则可以对敏捷工作进行一些改动。如果您不这样做，那么您将很挣扎。

最低限度

首先，最重要的是，您必须拥有自上而下的赞助商，这些赞助商必须了解委托人并充分相信委托人，可以在各个环节强制执行，并且认为敏捷适合您的情况。

拥有不相信该过程的高级管理人员最终会破坏该过程，因为它们将使下属扭曲，歪曲，污染，破坏或恶化该过程。

如果高级管理人员不了解原则，他们将开始要求捷径和妥协，这会扰乱流程。然后当事情崩溃时，反对者可以说：“我告诉过你，敏捷不起作用！” 回到死亡行军！

这比不采用敏捷更糟糕，它通常被称为“敏捷但...”。管理层使用敏捷术语，“但是...”会抛出所有实际的委托人，并继续做他们以前所做的事情，“但是...”现在称为敏捷。这给那些不懂得更好的人一个坏名字。

好的副作用

您列出的东西，如无错误，自动化测试，明确定义的开发，专职人员等，对于敏捷来说都是很好的积极副作用。

敏捷不是灵丹妙药或灵丹妙药，但它确实提高了各个级别的透明度（客户<->管理<->开发人员），并使对生产力有问题的人员迅速脱颖而出；特别是敏捷的具体实现，例如Scrum。

我想到了几件事：

• 专业的团队凝聚力-这些人愿意与他人一起玩吗？他们是成熟，负责任的人，可以在工作中享有一定的自主权吗？

• 沟通文化和政策-人们在组织中表达关注，想法和意见的程度如何？

• 了解什么是敏捷，什么不是敏捷-这些外部利益相关者是否对流程足够了解，可以最终承担责任？如果没有，那么这可能会导致伪敏捷。同样，是否有明确定义的产品负责人和ScrumMaster来帮助组织一些事情？