在某种程度上取决于团队的组成

676balanced

它要求很高，因为它影响我们所做的一切，但也正是出于同样的原因，它很重要。 那么进展如何呢？ 寻找问题 要想进步，首先要发现问题。因此，在早期阶段，我们在绘制以前的流程方面做了大量工作，以便能够识别问题区域。 近年来，我们已经从一个相对较小和清晰的机构发展成为一个中型机构，提供更复杂和全面的解决方案。以前那些微不足道的小挑战因此而与我们一起成长，并成为更大、更重要的问题。 我们发现的一件事是，我们在解决方案的早期详细规划上花费了太多时间，而实际上却没有足够的了解。缺乏足够的洞察力会导致错误的假设，从而需要在此过程中进行许多更改（而这不一定反映在时间估计或进度计划中）。我们还发现，我们和客户都非常关心结束日期和大量交付，这使得在此过程中几乎没有留下优先级和持续发布的空间。此外，我们还发现，会议次数太少，对话过程中很少进行对话，导致了所有权和学习的程度较低——无论是来自客户，还是我们团队内部。 问题的解决方案 过去，我们以不同的方式解决项目。

要解决的任务以 特殊数据 及客户的期望，我们选择了我们认为最合适的方法。 有些项目得到了更灵活的解决（其中路径是在您进行过程中创建的），而其他项目则使用瀑布方法来解决，我们从传统的需求规范和阶段开始 - 首先设计，然后开发。 显示敏捷过程和瀑布方法之间差异的插图 在这里我们发现，在敏捷流程中，我们已经成功地： 以更低的成本更快地交付价值（我们共同开发您需要的东西，而不是我们认为您需要的东西） 一路调整路线、目标和财务框架 通过允许事物一路变化来创建更好的解决方案（并不是一开始就考虑周全，然后结果就是这样） 根据彻底的优先级发布部分解决方案，让事情进展得更快 在跨学科的团队中更好地工作，这可以在各个层面上提供更好的解决方案 - 而且更有趣！ 通过包容性流程与客户建立共同所有权 提供更高的质量，因为我们有持续的质量保证和测试 根据这项工作的发现，答案对我们来说非常明确：现在是采取全面措施的时候了 - 全面采用灵活的方法，无论大小。



我们可以选择现成的敏捷框架（例如 Scrum）并处理它，但我们希望在 Increo 中找到适合我们自己的道路以及我们想要的工作方式。例如，对我们来说很重要的是，它不会变得过于由开发人员驱动，并且我们有跨学科工作的空间，尤其是，有足够的空间来进行用户体验、视觉设计和搜索引擎优化。 这就是我们想要的工作方式 团队 我们始终提供互补的核心团队（通常由 UX/UI、开发和 SEO 专业知识组成）。这些必须与客户密切合作。至关重要的是，团队中至少有一名成员是客户的决策者，并充当产品负责人。 显示敏捷过程中的步骤的插图，从最初的洞察到冲刺和持续改进 ‍ 我们从基本的洞察阶段开始 为了能够提供最佳的解决方案，需要洞察力。洞察力也是我们在工作中获得的，但我们也需要一个良好的基础。在早期阶段，我们必须相互了解，并且必须共同确定要开发的解决方案的目的和目的。我们经常需要目标群体的洞察力，并且我们应该定义最重要的用户任务和我们要解决的问题。 快速启动 我们共同定义了必须具备的条件，以便启动解决方案的第一个版本，并确定待办事项（即任务列表）。这个划定应该基于用户最需要什么，什么创造最大价值。