让我们从一个真实的故事讲起吧：

时间：2011年夏天一个炎热的星期二。

地点：巴西，圣保罗市，圣保罗大街某栋办公楼的某个会议室。

事件（更确切地说是仪式）：审阅为某金融机构所做的Scrum项目的第七个Sprint。审阅过程中，开发团队会向客户展示该sprint中完成的工作（主要是开发了一些指定的功能）。人物：围坐在桌边的11个人，分成如下几组：

客户：

• 一位项目经理（灰色）
• 两位遗留系统专家（灰色）
• 三位最终用户（使用产品的人）（绿色）

供应商（我们）：

• Scrum Master（本项目中不是开发人员）（灰色）
• 我，从客户角度作为Agile BA，从技术团队角度则是PO（灰色）
• 三位程序员（整个团队有六个人，但审阅会在客户公司进行，我们又没有面包车，所以没把整个团队拉过来）（红色）

座位安排如下图所示：

有趣的是，最终用户（绿色）和程序员（红色） 面对面而坐，可是没有人要求他们这样。

落座完毕，程序员开始介绍。他们一边展示按照客户的布局要求设计的界面，一边演示上次计划会中选定开发的各种操作。突然，客户开始提问。一问一答之间，谈论的内容便也信马由缰起来。整个过程我只是默默旁观。

我注意到，我们——那些灰色的圆圈们——本来应该主持会议、控制会议节奏、提出议题的，此时却惜字如金，不说一句废话。

我又注意到，在交谈中程序员所用的字眼都是面向业务的，根本不需要翻译。

更有趣的是，一位最终用户发现上一个Sprint遗漏了一些重要需求，这些需求自然赶不上即将发布的版本。

这种情况难免会发生，毕竟计划赶不上变化。对此，不同的项目管理方法采用不同的应对手段，对于Scrum来说，就必须推迟发布。当然，谁都不愿意这样，所以当推迟发布不可避免，推迟的时间就越短越好，最好控制在一个Sprint之内。

作为Agile BA/PO，我的工作主要是同时理解业务和正在开发的系统。换句话说，我需要和客户、最终用户打成一片，为他们的需求找到最经济的实现方式。系统中已有的大部分功能都是以这种方式确定下来的。但对于眼下这种情形，我能做什么呢？非常少。

出乎意料的是，开发团队利用他们的业务知识，客户利用他们对系统的了解，双方非常高效地商讨出了解决方案。这可是破天荒地头一回。

在这个过程中，我们这些“小灰”们只是偶尔提些建议，我则负责更新文档（其实这个工作在那个场合一点也不重要，只是在编写用户手册以及支持外部QA时有些用处）。

最有趣的是，我们正在讨论的是项目的第七个Sprint，鉴于我们的Sprint包括10个工作日，那意味着我们正在谈论的是大约105个日历天数的工作成果，也意味着项目伊始至今也不过3个月左右的时间。

撇开不谈那些实际的工作成果——在不到五个月的时间内完成了相当多的功能，同时系统架构、用户交互符合严格的标准，所有这些还都是以外包的形式完成——Scrum的应用还给我带了另一大好处：

在短时间内，我们创建了一个六人的开发团队，该团队不仅能从技术角度给出解决方案，而且能从业务的角度理解问题并做出反应。

我希望我能衡量这一好处的经济价值，但没那么简单，因为我们不仅造出了金蛋（运行的代码），而且培养出了能下金蛋的鹅（我们的团队）。

我们能有这样的成果归功于三方面的因素。首先是Scrum一直推崇的核心精神，我称之为“团队实体”——团队有责任在每个Sprint结束的时候，通过与有关各方的面对面交流，将解决方案进行交付。

这样的仪式缩短了距离，消除了偏见和疑虑，增进了心灵的沟通。程序员和客户开始用名字称呼对方（至少在巴西是这样），开会时也会纯粹因为关系亲近而坐在一块儿。

在我还是商业管理专业的本科生时，我学过一些不同的方法用以评估职业人士的工作表现，但是没有哪一种能像Scrum这样直观、公正。我觉得，顶多两个Sprint就可以让你了解一名职业人士是“猪”，还是“鸡”，或者更糟。

这也引申出我们的第二个因素——团队优化。正如人们所说的，“Scrum不能帮你解决问题，但可以帮你看清问题”。通过每天的例会、团队中任务的分配以及工作可视化工具的应用，例如我们使用的“ Sprint 看板（一个画板，上面展示了工作的进度和任务的分配）”，谁干得好谁干得差一目了然。

任何项目团队都需要管理：如果团队里有人只聊天不干活，那他/她会被要求离开项目组。如果在新的项目组，他/她还是如此，那抱歉，只能让他/她走路。

与解雇相比，开除出项目组没有那么严厉。这种事情也确实发生过几次，其中还有一位老兄不幸被解雇了，因为他在上一个项目中就被开除过。所有这些开除的决定都不是独断的或单方面做出的，所以不需要过多地解释，被开除的成员也通常心服口服，团队的气氛也没有因此变得紧张。

碰到这种事情发生，我就必须做两方面的工作。一是要让开发团队能畅所欲言地交流，甚至决定谁应该离开；二是要让客户理解开除组员的决定，虽然这会使得团队规模变小，甚至小过我们与客户约定的规模，但都是为了使项目能更好地开展。

我在两方都发起了信任投票，结果让我们清楚地看到，对于团队来说，小而精胜过大而滥。

第三个因素和Agile BA/PO的角色有直接的关系，就是我的“交付-价值”表的应用：

我常在我的课堂以及讲座上展示这张表格或者他的变体。它能帮助说明一个道理：虽然开发团队和业务团队之间有个中间人的角色（例如Agile BA/PO），但双方绝对不应该彼此疏远。

从开发团队的角度来说，Agile BA/PO是问题域（Problem Domain）的代表（调查研究之后），但开发团队也需要及时了解业务变化，同时业务上的问题也需要听取开发团队的意见。同理，虽然解决方案由开发团队负责，但BA/PO必须了解解决方案的最新情况，系统遇到问题也需要听取BA/PO的意见。

迭代开发的一大妙处是互动无所不在：在各种Scrum仪式上，包括计划会、每日例会和Sprint审阅会，甚至在Sprint开发进行期间也是如此。

这使得领域相关的信息能够以支持决策优化的动态过程形式自由地传播。可以说，迭代增进了交互。

我记得在同一个项目期间，有一天我在拜访客户时接到了一个程序员的电话。他想对某个需求的实现方法做一些技术变更，特地打电话问问我的意见。交谈虽只持续了2分钟，却增进了我们之间的联系，让我了解到一种能更好解决问题的办法，而且产生了一种积极的、持久的共识。

简单来说就是，即使责任已经很明确，我们仍要尽力消除双方的交流障碍——一方事事从价值出发，一方时时以交付为重。

在这篇文章里我一直谈论Scrum，但上下文提到的很多有趣的东西都是来自于精益软件开发概念。在这篇文章的第二部分，我将以商业管理专业科班的身份阐述为什么作为Agile BA/PO应该希望自己变得多余。

问题在于：你敢不敢？