1704234532
1704234533
►日常管理工具
1704234534
1704234535
看板 是一个非常重要的实用工具，很多公司的办公区里都会有，在硅谷创新公司里也被广泛应用。比如，有一块写着当前迭代关键信息的白板，或者有一面用来粘贴任务卡片和便利贴的玻璃墙，如图8-2所示。
1704234536
1704234537
接着，再说一些Scrum实际应用的具体做法。
1704234538
1704234539
2015年下半年，我孵化的一个项目，采用的就是以Scrum为原型的敏捷方法。
1704234540
1704234541
1704234542
1704234543
1704234544
图8-2 我在硅谷某孵化器里拍的看板
1704234545
1704234546
当时的团队成员大部分只有1到3年的工作经验，缺乏足够的专业训练。所以在开始几周，花了很多时间跟大家一起定规矩，并最终制定出如图8-3所示的简化项目流程。
1704234547
1704234548
1704234549
1704234550
1704234551
图8-3 创业公司的简化项目流程
1704234552
1704234553
项目流程简化
1704234554
1704234555
角色的简化
1704234556
1704234557
首先，根据业务和团队的现状，对项目进行了合理的角色简化。这还是挺考验经验的，必须见过分工很细的团队，且能理解其中每个角色是怎么一步步分化出来，以及不同角色各自的设置目的，才能做好。当时这个项目的做法是：不区分交互和视觉，用全民测试代替专职测试，运维、DBA等全部由开发承担，前端职能单列出来，最终一共设置四个角色：产品、设计、前端、开发。
1704234558
1704234559
流程的简化
1704234560
1704234561
同样，需要见过更复杂的流程，知道每一个环节是为了防止出什么状况，才能合理地简化。最后，设置了四个关键节点。这些节点是除了产品、技术、运营之外的其他关键团队成员也要一起参与的，已经没法再减了。
1704234562
1704234563
►立项会议： 确定项目目的——为什么、做什么（时间控制在半小时以内）。
1704234564
1704234565
►需求评审： 确定项目怎么做（对相对较小的项目，可以和立项会议合并，总体时间控制在2小时以内）。
1704234566
1704234567
►功能评审： 简单地讲，就是在测试环境下演示一下产品，以确定做出来的是不是团队要的（1小时左右搞定）。
1704234568
1704234569
►发布上线： 确定产品是不是用户想要的，以及用户还要什么。通过获取用户反馈来让产品的优化形成一个螺旋上升的闭环。
1704234570
1704234571
以上说的是主流程，还有两个常见的分支流程也简单提一下。
1704234572
1704234573
►需求变更 ：这在项目过程中不可避免，一开始可以简化成某个人拍板，决定是否接受变更。
1704234574
1704234575
►日常需求： 即零散、随机出现的小需求。开始只掌握一点，即所有需求必须经过产品经理，运营等角色不能直接找开发，确保产品经理知道所有的需求信息，以便统筹安排。
1704234576
1704234577
文档的简化
1704234578
1704234579
在项目开始阶段，文档只保留PRD、设计稿、代码三件套，其他文档，都用看板、白纸加上拍照留存来解决。既然看板可以代替很多文档的职能，接下来就看看其在项目中的实际应用。
1704234580
1704234581
看板实践