基于DAD方法的IBM敏捷开发过程中的敏捷管理

　　在构建阶段 - 即核心敏捷所关注的高优先级产品Backlog的实现、测试、验收的过程 -这个阶段由多个迭代组成。每个迭代均有可以工作的产品交付，靠近最后的几个迭代交付的产品将是潜在可发布的。

　　图3. 构建阶段

　　既然我的流程定制与开发已经在RMC的平台中完成了，我就通过RMC的生成过程视图的给大家演示每个阶段的详细流程设计吧。例如我展开这个构建阶段部分即展开构建阶段流程图如下图：

　　图3. 构建阶段流程图

　　上图所示我们通过一个Iteration[1..n] 的图标元素来代表多个迭代过程，这个元素是可以被展开的，让我们点击这个图标展示迭代的内部流程图如下所示：

　　图3. 构建阶段迭代内部流程图

　　如上图所示，在一个核心构建迭代中，团队完成的有“迭代规划(Plan Iteration)，完成故事(Complete Story)，稳定构建(Stabilize)以及准备用户文档”的主要几个任务。同时，这个流程结构中，有个特别的任务是“持续性任务(ongoing tasks)”，它记录的是在项目过程当中，那些支持团队完成故事、稳定构建等一系列核心过程所需的“辅助、支持”工作，有管理、计划和各种报告的输出。在理解和分解“迭代规划(Plan Iteration)，完成故事(Complete Story)之前，我们先看看这个“持续性任务(ongoing tasks)”，它是如何通过“迭代管理(Manage Iteration)， 风险管理(Manage Risks)， 监控和管理测试(Monitor & Control Test)，变更管理RequestChange”几个部分工作来支撑团队的呢?

　　图3. 构建期迭代内持续性任务(OngoingTasks)过程图

　　迭代管理(Manage Iteration) – 发展团队其实也是迭代执行的一部分。提高团队成员之间的协作和新人的培养，以及如何更好的纳“团队建设”到项目开发的活动中来的努力，这正是迭代管理所考虑的范畴。所谓迭代管理是一个以目标驱动而不是随着迭代结束而结束的事务，这个过程我们实际上是项目内外都在坚持。

　　图3 展开RMC的任务节点图 ——持续性任务迭代管理(ManageIteration [Team Level])

　　迭代管理事务力主通过系统对项目进度、工作项剩余时间的监控，以及帮助团队去除“政治化、部门墙”等制约因素，而达到团队的迭代目标的。当团队落后于预期进度，系统报警，此时项目管理团队将需要帮助团队评估如何通过减少工作量而仍然可以满足迭代的目标。例如利益相关人，如产品负责人、团队负责人将在关键时候参与决策，审批项目范围变更、工作项延期、任务删减的计划和行为。总之，就是危机响应，帮助团队解决掉那些影响重要目标的关键问题和风险。

　　理想的迭代管理实现是由系统自动收集数据、自动度量并提交预警报告的。系统将通过事先定义的几个度量尺度或者度量矩阵，实时监控项目过程。当然，在不满足全自动化的条件下，也可以靠人工收集和处理，或两者兼而有之。

　　管理风险(ManageRisks)– 建立一个该项目的潜在风险的清单，在早期项目的迭代我们和团队坐在一起，讨论并创建之。并为了减小风险列表的大小且保持我们的关注力在高风险上，我们将类似的风险合并，且按照风险对项目产生影响、可能性由大到小的顺序排名风险清单。

　　量化风险管理建议的将风险根据整体风险的大小进行排序。要确定风险大小需要估计的以下信息：

　　风险的影响：计算如果在风险发生之时，对项目计划进行调整，因此对日程、人力资源、成本规划而产生了的偏差。

　　发生可能性：该风险将实际发生的概率(通常以百分比表示)

　　风险值：由“风险的影响” 乘以 “风险发生可能性”表示了风险的实际大小

　　明确了一句风险大小优先排序制定风险应变计划。典型的策略应遵循如下：

　　风险的缓解计划：即通过关键问题的解决，减少发生风险的影响和可能性。

　　风险的应急计划：即通过预留额外的时间、资源的B计划，以应对风险。

　　风险的回避计划：那就是重组项目，将风险的行为减到零，以消除风险。

　　在软件开发中，我们如此制定我们风险应对策略的:

　　为了减少产品X和Y不能被整合的风险，我们需要在初期就建立一个原型用以研究整合的难度及风险。设计一系列的测试点(在一个列表中列举)，以确保整合是成功的。

　　为了减少数据库A将不正常运作的风险，我们需要模拟目标软件在并发访问、压力的环境下访问数据库，可能需要虚拟出数据流，或者虚拟目标软件来满足在目标软件没有建成之前就要验收数据库的前提.

原文转自：http://www.ltesting.net