在日常工作中估算工作量的时候，多少会遇到不熟悉的技术，导致无法估算出工作量。这种问题遇到的相对频繁，所以今天的极限拷问是：
① 项目中涉及不熟悉的技术时，应该如何应对？
② 技术研究应该怎么做？做到什么程度？产出什么交付物？
在面对不熟悉的技术时，可以考虑制作一个简单的 demo，研究该技术对于当前需求的满足程度，这个时间不宜过长，而且 demo 也只需要简单验证是否能满足需求即可。
对于项目中不确定的技术，时间允许的话最好是空出时间做Spike，以消除技术风险。
可参考以下三点方向解决：
1、弄清楚是什么，为什么，确定产出物
估算是首先应该保证的就是自己理解了需求，弄清楚是什么，为什么，并当场确认做到什么程度，能够得到帮助的线索，并做好Task拆分。
2、 寻找他人帮助
遇到自己不熟悉的技术时，可以先准备一些问题，然后寻找有相关经验的人，讲清楚上下文以及问题，通过他人获取到经验。
3. 准备搜索的关键字
如果一之间找不到有经验的人，也可以通过提前准备好一些搜索词，内部和外部来通过网络获取资料。
当遇到技术问题，我们需要让团队知道这是一个风险点，评估的不准确。执行过程中，不是按照天来进行信息同步，当有思路时，即可沟通下，思路一致后再继续解决问题。通过频繁的沟通，团队中的人员会大致知道当前的进展。
其实，我们在处理这种 “ 探索类故事 “，首先要求开始开发之前提前一个迭代探索，但是发现大家探索估点都比较大，于是我们要求按点数提交成果，每天探索还有每天产出，即便复制粘贴也好，但是提交了要能实用，探索最后应该有demo支撑，或者下个迭代开发的时候自己加班填坑。
对于其他企业，我的建议是：探索类项目必须预设目标，并且给出路线图和至少双周计划，保证处理好 “故事” 。
那你觉得作为技术研究应该怎么做，给出什么交付物合适？
技术研究仅需要探索相关技术点，产出物是一个可被抛弃的demo，通常在2到5天内完成。
我认为技术研究还是要根据应用场景限定时间内适度进行，明确现阶段目标，比如是满足怎样的需求，或把完成某个需求的效率提高到某个具体程度。
首先要清晰的知道自己要去解决什么问题，才需要研究某一项的技术，包括上文提到的：列好Task，将问题简单化；寻找周围人的帮助或者通过资料获取；小步信息同步。
至于做到什么程度，我觉得要制作一个简单的 demo，它能明确能满足和不能满足的需求是哪些，做出完整的成品大概需要多少人力和时间，当然做到什么程度，由需求决定。
有的收到信息解决就发现这项技术无法解决问题，或者过于技术过于复杂了，那么得到这些信息同步时就可以决定时继续还是停止，换用其他思路或者技术选择。
有的需要出现一个简单的demo，并识别出搭建demo的技术有哪些优势和局限性，最终决定是否使用。
准备工作都做好之后，需要给出产出物。它可以简单演示的 demo，如果有不满足的需求，最好有不满足需求的清单，同时说明哪些可以通过改造达到，哪些是通过改造无法满足的。
不同的场景对应不同的产出物，可以是一次沟通，一个task列表，一个demo。哪种对我们实际帮助越大，就选择哪个。
总的来说，我们认为估算是为了辅助决策，项目中遇到不熟悉的技术问题是，此时的估算风险比较大，重点不是当时说出那项工作要多久，而是如何将清晰并解决，清晰之后进行估算，TL在过程中也会有一些预判。结果过程就是将复杂或者繁杂的问题变小，小步确认，最终解决。
以上内容整合自【极限编程中国 | 实践者】 微信群26日讨论，内容贡献者： 
若有收获，就点个赞吧
0 人点赞
