image
记得很早在哪里看过一篇英文文章，介绍敏捷方法的由来。因为2000年左右的经济危机影响深远，客户的IT投资骤减，处于交付中途的软件系统无法上线，只剩下成堆的文档，对于客户而言一无是处。软件厂商陷入深深自责（没钱赚才是真的）。行业被逼无奈，创造了敏捷方法应对再次可能的危机，显著的变化之一，就是以迭代增量的形式开发软件，推向极致就是频繁上线。这样就可以确保，某种危机即便在任何时刻再度造访，软件系统至少以某种比例的完整度在运转着。自此可以保护客户的投资，不会浪费掉一分钱。
这消息不论真假，但多少反映了某一方面的真实：敏捷带来的不止是新奇、改进、优雅（当然也有痛苦），即便容易被人忽视，但它现实利益的一面的确也是存在的——让客户觉得物有所值。这也是我们常常提及的价值交付。不是随便喊喊的口号。
价值交付，必然需要体现在具体的行动上。一如敏捷中各类实践作为整体的完整性，价值交付的思维也需要表现在软件构建的过程中。尽早上线，频繁上线，哪怕开始只是简陋的功能也直接交由用户使用，是最符合直觉的，因为和生产环境以及最终用户有关。而更多需要表现在日常那些细致入微的活动中。故事卡的Kickoff，开发过程中频繁的本地构建和环境部署，Desk Check，迭代Showcase和Sign off，都有尽早呈现的意味在里面游弋。它们只是各自有不同的粒度，以及需要区分的呈现对象。但无不是借助细致粒度的反馈，来弥合因为多人合作以及复杂环境所带来的需求与沟通的罅隙，以及不确定性。
在这些尽早呈现的过程中，检验需求的真实和市场的反馈是毋庸置疑的，团队还可以借此验证自己的技术和能力的组合。方向正确了，在此上迭代增量，每个人也会渐渐拥有坚定的信心。
这对那些莫须有的需求存有天然的抑制作用，费劲口舌去争辩需求的合理性，不如尽快交由市场和用户去判断。预防开发者的过度设计、自大以及添油加醋，也有顺理成章的疗效。
为了确保快速的呈现，交付上线，并应对必然而来的反馈和需求变化，代码要有可读性方便维护，测试覆盖率要高确保修改安全，不可选用复杂的架构设计，要足够轻量，微服务显然更有伸缩弹性，架构不具有演进性显然会积重难返。对有效反馈的渴求，刺激着团队需要饱含轻量、快速响应、随时优化调整，以及不多不少的思维，然后体现在所有的开发活动中。
想起那幅著名的价值交付的对比图。客户的需求是一辆四轮的豪车，而尽早呈现交付给他的是一个三轮脚踏车。看着不可思议，但如果客户的需求只是从一个地方到另一个地方，这是不是在当下就足够了呢？
网友评论