避免稳定sprint的12个实际步骤

BY ERIC ISOM 沈义 · 沈潇灵 译

这一切都与质量有关。只有在产品不符合你的质量要求时才需要稳定sprint。

这些是你可以作为项目经理或Scrum主管采取的实际步骤。 其不要求你启动公司范围内自上而下的计划。你可以一次按照这些步骤操作,并查看每个步骤的改进情况。然后其他人会看到你的结果,并问你是如何做到的。

辨认出问题

你创造的质量很差,不得不重做。这就像一个糟糕的制造过程。你构建了一些东西,检查,发现它不符合要求,并重新设计它以满足要求,或者抛弃它。你编写代码,发现它不稳定,现在你正在用稳定sprint重新编写代码。

我们多年前在制造业中吸取了这一教训。不幸的是,我们必须以艰难的方式学习它。戴明和其他质量领导者教授了这些原则。日本人听取了他们的意见,并将他们的制造业变成了世界上最好的。多年之后,我们其他人才会注意到并开始倾听。

现在它在软件开发中再次发生。我们认为稳定sprint(返工)是必要的。我们过分依赖测试(检查)。

我们说,软件是不同的,错误也是不可避免的。无论如何,技术债务都会增长。而且,可以预期稳定sprint。这就像美国的制造行业多年前的借口:缺陷,库存,延迟以及返工是无法避免的。

能不能听到20世纪制造行业的回音?

我们不会问自己我们在编写代码的方式上需要改变什么。很难想象以任何其他方法。

当有人出现并开始向我们展示道路时,我们就会忽视他们。他们提出的建议太具有破坏性,成本太高,只是行不通。我们公司/行业不同。似曾相识。几十年来,人们同样忽略了戴明。 

时间已经到了将我们在其他行业中学到的关于质量的艰苦教训应用到优质软件的开发中。

不要让系统不稳定

首先,即使是持怀疑态度的人也不得不承认你不必让生产系统变得不稳定。你有一个选择。

即使你的测试(检查)在发布之前没有发现稳定性问题,你应该在发现稳定性问题时立即回滚。

这个简单的建议引发了一场经典的辩论。

一方面,不成熟的组织认为修复损坏的系统是可行的(有时甚至是不可避免的)。它们允许生产系统在他们争抢和修补时被打破。 他们匆忙并认为最好尽可能快地修复它,而不是花时间回滚。他们觉得承认必须回滚太尴尬了。

另一方面,成熟的组织优先考虑客户服务和系统的稳定性。他们知道,即使需要等待更长时间才能获得这些新功能,客户也可以通过系统运行得到更好的服务。这是事件管理,你的首要任务是尽快让系统再次运行。

如果你的版本破坏了系统,最好要回滚到之前的版本。不要试图将其在现状中固定。并且不要只是忍受它直到下一个版本。你需要训练自己不要容忍不稳定系统的发布。

在接下来的步骤中,你将需要这个规则,使你达到一定的质量水平,以避免稳定sprint。

找到根本原因

回滚后,你自然会专注于查找和修复即时问题,以便可以重新发布。是的,这是返工。 但我们一步一步迈出这一步。如果你遇到稳定性问题,你必须首先扑灭火灾。

找到并解决问题,然后重新发布系统。

现在是重要的部分。从长远来看,要想拥有一个更稳定的系统,并在将来避免这些问题,你就不能止步于此。如果你这样做,他们会堆积起来直到你确实需要稳定sprint。

现在,你必须找到并解决问题的根本原因。允许编写,测试和发布此不稳定代码而没发现潜在问题的来源是什么呢?

要注意,我不建议你在将来添加更多检查和更多测试以捕获此类问题。你可能需要多一些,但你也不要添加太多的检查和测试。

这就是制造业中发生的事情。如果在客户发现缺陷之前未发现缺陷,我们会增加质量检查的深度和广度。更多测试,更多检查,更多清单上的项目。这是一种下意识的反应,会造成太多的检查,并使质量控制成为一个坏名声。

“检查不会提高质量,也不能保证质量。 检查为时已晚。 质量,好的或坏的,已经在产品中。 正如Harold F. Dodge所说,“检查产品无法产生质量。”

“Inspection does not improve the quality, nor guarantee quality. Inspection is too late. The quality, good or bad, is already in the product. As Harold F. Dodge said, “You can not inspect quality into a product.”

W. Edwards Deming, Out of the Crisis, p. 29

不是添加更多测试和检查,反而要进一步向价值链上方找到问题的根本原因。

小心不要关注导致问题的是谁。相反,要关注是导致的什么。你能如何改变环境和过程以提高质量并避免将来出现此类问题?

不要打扰开发人员

如果你是一名软件开发人员,那么你就知道进入与保持最佳状态的重要性。编写好的代码需要大量的注意力。需要考虑很多变量与连锁反应。需要几分钟才能进入这种集中状态。

打破这种专心状态,你会大大增加错误的机会。 假如每隔15分钟中断软件开发人员,他们几乎什么都不会完成,而且你最终会遇到很多错误,糟糕的设计决策,技术债务等等。

尽你所能鼓励和保护他们的能力在该“最佳状态”中工作。你需要尽量减少分心的机会。比方说,要尽量避免他们在眼角里看到有人走过他们的隔间。这是一种分心。 他们听到大厅里的谈话。 另一中分心。

你有没有想过为什么软件开发人员更喜欢在没有窗户且远离人的黑暗房间里工作?并不是说他们是反社会的。(好吧,也许他们是反社会的,但这是另一个话题。)他们本能地被吸引到最小化干扰的环境。

如果你将它们放在隔间或开放空间,他们会戴上耳机来阻挡噪音。如果我戴上音乐,它有助于淹没噪音,但我听不到音乐。几分钟后,我就会进入那个“最佳状态”。连几小时可以过去,我也不记得听了什么音乐。

这就像习惯回家的路一样,回家以后却不记得途中的任何东西了。你有了什么想法就开着自动驾驶回家。

但对别人来说,音乐也可能会分散他们的注意力。比如,当一首新歌开始放也许会打断你的思路,并打破“最佳状态”的力量。

耳机只是为了弥补不好环境的缺乏。 如果你能够搬到一个更好的环境就会是最好的方式。

开发者真的需要自己的办公室,没办法这样的话,隔间的墙要够高以便减少分心。如果可以的话,也可以让开发者戴着耳机或做所需要的来专心。

还有,竭尽不要打扰他们。

你可以把上午的时间当作召开会议的时段而把下午作为特别专心的时段。这样你就会在上午的时候协调,而让下午从不间断。你也可以把上午下午的会议与专心的时间反过来执行。

执行代码审查

当一个开发人员向另一开发人员解释其代码时,意见神奇的事情经常将发生。在描述时,他们经常会突然意识到一些事情。你可以在他们的脸上看到“诶!对啦”的那种表情。也许他们会发现一个更好的方法,或许,他们没有考虑的连锁反应。此外,他们也许会发现其中犯的一个错误(可能是他们被打断时而犯的)。

这比其他开发人员发现可以改进的情况更为普遍。向其他人解释的简单行为经常会帮你你看到以前从未见过的东西。

而且,你还会从其他开发人员那里获得大量好的建议。 他们将以不同的方式看待事物,并帮助你发现缺陷和技术债务。

代码审查将帮助你避免引起稳定冲刺的问题。

执行设计审查

为什么不进行设计审查和代码审查? 当两到三个开发人员审查提议的设计,探索选择并集思广益时,同样的魔术也会发生。

更好的设计减少了技术负担,更加灵活和稳定。

开发自动回归测试

这里不要太过分。关键是确定通过系统的最关键的路径。对于电子商务网站,其中包括:

  • 浏览产品
  • 将项目添加到购物车
  • 进行购买
  • 注册

为这些路径都要创建回归测试。在发布之前,要确保你的系统通过了这些测试。更重要的是,在每个代码签入时都运行这些测试。

当更改的细节仍在开发人员的脑海中时,最好立即抓住一条打破关键道路的方法。 而且,您不会浪费时间搜索冲刺的大量更改,以找出是哪个冲破了。

不用担心其他途径。回归测试需要快速进行(例如5分钟),这样你就不会在每次代码检入时都运行回归测试。

如果需要,你可以进行更多的回归测试,也可以在晚上运行它们。运行一个小时都没关系。早晨,如果测试发现问题,则只有1天的登机手续才能找到问题的根源。 这比等到冲刺结束要好得多。 或更糟糕的是,直到它部署并崩溃。

考虑成对编程

这可能听起来很极端,但是在某些情况下,这是值得的。 几年前,我和一个朋友为IBM的教育软件设计并构建了一个动画图形库。 我们花了6周的时间详细设计,编码,测试,在1天的测试中发现并修复2个错字并进行部署。

10年后,它仍在使用。 在所有这些时间里,他们从未发现一个错误。 一个错误都没有。一个也没有!

而且他们从未向其中添加任何代码。 它完美地完成了原本应做的一切。

创建试运行的环境

在类似于生产的环境中承受负载之前,某些问题不会出现。 不要等待这些出生产环境中出现,而要主动创建一个与你的生产环境具有相同设置的暂存环境。

将候选发布版本部署到暂存环境,并使用一些测试工具来模拟繁重的生产负载。比如说,很多用户一次登录,或者正在进行大量交易。确保这些将模拟你最繁忙的交通高峰。

然后,将其推动直到破裂, 要知道它的弱点到底在哪。接着要研究你认为可能会成为问题的任何限制。发现了之后,要在它们成为问题并需要稳定冲刺之前将其修复。

监督产生

你需要先发现并解决生产问题。监视响应时间,内存使用率,CPU使用率,带宽使用率,磁盘使用率,磁盘故障,每秒/分钟/小时的事务处理,流量等。

发生故障之前,要提前更换硬件。在耗尽内存和带宽之前先增加,等等。

调查反应时间较差的事件,然后再传播。

在问题仍然很小的情况下提前发现 – 也就是在需要整个稳定冲刺来处理它们之前。

要选择最适合团队的人

如果你团队里的人不具备执行所有这些操作的技能,则将其他人加入团队。或培训你正在拥有的人。

如果他们不愿意被培训,那么你需要说服他们或找新的人。这样说可能听起来很刺耳,但是如果你的团队不愿意学会新的工作方法,那么你就永远不会获得不同的结果。

但是,请记住,其中许多概念最初都是违反直觉的。毕竟,美国制造业数十年来一直抵制这些质量观念。即使那样,他们也只是在竞争迫使他们开始采用现代质量实践。我们需要给人们一些时间来习惯新的工作方式。

有些人永远不会放弃他们需要稳定冲刺的想法。其他人会马上学会新方式了。大多数人都需要你的指导。

了解有关精益制造,丰田方法和持续交付的更多信息。向你的团队介绍你学到的知识。

不断更新、(打磨锯子)

永远不要停止学习和改进。要把持续改进作为个人习惯。帮助你的团队和组织采用质量文化。接下来的好处将不仅仅在于避免稳定冲刺。

要了解如何实施你所学会的知识。成功却是最好的广告方式。你的成功就会让别人想知道你是怎么做到的。

有关如何在Scrum项目中取得更大成功的更多想法,请查看永远不要停止学习和改进。 将持续改进作为个人习惯。 帮助您的团队和组织采用质量文化。 好处将不仅仅在于避免稳定冲刺。

了解更多有关并实施所学知识的信息。 没有什么能比证明的结果卖得更好。 运用音质原则获得的成功越多,就会有更多的人想要知道您是如何做到的。

有关如何在Scrum项目中取得更大成功的更多想法,请查看永远不要停止学习和改进。 将持续改进作为个人习惯。 帮助您的团队和组织采用质量文化。 好处将不仅仅在于避免稳定冲刺。

了解更多有关并实施所学知识的信息。 没有什么能比证明的结果卖得更好。 运用音质原则获得的成功越多,就会有更多的人想要知道您是如何做到的。

有关如何在Scrum项目中取得更大成功的更多想法,请查看Scrum失败的两个主要原因