15、敏捷开发中的恐惧应对与管理之道

最新推荐文章于 2025-08-11 10:43:42 发布

pytorchlight8

最新推荐文章于 2025-08-11 10:43:42 发布

阅读量33

点赞数

CC 4.0 BY-SA版权

分类专栏： Scrum实践精华：从理论到实战文章标签：敏捷开发 Scrum 团队恐惧

本文链接：https://blog.youkuaiyun.com/pytorchlight8/article/details/149897868

Scrum实践精华：从理论到实战专栏收录该内容

18 篇文章 ¥499.90

订阅专栏¥69.90

会员秒杀 ¥9.9 重磅福利

超级会员免费看

敏捷开发中的恐惧应对与管理之道

在软件开发领域，敏捷开发尤其是 Scrum 框架的应用越来越广泛。然而，在实践过程中，团队成员和项目管理者往往会面临各种恐惧和挑战。下面我们就来深入探讨这些问题以及相应的解决办法。

一、团队常见恐惧及应对

（一）对变革的恐惧

发起变革的关键在于如何构建和传达过渡信息。大多数人不喜欢被迫或彻底改变现有局面的变革。因此，建议将变革呈现为一个持续的实验，让团队成员明白变革正在接受审视，若行不通，团队会共同检查和调整。这种安全保障措施能减轻那些害怕变革者的恐惧。

（二）对暴露问题的恐惧

有些开发者喜欢独自工作，对常规检查他们工作的行为会产生抵触情绪。但 Scrum 强调定期检查，目的是识别浪费和错误的活动。日常的站会、冲刺评审和回顾会议可能会暴露出那些不想为团队做好事的成员，而这些人往往最害怕暴露问题。

不过，Scrum 对产品和过程的定期检查是有益的。就像晒太阳，适度暴露在阳光下能带来健康的肤色和维生素 D，而过度暴露则会受伤。在软件开发中，尽早频繁地发现问题，就能减少后期痛苦的意外情况。当以积极的方式进行检查时，团队成员会接受这些检查，同时也能尽早发现那些“坏鸡蛋”。

（三）对犯错的恐惧

一些组织存在指责、掩盖问题和内部冲突的文化，这些组织很难接受 Scrum 或其他基于经验过程控制的框架。因为软件行业本身就充满风险，犯错难以避免。风险与不确定性相关，而不确定性源于知识的缺乏，知识、不确定性和风险相互关联。

但实际上，最大的学习来自于冒险和犯错。以以色列为例，尽管面临战争威胁且人口较少，但它在纳斯达克上市的科技初创企业数量却很多。以色列文化容忍“建设性失败”或“明智的失败”，当地投资者认为不允许大量失败就无法实现真正的创新。在以色列军队中，对训练和模拟中的表现，甚至战斗中的表现，都持中立态度，只要冒险是明智的，就有值得学习的地方。

软件公司如 Facebook 要求开发者在第一周就将代码推送到生产环境，这创造了一种“心理安全”的环境，让团队成员能够接受犯错，从而为有计划的冒险和创新提供了温床。

此外，减轻恐惧的一个好方法是缓解气氛。在一个高压环境中，CEO 以幽默的方式提及错误，能让团队放松，同时公开讨论错误和弱点还能加强团队成员之间的联系。

二、管理项目赞助商的要点

在 Scrum 项目中，项目赞助商虽然不是 Scrum 框架明确规定的角色，但对项目的成功至关重要。然而，许多非软件背景的赞助商可能对 Scrum 有误解，认为工作中的乐趣与生产力相互排斥。作为 ScrumMaster，有责任协调赞助商和团队的期望。

（一）建立关系

不要只在正式的冲刺评审或紧急情况下才与赞助商见面，应主动安排定期的更新会议，如午餐或咖啡时间。在这些会议中，强化项目的积极变化，了解赞助商对项目的看法。同时，与赞助商建立良好关系有助于发现潜在的公司政治问题，并提前做好应对计划。

（二）明确参考点

确保对项目的总体目标有清晰明确的理解。可以使用简单的产品“一页纸”概述来让赞助商参与产品的高层规划。即使赞助商不熟悉产品待办事项的细节，也应熟悉“一页纸”中的内容，后续的具体需求争议应以此为依据解决。

以下是“一页纸”产品概述的示例表格：
|类别|详情|
| ---- | ---- |
|电梯演讲|For…Who…That…Unlike…|
|目标客户|1) People who work in…
2) Those who need a…
3) …|
|主要功能|1) Share content with…
2) Personalize ads on…
3) …|
|好处/差异化|1) More accurate than…
2) Better integration with…
3) …|
|指标/目标|1) X users per month
2) Y click-through-rate per month
3) …|
|主要里程碑|1) v1.0 alpha
2) v1.0 beta
3)…|
|性能属性|1) X requests per second
2) Y concurrent users
3) …|
|权衡选项|Scope: Flexible
Resources: Fixed
Schedule: Firm|

（三）让赞助商参与

当问题出现时，主动向赞助商提供多种解决方案，让他们参与问题的解决。此外，偶尔邀请赞助商参加规划扑克会议，让他们了解团队的工作。当然，也要邀请他们参加定期的冲刺评审，给予团队反馈和鼓励。

（四）保持沟通

赞助商不喜欢被蒙在鼓里，Scrum 的透明度和可见性优势应充分利用。可以采取以下措施让赞助商了解项目情况：
- 带赞助商参观任务板，解释彩色便签的含义和燃尽图中的异常情况。
- 定期进行关于 Scrum 实践的演示或“午餐会”，如解释相对估算或理解用户故事。
- 分发书籍和文章，强调 Scrum 的主流趋势，让保守的组织感到安心。
- 每月发布 Scrum 成功故事更新，不仅关注定量指标，也强调定性的好处，如打破部门壁垒。
- 分享经验故事，让赞助商了解其他团队的成功案例。

（五）保持外交纪律

不要直接对赞助商说“不”，可以采用委婉的方式。例如，当赞助商提出在冲刺中更改用户故事的要求时，可以先表示可以做，但要说明这样做的影响，如破坏团队的节奏、可能导致冲刺取消、破坏 Scrum 流程等。然后建议在下次冲刺开始时处理该用户故事，这样往往能实现双赢。

在讨论将时间用于纯技术任务（如单元测试和重构）时，也可以使用其他成功公司的统计数据和先例来说服赞助商。例如，引用《华尔街日报》关于 eBay 的文章，说明处理技术债务的必要性。

总之，在敏捷开发中，无论是团队成员克服恐惧，还是管理者协调与赞助商的关系，都需要采取合适的方法和策略，以实现项目的成功。

三、应对恐惧与管理的策略总结

为了更清晰地总结上述内容，我们可以通过以下表格来梳理团队常见恐惧以及相应的应对策略：
|恐惧类型|具体表现|应对策略|
| ---- | ---- | ---- |
|对变革的恐惧|不喜欢被迫或彻底改变现有局面|将变革呈现为持续实验，让团队明白可共同调整|
|对暴露问题的恐惧|开发者抵触常规检查，部分成员害怕问题暴露|以积极方式定期检查，尽早发现问题|
|对犯错的恐惧|组织文化难以接受犯错，害怕影响项目|营造“心理安全”环境，鼓励冒险和创新|

同时，我们可以用 mermaid 格式的流程图来展示管理项目赞助商的流程：

graph LR
    A[建立关系] --> B[明确参考点]
    B --> C[让赞助商参与]
    C --> D[保持沟通]
    D --> E[保持外交纪律]

这个流程图清晰地展示了管理项目赞助商的步骤，从建立关系开始，逐步深入到各个关键环节，最后通过保持外交纪律来确保良好的合作关系。

四、实际案例分析

我们可以通过一个实际案例来进一步理解上述策略的应用。假设一个软件开发团队正在采用 Scrum 框架进行项目开发。

在项目初期，团队成员对变革存在恐惧。由于之前采用的是传统开发模式，突然转变为 Scrum 模式，大家对新的工作方式和流程感到陌生和不安。此时，团队领导将变革描述为一个实验，定期组织会议讨论变革的进展和问题，让团队成员参与到调整过程中。随着时间的推移，团队成员逐渐适应了新的模式，对变革的恐惧也逐渐消失。

在项目进行过程中，发现部分开发者对暴露问题存在抵触情绪。他们习惯了独自工作，不喜欢在站会等场合分享自己的工作情况。团队领导通过强调定期检查的积极意义，如能够及时发现问题、提高工作效率等，并以积极的方式进行检查，让开发者逐渐认识到检查的好处。同时，在检查过程中，也发现了个别成员存在工作不认真的情况，及时进行了处理，保证了项目的顺利进行。

在与项目赞助商的沟通方面，该团队也遇到了一些挑战。赞助商对 Scrum 模式不熟悉，认为团队的工作方式不够“忙碌”，担心项目进度和质量。团队的 ScrumMaster 主动与赞助商建立了定期的沟通机制，通过午餐会等方式向赞助商介绍项目的进展和 Scrum 模式的优势。同时，邀请赞助商参与规划扑克会议和冲刺评审，让他们亲身体验团队的工作。在赞助商提出一些不合理的要求时，ScrumMaster 采用委婉的方式进行沟通，说明可能带来的影响，并提出合理的建议。通过这些措施，赞助商逐渐理解并支持了团队的工作。