最近，上海电信就采用了赛门铁克的“云计算”方案，让我们看到，虚无缥缈的“云”终于落地了。对于云计算原来我们讲的一个重要概念就是计算能力和存储能力从桌面端到网络端(云端)的迁移，另外广义的云计算包括了SAAS，PAAS和IAAS三个方面的内容，电信行业前两年在SAAS领域的努力并不是特别的成功，在这里面重要的问题点还是SAAS是偏互联网的运营，而拿着传统的电信运营模式去做互联网的运营注定是会失败的。

所以吴锡源对中国电信运营商向“云计算”迁移的步骤给出了几点建议： 首先，部署云基础架构，利用虚拟化技术建立一个云存储，把分布在不同数据中心的存储资源整合在一起，进行统一的管理，分配给不同的应用使用； 其次，部署中间件层，建立一套SOA基础架构，让运营商对外提供标准的服务； 第三是在此基础上，构建新的云应用，实现SaaS的目标。

所以云计算落地的第一步是IAAS，而云基础架构本身又是搭建在虚拟化技术上面的。现在很多大型影响厂商如IBM或HP的小型机，EMC的各种存储设备本身就是支持虚拟化和云计算的。即硬件设备的CPU和内存资源对于多个应用是共享的，是今天动态分析或动态扩展的。虚拟化的重点是超级计算机通过虚拟化变成了

最近一直感觉自己在退步或停止不前，一方面是最近确实工作很忙，事情比较多，而一忙起来就由一种主动工作变成了一种被动工作，从有计划的工作变成了无计划或即短计划工作，这就造成真正留个思考和总结的时间越来越少；另外一个方面就是工作内容最近也发生了比较大的变化，原有积累的一些好的实践反而在新环境下很难完全落地，也感觉到是一种退步。

其实我们并不关心现状本身，而是关注是否真正能够持续改进，只有能够持续改进就是一种进步，否则就是退步。而持续改进要的正是团队的思考，学习和不断的回顾。敏捷里面有一个最高指导原则讲的很好，即无论发现了什么，考虑到当时情况、个人技术水平和能力、可用资源，我们理解并坚信：每个人都已全力以赴。基于这个最高指导原则，我们才可能更好的进行反思和回顾，对事不对人。

知识为什么需要沉淀和积累，需要转换为方法论和智慧，一方面是指导后续的行动，一方面则是唯有智慧是最不占用头脑资源的。每个人的记忆能力都有限，而分析和解决问题能力，思维能力并不是靠的记忆力。这个问题我们必须要想清楚，因此很多时候我们从事新的领域和工作的时候自然会丢弃掉原有熟悉的业务领域，自我感觉是退步

原文：http://www.agiledon.com/post/2009/02/PM-Thinking.html

这段时间，一直在负责一个项目的管理与开发。在时间短、任务紧，而团队人员又大部分是没有经验的菜鸟的恶劣情况下，我带领接近40人的团队，终于在客户规定的时间范围内如期交付产品。这其中，经历了需求变更、人员变动（因为其它任务，先后有近10人离开团队）等诸多问题，项目仍然取得成功了，不能不说有几分侥幸，但此外也有一些经验与教训可以与大家分享。

软件工程-需求

项目应以需求为核心。一个项目是否能够成功，对需求的准确把握在成功因素中要占上60%的比例。不管系统的架构设计、团队管理有多么的成功，如果需求出现偏差，仍然是南辕北辙。由于EAS项目的特殊性，项目开发过程中能够与客户建立有效快速的沟通渠道，是项目成功的关键。

需求必须获得客户的确认。通过需求调研与分析后获得的用户需求说明书，以及软件需求规格说明书都必须得到客户的签字确认。确认的内容包括项目的目标、范围以及项目需求功能点（用例）。EAS项目在前期对需求不够重视，导致在需求理解上出现了一些

原文：http://www.agiledon.com/post/2009/02/Agile-Retrospectives.html

印第安人在赶了3天路后，会停下来小憩一天，因为他要等着自己的灵魂跟上来。敏捷开发在经历了一次迭代或者冲刺（Sprint）后，也需要休整，以 等待团队的灵魂跟上来，这一过程被称之为“敏捷回顾（Agile Retrospectives）”。敏捷回顾与项目总结会议不同，它并非项目结束之后的盖棺论定，而是在项目过程中，通过回顾会议及时总结上一次迭代中的 得与失，以期达到改进项目开发、团队合作等敏捷活动的目的。

如果将项目开发比作是一次征途，那么在项目中期的短期休整是很有必要的。然而 这种休整并非是将团队成员集体拉出去腐败一次，或者到K厅去鬼哭狼嚎一番，以泄心中的郁闷，如此种种只能说是身体心灵的休息与放松。就像是运动员在比赛期 间，队医的按摩、擦汗的毛巾、解渴的饮料。这些重要吗？当然重要，放松疲惫的身体与心灵，方能更好地走向更远的目标。但更重要的是灵魂的“反刍”，就像教 练员针对运动员在上一局比赛的盘点与指导，指出选手以及对手的优与劣，从而制定出后面比赛的对策，方能把握取胜之钥。

敏捷回顾不是一场没有主题的讨论会，大家坐下

先再谈下风险，对于风险必须要关注风险应对措施的风险。很多时候我们识别出了风险，也针对风险给出了风险减轻措施和风险应急措施。但是当进行风险减轻的时候，或者当风险转变为问题进行应急的时候，发现当初的这些措施本身就存在不确定或者无法执行。比如我们做船，识别了风险在每个座位都准备了救生衣，但是当船真正翻了的时候，发现救生衣很难取出来，风险应对措施根本就无法执行，本身就存在风险。这种情况一方面是意识的问题，一方面是我们本身就根本没有重视风险。

团队很重要，企业小的时候团队的精神在于经理人的个人魅力，这也不能说团队不够成熟。企业大的时候或者团队发展比较久后靠的是团队文化，团队中谁离开都不会影响到团队。对于企业，在企业文化中我们谈到一个词叫心理契约，而在团队中仍然存在心理契约，一种隐性约定的团队文化和纪律。

任何一件事情尽量减少在中途放弃，要么一开始就决策不做，要么就按目标做好。当一件事情已经展开的时候，中途放弃不仅仅是成本的损失，更多的则是一种信用的损失。在项目管理上，经理人在自我思考上更多应该是一个悲观主义者，悲观的含义在于风险和危机意识，思考来不得半点马虎。而在团队气

迭代是我用的最多的一个词，而且在快速和敏捷开发中更加强调短迭代，一周到两周为一个迭代周期。迭代的目的一方面是进度可视，进度可视的体现是产出物可视，每次迭代是一个至少内部可以独立发布的版本。同时迭代另一方面重点仍然是应当需求不明确的情况，对于需求的不明确我们的解决之道就是分解，要通过分解找到明确的内容，放入前面的迭代周期先做，而不是由于需求不明确造成我们整个项目计划的不明确。

高效的开发团队中的每一个人都应该是一个高效的人，是一个懂得如何自我管理的人。而对于开发的自我管理有一个重点则是开发团队的GTD方法，在软件开发中即是PSP个体软件过程。开发人员要达到高效不仅仅是技能水平很出色，而且必须有很强的纪律性，懂得如果管理自己的任务和分配自己的时间，同时通过大量的积累懂得自我的工作效率。

需求要条目化，条目化的重点是原子性，原子性从业务上解释则是该条需求在业务上是可以独立验证的最小单位。如果从这个角度出发，一个软件需求用例可能包括多条可以条目化的需求。而这个条目化的需求则是对应到类似FDD特征驱动开发中的特征点。只有有意识的走到这一步，才谈得上软件开发文档的全部结构化管理，

原文:http://www.javaeye.com/topic/299761

Scrum 理论是基于一个国外的学科，叫《过程动态学，建模及控制》，什么意思呢？过程控制方法有两种：预定义过程控制和经验性过程控制。预定义过程就是在执行之前先要制定详细的计划，然后严格按照计划执行，这种控制方式在过程比较简单的情况下比较适用，但是如果过程不可能预测的非常详尽的话，预定义过程就显得力不从心，这时候“经验过程控制”就更合适于过程控制。

经验过程控制讲究“检查”和“调整“，就是在执行过程中不断的检查是否出现问题然后根据实际情况来调整过程的执行。这两种过程各有优缺点。

预定义过程在当今软件业仍然有着广泛的应用，为什么呢？就是因为预定义过程可以在项目开始之前就能给出大概的项目预算和风险评估，这样投资人才可能放心的投资项目。当然它的弊端就是应对变化的风险很差，尤其在于软件开过程中，变化是不可避免的，很多情况是不可预知的，所以预定义过程在这种情况下就显得力不从心。

下面谈谈scrum如果用经验过程控制来进行项目管理。

典型的瀑布式项目的分工一般是：项目经理，team lead， developer， 需求分析员

悟性来源于对自我实践过程的不断反思，悟性来源于自我思维能力的提高，其本身也是一个通过PDCA循环过程不断进行改进和提升的。即不断的积累和渐修带来了顿悟，有很多时候我们都是一个道理老想不通，自我实践和遇到的事情多了，在融会贯通后往往恍然大悟。而谈悟性最大的作用是带来的自我能力的提升，当时悟了可能并不重要，更重要了是领悟后指导实践，提升了自我实践技能和工作效率。

有可能我们对一些事情领悟的快，一些领悟的慢。或者说我们天生领悟的慢，但是领悟的慢往往是好事情。因为迅速的领悟往往并没有进行深层次的思考，没有深层次的思考更谈不上指导实践。而领悟的慢的人思维过程会更加系统化和严谨，在领悟的过程中往往随时都在考虑明白道理后我应该如何做，因为任何道理和方法只有自己真正做了才谈得上真正领悟。

灵性对每个人也很重要，代表了做事情机灵和敏捷，但是很多时候灵性的人容易停留在面上，即只关心如果做，我迅速了掌握了如何做？但是往往并不关心我为什么要这样做？还有没有其他更好的方法来做。因此离开了悟性的灵性往往并不会为自我带来更多的价值。很多时候我们起跑可以晚一点，可以慢一点，真正把问题想透彻了，带

最近买了个魔方来玩，现在6面复原的时间基本在1分半到2分钟左右，最快能够在1分多一点。这里面其实涉及到工作技能中的一个重要问题，即使先生产率稳定再提高生产率还是先快了再来考虑效率的稳定。工作中很多时候的方法应该是先有稳定的工作效率再来考虑如何提高效率。如果个人效率波动太大，则对自我计划和估算都会造成很大的影响和不确定性。个人效率波动太大对个人和对企业都属于灾难。

市场和销售是两个重要的领域而且各有侧重。原来我们的理解是市场战略，市场策划，产品和行业分析，市场营销和定价策略等都属于市场的内容，产品在没有形成明确的销售机会前的很多工作都属于市场。因此IPD集成产品开发中包括了MM市场管理，做为产品生命周期管理的一个重要组成部分，即理解市场，细分市场，产品组合规划，路标规划和产品版本规划。而销售关注两个重点，一个是客户关系管理，一个通过客户关系管理发现销售机会，从销售项目立项一直跟踪到招投标和最终形成合同。

做项目我们经常在谈客户意识，客户意识的重点则是客户没有想到的你要帮助他想到，客户有想到的你要帮助客户提前想到。客户本身又分为高层，管理层和执行层，你随时需要模拟不同的客

这周本来约好了秋水和长云一起小范围聚聚聊下最近的工作心得，结果刚好在外面出差没有能够赶的回来，现在这种小范围的交流对我来说太重要了，一方面是沟通交流思想，一方面是舒缓自我，特别是我最近也在持续使用OutLook+OneNote，也很喜欢和长云交流下使用的情况。

最近确实是很忙，而心亡为忙，越忙的时候思考的时间越少，或者说思考的深入度越低。一个是忙的时候关注的事情太多，很难真正做到专注；一方面是忙的时候自我学习时间被挤压掉了，很难真正的结合实践去做积累。

很多时候我们在讲忙而不乱，也在讲可以借助GTD方面的工具来清空头脑和减少忙乱。但是出现忙乱是一个质变的过程，质变是通过的量变的积累，即可能是前期大量没有做好的小事件的一个积累，表现到最好可能就是忙乱。用时间管理的话说就是以及走在了时间的后面，转变为一种救火状态。用项目管理的语言就是大量前期没有识别或重视的风险最终转换为了问题。所以我们将应当忙乱的重点是抓住重点，循序渐进的过程。不要想着一两天就能够纠正过来，而是要留出时间，梳理时间，在各个击破。

个人自我管理的重点是要管理好自己，实现自我规划，创造自我价值。所以专业