“以可持续的速度工作”,这是《敏捷宣言》的原则之一,也常常是难以实现的一条。 Agile Leader 新闻组最近开始讨论可持续速度的相关话题。
什么才是真正“可持续的速度”,如何始终如一地达成可持续的速度,这是讨论围之展开的两个中心。
Bob Sarni 引用敏捷原则,开启了这次讨论:“敏捷过程提倡可持续的开发。出资方、开发人员和用户应该能够保持恒久稳定的进展速度。”
他进一步说明:
在我与众多组织和团队的工作经验中,可持续的速度看来是这些团队和组织共同面临的问题。要维持可持续的速度,需要很多因素——产品的路线图和承诺、愿景、速度 / 流 / 节奏、工作与生活的平衡、可见性、企业文化、个人问题、信任、多任务,等等。 团队层面要做到可持续的速度难度更高,因为团队中每个人都有自己的可持续速度,并且影响团队的整体速度。
Manoj Vadakkan 认为:无法以可持续速度工作,其问题在于,组织在实施敏捷实践时,没有深入理解背后的价值观和原则。
我看到的实施 Scrum 主要的问题在于:它被当做迭代过程实施,没有以原则和价值观做基础。不知道大家是否同意:可持续速度的问题,是我们的流程没有以速度为基础造成的诸多问题之一。 我担心的是:总体来说,关于这一点我们强调的还不够——不以敏捷的价值观和原则为基础,这个(Scrum)不会有成效。
其他人也同意:如果不以敏捷价值观为起点,敏捷和 Scrum 的转换将不可持续,团队和个人会面临精疲力竭的风险。 Scott Duncan 讲述了自己与大型组织工作的经验:
- 就我所知,他们现在希望人们可以“持续”的,称为“职业周”,比如 50 个小时,或是每天多加班 2 个小时,而且不会有加班费或任何补偿。
- 基于小时数的估算方法,假定人们每周高效工作至少 40 个小时(即使期望人们每周只工作 40 个小时),每个特性和需求都会以小时数估算,然后团队中的人员数目乘以 40,再乘以按周计算的开发时间段,再把得到的结果用需求和特性的小时数填满,这样团队和项目所有的小时数就被充满了。
- 相信真正的职业人士会“一切可能把工作完成”,因此并不真正关心可持续的理念。
- 着手工作时,假定所有的时间都已经被占用,因此任何没有事先规划的事件(比如变更、设计“发现”等)都会假定使用加班来吸收掉。
Manoj Vadakkan 引用了自己在 Scrum 联盟网站上的一篇文章,他在其中的总结是:
当然,客户不关心你的雇员是否每天长时间工作,可你是否跟他们讨论过产出代码的质量?试着告诉他们不利一面,他们也许会开始关心。长期看来,客户如果想在下个版本中改变代码,他们才是付账的人。你是否认为可持续速度值得拥有?也许我们应该跟客户商量商量。也许他们会同意质量很重要,也许不然。有一点可以确定:我们不能替他们拿主意。
Karen Greaves 基于自己的经验,提供了具体建议:
我现在在自己组织内的工作方式是: 1. 断开工作小时数和工作效率或是交付价值之间的联系。作为管理人员,永远不要度量工作小时数。也就是说,不要用工时表,不要有固定的工作小时数,甚至不要暗示员工“必须”每天工作 8 小时。更应该做的,是设定人们应该交付的成果的期望值。
2. 把关注点放在完成工作上,而不是保持忙碌。如果你今天工作不在状态,不如回家。如果你今天小宇宙爆发,而且工作不断取得进展,那就继续下去。引用一下 Kent Beck 那句话:“如果你不想工作,那么你在办公室里度过的每一个小时,都等于是加班。”
3. 永远不要让人们周末加班。
4. 提供一个有吸引力的目标,这可以激励人们达成它,而不是编造一个无法实现的截止日期。
5. 不要把工作安排得太紧。留出人们估计无法如常工作的时间。我们有特快专递日、实验室日,还有正常的周五学习时间。目前来看,这些做法在我的团队内效果还不错,虽然业务人员很难接受,但是我对它们的坚持还是有所收获。当我一年多前接受我现在的工作时,团队会定期在周末和深夜加班。去年,我们可以做到在每个发布日期当天的下午 6 点之前发布版本,而且从未在周末加过班。质量改进了,大家的工作满意度提升了,人员流失率也降低了。工作效率虽然有所波动,但与其直接相关的,是版本发布的目标和规划。
在 Agile Leader 讨论组外,还有一些人就可持续速度的话题发表了自己的看法。
Bob Hartman(“ Agilebob ”)有一篇文章《刚接触敏捷吗?从以可持续的速度工作开始吧》。他在其中指出,如果无法做到以可持续的速度工作会有什么后果:
- 缺陷会增加。疲劳的团队会产生更多缺陷。
- 工作产出会降低。疲劳的团队在更多时间内完成的工作更少!
- 士气会大幅降低。这会导致雇员们在项目的最低潮期时离职。
- 互相责备的游戏会更普遍。(你之前没说 X,所以不是我们的错;我当时就说了来着;当时没那么做;当时就那么做了……)
- 团队开始抛弃优秀实践,转而选择“看起来”更快的时间。抱歉,比起只是写代码,然后抛给墙那边的 QA 去测试来说,测试驱动开发(TDD)确实更快!
他为敏捷团队的主管们提出强烈建议:
项目经理和 Scrum Master 需要观察团队的精神和身体健康程度。要维持可持续的速度,主管必须要能感受到团队的状态。把上句话再读一遍,再问问你自己:做项目经理时,如果发现团队不健康,就让他们减少工作时间,上次这么做是什么时候?
在您的团队中,“可持续的速度”意味着什么?您是如何确保可以维持下去的?
查看英文原文: InfoQ: Sustainable Pace – What’s it mean and how to achieve it?
评论