今天花了大概90分钟读了《看板和Scrum相得益彰》一书，让我击节赞叹，确实是一本好书！
1 本书很薄。薄的书能让人有耐心读完。
2 本书言简意赅，观点明确。能让人产生共鸣，能解惑。
3 充满了干货，读后让人有收获，可实际操作。
对于我的收获整理如下：
CH1-1 Scrum方法：团队拆小，任务拆小，时间拆小；看板：可视化、WIP、 度量；
CH2-1 Scrum与看板都是工具，无所谓好坏，只有在某种场景下是否适用；
CH2-2 工具不是万能的，都有局限性；
CH2-3 Scrum要求的规则比看板更多；
CH2-4 RUP做减法，Scrum等方法需要做加法；
CH2-5 要解决现实问题，需要多种敏捷方法联合使用；
CH3-1 Scrum中定义了角色，看板则没有；
CH3-2 少就是多，当犹豫不决时，先少做；
CH4-1 Scrum规定了迭代是固定时长的，看板没有规定；
CH4-2 迭代周期、交付周期、回顾周期、策划周期可以不同；
CH5-1 看板按流程状态限制WIP，Scrum板是按迭代限制WIP上限，而不是每个状态的WIP上限；
CH5-2 WIP的上限可以是故事点，未必是故事数或任务数；
CH6-1 预定义的过程的不可行，都需要根据实际场景进行变化的经验控制；
CH6-2 Scrum、看板给了基本约束，实践中要自己验证，自己适配；
CH6-3 XP的快速反馈环的长度可以调整，可以自定义；
CH6-4 看板给的实时度量指标：平均生产周期，瓶颈；
CH6-5 WIP上限不是固定不变的，即使在一次迭代内也可以根据反馈及时调整；
CH7-1 Scrum在一次短周期迭代内需求不变；
CH7-2看板的原则是：一件出来，一件进去；
CH7-3 Scrum的平均响应时间是Sprint迭代周期的一半；
CH8-1 Scrum每次迭代结束清空重置板子给团队以成就感；
CH9-1 Scrum团队自管理自己的Scrum板，其他人无权改动；
CH9-2 看板不要求团队是跨职能的，看板不是某个团队独有，可以多个团队维护一个看板；
CH9-3 谁可以维护看板的哪些列，要定义好规则；
CH10-1 看板没有规定任务的颗粒度，可大可小，Scrum一般要求一个用户故事要一次迭代内完成；
CH11-1 Scrum估算了相对规模与工作量，度量了生产率；
CH11-2 有的团队甚至没有做估算，而是把任务拆分的大小近似相同即可！
CH12-1 产品Backlog与团队Backlog是两个不同的概念；
CH14-1 Scrum中需求的优先级在下次迭代时调整、生效，看板可以随时调整，甚至可以没有需求优先级；
CH14-2 Scrum强制了需求优先级，看板没有；Scrum要求了燃尽图，看板推荐燃起图；
CH15-1 如果一切顺畅，WIP的上限也就没用了；
CH15-2 看板有几列？列代表了状态，可以自己定！
CH15-3 太低的上限导致低生产率，太高的上限导致长生产周期！
CH15-4 看板的上限未必一定是必须！
CH19-1 大家都认为别人应该改变！手电筒现象；
CH20-1 Scrum与看板殊途同归，要解决的问题是相同，解决方法有差别；
CH21-1 启动会很重要，统一思想，统一认识；
CH22-1 不管哪种方法，要能解决问题；
CH23-1 实施看板方法要先做价值流分析；
CH23-2 看板并非一定在横向是工作流，也可以纵向是工作流，这也是一个很好的方法；
CH23-3 看板的每行，每列的含义要定义清楚；
CH25-1 不同的人想到的任务优先级可能是不同的，于是需要解决冲突；
CH25-2 为优先级低的，被顶替掉的任务设置一个溢出区；
CH26-1 超过1小时的任务放在看板上，琐碎的任务不放；
CH27-1 把故事点等同于人时是一个常见错误；
CH28-1 固定时间点开会的好处：例行工作，不会被其他事情给挤占掉时间；
CH28-2 可以在计划会议上讨论是否要更换WIP的上限设置；
CH29-1 赋能给团队，让团队自己找答案，不要替他们找答案；
CH29-2 策划会议的开法可以有多种，可以灵活处理；
CH29-3 在估算之前，先确定了故事的技术解决方案；
CH30-1 着眼于改进流程来识别度量元；
CH31-1 提升效率从团队齐心协力开始；
CH31-2 看板提升了整体透明度，促使思考更重要的问题；
CH32-1 没有从失败中吸取教训才是真的失败！
扫一扫
2277
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
