第四章：敏捷开发与版本管理
说实话，我见过太多AI项目死在半路上。不是技术不行，是协作乱了。代码改来改去不知道哪个版本能跑，今天修好的bug明天又冒出来。嗯，这章我们就聊聊怎么用敏捷开发和版本管理，让团队像精密仪器一样运转。
4.1 Git Flow工作流：别让代码变成一团乱麻
Git Flow是我个人最推崇的分支模型。说白了，它给代码仓库画了条清晰的生命线。我早期带团队时，大家直接在master上改代码，结果上线前三天发现有个功能被覆盖了...那场面，简直灾难。
Git Flow的核心分支：
- master：只放生产就绪的代码。每次合并都要经过严格review。
- develop：日常开发的主战场。所有功能分支都从这里拉出去。
- feature/*：新功能开发分支。比如feature/face-detection-v2。
- release/*：发布准备分支。用来做最后的测试和修修补补。
- hotfix/*：线上紧急修复。直接从master拉，修完再合并回去。
我的经验：feature分支命名最好带上任务编号，比如feature/REAL-342-optimize-inference。这样git log一看就知道对应哪个Jira ticket，追溯起来特别方便。
下面这张图展示了Git Flow的完整流程：
小技巧：在.gitignore里把模型权重文件（.h5、.pth、.onnx）都加上。这些文件动辄几百MB，放git里每次clone都痛苦。我一般用Git LFS或者单独的对象存储来管理。
4.2 Sprint规划：两周一个迭代，刚刚好
Sprint规划说白了就是定下未来一到两周要干什么。我个人习惯用两周作为一个Sprint周期。太短了来不及做完整功能，太长了容易跑偏。
一个典型的Sprint规划会议：
- 回顾上一个Sprint：哪些做得好？哪些需要改进？
- 梳理Backlog：把产品需求按优先级排好。我常用MoSCoW法则——Must have、Should have、Could have、Won't have。
- 估算工作量：用故事点（Story Point）来估算。别用小时，那玩意儿不准。我团队用斐波那契数列：1、2、3、5、8、13。
- 承诺Sprint目标：选出这个Sprint要完成的故事点总和。一般不超过团队历史速度的80%。
避坑指南：我曾经犯过一个错误——把Sprint排得太满。结果团队成员每天加班赶工，代码质量直线下降。后来我学乖了，每个Sprint留出20%的缓冲时间，用来处理突发bug和技术债务。
4.3 每日站会：15分钟，站着说完
每日站会，说白了就是每天早上花15分钟对齐一下进度。我见过很多团队把站会开成了汇报会，每个人讲10分钟，那就不叫站会了，叫坐会。
站会的三个标准问题：
- 昨天我做了什么？
- 今天我要做什么？
- 有什么阻碍我前进？
嗯，就这么简单。但实际操作中，我建议大家注意几点：
- 站着开：真的站着。坐下了就容易聊嗨。
- 过任务板：用物理白板或者Jira、Trello都行。把任务从「进行中」拖到「已完成」的感觉，很爽。
- 不深入讨论：遇到技术难题，站会后拉个小会单独聊。别让全团队陪你debug。
我的习惯：站会前我会快速扫一眼git log，看看昨天大家提交了什么。这样站会上如果有人忘了说某个改动，我可以提醒一下。你想想看，这能避免多少信息遗漏？
4.4 代码Review机制：不是找茬，是互相学习
代码Review，很多人觉得是浪费时间。我刚开始也这么想。直到有一次，我review同事的代码时发现他把学习率和batch size写反了...那个模型训练了三天，结果全废了。从那以后，我再也不敢跳过Code Review。
好的Code Review应该怎么做？
- 小批量提交：每次PR不要超过200行代码改动。超过500行的Review，基本没人能认真看完。
- 关注逻辑，不纠结格式：缩进用空格还是tab？这种问题交给linter和formatter去处理。Reviewer应该关注算法逻辑、边界条件、性能瓶颈。
- 给出建设性意见：别说「这代码写得不好」，要说「这里用列表推导式会更高效，你看这样改行不行？」
- 及时Review：我要求团队在4小时内响应PR。拖太久，上下文就丢了。
警告：千万别在周五下午提交大PR。没人想在周末前review你的代码。我吃过这个亏——周五提交的PR，下周二才有人看，中间白白浪费了三天。
下面是我团队常用的Code Review检查清单：
| 检查项 | 说明 | 优先级 |
|---|---|---|
| 功能正确性 | 代码是否实现了需求？边界情况处理了吗？ | P0 |
| 性能影响 | 有没有不必要的循环？内存泄漏风险？ | P0 |
| 可读性 | 变量命名是否清晰？有没有注释？ | P1 |
| 测试覆盖 | 新增代码有单元测试吗？ | P1 |
| 安全性 | 有没有SQL注入、路径遍历等风险？ | P0 |
| 代码风格 | 是否符合团队规范？（交给自动化工具） | P2 |
核心观点：敏捷开发不是流程，是文化。Git Flow、Sprint、站会、Code Review，这些工具只是载体。真正重要的是团队之间的信任和沟通。我见过用最简陋的流程做出最牛产品的团队，也见过流程完美但产品一塌糊涂的团队。你想想看，差别在哪？
最后分享一个我个人的小习惯：每次Sprint结束后，我会把git log导出来，看看这个Sprint的提交频率和代码量。如果发现某几天提交特别少，我就会去问问那个同事是不是遇到了什么困难。有时候，一个简单的「需要帮忙吗？」就能解决大问题。
公众号:蓝海资料掘金营，微信deep3321