变化才是常态

一路敏捷至此的各位，应该对於敏捷强调的「面对变化」已有所体悟。

有个缩写词汇 VUCA 表达了现况，维基百科的条目是这麽说明的：

vuca 是 volatility（易变性）、uncertainty（不确定性）、complexity（复杂性）、ambiguity（模糊性）的缩写。VUCA这个术语源於军事用语并在20世纪90年代开始被普遍使用。随後被用於从盈利性公司到教育事业的各种组织的战略这种新兴思想中去。

我们可以知道 VUCA 源於军事，在战场上的变化可想而之，而商场如战场… 不用了，不需要再对比与延伸了，我们直接看看周遭、看看手机、看看最近装了哪些 Apps 又移除了哪些、最近又有什麽新产品发表了、市场上又冒出哪一只独角兽了。

或是，又有什麽陨石掉下来了？

(注：这边的陨石概念来自红极一时的「メテオフォール型开発」。好啦，现在也很红)

面对变化的心态

在对团队内训时，我强调这种变动与不确定性，是充斥在整个大环境中，希望一个需求不发生变动，或一个需求不会衍生其他需求，都是不太理智的。这就像是一个理想的冲刺，从 PBI 定义、拆解、实作，整个过程如果 Product Owner 与 Scrum Master 努力的维系世界和平，那麽团队应该可以专注完成，但这也不保证在 Review 时我们会得到一致的认同，也许客户看到一个动起来的东西就会产生各种新想法，这几乎是肯定的。

客户或市场的改变，纵使 Product Owner 进行协调，仍然有推翻前局的可能性。当我们站在敏捷的角度来看，这其实是幸运的，我们在整个期程还没走完就得到了回馈，有了应对的机会。不过推翻之前做的东西，在重视效率与自我实现的团队当中可能心生不满，必竟这些都是心血，也是众人智慧的产物，但是要记得，正在交付的是客户(或市场)想要的价值，不是交付自己的理想，当然我们期待这两者的重叠。

那麽，不断被拿来揶揄需求变动的「陨石开发法」，我们用什麽心态来面对它？

这得看这颗陨石是何许人也了，如果它大到一个程度，连 Product Owner 与 Scrum Master 都无法化解，在 Scrum 当中最惨烈的情况是，PO 有权停止当下的冲刺，这是考量到市场 (或客户) 发生剧烈变化的时候，团队很可能失去继续发展手边工作的理由，理智的切断冲刺也是个合理考量。

面对变化的应对

那麽，团队呢？看起来深受陨石所害一群人，可以做点什麽？

这就得发挥工程人员最擅长的部分了，设计具有弹性的架构，使它具备可抽换与可扩充的能力，句话可以解读得很广大，感觉要用上各种精妙的设计模式。能适时引入模式是值得赞许的，但还有一些更简单的方案，可以减缓变动带来的痛苦，例如：可以抽换的设定档机制、DRY 与 SOLID 原则的实践、共用的 CSS 定义等，有不少工程人员容易掌握的技术可以减少变动带来的影响，我们要在开发的时候，意识到可能会发生变动，并思考「如果要未来要改变，我现在应该要…？」。

如果有人说「但这边就是当初觉得不会改，所以没预留弹性啊！」，这样就认了吧，这种事总不会一直发生的，假若一直发生，除了客户可能有独特的喜好之外，或许我们自己的经验资料库也需要更新一下。

与期害怕或抱怨变化的发生，不如先准备好迎接变化，不是吗？