1703950864
再次，是消除异地团队的陌生感，推荐采用远程视频工具进行异地会议，让团队成员做自我介绍，增进彼此的了解。另外，有条件的话可以让团队成员出差，跟团队面对面工作一段时间。
1703950865
1703950866
最后，异地团队需要增加Demo的频次，以便需求提出人更早地参与到成果物的确认当中，及时纠正因异地沟通产生的理解上的偏差。
1703950867
1703950868
技术管理之巅：如何从零打造高质效互联网技术团队？ [:1703949715]
1703950869
4.1.2 看板（Kanban）适合哪些技术团队
1703950870
1703950871
看板和Scrum是敏捷体系中的不同实践方式，看板更强调单个可交付物的开发周期，所以能够缩短“idea to market”的时间，这一点上跟Scrum要求的固定迭代周期相比，管理的粒度更细一些。看板给业务方的感觉是“这个功能做完就上线，真快”，而Scrum给人的感觉是“这次Sprint的10个功能一起完成了，我的这个功能才能够跟着上线”，想想就知道，哪种方式更受到业务方欢迎了。
1703950872
1703950873
看板的特点是工作流程的形象化，通常会把工作细分成多个任务，写在卡片上，贴在墙上。限制“在制品”（Work In Progress，简称 WIP），明确设定限制在每个状态下同一时间能有多少工作任务。度量生产周期（即完成一个任务的平均时间），优化开发过程，缩短开发周期和使开发时间更易于预测。如图4-2所示是典型的看板，将工作过程完全可视化，很直观地告诉团队，当前的效率瓶颈在哪里，团队一起去改善，以便开发过程更顺畅，效率提升更快。
1703950874
1703950875
1703950876
1703950877
1703950878
图4-2 看板工作墙
1703950879
1703950880
为了更好地区分看板和Scrum，我们来看看它们究竟有哪些共同点和不同点。
1703950881
1703950882
首先，它们的是共同点：两者都符合精益和敏捷思想，都使用“拉动式”安排日程，都限制开发中的工作数目，通过透明度来驱动过程改进，都致力于可交付的软件产品，都基于自我组织团队，都要求把工作细分，发布计划都基于经验数据，并且持续优化。
1703950883
1703950884
接下来，我们通过表4-1来对比一下看板和Scrum的不同点。请大家关注标“★”的内容，这些是看板最显著的特征。
1703950885
1703950886
表4-1 看板和Scrum的对比
1703950887
1703950888
Scrum 看板 要求定时迭代 ★没指定定时迭代，可以分开计划、发布、过程改进，可以事件驱动而不是限定时限 团队在每个迭代承诺一定数目的工作 承诺不是必需的 以速度（Velocity）作为计划和过程改进的度量数据 使用开发周期作为计划和过程改进的度量数据 指定跨功能团队 没有指定跨功能团队，也允许专门团队 工作任务细分，可在一个迭代中完成 ★没有指定工作任务大小 指定使用燃尽图 没有指定任何图表 间接限制开发中工作（每个迭代） 设定开发中工作的限制（每个工作流程状态） 规定估算过程 没有指定任何估算方式 在迭代中不能加入新工作任务 ★只要生产力允许，可以随时加工作任务 由单一团队负责Sprint Backlog 多个团队和团员分享看板 指定三个角色（产品负责人/Scrum Master/团队） ★没有指定任何团队角色 Scrum Board在每个迭代后重设 看板反映持久开发情况 规定优先化的Product Backlog ★优先级是非必需的 从表4-1可以看出，在迭代周期上，Scrum要求有固定的周期，而看板没有固定周期；在工作任务的细分上，Scrum要求细分任务，并且在一个迭代内完成，而看板没有规定任务的大小；在是否允许插入任务上，Scrum不鼓励在Sprint中插入任务，而看板允许随时插入优先级更高的任务；在指定角色方面，Scrum要求有Product Owner、Scrum Master等角色，看板没有指定任何角色；在任务优先级上，Scrum要求Product Backlog里的任务有唯一优先级，而看板不要求任务优先级。
1703950889
1703950890
以上我们了解了Scrum和看板的相同点和不同点，那么究竟什么样的开发团队适合用看板模式？从上面的总结可以看出，看板对开发团队的整体素质要求比较高，看板能够更快速地交付产品，适合创新型、需求变动非常大的产品开发。所以建议实施看板的团队，至少有比较懂敏捷开发的人作为教练，或者团队已经实施过Scrum，并且成熟度比较高，才可以尝试看板模式。
1703950891
1703950892
技术管理之巅：如何从零打造高质效互联网技术团队？ [:1703949716]
1703950893
4.1.3 最佳实践案例：电商如何做Scrum和看板
1703950894
1703950895
案例4-1 电商如何做Scrum和看板
1703950896
1703950897
我们通过国内大型电商公司1号店，来看看他们是如何做Scrum和看板的，如图4-3所示，这是1号店敏捷开发的历程。
1703950898
1703950899
1703950900
1703950901
1703950902
图4-3 1号店的敏捷开发历程
1703950903
1703950904
1号店的敏捷实践，始于2013年初。成立了10余人的敏捷专家组，他们的职责是制定1号店敏捷成熟度模型、敏捷Base rule、担任敏捷教练、将敏捷实施到所有团队。小组成员平时都有各自的工作，利用下班时间进行讨论和开展工作，这一工作模式被他们称为“夜总会”，经过两个月的反复讨论，敏捷成熟度模型、敏捷Base rule已经形成，以Scrum为敏捷原型，并且根据1号店的实际情况，对一些具体实践上进行了优化，接下来就开始在开发团队中试点敏捷开发了。
1703950905
1703950906
第一次的敏捷开发试点，大约有6个开发小组加入到试点当中，这些小组里对敏捷的理解参差不齐，选择这些团队是想验证敏捷成熟度模式、敏捷Base rule在这些团队中是否适用。敏捷专家小组指派成员到开发小组中担任敏捷教练。
1703950907
1703950908
经过2～3个月的试点，积累了足够的反馈意见，对敏捷体系进行了修订。第二次敏捷试点也随即开始，这次大约有30几个开发小组加入到试点当中，占整个技术部的50％。为了在技术部里形成敏捷的氛围、普及敏捷理念，组织了敏捷基础培训、敏捷沙龙、最佳实践分享，并且让敏捷专家走出公司，跟同行学习和交流。
1703950909
1703950910
敏捷开发经过半年的试点，认为敏捷体系已经足够成熟，并且从业务方的反馈来看，敏捷确实缩短了产品交付的时间，很好地支持了业务的发展。
1703950911
1703950912
于是1号店技术部，进入了全民敏捷的时代。随之改变的是技术部对开发过程的度量体系，建立了一套基于敏捷的度量标准，例如DoD（Feature的Defination of Done）达到率、迭代按时率、敏捷成熟度等。
1703950913