分布式软件开发(2)

发表于:2014-05-26来源:博客园作者:李响点击数: 标签:分布式开发
站会: 相信了解敏捷的人对站会这一实践都不会陌生。在分布式开发过程中,我们不仅开展了团队的站会,还进行了基于角色的站会。一般而言,团队的

  站会:

  相信了解敏捷的人对站会这一实践都不会陌生。在分布式开发过程中,我们不仅开展了团队的站会,还进行了基于角色的站会。一般而言,团队的站会更多的关注故事卡的状态流动,检查路障,而不会关注每个不同角色的具体工作;而在基于角色的站会上,例如开发站会上,开发人员之间可以讨论技术上的某个难点。同样的,业务分析人员也要通过每日的业务分析站会来了解产品经理的思路变化和业务部门的更新。 我曾经遇到过一个项目有来自三地的测试人员,那么测试人员之间的站会就非常重要,测试人员利用角色站会这一机会讨论测试策略。随着项目的演进,测试的重点也不断转移,从一开始关注功能测试到逐渐关注集成测试,角色站会给他们提供了一个契机及时讨论项目碰到的问题和机会。

  迭代计划会议:

  迭代计划会议也是常见的实践。在分布式的场景下,迭代计划会议需要更多的准备,要求各方团队成员提前理解下一迭代需要完成的需求,这样大家可以在迭代计划会议的时候着重讨论有疑惑的需求,而不是浪费很多时间在解释需求本身是什么上。在答疑解惑之后,大家对要完成的迭代目标必须形成一致的意见。同时,在分布式的开发中,不同地域方的团队成员会更加关注本地团队所能完成的需求,却忽略了其他地域团队的开发速度。在其他地域团队遇到困难时,更重要的是帮助对方一起完成对方做的需求,而不是只关注自己做的需求。通过一起达成迭代目标,让大家分享共同的责任感。

  在实际项目过程中,通常业务分析师会提前将计划的需求故事发给团队成员。运用合适的分布式项目管理工具会让这一过程更加容易,如 Mingle 或者 Jira。在工具中整理出下一个迭代的故事墙,让团队成员提前看到虚拟墙。在迭代计划会议上,主持方将虚拟墙打开并屏幕共享给其他方,这样各方就可以关注在同一个需求故事卡的讨论上。

  回顾会议:

  由于各种限制原因,分布式团队很容易产生沟通不足现象。而回顾会议创造了必要的沟通桥梁,因而非常重要,一定要保证所有方都能参与进来。远程回顾会议通常利用在线白板,让每个成员提前在在线白板上提交上个迭代里做得好的和值得改进的地方。这样,当回顾会议开始后,每个人都是有所思考的,提出的意见更有深度,而且也可以更好地利用回顾会议的时间一起探讨所有人都关注的问题。通常,通过回顾会议可以发现,处于不同地理位置的多方成员往往关注的事情也不同,而会议上各方成员又可以了解对方在担忧什么,遇到了哪些困惑,并将这些担忧困惑分享,形成大家都认同的改进行动。

  结对编程

  结对编程这一实践对于知识的传递非常重要,即便在分布式团队中,结对编程依然是非常重要的实践。合理地利用时差,在各方重叠的工作时间里通过屏幕共享工具远程结对,是保证代码质量的重要手段。

  每天合理地利用远程结对不光可以传递知识,同时也是一种有效地影响其他团队成员的方式。远程结对可以让咨询师清楚了解处于不同地域位置的客户团队的代码水平、代码风格和思维方式,从而可以通过每天频繁的结对编程言传身教最佳实践。这种影响行为改变的方式效果显著,而且对于增强团队成员互相了解信任,并形成有统一责任感的“同一个团队”,也非常有帮助。

  但不可否认,远程结对会影响开发效率。并且,由于各方工作时间安排以及公共假期等原因,很难保证远程结对的频率。所以,远程的代码评审(Code Review)就显得格外重要。每天各方开发人员在一个固定时段去评审所有提交的代码,能够让团队成员不光关注自己,也了解别人做了哪些代码改动。同时,代码评审对于形成统一的代码风格也很重要。当处于远端的咨询师想去去影响客户的代码风格时,如果无法让所有的人都理解为什么要用某种风格,那么之后的一致性也就无从谈起。而远程代码评审就能在沟通不足的条件下,从分展示好的风格带来的改进(Lead By Example),从而达到提成远程提升客户技能的目的。

原文转自:http://kb.cnblogs.com/page/158996/