我对敏捷的看法

您在组织成立之初就种下的种子会影响组织随着时间的增长。

我认为可以肯定地说您有一些宏观目标：

• 可预测性：您作为经理想预测会发生什么以及何时发生
• 灵活性：您想敏捷地满足客户并完成销售
• 开放式沟通：你们希望与团队保持良好，开放，诚实的沟通，尤其是在情况不太理想的情况下

根据我的经验，敏捷似乎可以实现上述目标，即使看起来并非如此。

尽管有一个长期计划似乎具有可预测性，但瀑布式，许多前期类型的方法并不敏捷，最终将导致无法实现上述目标。

因此，当我说“敏捷”时，我的意思是：

• 该团队致力于实现定期目标。 每次的周期都是相同的，并且相对较短：1-3周……一次迭代。
• 所有任务都放置在中央“待办事项列表”中，并在该待办事项列表中确定优先级。 简单的任务称为故事，而复杂的任务称为史诗。 任何无法在迭代中完成的故事都是史诗，在开始之前，史诗必须分为子故事。 任何会浪费时间的事情都是一个故事，其中可能包括“可用于客户支持请求”，“合作伙伴电话”以及“在圣诞节期间请假几天”。
• 积压重排优先级可以随时发生。
• 每个故事都分配有团队同意的分数。 我发现基于斐波那契数列的点值最有效。
• 在迭代的开始，每个团队成员签约完成某些故事，并将某些故事标识为扩展目标（他们不保证他们将完成扩展目标）。
• 在迭代过程中，我们会定期召开简短的“站立式”会议（我建议每周两次），每个人都在谈论“自上次会议以来他们做了什么，他们打算从现在起到下一次站立时的工作，以及任何阻塞问题，每人不超过60秒。 这些低影响的接触点有助于使团队保持一致。
• 在迭代结束时，每个人都演示他们完成了什么，以便整个团队与正在发生的事情保持联系，以便我们庆祝每个团队成员的成就。
• 完成任务的点将放入电子表格中。

很明显，以上方法带来了灵活性。 根据重新排序的待办事项来更改方向，最多只需要迭代一次。

不太明显的是，它还导致更好的可预测性。 进行简短的迭代意味着人们可以更好地预测2周或3周任务的艰辛程度，是否可以完成任务或是否需要将其分解为子任务。 因此，基于每个迭代，您可以立即获得可预测性。 但是，您获得的好处是经过3或4次迭代，您将为整个团队和每个团队成员获得一个非常稳定的“点消耗”模型。 该点消耗模型可得出非常准确的预测。 您会发现故事（没有史诗的故事）定价准确，并且每个团队成员在反复迭代中始终保持一致的观点。

更加不明显的是，敏捷如何导致更好的沟通。 在传统的瀑布模型中，总是有滑移。 滑倒会导致屁股被遮盖和责备，以及其他很多其他原因：“我不信任团队成员，所以我将以一种使我感到最少痛苦的方式进行交流。 糟糕的情况和常见的情况，以及我一次又一次看到的情况是，为期3个月的项目在到期日的几周内滑了一个月或两个月。 在发生这种情况时，每个人都充满压力和胡思乱想（不同于项目的开始阶段，你们那里有钱在银行，潜在客户和有积极性的团队……在这个阶段，似乎没有什么不可能。）在敏捷的过程中，人们签署任务并在迭代结束前不交付任务的人不会受到惩罚。 发生的是，如果这是一个重复的事件，作为经理，我们可以简单地说：“乔，您在此迭代中注册了45分，但是从历史上看，您每次迭代消耗/提供了30分，如何注册30点和平衡作为延伸目标？” 尽管表现不佳的员工应从团队中删除。

这种方法的另一个好处是所有代码和所有想法都可以改进。 这意味着人们更有可能说，“我错了，让我们改进它”，“很高兴您对我的代码进行了改进”，以及其他利用所有团队成员技能的事情。

但是，您说，“架构是什么样的？” 我说，“谁在乎？” 请记住，这是我对Lift的态度。 Lift中有几个试金石概念（例如，安全性，抽象了HTTP请求响应周期），但总的来说，它是基于用户反馈而增长的。 无论我们今天想到的是哪种架构，都会出错，损坏或范围太广，以至于在4到6个月内就会过时。 另一方面，如果我们有机地生产产品，并确保我们愿意扔掉不再适合的产品，那么我们可以不断满足客户的需求，并从我们一路走来的错误中吸取教训。 请注意，无论我们选择哪个方向，都会出错。 在瀑布模型中，我们鼓励隐藏错误，而在敏捷模型中，我们鼓励承认错误并将其修复为交互任务。

我需要花几次迭代才能获得流程的节奏，但是据我的经验，一旦有了节奏，管理层和销售人员将获得可预测性和灵活性，整个团队将获得开放的沟通。

参考： Good Stuff博客上JCG合作伙伴 David Pollak 对敏捷的看法 。

翻译自: https://www.javacodegeeks.com/2012/11/my-thoughts-on-agile.html