精益软件开发中的改善

作者 Geoffrey Wiseman 译者 Jason Lai 发布于 2007年7月26日

领域

过程 & 实践,

语言 & 开发

主题

工件和工具 ,

持续改进 ,

工具 ,

精益 ,

回顾 ,

敏捷 ,

变更 ,

Kaizen

分享到

改善（Kaizen）是精益（Lean）方法使用的消除浪费，并且在定期甚至每天改进结果的主要方法。Alan在leanagilescrum邮件列表中抛出这样一个问题：

在精益/敏捷软件开发之中，是否存在一些已知技术，用于辅助改善的活动呢？

Martin给出了如下建议：

软件改善对于我来说，不仅仅是寻找浪费，而是寻找能让你持续不断地改善工作的方式。

我是个来自第一线的开发人员，因此我非常关注代码质量。如果你有一个未经测试或者无法测试的一塌糊涂的遗留代码库，那么你通过重构可测试性和设计模式所能带来的改善，要衡量起来是颇为容易的。我觉得，你可以把这看成消除人们抓耳挠腮问“这应该是做些什么的呀？”的时间。

我希望从经过测试的类数量和代码覆盖百分比（尽管这本身就需要慎重考虑）这样的角度看待问题。

我坚持认为，如果你没有高质量的代码，你就只能随着其它的改善方法走到这么远了。

最后，Phillip在回复中，详细地评论了在改善之前、之后和之中要遵循的步骤，他总结陈词到：

上面描述的过程应当在一周内完成。改善的精髓在于识别浪费，并且通过过程改进来消除这些浪费，引入实际参与工作的人快速完成上述工作，实现变更，并支持和监督变更，然后再次完完整整地重新开始。

在一篇相关的博客文章中，Bruno Câmara分析了Scrum和改善之间的交集。他主张说，增量式改进一般在Sprint回顾中完成，而对数据的收集和分析是每天通过Burndown Chart和项目Backlog来完成的。他又稍微扩展了问题领域，建议敏捷过程通过减少过多文档的方式避免浪费，并希望小型的自我管理能力出众的敏捷团队应当将决策权限交给开发人员，这也和改善的初衷是一致的。

如果您希望了解更多关于精益、改善、回顾和持续改善，请访问以上InfoQ站内链接。

查看英文原文：Kaizen in Lean Software Development