基于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将不正常运作的风险，我们需要模拟目标软件在并发访问、压力的环境下访问数据库，可能需要虚拟出数据流，或者虚拟目标软件来满足在目标软件没有建成之前就要验收数据库的前提.
• 为了减少测试工具Z将无法有效地执行应用程序的回归测试的风险，我们将在即将到来的迭代中使用它。

风险评估实际上是一个持续的过程，而不是一个只发生在特定的时间的过程。至少，你应该在迭代或一个里程碑抵达时评估风险。重新聚焦迭代目标时重新评估风险，尤其是:

• 消除掉已经完全缓释、不在存在的风险
• 寻找、发现那些新近引入的风险
• 重新评估的风险值和重新排列的风险列表

如果可能的话，请每周都重新审视你的风险清单，看看他们都发生了什么变化。让最靠前的十大风险可以在整个项目过程中保持足够的曝光度、可见度，并坚持采取、执行风险应对的计划和行动。通常，你应该将风险状态评估报告附加到你的周报、月报（如果有）的简报中去。

监控和管理测试（Monitor& Control Test） -  既然是敏捷方法，为什么还需要监控和管理呢？我前面说过，在企业环境适当的纪律和度量是有帮助的。就如我们所看到的DAD方法中，构建迭代的质量管理和测试工作经由核心团队和独立测试团队负责，而且显然在不同时期（迭代、软件生命周期的不同阶段）均有不同的测试关注点。为了使得测试工作条理清晰、资源充分利用、团队目标的适时调整需要从全局测试的角度基于规划；为了在测试工作中赢得宝贵时间和准确的调整测试策略，我们需要对测试工作进行监控和管理。

 

测试工作量的监控 – 这个任务的重点是对于测试工作的进展状态、测试工作工作量、测试状态监控，以提高测试有效性为目的适时调整。应该评估你的工作是否是适当的质量，而且它是完全够用，且后续将利用它作为质量评价工作。如果可能的话，使用检查表，以验证质量和完整性是否足够好。

 

图3. 随时更新的测试进展状态报告

 

 

寻找积极的迹象，如发现缺陷的稳定，持续率，或随着时间的推移持续增加或减少的规律。寻找尖锐波峰和波谷的出现点，这表明测试团队可能会遇到的政治、过程、协作方面的压力，我们需要适时给出支持和问题的解决方案。

 

看看缺陷闭合的趋势。确定当下情况这里有没有测试关闭待验证不足的问题，或者开发修复问题不充分性的问题。量化和分析， 因为开发者标记缺陷为“不可再现（Notreproducible）”来关闭问题的趋势，和分析问题的严重程度。分析缺陷因为“代码按设计工作 （work as design）”被开发者关闭的数量和趋势等。请注意，在这些问题凸显的时候，关注是否因为过度的开发工作量、或者因为害怕审查他们的工作而采取的行动所致。您也应该分析的缺陷确认趋势，分析修复缺陷又再次引入新缺陷至后续版本中的问题。总而言之，从趋势分析可以得到发现团队工作效率降低、个别队员超负荷工作和藉此改善团队协同的机会。

 

测试覆盖范围监控 – 这个任务的重点是对于迭代、版本测试工作的覆盖范围、测试组织充分的监控；以及判断跨迭代的独立测试团队与迭代内团队自主测试的配合是否恰好充分，测试的增量计划是否满足了增量型开发持续增长的需求。

 

测试覆盖有功能点覆盖、也有配置和测试环境的覆盖，有效的了解测试的覆盖程度需要类如RQM（Rational Quality Manager）这样的工具，帮助设计测试覆盖规划，以及监控测试实际覆盖状况。

 

图3. 设计最佳的覆盖面和最高效的执行路径

 

将度量测试覆盖率的公式集成如工具，例如RQM，RTC，可以回答“测试完成了%多少？多少设计的测试案列还没有被测试过？多少需求和功能点还未和相应的计测试用例关联？”最为常用的测试覆盖度量矩阵是“单元测试的代码覆盖率”。.

任何有计划的测试任务至少基于描述过的一个测试覆盖策略。覆盖策略指导着测试者的测试用例设计。基于需求的测试覆盖率可能已足以产生测试完整性的量化评定了。例如，如果所有的性能测试的要求已被确定，然后所有测试执行的结构可以关联需求，则很可能得到性能测试要求的75％已被验证的结论。

类似的，如果基于代码的覆盖技术被应用。这种类型的测试覆盖率就可能足以说明系统的白盒测试覆盖率，这也是目前大多数企业和企业所认可的。

这两种测试覆盖的策略可能需要人为干预，而最佳的方式我认为是通过系统自动化抽取数据形成报告，尽量避免引入人为因素最为科学。

 

测试工作个人仪表 – 个人仪表盘首要的工作是让个人在工作中以最小的代价了解自己的工作进展、合理安排自己的工作。个人仪表盘的是以人为本、团队自我管理的初衷来设计的，将质量和测试监控的度量指标和个人仪表盘的视图规则联系起来，个人就能够更有纪律的完成自己的工作，配合团队和项目的整体进度。每个人也非常清楚自己工作对整体所产生的影响，了解自身的价值，帮助建立自我认同感。

图3. 测试者根据团队规则和个人意愿设计的个人仪表盘