在团队进行开发时，经常有工作被打断的时刻，小A和小B此时正处于这一节点——小A原本正在开开心心的写自己的代码，小B突然说：“我需要你修改后的接口，麻烦你赶快给我，不然我的工作都阻塞了”，此时的小A发现自己陷入了两难的境地。
提交代码？手上的工作还没完成，现在系统是不可用状态
让小B等着？小B又很着急的样子。
那么今日极限拷问来了：
1、请问小A应该怎么办？
2、有哪些实践可以帮助他们更好地应对此类情况？
当与同事的工作内容有依赖关系时，即不想耽误同事的进程，又无法提交自己手中未完成的代码，小A应该怎么办？
首先可以考虑一下小B手中的工作与自己手中的工作，哪一项优先级更高，如果小A手头工作优先级更高，那么应该和小B说明情况，过一会儿再给；
反之若小B的优先级更高，那么小A可以先将自己的工作 git stash，然后和小B定义新接口行为和返回，接着双方按照定义好的“协议”实现。
“协议”可以用文档、简单小黑板板书并拍照来实现，小A可先模拟出返回，保证B能正常使用，而不需要等自己真正实现接口，确保小B的工作在新接口没有完成的情况下继续进行。
在小B推进工作时，小A可以将小B提出的新接口实现，等到所有接口文档都给到小B后，小A便可以 git stash pop 继续原来的工作。
那么哪些实践可以帮助他们更好的应对类似情况呢？
首先，SM要总结为什么发生这样的事情，是当时设计的遗漏，还是沟通上出现了问题，在第二天早会或者交付周期 review 的时候提一下这个事情，大家协定好按照流程执行。虽然敏捷推荐动态的响应变化，但是一定程度上遵守流程持续地推动项目才应该是主线。
然后在日后的团队协作中最好做到：
- 建立各种分支管理模型，stash 后切出功能分支调试新接口，完成后合并，或者未完成切回原来功能分支继续原功能开发。保证工作状态切换不会带来额外的时间花销。如果接口开发周期长，需要频繁合并主干分支到功能分支，以避免不必要的冲突（此处假设两个功能在一个 project 中）
- 测试驱动开发， A，B分别对自己的功能按照定义的协议写测试用例，通过测试后再运行，从而避免联调花费的额外时间。
- 持续交付， 此模型建立在新接口需要较大工作量的基础上，即双方有阶段性成果的时候，频繁部署，频繁跑测试CI/CD, 而不是累计起来最后测试。
总而言之，手头工作及时交付，不要让它躺在自己的代码分支，成为库存造成浪费。
在此时，又凸显出一个十分有讨论性的问题：那就是究竟要不要将时间作为工作量的衡量标准呢？
Q&A:将时间作为进度的把控点可行吗？
然而，无论在工作中每个人是否尽全力，估算时间都不能解决或是回答“规定时间内任务完不成”这个问题。因为每个人的速度都不一样，而且所有计划都无法避免没有临时的事，造成时间很难被估计。正确的做法是估算点数，速度是事实。
那么如何估算点数呢？
在这里先要明确的是，点数是一个相对量，可以理解为在团队内部建立一个大家都理解并且认同的基准参照系，基于全员达成一致理解的基础上对工作量进行预期。
在进行故事点估算时，大部分团队会使用某个预先定义的、不包含所有可能情况的数值范围来进行，如2次幂的序列，或斐波那契额数列来进行这种估算。
以斐波那契额数列为例：把任意一张故事卡摆出来，比它点数大的放左边，比它点数小的放右边，一样大的并列排放，所有故事卡依次放好后，从右到左的顺序是1、2、3、5、8…，此时，将大于8的拿回去重新拆分，再次按照上面的规则排序，这样就完成了点数估算。
其实，估算点数可以提高效率，就像测试可以提高质量一样，在进行工作量预估时，不要将时间与其搅在一起。
以上内容整合自【极限编程中国 | 实践者】微信群12月3日讨论，内容贡献者：
若有收获，就点个赞吧
0 人点赞
