接着上一篇的思路聊。既然我们可以把开发者社群看作一个整体，copy-paste别人的blog文章就是在违背DRY的精神，其实所谓"重造轮子"道理也是一样，既然别人都已经做了相同的事情，并且把它开源了，并且你看了它的代码以后，觉得做得不错，为什么还要自己费心去实现同样的功能呢？自己来实现能给你带来什么好处呢？

我可以列举一些我认为可能会让我们选择自己来做的理由:

1. 我比其他人更了解我们自己的需求。
2. 自己实现起来更容易，代码量更小，也更好用。
3. 我是做技术的，能够DIY，就DIY，这样更能体现我的价值。

这些理由有它的道理，但是我们有必要仔细掂量掂量:

1. 我比其他人更了解我们自己的需求。这是软件开发中很常见的一个误区，客户的需求难以把握，随着时间的推移，我们自己的技术层面的需求实际上也在不断变化，开源的框架往往经历了更多的考虑和验证，并且有一群热心的维护者帮你做bug-fix和升级，甚至我们自己就可以成为这群热心人中的一员。
2. 自己实现起来更容易，代码量更小，也更好用。一开始确实是这样的，开源的框架为了满足不同的需要，往往需要比我们自己写代码要更加复杂和冗余，但是自制框架意味着我们自己定义的接口规范，这个接口规范能不能够在整个项目周期保持稳定暂且不谈，就算接口实现的再简单，项目中其他人也需要时间去理解和消化，然后记住一个定义好的调用方式，今后新加入的工程师也需要学习这个接口规范。开源框架则做得更好，一方面在这个项目中积累和学习到的知识，可以直接用在其他采用同一框架的项目中，另一方面新加入的人如果有过该开源框架的开发经验，上手时间可以缩短。
3. 我是做技术的，能够DIY，就DIY，这样更能体现我的价值。我必须承认，我本人就亲身经历过这样的情况。在即将结束的这个项目中，我甚至自己DIY了一个简易的.NET报表引擎，为的是甩开Crystal Reports。一开始能够DIY报表引擎的想法让我兴奋得睡不着觉，最终前后花了3天很满意的完成了设计和开发，并交付报表开发人员重画报表。可是真正用了一段时间之后，基本的需求满足了，基本的可扩展性也具备，但是缺少可视化设计器、更灵活的公式、更丰富的报表元素，基本上就定型了，没有人有时间和精力再去维护它。

在很多开发团队，大家经常碰在一起讨论具体的技术和设计，这很有必要，有时也不可避免。但是也许Joel Spolsky说的对，软件设计很难，但是比设计软件更难的，是同整个team一起设计软件。做技术的，对于自己了解、掌握、做过、尝试过的东西，对于自己熟悉和信任的东西，多多少少有些偏袒，而对于新的、自己不了解、不熟悉的东西，则难免心存疑虑。这就难怪很多设计讨论会最终很难达成一致。这个时候，要么由技术上的最高权威直接拍板，定下来是什么就是什么，要么就分歧双方或多方各自陈述，然后由项目外部的实体进行独立仲裁。

我看好开源框架，尤其是那些经过考验广泛被采用的框架，因为相比自制框架，它们有着更大的优势。

PMO是什么？它可以是很多不同单词的组合，在这里，我要说的是Project Management Office。请原谅我的孤陋寡闻，PMO的概念其实在两年以前就已经是业界的buzzword了，而我直到最近才因为工作的原因接触到这个概念。

在这篇随笔里面，让我们初步的探讨一下，为什么我们需要PMO，或者说，PMO应该具备怎样的职能呢？

PMO可以说是随着IT产业的潮流应运而生的产物，最初的目的是节约成本，提高项目成功率，以及实施标准流程，以应对越来越多的项目管理任务。虽然它在节约成本和提升项目管理质量上目前还很难有一个可量化的指标，但是越来越多的公司和企事业单位在它们的IT部门设立集中的PMO，统管所有IT项目。

按照比较公认的说法，PMO的核心职能包括：

1- 定义并推行可重用的项目管理流程；

2- 集中控制项目进展和资源调配。

仔细想一想，也许我们有两种不同侧重点的PMO：一种是顾问型的，为项目经理提供培训、指导和最佳实践；另一种是集中式管理型，将项目经理集中到PMO，然后派往不同的项目，最终由PMO统一控制所有项目和资源。

我相信国内很多公司应该是更倾向于后者，一方面，项目管理或者说软件工程本来就是一门艺术，很难有一个定式，就算有再多的“最佳实践”，根据项目具体情况的不同，也很难保证它们就一定适用，现实中要找到真正管理经验丰富，可以向别人提供理论指导的人才，并非那么容易；另一方面，后者能够更加直接的体现出PMO存在的价值，不光是直接的具体的项目管理，也有利于确定不同项目的类型和轻重缓急，合理分配资源。

当然，如果一个PMO最终做成一个完全意义上的行政部门的话，它也不应该同公司的企业文化相冲突，它起到的作用也应该更多的体现在如何去将项目的失败和公司的亏损减到最低限度，如何提高公司的项目管理水平，而不是一味的、机械的通过所谓的“标准流程”处理项目的实际问题，或者仅仅是一个跟踪项目进度，通常以一种管理者的姿态去命令各个项目组的部门。它应该同公司的各个相关部门：如CIO、CAO和QAO，以及具体的项目组、公司财务和高层管理部门共同协作，促进公司各个项目的顺利实施。

一个比较常见的、直观的说法是，PMO需要保证所有其属下的PM具备管理当前项目的能力。而从长远来看，最理想的PMO能够给公司的IT部门带来持续不断的业绩提升。

先说到这，关于本话题，今后也许会有更多后续文章。同时欢迎大家参与讨论！

今天偶然在TheServerSide.com上发现一篇挺有意思的文章，大意是讲在软件开发项目中类似日构建这样的工作为什么重要，通过它我们要达到的目的是什么。虽然文章的背景是讲一个叫做BuildMonkey的东东，但是很大的篇幅实在是我们日常很容易忽略的问题。如果你在公司做项目经理或者负责配置管理，建议你看一看这篇文章，说不定会有启发。

原文见：

http://www.theserverside.com/articles/article.tss?l=BuildManagement

一个典型的J2EE项目通常应该使用哪一种开发流程呢？流行开发流程有很多种，应用比较广泛的有：瀑布式、迭代式、以及RUP (Rational Unified Process)。每一种都有其优点和不足，所以通常我们应该把它们结合起来而不是认定其中一个然后100%按着它的规范走。

首先来看看每一种大致是什么意思：

[瀑布式]

这种模式的流程强调在开始编码和测试之前完成所有的需求分析和设计，这种模式历史相当久远，也很成熟，甚至到了今天，这种模式还是被广泛的采用到绝大多数公司和项目中。采用这种模式开发的项目通常很大，并且需要较长时间交付。正因为如此，这些项目通常会有更多的风险：在业务需求不断变化的今天，如果待开发的系统不能及时反应出这些需求的变化，最终开发出来的产品可能已经不是客户真正需要的了。

[迭代式]

为了应对传统瀑布式的开发在处理需求变更上的不足，近些年出现了一种全新的极限编程的概念。极限编程（XP）的核心思想在于：从长远看，早期发现错误以及降低复杂度可以节约成本。极限编程强调我们将任务/系统细分为可以在较短周期解决的一个个子任务/模块，并且强调测试、代码质量和及早发现问题。通常，通过一个个短小的迭代周期，我们就可以获得一个个阶段性的进展，并且可以及时形成一个版本供用户参考，以便及时对用户可能的需求变更作出响应。

[RUP]

RUP的全称是Rational Unified Process，是一套定义得很完整的软件工程模型。它强调编码前的需求分析和设计，以及短迭代周期的开发和发布。它鼓励团队首先开发项目中风险最高的模块，用更多的时间发现和应对问题，当设计需要变化时，它也能够在一定程度上减轻一些重复工作。不过，因为RUP十分严谨，也比较具体，通常要完全跟着这个流程走也不是100%必要。

下面我们来看看实际上我们应该采取什么样的流程或者策略：

实际的J2EE项目中，RUP的应用呈逐年上升的趋势，不过也并非所有这些采用了RUP的项目也是完完全全RUP式的。我们可以考虑一种综合上面三种流程的优点的方式，根据具体的项目量体裁衣。需要对这几种的优点来一个总结：瀑布式由于比较成熟，通常很好的强调了先需求后设计再编码的重要性，也比较适合大公司先预算后执行的方式；极限编程强调测试先行和简单是美，这样有利于及早发现问题以及更好的应对变化；RUP强调的集中化的分析和设计也有其不可替代的优越性。

要做出一个结论性的答案并不容易，如果贵公司相对较大并且愿意支付一定的管理成本来推一套成熟且完整的开发流程并在公司内部所有项目或者是大多数项目严格执行，我想RUP应该是首选；如果贵公司希望有更大的灵活性，可以考虑一些折衷的方案，根据具体的项目，从上面三种流程提取有价值的部分，来确定具体的流程。

有人做了一个总结：一个J2EE项目组通常会有怎样的人员结构，或者说，一个J2EE项目通常需要怎样一组代表不同的工作性质及内容的角色。实际情况中，一个人可能同时承担多个不同的角色，一个角色也可以有很多不同的人来分担。这些角色包括：

• 项目经理
• 架构师
• 领域专家
• 美工
• 前端开发人员
• 后端开发人员
• 数据库设计师
• 数据库管理员
• 数据移植专员
• 系统管理员
• 测试人员

其中，项目经理负责安排和协调整个开发小组的任务和进度，向决策层和用户代表反馈项目进展和状态，以及负责保证项目组或者其成员所需的所有资源足够完成项目开发并及时到位；架构师负责项目的总体技术选择、系统设计和指定具体的技术标准和细节，通常也需要跟整个小组紧密协调；领域专家负责采集和分析用户需求，在整个项目开发过程中了解和确保产品能够符合最终用户的要求；美工设计用户界面；前端开发人员按照美工的蓝图增加具体的前端处理逻辑；后端开发人员实现具体的业务逻辑，通常包括持久层的操作；数据库设计师负责通过领域专家提供的需求设计数据库的表结构和表关系，如ER图；数据库管理员根据ER图生成实际的数据表，并对数据库进行维护，以及协助优化数据库和SQL查询语句性能等；数据移植专员负责编写移植脚本，帮助客户将原有系统数据导入新的系统；系统管理员负责维护开发工作中需要的所有开发、测试、产品环境，以及进行产品发布；测试人员负责测试，保证开发出来的产品满足需求文档并没有bug，测试人员应该具备一定的领域知识。

拿一个具体的项目组来说：

这是一个J2EE外包项目的开发组，共有人员30名，1个项目经理、2个领域专家、22个开发人员开发人员、1个数据库管理员、以及4个测试人员。由于设计部分是由甲方做好，项目组没有专职的架构师和数据库设计师。项目采用EJB+Struts的总体结构。

项目经理负责同甲方的项目经理确认任务安排和进度，以及协调项目组内部各成员的工作进展，并提供必要的行政和软硬件支持，同时执行项目经理的其他日常工作，如配置管理等。2个领域专家参与同甲方领域专家的沟通，确保拿到的需求文档和设计文档充足且合理，并参与SIT，确保最终的产品符合文档的需求。数据库管理员负责维护并同步甲方提供的数据库，同时协助开发人员优化SQL。测试人员负责在不同模块完成后进行功能测试以及最后的SIT。开发人员按照不同的模块分成5个组，每个组又进一步细分为1个后端开发人员和多个前端开发人员，后端开发人员同时是该组组长。所有组长统一向项目经理汇报。

由此可见，上面总结出的那个J2EE项目组成员角色清单还是相当有说服力。总体上，在这个项目组中，项目经理是其协调和沟通作用的单点，项目组的主体由开发人员构成（这不奇怪，本身就是要开发产品嘛），领域专家和数据库管理员主要还是配合开发人员的工作，而测试人员则除了一般意义上的测试和配合之外，因为相对独立于开发，也起到一定的对项目开发流程的监督作用。

J2EE这个东东（可以理解为一组规范）本身就强调角色分工，当这些分工不同的角色都尽心尽力做好自己的工作，文档齐备，并且各个不同的角色之间保持足够的沟通，加上确定的流程，面向企业的Java项目就会更倾向于朝着健康可控的方向发展。