一、敏捷开发：从"瀑布"到"小步快跑"
以前做团队项目，我们习惯"瀑布模式"：需求分析两周→设计一周→编码三周→测试一周。结果往往是：编码时发现需求理解错了，测试时发现架构有问题，最后集体熬夜返工。
《构建之法》介绍的Scrum敏捷开发改变了我们的 workflow：
每日立会（15分钟）：
昨天完成了什么？
今天计划做什么？
遇到什么障碍？
刚开始我觉得这是形式主义，直到有一次队友说："我卡在这个API调用上两小时了"，另一个队友立刻说："我上周解决过类似问题，十分钟后帮你看看。"信息透明节省了大量重复踩坑的时间。
Sprint冲刺（2周）：
我们将大项目拆分为可交付的小功能，每两周必须有一个"可用版本"。这种"持续交付"的压力倒逼我们优先做核心功能，而非纠结细节。第一次Sprint结束时，我们虽然只实现了登录和发布功能，但真的可以跑起来，那种成就感比写一万行"半成品"代码强得多。
二、角色认知：没有"我"，只有"我们"
书中提到的功能团队模式让我重新理解"团队"二字。以前我们分工是"你写前端，我写后端，他写数据库"，然后各自为政，集成时接口对不上。
现在我们的做法是：
共同看板：用Trello管理Product Backlog和Sprint Backlog
结对编程：复杂模块两人一起写，实时代码复审
共同负责：Bug不归属个人，而是"团队的债务"
印象最深的是Bug Bash活动：我们花两小时集体找Bug，不批评谁写的代码，只关注如何改进。结果发现的问题比测试阶段多30%，而且团队氛围更融洽了——原来找Bug不是"挑刺"，是共同守护产品质量。
