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

“以可持续的速度工作”,这是《敏捷宣言》的原则之一,也常常是难以实现的一条。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?

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

Advertisements
此条目发表在Agile, Best Practices分类目录。将固定链接加入收藏夹。

发表评论

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