博客搬家了！！！

本博客正式版家到
http://blog.redoublelive.net

对于Redmine系统功能的一些感受（不足）

最近，在工作中频繁使用Redmine系统来管理实际的项目。在使用中发现，Redmine真的是非常强大的项目管理系统。部署方便，功能齐全，理念也比较先进。

然而，美中不足的有两点：

1. 现在的项目管理系统，都非常强调协作于沟通在项目管理中的重要作用。因此，系统中都有针对于某一条任务，大家共同来贡献内容的功能。实际工作当中，关于这一条任务的一些当前的工作进度、任务中的一些困难及其解决情况、关于该任务的一些设计细节、关于遇到问题的大家的讨论等等，这些都会记录在该任务中。这个功能在Redmine中有实现，但是在UI设计上显得过于古板了――任务的一些基本属性充斥了整个主要版面。而关于该任务的讨论在页面在最下端，经常需要向下滚屏才能看到，而且还与该任务的一些修改日志混杂在了一起。这样，对于任务的协作与沟通这个主题显得非常的不突出。

2. 实际工作中发现：我经常需要将某一个任务再次进行拆分，拆分成许多更微小的条目。然后针对这些条目在标记完成的状态。在这一点上redmine没有对应。只能在任务的详细信息中进行维护，又基于上一点原因的考虑，redmine对于这一点的对应非常不好。（据说redmine 1.0版本中会开始支持sub-issue，估计这样会好一些。）

针对以上两点，ActiveCollab, Streber, Zoho Project实现的非常好！值得借鉴。

项目管理系统对于实际管理需求的对应

刚刚和软件部门的部门经理进行了一会儿的讨论。

部门经理提出了他在今年的管理思路，然后想询问目前的项目管理系统如何对应。

管理思路如下：

• 整个部门会分为若干个项目团队，每个团队有唯一的负责人。
• 每个团队会同时负责多个系统/项目，每个项目的有唯一的负责人。（我建议项目的负责人就由团队负责人兼任）
• 各个系统/项目的需求来源会是多渠道的，有可能是不定期的。
• 部门经理日常既需要按照项目团队来管理人力资源，有需要按照系统/项目来进行业务管理。
• 部门经理需要看到针对团队和项目的不同层次的规划。

鉴于目前公司使用的REDMINE系统，我提出的对应方案如下：

• 针对每一个项目团队，在系统中建立单独的项目。团队负责人即是项目经理。
• 针对每个团队同时负责的多个项目，在系统中以issue catalog进行区分。
• 由项目经理负责将各个渠道的需求条目进行汇总，进行管理，并协调确认优先级。然后即可以采用SCRUM方式进行项目流转。
• 项目经理在规划时：
• 季度级别的规划以子项目的形式体现。（这个稍微有点别扭）
• 迭代周期级别的规划以version的形式体现。
• 迭代周期内部，使用issue进行任务分配。
• 这样，按照系统中的项目看来，项目组成员的工作量是饱满的。然后可以按照issue catalog进行过滤，观察某一个系统/项目的情况。

鉴于redmine非常强大的issue自定义过滤功能，因此可以很好的满足软件部门经理的管理需要。

而zoho project和activecollab该如何对应呢，正在考虑中……

（

activecollab：

• 只有单层的milestone功能，而没有子项目管理能力。因此对于多层次的规划需要对应比较困难。
• ticket有category功能，但是其过滤查询功能显然没有redmine强大。

）

（

zoho project / 百会项目：

• 里程碑分为两个层次，多种类型，完美对应规划需求。这点，比redmine强。
• 对于任务没有分类功能。
• 没有子项目功能。
• 任务查询功能不强。

）

activeCollab的功能特色

虽然我对如何使用REDMINE已经非常熟悉了。REDMINE已经非常强大了，但是，基于以下的一些原因，我准备在新公司继续使用activeCollab来进行项目管理，而不是Redmine。

• activeCollab提供功能，可以将单个项目的所有内容导出到一份静态文件包。
• activeCollab的文件管理功能，可以管理版本。同时，各个ticket中上传的附件，可以在统一的文件管理中全面查看。
• activeCollab的人力资源管理功能，可以对人员所在的公司进行管理。
• 对于一个任务来讲，可以同时分配给多个人。
• milestone->ticket->task三级管理，强于redmine的version->issue的两级管理。
• 有全局的DOCS管理功能。

下面是相对于redmine来讲activeCollab的弱项：

• 没有subproject设计，但是可以使用ticket中的category勉强对应。
• page功能没有wiki功能强大，勉强够用。
• 没有甘特图功能。
• 报表功能和筛选功能不如REDMINE强大。
• 没有插件机制，因此缺少了很多定制的功能，例如：燃尽图等。
• 缺乏流程定义功能。
• 缺乏自定义字段功能，所以一些信息的维护不够复杂，例如关于项目的一些信息等等。
• 没有单独的新闻模块。
• 不能继承版本控制系统。

不过上面这些暂时都可以忍了。另外最重要的：activeCollab不再免费了！

影响人生的八句话 - winter606的转帖 - 使用 Google 工具栏发送

影响人生的八句话 - winter606的转帖

第一句话：优秀是一种习惯 （这是古希腊哲学家亚里士多德说的）


第二句话：生命是一个过程 （事情的结束尽管重要，但是做事情的过程更加重要）


第三句话：两点之间最短的距离并不一定是直线 （两点之间最短的距离一定是直线，这仅仅是几何学上的定义。现实生活中并不如此，在人与人的关系以及做事情的过程中，我们很难直接了当就把事情做好。


第四句话：换位思考是一种原则 （生活中人与人之间总会有些合作的事情，此时，你不要仅仅考虑自己的利益，要充分考虑对方的利益。）


第五句话：不要跨越那条看不见的线 （生活中健康的人际关系是既要保持合适的距离，又要避免无谓的人际冲突。）


第六句话：缺陷是一种恩惠 （做人最大的乐趣在于通过奋斗去获得我们想要的东西，所以有缺点意味着我们可以进一步完美，有匮乏之处意味着我们可以进一步努力。）


第七句话：要学会感激磨难（朋友们要学会感激哦，感激伤害你的人，因为他磨练你的心态；感激绊倒你的人，因为他强化你的双腿；感激欺骗你的人，因为他增进你的智慧；感激蔑视你的人，因为他觉醒你的自尊；感激遗弃你的人，因为他教会你独立。学会感激，感激一切使你成长的人。）


第八句话：放弃是一种智慧 （人一定要学会用你的东西去换取对你来说更加重要和更加丰富的东西。所以说，放弃是一种智慧。）

敏捷开发过程的选择

敏捷开发过程有很多：XP, SCURM, CRYSTAL, ASD, FDD……
近两年以来，越来越发现，这些过程没有好与不好，之后是否适合。
第一个层面是是否适合中国的大环境；
第二个层面是是否适合你所处的组织；
第三个层面是是否适合你手头的项目类型和客户。

有的时候可能不能过度的追求某一个过程，为了过程而过程。例如：
XP显然对客户的要求非常高。实施的结果往往是我们某种程度的敏捷了，但是并不是XP。
SCRUM的作者自己也说：SCRUM不太适合固定价格的合同。而在国内，工程项目开发领域，有多大比例的合同不是固定价格的呢？所以SCRUM更适合国内的产品开发。
CRYSTAL的要求非常松散，作者自称也适合固定价格合同。其实因为严格讲CRYSTAL不是一个过程，而是和ASD一样，是一个过程的生成器。
FDD, ICONIX貌似更加适合国内的现状。而且我以往的经历中有很多ICONIX成功案例。
所以准备最近在好好研究一下FDD。
UP应该也可以，但是一是UP的裁剪对使用者要求太高了，二是UP对团队能力要求也比较高。

百会项目与redmine的对比

百会项目是一个SaaS的在线项目管理应用。价格便宜，功能强大。在此对比一下百会项目与redmine。

百会项目与redmine都有的特色功能：

• 多项目管理
• 人员管理
• 里程碑（版本）管理
• 任务管理（在任务上可以进行很多注释和回复）
• 甘特图
• 工时登记
• 日历
• 文档上传
• 报表
• 论坛
• WIKI 
• Email集成

百会项目有的功能而redmine没有的功能：

• 会议安排
• 任务可以关联到某一个文档或者WIKI页面
• 文档统一管理，而不是分散在各个任务中
• 时间表
• 及时聊天
• 集成百会办公套件

redmine有而百会项目没有的功能：

• 非常灵活的任务列表的过滤
• 自定义报表条件和内容
• 文档自定义分类，同时上传文件可以指定到版本
• 自定义工作流
• 自定义项目、任务等等条目的新加字段
• 插件机制
• 自定义个人首页
• 与版本控制系统集成
• 项目信息更加详细
• 新闻功能

二者都没有的功能：

• 以个人为线索观察项目和工作量分配
• 单个项目所有信息导出成静态文件
• 风险管理（redmine可以使用插件实现）
• SCRUM风格需求管理（redmine可以使用插件实现）
• SCRUM风格图表（redmine可以使用插件实现）
• 任务分层
• 测试用例管理

其它说明：

百会是商业软件，需要付费，但是非常便宜。

redmine部署到本地，而百会项目是基于Saas的。

正在仔细观察activeCollab，商业软件，价格可以接受，无中文版，但是有一些有意思的功能设计，如：

• 任务可以分层
• 多公司（机构）管理
• 回收站功能
• 单个项目导出到静态文档
• 自动备份

买了新车,无外乎是铺地胶、座套、贴太阳膜、方向盘套等！我国的一大特色！

先说车窗贴膜

汽车玻璃采用了隔热玻璃，能有效阻挡汽车外部阳光，并能提供给驾驶员一个良好的视线！（据我所知，捷达都是隔热玻璃的，呵呵）
贴膜以后阻挡视线不说，坐在车内还有压抑感，并不能没有阻碍的欣赏窗外美丽的景色了！
贴膜是中国一大特色，好像赤道国家比咱国家热，可是就没有贴膜的！
欧洲国家在车内浪漫的也不少，隐私也极多，也没看见贴膜的！
美国也没有贴膜的，但是后窗有深色玻璃，但是那肯定是社会名流或者是黑社会的人员为了避免曝光所坐的！
普通的公民的车也没有贴膜的！
中国就是怪，满大街的车，黑呼呼一片！你说奇怪不奇怪！
曾经有一位朋友去开着贴膜金杯车去机场接客人，国外的朋友看到车后连说：NO，NO，NO，这样的车我不坐，坐也可以，把膜揭掉，要么换车，如果司机愿意揭掉汽车玻璃的膜，我可以补偿汽车司机200美元，可以么？我不想坐黑社会的车！翻译和司机乐的合不拢嘴！


再说地胶
还有地胶，好好的地毯不用，非要弄个廉价的胶皮铺在车内地板上，尘土始终在地胶表面，脏点还别开空调，一开空调，把地胶上的浮土吹的满车都是！
新地胶还好点，万一磨破了，水气进去了，天一热，湿气在地胶与地板之间散发不出来，就那味，肯定认为开车的是汗脚丫子！
地胶廉价，质量不过关，各种有毒物质超标，造成车内空气污染！
哎，又是中国一大特色！


再说汽车坐套
汽车厂家煞费苦心的来选择布料，做到能防静电，耐磨、透气、阻燃、防火等等，耐脏的布座椅面料，汽车座椅面料在整车所占成本的百分之一左右，却被一个几十元到几百元不等的廉价坐套所替代！
真皮座椅加坐套的大师也大有人在！
其他的国家也没有！
又是一个中国特色！


还有方向盘套
汽车在设计之初，考虑到了方向盘的大小，材料、以及手掌在方向盘的舒适感，考虑到了人体工程学，以及方向盘材质的透气性，耐磨性、排汗性等，但是这些做法是徒劳的，现在有很多车主装上了价值几元到十几元不等的方向把套，有的是用低价的塑料，有的是用毛毛的材料制作！说是冬天方向盘太凉？难道手攥着粗粗的方向盘不难受？
瑞典在北极附近，那里的车也没有这么先进的毛绒绒的把套！
其他的汽车发达的国家也没有，难道我们国家的汽车发展水平这么有超前性？


再说车内小饰物
在车前风挡玻璃处的内后视镜，有好多人在上面挂着小饰物，
有中国结、菩萨、观音、前几年还流行过一段领导人的像片，其实有这些东西悬挂起来不错，但是挂的不是地方。
您在驾驶时，这些小饰物会随着车辆的行驶而摇晃，提倡安全驾驶，您想想你在专心开车的时候，有个东西在你眼睛的余光内游动，能舒服吗？还有刮小铃当的，晃悠加带响的，又眼晕，又耳鸣，还影响车内人员的谈话与休息。
最重要的是会影响驾驶员的视线，在车辆直行时还不觉得，在转弯时你就会觉得碍事了！小饰物的摆动，会影响你对车辆右侧的突发事件的判断能力，如果您不相信，您可以把小饰物拿掉几天，试试看，如果我说得不对，您再挂上！呵呵！
也是中国的特色


汽车封釉
新车买来了，车主为了呵护爱车的漆面，要进行所谓的汽车封釉，说是可以永保漆面的光泽度。
车漆是经过特殊的工艺喷涂到汽车表面上的，车漆内含有金属成分，耐褪色，抗老化等性能，在汽车行业内规定，生产厂商要保证汽车漆面在10－15年内不发生质量上面的衰退。十年以后，您的车已经老了，您还在乎他的漆面么？何况您的车已经成为二手车、三手车……
现在买车以后，更换新车的频率根本不会超过十年，为什么要增加自己的额外的经济支出哪？所谓的封釉只不过是一种拐着弯的从你的兜里掏出你没有必要花的钱！


底盘封塑和减噪改装
轿车底盘封锁，底盘封塑可以减低汽车内的噪音与底盘的刮蹭保护作用。
汽车的噪音不单单是从底盘传来的，汽车噪音是包括轮胎噪音、发动机噪音，行驶中风噪音、排气系统等，单一的底盘封塑根本降低不了噪音，要做系统的整治，换玻璃、密封条、换低噪音发动机、换好的轮胎等等，造价肯定不菲，还不如买一辆更高级的车哪！也有做了降噪改装后加排气尾喉的（说是增大马力，增加发动机的声音来提高驾驶乐趣的），真不知道是为了啥？
封塑以后可以当底盘装甲使用，现在的路是越修越好了，现在的轿车离地间隙都很低，说做了封塑以后可以提高通过性，难道您要开车轿车去越野吗？路不平的话，再好的底盘装甲也是无法通过的，我想，真是在行驶中遇到了大的障碍物（例如大石块），车辆底盘肯定会承受不了撞击而损坏的，底盘都坏了，装甲也就完了！其实合理的判断路况，与驾驶技术切切相关。车辆一般都是在城市内行驶，一年之内很少有时间出去遇到坏路，底盘装甲封塑要给车增加几公斤到十几公斤不等的份量，每天承载这增加的份量，燃油消耗量经过日积月累也是一个可观的数目吧！

面对的是企业的软件工程文化

近几年以来，我求职的两个主要的方向都是：BA（业务分析）和项目管理改进。也是我的兴趣所在。

所以目前我的工作是做我所在的公司的项目管理办公室主任，负责项目管理体系的建立。

不过，工作以来，曾经在3家公司干过。在第一家公司做到了开发部门的部门经理也PMO经理。在第二家公司做行业经理和项目经理。到了第三家公司在PMO主任。在这三个位置上，工作内容不尽相同，但是几乎或多或少都会有这样的感觉：项目管理改进的工作很难。虽然职位不相同，所以其工作方式和权限也不相同，但是感受总是非常的相似。眼中看到企业中软件开发的过程存在很多的问题，但是人们做出变化非常难。

直到最近，我才悟出其中的道理。我所面对的不仅仅是软件过程改进这么简单的事情。需要概念的是一个企业或者组织的''软件工程文化''！

这种文化是在该组织的老板在组件团队之初就已经形成的，与老板的认知与经历所匹配，然后随着组织的成长而渗透到整个团队的意识中。

因此，想凭借着某个个体的力量而改变整个组织的软件工程文化，非常难。尤其是如果老板对该文化仍然自我欣赏或陶醉的状态下，几乎是不可能完成的任务。

在这样的状态下如果想要生存的话，我所做的事情必须是实际上在对该文化进行加固的工作，而不论该文化是否是合适的。

有了上面这样的认识，就应该调整一下自己的心态：

• 不要妄图使企业的软件工程文化符合自己的要求，除非自己是老板。
• 想要生存的话，应该是自己适应所在企业的软件工程文化，然后是整个工作文化。只允许在文化框架内部进行微调。
• 如果做不到的话，以后还是寻找只需要管好自己的职业位置，例如业务分析人员。

streber项目管理软件，新思路

听说这个软件有一段时间了。最近才刚刚拿起来看看。

新颖的思路：

1. 任何一个条目都是wiki，因此，可以发现，对于项目信息的组织方式其实可以非常的灵活。项目、公司、任务、主题都是wiki条目。
2. 从这一点来讲，系统仅仅提供了一个平台，如果想把系统用好的话，则需要项目团队又更规范的约定。
3. 另一方面，系统可以应对更多类型的项目，弹性非常大！
4. 可以上传文档进行文件管理，而且具有文件版本管理的功能。

遗憾：

1. 仍然缺乏全局的项目管理视图，例如全局的人员利用情况等。这样，这个软件就仍然只能定位于小团队项目管理。（团队不超过40人，同时进行的项目最好不超过5个）
2. wiki条目如何才能导出成文档呢？
3. 由于使用wiki，对团队成员要求略高。
4. 报告功能很弱。（例如最近非常时髦的Burndown Chart就没有提供）
5. 没有日历功能
6. 没有插件机制
7. 功能仍然不够全面，例如：风险管理，费用管理等等没有实现。

想劝劝我的一个朋友

最近正在想劝劝我的一个朋友找新的工作。

我的朋友正在我上半年所在的项目组，变成了副项目经理。工作压力非常大，每天加班工作的很辛苦。这几天给他打了电话，听说12月初，他老婆就要生了，他还在经常的加班到彻夜不归。

所以我非常想劝劝他赶紧换工作吧。

1. 工作压力大没有关系，但是这样的项目我非常清楚：痛苦指数会一直升上去，没有将下来的时候……
2. 工作负责任是对的（包括对自己的老板负责），但是其实单个人并没有那么的重要，地球没有谁都会继续转，大家还会生活的很好。
1. 你会发现，自己其实只是老板的工具。
2. 如果你干的真是革命工作，那么放弃了那么多也值得了。但现在呢？你是在为资本家打工啊。
3. 项目干好了又能怎么样呢？结果还不是客户的兔崽子们又去邀功了？
4. 项目组有多少人病重了？你的身体有谁来关心呢？
3. 20年后，你会为哪件事情后悔呢？是为了当初没有多些时间陪陪家人，还是为了当初没有多谢时间加班？

两个idea

1. redmine的新插件：Isotrol RequMNGT plugin 可以保存baseline！好功能！
2. redmine中的文档模块可以定义文档的类别，这样还是有比file模块有更强的管理功能！因此建议项目的管理文档都上传到文档模块。

心情很差

svbux倒闭了。

投资的1000块虽然不算多，但是也挺恶心的。

看看风声，其他的站也不安全。

两次教科书一般的SCRUM会议

上周五和本周二，我经历了两次教科书一样的SCRUM会议。

背景：

我准备在公司推进敏捷项目管理方法。想办法得到了软件开发部部门经理的支持。于是乎在新立项的G维护项目中进行实验。

上周五下午，是G维护项目的一次迭代汇报会议。

会议中，我帮助项目组成员回顾了已经完成的工作，同时分析了工作没有按照计划完成的原因。会议的效果如下：

1. 下一次迭代的估算时，每个成员每周流出1天的工作量来应付突发的事件。
2. 讨论出了若干实际的方法来解决项目中出现的沟通的问题。

本周二上午，是G维护项目的迭代规划会议。会议中：

1. 先约定了以后会议的一些常态规范和约定
2. 计算了本次迭代项目组所有可用工作量的小时数
3. 请产品经理按照优先级的顺序给大家讲解需求
1. 产品经理由于没有按照部门规定的用例格式书写需求条目，被部门经理严重批评
2. 过程中，我尽量的引导了所有项目组成员对需求条目进行讨论和澄清
4. 针对每一条需求，项目组成员进行了DELPHI的估算方式
1. 估算以小时数为单位，而不是功能点
2. 针对每一条的估算分割成了开发和测试两部分
5. 由于有另外一个产品经理的需求还需要占用项目组的时间，因此要求两个产品经理对需求条目进行合并，并对优先级进行了协调。
6. 项目组成员对本迭代的需求进行了认领
1. 开发经理也会承担一部分开发任务。按照原来的计划方式，开发经理会承担很多难度较大的需求条目。工作量过载会导致开发经理成为瓶颈。采用这样的计算方式，避免了出现上述的问题。其他的开发人员帮助开发经理分担了工作。
2. 测试人员只有一名，但是测试的工作量已经溢出，因此要求开发人员分担了一些测试执行的工作。
3. 最终达到了工作量的大致平衡分布。

当然，规划会议中也出现了一些问题：

1. 对于某一条需求，分割粒度不够。有两个开发人员估算了40小时，开发经理估算了20小时。按照一般的约定，应该由产品经理再次分割指16小时之内。但是强势的部门经理坚持认为该需求不能在分割了。基于当时的环境，我没有坚持。
2. 还是针对该条需求，开发人员的估算存在明显的分歧（包括部门经理在内），出现了短暂的紧张气氛。由于我意识到该条需求具有明显的潜在认领者（开发经理），因此我也没有坚持针对他的估算必须达成一致。
3. 针对于需求的描述格式。由于部门内部发布了用例的规范格式，因此当然要求产品经理进行遵守。但是针对这个特定的项目（用户的角色非常单一），我们都发现，描述功能比描述场景可能更加合适。因此，在日后的改进工作中，有必要发布用户故事的格式规范。
4. 在浏览需求条目时，发现了不同的需求条目之间存在着依赖关系，即某需求的开发的开始和估算依赖于另外一条需求。我在本次会议中没有处理这个情况。我觉得这其实是由于被依赖的需求条目还需要被拆分。但是，我准备在下一次迭代中再处理这种情况。
5. 本次规划中发现需求来源于两个产品经理。这一次虽然协调的比较顺利，但以后还是需要尽量避免。

虽然出现了一些问题，但是我还是对这两次会议非常满意了！关于部门经理非常强势的问题，由于本次实验部门经理也非常支持，因此我会在以后的私下聊天中，逐步改变部门经理的管理方式。

感谢以下一些图书的作者：

《SCRUM敏捷项目管理》

《SCRUM敏捷项目管理实战》

《硝烟中的SCRUM和XP》

《敏捷无敌》

《敏捷估计与规划》

Redmine又有了新的插件！

今天早上本来想试验一下redmine中的导出文档的功能。结果发现无法按照正确的编码导出PDF文件。可以导出CVS格式的文件，但是导出的字段也不完整。
于是上redmine主页查找相关的插件。结果发现出现了一些新的插件！

1. Isotrol Estimer plugin （基于功能点的估算，终于等到了……）
2. Isotrol RequMNGT plugin （需求管理）
3. Isotrol RiskMNGT plugin （风险管理）
4. Issue Due Date plugin （最终日期）
5. Issue Group plugin （分组）

上述插件显然是某个公司开发之后放上来的。正好是我目前最需要的一些功能！
有时间一定要好好研究一下！
对了，上周五下班前参加了软件部某个项目的周末迭代总结会议，不错，教科书一般的进程。

个人桌面维基软件的选择

目前还缺乏完美的产品：

• TiddlyWiki
• 优点：完整的语法支持，丰富的插件，非常好的便携性能，可以发布到户联网。
• 缺点：性能！（真要命）
• Tomboy
• 优点：非常好的性能和易用性，支持的格式还算够用，具有同步功能（联网或者本地）。
• 缺点：不支持内嵌图片，没有内容导出功能。
• Zim
• 优点：可以内嵌图片，能够到处成HTML等文件格式，编辑方便有快捷键，内容以TXT格式存储方便移动。
• 缺点：支持的格式是在是太少了！windows下面安装极其麻烦。

可以看出来，缺点都很要命！

有时间再看看wixi。

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：

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

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