新敏捷团队所犯 10 大错误

以下是新手敏捷团队最可能犯的 10 个常见错误的集合。您可以从中找到建议的修补方案,这些建议直接来自我们的支持人员、用户学习和指导团队,他们在引导团队向敏捷过渡方面具有多年经验。如果您对 Agile、CA Agile Central 不了解,或是需要进修,只需单击以下列表中的某个项即可直接跳到某个主题:

  1. 恐惧
  2. 沟通不畅
  3. 团队结构较差
  4. 估算不准确
  5. 计划能力不足
  6. 测试水平较低
  7. 忽略客户反馈
  8. 团队缺乏权力
  9. 缺少回顾和演示会议
  10. 没有解决员工抵制的方案

1. 恐惧

恐惧是一种强大的情绪,可能在很多情况下遇到。这种情绪可能会导致您的新敏捷团队作出错误的决定和实践,并使他们感到沮丧。恐惧的死敌是信任。通过在所有级别灌输信任来打败恐惧。首先,要让您的团队了解到组织信任他们并且相信他们能够作出正确的承诺和决定。应该相信团队会以一个整体进行学习和了解并作出选择,而不是只从管理层接收命令。

常见的恐惧遏制团队发展的示例是承诺的问题。由于团队担心承担责任或害怕由于失败而受到责备,他们通常低估或多估估算值。首先,允许您的团队给自己在估算中出错的权限。培养信任的环境,这样团队可以找出出错的原因,而不是相互指责。这样有助于您找到真实的速度上限。个别的失败会转化成将来无数的成功。

2. 沟通不畅

如果您的团队成员之间每天不能定期沟通,会给将来带来隐患。即使有最谨慎的文档,发现问题和拦路虎的最佳方式仍是面对面交谈。通过设置专门的团队区域来培养协作,所有团队成员都可以在那里交谈。使用视频会议和即时消息软件为全球团队创建虚拟会议室。在 CA Agile Central 中,您可以使用通知显示板面板讨论来增强团队沟通。

举行每日立会。所有团队成员之间的简短迭代面对面会议有助于每个人了解昨天完成了哪些工作、今天计划的工作有哪些以及哪些问题可能会影响工作。有关要分享迭代信息,应选择“质重于量”。在实际开会过程中,如果会议不必要地延长时间,团队成员会由于站立时间太长而感到不适。不要奢望在立会中解决问题;可以让 Scrum 专家稍后与个人讨论相关问题的详细信息。

3. 团队结构较差

运行良好的敏捷团队有两个共同特征:跨职能和稳定。

真正的跨职能团队具有所有必要的技能,能够从用户情景过渡到完成阶段。例如,如果您团队的已完成定义包括完全记录的代码,那么请在团队结构中包含一位技术作家。此外,还应包括一位测试人员移确保高质量的代码。团队需要在深度和广度上了解用户情景,这样可以准确估算范围。

稳定意味着团队成员有时间与彼此一起成长。挑战自己,在每月、每季度甚至是每一年都保持团队的完整性。使团队有始有终的完成每一个项目。团队成员通过互相学习对方的角色受益良多,随着对每个人技能的熟悉程度不断增加,可以挑战彼此并提供准确的估算。这些成熟的团队具有精确定义的速度,为产品所有者和利益相关者提供更好的预测。

4. 较差的预测习惯

估算新工作的规模和范围不是一件容易的事情,特别是对新手团队而言。继续努力;随着时间过去,估算会变得越来越简单。让管理层了解团队需要两到三次的开始冲刺就可以了解到初始速度。在团队了解他们完成工作的速度之前,不要接受功能集的预定截止日期。

部分团队可能会将用户情景分数与实际的工作小时数联系在一起。千万不要这么做!使用诸如T恤大小、颜色或分数等抽象值来表示新工作的大小。这很重要。抽象能够帮助我们跟踪情景的复杂性,而不是个人的可用性。分数估算可以反映一个团队作为整体的能力。一旦用户情景大小确定并提交至迭代,个人产能将会以每小时任务估算的形式开始发挥作用。

5. 较差的计划习惯

与瀑布式或其他方法相比,有些人可能相信敏捷与计划没有关系。事实上,敏捷开发需要更多的计划。敏捷开发的区别在于,此关键操作是持续性的,而不是在开发周期开始进行清点的一次性事件。将它视为一个连续过程,在每个不同的复杂性和粒度级别都会出现。预期和承诺花费 20% 的可用工时计划以便取得成功。

排定积压工作梳理、每日立会、迭代计划和发布计划会议。为这些会议制定一致的节奏,以便团队成员形成“肌肉记忆”,以便更好地为即将到来的时间框进行计划。制定会议节奏,使团队提前了解一到两个迭代。

6. 测试水平较低

敏捷并不是以更快的速度交付软件;而是以更快的速度交付高质量的软件。产品所有者不应该验收已完成的工作,直到这些工作经过测试并且满足团队的验收标准。战胜不良测试习惯的方法之一是强调开发自动测试。对每个内部版本进行测试,直到通过测试。

您可能会认为测试应在最后完成,即在开发人员完成编码后。事实恰恰相反!随着测试人员加入跨职能团队,测试就可以立即开始。在迭代计划之后,大家都会了解用户情景的要求。开始针对情景提供的值构建测试,这样一旦代码就绪就可以对它们进行验证。这样会消除潜在的瓶颈。

7. 忽略客户反馈

客户是您最重要的利益相关者。让他们帮助您的组织起草对特征和功能的愿景。在梳理积压工作和计划时查看最热门的请求。考虑将客户支持代理吸收为团队成员以便提供数据和趋势。在每次迭代时查看此反馈循环,这样您就不会继续构建不能满足客户需求的内容。

CA Agile Central 提供了通过 CA Agile Central Idea Manager 管理客户反馈的轻松方法。您可以建立自定义的投票网站,可以在其中收集和组织新的功能请求,并由外部和内部利益相关者进行投票。您甚至可以通过发布有关每个请求的反馈和状态更新来直接与客户沟通。CA Agile Central Idea Manager 随 CA Agile Central 的无限版提供。

8. 没有赋予团队权力

有三个步骤可以确保在敏捷流程中赋予团队权力。首先,您必须通过邀请成员加入计划来与团队建立紧密关系。下一步,询问团队成员对已提议工作的了解情况。最后,必须尊重这些意见的价值。真正的权力意味着团队能够做出影响承诺的决策。公司不需要告诉团队要做什么,而是提供最重要的数据。

当团队列出确定了优先级的请求列表时,不是下达指令,而是让他们成为流程的一部分。他们可能会向组织返回如下反馈:“我们能够完成情景 A,但是这意味着必须放弃情景 B。”或者“如果必须在此次迭代中完成情景 C,那么质量可能会面临风险。”部分团队会回避此责任;他们只会遵从。挑战团队的成长,培养信任的环境来赋予权力。

9. 缺少回顾或演示会议

您认为我们已经完成推荐会议了吗?还没有。包含迭代和发布的会议是完成“检查和调整”周期的里程碑。这种情况出现在所有级别。您的每日立会应该包括回顾部分。在迭代结束时,与组织举行一个演示会议展示您的团队已完成的工作。其他团队将为您提供有价值的见解(以及表扬和鼓励)。

与您的团队举行迭代和发布会议。在这些会议中,团队可以讨论有益的经验、遇到的问题以及在下一个时间框里防止问题出现所需的操作项。但是不要只将关注点放在已承诺的东西上;将敏捷流程作为一个整体来回顾。正在计划哪部分工作?团队是否遇到了此列表中的任何错误?可以做哪些调整?

10. 没有针对抵制的计划

变化是一件困难的事情,有的人可能会拒绝切换到敏捷流程。可以通过与管理层进行沟通来为这种情况做准备。组织必须明确团队成功高于个人表现的理念。消除个人度量标准;无论输赢,都是一个整体。这将会遇到潜在的文化问题 — 透明的敏捷流程带来的可能导致同事之间的判断。又再次回到提供信任的环境

部分人在向敏捷流程过渡时遇到的需求是在早期阶段的团队现场。他们将成为您的开路先锋,能够观察到可能使流程置于风险中的细微异常。CA Agile Central 指导能够协助组织满足这种需要。我们能够通过量身定制您的需求来自定义计划,并强调您的团队最需要的敏捷概念。我们甚至能够通过快速电话会议为您提供建议。

反馈

需要更多帮助? CA Agile Central 社区为您提供一站式自助和支持。要将反馈或支持请求提交到 CA Agile Central 支持、获取解答并与其他用户协作,请加入我们的 CA Agile Central 社区