软件项目的目标
在讨论这些最佳实践之前，先明确一下软件项目的目标，因为所有的最佳实践都是为实现项目目标服务的。Alistair Cockburn在他的著作《敏捷软件开发》中指出，软件项目的目标有两个，取得当前项目的成功并进行积累，为后续的项目做准备。
关于第一个目标，一个比较麻烦的事情就是如何定义成功。一般来说，大家认为在预算范围和进度计划之内交付客户想要的产品，项目就算是成功的。但这样的理解似乎过于初级。Dewys Lasdon曾指出，&ldquo 我们 的工作不是用限定的费用及时地给客户他想要的东西，而是给他从未梦想过的东西当他得到的时候，他意识到这就是他一直想要的东西。&rdquo如果你结合iPod取得的成功来看，就能很好地理解这段话的含义了。
关于第二个目标，主要有两层意思。第一层意思是&ldquo锻炼队伍&rdquo。在项目中，团队共同工作一段时间，进行了许多&ldquo战术配合&rdquo方面的练习，大家相互之间更有默契。对于个人来说，通过具体的开发实践，学习了不少新知识，也积累了经验。
第二层意思是为后续项目提供积累。后续项目可能是运维项目，也可能是产品的下一个版本，或其他项目。不少项目开发工作对于后续项目有重要意义，如项目文档和回归测试套件等。如果你曾接手过别人的项目，或者只是花时间读过别人的程序，就一定会对此深有感触。
顺便提一下，项目的第二个目标不一定是次要目标。对于某些领航项目或概念验证项目来说，为后续项目提供经验积累就是项目的首要目标，也是项目成功的衡量标准之一。
RUP
根据IBM的官方说法，&ldquoRational Unified Process是一个灵活的软件开发流程平台。借助它可配置的构架，RUP 使你能够只选择和部署项目的每个阶段需要的流程构件。RUP 平台以业界公认的软件工程最佳经验为核心，它包含配置 RUP 以满足项目特定需求的工具。从这种意义上说，RUP 是一个软件开发方法框架，以及一个公认的、灵活的、实用的流程平台，用于成功的软件项目。&rdquo RUP提出了六项最佳实践:
1. 迭代的开发软件
2. 需求 管理
3. 使用基于构件的体系结构
4. 可视化软件建模
5. 验证软件质量
6. 控制软件变更
让我们来看看其中的需求管理。一项调查(James Martin An Information Systems Manifesto，Prentice Hall，1984)表明56%的缺陷其实是在软件需求阶段被引入的。而这其中的50%是由于需求文档编写有问题、不明确、不清晰、不正确 导致 的。剩下的50%是由于需求的遗漏导致的。更重要的是，许多需求缺陷直到很晚才被发现。而缺陷发现得越晚，修复缺陷所需的代价就越大。所以在传统软件工程方法中，非常重视需求工作，甚至称这部分工作为需求工程。
需求工程的主要出发点是减少需求中的缺陷，从而降低项目风险。Joel Spolsky 指出:“首先，没有编写规格说明是软件项目中你所承担的一个最大的、不必要的风险。”特别是在外包项目中，绝大多数客户都不会同意没有需求规格说明书的开发方式，因为这样做风险太大，实在不值得冒这个险。
需求工程的另一项重要使命是发现机会，即发现创新的产品，为用户提供更多价值的机会。如果你草率对待需求工作，将丧失这种机会。例如，在我们进行业务流程分析时，应该适当 关注 企业流程再造，业务管理创新，实现更多客户价值的机会。只有这样，才能可能做出Dewys Lasdon所说的“客户从未梦想过的东西”。
需求工程中的一个重要方面是管理需求的可追踪性，即从项目的总体目标追踪到业务用例，再追踪到实现用例和具体需求，最后追踪到实现和测试的能力。如果忽视了这个方面，项目的开发可能会偏离方向。
我们在编写需求时，常常会用到一些文档模板，如需求规格说明书模板和用例模板。某些模板非常全面、细致，以至于某些部分我们初看上去甚至觉得可以忽略掉。但是当你打算忽略掉模板中的这些部分时，千万要小心，因为模板的主要作用之一就是降低遗漏需求的风险。
有一次一名项目经理打算在开发团队中引入用例模板，查找了一些资料之后，写了一个草稿让我复查一下。我发现他的模板中没有用例的使用频度，问他时他说，觉得没有太大作用就裁掉了。于是我告诉他，用例使用的频度对系统的设计和实现有很大的影响，这属于系统的非功能需求，不能省略。
如果你想进一步了解需求工程，推荐你读一下《掌握需求过程》这本书。
XP
在各种敏捷方法学中，极限编程(XP)是知名度最高的一种。XP的主要实践有:Sit Together(坐在一起)、Whole Team(完整团队)、Informative Workspace(信息化工作场所)、 Energized Work(精力充沛地工作)、Pair Programming(结对编程)、Stories(用户故事)、Weekly Cycle(每周开发循环)、Quarterly Cycle(每季度开发循环)、Slack(松弛计划)、Ten-Minute Build(10分钟构建)、Continuous Integration(持续集成)、Test-First Programming(测试优先编程)、Incremental Design(增量式设计)。除此之外，XP还有一些配套实践。
让 我们 来看看其中的持续集成。如果前期的工作做得很到位，需求错误的风险得到了有效控制，那么项目进入构建阶段之后的主要风险就是无法得到可以工作的软件。在我经历的一个项目中，在大年三十下午，项目小组还在努力，公司的大老板也来到了开发现场。但是不幸的是，直到最后一刻，我们也没能实现大老板的心愿，在过年以前拿出一个能工作的测试版本。
持续集成不仅仅是针对无法得到可以工作的软件这一风险。通过在持续集成过程中执行各种层次的自动化测试，各种自动化的代码分析工具，我们就可以清楚地认识项目当前的状态，并努力保证项目处于 健康 的状态。
例如，通过代码依赖关系检查，我们可以确保在MVC架构中View没有直接调用访问持久层数据，从而保证架构在实现过程中没有被破坏。“信任，但要检查”，这应该是我们对待项目团队的态度。如果我们知道目标，但不知道我们 目前 在哪里，这种情况就叫做“迷路”。由于对项目当前的状态没有正确的认识，项目成员会对项目的进度产生错误的观念。持续集成有效地控制了“迷路”的风险，使软件开发的进度变得更透明、更可预测。
另外，持续集成和自动化测试、自动化代码分析一起，为我们提供了适应变化、将软件修改得更好的机会。我们可以大胆地对代码进行重构、采用新的组件、实现新的功能，同时保证这些修改与系统的其他部分很好地集成。如果没有人愿意、没有人敢修改原有的代码，这个项目的生命周期也就差不多走到尽头了。保留不断改进的机会，这对每个项目都是很重要的，这也大大降低了运营维护的成本和风险。
CMMI
CMMI(Capability Maturity Model Integration)是针对产品开发和服务的一个过程改进 成熟度模型。它包含了一些最佳实践， 关注 开发和维护活动，覆盖从概念到交付和维护的完整产品生命周期。这些最佳实践按照关注的领域进行了分类，即所谓的“过程域”。
CMMI的过程域包括:项目计划(PP)、项目监督和控制(PMC)、供应商协议 管理 (SAM)、需求管理(REQM)、配置管理(CM)、过程和产品质量保证(PPQA)、度量和分析(M&A)、组织过程核心(OPF)、组织过程定义(OPD)、组织培训(OT)、集成供应商管理(ISM)、风险管理(RSKM)、集成项目管理(IPM)、集成团队(IT)、需求开发(RD)、技术解决方案(TS)、产品集成(PI)、验证(VER)、确认(VAL)、决策分析和解决方案(DAR)、集成组织环境(OEI)、组织过程绩效(OPP)、定量项目管理(QPM)、组织创新和实施(OID)、因果分析和解决方案(CAR)。
让我们来看看配置管理。任何严肃的商业开发都不能冒没有配置管理的风险，好的配置管理让我们能重复任何一个时间点的项目状态。在与一名项目经理的闲谈中笔者了解到，她对公司多年来实施CMMI的效果很不满意。我试着从积极的方面来引导她，问她觉得有什么方面进步很大吗?她说进步还是有的，感受最深的一点就是大家都习惯了使用版本控制系统。另一方面，我们仍然看到许多新参加软件开发工作的开发者，他们需要花一段时间才能熟悉版本控制的概念和操作。
如果与需求管理、变更控制和持续集成等其他最佳实践配合，配置管理将为项目成功提供更多的机会。
如果你持续关注配置管理这个过程域，你可能会看到许多使用cvs的开发者迁移到了Subversion上，也许还会看到Mozilla项目采用了Hg(http://www.selenic.com/mercurial/wiki/)，并给出了对配置管理工具的需求和选择的理由。Sun的Netbeans项目也迁移到了Hg，也给出了理由。如果你不关注这个过程域，你可能错过一些机会，给组织机构的发展带来一些风险。例如试图用微软的Visual Source Safe来管理大规模的项目，进行全球化开发。
融合
许多人都已经注意到将两大阵营的最佳实践进行融合的可能性。Jacobson提出只有敏捷是不够的，我们需要一种明智的(smart)软件开发方法。在一次演讲中，他用一个笑话解释是什么是明智:明智就是不要让自己受到伤害。我理解这就是在讲控制项目风险的问题。
Boem和Turner的著“Balancing Agility and Discipline”直接讨论了两种方法学的融合，并将结论导向了风险驱动的开发。Tom DeMarco和Timothy Lister的著作《与熊共舞》也是讨论风险问题。你甚至可以这样理解:项目管理过程就是一个风险管理的过程。
软件开发是一项风险事业。报告显示，即使放松条件，软件项目成功的比例也只有50%。更糟糕的是，这个数字没有变好的趋势。但我想指出的是，数字会欺骗。因为今天面对的是更复杂的系统开发，就像下棋，我们的对手在变得更强。对于一个职业棋手来说，他的胜率可能和业余棋手差不多，但他无疑更强大。也许项目成功的比例不会再提高，但我们的能力却在变得更强。
另一个强调得不多的方面是最佳实践所创造的机会。最佳实践为我们提供了许多得到更好解决方案的机会。换句话说，不仅提供了赢的机会，而且提供了赢得漂亮的机会。
冰冻三尺，非一日之寒。当你经过多年的学习、练习和持续改进，终于成为一名职业棋手时，你就能对复杂的棋局有更深刻的理解，在危险发生前二十步就将它化解，敏锐地发现漂亮的着法，取得重大的胜利。
风险和机会是所有最佳实践关注的东西。和下棋一样，你必须时时评估盘面上出现的风险和机会，并采取相应的战术手段。这些最佳实践就是为了有效地控制风险，并不要漏掉机会。如何让最佳实践服务于项目的目标，服务于组织机构的战略目标，这才是最重要的。最佳实践的意义在于它为你变得更强大指出了方向。
扫一扫
662
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
