直到实施了任务执行管理工具DevTrack，Smart先生才逐渐认识到由DevSpec引导的“功能驱动开发”是如何实现的。DevPlan中的迭代计划、DevTest中的测试任务和DevTrack中的开发任务，都是围绕DevSpec中的功能展开的。这不仅使整个敏捷过程都严格围绕最终产品进行，而且其中的可追溯性和可核查性，也正是敏捷开发思想的有益补充。
现在，当项目成员在会议室和用户讨论得热火朝天的时候，Smart先生可以悠闲地在电脑前喝咖啡了，他知道整个过程都是可以控制的，需求和设计变化再多再大，经历再多的迭代和小型发布，只要所有功能都按照计划被开发和测试，项目还是会如期完成。
敏捷团队的成功案例总结
毫无疑问，DevAgile团队最终用敏捷开发方式取得了项目成功。让我们再来总结一下，他们是如何具体做到的呢？首先，需求被搜集和整理，产品功能和简单设计产生，将这些结构框架和相关文档存入DevSpec之后，开始制定迭代计划，并定义模块接口。紧跟着，针对接口做出测试代码。这些知识文档全由DevSpec来管理，因此DevSpec中形成了由需求、功能和知识文档组成的“概念产品”。
最后，功能点被导入DevTest而产生一个或多个测试任务，每一个测试任务都能按照DevTrack中定义的工作流（图2）进行。
图2的工作流被启动之后，编码人员在第一状态负责编写代码、重构和白盒测试。项目经理为了实现配对检入，把第二状态设为需有A和B两人一起检入的“配对检入”。每一个状态都有明确的负责人。A可以是第一状态负责人，而与A配对的人员则可以是跟A 所做的任务有关的人员。第三状态负责人可以是测试人员，在单元测试成功后便完成了整个流程。反之，则重新回到第一状态。
以上的案例中，对所提到的四个敏捷特点都有所注解。当然，这是一个可行的方案，而绝非唯一。
另外，面对面沟通也是个很好的敏捷操作，但是实际上却不易实现。客户或熟知商业逻辑的同事通常是无法长时间和开发设计人员在一起工作的。若一定要面对面，很可能会以高昂的费用为代价。更实际的方式是通过一定的沟通平台（如一些即时语音或视频通讯工具）来达到类似面对面的沟通。
无论采用何种方式，沟通后的结果都要能妥善地记录下来。知识的分类和历史的记录会使清晰度达到最高，进而使后来的一切活动，包括编码、测试、分析等，都变得容易。
除了以上所提到的工具，软件配置管理、单元测试、软件的基础架构管理等工具，都是决定敏捷开发项目是否能够取得成功的关键因素。
总的来说，工具的使用要能帮助敏捷团队达到下列几项目的:能针对迭代进行灵活的计划，能管理需求变更，能始终体现最终产品的框架，能将关键过程既用流程固化又随时可调整，能对需求和供能点排列优先级，能使各方沟通更加便利等等。只有这样，才能使敏捷方法真正受益于工具，而不是受工具所累。
此文章共有5页 上一页 1 2 3 4 5 下一页
文章来源：中国项目管理资源网
|
Leadge.com首页 > 知识库 
