Smart先生认为,作为敏捷团队的项目经理,他应该从传统项目经理的“工头”身份中解脱出来,发挥他的领导力,去监控和协调开发过程。虽然项目经理还是必须定义和初始化项目,作项目计划,执行计划,监督并控制结果。
但是完成这些步骤的方式却是不同的。具体来说,敏捷项目的计划不再是详细的完整的项目实施步骤和资源分配,而更多的表现为一种迭代计划。在开发人员与客户或其他团队沟通的每一次迭代中,计划和资源分配随时可能被调整,以不断适应项目进展的需要。在DevPlan的帮助下,这种调整变得方向明确、清晰和有据可查。它将每一次迭代的框架确定下来,剩下的工作就是根据这个框架实施了。
角色3:测试管理的利器
有了DevPlan,测试计划和开发计划开始制定,项目在一种既有序又敏捷的机制下运有序地转着。为了实现“测试驱动开发”,DevAgile不可避免的遇到了测试管理的问题。他们注意到,需求管理工具DevSpec内的需求,可被直接导入测试管理工具TechExcel DevTest,并自动生成测试任务。所有测试任务可以遵照既定的工作流执行,保证测试工作的有序开展和管理,并在编码之前发现设计偏差。
另外,他们以往是用光盘来存储可执行版本,文件柜的每一个抽屉里都装满了光盘。在进行敏捷开发以后,光盘的数量更是与日俱增,要找某版本的光盘时,多半是很困难的。
DevTest能够保存和管理发布的软件版本,而且和DevSpec内的功能及缺陷文件夹相对应。也就是说,若在需求管理工具DevSpec内有个6.1功能文件夹,那么在测试管理工具DevTest中也有个相对应的6.1发布文件夹。这显然比用其他方式来存储软件版本更加科学和方便。
角色4:任务执行的利器
有了以上这些项目管理的利器之后,DevAgile团队的工作并非一帆风顺,因为新的问题又出现了:一些成员片面的认为敏捷开发是一种松散型开发模式,也就是不需要遵守固定的流程。这直接导致了很多开发任务的执行效果糟糕,有些任务被提出以后就失去了踪迹,就连Smart先生也难以追踪每一个任务的结果。
于是,DevAgile团队又引入了与DevSpec和DevTest可以集成的DevTrack。这是一个开发任务的跟踪管理工具,提供既固化又可灵活更改的流程,对每一个任务的生命周期进行严格管理。它保证该走的过程一定走过;该反馈的一定反馈;该提醒的一定提醒;若任务需被升级,那就一定会被自动升级。更令人兴奋的是,当任务完成之后,其结果会自动返回需求管理工具DevSpec或测试管理工具DevTest。Smart先生可以轻易地由DevSpec看到针对6.1版本发布的所有功能和开发任务是否全部做完,对发布的管理省时省事。
此文章共有5页 上一页 1 2 3 4 5 下一页
文章来源:中国项目管理资源网
|