Almost all absurdity of conduct arises from the imitation of those whom we cannot resemble.
(Samuel Johnson)几乎所有荒谬的行为均源自于模仿那些我们不可能准确模仿的人。–塞缪尔 · 约翰逊
背景：
- 小A 正在开开心心的写自己的代码，小B 突然说：我需要你修改后的新接口，麻烦你赶快给我，不然我工作都要阻塞了。
- 小A 发现自己陷入了两难境地。提交代码？手上的功能还没有完成，现在系统是不可用状态。让小B 等着？小B 又很着急的样子。
问题一、请问小 A 应该怎么办？
- 采用分支开发，主线发布，降低交付的批量大小
- 可以给予契约开发，Mock 接口
- 两个人先讨论一下，是否有改的必要，确定优先级，需求讨论，确定纪律
- 首先 git stash， 之后解决小B 问题，再之后 git stash pop
问题二、有哪些实践可以帮助他们更好应对类似情况？
- 采用 GItflow 的开发流程
- 测试驱动，避免修改代码引入缺陷
- 持续集成，增加提交频率，不要在本地囤积太多代码
- 提高团队技能，任何人都可以对项目快速上手
- 把接口定义好，等双方都开发完成之后就进行联调，排期时把 Buffer 时间留出来
- 使用 MockJS 来模拟请求响应
- 对于使用 git stash 的方式，还可以采用 git worktree 使用不同的文件夹来存放对应不同的分支代码，并且可以自动合并提交
经典摘要
- 做完一个领一个，速度是一个事实，不要估计时间，要观察时间
- 如果你的假设是每个人都已尽力，那么“完不成怎么办？”这个问题靠估算是回答不了的
- 估算只估点数，不要估时间
- 一个迭代做完，做了 20 点，下个迭代继续计划 20 点
- 如果 20 点不够用，要 30 点，团队可以向团队的办法，老板可以向老板的办法
- 任何时间都不要估算每个故事的时间，不要把工作量和时间搅在一起
- 所有卡这样摆好，从左向右，依次是 1 2 3 5 8 ，大于 8 的拿回去拆分
- 估算有个很重要的作用，就是为了理解需要，全员的理解达成一致，不仅仅是为了对工作量进行预期
- 不要对人下菜，优化是团队的事，不要在团队里搞 silo
