06 | 规模化推广：复制粘贴试点的经验就够了吗？

作者回复: 因为管理实践是后面一切具体技术实践的基础，基于篇幅原因，我在这里就只展开谈如何在管理实践上探索团队间的敏捷。具体到怎么做上，主要有下面几个方面。  定义了一系列关于业务分析师的沟通策略和沟通机制，来在“做什么”上的目标对齐，即产品目标对齐。例如产品团队中，业务分析师每天有自己的站立会议，沟通各自的产品工作，这样来保证不同团队间的产品工作内容是可以协同的，既不会让目标分解后有产品内容落掉，也不会有做重复的；而到Scrum团队中，业务分析师会定期跟团队开需求梳理会议，也会有需求做完后的评审会议，平时也有跟团队成员的不定时沟通，例如沟通用户故事的内容和验收准则等。 这是因为，在组织中，业务分析师在产品管理中起到了承上启下的作用。他承担了两部分工作，一个是在产品团队里，定期聚在一起来看各自的产品目标分解，来完善自己小团队需要做的产品细节内容，另一个是要到各自的Scrum团队去，给Scrum团队成员讲解需求细节等等，以便于团队能够正确理解需求细节并在此基础上正确实施。  定期的产品集体计划会议，保证在“怎么做”上的目标对齐。在这个会议上，产品负责人来给大家宣讲未来两个月的产品目标，并简单介绍产品主要要完成的功能；各个业务分析师把各自团队需要的做的细化需求展示给他们各自的团队，该需求列表是排好优先级的；Scrum团队对需求条目进行粗略估算，估算完毕大家根据各自的产能来进行4个迭代的需求排步，在排布的过程中，识别各个团队之间的依赖；在做排布的过程中，各团队的Scrum Master要聚到一起来看依赖的情况，并一起做一张依赖关系表和依赖的开发安排。在会议结束的时候，大家一起制定了未来2个月的迭代计划，识别了各个团队之间的依赖，并在会议结束的时候将团队依赖做到看板上，以便后续管理依赖。 我们的产品集体计划会议，类似于Safe的增量计划会（PI Planning），不过，我们没有做3个月长度的计划，而是缩短为2个月，因为团队还没有能力做更长时间的规划和预判。我们也没有全盘复制SaFe里的关于这个会议的全部内容，而是根据实际情况做了一些修改。例如我们没有选择集体澄清需求，而是在正式开这个会议的时间之前，让各个小团队自己先理解各个小团队的需求，这样我们整体会议就不需要2天的时间，而是缩短为1天。  定期的团队的Scrum Master之间的Scrum of Scrum会议，来沟通大家各自的进展。只将团队间的依赖关系做到看板上，这是不够的，更多的还需要在开发过程中，及时地跟进依赖的开发进度。所以我们安排了定期的团队的Scrum Master之间的Scrum of Scrum会议来沟通大家各自的进展，这个会议一般在一周中安排2-3次，如果团队间的依赖开发有延迟，就会提前预警。

作者回复: 产品管理强调What，也就是做的什么产品。重点在需求管理，计划管理，发布管理。产品管理既关注产品的具体形式，也关注产品实现的过程，也要对最终使用产品的用户负责。 而项目管理强调How，怎么做，主要是任务管理，侧重的是如何实现这些需求。项目管理更关心达成项目目标实现的过程。

作者回复: 有些基本点是相似的，因为都要解决团队间的沟通问题等等。

作者回复: 首先是这样，可以有在线工具管理起来，比方说Jira，每个小团队每天都会更新，所以进度都可以在工具上显示出来，只要登录在线工具，就可以看到进度情况；再者为了更好地管理风险，以及促进团队之间的协同，可以建立一个小组之间的沟通机制，隔几天让每个小组的负责人碰一下面，沟通一下依赖的进度情况，以及是否有风险等等。

作者回复: 抱歉，这个问题我有点没搞明白，“和他们自身业务理解透彻程度把控这块很难搞”这个是指什么？