一个输入框你要做一周？
|
我帮他略为列了一些子任务之后，他陷入了沉思：
我印象中这个任务花费的时间应该是多于三天的，因为光找其他团队的接口人要契约就花了一天半。 04 应对策略通过上述的例子，相信大家已经看出评估失误的一些原因了，而要应对这些错误，大的原则当然是反其道而行之。 在具体的实践上，除了经验之外，一个可行的应对策略是足够程度的细化。通过细化事实上可以在一定程度上降低不确定性，使得很多原先没有看清楚的点被重新发现。 比如输入框的各种状态，状态之间的迁移，每个不同状态所涉及的样式等，通过细化（比如通过可视化的方式画出状态机），则很多细节自然浮现。 更进一步，如果涉及到数据的获取，那么对应的加载中，加载失败，无数据等等状态又会进一步驱动出更多的细节，从而潜在的可以产生更加客观的评估。 实践中，通过有限状态机的方式来描述穷举一个组件（或者一组互相关联组件）的状态是一个比较有效的方式，它可以更好的揭示组件的各种变体的形态和所需逻辑。
（图片来自：http://dwz.date/gcS） 另一方面，在心理上需要充分认识到现实世界的复杂程度，特别是涉及组织，，相关方很多的时候，不确定性会非线性的增加，从而导致评估的失误。 这要求我们一方面要拥抱变化而不是对抗变化，另一方面驱使我们采用更简单的设计，更坚固的基础设施，质量更高的构建方法等等，从而更快速的响应变化。 05 小结至此，相比你已经猜到，虽然开发在估算中以为自己已经留有足够buffer，事实上这个功能的实现必然超过一周。 在实际项目中，一方面由于知识壁垒和一些偏见，人们倾向于忽略必要的细节，从而造成对实际所需工作量错误的评估。 另一方面，由于我们所处于的现实世界是一个高度复杂，不确定性很高的环境，很多因素往往会互相叠加，互相影响，从而导致即使我们从比较客观的视角去评估，如果忽略了不确定性，同样可能低估实际所需的工作量。 我们可以通过足够细化的方式降低不确定性，从而提高估算的可靠性。 另一方面，还需要积极的拥抱混乱，通过更简单可靠的方式来构建软件，从而提高响应变化的能力。 P.S. 我本来计划着写这篇文章大概需要3天，结果画图就花了两个晚上。然后又去检查了之前的博客，确定相对于之前的类似观点有了一些提升，才开始写草稿（耗时两个晚上），然后又花了两个晚上来润色。
来源：https://mp.weixin.qq.com/s/cjONOqFZoVbmLSROWde7RQ 作者：邱俊涛；公众号： ThoughtWorks洞见 本文素材来自互联网 （编辑：西安站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
