结合工具来实现敏捷开发 - 12

好了，计划会也开完了，Sprint也建好了也规定好时间了，这个Sprint要做的功能点也分配下来了，该是开发同志们干活的时刻了。

 

分完任务后，每个开发同志登录到DevTrack以后，都会在Story Board里看到自己需要做的任务，一般情况下该任务状态为“开发中”，然后的话，就和大家平常做的事情就一样了：写Code，当然也许你还需要通过任务链接的需求信息和设计文档来研究一把。

 

写Code的事情就不必写了，直接进入写完Code以后的事情吧。写完Code后呢，首先需要让其他人来进行一下Code Review，完了以后呢，先是Commit Code，在Commit的时候，有一个窗口会自动弹起，让你把改的这些代码跟相关的DevTrack任务做绑定，这样子你就可以在DevTrack的任务里看到相关联的代码信息。

 

代码提交完成后呢，如果这个任务是完成了，就在DevTrack里把任务打到“可以测试”状态，这样子测试人员就可以开始测试了，当然你还需要把花费时间和剩余时间两个字段更新一下，并且把实际完成时间那个字段也更新；如果今天只是完成一部分，那么不需要改任务状态了，只需更新一下花费时间与剩余时间就行了，明天继续。

 

开发工作完成了以后，剩下的就是测试的事情了，在敏捷开发中，一个Sprint里，需要开发和测试都参与，所以当一个Sprint结束的时候，也就意味着测试已经完成测试工作，这个Sprint里的所有需要做的功能就可以用了（当然，有些功能可能由于某些原因会被推迟到下个Sprint中完成）。

 

其实很理想的情况就是，在一个Sprint里，开发做完，测试马上测完，开发再修Bug，然后测试再Confirm Bug的修复情况，这样子把一个Sprint完成，不过这种情况只能在项目很小的时候能达到，很多时候不一定会这样顺利，比如说Sprint其实时间已经定了，但是开发在最后一天做完几个功能，测试人员要测的话，肯定在这个Sprint中来不及，又不可能去延长这个Sprint，所以在这种情况下，我们就以开发任务完成来作为Sprint完成的参考，Sprint一完成直接下一个Sprint的开发，而测试任务的话，基本上会比开发任务慢一个Sprint，也就是说，比如这个礼拜开发应该是在做Sprint 2的任务，那么，测试的话，其实是在测Sprint 1里已经做好的任务。那可能有人要问了，测Sprint 1的时候，万一发现了Bug，开发是修还是不修呢？答案是需要修！我们每个Sprint就是需要产生能工作的产品，有Bug的话，我们认为是不能工作的，那就相当于没完成这个Sprint，也就无法实现所谓的迭代的增量了，增的不是量，而是Bug了。所以，开发在做一个Sprint时，其实是有三个活的，一个是做功能，第二个是修这个Sprint里功能产生的Bug，第三个就是修上个Sprint里产生的Bug。所以在这种情况下，如果从功能完成角度上来评估一个Sprint的完成的话，其实应该每次都是评估前一个Sprint，而不是刚刚完成这个。

 

针对Sprint的完成，我想每个公司根据开发量和测试量的大小应该都会有所区别，但是有一点是肯定一样的，就是每个Sprint都一定得出来一个能工作的产品，都得有实际的增量。现在很多公司，虽然名义上说用Scrum的，但是经常这个Sprint拖几个功能没完成，那个Sprint拖几个Bug不修，到项目结束的时候什么情况呢?

第一，             大家都对这个产品实际情况不知道，因为好像功能都做了，但是有很多严重Bug没修；

第二，             对产品的质量没有底，因为很多该早点修的Bug没修，在后面修的话，就不知道会不会影响其他功能，我们知道一个Bug如果在初期一直不修的话，到后期修复它的成本会越来越高，因为初期产品是稳定的，也许没多少功能，你修一个Bug不会影响其他功能，但是到后期功能越来越多，如果这个Bug所在功能跟其他功能有很多关联的话，你修这个Bug就非常有可能影响到其他功能，这样子测试上投入的时间和成本就会非常大，也许是初期的几倍。

所以，我们是建议每个Sprint的功能和Bug修复一定不能拖得太久，最多能拖一个Sprint，绝对不能拖到最后的时候才回过头来弄完，不然的话就不是敏捷了，因为后期投入太多测试力量和Bug修复力量，跟瀑布模型就没啥区别了。