我的2007

对于软件项目团队，人员的技巧和经验可能对生产率产生高达10倍的影响。在《人月神话》中曾提到对于一个100人的团队，最好是只保留25个经验丰富的项目经理进行开发，而解散其它成员。当实际上一个软件团队不可能要求每个人都经验丰富，经过充分的培训和智商奇高，都是牛人的团队往往更容易出现混乱。因此 需要谨慎实施只雇佣优秀开发人员的想法，一个更好的方式是多考虑如何去建设一个有战斗力的团队或者是如何真正去保证团

导读：　　序号 类型 度量指标 描述 度量频度 数据源　　1 原始度量元 需求功能点个数 被测系统或被测模块的需求规格说明书的需求个数 测试需求分析阶段 　　　2 系统内部接口数 单系统内部的模块之间的接口数量 测试需求分析阶段 　　　3 跨系统外部接口数 被测系统与外部系统之间的接口数量 测试需求分析阶段 　　　4 测试需求个数 对被测需求分析后的测试需求的个数 测试设计阶段

导读：　　　　在以前的文章中关于项目经理做什么或者如何做好一个项目管理者/项目经理都有很多的叙述。但是最近也有很多的朋友MSN询问作为一个PM应该关注的重要的事情是哪些？ 当然其实所谓的重要的事情，如果从系统化的角度来看的话，有三个系统化教材可以得到全部的答案，这也是作为在软件行业内作为PM应该熟悉的内容，他们是SWEBOK（Software Engineering Body Of K

导读： 　　作者：Rock Sun, Subversion中文站。 　　如有转发请注明出处：http://www.subversion.org.cn/index.php?option=com_content&task=view&id=85&Itemid=9 　　版本控制最关键的一件事是保证数据的安全性，不能因为磁盘损坏，程序故障造成版本库无可挽回的错误，为此必须制定较完备的备份策略。在Subver

导读： 　　在Web工程过程中，基于Web系统的测试、确认和验收是一项重要而富有挑战性的工作。基于Web的系统测试与传统的软件测试不同，它不但需要检查和验证是否按照设计的要求运行，而且还要测试系统在不同用户的浏览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。然而，Internet和Web媒体的不可预见性使测试基于Web的系统变得困难。因此，我们必须为测试和评估复杂的基于

 “没有教导人们 OO 是一种设计，然后告诉他们设计的原则，相反人们被告知 OO 就是使用一种特定的工具，而我们可以用任何一种工具编写出优秀或糟糕的程序。除非我们教会人们如何进行设计，程序语言起到的作用是很小的。结果往往是人们用这些语言作出了糟糕的设计，几乎没什么价值。” —— David ParnasRUP实施之夺命七招 (加拿大) Valtech首席科学家 Craig La

作者：彭敏　 企业对使用敏捷开发方法来处理复杂软件工程项目越来越感兴趣。这些企业希望通过控制成本和进度来提高开发流程的效率，并且同时交付满足客户需求的有价值产品。

IBM Rational 技术白皮书傅纯一 IBM中国有限公司软件部Rational中国区技术销售经理2004 年 9 月 1. 传统开发流程的问题传统的软件开发流程是一个文档驱动的流程，它将整个软件开发过程划分为顺序相接的几个阶段，每个阶段都必需完成全部规定的任务（文档）后才能够进入下一个阶段。如必须完成全部的系统需求规格说明书之后才能够进入概要设计阶段，编码必需在系统设计完成之后才

       “欲造物，先造人！”一个项目的成功或失败，其首要关键因素是人。项目成员是否能够步调一致，是否能够积极主动的朝着同一目标前进便成为项目顺利开展直至最终完成的基本前提。通常员工表现不佳，有来自员工内在思想的原因，也有来自其它多方面外在环境的原因。其中后者有更多的因素，影响面更大。这就要求项目经理必须努力帮助员工创造更好的环境，包括工作场地、设施工具甚至生活条件等硬件环境，同时也包括项目总

        制定软件项目进度表有两种途径：其一是软件开发小组根据提供软件产品的最后期限从后往前安排时间；其二是软件项目开发组织根据项目和资源情况制定软件项目开发的初步计划和交付软件产品的日期。多数软件开发组织当然希望按照第二种方式安排自己的工作进度。然而遗憾的是，大多数场合遇到的都是比较被动的第一种方式。 　　在软件项目管理工作中，对软件项目的进度安排有时比对软件成本的估算要求更高。成本的增

SOA规范的来龙去脉 前言：SOA的概念早已从多年前的朦胧步入了逐渐清晰和具体化，当SOA开始真正地进入企业应用和实施的时候，这些飘在空中的SOA概念必须要落实到实际的白纸黑字规范和标准上，只有这样，才能实现各个不同SOA系统和实现之间的无缝连接。随着SOA概念的不断成熟以及各大IT巨头逐渐在SOA的具体细节上不断达成共识，于是成立了一个SOA的标准化组织OSOA（www.osoa.org

导读：　　　　软件项目的返工问题　　软件行业普遍利润率低，软件项目的成本超支司空见惯，到底成本到哪儿去了？　　软件工程师天天加班加点，说到底还是返工问题。软件项目的返工成本几乎达到　　项目成本的一半以上。到底什么算返工，目前业界好像还没有确切的定义，我总结　　了一下，一下情况应该算是返工：　　返工的定义可以理解为应该并有能力做到返工后的水平的却因为各种主观因素　　却没有一次

导读：　　在软件测试过程中，测试数据的准备是一个工作量很大而且也是一个技术活。因此如何准备大量的测试数据，而且如何准备高质量的测试数据，满足测试的需求，就是一个重要的话题。　　首先看数据的来源，数据的来源一般来讲有三个个，一个是根据被测系统需求的分析，针对正常业务，异常情况，边界情况等来构建完整的数据，又称为“造”数据。这不仅仅包括最基本的基础数据，比如：用户、权限、配置、基础编码、原

导读：　　在项目管理的三要素TQC中，这三者在项目管理中是需要平衡的，但是更需要明白他们并不是平等的，为什么这么说呢？这也是因为软件项目的特点引起的，关于软件的项目管理的特点参见我的博客中关于CMM的文章的描述。在软件项目中进度的延迟和成本的增加很大程度上是因为质量引起的，系统的质量问题往往会导致返工，在软件项目中返工已经成为项目经理的恶梦。而返工的直接后果便是进度的拖延和成本的上升，当

对开发人员采用拉的方式而不是用领导者推的方式. 激励开发人员就好比是像要向前移动一根绳索，最好的办法不是在绳子的这一端推而是在另外一端拉。 如果对工作人员激励不到位，也不管他们工作时间多长，管理者将得不到40小时的产出.因为很有可能他们上本只是为了应付，或者为了避免到了截至日期完不成任务而产生坏的影响. 需要少量的超时就可以了。不要过度要求。 开发人员一般能自我激励，因为要使他们加班的关键就是诱发

    1，把合适的工作分给合适的人    显然，每个人都不是全能选手，每个人都有所长和所短。领导应该了解自己的下属，包括他们的特长和所好，让每个人做其最擅长和喜欢的工作。下发工作最好不要是强制性的，先征求他们的意见和建议，问一下他们的看法，一定对完成工作有很大的帮助。因为不是所有的领导其脑子都比下属聪明，相反，在具体的微观的细节上，下属往往比领导更有发言权。让工作在下属的愿望和控制内进展，更能体

    对于软件开发来说，源于丰田生产管理系统中的“看板系统”是一种用于安排工作的非迭代方法。它并不使用固定时长的迭代和计划会议的工作方式，而是完成先前的工作后才从backlog中取得新的故事来做的工作方式。Dave Nicolette （Valtech公司的一个敏捷教练）说道：“在敏捷社区中，有一些人似乎变成了干零活的人。他们仅掌握一种敏捷工作的方法，却把它来遇到的解决所有问题．当你只会接管道时

JavaEye新闻上次发表了“年度总结：Java 2008年大事记”，现在是此系列第二篇：年度总结：2008年Java工具。 磨刀不误砍柴工，拥有一个好的工具，在现代化编程/团队管理中拥有重要的地位。2008年的软件开发生命周期管理软件(software development lifecycle: SDLC)在2008年有了长足进展，JavaWorld的Java工具领域专家John Fergus

软件开发的残酷的现实告诉我们：没有规则的软件开发过程带来的只可能是无法预料的结果。我们中的大多数项目管理人员在其个人简历中纷纷写到：“拥有多年的丰富的项目管理经验”，但在实际开发中，“丰富的”管理经验变成了软件开发人员可怕的梦魇。一次次的失败、一次次的返工，他所谓的项目管理经验只不过是再一次的游戏于“无间”(十八层地狱)。一次，在与不少项目管理者的交流中，大家纷纷提到的软件变更带来的可怕影

导读： 　　社区Agile主题敏捷实施,企业级敏捷标签Scrum作者李剑，在InfoQ中文站上发表了一篇"Scrum在中国——企业实施情况调查实录"。这份调查实录，分别调查了五个实施SCRUM的公司，其中三家公司实施成功，二家公司失败。我建议所有准备或者正在实施SCRUM 的人们都能来读一下。 　　在此，我们会对这篇文章中的案例分类进行分析、诊断。并探讨什么是敏捷开发方法、什么是SCRUM

SCRUM方法如下：由Ken Schwaber和 Jeff Sutherland 提出，旨在寻求充分发挥面向对象和构件技术的开发方法，是对迭代式面向对象方法的改进，名称来自英式橄榄球（在比赛中每个队员都应时刻保持对场上全局的判断，然后通过集体行动，奋力实现同一目标──胜利）。SCRUM方法最初实践于Easel公司(1993年)，现已被数十家公司数百个项目开发中应用，适用于需求难以预测的复杂商务

导读：　　此书最早出版于1966年，我还没出生，PC也还没出现，知识分子应该还没有今天的浩浩荡荡。乍一看书名，讲的是“管理”没引起什么兴趣，看了才知讲的是知识分子的自我管理，只能叹为先知先觉，昂首仰视ing……　　英文名字叫《The Effective Executive》，怎么看都象“有效执行”，看完了才觉得中文名译的也是经典，虽然让我误以为是一般管理的书籍差点漏过：） ［注：德鲁克

导读： 　　　　年底正好跟猎头公司接触的很多，自己的朋友、同事、BF都在IT圈子里。就说说几大IT 　　公司的情况，给想跳槽或者有目标的朋友们借鉴一下。所谈的数字基本属于平均水平， 　　也只谈到中层，高管层不是我们所了解的，天文数字也不到这里讨论了。 　　本人是做sales的，所以以sales的情况为主，附带谈谈开发的状况。 　　1、主流IT公司的三、六、九等。 　　在猎头那边，IT公司也

导读： 　　新方法论 　　The New Methodology 　　作者：Martin Fowler 翻译：坚强2002 　　源文档 　　过去的几年中，敏捷开发蓬勃发展，敏捷方法被当作修正机构结构僵化的一剂良药抑或是打通软件过程奇经八脉的不二法门。本文我将探索敏捷方法的源头，不是强调它何等重要而是要把关注点放在它的适应性和以人为本这两个方面。 　　Contents 　　· 无章法里程碑敏

导读： 　　看了很多创业的case，都有点下笔千言，离题万里的情况。就是很多case都很精彩，但是公司的价值最终是落实到给创业者和投资人的回报的。因此，所有的case，最终都是，落实到盈利模式上。 　　一位投资人士说的很明确，中国的盈利模式很简单，就是两个半，广告，游戏，还有半个是电子商务。我觉得这句话如果送给很多创业中的人，他们肯定都有如梦初醒的感觉。很多人看着成功故事融入互联网创业大潮

漫谈创业和管理－程序员5大思维障碍  程序员是最容易创业的，或者说是创业成本最低的职业。只要有一台电脑和投入自己的时间，就可以写出畅销天下的软件，这是每个程序员的梦想。更何况世界首富常年以来就是程序员出身的比尔盖茨，这也刺激了更多的程序员走上创业之路。 可是等到真的开始创业，才发现这条路并不容易.由于创办CSDN网站和《程序员》杂志的原因，接触了大量的技术创业者，或者从技术转向管理的程

  1.客户没有能力阅读用例      如果客户实在没办法撑住困意看完用例的细节，即使草草签了名，得不到用户真正确认的用例，依然无法用来驱动设计和测试。      解决方法：放弃编写用例，改回用户看得懂的传统方式。    2.团队没有能力实现用例驱动      如果开发团队在设计与测试时，根本不依照用例细节进行，那用例就只是个摆设，花瓶。      解决方法：对设计、测试人员进行用例驱动的培训

n 4+1视图模型概况     Kruchten 提出了一个"4+1"视图模型，从5个不同的视角包括包括逻辑试图、进程视图、物理视图、开发视图、场景视图来描述软件体系结构。每一个视图只关心系统的一个侧面，5个试图结合在一起才能反映系统的软件体系结构的全部内容。如下图： n 逻辑视图（Logic View）     逻辑试图主要是用来描述系统的功能需求，即系统提供给最终用户的服务. 在逻辑视图中，系

这是微软资深项目经理人Stephen Maguire的项目管理经验。软件开发和网站开发有极其相似的地方，我们可以从中学习领会许多知识。 第一章 .有效团队的基础 1、专心改善产品公司付工资给设计师，要他们在合理的时间开发出品质精良的网站，但是设计师们的时间却经常被其它事情占用了。 典型

RUP是Rational统一过程（Rational Unified Process）的简称，它是Rational公司（现归属IBM公司）推出的一种软件过程产品。从软件过程模式角度看，RUP又是一种典型的软件过程模式，它以迭代增量式、架构为中心、用例驱动的软件开发方法、采用UML语言描述软件开发过程为主要特征，其中以用例驱动乃是贯穿软件开发始终的方法。 什么是 CMM？　　 CMM(Capa

现在体会到了开会原来也是个体力活，从早上9点到下午6点，又开了一天的会，最近这样的会议不知道有多少次了，有和局方的，项目组内的，大部分是设计人员内部交流会，大的项目作起来真不容易，只有通过会议来解决业务流程问题和人员组织分配问题，但问题是项目作到现在了还在讨论srs问题，忽紧忽松的管理模式实在有时候让人摸不清思路，项目的进度是有客观规律的，如果违背客观规律，那么作出来的项目还有生命力么；今天刚

进入项目已经10几天了，虽然前几天提的建议没有得到改进，但我用自己的实际行动正在影响着项目，正准备走向：源代码设计＋时序图设计＋伪码设计，先设计业务层，建立起需求和编码之间的桥梁和纽带，偶负责的是平台最核心的功能设计和实现，偶也通过自己的实际能力赢的了周围同事的信赖和支持。作一个优秀的软件架构者和优秀的项目管理者， 继续努力，摆正心态，向着设定的目标前进！

        年前和领导谈了工作调动和薪资调整的问题，年后经理给了回复，结果让人大失所望，不是结果的问题，而是对这件事情的处理态度。          其一，对是我朋友的朋友的上司的处理态度问题；                     本想朋友的朋友怎么也是朋友，会站在兄弟的角度帮你分析问题和处理问题，但没想到老板永远比朋友重要，也许根本就不算朋友，我又错了，给别人台阶下，给自己挖了个

软件开发为何不能像硬件开发那样可控？a软件质量之旅将带给我们一些启示。 提到软件产品开发，我们的脑海里总是浮现出这样的情景:开发组的每一位成员都在辛苦地工作，加班加点，甚至通宵达旦。虽然项目经理一次又一次地修改a了进度计划，而实际的开发情况却总是令人担忧，以至于每次向领导汇报工作的时候，总是觉得以前制定的计划没有很好完成，总是觉得人力资源不够，总是觉得没有太多的时间。等到代码终于开发完成了，测

极限编程又称xp方法，是敏捷开发的软件过程模型。　　极限编程的4条准则：沟通，简单，反馈和勇气（修复缺陷，集中攻关和放弃原有的代码）。　　基本原则：快速反馈，假设简单，递增更改，提倡更改，优质工作。　　开发软件的4项基本工作：编码，测试，倾听和设计．首先使用计划游戏，根据功能的优先级和实际进程来决定游戏的玩法，并只是制定下一阶段的计划，希望程序员主动的接受责任，并对预期实现的时间进行估计。不断发布

拿破仑同学说过：不想当将军的士兵不是好士兵。这话有一定的道理，人活着有时是为了一股气，为了实现梦想，我们需要不停地充气，气足了人才会有干劲有激情，对于我们中的多数人来说，这是一个漂泊的时代，社会上80%的人都是打工的，只不过大伙的衣领分级别而已，有金色的，有白色的，有灰色的，有蓝色的，有无色的，不要以为金色的就了不起，本质上与蓝色是一样的：打工。偶也是个打工的，只是有一部分是为自已打工，我对打工着

版权声明：原创作品，允许转载，转载时请务必以超链接形式标明文章原始出版、作者信息和本声明。否则将追究法律责任。本文地址：http://blog.csdn.net/jobchanceleo/archive/2007/02/14/1509960.aspx马上要过年了，如果不想考虑新的工作机会。相信很多朋友都计划着向公司老板提一下加薪的要求。有N多文章谈过加薪的事，在此分享一下我的个人观点。

本人从事了四年左右的软件开发工作，曾参与开发过多个大型项目，对于整个项目开发中我觉得有很多地方都应该应当值得注意，特写如下观点和各位看客共同探讨！ 1、项目设计 项目设计的主导思想，我觉得可以理解为两种，一种是完全设计，一个是简单设计。 完全设计是指在具体编写代码之前对软件的各种方面都调查好，做好详细的需求分析、编写好全部的开发文档，设计出程序全部流程后再开始写代码。 换句话说，就是全部的计划好了

    5年，粟维胜（Webboy）就干了一个事情----给中小网站供应CMS。最早叫动力文章系统，现在叫动易CMS。在ASP的通用平台上，动易的份额还不错。挺羡慕他，他玩互联网的时候我也在互联网上玩码字，他的公司一年的收入做到了几百万，我还在码字，虽然我也经常思考通用CMS的盈利模式的问题。    上周末，Webboy看到了一篇讲开源软件的文章后，跟我谈起了开源软件。他觉得，媒体对开源软

         公司新来了个开发部经理，据说以前在我们公司呆过，而且是从华为出来的，一直想了解新的领导的管理方式和执行能力， 通过这俩天的接触，发现了有很多值得我等学习的地方，摘取一二，以飨来者：          一、对项目清晰的把握，从客户角度确定进度，从公司角度分析利弊；                  前几天开了项目会议，确立了项目的目标，从各方面阐述项目对公司，对个人的利弊，