关于我
加入ThoughtWorks之前，笔者曾有幸参与了几家大型企业IT部门项目管理和组织级敏捷转型咨询。作为一个曾经的PMO咨询顾问和敏捷教练，我深知敏捷转型在企业中落地的艰难。其难度不仅在传统工程实践的习惯的转变，更由于组织结构以及业务流程带来的挑战。在加入 ThoughtWorks之后，我在以 BA（业务分析师）的身份工作的同时，对敏捷实践的落地以及敏捷转型的实际问题也有了更深的理解。
在作为BA支持了几个项目的交付落地以后，我发现由于组织结构或经费等等原因，大多数软件交付的团队是没有专门的敏捷教练的。而BA作为团队中重要的组织协调者，在帮助项目梳理需求，跟进需求落地的同时，还需要帮助团队进行敏捷成熟度的提升，以确保交付更顺利地进行。无论BA是在客户方的团队还是Thoughtworks内部的团队里工作，都是如此。
故事背景
2017年6月，我参与了某大型房地产互联网企业在东南亚地区的收购项目。该房地产互联网公司和ThoughtWorks合作多年，在敏捷工程实践上已经有了很深的积累。但刚被该公司收购的不久的亚洲各个互联网公司的敏捷转型刚刚起步，成熟度还比较低。在加入目标公司团队以后，我发现团队即使在用JIRA作为Kanban工具来管理日常工作，但对于敏捷实践、理念的理解却不清晰或者存在许多误区，变成了“形式上的敏捷”。例如：
1. 团队没有故事卡 kick-off 和desk-check，开发工程师直接把故事卡拿到自己的名下开始工作。在开发完成后没有desk-check，直接合并代码，导致质量问题。
2. 比如团队对迭代目标以及需求的优先级不清楚，出现高优先级或高依赖的故事卡无人认领，低优先级的故事卡在开发中的情况。这导致下游对我们有依赖的团队工作被堵塞，无法进行。
3. 而由于团队成员分布在5个不同的国家或地区，且前后端完全分离，给项目内的沟通带来了天然的屏障。出现团队之间沟通不透明，工作进展不明确，干系人之间互相抱怨的情况。
而由于网站的上线日期近在咫尺，若想保障交付的顺利进行，作为BA仅仅着眼于需求的梳理是不够的，必须要扮演一部分敏捷教练的角色协助团队进行一些改进。否则，“持续交付功能”就变成了“持续交付 Bug”。
BA在促进团队的敏捷转型中能做什么呢？
BA不是专职的敏捷教练，在项目交付中主要的精力还是需要投入到本职工作中。但从敏捷转型的角度，BA能做的是从业务和需求出发对团队成员加以引导，帮助植入敏捷概念，引导敏捷实践在团队的落地。当然各个项目的背景和问题不尽相同，BA需要根据项目的实际情况去识别项目敏捷管理方面的问题，找到解决方案，并在实践中不断调整。在上文提到的互联网房地产网站的项目案例中，我从BA的角度出发，基于已发现的问题，在促进团队改进以及敏捷转型中识别了一些关键活动：
一、帮助团队建立敏捷的交付流程
我所加入的客户团队原先是没有QA和BA的，也没有完善的流程来管理一张故事卡片的生命周期。在 ThoughtWorks的BA和QA加入后，我们发现由于没有卡片的kick-off, 开发对于卡片的理解和卡片原本需要达到的目标容易不一致，导致返工; QA在测卡时不了解卡片内容和上下文，测试时也不知道如何开始。而没有desk-check, 开发做完卡直接挪到 in QA, QA发现问题需退回去重新开发，导致反复返工，影响交付效率。
我和QA小伙伴一起，提议在团队里执行完整的 “Kick-off to desk-check”流程。并且组织了一次会议和团队分享了一张故事卡的完整生命周期，以及各个角色在不同环节应该如何参与，并和团队就工作流程达成一致。如下图所示：
1. 我们将使用Backlog来管理还未进入当前迭代, 并且未开始分析的需求。
2. BA正在分析中的卡片会放在“In Analysis” 列。
3. 而已经分析清楚的卡片会放进“Ready for Dev”，按照优先级的高低从上至下的排列，开发在拿取卡片时也需要从上至下，先拿优先级高的卡片。
4. 在开发领卡以后，会由开发，BA， QA一起对卡片做kick-off, 保证大家对卡片内容和上下文的理解一致。
5. 在完成开发以后，开发人员需要发起desk-check，由QA, BA（我们团队是纯后端团队，所以没有UX，而对于前端或者端到端的团队来说，kick-off 和desk-check都是需要UX 参与的）一起检查结果是否符合验收标准，不符合标准的卡片将由开发人员继续修改，直到通过desk-check为止。
6. 卡片进入测试环节以后发现的问题，将由QA建Bug卡来跟踪，由引发bug的开发人员来修复。
7. 测试通过的卡片需要及时推送到beta环境，供依赖我们成果的web前端团队使用。（不同的团队和项目的在环境配置上的情况不同）
这一套流程的明确相当于给了团队一个工作协议，每个团队成员都按协议领取故事卡，并参与到卡片生命周期的不同环节中，最大限度的保障卡片交付的顺畅和质量。
二、推广正确的敏捷实践
除了梳理和确立流程，BA在一个团队的敏捷实践的引导上也起着至关重要的作用。BA经常需要作为引导者带领团队进行每迭代一次的迭代计划会议，或是对于史诗故事（ Epic Story）或者用户故事（User Story）的工作量估算，等等。当然团队里还存在很多技术上的敏捷实践，比如结对编程，持续集成等，这些都由团队的技术负责人（通常称tech lead）来主导，在此不多做赘述。
在加入了该项目以后，我发现团队没有迭代计划会议，导致团队对于接下来要做的工作的优先级不清楚，而只有部分成员清楚接下来工作需求和技术方案。为了向团队澄清接下来工作的优先级和具体需求，以下几件事情势在必行：
1. 确定接下来的上线计划，梳理团队工作的优先级
团队工作的优先级是和整个项目的优先级紧密联系的。而该项目是一个截止时间驱动型（Deadline Driven）的项目，因此项目的优先级就需要参考上线计划。我从交付负责人处拿到了各个站点的上线计划。从上线计划（从下图）则可以轻易的识别出，在当时的时间点（2017年7月），团队的第一优先级就是支持香港站点上线了。
但在团队的一份已有的需求列表上，优先级却是按如下的方式排列的：
这个列表会使人困惑。按照各站点上线的时间表，香港站的开发时间只剩不到一个月了，虽然各个站点在功能模块上大同小异，但目前显然没有那么多时间让我们一蹴而就的完成所有站点的工作量。而且由于我所在的团队负责的是中间API层的工作，网页前端的开发对我们的成果是强依赖关系，API层的工作不完成，将直接影响网页前端的开发甚至站点的按时上线。这个时候团队要做的是聚焦在香港站上线的支持上，其他工作都需要往后排。
在得到客户方交付负责人的同意后，我开始根据各个站点的上线时间表重新整理优先级。整理后的需求列表如下：
团队在香港站上线前需要支持的工作放在第一优先级。其他功能根据各个站点的上线时间一一往后排，放进backlog，暂时不用关注。
2. 定期召开迭代计划会议，向团队澄清迭代目标和需求
在理清楚团队接下里的工作内容和优先级以后，就需要向整个团队澄清传达了，保证整个团队对于目标和需求的理解一致。因此，迭代会议是敏捷交付团队不可或缺的过程。而由于团队之前没有迭代计划会议的惯例，BA需要和交付负责人以及团队就开会的原因和目标达成一致并设定会议时间，环节。
此外，由于团队不熟悉工作量估算的方法，在迭代会议中，BA还需要协助团队快速选择一种合适的估算方法，找到工作量估算的基线（如确定某个故事卡为1个故事点，或者一个标准人天等），并通过工作量相对大小的对比来进行工作量估算。这样做的目的是通过几个迭代的积累，了解团队的工作速率，为以后的迭代计划设立参照。
三、促进信息的可视化，加强各团队之间以及和重要干系人的沟通
面对面的单点沟通往往是最顺畅的，而在同一个地点工作的小团队（如，5-8人）的沟通也往往不成问题。但由于客户组织结构的特殊性，项目是由分布在5个不同的国家和地区的团队组成的，如墨尔本，马来西亚，中国西安，印尼和香港；而且前后端完全分离（前端团队，中间层API团队，以及后端团队完全分开）。除了语言和文化会造成一定的障碍以外，团队成员的对敏捷工作流程的差异给项目的沟通增加了更多的难度。
作为BA刚加入团队时，我偶然会听到一些其它团队对我所在团队的抱怨，大意是前端团队完全不知道我所在的API团队在做什么，Jira看板也看不懂，进度也不明确。经过分析：我发现原因主要有两个。
1. 前端，API，后端三个团队的依赖太强，但各个团队的进度未充分可视化。
2. 未及时和各干系人做好同步。
由于组织架构的关系，项目里各团队之间的依赖关系是特别强的，如下图所示：
一旦后端团队的工作不完成，API 团队就无法开始工作，因此前端的需求也无法开始开发。如果多边通信结构中信息传递一旦出现障碍，还会引发其它的状况。例如曾经出现过后端或者 API 团队的工作已经完成了，而前端团队并不知情的情况。
作为BA，在这种场景下需要做两件事情：
1. 建立端到端的史诗故事看板（Epic kanban），向其他团队可视化进度。由于API团队的故事卡并不是严格意义上的用户故事，而是技术任务卡。因此当其他团队或干系人想要了解进展时，是很难直接从卡片的层面上识别某功能是否已经支持了。为了更好的统筹需求，可视化进展，一个端到端的史诗看板就非常必要了。有了这个看板并及时更新，前端团队就可以快速了解又有哪些需求的后端被解锁，前端可以开始开发了。
2. 在每天的项目级站立会上及时更新团队进展。项目级站会又称 Scrum of Scrums，项目的PO，交付负责人，BA等重要干系人参加。项目上决定的传达，各团队之间的信息交换都会在这个会议上发生，所以这是一个沟通进展和风险的最佳场合。除了利用看板可视化进度以外，再在这个会议上需要同步进度和风险。在这样的双重措施之下，所有的集成事务一目了然，提升了总体进度的透明度。
写在最后
从业务层面，BA是需求的开发者和桥梁；从团队运转的层面，BA是重要的组织协调者。在团队没有专职敏捷教练的情况下，BA在做好需求梳理的同时，适当的进行敏捷实践的引导以及敏捷理念的传达，必定能帮助更顺利的交付，给团队敏捷成熟度的发展助力。
该房地产网站公司的案例只是我作为BA在单一的项目实践中的体会总结。根据不同的项目状况，BA在促进团队发展，以及敏捷转型中还可以做更多。当然实施起来可能并没有那么容易，我们需要更多的时间，更多的引导和实践来逐渐培养团队的敏捷意识。小团队的敏捷转型本质上是一种自下而上推进组织级敏捷转型的方式，如果团队内的各个角色都一起努力，所有团队一起来做，组织级敏捷转型的实现也就不远了。