l
Develop Iteratively
l
Manage Requirement
l
Use Component Architectures
l
Model Visually(UML)
l
Continuously Verify Quality
l
Manage Change
做为
RUP
工具和过程的基础，
best practices
的影响了业界至少有十年。但是，时过境迁，如今，软件开发已经成为一个关键的业务能力或者说是商业能力。因此也就越发的强调
business-driven development
。在这样的背景下，发布不久的
RUP7.0
当中对于
best practices
进行了重新阐述，代之以
key principles
，这样来适应日益发展的系统和软件开发。
那么让我们来看看
key principles
都有哪些：
l
Adapt The Process
l
Balance Competing Stakeholder Priorities
l
Collaborate Across Teams
l
Demonstrate Value Iteratively
l
Elevate Level Of Abstraction
l
Focus Continuously On Quality
那么每一项key principles都是什么含意呢？
Adapt The Process
：
项目应该有适当的过程，太大的过程和过于简化的过程都是不好的。要根据项目的活动、控制程度、大小、所处于的阶段、团队的分布等等一系列因素来进行过程剪裁以便采用合适的过程。
过多的过程有的时候并不是好事情，需要因地制宜，因为它意味着更多的文档、要同步更多的模型、更多正式的评审等等；对于一些小型的项目组，成员对技术非常熟悉，人员少而且都坐在一起工作，这时候往往考虑使用轻量化的过程，比如比较流行的敏捷过程。当然随着项目逐步增大，对于过程的纪律性要求也会逐步升高。另外，过程需要被持续的改进，并且还需要根据未知项的级别和多少来平衡计划与估计。
Balance Competing Stakeholder Priorities
：
我没有查到这个key principle的本源，不知平衡利益相关方的优先级是否也从咱们中国文化中的平衡哲学中（阴阳）有所借鉴。在项目中我们常常见到的就是业务需要与各个相关方可能发生的冲突，以及客户化的开发与软件资产复用所产生的矛盾。
另外，还需要不断的更新优先级列表，因为随着对项目理解的深入，这是一个动态的过程。
因此，要做好这个法则，进行有效的需求管理是基础。真正做好需求分析和管理才可以有效的识别和排列各个需求的优先级，平衡好业务和客户的需求。对于开发来讲就要有一定的技术内功作为基础，具有一定的架构和封装能力，管理好已有的软件资产，并充分了解其商业价值，以便在恰当的时间和地方进行复用，既照顾了客户需求又复用了已有资产降低了成本。
Collaborate Across Teams
：
这个法则主要是强调整个项目范围内的沟通、协作，要通过恰当的团队组织以及有效的合作大环境建立而产生协作的土壤。最终形成有战斗力的团队。
要实现良好的团队协作，需要激发团队成员的斗志，让大家都表现出自己的最佳状态。要建立起一个能够“自管理”的团队，要鼓励团队成员跨职责的协作；当然，要有一个有效的协作环境作为基础（比如工具平台、通讯平台、组织氛围），通过对工件和任务进行管理来加强协作、过程和质量。另外，不要忘记根本，项目是需要盈利的，这就需要将商业团队、软件团队、和执行团队进行有机的集成。
Demonstrate Value Iteratively
：
迭代仍然是一个关键问题，软件开发需要采用迭代的过程来更好的适应变更、得到反馈、加入新的条件、更早的降低风险并动态的调整所采用的软件过程。
迭代是一个老生常谈的问题，关键的不是形式而是内容，好的迭代需要明确进入和结束准则，应该增量的实现用户价值，并实时的收集反馈，根据项目各方的动态状况作出调整。那种仅仅将项目从形式上划分成几个阶段或者release的方式其实只是加入了检查点（checkpoint），并不是真正意义上的迭代。
Elevate Level Of Abstraction
：
提升抽象层次。如果说是技术的发展使我们提升了抽象层次，到不如说是复杂度的增加迫使我们不得不发展技术来提升抽象层次，以便解决复杂的开发设计问题。现在软件项目的复杂度越来越要求我们在早期能够形成一个稳定的架构，以之成为应对变更、复用、甚至是减少文档化工作的基础。一个好的架构必须是有弹性的、高质量的、易懂的、并且是复杂度可控的。另外一点就是一个架构应该在早期进行测试，而不是在实现后才去验证。
我们可以回首看看中间件、SOA等的发展，无不是在抽象层次上做了大量文章。对了，还有大家广泛使用的UML，例子举不胜举。
Focus Continuously On Quality
：
这一条非常像best practices里面的Continuously Verify Quality。作为迭代的软件过程来说，它可以提供更多的机会来度量和验证。
质量的保证是需要从两个方面努力，一个是过程质量，这就需要建立一个良好的，适用的过程；另一个是软件过程产物质量，这就需要尽早的持续的进行集成和测试。
posted on 2007-08-30 16:36
Robin's Programming World 阅读(932)
评论(0) 编辑 收藏 所属分类:
转载