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
1703950914
经过了1年左右的敏捷实践，已经有5％的团队敏捷成熟度达到L2（指的是敏捷成熟度，L0最低，L2最高）、80％达到L1、敏捷成熟度最低的L0也只剩下15％左右。此时，敏捷专家组的成员在思考这些问题：还有没有办法做到更快？或者说更灵活地受理需求？软件的质量也能够保证。回答是肯定的，于是敏捷专家小组，又开始了夜总会，对看板（Kanban）敏捷方法进行了深度探讨。
1703950915
1703950916
在1号店实施Scrum一年半的时候，开展了对看板的实践。看板体系中同样包括了成熟度模型、看板Base rule，在此基础上增加持续集成、电子看板等工具，以确保成熟度高的团队以更快速的交付、更灵活的反应支持业务的发展。
1703950917
1703950918
1号店的敏捷之路还在继续，其中的一些实践经验对大家还是有借鉴作用的，这些探索对Scrum、看板在国内的发展和普及有着深远的意义，也愿意把这一路走来的经验跟大家分享，共同进步。
1703950919
1703950920
1703950921
1703950922
1703950923
技术管理之巅：如何从零打造高质效互联网技术团队？ [:1703949717]
1703950924
技术管理之巅：如何从零打造高质效互联网技术团队？ 4.2 互联网项目怎么管
1703950925
1703950926
技术管理之巅：如何从零打造高质效互联网技术团队？ [:1703949718]
1703950927
4.2.1 “微管理”让项目管理更高效
1703950928
1703950929
前面已经提到，互联网公司的产品开发是以产品敏捷为主、项目管理为补充的，下面我们将详细介绍互联网项目管理的方法。
1703950930
1703950931
微管理，指的是在互联网下的项目管理方法，将经典的PMP（Project Management Professional，项目管理专业资格认证）项目管理体系进行裁剪，以适应互联网项目周期短、需求变化快、跨团队协作多等特点。微管理的本质是将管理变成服务，调动项目成员的主观意识，为共同目标的达成而努力。