简单，有效的工作流程

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

我的经验：
允许同时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！