极限追问 025 - 依赖关系怎么办?

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

文章作者: HoldDie
版权声明: 本博客所有文章除特別声明外,均采用 CC BY 4.0 许可协议。转载请注明来源 HoldDie !
评论
  目录