1. 客户背景
客户属于传统软件产品研发行业,在北京、武汉、济南三地分别有研发团队,三地协作共同研发一款软件产品
2. 客户需求
采用敏捷开发,提高交付的速度,快速响应市场
3. 遇到的的困难和AgileDo的解决方案
3.1 三地的团队各自有独立的研发流程,不容易协作
项目建立伊始,就要决定如何协作。AgileDo的敏捷教练和所有团队成员一起组织了一个“工作协议”活动。我们定下来用 Scrum @ Scale 作为异地协作的模式,并确定一些实践方式,如怎样做结对、用哪些工具、质量目标、工作的完成定义等等。然后在Wiki上记录下来,这样整个团队就有了共识。一旦这些共识需要修改,比如在回顾会议上提出改进,这些实践就要在wiki上更新,有新人加入的时候,他们看到的总是最新内容。为了让这些实践可以更好的落地,项目开始的最初,北京、武汉两地的团队各自派出三名核心成员,和济南的团队一起工作了三周,在工作中进行实践的优化和达成共识
3.2 异地协作如何处理业务依赖
我们的模式是让每个本地团队尽可能自给自足,以减少对对方的业务依赖。具体而言,是在Sprint 0的阶段业务切分时就做到三地的业务是松耦合的,每个团队的业务相对独立,这个是CPO和三地的PO工作的重点之一
3.3 异地协作如何处理集成的风险
三地的团队有公共的持续集成服务器,核心代码要求必须有Unit Test,核心业务必须由本地的核心开发人员结对完成,每个版本的代码提交都会进行代码的自动集成
3.4 异地协作如何处理平时的沟通
腾讯会议等软件是我们的首选,微信群的讨论也是我们异地多人讨论的常用方式。在Wiki上会分享三地对应事项的紧急联系人,以保证任何事情都可以无需等待的处理。在公共服务器上有项目管理软件,记录三地的项目进展状态。因为我们是分布式团队,虽然每个团队都有物理白板进行每日站会,但我们会要求所有的团队都在工具上继续项目进展的细节,以帮助其他地方的团队更好的了解整个项目的进展和风险
4.效果
以上列出的困难和解决方案仅仅是工作中的一部分。AgileDo的教练和客户团队现场持续共同工作,以解决更多实际场景中遇到的障碍。目前,客户三地的团队协作已经可以稳定的以两周的频率交付产品的增量版本
1803



被折叠的 条评论
为什么被折叠?



