1703950850
1703950851
大多数互联网公司是以产品敏捷为主、项目敏捷为补充的，这个模式很好地解决了产品和大项目的开发管理问题。如图4-1所示是项目敏捷和产品敏捷协作图，开发需求分成两类，产品需求和项目需求，产品需求由各产品开发小组（图4-1中的Domain指的就是一个产品开发小组），用产品敏捷的方法进行开发工作；项目需求由项目经理采用项目敏捷的方法进行项目管理工作。
1703950852
1703950853
1703950854
1703950855
1703950856
图4-1 项目敏捷和产品敏捷
1703950857
1703950858
分布式敏捷，指的是由异地开发团队协作，进行敏捷开发的方法。传统的敏捷开发方法是强调敏捷开发小组在同一个办公室，集中开发，而实际工作当中，多地研发中心协同开发的现象是普遍存在的，分布式敏捷就是为了解决异地团队进行敏捷开发的场景而存在的。那么，异地团队进行敏捷开发会遇到哪些问题呢？
1703950859
1703950860
首先，日常的沟通问题是最突出的，一般来说需要使用视频电话、即时聊天工具、桌面共享软件来辅助日常的交流，沟通效果会有所提升。而对于管理人员来说，需要一套在线敏捷开发管理工具，以便随时了解异地团队的工作进展，这也要求团队成员把每天的工作进展，录入到敏捷开发管理工具中去。
1703950861
1703950862
其次，要建立高效的异地敏捷团队组织架构，前面的“3.4如何让异地团队更高效”章节中已经提到了解决方法，大家可以参考，这些方法包括高效的组织架构、消除网状沟通等。
1703950863
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
