Scrum实际应用（一）

　　在前一篇文章《Scrum开发模式》中已经详细的介绍了Scrum的运作模式，同时大家也初步了解了Scrum是什么。这篇文章主要介绍在Scrum模式下如何利用工具来实现我们的敏捷开发。

　　要准备的软件：

　　MS VS 2012

　　MSSQL 2008R2 SP2

　　TFS 2012

　　TFS Power Tool 2012

　　软件的安装及配置不讲，不懂的尤其是关于TFS安装配置可以在Google中搜索相关文章，介绍的挺全面的。

　　假设：我们已经创建了TFS服务器，并且VS连接到TFS服务器。

　　那么，我们的解决方案在TFS中是怎么呈现的呢？如图：

 　　

　　是的，我们的解决方案就孤零零的在那里，没有分支，没有兄弟姐妹。那么根据我们Scrum中的规范，我们需要进行迭代，但是迭代不能在“Main”上，而应该在分支上。同时，我们一个迭代结束后会有产品，当然我们的产品也不能在“Main”上，所以，我们要这样调整我们的TFS。

 　　

     我们先来看迭代1和Main这一部分，可以看到，我们从Main主线上分出了一个迭代1，我们所有的开发工作都在迭代1上进行，当迭代1完成迭代，就要把代码回归合并到Main上。再来看Main和产品1，左面的发布应该都能看懂，就是从Main上发布了一个版本出来，但是后面的黄线“合并”是什么呢？通常，我们发布一个版本交由客户试运行，在试运行阶段多多少少会出现Bug和需求问题，那么我们要在哪里修改这些问题呢？迭代1还是产品1？当时我们在讨论的时候，一部分倒向了迭代1，一部分倒向了产品1，当然，从为了更好的维护版本，控制版本可用的角度，我们需要在产品1上做修改。在产品1上修改完成之后，产品1就不存在客户提出的问题了，但是我们的主线程序Main上还是有问题，因此，我们需要将产品1合并到Main上。

    在完成了第一次迭代，就要进行第二次第三次迭代，同样也会产生更多版本，那么，在我们的TFS上就成了这个样子：

 　　

　　随着我们不断的迭代，Main会不断变更，但是我们需要保证Main永远是正确的代码。我们的签入签出在迭代上进行，迭代完成，合并到Main上。在合并之前，我们要把Main先签出到迭代上，这样做的好处是，将错误带到迭代上进行修改，完全没有Bug之后回归到Main上，这样做的好处是永远保证Main的正确性。

　　这是我们开发部分，那么我们的测试在做什么呢？在VS2012里有一个工具叫“测试中心”，这个工具可以帮助测试人员快速的完成测试用例，通过我们的TFS平台快速的提交Bug并及时查看程序员反馈的修复Bug情况。

　　由于这个本本不是开发本，所以没有环境，给大家带来不便了。有时间的话我会把图补上或重开一篇。这里面的东西很多，需要大家多多去研究！这里是关于程序员在VS端需要做的工作，关于测试人员的工作我会用新一篇去详细的说明。