Welcome! Ubuntu 9.10

今天白天Ubuntu 9.10第一天发布，我也赶了一下时髦，DOWNLOAD了一份ISO。

准备今天晚上开始安装！

虽然非常仔细，但是还有遗漏

关于软件采购的事情，虽然前期的工作已经非常谨慎了，但是到了下午就要签合同了，仍然发现有一些问题没有确认清楚，例如：

1. 是否支持ORACLE数据库。因为有可能需要在客户现场的系统都是用统一的数据库系统。目前采购的软件如果需要部署在ORACLE上面的话，有可能需要价格在DOUBLE。
2. 能够提供什么样的接口与其他的系统进行集成。因为有可能本系统需要与客户方若干已有的系统进行集成，可能会仔细的安排各个系统各自的职责等等。
3. 是否能够提供可供二次开发的接口。这个也非常重要。

Firefox插件的选择

	FEBE	Sxipper	Xmarks	Lastpass
Configurations	o
Extensions	o
Bookmarks	o		o
Password	o	o	o	o
Auto Form		o		o
Online	box.net (GFW)		Xmarks (GFW) / Self Server	o
Offline	o	manual backup	o
Sync	On Time		Auto

结论：选择FEBE+Lastpass的组合，配合dropbox

这是一个哲学论断

如果一个系统足够复杂的话，那么中央总控式的管理方式注定崩溃。需要发挥系统中下层的自管理能力和主观能动性，才能保证良好运转。

范例1：

如果一个软件系统比较复杂的话，那么自顶向下的设计方式（即传统的面向过程的软件工程）注定失败，无法应对未知的变更。只有自底向上的设计开发方式（即面向对象的软件过程），才能演进方式的建立系统架构，才能保证系统结构的健壮性。

范例2：

对于软件开发项目来讲，传统的瀑布式项目管理方式很难保证项目的准确实施。只有最近出现的敏捷管理方式才能够最大程度的发挥团队成员的主观能动性，保证项目的成功。项目管理需要留给执行人员发挥个人能力的空间。

范例3：

在中国来讲，传统的计划经济体系注定无法满足社会发展的需要。所以需要市场体制来对经济的发展进行自我调节。

想来想去，觉得这是一个哲学论断。

采访张琳

刚刚看到CCTV-5的访谈节目，在演播室采访运动员张琳。席间记者对张琳的表现评论了一番之后，主持人请张琳说话。张琳说：讲的太好了，我没什么要说的了。

呵呵！

国内的体育记者绝大多数是这个特点：最重要的工作是表达自己的观点，而不是采访到被采访对象的观点。

另一方面说明：国内的媒体工作者，制造别人的想法已经成为一种习惯了。

取消使用instiki，完全转向redmine。正在看activeCollab和ProjectPier

最终决定，在redmine上面新建一个“项目管理制度”的公开项目。其中只包含wiki模块和文件管理模块。

这样，就可以不需要使用instiki系统了。

另外，经过猩猩的推荐，正在看另外的两个项目管理系统：activeCollab和ProjectPier。

决定退回到redmine+instiki了

考虑再三，决定还是退回到redmine+instiki了。

Jira虽然非常灵活，但是其以issue为主线的方式还是不能解决一切问题。例如：没有以项目为单位的文档管理，没有子项目的设置，其子任务的机制也比较简单；wiki不能以项目为单位分开。

redmine虽然不能建立子任务，但是如果能够在设置version是变换一下，变成里程碑的话，没有子任务估计也可以忍受。

然后就是有几个任务需要解决：

1. 参考jira，利用插件，多建立一些项目的图表。
2. 看看是否可以开发一个风险管理的插件。
3. 看看issue的过滤器能够多灵活？

准备再研究一下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客户折磨着。……