对我而言,这就是关键:除非我们能够尽可能快的得到反馈,从而得以判断相关性并识别因果,否则谈什么实践持续改进、学习如何让团队和个人变得更好、获取能让我们的产品服务更加成功的能力等等基本上都是虚幻的。
事实上,从概念到反馈的短周期的好处是如此之大,以至于应当成为我们的商业模型的最重要的标准之一。如果你在决定是把自己的产品做成一个用户安装包还是在线软件服务时,这种考虑会把你推向后者(这是我的经验之谈)。如果你在开发的系统涉及到硬件,尽可能快的做出技术原型并且将硬件和软件模块化,这样你就可以快速、独立地更新它们了。三维打印技术很有可能在这个领域产生巨大的影响,因为它使软件开发实践在硬件系统的演化中的应用成为可能。如果你想要有一个足够短的反馈周期,或多或少都需要有一个跨职能团队。
软件方法学——甚至是“招一帮牛人让他们自我管理”的方法——都会失灵,因为它们常常导致了货物崇拜(cargo-cult,比喻那些形式主义、机械模仿、只知其然不知其所以然的行为)的行为:我们有站立会议,有排好优先级的backlog,天啊,我们甚至还在进行持续集成。为什么我们做出的东西仍然很差并且延期了呢?因为你忘记了最重要的事情:建立一个尽可能快速的学习和适应的组织。
虽然如Laurent Bossavit所说(私下交流),“一个开发者具备的技能,部分包括他/她所知道的方法及他/她偏好一种语言甚于其它语言的原因”。
我并非建议放弃在软件开发中开展实验来确定什么行什么不行,以及这些结论成立的上下文。恰恰相反,我说的是我们做得还远远不够。