PMP^®培训考试中心
中国国际人才交流基金会
授权指定PMP^®考试及PMP^®培训机构

4000-913-513

架构风险主要是指团队选择的架构能否满足当前项目的要求，没有哪种生命周期可以完全应对产品架构相关的风险。在架构代码开发完成并收集完毕之前，无法断言设计的架构能否正常发挥作用。

有很多选择顺序式生命周期的项目团队，他们觉得顺序式的生命周期可以控制架构上的风险，但是在瀑布生命周期中，最终的集成和测试是最后发生的，瀑布式和阶段-关卡流程对于架构风险的控制是最差的。

如果项目经理必须使用顺序式生命周期，又想早些发现架构风险，可以采取下面这些方法。

• 对于接近“完成”的原型，要尽早在项目中对其展开迭代，包括对这些原型进行测试。如果采用的都是“快而脏”的原型（就像在螺旋式生命周期中采纳的方式），那就很难发现架构的性能或可靠性是否可以满足实际要求。

• 尽早实现几个可以考验架构承受能力的功能。从实现这些功能的过程中，看看能否催生架构的新想法。同时要注意功能团队遇到了哪些风险，这有助于项目经理判断是否需要选择另一种生命周期。

假定项目经理为了检验推荐架构的可行性，选择用三周的时间来实现四个功能。三个星期过后，团队发现这个架构只对两个功能的实现很有帮助。对于自己在三周的迭代所能完成的工作量，他们的估算是不准确的。

项目经理可以继续使用有时间盒限制的迭代来完成剩下的工作，或者选用不同的架构来重复这三周时间要要完成的工作，看不同的架构能否控制开发风险或提升开发效率。

在顺序式生命周期的早期，要多做实验（即使这种生命周期不需要实验过程），这样在项目后期遇到架构或设计风险的可能性就越小。

• 用时间盒来限制整个架构相关的工作。让架构师和开发人员开发出至少三种不同的架构选择，他们还要告诉项目经理每种架构的长处和风险所在。

要想完整掌控架构风险，只有基于它实现某些功能并进行测试，项目经理所在的组织，或者存在出资人、资深管理层或PMO想在项目启动之前先看看架构的情况，或者存在如果不进行架构复查可能带来很大风险的情况。

在这种情况下，项目经理最好还是要完整的完成一些功能的原型化设计，这样多少可以获得一些经验，有助于判断能否放心的在项目中使用这个架构。