背景
我所在的团队是一个海外项目的离岸交付团队，成立于2019年10月，一直保持着7个人队伍，1个BA， 1个QA和5个开发。
团队的发展从一开始的需要客户团队的帮助了解和熟悉业务上下文才能完成交付，后来独立drive并完成交付任务，近期因客户团队核心成员离开，我们帮助客户团队补充业务知识并带领客户团队一起完成业务的交付。
虽然团队成员几经变迁，但业务知识和敏捷实践的理念一直作为团队的支柱得以很好地延续下来，并且逐渐成熟。下面我将介绍团队在这2年多的不同发展阶段，在各项工作活动中如何实施敏捷的。
工作活动
Weekly IPM
每周一BA将会主持一场全员参与的Iteration Planning的会议，会议的内容就是根据PM对于交付任务的优先级，将Backlog中的Story卡进行Groom，并挪到Kanban的 TO Do列表中。
每日站会
我们每日的站会和客户远程参与的。站会的目的是为了更好的了解各个story完成的进度，以及是否有blocker需要得到支持。 通常我们会打开Jira卡片的信息，并由对于工作在这个卡上的成员进行简明扼要的更新。主要包含：已经做到什么进度了，有没有遇到问题，接下来会怎么处理等。
Tech Huddle
每天我们会有30分钟的时间和客户团队一起进行Tech Huddle会议。在团队发展的过程当中，Tech Huddle的会议内容是有不同的含义的：
- 团队成立初期
由于项目刚成立，团队成员对业务知识，历史背景，技术方案等都不熟悉，客户团队会在每日的Tech Huddle时间，解答团队成员提出的问题，并分享更多相关的业务知识以及Review由我们团队提出的Pull Request。
- 团队独立交付期
这个阶段，虽然两个团队独立完成不同的交付任务，但双方都工作在同样的repos上。这个时候的Tech Huddle时间通常用来，交换context，讨论双方的技术方案，或者技术分享等。
- 团队合并工作期
团队合并发生在客户团队核心成员集中离职或转岗，导致团队中新人较多，技能能力和业务知识缺乏导致客户团队的交付很难正常推进。2个团队合并到同一个Kanban Board上工作后，Tech Huddle时间成为给新成员分享业务知识，系统流程，或是讨论实现方案等。
Dev grooming
团队一开始没有Dev Grooming这个环节，带来的问题是开发人员拿到卡就开始做实现，并没有Tasking的过程，对于scope也没有完全弄清楚，直到Review PR的时候才会发现与期望的Scope存在偏差或者有许多遗漏的场景。加入Dev grooming的目的是期望开发人员在这个阶段明确scope，tasks 以及definition of done，并可以做一些实现细节的可选方案，以便于在kick-off时讨论。
Kick-off
在完成story卡的grooming之后，必须邀请BA，QA及部分开发人员进行story卡的kick-off。在这个简短的会议上，需要向BA陈述对业务需求的理解，对QA描述做完后怎么验收，并对其他开发人员介绍实现方案，各方达成一致后能进入到开发阶段。
Pair Programming
Pair的工作方式在项目一开始的时候，大家都不愿意跟别人pair，认为有点浪费时间，并不高效。后来，大家一起学习如何高效的进行Pair，并且当Senior成员带着coaching的意识和其他成员进行pair的时候，团队氛围逐渐变得融洽，大家也都默认采用pair的方式进行工作了，并且在后来的与客户团队合并工作后，也逐渐影响了客户团队。
- 团队内一开始不采纳pair
关于不pair的原因，我曾经采访过几位团队成员，得到的回答是：他（她）太慢了，我一个人写代码快多了；跟他（她）pair我啥也学不到；他（她）不知道我做的这个；他（她）对前（后）端不熟...
- 团队内开始pair
在经历了大家一起对pair programming最佳实践的学习和讨论，建议大家带着分享context，互相学习对方长处的意识，并且让团队成员意识到平稳交付的重要性之后，Pair的工作方式逐渐在团队形成。
- 跟客户一起pair
由于客户团队新成员需要对项目的业务及技术知识有逐步的了解，在2个团队合并工作后，与客户Delivery Manager达成一致，鼓励团队成员进行交叉Pair的工作方式，虽然会由于时差和语言的关系导致一段时期内的效率降低，但对团队的长远发展是有利的。这也成为团队现在的默认工作方式。
Desk Check
当一对开发的pair完成了功能的实现并完成了自测之后, 便会邀请BA和QA来验证功能是否符合期望。
Showcase
- 不定期的mini showcase
项目刚开始的时候，在完成部分功能的实现后，团队会快速邀请客户PM，并展示我们已完成的功能，但时差关系或客户太忙没有时间参与，我们也会采用录屏的方式展示给客户以快速获得feedback。
- 2周一次的部门showcase
整个大部门每2周有一次showcase的会议。在showcase的会议上，团队成员会派出代表在会议上做showcase，展示团队近期已完成的功能。通常在showcase之前，团队的BA，QA会和演讲人一起协作，以最好的方式将价值呈现给客户。
Team Retro
每个月团队都会和客户的stakeholder一起进行1个小时的Retro会议（团队合并工作期间，2周一次retro）。会议主要回顾前一个阶段，团队在哪些方面做得比较好的地方提出肯定并期望大家能继续保持；对做得不足或感到不满意的地方提出讨论并制定相应的action，指定相应的人去执行和跟踪；对提出的疑问由相关人员进行解答，以及对提出的建议进行讨论决定是否采纳等。
小结
团队成立至今已2年半，我有幸在团队成立半年后加入并伴随着团队一路成长。在敏捷实践推广和践行的路上，我们始终在不断的学习，进步。一路走来，团队成员个人持续成长，成员间合作逐渐契合，日常活动逐渐高效，客户合作逐渐稳固，交付实践逐渐平稳。
