如何结合Scrum和Kanban背景介绍by吴穹这篇文章背后的故事是这样的：某同学写了一篇比较Scrum和Kanban的文章。这是一个老话题了，最近有一些思考，感觉不吐不快。就想写一篇小文，拉上几位老友，一起和大家扯扯这个话题。比较Scrum和精益Kanban是一个伪命题Scrum是一个框架，在此框架中人们可以解决复杂的自适应难题，同时也能高效并创造性地交付尽可能高价值的产品。而精益看板是一组促进组织变革的思维（框架）。因此，不理解上述背景，而直接比较两者是可笑的。读者需要意识到，Scrum是一个交付框架，而精益看板是一组变革思维。Scrum相对具体，而精益看板相对抽象。Scrum的历史作用不可否认，在敏捷运动的发展过程中，Scrum起到了很大的作用。我把它称为跨越瀑布的拐棍。Scrum的3355框架，简单明了，对刚刚脱离瀑布开发模式的团队来说，比较容易适应。Scrum实施中的最大陷阱Scrum实施中有三个常见问题：1.Scrum成为小瀑布；2.团队职责混乱；3.忽视技术实践。下图就是Scrum实施成小瀑布的实例，例如10天Sprint被规划成2天需求澄清，2天设计，4天开发，2天测试。这样的后果往往是需求延期，开发时间不足，开发移交质量差，测试不充分等等。Scrum成功实施的关键是引入精益流动思想，保证每个BacklogItem独立流动，在10天迭代中基本保证每天都有BacklogItem完成可以移交测试。可惜的是，如此重要的原则在Scrum框架里面竟然没有提及，不能不说这是Scrum框架的一个重大缺陷。GitChatScrum实施的另一个常见问题是团队职责混乱，这是因为Scrum框架中给出了一个过分理想的角色模型：唯一产品负责人，自组织开发团队，不对交付结果负责的ScrumMaster。我见过的大多数团队都没法按照这样的组织结构运作，这种团队在Scrum中叫Scrum-but,特制没有严格按照Scrum要求运作的团队，Scrum不能保证其实施效果。这其实是一个非常好的卖假药逻辑，本药包治百病，只要每天连续服用25个小时，如不能按说明服用，服用无效不退款。实际上，不同企业有不同特点，我们应该做的是按照精益思想，分析价值流动中的问题，然后对症下药，调整优化组织结构。Scrum实施的另一个常见问题是忽视技术实践，在Scrum实施过程中未能同步推进。以至于最早XP社区，有所谓“不举”的Scrum的提法。Scrum实施过程中，一定要分析研发团队交付过程中面临的技术挑战，在Scrum实施过程中同步改进。用精益的思想指导Scrum实施给大家推荐三本书，在实施Scrum之前，你需要先去理解软件开发的本质，之...
