一个输入框你要做一周？

另外，当有了前端和后端的分别之后，协议/契约就会变成另一个障碍 — 如何保证协议双方对契约的消费的同步。比如，当前端发现需要展现一个额外字段在界面上，而发现后端并没有提供的时候；或者后端将日期存成了更加方便存储的long，而前端消费时发现没有timezone信息等等。

有了前后端双方的交互之后，校验规则同样需要在后端的模型对象和持久化层中都有所体现。

一种做法是前后端使用同构的架构（JavaScript全栈），这样有一部分代码可以在全后端复用（我们在上一个项目就中采用了React+AWS Lambda+Node.js的模式，整体体验还算不错）。

如果是异构架构，则需要将类似的代码用不同的语言写两遍，而且另外一个潜在的问题是：如何使得两者保持同步？

当然，我相信在工程上，这些问题最终都可以被解决，但是每个问题及其解决方案都不是免费的。即使团队中的开发有足够的经验和快速的学习能力，很多问题依然是无法预见的，而你永远无法解决一个你不知道的问题。

6. 异常情况

大部分情况下，人们倾向于从正常流程去考虑工作量。

而事实上在开发过程中，所谓的“正常流程”才是不正常的。现实世界中有太多的不确定的因素可以让我们的应用崩溃或者停止工作——网络请求超时，地址服务器宕机，后端版本升级，浏览器的不兼容，操作系统的不兼容，不同的硬件环境，特定的浏览器版本（我最近工作的项目上，由于客户使用的kerberos鉴权机制导致只有Firefox的特定版本才可以正常访问应用）等等。

与之对应的正常流程反而如同在走钢丝。

既然异常无可避免，我们需要为其设计很精巧的保护机制，一方面需要让系统可以在错误中恢复（不至于白屏，或者禁用所有功能），另一方面还需要展示以及记录可靠且准确的信息以供修复（日志，前端的Modal，截图等等）。

7. 用户体验

功能之外，还有很多其他因素需要考虑。比如可用性（Accessibility）以及易用性（包括页面上字词的选择和用户体验），以及兼容性的考虑。一些常见的会影响开发工作量的因素包括：

• 跨浏览器支持
• 老旧的浏览器兼容
• 多设备支持

如果涉及响应式设计，则需要和UX进一步合作来确定实际方案。很多时候，多个设备上的交互模式都不尽相同，比如iPad上的hover效果，小尺寸屏幕上的字体等等。

03 技术之外的因素

除了技术上很难预见的延迟和障碍之外，实际项目中还有很多会消耗掉大量时间的事件，它们无处不在，细微而琐碎，但是累积起来产生的影响则相当可观。

1. 混乱才是常态

比如项目上有若干名同事：

const roster = [    '吴荣华',    '侯晓成',    '贾彦军',    '邱俊涛'    ]

从概率上来说，每个人都或多或少有些工作之外的事情要处理，比如偶尔休假，不太舒服在家休息，通勤路上堵车，或者在买咖啡排时迷路等等。

const excuses = [    '堵车了',    '迟到了',    '要接小孩',    '不舒服，请半天假',    '休假了'    ]

而生活就像是这样一行代码：

${_.shuffle(roster)[0]} ${_.shuffle(excuses)[0]}

所以，我们眼中的世界就是这个样子的：

当然这些异常不会每天都发生，但是如果项目足够长，这些事情则几乎必然会发生。随着人员的增加，参与方的增加，不确定性随之提高，不是一切都正常的概率则会变得非常大。毕竟，混乱才是这个世界的常态。

而这些混乱可以让我们之前的估算失效，耗时增长。而这些混乱在估算之初则很难被我们看到，从而导致估算往往偏小。

2. 一个小故事

在几年前的一个项目上，我估计理想情况下大概需要三天来实现一个对某个资源的RESTful API，客户的技术负责人当时就怒了，说他自己写半天就可以写完，不就几个CURD嘛。

我帮他略为列了一些子任务之后，他陷入了沉思：

• Database migration脚本
• 实体类
• 实体类之间的关联
• Service/Controller类
• 异常处理
• 单元测试
• 与下游系统的契约
• 集成测试

我印象中这个任务花费的时间应该是多于三天的，因为光找其他团队的接口人要契约就花了一天半。

04 应对策略

通过上述的例子，相信大家已经看出评估失误的一些原因了，而要应对这些错误，大的原则当然是反其道而行之。

在具体的实践上，除了经验之外，一个可行的应对策略是足够程度的细化。通过细化事实上可以在一定程度上降低不确定性，使得很多原先没有看清楚的点被重新发现。

比如输入框的各种状态，状态之间的迁移，每个不同状态所涉及的样式等，通过细化（比如通过可视化的方式画出状态机），则很多细节自然浮现。

更进一步，如果涉及到数据的获取，那么对应的加载中，加载失败，无数据等等状态又会进一步驱动出更多的细节，从而潜在的可以产生更加客观的评估。

实践中，通过有限状态机的方式来描述穷举一个组件（或者一组互相关联组件）的状态是一个比较有效的方式，它可以更好的揭示组件的各种变体的形态和所需逻辑。

（图片来自：http://dwz.date/gcS）

另一方面，在心理上需要充分认识到现实世界的复杂程度，特别是涉及组织，，相关方很多的时候，不确定性会非线性的增加，从而导致评估的失误。

这要求我们一方面要拥抱变化而不是对抗变化，另一方面驱使我们采用更简单的设计，更坚固的基础设施，质量更高的构建方法等等，从而更快速的响应变化。

05 小结

至此，相比你已经猜到，虽然开发在估算中以为自己已经留有足够buffer，事实上这个功能的实现必然超过一周。

在实际项目中，一方面由于知识壁垒和一些偏见，人们倾向于忽略必要的细节，从而造成对实际所需工作量错误的评估。

另一方面，由于我们所处于的现实世界是一个高度复杂，不确定性很高的环境，很多因素往往会互相叠加，互相影响，从而导致即使我们从比较客观的视角去评估，如果忽略了不确定性，同样可能低估实际所需的工作量。

我们可以通过足够细化的方式降低不确定性，从而提高估算的可靠性。

另一方面，还需要积极的拥抱混乱，通过更简单可靠的方式来构建软件，从而提高响应变化的能力。

P.S. 我本来计划着写这篇文章大概需要3天，结果画图就花了两个晚上。然后又去检查了之前的博客，确定相对于之前的类似观点有了一些提升，才开始写草稿（耗时两个晚上），然后又花了两个晚上来润色。

来源：https://mp.weixin.qq.com/s/cjONOqFZoVbmLSROWde7RQ

作者：邱俊涛；公众号： ThoughtWorks洞见

本文素材来自互联网

（编辑：厦门网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!