敏捷开发的入门

现在互联网行业的开发工作或多或少都受到敏捷的影响，都讲究持续迭代，持续集成。构建最小可用的应用，及时反馈，而不是等造完了火箭之后发现原本的需要是要造个飞机。

每天站会，应该也是从敏捷延伸出来的概念。不过公司这边每天的站会越来越流于形式了，很多时候我们确实不怎么关心别人的进度，而是为了证明自己干了活。站会本来的目的应该是及时暴露风险，不过我们也确实达成了这个目的。

对于 tdd 的理解确实又加深了一些，不是所有场景都适用于 tdd。tdd 更多情况下应该用于稳定的功能，以及测试先行，当你写一个方法时，就要明白它的输入输出是什么样子的。这样子，其实自己大脑也会清晰很多。

以及项目时间的预估，自己真的能否清除预估准确别人的时间。“做事所花费的时间总是比你预期的要长，即使你的预期中已经考虑了侯世达定律”。书中给的解决方案是建议故事点法，大家一起来对难度规模做一个估计。每个人有自己的点数，这样子会相对准确一些。不过还是要有功能缓冲和进度缓冲，还是要做任务拆解，优先保证核心功能。

基于分支的开发，有个问题确实比较严重，如果别人对你的方法有依赖，你很难对这些方法做一些重构的优化，比如重命名或者是修改参数。因为你的修改在合并主分支前对依赖方是不可见的。等到依赖方將其分支合入主分支的时候，就真的是火葬场了。

代码审查我一直觉得也是很重要的东西，但公司这边确实实践得很少。

现在就只能吸收这么多了，未来有新的感悟可以再回来看看。