DevTrack的主要用于开发完成功能点编码以及测试人员完成敏捷测试。当需求设计完成后，项目经理会通过DevSpec/DevPlan来分配开发任务给相应的开发人员，并且同时生成敏捷测试任务，而开发一旦完成功能以后，会在DevTrack中把相应的敏捷测试任务打到“可测试”状态，这样子，测试人员开始进行测试了，测试完了，把任务关掉，这个功能点算测试完成了，项目经理会通过检查测试任务是否已经关掉来判断这个功能是否已经完成。

　　由于之前测试人员已经把当前迭代周期中的功能点写成测试用例了，对于做好的功能点其实已经从理论上很了解了，所以测试起来“轻车熟路”了。测试总会发现Bug，但是Bug有严重和不严重之分，我们现在处理Bug的原则是，对于影响到这个功能让客户评估的Bug都必须在这个迭代周期和下个迭代周期中修复，这些Bug可能包括报错，功能彻底没法工作，也可能包括一些页面上的美观，因为我们的产品会定期给客户做评估，以让客户看看做完的功能是否符合他们的要求，所以对于做好的功能点起码需要能让客户能用起来，所以客户会直接用到的看到的地方需要优先处理掉。而对于其他普通的Bug，DevTrack会有专门的一个文件夹保存，这些Bug会在Release之前通过优先级来一一进行修复，有些实在优先级很低的或者暂时不能完成的可能会推迟到下个版本再做或者直接不修了，因为有时候修一个Bug可能会带来一些意想不到的问题，如果可修可不修的Bug，不需要冒影响产品质量的风险去修了。

　　不知道大家有没有注意到，上面说了Bug需要在这个迭代周期与下个迭代周期中修复，为什么不在这个迭代周期中修复呢，其实是这样的，因为测试总是在开发后面开始的，如果一个功能点在一个迭代周期的后期完成，从时间上可能测试无法在这个迭代中完成，但是迭代周期的时间又不是想改可以改的，所以这种情况下，我们会在下个迭代周期中把这个功能点测完。不过一般情况下，我们还是建议不要延迟到下个迭代周期中完成，因为一个迭代完成后，我们会给一个Build给客户做评估，如果有没测试完的功能，可能有一些潜在的影响客户使用的Bug，这样子对销售会产生不好的影响。所以，解决的方法是一个功能点开发完成必须马上让测试测，发现Bug马上修复，如果有功能点到了迭代末期才做好，则已经Check In代码确保没有严重Bug（主要是表明和这个功能基本的使用），没有Check In 代码的等到下一个迭代周期再Check In代码，测试也推迟到下个迭代中测试。

　　这样子，迭代周期一个个进行中，开发做了一个个的功能点，然后测试会把这些测完，在这个周期中，开发与测试的工作量都会在DevTrack中被记录，主要是花费时间与剩余时间，从而得到了产品未来的一个进度趋势图，也是所谓的燃尽图。

　　4、需求变更：

　　敏捷是欢迎变更的，客户有啥想法可以随时提出随时改进，我们公司的产品是定期给客户一个Build来进行评估的，所以客户经常会要求做一些更改，对于还没有测的功能点稍微好一点，因为只要改设计文档，但是对于已经做完或者正在做的，已经测完或者正在测的呢？答案当然是也得更改，做好的重做，测好的做完重测，对于瀑布模型来说，这个也许是难以想象的，但是对于敏捷来说，这个是家常便饭了。

　　在实际操作中，我们可能会用到一个DevSpec的功能，这个功能比较不错，所以我单独提出来说一下。有些时候，如果一个功能已经在测试了，如果突然有了改动，而这个改动也已经做完了，如何通知测试人员重新测一下呢？口头通知？Email？其实都可以，只是有些时候，改动太多，需要知会的人太多，或者改功能的人不知道要通知哪些人，那怎么办？DevSpec有个功能可以自动提醒跟这个功能点有关任何开发、测试人员，让他们知道他们做的事情有改变了。