可持续的速度——怎么理解?如何实现?

“以可持续的速度工作”,这是《敏捷宣言》的原则之一,也常常是难以实现的一条。Agile Leader新闻组最近开始讨论可持续速度的相关话题。

什么才是真正“可持续的速度”,如何始终如一地达成可持续的速度,这是讨论围之展开的两个中心。

Bob Sarni引用敏捷原则,开启了这次讨论:“敏捷过程提倡可持续的开发。出资方、开发人员和用户应该能够保持恒久稳定的进展速度。”

他进一步说明:

在我与众多组织和团队的工作经验中,可持续的速度看来是这些团队和组织共同面临的问题。要维持可持续的速度,需要很多因素——产品的路线图和承诺、愿景、速度/流/节奏、工作与生活的平衡、可见性、企业文化、个人问题、信任、多任务,等等。

团队层面要做到可持续的速度难度更高,因为团队中每个人都有自己的可持续速度,并且影响团队的整体速度。

Manoj Vadakkan认为:无法以可持续速度工作,其问题在于,组织在实施敏捷实践时,没有深入理解背后的价值观和原则。

我看到的实施Scrum主要的问题在于:它被当做迭代过程实施,没有以原则和价值观做基础。不知道大家是否同意:可持续速度的问题,是我们的流程没有以速度为基础造成的诸多问题之一。

我担心的是:总体来说,关于这一点我们强调的还不够——不以敏捷的价值观和原则为基础,这个(Scrum)不会有成效。

其他人也同意:如果不以敏捷价值观为起点,敏捷和Scrum的转换将不可持续,团队和个人会面临精疲力竭的风险。Scott Duncan讲述了自己与大型组织工作的经验:

  1. 就我所知,他们现在希望人们可以“持续”的,称为“职业周”,比如50个小时,或是每天多加班2个小时,而且不会有加班费或任何补偿。
  2. 基于小时数的估算方法,假定人们每周高效工作至少40个小时(即使期望人们每周只工作40个小时),每个特性和需求都会以小时数估算,然 后团队中的人员数目乘以40,再乘以按周计算的开发时间段,再把得到的结果用需求和特性的小时数填满,这样团队和项目所有的小时数就被充满了。
  3. 相信真正的职业人士会“一切可能把工作完成”,因此并不真正关心可持续的理念。
  4. 着手工作时,假定所有的时间都已经被占用,因此任何没有事先规划的事件(比如变更、设计“发现”等)都会假定使用加班来吸收掉。

Manoj Vadakkan引用了自己在Scrum联盟网站上的一篇文章,他在其中的总结是:

当然,客户不关心你的雇员是否每天长时间工作,可你是否跟他们讨论过产出代码的质量?试着告诉他们不利一面,他们也许会开始关心。长期看来,客户如果想在 下个版本中改变代码,他们才是付账的人。你是否认为可持续速度值得拥有?也许我们应该跟客户商量商量。也许他们会同意质量很重要,也许不然。有一点可以确 定:我们不能替他们拿主意。

Karen Greaves基于自己的经验,提供了具体建议:

我现在在自己组织内的工作方式是:

  1. 断开工作小时数和工作效率或是交付价值之间的联系。作为管理人员,永远不要度量工作小时数。也就是说,不要用工时表,不要有固定的工作小时数,甚至不要暗示员工“必须”每天工作8小时。更应该做的,是设定人们应该交付的成果的期望值。
  2. 把关注点放在完成工作上,而不是保持忙碌。如果你今天工作不在状态,不如回家。如果你今天小宇宙爆发,而且工作不断取得进展,那就继续下去。引用一下Kent Beck那句话:“如果你不想工作,那么你在办公室里度过的每一个小时,都等于是加班。”
  3. 永远不要让人们周末加班。
  4. 提供一个有吸引力的目标,这可以激励人们达成它,而不是编造一个无法实现的截止日期。
  5. 不要把工作安排得太紧。留出人们估计无法如常工作的时间。我们有特快专递日、实验室日,还有正常的周五学习时间。

目前来看,这些做法在我的团队内效果还不错,虽然业务人员很难接受,但是我对它们的坚持还是有所收获。当我一年多前接受我现在的工作时,团队会定期在周末 和深夜加班。去年,我们可以做到在每个发布日期当天的下午6点之前发布版本,而且从未在周末加过班。质量改进了,大家的工作满意度提升了,人员流失率也降 低了。工作效率虽然有所波动,但与其直接相关的,是版本发布的目标和规划。

在Agile Leader讨论组外,还有一些人就可持续速度的话题发表了自己的看法。

Bob Hartman(“Agilebob”)有一篇文章《刚接触敏捷吗?从以可持续的速度工作开始吧》。他在其中指出,如果无法做到以可持续的速度工作会有什么后果:

  1. 缺陷会增加。疲劳的团队会产生更多缺陷。
  2. 工作产出会降低。疲劳的团队在更多时间内完成的工作更少!
  3. 士气会大幅降低。这会导致雇员们在项目的最低潮期时离职。
  4. 互相责备的游戏会更普遍。(你之前没说X,所以不是我们的错;我当时就说了来着;当时没那么做;当时就那么做了……)
  5. 团队开始抛弃优秀实践,转而选择“看起来”更快的时间。抱歉,比起只是写代码,然后抛给墙那边的QA去测试来说,测试驱动开发(TDD)确实更快!

他为敏捷团队的主管们提出强烈建议:

项目经理和Scrum Master需要观察团队的精神和身体健康程度。要维持可持续的速度,主管必须要能感受到团队的状态。把上句话再读一遍,再问问你自己:做项目经理时,如果发现团队不健康,就让他们减少工作时间,上次这么做是什么时候?

在您的团队中,“可持续的速度”意味着什么?您是如何确保可以维持下去的?

查看英文原文:InfoQ: Sustainable Pace – What’s it mean and how to achieve it?

译者 郑柯 曾任职《程序员》杂志副主编,《项目管理修炼之道》译者。

This entry was posted in Agile, Best Practices. Bookmark the permalink.

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s