Regular catch up with client，即 定期跟客户进行沟通，双方共同商议一个时间（工作时间最佳），一起开个短暂的小会，时间上的成本较低。

Catch up的主要参与人员是BA(PM)和TL，通过于客户方Face2Face会议或者online会议进行一个短暂的沟通，沟通内容主要涉及：

1. 我们团队昨天的更新. 
2. 客户昨天的更新 
3. 确认Story。如果有变更，能及时作出调整。 
4. 提醒客户使用我们开发出来的功能，以便我们尽早得到反馈。 
5. 一些节日的问候，嘘寒问暖，表达我们团队的关怀。 

因项目而异，Catch up实践可以大体分为两种：

1. 针对Onsite项目Face2Face形式。因为跟客户在一起工作，就可以较为高效地组织Face2Face的会议，实践证明，Face2Face是效率最高的一种形式。 
2. 针对独立交付项目的Online形式。因为地点、时差等原因，适当调整Catch up的频率，另外选择一个便捷可靠地工具（例如：Fuze, GTM, Skype等），提前设置好环境并分享给客户相关人员。 

通过与客户进行定期的沟通，产生的价值主要体现在客户信任和客户关系方面：

1. 首先，让客户有非常强烈的参与感，以及让他们对项目整个进展的把控（他们会觉得自己才是项目的主导者），增强他们的信心以及对我们的信任。 
2. 其次，让客自己决定功能实现以及及时验收功能，降低了需求变更和打回的风险。 
3. 最后，则是润滑剂了，能够在客户良好的信任的基础上，保持合作关系的轻松愉快，这会为项目的成功交付使上劲。

并不是每一个项目都会有这个实践，有些独立交付的项目，他们每日站会的时候客户也会参与进来，就不需要额外单独的时间去做这件事情了，而有些项目，因为特殊性，客户可能不希望这么频繁的Catch up，这时候需要团队灵活变通，与客户一起商讨出一个合适的时间周期，做出一些权衡，让客户自身觉得舒服。总之，Keep住的一点是：保持跟客户的信息沟通，尽可能早的得到客户的反馈，保持良好的客户关系。

3、Standup

Standup是一项成本小收益大的活动，做好它是敏捷的第一步。

Standup，就是每日站会。我听过一个有趣的事情：在敏捷开发方法兴起的时候，很多传统开发模式的团队跃跃欲试，他们选择从Standup切入。然后每天早上上班后，大家聚在一起开个会（站着、坐着都有），然后该怎么做还是怎么做。他们会对别人说，我们在搞敏捷开发…

没错，Standup就是团队在一起快速地开一个会，大家挨个的更新一下自己的状态，更新包含以下几个方面：

1. 昨天完成的工作。 
2. 今天计划做什么。 
3. 面临什么阻碍。 
4. 自己手头Story的进展。 
5. 是否存在技术风险。 

既然是快速的会议，Standup的时间就不宜过长，建议5~15分钟。最好是站着开会，因为研究表明，当人们坐着开会的时候，会议的时间会被无形中拉长。Standup的时间安排在工作时间开始后的半个小时最佳（比如9:00上班，9:30开始），这样大家就不用一到公司就急急忙忙的参加Standup，大家有个缓冲的时间，比如说设置电脑，泡咖啡，沏茶，整理今天的todo list等。

没有什么特殊原因的情况下，确保团队成员都要参加，如果一些人因为特殊原因经常不按时到，适当调整Standup的时间，但也不宜太晚。

而对于规模很小的团队（3~5人），也强烈建议执行Standup，因为它的成本真的很低。

或许有人会觉得：大家天天都在一起工作，沟通如此方便，何必要这项活动？ 这有点深处酒巷中不觉酒香的味道了。站会能够给团队带来的价值不容忽视：

1. 让大家进入一天的工作状态。 
2. 清楚自己的Story的进展，提醒自己把握好时间，或者激励其他成员的开发进度。 
3. 让团队成员知道项目其他地方的进展。 
4. 如果谁遇到不好解决的问题，可以将问题抛出来，大家一起积极讨论解决方案，也能寻求其他人员的技术支持。 
5. 避免在重复造轮子而耗费时间，让大家知道目前团队中可供复用的解决方案。 
6. 帮助Team Leader了解哪些领域需要更多的帮助，从而更好地分配资源。

猜出来的需求往往是不靠谱的，最终需要打回重做！

所以kick off能够有效的避免Dev自行臆测业务需求而产生的浪费。除此之外，能够弥补BA在编写Story的时候技术视角的一些遗漏。

一些项目会引入好的开发实践，比如说BDD。它能按照人类自然语言去描述一个功能的实现。我们的Story描述通常会参照这种方式: as...when...then...when...then。这个时候，DEV、QA、BA可以在Story kick off的时候利用一些测试工具（Cucumber）一起来编写Story验收测试用例（主要由QA来编写），DEV负责编写代码来通过这些测试。理想情况下，验收测试用例如果正确完整，当所有测试都通过后，意味着Story功能已经完成。而且这种TDD的方式，代码出现bug的几率也会大幅度降低。