异地项目开发管理解决方案
dongx...@gmail.com
队和北京的管理起来,初步想到以下几点,望有这方面经验的同仁多提宝贵意见,谢谢:
我们有一个公网的服务器:
1. 在服务器上建立svn版本控制服务器,并且把svn和apache结合起来,让广州的同事可以通过c/s和b/s两种方式访问版本库;
2. 使用JSPWiki管理项目中的文档;
weihello
Summary of the Patterns
Kickoff A co-located meeting where a project can
begin with a shared understanding amongst, and
trust between, team members
Visits Build Trust Periodic visits by team mem-
bers based in remote locations preserve the trust re-
lationships required for a distributed team to main-
tain healthy relations
Ambassador Have a local expert in remote condi-
tions to resolve misunderstandings in either direc-
tion
Multiple Communication Modes Compensate for
the shortfal l in communication between team mem-
bers caused by distance by affording as many dif-
ferent, simultaneous communications channels as
possible
Virtual Shared Location When team members can-
not share a physical location simple but effective
col laboration software creates a virtual shared lo-
cation
Remote Pair Team members in different locations
to work on problems together, sharing knowledge,
sharing experience, remaining close col leagues when
far apart
在 07-6-6，dongx...@gmail.com<dongx...@gmail.com> 写道：
Jeff Xiong
--
Jeff Xiong
Software Journeyman - http://gigix.thoughtworkers.org
Open Source Contributor - http://rubyworks.rubyforge.org
Technical Evangelist - http://www.infoq.com/cn/
胡凯
- 每天早上的用电话Standup。让两方面都了解进度和困难。
- 应该有一个搭好的演示环境，这样，每一两周广州的同事可以给北京的同事演示软件的目前的特性。
- Wiki
- 有专人负责收集大家的问题和保持与北京的联系，并且把答案及时的反馈回来。
- 有Matrix帮助北京的同事分析目前项目的情况，Test Coverage, Iteration Point, build time...............
--
When you came to this world, there is no going back, And , when you can't go back, you only have to worry about the best way of moving forward, The rest is up to God, including the danger ---- From <Alchemist>
yans
-Yans
See you Wired:)
zongzi
给主要的几个人员之间，安装好语音通话设备是很有益处的。
随便找个TS或者UC服务器就行。
weihello
Bin Dong
On 6月6日, 下午5时54分, "dongxiao...@gmail.com" <dongxiao...@gmail.com>
wrote:
Jeff Xiong
另一方面，前面也提到了很多降低交流成本的办法，就不重复了。
pengfei wang
Jeff Xiong
Yiding He
weihello
yk where
异地开发的不足，也在这个地方。不管采取啥策略，应该注意用比较低的成本，完成背景信息在团队中的传递。
dongx...@gmail.com
在详细说明一下我们的情况: 我们的需求分析人员,顾问,测试人员都在北京,项目用户也在北京,广州有大概8个开发人员,北京只有3个开发人员.
为了能保证充分的沟通,我觉得一方面要有好的异地开发的管理软件,另一方面要有好的制度(每天上午15分钟skype会议,持续集成,持续测试),最重
要的是
有了制度要能够坚持下去.
乔梁
Korben Zhang
异地开发沟通和交流自然受影响，在机器上聊天的方式，来交流系统没有构建成功作用比较弱。我想异地开发可以采用的方法可能有：
1.语音、视频+白板
2.版本控制
3.定时自动构建
4.监控报告
做事的方式可以多种多样，最重要的是团队成员都能够接受并认同"制度"，对其作出承诺。
--
Following my heart.
Korben(Korbe...@gmail.com)
冰云
内容如下：
异地分布式敏捷软件开发 (Distributed Agile Software Development)
异地分布式软件开发（Distributed Software Development）是指由多个位于不同地理位置的团队进行同一个软件项目的开发
过程。这个词越来越频繁的出现在各种技术媒体中。
异地分布式软件开发不同于外包，它建立在平等关系的两个团队之间。通常是一个公司的不同分公司或办公室间的协作，他们之间大多不存在博弈的合同关系。而
外包是指一个公司将其软件系统的开发委托给另一个公司或组织完成。二者之间是合同的甲乙方关系。
但无论是异地分布式软件开发或是外包，可以接触到实际客户的一端一般称为on-site，另一端可相应的称为off-site，他们可以根据地理位置分
为三类：
（表格略）
异地分布式开发的组织方式
异地分布开发的组织方式有很多种。最常见的一种是公司将完整的团队组织结构分布在两地，每个团队都有本地项目经理，需求分析师，开发者以及测试。同时公
司设定项目总负责人角色，负责两地的沟通与协调。
图略
有的公司将需求分析人员放在on-site一端，开发者、测试人员和项目经理在off-site一方，同时在本地也保持常规的需求分析师。也有公司将测
试人员和开发人员分放在不同地方，一方面开发，另一方面利用时差，在夜间测试并在第二天及时反馈测试结果。
图略
各种组织方式都有其不同的适用场合。然而他们的共同点在于，都是注重micro-management，即加强在本地团队中项目管理和协调，而不是由一
个人同时直接管理两地的活动。同时，也尽量保证团队两边都具有项目协调人、本地项目经理、需求分析师等辅助角色。
基本原则：极尽交流之能事
异地分布软件开发面临的最大问题是交流问题。随着人员距离的增加，交流效率将大大降低（参见Alistair Cockburn的文章），同时交流成本
将极大提高。很多时候on-site一端团队不能把正确的需求传递到off-site一端，这直接造成产品质量的下降。
为了使避免这种情况，应尽量采用一切手段来提高交流的效果。例如，项目经理和团队成员都需要了解其他人的工作状态，一个技巧是可以将你的MSN或Y!名
称后缀写上你在做哪一块的需求。并可以随时和同事通过IM进行交流。
图略：交流频度和价值图，Vincent Massol，2004
每天的定时会议将成为很重要的一个很重要的交流方式。如果团队的人数较少，大家可以按照站立会议的方式在电话会议系统中说明自己的情况和遇到的问题。如
果人数较多，一种可替代的方式是每个团队自己进行每日例会，并由个项目的项目经理和需求分析人员进行另外的会议以便协调工作。
如果两个团队时差较大，例如中国北京时间和美国东部时间时差12-3小时，想要进行直接的电话会议交流很困难。如果遇到3个处于不同时区的团队，更是经
常不可能找到一个合适的时间来进行任何的会议。在国际化的公司中，起早贪黑的进行几地的电话会议很常见，但这却不适用于整个开发团队。对这种情况，每日
的开发状态邮件是很有用的。每日开发结束后由项目经理或成员来根据团队的情况来撰写一天的总结，并发送给远端的团队。
交流的障碍经常发生在陌生人之中，如果两地的开发人员互不熟悉，可以考虑将双方人员的照片贴在墙上，以增加熟悉感。可行的话，进行可视会议和当面的会
谈。尽量减少陌生感，使交流效果提升。
任何交流方式都比不上面对面的交流。异地开发时，off-site一端很容易丢失on-site一端与客户交流的语义上下文和环境。如果情况允许，公司
应该设立常规的出差和轮换制度。让一部分的团队成员到另一端，见一见一起工作的同事，了解一下客户的需求和感受一下不同的环境。
敏捷开发过程的改进
般的敏捷过程中，都会有一个初始阶段，在这个阶段了解开发需求和制定发布计划。要进行这样的活动，最理想的办法是让所有人都出差到on-site一端，
一起了解需求和建立共识。这将会对后面的开发有很大帮助。如果由于人数或成本不可行，至少要派遣所有的需求分析师和项目经理、协调人以及部分测试人员到
场参与。对于迭代一级的计划，应该由两地的项目经理和需求分析师提前进行计划会议并做出决定。
日常的项目管理工作中，采用卡片墙的方式只适用in-house的开发。在异地开发中，为了使得每个团队都可以了解到团队任务，至少需要在两边开发室都
设立卡片墙，并保持同步。可以采用在线工具帮助进行项目跟踪，例如Mingle或Trac，都是适用的在线工具，同时也是在线Wiki或共享知识库。
项目协调人，应当制定完善的交流计划和交流机制。例如前文提到的每日的例会和每日开发状态邮件，每周的需求交流计划，问题的提出和反应机制等等。这些应
当制定成为团队守则来遵循，并随着实际情况的变化修订。交流不怕多，只怕不充分。
一个共享的代码版本控制系统是必须的。例如在公司内网建立一个SVN并通过VPN来使用。On-site和off-site团队可建立自己单独的持续集
成环境，但需要保持系统环境的一致。两方的开发人员都应该保证每日离开办公室前的提交通过集成。这样可以避免异地团队开始开发不至于被失败的集成所耽
搁。
基本的敏捷时间必不可缺，例如测试，尤其是功能测试。On-site的QA应当在需求确定的时候制定好验收条件。一个描写良好的验收条件会对开发人员有
所帮助。尤其是在On-site一端不能及时解答问题的时候，会起到很大的作用。
每个迭代结束时，应尽量安排一个两地同步的演示会议。让所有人都在电话会议上看到这个迭代的成果。迭代后的总结与回顾也应当两地一起进行，如果人数和条
件不允许，可以分别进行，并互相通报回顾结果和改进方法。
离岸团队的参与度
多团队中，处于on-site的成员由于可以接触到客户，他们的话语权可能会被放大，使得on-site一边的人倾向于命令式的消息传递，直接指派需求
和开发进度，而忽视了对需求背景情况和上下文进行介绍。这种情况可能造成off-site一端团队产生抵触心里，从而导致项目的失败。
解决方法是提高off-site团队的参与度。如制度性的进行人员轮换，让两端的团队成员有所接触，并互相熟识。定期组织两个团队的共同活动。如果都处
于一个时区，可以考虑进行每周的Learning Lunch，大家在互相能看到视频的情况下一起吃饭和听讲座。讲座内容可以是任何话题，例如一些项目
相关的技术决策等等。
不要忽视offsite团队的任何意见和建议，他们在很多时候能从另一个侧面对项目提出见解。鼓励offsite团队决策和发起讨论，这样可以提高他们
的参与度。
实施异地开发的最初目的是为了降低人力成本和运营成本，一些跨时区的异地开发还可以提高时间利用效率，实现全球24小时开发。然而，异地开发带来了高昂
的交流和管理成本，如果处理不当将直接导致项目或产品的失败。
近年来随着国内软件公司业务的发展，异地开发项目将会越来越多。全球化的进程也会使得外国公司开展更多类似的开发。异地开发项目将会逐渐发展和普遍。可
以想像，多年以后，如果一个公司没有异地开发的团队，将会是多么的令人诧异。
On Jun 7, 11:07 am, "Korben Zhang" <korbenzh...@gmail.com> wrote:
> 现在软件由分布全球各地的团队构建的形式比较多了。比如开发人员相距十分远，美国和印度。开源项目开发运用异地团队形式是非常普遍的。
>
> 异地开发沟通和交流自然受影响，在机器上聊天的方式，来交流系统没有构建成功作用比较弱。我想异地开发可以采用的方法可能有：
> 1.语音、视频+白板
> 2.版本控制
> 3.定时自动构建
> 4.监控报告
>
> On 6/7/07, 乔梁 <sagittatius.q...@gmail.com> wrote:
>
>
>
> > 做事的方式可以多种多样，
> > 最重要的是团队成员都能够接受并认同"制度"，对其作出承诺。
>
> --
> Following my heart.
> Korben(KorbenZh...@gmail.com)