心情很差

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：

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

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

采访张琳

刚刚看到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的高级项目管理顾问。原来也是联创的员工，是老板的老同事。而且据称也是位天才级人物。原来如彼。
总之，我晕！