10招速成敏捷破坏者，炒掉你的老板

    很多人可能都听说过敏捷的Scrum框架，其中的一部分人可能了解Scrum为何物，有的可能已经在项目中实践过Scrum。 那么， 在本文中，我们来讨论一下有哪些方法可以拿来破坏你们的Scrum项目，炒掉你们的老板，然后开开心心裸辞。当然如果你珍惜现在的机会，那么本文可以告诉你如何让你的Scrum项目走向成功。

    本文不会详述Scrum基本原则，如Sprint，每日站会，可视化任务板和燃尽图等，因为如果你正在实施Scrum，显然这些原则都是你必须要做的事情，这里无需多言。

    1、没有回顾会或者过场面的回顾会
    如果没有Sprint回顾会，我们怎么可能把项目做得更好呢？显然回顾会是必需的，因为通过每次冲刺后的回顾，每个团队成员聚到一起，沟通上一次冲刺阶段我们有哪些事情做的比较好的，哪些事情可以做得更好。当然了，最重要的是我们必须检讨那些做得不好的事情，特别是错误，然后从中吸取教训，制定改善方案，在下一个冲刺阶段去改进。如果不这样做，那么回顾可以说是没有多大意义的。

    2、糟糕的产品负责人（Product Owner）
    产品负责人（Product Owner）要时刻处于就绪的状态，参加到每日站会，Sprint回顾会和Sprint计划会，但产品负责人不应该在Sprint计划里去估算待办事项，因为待办事项的估算是团队的责任，是团队一起去估算的。产品负责人要能够根据业务和情况的需要对待办事项进行优先级排序。产品负责人管理产品愿景、发布路线图和投资回报。并以一种足够清晰的方式去阐述用户故事，让团队成员能够准确的迅速的明白其中的意思。Sprint待办事项中不应出现正在进行变更的任务。

    3、糟糕的敏捷负责人（Scrum Master）
    敏捷负责人（Scrum Master）不是团队的领导，这一点必须要注意了，因为敏捷其中一个基本原则是：团队信仰自我管理并支持自我管理，因此Scrum Master并不是一个团队的领导角色，而是在团队需要的时候，作为一个领航者引导团队、管理流程、推动尽早交付客户价值。如果团队成员没能通过讨论达成一致，Scrum Master应该做出最终的决定。Scrum Master应该能够罗列出限制团队效率和进展的障碍清单，并尽快消除这些障碍，让团队保持足够专注，并通过持续改进，保持各项事情顺利进行。
任务不应分配给成员，成员应该主动去接任务。

    4、Scrum会议耗时太长
    在每日站会中，每个成员都应该说出昨天做了什么，今天将做什么以及遇到什么障碍了，这就是站会全部的内容。站立不应该用来讨论问题或者唠嗑其它无关事情，陈述内容不必提供详细信息。如果需要成员提供详细信息，务必在站会结束后单独详聊。站会时间尽量不要超过10或15分钟，具体情况还要取决于团队规模（如果团队人数太多咋办，可以参考亚马逊两块披萨的故事）。
回顾会和Sprint计划会议也应该限制在一定的时间范围。
坚持Scrum会议的精髓，不要会议搞得又臭又长。Scrum虽然是一个很有趣的框架，但它终究不是一个游乐场，基本原则要遵守。

    5、完成的错误定义
    在每个Sprint结束时，生产的软件产品应该是处于往生产发布就绪状态，随时可以演示。这就要求软件必须进行过测试，不仅是要通过单元测试和集成测试，还要通过用户测试/手工测试。生产软件是一个复杂的活动，对于所有的团队成员来说，确切的理解对于给予的项目来说什么是“完成”了是非常重要的。

    6、没有快速跟踪
    Scrum Master应跟踪团队速度，如果团队前进速度放慢了，Scrum Master必须采取一些措施，通过著名的丰田TPS系统5问分析法或Ishikawa鱼骨图定位到问题根本原因。

    7、Sprint里的瀑布（交付半成品）
    100％完成75%的故事胜过完成100％故事的75％（完成定义参考第5点），因为后者交付的都是半成品，不可靠甚至不可用的产品。故事是属于整个团队拥有的，不是个人，测试人员也是团队的一员。

    8、积累技术债务
    必须要避免技术债务，软件大师Martin Fowler形容技术债务是“因为选择了快速但很脏的技术实现，在未来的开发里我们就不得不付出额外的工作去修复”，否则会在最后出现更多缺陷。在技术债务的影响和快速交付的要求之间可以平衡处理，但是尽量把最核心的技术债务在本次迭代完成，常用的做法是把技术债务作为技术需求对待。重构（或者重新设计）应该在需要时立即进行，因为如果在最后项目完成阶段才去做这些事情，花费时间太多成本太高了，越晚修复成本越高。BUG要尽快修复。

    9、中断/绕过产品负责人（Product Owner）
    团队应该保持专注，也就是说太多的中断将会影响团队交付。当然可以要求团队成员中途来支持一下别的事情，但如果是新功能应向产品负责人提出，而不是绕过产品负责人直接向成员提出实现新功能的要求，应该由产品负责人将新功能需求添加到待办事项中并重新考虑优先级。如果这是一项重要功能，产品负责人可以安排团队在下一次冲刺结束时交付该功能。

    10、没有分析/文档
    Scrum并不意味着可以不进行分析或者不应该编写文档了，只是分析和记录文档的方式略有不同：这是一个持续过程。待办事项里的故事点应该要足够的清晰详细，以便团队在Sprint计划会中进行任务拆分和任务估算（故事点将在sprint中去实施，所以它要足够的详细才能保证准时交付）。故事点在项目开始时不应过于详细（但仍然要清晰），但在创建待办事项时需要估算故事点要其必须足够详细。

    给想要实施Scrum并且想成功实施的建议/结论：
    Scrum不是一颗银弹，没有一种方法可以定义N多个规则然后就可以解决所有问题。相反，它是一个定义了一些最佳实践的敏捷框架。当然，你必须遵守其基本原则才能使其发挥作用，忌讳一上来就把框架流程修改得面目全非，并美其名曰结合自身特性实施Scrum，其实你可能并没有通过正确的实践来验证标准的Scrum框架并不适配你的项目。但是具体如何实施（比如我们什么时候开每日站会，任务卡怎么设计，......）取决于你，可能因项目而异。

（扫一扫关注本文公众号）