准备再研究一下JIRA+CONFLUENCE

准备再研究一下JIRA+CONFLUENCE。以前说过这个组合的问题，不过现在再考虑应该更加充分的利用CONFLUENCE的功能。例如文档管理和风险管理是否也应该放在CONFLUENCE中。

因为JIRA和CONFLUENCE的灵活性、稳定性以及商业化实在是值得考虑的因素。另外最近JIRA也加入了一些转门针对敏捷开发的特性。

不过，其实不论是REDMINE或者JIRA+CONFLUENCE来讲，都仅仅是针对单个项目管理的工具。而我目前所面临的问题是需要进行项目群管理（Program Management）。如此说来，是否只能考虑昂贵的商业软件了呢？

项目管理软件选择陷入僵局！

项目管理软件的选择目前陷入僵局！

	Jira+Confluence	dotProject+PmWiki	Redmine+instiki
优势	灵活的ISSUE管理和自定义的过滤器	管理领域全面	功能适中
	基于登录的WIKI和完善的权限控制	内置讨论区	分项目的WIKI
	插件丰富	条目分类清楚（任务，时间，问题，风险，机构，部门，联系人）	插件丰富
劣势	没有分项目的WIKI	没有分项目的WIKI	instiki功能简单
	商业版，目前可以破解	缺乏自定义过滤器	任务分层必须使用插件实现，但是插件安装失败
	没有事件管理	插件少，缺少图表	插件安装困难，版本混乱

highlight出来的条目表示无法忍受的内容。

由此看来，目前只能选择jira组合，但是这个选择明显风险很大。

时间紧迫，该怎么选择呢？

其实，如果是独立的项目组的话，任何一款都可以。甚至xplanner和scrumworks等其他的软件也可以考虑。但是目前需要选择的是公司级别的系统，因此需要满足很多管理层的需求才可以。

成功安装jira & confluence

静下心来安装jira和confluence。今天一天的时间安装成功。剩下的就是进行配置了。

准备放弃redmine了

不得已只能放弃redmine了。

本来兴冲冲的在PMOSERVER上面安装了instantrails, redmine和instiki。也都能够正常运行了。问题是：

redmine的subtask插件怎么也安装不上！

今天一早终于查出：插件与redmine 0.8.4版本不兼容。作者自己也不知道怎么办！

唉，开源产品的问题啊。

这么看来，只能放弃redmine和instiki的组合了。

其他的组合是：

jira+confluence 或者 dotProject+PmWiki

dotProject + ~PmWiki

dotProject有两个问题一直非常困扰我：

# 我需要按照TaskType过滤查看任务，但是系统中似乎没有这样的功能。（我本来需要在TaskType区分是 功能、沟通、管理、缺陷等等）

# 系统的图表功能太有限了，之后甘特图。如果需要类似Buendown Chart的话，怎么办？

新公司的工作内容

到新公司一个多月了。作为项目办主任，头一个月的试用期主要完成了下面一些工作：

1. 工程部门和软件部门的项目现状的调研，其中包括多次参加各个项目的诊断会议，然后给出诊断报告。
2. 制定一个初步的软件开发项目管理过程指导书，同时给出相应的各种文档模板。
3. 制定项目办未来大约两年的工作内容规划，在规划中给出项目办的工作职责以及8个阶段的工作内容和预期效果。
4. 制定公司级别的项目管理团队绩效考核办法。
5. 另外的一个重要的任务，是老板吩咐了需要在公司建立项目管理信息系统。

关于项目管理信息系统，一开始想到的就是~VisualProject。但是最近几天听听老板的口风，看来在一开始还是不能立刻推荐给老板比较高端的商业软件。现在的策略是寻找低费用或者免费的产品，现在公司内部找一两个项目试运行。等到老板看到效果了之后，在酌情进行推荐。
关于PMIS (Project Management Information System)的选择，目前决定使用版本控制软件+项目管理系统+维基（作为门户）的组合。

• 版本控制软件选择了''Subversion''而不是目前公司通用的Visual Sourcesafe。


• 主要是考虑到为了以后能够更方便的配合项目管理系统。因为多数流行的低费用的项目管理系统都能够对Subversion或者CVS进行集成，而支持VSS的很少。


• 项目管理系统选择了''Redmine''而不是Jira或者dotProject。


• dotProject虽然功能非常强大，基于PHP部署方便，但是其定制能力有限，而且想要扩展的话也是源代码级别的。考虑到可能的功能的灵活性的要求，只能放弃了。（使用过程中发现~PHP5.3下面有无法解决的问题，总是显示错误提示，之后换用~PHP5.2.X，一切正常。好在基于WAMP进行试用，切换PHP的版本非常方便。）


• Jira其实是非常适合的产品。系统稳定，功能强大。可定制能力非常强！而且功能扩展也非常方便，有现成的N多插件可以选择，足以满足需要。而且可以和Confluence进行集成也很诱人。缺点是商业软件，破解繁琐。基于JAVA平台，因此试用时部署非常方便，但是在生产环境下的部署却比较麻烦。


• Redmine基于~RoR平台，部署非常方便。有插件机制因此也可以方便的进行扩展。Open Source所以实在不行也可以自己编写扩展。功能还算灵活，相比Jira配置简单，内置了WIKI和新闻发布。目前的问题是：功能不够复杂（呵呵，给老板看的时候需要更像一个庞大的系统），缺乏企业级的管理功能，不过通过插件应该可以弥补。性能如何目前还不肯定。


• 维基系统选择了''instiki''而不是~PmWIKI或者Confluence.




• Confluence应该是最适合企业应用的WIKI软件，况且能够和Jira完美配合。无奈是商业产品，破解困难。另外基于JAVA，生产环境下和Jira一同部署也比较麻烦。


• ~PmWIKI基于PHP系统，部署非常方便。另外自身功能也很不错，权限控制也比较灵活，能够应付企业应用。有非常丰富的插件可以选择，可扩展能力很强！


• instiki功能简洁，勉强满足需求。不过它也是基于~RoR平台的，因此在和Redmine同时部署的时候比较方便。

最近我就要在服务器上安装上述的系统了，因此后面会将安装过程和配置过程进行记录。

何时应该使用用例进行建模

当遇到下述情况时，用例是需求捕获的最好选择：

• 系统有功能性需求所主导。
• 系统具有很多类型的用户，系统对他们提供不同的功能（有很多参与者）。
• 系统具有很多接口（有很多参与者）。（我的理解：如果针对业务应用系统而言，意味着有很多操作界面。）

当遇到下述情况时，用例是一个糟糕的选择：

• 系统由非功能性需求所主导。
• 系统具有很少的用户。
• 系统具有很少的接口。（例如嵌入式系统或者算法复杂但接口很少的系统）

何时停止用例建模？

• 用例建模的基本原则是保持捕获到得信息量是必要的、最小的。这意味着，很多次要场景可能根本就没有说明——用例中的一行有关它们的描述可能让人足以理解系统的功能。

以上摘自《UML and the Unified Process: Practical Object-Oriented Analysis & Design》, Jim Arlow & Ila Neustadt

又被GFW恶心了

刚刚发现，picasaweb中的图片全部被GFW过滤掉了。

无语！

月盈则亏，水满则溢

上大学的时候，就曾经有一个同学和我说过：中国的腐败现象很难根治。

腐败现象不可怕，可怕的是老百姓们对待腐败的态度。

其实在你身边就有很多很多的各级政府腐败官员，但是你会发现身边老百姓们对待他们的态度并不是非常的痛恨这些腐败的官员，而是带着一种非常羡慕的心态。当教育孩子的时候经常会说：“你看，XXX家里的儿子当了官多好，家里面有很多钱。长大之后你也要当官啊。”

联想到软件开发项目，也会有一些类似之处。在项目当中犯了错误不可怕，关键在于如何认识这些错误和不足。当一个团队经历了长期的疯狂加班，项目管理一片混乱，然后提交了一个非常烂的成果之后，最可怕的是大多数人都认为这是非常正常的、软件开发项目就是这个特点。尤其是当这样的想法也来自于高层的领导的时候，这个团队就基本上无可救药了。

老板还经常抱有这样的想法：“我当初经历过N多XXX的项目，有很多很多大项目的经验，你们现在远不如我们当初艰苦与投入……”言外之意是项目做得不好是因为大家工作的还不够疯狂。客户的满意度来自于看到开发人员过度悲惨而产生的怜悯心态。

好像是的，老板们都经常会以以前做过很多更艰苦的项目而标榜，而不太思考这些艰苦是由什么原因而造成的。

今天下午的测试培训会议

下午突然听说老板找了一个IBM的专家来做测试的培训，于是应要求下楼听了听。
看见一个口齿不太清楚的人正在演示ppt。听了听内容，基本事实幼儿园级别的入门培训。从测试的一些基本概念到测试管理，简单讲了讲td的使用等等。
老板和测试人员们正在很崇拜的请教。
（下周就要进行UAT测试了，现在临时抱佛脚。）
中间讲到了目前应该怎么测试流程，专家建议仅仅找一个最主要的流程走通。（专家把物流系统当作简单的网上购物了。）
讲到目前测试人员太少，只有两个。专家说50多个开发人员起码需要有五六个测试人员嘛。现在需要将开发人员调入参与测试执行。（目前项目的状况，开发人员还都在满负荷地进行开发呢……五六个测试人员就够了吗？）
讲到测试人员目前介入得太晚了，不了解需求。专家说：这说明项目经理一开始就没有重视这件事情。现在需求人员应该没有什么事情了吧，也需要参与测试。（现在需求人员已经忙得不可开交了，天天在应对客户方面的各种各样的要求。项目刚刚立项的时候我就正式的和老板要求了：一定要在需求期间测试人员参与，一定要保证测试人员的数量和质量。结果呢？先后进入项目的6个测试人员迅速离职或者辞退了。然后老板说不要指望测试人员测试了，开发人员自己来吧。然后真正需要有经验的测试人员出具测试方案了，老板指派项目管理中心的专职SQA人员进行负责。）
讲到目前还有需求变更的情况出现，专家说项目经理对需求变更没有很好的进行控制。（专家知不知道项目组面对的是什么样的客户？）
可以看出，老板还是对测试一点概念也没有，进而发现老板对项目管理的内容实在是理解得太初级了。所以现在对这个山寨专家非常崇拜。
我私下问了问这个专家什么来历？据说：这位姓束的专家是IBM的高级项目管理顾问。原来也是联创的员工，是老板的老同事。而且据称也是位天才级人物。原来如彼。
总之，我晕！

面向对象设计背后的数据库设计（摘自"The Object Primer"）

1. 把对象映射到关系数据库

首先，类的属性将会映射成关系数据库中的0列或多列（最好使用相似的命名规范）。

对象的有些属性本身就是对象，它真实地反映了两个类之间的关联。

并非所有的属性都是持久的，有一些被用来进行临时计算。

2. 影子信息

影子信息（shadow information）是除了普通领域数据之外，对象需要维护的任何用于将它们自己持久化的数据。

一般如主键信息，特别是没有业务含义的代理主键。并发控制标记、时间戳、增量计数器。

3. 映射继承结构

将继承映射进关系数据库中，有3种主要的方法：

1. 把整个类层次映射到单张表中。
2. 把每个具体类映射成自己的表。
3. 把每个类映射成自己的表。

3种技术的对比

技术	优点	缺点
单表	方法简单 容易增加新的类：仅需要对额外的数据增加新列 通过简单改变行的类型来支持对象多态 数据访问是快速的，因为数据在一张表中 特殊报表是非常容易的，因为所有的数据都可以在一张表中找到	类层次的耦合增加了，因为所有的类都直接耦合到同一张表中。类中的变化可以影响表，这样就影响了层次结构中的其他的类以及他们的相关映射 数据库中潜在的空间资源的浪费，因为许多行将会是空行 当类型之间有严重的重叠式，表明类型变得复杂 对于大型层次结构，表增长得很快
每个具体类一张表	访问单张表中的数据时好的性能 生成特殊报表简单，因为一个类的所有数据都仅存处在一张表中	对类的修改需要我们修改他的表，及其任何子类的表。 无论何时对象改变了他的角色，就需要把数据拷贝到相应的表中。 支持多行信息，还要维护数据完整性，这很困难。
每个类一张表	映射简单，因为他是一对一的 容易支持对象多态，因为我们只在每种类型相应的表中有记录 修改父类和增加新子类非常容易，我们仅需要修改/增加一张表 数据大小的增长与对象数目的增长成正比	数据库中有多张表，每个类一张表（加上维护他们之间关系的表） 潜在的要花更多的阅读和读取数据的时间，因为我们需要访问多张表 特殊报表是困难的，除非我们增加视图来仿真待处理的表

4. 映射关系

对象模式中的关系是通过对象引用和操作的组合来实现的。而在RDB中，他们通过外键来维护。

映射关系的方式依赖于他的多重性：

1. 一对一关系

如果每个类都有一张表对应，那么这两张表之一需要实现一个外键。

第二种策略是简单的在单张表中存储两个类的数据。

2. 一对多关系

它的实现方式是在关系中多的那方面使用Hashset等集合，在一的这方面使用对象引用。

在数据库中，他是在关系中多的一方通过外键来实现。

3. 多对多关系

两个类之间的多对多的关系被映射成数据库内的关联表。

4. 迭代关系

也称为自反关系，它是指关系的两侧都是相同的实体。

我们可以使用非迭代关系相同的方式来映射它们。

功能驱动与用例驱动（关于用例、用户故事和特征的解释）

软件开发过程中，描述并分析需求会同时采用不同的角度和方式。例如功能分析和场景分析。

其中功能分析是指描述系统所应该具有的功能。场景分析是指在特定场景中用户的操作步骤以及系统给出的相应的反应。

功能分析文档所列出的清单一般会叫做“软件需求”或者“系统特征”。

场景分析文档所列出的内容一般就是“用例文档”

由此可见，RUP中所使用的用例驱动开发，XP中所使用的用户故事驱动开发以及特征驱动开发，表面上看起来是以其分割粒度的不同进行排列下来的。其实我们可以看出，用户故事和特征都是从功能分析的角度对系统的需求进行的描述。其与RUP所说的用例驱动完全使用了不同的分析方法。

这样我们就可以更好的理解XX驱动开发之间的区别在那里。

下面是功能驱动与用例驱动之间的对比表格：

功能驱动	用例驱动
当你有许多未密切相关的不同功能时，工作会进行得比较好。 让你可以较快想客户展示可运作的程序代码 是非常功能性驱动的。采用此方式，你不会忘记任何功能。 对具有许多未连接功能性片段的系统，进行的特别好。	当你的应用程序有许多流程与场景，而不是个别的功能性片段时，进行得比较好。 让你在每个开发阶段可以向客户展示较大的功能性片段。 是非常以用户为中心的。采用此方式，你将为用户使用此系统的所有方式编写程序代码。 对交易式系统（系统以冗长、复杂的流程定义而成），进行的特别好。

在实际需求分析的过程中，两种分析方式相辅相成，都有其独到的贡献，最好能够结合使用。

我理解，互联网类型的项目更适合功能驱动开发，而企业业务系统类型的项目更适合用例驱动的开发。

芜湖项目现场需求调研阶段总结

芜湖项目现场需求调研阶段，工作效率高，工作成果的质量也很好，现在总结如下：

1. 需求分析团队人员要尽量少，减少沟通成本。尽量只允许业务核心人员参与，这样能够以最快速度对业务流程进行确认。
   反观现在大平台的项目，需求分析阶段有30多个人参加，包括了国家局的人员和各省市的人员。分成了6个分析小组。诸多问题无法现场进行确认，因为参加的人多，因此大家都不作结论，只能会后通过EMAIL来回来去。由于分组很多，因此涉及到很多跨小组的问题进一步增加了沟通成本。
2. 需求讨论会议现场形成文档，由于文档形式上是共同创作完成，因此可以省略客户确认文档的过程。
   反观现在大平台的项目，会议之后，需求分析人员晚上加班形成需求访谈报告，需要客户确认，然后再形成需求规格说明书，再要求客户确认，这样效率非常差。
3. 关于需求分析的团队构成，建议如下：
   - 客户业务人员
   - 客户IT人员
   - 主力业务分析人员：主要负责需求分析工作，引导大家使用正确的方式和正确的方向进行需求分析工作。
   - 业务分析助理：主要使用合适的工具，现场进行文档撰写工作。也可以提出自己的建议。因此该人员也需要有一定的需求分析能力和文档撰写经验。
   - 项目助理：负责对会议中的各种未定事项以及决议进行跟踪，并且进行其他的一些辅助性工作。
   - 解决方案顾问团队：辅助角色，可以离线支持。主要对相关业务领域或者IT技术领域进行咨询工作。
   - 开发组组长以及主要设计人员
   - 系统实施负责人
4. 使用的工具建议如下：
   - 业务流程分析工具，以便团队成员能够在早期对业务流程有全貌的认识，如BPMN, EPC图等等
   - 快速互动原型工具，以便快速形成可以进行互动的动态系统原型，给客户良好的感受。推荐serena prototype composer或者axure rp等。
   - Sparx Enterprise architect，全面的项目模型管理，在此阶段主要使用到：用例分析，领域模型，需求条目管理等等。（在用例中需要填写senario条目，并且需要与需求条目进行关联）
   - Balsamiq Mockups，对操作页面进行设计。
5. 对目前的大平台，现在能想到的建议如下：
   - 分组尽量少，1~2各组，人员尽量少，减少沟通成本。
   - 现场形成文档。
   - 在早期需要有总体业务流程分析过程，然后在进入细节系统需求分析过程。
   - 使用上述的工具
   - 使用上述的团队组织结构
   

综上，发现上述经验并不太符合敏捷过程，反而与《人月神话》中的理论非常相似。起码，可以总结出来两点：1.架构（需求分析）是贵族专有的工作内容。2.需要组成外科手术型的团队结构。

芜湖出差，巡回取货项目的一些心得

五一之后到芜湖，客串巡回取货项目的项目经理，负责需求调研工作。整两周的时间，有如下一些心得体会：
出差两周，其中需求调研工作大约占用了6个工作日的时间。另外有2个工作日大约是各种各样的汇报。
工作进行的比较顺利。体验也很好，主要是可以按照自己比较推荐的方法来进行项目工作，大家都比较轻松，工作效率也很高。客户方也反映工作效率很高，工作很有成效。
开始的几天，使用serena prototype composer工具，项目组成员在同一个会议室中，主要讨论工作流程（与系统无关）。然后同样使用这个工具，讨论大致的系统操作流程，同时画出初步的系统界面。这个阶段成果效果非常好：大家对系统的总体概念已经形成，基本确认了系统范围。并且形成了可以进行互动的系统界面原型。
然后开始使用EA和Balsamiq Mockups配合进行用例分析与界面设计。在EA中复制了serena prototype composer中的工作流程，然后进行用例分析，在用例中进行场景senario步骤描述。针对每一个用例，至少使用Mockups软件绘制一张界面设计图。另外在EA中进行领域模型的设计。
综上，提供出一份真正对开发有帮助的需求文档。
经估算，这两周的需求分析工作定义出的系统需求大约需要5人团队开发3个月的时间的工作量。开起来也非常符合比例。当然这仅仅是估算的合理值，估计和客户方面进行协商之后，时间上又会变得非常不合理。

客户非常高兴的从我这里拿到了上述的三款设计工具。不过，真正重要的是需要会使用这些工具啊。

在出差期间，抽时间学习“Head First OOAD”，有如下收获：
终于对需求和用例明确的区分开了。需求大约总是以“系统应该可以xxx”这样的格式描述，主要描述系统所具有的功能和能力。用例侧重于描述某某场景senario下面的操作步骤。因此大约会是包括正常路径/可选路径/替代路径等等。

不过，在出差期间，本计划使用类似极限编程方式的增量开发，结果未遂。最终变成了类似ICONIX方式的过程。

另外，意外的发现，原公司上班时，结识的MOTO客户，现在正在作为甲方折磨着现在我的客户。现在我的客户天天折磨我们，同时他们也在被MOTO客户折磨着。……

软件开发过程DRY

依据RAILS框架所倡导的DRY (Don't Repeat Yourself)的思想，可以大大提高编程时的工作效率。如果能够由此推广开来，发现软件开发过程中有哪些工作内容是重复而浪费了，并能够有针对性的改善的话，是不是可以提高工作效率呢？
我们的现实情况是：需要满足客户以及老板和项目管理中心所谓正规软件工程所需要的标准过程，还有标准过程所要求的文档。所以，通常来讲，我们会按照这样的过程进行工作：

考虑以下一些方法：

1. 利用用例分析或者用户故事，来讲需求分析与需求传递和培训两个过程合并。
2. 考虑需求文档中的用例分析部分可以是主力需求分析人员带领开发团队共同完成。
3. 需求文档的工作量很大，并且变更之后的维护也是问题。因此考虑需求文档与测试用例进行结合，减少需求文档中的内容。
4. 使用某种形式的工具来自动生成规范格式的需求说明书。
5. 概要设计说明书中仅包含系统架构层面的设计工作。
6. 系统设计过程与测试案例编写过程融合（参考XP过程）。
7. 实用工具（例如javadoc）来自动由编码生成详细设计文档。
8. 现实存在详细设计过程，但是并不正规，仅仅产生一些中间产物文档，如界面草图、UML顺序图等等。

关于敏捷软件开发新的理解

前两天，在一次聊天中，我问了问未来开发组的组长：眼看设计过程就要结束了，项目启动到现在进行了3个月的时间，想一想，前一阶段我们所做的工作中，有百 分之多少是对后面的工作有意义的？开发组长无奈的苦笑了一下。显然大家心里面都有数，这个比例很不理想。尤其是设计文档中的模块设计部分，大量的工作量， 完全是为了设计文档能够评审通过。

对于敏捷软件开发，目前理解期最重要的目的是识别软件过程中没有必要的任务或者是性能低下的任务，然后去除之或者改进之。基于这个出发点回顾一下目前的情况：

1. 需求分析。唯一不变的就是变化。项目的早期集中时间进行需求分析然后确认基线，再等到真正动手开发某一模块的时候可能已经过去了一段时间，并且需求已经发生了变化。这样还需要对新的需求进行再次分析。在这样的情况下，前后的需求分析则存在工作量的浪费。
   1. 敏捷过程则是需求分析存在与整个项目的始终。细节的需求分析工作尽在真正开始代码之前才进行。虽然以后仍然有可能发生变化，但起码针对上面的情况做了优化。
2. 软件设计。目前的项目，设计阶段需要的交付物有：架构设计，概要设计，详细设计，物理模型设计，接口设计等等。设计的目的当然是为了能够知道开发。这一部分工作显然是必须的，但是能否优化呢？敏捷过程典型的对策是1.仅仅做足够的设计；2.测试驱动开发。
   1. 系统的架构设计是需要的。但是针对某一功能来讲，仅仅在开发之前才做相应的详细设计。设计仅仅做到能够指导开发的程度，对文档的格式要求比较宽松。
   2. 传 统的UML设计包括类图、顺序图、协作图、活动图、状态图等等。这个敏捷过程一般没有强制要求。XP过程中推荐以TDD和CRC分析来代替。其中CRC分 析基本上是UML协作图的替代物，但是更加强调团队共同完成。而TDD则是在保证了测试自动化的同时还能够对软件设计进行指导，做一件事达到两个效果，体 现其高效率。
3. 界面原型。我前面说过，希望能够在需求分析阶段就能够对系统的界面进行确认，还找了一些专业做页面原 型的辅助工具。现在看来，其实也存在浪费。其实更高效的做法是以最快的速度拿出开发出的成品或者半成品让用户进行确认（这样一来，唯一的问题是你能有多 快？;-) ）。界面草图有的时候是需要的，但是它变成了非常不正式的中间产物，不必要进行存档。
4. 重构。仔细想想，其实重构的工作对于任何一个项目来讲都是必须的。而现实是，如果没有采取全面的自动化测试的话，传统的软件开发项目没有能力也不敢进行深度的重构。而相反基于TDD的XP团队则更有勇气对软件进行彻底重构。
5. 集成。集成的工作量无法节省。敏捷过程的做法是持续集成——将工作量分散到整个软件生命周期。这样能够及时发现问题，并从感受上减少工作量。

我有一个朋友，看他上网打桥牌的时候，经常发现他的搭档在抱怨他发生了失误。而实际的情况是怎么样的呢？我的朋友是全国顶级桥牌赛事的前四名获得者。那些被抱怨失误的牌都是由于他的搭档的水平不够，对于他的精妙招数无法理解。
在软件开发领域，其实我们也正在处于我的朋友的搭档的水平。经历的项目越多，越会发现业内大师的很多理论的精妙之处。很多情况是：如果大师们的理论你认为有很大问题的话，其实是因为你的层次还不够。

现实很残酷

现在手头是这样的一个项目：

1. 为期7个月
2. 工作量分析的结果，项目团队需要60个人或者更多
3. 项目组中只有包括我在内的3个人有相关行业经验
4. 开发团队中有大约20多个人是刚刚招聘到位的
5. 对于所使用的技术，除了JAVA开发之外，JAVA开发框架、BPM/BRM引擎、B2B网管、字符终端开发等等都是项目组第一次使用
6. 项目组中几乎没有人有面向对象的设计和开发经验
7. 客户方面政治斗争严重

这是我所经历过的第二个死亡之旅项目。

考虑使用UberNote代替Google Notebook

刚刚发现一款新的Web应用：Ubernote

• 展现方式同Google Notebook非常相似
• 采用了不分层的Tag方式进行管理
• 可以对Note进行所见即所得的富文本编辑
• 可以多人合作共享Note
• 有浏览器插件，可以直接抓取网页。而且插件很丰富：Toolbar, Clip, Bookmark, Snap
• 居然能够直接从Atom导入现有的Google Notebook内容。
• 缺点是对于每一个Note不能折叠显示。
  

所以真的可以考虑切换过去？

另一个可选的替代方案是：TiddlyWiki + Clipmarks，只是Clipmarks的速度比较慢。

Google Notebook的备选替代品

Google Notebook停止开发了。虽然现在还能够使用，但是还是需要准备一些备选产品了。另外，Google Notebook的功能一切都好，唯一的问题是，不能存储网页篇幅很大的文章。
替代品列表：

1. Office OneNote 2007：非常好的产品，文字编辑非常灵活方便，支持表格。分类清晰，功能强大，能够直接抓取网页。不能支持在线同步，但是只需要配合Dropbox就可以完美解决。唯一的问题是商业产品，需要收费。另外只能基于Windows平台。
2. Evernote：也是业界很出名的产品。Tag方式的管理，支持全文搜索，能够直接抓取网页。有在线同步功能，同时还有桌面客户端。
   缺点是：体积庞大，免费版本每月有数据量的限制。并且不支持表格，编辑功能稍弱，不够灵活。
3. TiddlyWiki：体积小巧，功能灵活。基于Tag方式管理，可以安装第三方插件。开源。支持UBB方式的自定义格式，非常方便。配合Dropbox可以实现在线同步。单一的HTML文件，所以跨平台。
   缺点是：不支持直接抓取网页。

现在看，TiddlyWiki的方式很好。所以正在寻找能够直接抓取网页并能够在线同步的工具进行配合使用。

对面向对象以及极限编程新的理解

传统的面向过程的开发是自顶向下逐步细化的过程。这是非常符合人们习惯的思维方式的。所以自然由需求分析->概要设计->详细设计->编码->测试->发布的瀑布模式成为了最规范的软件过程。
而面向对象的开发是自底向上的过程。在这样的过程中，往往是先实现已经了解的局部。逐渐的随着过程的推进，系统的全貌浮出水面。而基于面向对象开发的特点，在这个过程中，前面的工作成果往往能够很好的进行复用，重构的成本也很低。自然而然的，开发的过程会形成多次的迭代。但是，在这个过程中，最重要的是需要按照面向对象的思维方式进行设计与开发。

基于上面的认识，在回顾XP的各项原则会发现，以前认为不现实的内容其实都是顺理成章的事情了。唯一的问题仅仅是现场客户的问题，不过这个在一定的程度上 面也能够克服。由此可见，当深入了解了面向对象的开发的精髓之后，XP的各项原则实际上都是面向对象过程的一些内在的需求而已。

极限编程的12个原则：

1. 计划的制定
2. 小版本
3. 简单设计
4. 测试驱动
5. 持续整合
6. 重构
7. 配对编程
8. 代码共享
9. 每周只工作40小时
10. 现场客户
11. 隐喻
12. 编码标准

关于OOD的一点点总结

很多成熟的设计过程摆在面前：用例驱动、XP用户故事、特征驱动FDD、模型驱动MDD、敏捷模型驱动、领域驱动、测试驱动等等等等……到底应该怎么设计呢？
简单的讲，过程内容会分为需求分析和设计。
需求驱动是最根本的，所以在需求阶段，所谓的各种驱动方法其实都是对需求的功能分解，以便日后进行分治的设计以及管理跟踪。
由Use Case -> User Story -> Feature其实是由粗到细对需求分解的不同粒度。
有了需求条目之后，针对每一个条目可以继续进行设计工作。
设计过程的目标其实很简单：

• 类的识别
• 类的结构（例如：继承、关联、聚合、依赖等等）
• 类的属性
• 类的方法
• 系统运行是类之间的消息传递关系。

前三项是在整个设计过程中不断进行更新的，是个逐步细化的过程。分析的早期就可以识别大部分实体类，而在模拟需求条目的场景的过程中，逐步识别边界类（主要来自于页面流程分析）和控制类。主要的工具就是UML类图。
后两项则是通过模拟每一个需求条目所描述的场景来设计类之间的消息传递关系。在这个过程中，自然的完成对类分配方法。主要使用的工具如顺序图、协作图或者CRC分析。

对于MDD, AMDD以及DDD来讲，感觉上是针对非常熟悉的业务需求或者非常有经验的分析设计人员，因此采用了更新颖的设计路径。

而TDD应该理解为一种辅助设计手段。