单单Scrum是不够的

伴随着Scrum的实施,你若想取得长久的成功,需要的可不只是基础的框架。Scrum是故意这么设计的,它提供了框架结构作为起点,而它生来就能与其他的有效模式组合应用。

就像20世纪90年代晚期倡导的设计模式一样,一个模式可以被独立使用,也可以与其他模式组合使用。举个例子,命令模式和备忘录模式就可以组合起来构建一个高效的撤销/恢复系统。Scrum只是为一个团队设计的一种模式。它给了你最低限度的条条框框,确保你能运转起来。然而,在很多情况下,你需要吸纳其他的工具或模式,以构建更为有效的系统。

除了Scrum,你应该考虑:

  • 有效的敏捷工程实践——比如单元测试、持续集成、测试驱动开发、验收测试驱动开发(或者行为驱动开发)、结对编程等等。如果没有这些实践,日子久了,代码的健康度会越来越差!
  • 看板——一种用以在团队内部和组织层级间帮助沟通并改进工作流的工具。如果对组织内部的工作流没有一个良好的理解,我们可能会做出一个对局部有利但会伤害到整体的改变。
  • 组合管理——这是全局决策的艺术——业务聚焦,决定工作重点。组织需要通过组合管理来确保产品负责人理解主要的优先级,并确保团队是按照优先级顺序开展工作的。
  • 组织改进——Scrum实施过程中发现的很多问题,靠团队自身或者Scrum Master是无法解决的。组织需要成立一个旨在持续改进的专职团队来解决这些问题。
  • 内部团队协作——你怎样在多个团队之间协调工作?在Scrum之上再实施一层Scrum是最常用的模式,但它也未必是最好的选择。
  • 团队组织——你会怎样组织团队?按照组件来划分团队?还是成立全功能团队?还是采用Spotify模式(诸如小组、部落、公会等形式)?

没有最佳实践

Scrum原本可以把所有这些都纳入规范,但那样会与敏捷的一个重要观点背道而驰——没有最佳实践!在其他组织内部(或特定环境下)工作得好好的一种实践,你照搬过来却未必行得通。这种现象在大型组织内解决工作效率问题时尤为明显,而这类组织才刚有些可重复的模式浮现。即使一些固定的模式开始形成了(比如大规模Scrum、企业级Scrum等等),但在哪种特定的情况下采用哪种模式,这个问题仍然是不明确的。

最后,请记住:Scrum的诞生不是为了适应你当前的组织及其现有结构的。它意欲逼着我们去考虑:什么行得通?什么需要改进?

Scrum只是一个起点!

原文:SCRUM ALONE IS NOT ENOUGH
作者:MARK LEVISON

此条目发表在管理分类目录,贴了标签。将固定链接加入收藏夹。

发表评论