软件开发中团队协作与开发流程

<script type="text/javascript"> </script> <script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"> </script> 简单，有效的工作流程

在团队协作中，不能想改什么就改什么，很多东西是互相依赖和制约的。

我的经验：
允许同时check-out，这样提高效率。

一般dev工作流程：

1。开始工作，选择 work item.

2. sync/build/deploy/simple test, 确保你sync 的版本是能够正常工作的，这样可以避免混淆 - 是这个版本本来就有问题呢？还是我的修改导致了这样的问题？

3。check out 文件，开始修改。

4。个人测试，通过，在根据情况作必要的集成测试。

5。Code-review （什么？ 你们不用做 code-review？），根据code review 的意见在作修改。

6。认为可以check-in 的时候，先sync。再build，再deploy/verify 这样才能保证check-in 不会导致 build break。

7。Check-in，记住要把 step1 的work item 在check-in windows 中加上。这样别人才能知道你这个check-in是干啥的。以后可以从work item 中的“link” 找到与之对应的check-in。


如果代码合并（merge）的时候有冲突，后面check-in 的同学要负责保证代码 merge 正确无误。

另： 一个check-in 可以包括很多文件，不要一个一个文件地check-in，而是把所有文件做成一个 shelfset （参见命令的解释），把整个shelfset check in。 这样保证操作的原子性（atomic） - 如果成功，所有文件都会更新，如果失败，所有文件都不受影响。


Check-in Policies
目前，我们设置了三条Check-in Policy，大家在Check-in代码的时候应该都感受到了：

1。禁止Multi Check-out

2。Check-in必须和Work Item相关联

3。必须有Code Review

这3条Policy的设定是为了进一步控制Check-in Code的质量，避免代码冲突。

但是现在遇到了一些问题，突出表现在“只要对一个文件修改，就会自动check out……这个让大家晚上的开发出现了不少冲突”。

邹老师的帖子，简单，有效的工作流程中描述了常规的团队编码的流程，我们在课上也讲过。但是基于以下现状，我们在开始的头几天还是需要把Check-in Policy设置的严格一些：

1。经过上次的讨论，目前我们20个同学的工作基于同一份Source Control，不使用Branch。这会减少后期Merge的工作量，但对每一次Check-in的要求提高，遇到任何冲突必须马上解决

2。大家对团队开发模式还不是很熟悉，对ASP.NET，Community Server的编程模式还在探索之中，在这个过程中很可能修改了本不应该修改的代码文件

3。大多数时间不是用在修改源代码，而是对源代码的学习、探索中，这时对代码的修改可能更多基于研究的目的，而不是添加新功能

要解决“只要对一个文件修改，就会自动check out”的问题，可以在Souce Control中改一下设置，要求必须“明确”的Check-out。这样大家在本地进行研究的时候不会出现冲突。当你确定要修改code时再check-out。

当然Single Check-out会影响并行开发的效率，我们会在大家逐渐熟悉VSTS的协作环境、流程，对Community Server的开发模式也有了一定了解后放宽Single Check-out Policy，但是大家仍然要尽量避免Multi Check-out的情况，以免在Merge时遇到太多的问题。


Daily Report
建议的Daily Report格式：

引用内容

Highlights:

1. Blahblahblah…

2. Blahblahblah…

…

Lowlights:

1. Blahblahblah…

2. Blahblahblah…

…

To Do Next:

1. Blahblahblah…

2. Blahblahblah…

…

在Highlights部分总结一天的成果，如完成了哪些Work Items，是否有Feature实现，取得哪些进展，哪些工作是“On Track”的。

在Lowlights部分列出哪些是预期要做，但是没有完成的，还有哪些没有解决的问题（Open Issues），进度是否延迟。

To Do Next部分是第二天要开始/继续的工作，即接下来的打算。这些内容应该发映在后面几天的Highlights/Lowlights中。

PM可以从团队成员的Daily Report以及Work Items完成的情况中了解整个项目的进度，当然，Face to face的沟通也必不可少。

千万要避免的情况：每天的Daily Report都是Highlights，但里程碑就是不能按计划到达……


分工合作 一个自主运行，自我发展，自我约束的境界

没错，接下来的工作需要大家自己来管理自己，展示你们团队风采和协作能力的时候到了。

PM要Drive整个开发的进度，激励团队成员，做好团队内部、团队之间以及和老师之间的Communitcation工作，切记，PM是Communication Hub。

Dev Lead需要带领大家进行一些技术难点的攻关，促进技术讨论，协商技术架构的制定。Dev Lead应该清楚的了解每个Dev面临什么样的技术问题，有哪些Open Issues，并及时沟通数据库、编程调用接口等涉及各组之间的依赖性、相关性问题。

Team Lead负责后勤、行政方面的工作，配合我们的各个“委员”做好他们的工作。



Milestone 制定开发阶段的里程碑（或者Internal Release)

从昨天的Review情况来看，很多人对Milestone还是不太理解。制定开发阶段的里程碑（或者Internal Release)，有几个基本原则：

1。每个里程碑尽可能独立，有明确的、详细的交付成果。必须清晰定义哪些Feature在M1实现，哪些在M2实现

2。里程碑具有“二分性”，里程碑只有“做完”和“没做完”两种状态，90%,99%完成都不能算作里程碑到达

3。没有“计划外”的里程碑，也就是说当所有的里程碑都到达后整个项目就应该已经完成，所有的任务都应该列到里程碑中

4。里程碑没有按时到达预示着项目的风险，可以采取的措施：a)调整计划；b)采取纠正措施补救进度拖延

5。各个Team应该把里程碑进一步细分，以进行更精确的控制


Test
各个Team还有宝贵的一周时间对项目进行最后的完善。建议大家：

进行更多的Usability Test，让你们的产品更好用，更易用
补充、完善Test Cases，对产品进行完整的测试
在Release之前至少要有一次Full Test Pass，即所有的测试用例通过
准备Final Presentation！


7 Habits of Highly Effective People《高效能人士的七个习惯》，提醒自己：

1、Be Proactive (积极主动)
2、Begin with the End in Mind (以终为始)
3、Put First Things First (要事第一)
4、Think Win Win (双赢思维)
5、Seek First to Understand then to be Understood (知彼解己)
6、Synergize (统合综效)
7、Sharpen the Saw (不断更新)

  <script type="text/javascript"> </script> <script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"> </script>