2020-01-07举一个由我们小团队主导的项目
在业务需求沟通后，我们发现需要ABC三个技术部门同时协同完成，于是
1.在第一时间询问ABC三个团队的产品负责人，了解他们的项目排期，是否有时间支持。其中A团队表示他们在我们的计划时间内目前没有新需求导入，BC均表示已有安排。
2.将技术团队沟通结果反馈我们对接的业务部门，业务部门表示优先级很高，所以请业务中心统一协调BC团队的对应业务部门调整需求优先级。
3.达成一致后，由我方团队发送项目立项邮件，抄送ABC团队产品及业务负责人，约定立项会议召开时间。
4.会议宣讲项目需求，及所需配合事项及我们的各时间节点期望。
5.会议明确我方主导，ABC辅助，明确产品，开发，测试对接负责人，明确沟通交流机制，每天下午5：00-6：00为集中答疑时间；如有优先级更高的问题，反馈至产品负责人协调。
6.会议后，我方团队与A、B、C三方团队分别细致拆分技术方案，达成共识，并共同确定各时间节点。
7.将项目排期邮件抄送全项目组。
8.成立项目组线上沟通群。
9.项目顺利上线展开 13- 2020-01-14请教，老师能讲一下针对问题3，制定的具体沟通策略、沟通机制吗？
作者回复: 因为管理实践是后面一切具体技术实践的基础，基于篇幅原因，我在这里就只展开谈如何在管理实践上探索团队间的敏捷。具体到怎么做上，主要有下面几个方面。
定义了一系列关于业务分析师的沟通策略和沟通机制，来在“做什么”上的目标对齐，即产品目标对齐。例如产品团队中，业务分析师每天有自己的站立会议，沟通各自的产品工作，这样来保证不同团队间的产品工作内容是可以协同的，既不会让目标分解后有产品内容落掉，也不会有做重复的；而到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次，如果团队间的依赖开发有延迟，就会提前预警。 4 
2020-01-15在我的印象里面，敏捷一般只适用于小团队，规模化推广的时候最难的应该就是团队间的敏捷和沟通。不过，我还是认为敏捷开发多少有一点精英倾向，如果人员的素质达不到的话，最好还是放慢节奏，逐步推进。
通过定制度和反馈机制来试图解决业务敏捷的问题，我觉的也是难点。如果业务部门比较强势的话，那么想要把业务拉到 IT 团队的敏捷开发过程中，应该是一件比较困难的事情。
团队间的敏捷实践，需要大量而有效的沟通，这个也不容易，特别是每个团队有不同的利益诉求。
如果将来有机会换工作，那么我也希望能够进入一个采用敏捷开发的团队，同时我更倾向于小团队，而不是大组织。
如果我在一个大型的研发组织，想要做敏捷的规模化推广，我觉的也只能让那些有敏捷意愿的团队去试点并实施，对于一些比较排斥敏捷的部门，那就由他们自己去探索。即使高层领导想敏捷，而一线开发团队不想要，那么也不能强推。如果能把瀑布流做好，其实也没什么不好。当然，比较理想的是，在试点和早期采用敏捷的团队影响下，组织内的人员都能够意识到敏捷的益处，并且在敏捷的基础设施比较齐备的情况下，愿意尝试，有意转型。展开 1 2
2020-01-09想请教老师，规模化敏捷和项目集管理是否有相似之处？感觉从单项目敏捷到一些有联系的项目，相互作用共同产生价值，这点和项目集的理念有点相似。作者回复: 有些基本点是相似的，因为都要解决团队间的沟通问题等等。
1
2020-02-02我们公司有140的研发 有 6 7 个业务团队 我们团队直接经常英文业务这些不对齐 迭代不一样 出现问题
2020-01-28我们是500人的研发团队规模化敏捷，团队间的依赖主要在需求收集阶段识别出来并提给相关方。
2020-01-27今天学习有感:
从小团队试点到团队之间协同，我相信通过敏捷教练或者专家的指导可以建立起来一套机制，但是我担忧这套机制如何长久维持，如何被监督执行下去？毕竟世界趋于不确定性(熵)
2020-01-15敏捷与DevOps关系？
2020-01-13没有规模化过
2020-01-12敏捷推广时确实是忽略了业务敏捷和团队间敏捷，造成项目落地效果不佳。当时为了让业务人员参与，确定每个业务有人员参与站立会议，但实际执行时业务人员参与度不高造成开发的预期有出入。团队间当时也安排定期回顾参与，但实际大家都是走了形式，造成团队间目标不一致，进而交付的东西业务团队不是很关心。- 2020-01-12感觉业务让开发人员之间协作 和他们自身业务理解透彻程度把控这块很难搞，这个痛点怎么解决才搞？老师
作者回复: 抱歉，这个问题我有点没搞明白，“和他们自身业务理解透彻程度把控这块很难搞”这个是指什么？