在任务关键型系统开发中应用敏捷的5大技巧

IT民工

任务关键型系统和敏捷开发

任务关键型系统对人类安全具有重要的影响。这些系统的故障成本可能非常高，不仅会导致财务损失，还会造成伤害或死亡。针对他们严格和复杂的开发而应用和调整敏捷方法，有助于预防故障，改善质量，提供更可预测的成果，以及减少上市时间和成本。以下 5 大技巧可用于将敏捷性应用于任务关键型系统开发中。

技巧 1: 敏捷治理

敏捷治理在于通过避免常常纠缠着传统开发工作的不必要的阻碍，让一个环境中的开发团队可满足他们的目标。它的理念是，您和您的团队确定目标并将如何满足它们。但是，最重要的步骤是，首先真正制定决策来管理项目。然后，您需要理解您将衡量的对象、您将如何衡量它，以及您将如何应对这些衡量结果。
许多人管理着错误的事情，即那些容易衡量的事。敏捷并不在于容易；它在于做出了对于取得成功和避免失败有意义的事情。您需要决定与您的成功定义相关联的关键绩效指标 (KPI)，然后不断使用它们监控质量和完成进度。一个 KPI 可能是项目速度，它不仅表示您在时间上完成了多少工作，还表示这些工作具有多高的价值。拥有 KPI 后，您就可以使用它们驾驭项目。因此，进度的透明性和可视性至关重要。

技巧 2：动态规划

敏捷是一种严格、井然有序的系统和软件开发方法。作为一种瀑布式方法，这需要进行规划。但是区别在于，对于敏捷来说，规划是动态的。
主要前提是 1) 规划必须基于改善的项目知识而不断调整，2) 您的计划只能跟您当前拥有的信息深度一样详细。敏捷治理提供了 “现场的真相”，您应该准备至少在每次迭代后进行调整，但常常会每星期或者甚至每天进行调整。您在工作的过程中将了解更多信息，而且该信息应该反馈回您的计划。
我还建议采取一种两级的动态规划方法。第一级是一个总体规划，主要基于为 4 至 6 星期所计划的一组迭代，每次迭代包含构建版本和在该构建版本上的直接测试。第二级是用于每个迭代的更详细的规划，或者这个月到一个半月内的进展情况的描述。在每个迭代结束时，您回顾已完成的工作并将其与计划进行对比。如果存在差异（也就是说，如果结果与计划没有准确匹配），那么返回调整计划以反映事实。


技巧 3：测试驱动的开发

从完成的软件中消除缺陷需要大量的工作，可能需要很高成本。事实上，研究已经表明，60% 的软件开发工作通常都花在测试和消除缺陷上。最好一开始就避免在产品中引入缺陷。为此，可以采用测试驱动的开发。采用测试驱动的开发，您可以不断地对软件进行编写和测试。您使用 20 - 60 分钟的微型周期，而且使用微型周期的一半时间来编写代码，另一半时间用于执行测试，以证明它有效。您所实施的项目类型决定了您的微型周期。例如，在我曾经研究的一个航天器项目中，微型周期平均时长为 20 分钟。结果得到的是质量高得多且缺陷少得多的代码，减少了在项目结束时测试项目的成本。
另一个敏捷最佳实践是使用持续集成 将团队的工作集中起来，通过使用所有组件的功能流证明集成的正确性。持续集成通常在整个项目上每日执行一次，但一些组织每星期执行一次。一般而言，您发现缺陷或集成问题越早，解决它们的成本就越低、工作就越轻松。在项目结束时，将没有出现任何集成问题，这些都是传统软件开发方法将分开开发的软件各部分集成 时经常会出现的问题。所以，缺陷的避免总比（事后）缺陷修复更好。

技巧 4：增量式开发

任务关键型系统的项目在本质上是困难和复杂的。因此，执行这些项目的最佳方式与我们解决所遇到的大项目时所采用的方式相同：将它们分解为更小的部分。将您的系统构建为一系列迭代（“冲刺”），每个迭代持续 4 - 6 星期。
每个迭代应该有一个任务陈述。目的在于履行其任务，它的任务主要专注于要实现的需求（通常通过用户案例或使用案例来采集），但也包括要支持的平台、要包含的架构概念、要缓解的风险和要修复的现有缺陷。验证和校验测试在每次迭代结束时执行。
对于我的项目，我们还在每个迭代结束时有一个 “聚会阶段”。一些人将此称为事后检查，但我将它作为对持续成功的庆功会，而不是确定故障问题的事后分析。我会查看任务陈述，确定我们满足该陈述的程度，寻找改善该流程的方式。我们总是会问我们还能如何做得更好、更快、更有效？

技巧 5：动态风险管理

风险是您在一个项目中不知道的所有事物。在我参与的 300 多个项目的经验中，忽略风险是任务关键型系统项目故障的首要原因。许多组织很少执行任何类型的风险规划，而曾经创建过风险计划的组织，从来没有回头查看它。这是针对灾难的一个处方。您在构建任务关键型系统时，必须关注风险。因此，您应该使用动态风险管理计划（也称为风险列表）来管理风险并频繁地更新它。
在风险列表或风险计划中，您会发现风险是一个两个值的函数，即您想要避免的成果的严重性和发生这一成果的几率。这两个值（严重性和几率）是对您可能跟踪的风险的定量测量。然后您再执行风险缓解活动，也称为 “spike”，这是一些减少风险的计划活动。因为不是所有风险都足够严重或能保证赢得特殊关注，风险缓解活动仅为超过一个阈值级别的风险而创建。当风险足够高时，就会规划一个风险缓解活动，它会变成一个计划的活动。

结束语

当恰当应用于任务关键型任务的开发时，敏捷方法可帮助避免高成本的故障。敏捷方法还可以提高这些系统的品质，减少应用它们所需的工作。敏捷方法将注意力放在风险上，如果忽略了风险，它们会成为故障的首要原因；敏捷方法还消除了同样会导致故障的静态、冲击式规划。尽管工具不像方法那么重要，但 IBM Rational 软件工具（比如 Rational Team Concert、Rational DOORS、Rational Rhapsody、Rational Quality Manager 等）以及 Jazz 有助于带来减少易于出错的流程，并改进规划所需的自动化和透明性。结合敏捷最佳实践，比如 Harmony 流程中的最佳实践，您会获得一个必将取得成功的开发组合。




上一篇：中国敏捷实践中的误区
下一篇：敏捷开发正走向成熟

ReerieBog

啥也不说了，楼主就是给力！

foheydwo

不错 支持一个了

贺扮昌孚

膜拜神贴，后面的请保持队形~

静夜漫思

很有见地的探讨，先收藏着~

眼睛爱哭

有空一起交流一下。

空壳子

很有借鉴意义，先收藏了，谢谢楼主。

骨z1里的傲慢

路过的帮顶

扬子居

有空一起交流一下。

醉爱i

看了LZ的帖子，我只想说一句很好很强大！

寂寞、变堕落

路过 帮顶 嘿嘿

玉米小王子

我是个凑数的。。。

微亮的光芒

学习下我只是路过，不发表意见……

一路向前

支持，赞一个

试着让自己坚强

很有见地的探讨，先收藏着~