每天走进办公室，第一件事情是冲上一杯咖啡，在Pantry和同事聊会天。然后回到办公桌前，查收前一天未读的邮件。
项目经理和商业分析师打开产品代办列表（Product Backlog），看看当前项目的进展。大家还会检查开发环境、测试环境和模拟的生产环境，如果有问题，这是需要第一时间尽快修复的。
产品待办列表是团队在进行迭代式开发时经常使用的一种工具，来管理在未来迭代中将要实现的用户需求。出现在“产品待办列表”中的用户需求一般以“用户故事”为单位来组织。
传统的“堆栈式”产品待办列表强调按用户故事的优先级排序，越靠近栈顶的用户故事优先级越高，且拆分得要足够细，以便让团队在下一个迭代开始时从中选取要开发的用户故事。
迭代启动会议（IPM）通常发生在每个迭代的第一天，团队成员一起制定迭代计划。这个会议由商业分析师主持，团队一起同步几个方面的内容：
下一个迭代的用户故事;
对下一个迭代的期望和计划;
风险的评估和总结。
不同的人对需求的理解是不同的，所有团队成员都要明确用户故事的相关内容、所要实现的功能、满足了哪些条件用户故事才算完成。迭代会议的主要产出是下一个迭代中需要完成的用户故事，这些用户故事即为下一个迭代所要完成的主要目标。
站会（Standup Meeting）是团队一天协同工作的开始。团队在物理墙前快速开一个会议，团队成员逐个更新自己的状态：
昨天完成的工作；
今天计划做的工作；
面临什么阻碍，需要什么帮助；
自己手头用户故事的进展，是否存在技术风险。
并不意味着每个团队必须一直使用这个日程，团队会根据自己的情况，调整站会的安排。举个例子，运行了几个迭代后，团队发现讲述“昨天做了什么”并没有带来实际价值，而及时暴露潜在的风险更为重要，于是团队会将站会的时间更多地放在“我的任务有什么风险”的更新上。
既然是快速的会议，站会的时间就不宜过长，10分钟左右为佳。建议团队成员站着开会，因为研究表明，当人们坐着开会的时候，会议的时间会被无形中拉长——会议的重要目的是让每个人在自己以及同事面前作出承诺，这个承诺是团队之间的承诺。
站会结束后大家就开始了一天的工作。在敏捷开发中，所有需求都会以“故事卡”的形式拆分、细化、并传递给开发团队。
用户故事开卡（Story Kick-off）常常是一天敏捷软件开发的开始。在每个用户故事开发之前，要确保BA、DEV和QA对用户故事理解一致。这个沟通活动通常由DEV讲解该用户故事要完成的功能及验收条件（AC：Acceptance Criteria），一旦发现任何疏漏，BA会及时补充。DEV有任何疑惑也需及时提出来，当场确认，使这些功能得以正确实现。在后续开发中如果碰到任何疑惑，也应及时找BA了解清楚。QA会严格按照AC来验收用户故事。
结对编程（Pair Programming）是指两位程序员坐在同一工作台前开发软件。
结对编程将代码评审做到极致：错误发现地越早，修复成本越低；
结对编程是关于代码的标准、结构的变化（重构）、架构演化的知识，在 Dev们之间尽可能以无缝的形式流动，取得共同理解和学习的过程，并减少代码对特定人的绝对依赖。
Dev把自己对应的卡开发完成并提交代码后，需要和需求输出方（商业分析师）在测试环境下desk check以验收需求，否则不可以将卡挪到下一个泳道，这个过程叫Story Sign Off。
时空的距离不应成为团队协同工作的阻碍，如果能有超过四个小时的工作时间重叠，Always on（由电视、Mac Mini和即时通讯工具组成的无间断视频）一定要有。实时视频能增加许多亲切感和趣味，拉近团队成员的距离；更能让包括站会、desk check在内的很多敏捷实践变得容易。有了Always On，信息不回抬头喊一喊，开会了朝屏幕招招手，方便直接，即使大家相隔千里，也能随时就问题展开讨论。
敏捷团队非常重视学习和分享，通过做session实现能力培养和知识传递是一种很常见的方式。一天的中午，各个团队会有计划性地举行session分享。为了将知识分享的供需可视化，可以建立一个session墙，分成两部分：一边由团队成员写出想要了解的技术、业务知识，相当于是需求方；另一边写着根据需求而安排的session，相当于是提供方，这样清楚明了，便于跟踪。
在一天的工作中，有时候会组织功能演示（Showcase）。Showcase是敏捷开发流程中的又一个实践，通常发生在每个迭代的最后一天。团队把一个迭代中开发好的功能给相关人员演示，并收集反馈，以便在下一个迭代中可以对变化作出快速响应。同时每个利益干系人可以清楚地看到项目当前的进展，也许会超出预期，也许会低于预期。但不论是让人惊喜还是沮丧，都给大家看到了项目进度的真相，因此Showcase也是对项目检查和调整的反馈环。
在迭代结束的时候，团队做改进和调整的活动有两个：Showcase是对项目的改进和调整；回顾会议（Retrospective）是对团队工作方式的改进和调整。回顾会议可以让团队停下来思考并审视：我们哪些地方存在问题，需要改进；哪些地方做得好，需要保持。团队的工作流程、团队之间的协作方式等都可以是回顾会议的思考框架。
开发团队在完成每天代码之后，会聚在一起评审当天的代码，我们称之为代码审查（Code Review) 。团队经过一天的高强度的思考与编码，适当地停下来，看看其他人写的代码，同时将自己的代码讲解出来，往往能意外地获得一些灵感，或许能解决自己面临的阻碍。
团队会保证代码能够与已有代码进行集成，并且在一天的工作中也会尽可能频繁地把代码捡入到单个主线分支中。如果构建失败，团队会把修复CI当作第一优先级的事情来做。
完成Code Review，忙碌而有趣的一天结束了。在《选择三件事》这本书中，作者建议读者只要放弃什么都想做的执念，我们的生活就会更充实。每天我们应当在工作、睡觉、家庭、朋友和健身这五件事中，选择做三件主要的事情。回到家，陪陪家人、看看书、早点休息。新的一天会更加精彩！
后记——敏捷文化 OVER 敏捷实践
我在文化四象限中写过组织文化模型，包括协作型、控制型、培养型和技能型。每一种文化都有其优势和劣势，不能说哪种更好。只是对于某些类型的工作，或其当下所处的场景，一种文化也许比其他文化更适用。大部分组织都有一个主导的文化类型，并以其他三种文化的元素为辅。
敏捷有很强的文化特征，其核心是协作型文化，其次是培养型文化。在协作型、培养型文化为主导的组织里，敏捷开展就会容易得多，这是因为这样的组织天生就有敏捷的基因。反之，在控制型为主导的组织里，敏捷文化和企业自身文化的摩擦就会比较多。
本文讲到了很多敏捷实践。最好的方法是我们在开展这些敏捷实践的过程中，潜移默化地牵引大家思想的转变，逐渐让团队所有成员理解实践背后的意义，从而让大家自然而然地接受敏捷思想。随着时间的推移，个体与个体、个体与团队、团队与团队在敏捷实践中的频繁互动，团队里的大部分人的思想和行为产生了改变，文化也就自然发生了改变。
这样的团队不只是实践敏捷，更是掌握了敏捷思想，学会了用敏捷的价值观和原则思考，逐步达到知行合一，我们称之为文化敏捷。
阅读：
本文作者万学凡，ThoughtWorks首席咨询师，武汉。作者保留本文一切权利，未经许可请勿转载。
