博客园_程序人生http://feed.cnblogs.com/blog/u/9376/rss2010-08-13T10:40:52Zcaidehuihttp://www.cnblogs.com/caidehui/feed.cnblogs.comhttp://www.cnblogs.com/caidehui/archive/2010/08/13/1799259.html软件开发的特点总结之二-----软件产品我们天天在开发软件产品，有必要思考一下软件产品的特点，我大致查阅了有关材料，做点总结： 知识密集 创造性 虚拟性（不可见性） 实现不具有唯一性 复杂 高附加值 逻辑性强（*） 由于软件所具有的这5个特性，导致了软件开发工作的复杂性。软件开发知识密集，意味着我们需要高智商的群体来完成，具有创造性也对人提出了很高的要求。虚拟的，看不见，就验不着，验不着的事就会有点悬，因此软件开发就必须千...2010-08-13T10:38:00Z2010-08-13T10:38:00Zcaidehuihttp://www.cnblogs.com/caidehui/<p><strong> </strong></p> <p><strong> <p> 我们天天在开发软件产品，有必要思考一下软件产品的特点，我大致查阅了有关材料，做点总结： <ol> <li> <p>知识密集</p> <li> <p>创造性</p> <li> <p>虚拟性（不可见性）</p> <li> <p>实现不具有唯一性</p> <li> <p>复杂</p> <li> <p>高附加值</p> <li> <p>逻辑性强（*）</p></li></ol> <p> 由于软件所具有的这5个特性，导致了软件开发工作的复杂性。软件开发知识密集，意味着我们需要高智商的群体来完成，具有创造性也对人提出了很高的要求。虚拟的，看不见，就验不着，验不着的事就会有点悬，因此软件开发就必须千方百计的要让它看得见，文档、模型都是在设计阶段的要求。 <p> 看不见的问题，也导致客户在表述有关需求的难度，这个难度也正好是软件开发最不好解决的问题之一。 <p> 实现不具有唯一性，这个就麻烦了，每个人都可以有自己的做法，都能实现软件产品外部看起来的行为，但是里面怎么样，只有专业人士可以明白，这也导致了很多投机取巧的行为出现。 <p> 复杂，这个Dijistra在几十年做过一个总结，大意是说只有软件系统从底层到顶层的复杂性为9级。 <p> 高附加值，这个不知道是好是坏，好在于这个特性说明了软件的重要性，坏，也就说明了一旦出事的严重性。一旦软件投入使用，可能影响到一个企业的各个方面。 <p> 总的来说，软件产品是纯脑力劳动的结果，它不同于我们以往的产品。我们不能要求梵高一定要每天画出一副画，但社会确要求我们的工程师按照这个速度生产软件。 <p> 我们是脑力劳动者，却被像工人一样要求，我们是知识工人。</strong></p></p><img src="http://www.cnblogs.com/caidehui/aggbug/1799259.html?type=1" width="1" height="1" alt=""/><p><a href="http://www.cnblogs.com/caidehui/archive/2010/08/13/1799259.html" target="_blank">本文链接</a></p>http://www.cnblogs.com/caidehui/archive/2010/08/13/1799261.html软件开发的特点总结之三---软件开发过程为了开发具有下列特征的软件，我们必须要重新审视我们的过程： 知识密集 创造性 虚拟性（不可见性） 实现不具有唯一性 复杂 高附加值 软件开发过程的一些现实： 周期短 成果不可见性 对技术的要求高 技术更新快 风险大 软件开发过程必须要做到： 价值驱动 架构驱动 管理、控制与适应需求的变化 适应软件开发人员 让成果可见 效率高 高质量 降低风险 与过程有关的一些...2010-08-13T10:38:00Z2010-08-13T10:38:00Zcaidehuihttp://www.cnblogs.com/caidehui/<p><strong> </strong></p> <p><strong> <p> 为了开发具有下列特征的软件，我们必须要重新审视我们的过程： <ol> <li> <p>知识密集</p> <li> <p>创造性</p> <li> <p>虚拟性（不可见性）</p> <li> <p>实现不具有唯一性</p> <li> <p>复杂</p> <li> <p>高附加值</p></li></ol> <p> 软件开发过程的一些现实： <ol> <li> <p>周期短</p> <li> <p>成果不可见性</p> <li> <p>对技术的要求高</p> <li> <p>技术更新快</p> <li> <p>风险大</p></li></ol> <p> 软件开发过程必须要做到： <ol> <li> <p>价值驱动</p> <li> <p>架构驱动</p> <li> <p>管理、控制与适应需求的变化</p> <li> <p>适应软件开发人员</p> <li> <p>让成果可见</p> <li> <p>效率高</p> <li> <p>高质量</p> <li> <p>降低风险</p></li></ol> <p> 与过程有关的一些最佳实践： <ol> <li> <p>迭代，迭代周期控制在2-6周的范围内。迭代以软件产品构建为中心，每次迭代确定一个关键的主题，完成一个有价值的工作。软件产品构建需要首先确定好软件产品的基础，那就是客户的需求与技术的架构，然后再架构基础上进行分阶段的逐步开发。</p> <li> <p>价值驱动</p> <li> <p>风险驱动</p></li></ol></strong></p><img src="http://www.cnblogs.com/caidehui/aggbug/1799261.html?type=1" width="1" height="1" alt=""/><p><a href="http://www.cnblogs.com/caidehui/archive/2010/08/13/1799261.html" target="_blank">本文链接</a></p>http://www.cnblogs.com/caidehui/archive/2010/08/13/1799258.html软件开发的特点总结之一------人要想持续成功交付软件系统，首先要研究好做软件的人，他们的特点，他们的需要，如何领导他们持续走向成功。一般软件开发都采用项目式的方法，因此我需要讨论人的两个层次，一个是作为个体的人，也就是你、我这些工程师们；二是作为团队一员，你我的表现。 简单一点，不做展开: 工程师们的特点：（尽量客观） 知识丰富 高智商 爱好学习与钻研 自尊心强 过高估计自己，个人英雄主义 收入水平相对较高 责任心强 ...2010-08-13T10:37:00Z2010-08-13T10:37:00Zcaidehuihttp://www.cnblogs.com/caidehui/<p>要想持续成功交付软件系统，首先要研究好做软件的人，他们的特点，他们的需要，如何领导他们持续走向成功。一般软件开发都采用项目式的方法，因此我需要讨论人的两个层次，一个是作为个体的人，也就是你、我这些工程师们；二是作为团队一员，你我的表现。 <p> 简单一点，不做展开: <p> 工程师们的特点：（尽量客观） <ol> <li>知识丰富 <li>高智商 <li> <p>爱好学习与钻研</p> <li> <p>自尊心强</p> <li> <p>过高估计自己，个人英雄主义</p> <li> <p>收入水平相对较高</p> <li> <p>责任心强</p> <li> <p>不喜欢被束缚</p> <li> <p>沟通与表达能力弱</p> <li> <p>缺乏纪律性</p> <li> <p>你的和我的，分的太细</p> <li> <p>诚实</p> <li> <p>具有创造性</p> <li> <p>年轻</p> <li> <p>固执</p> <li> <p>专注</p></li></ol> <p> 上面罗列的特点，来自于这段时间的收集与整体。如果大家有好的资料来源，也请提供给我。 <p> 汇总起来一句话，就是我们其实是知识分子群体的一员。也就是德鲁克所定义的知识工作者。对于知识分子进行管理与领导的总结如下： <ol> <li> <p>尊重</p> <li> <p>清晰的目标</p> <li> <p>目标驱动</p> <li> <p>以事实为基础，避免人身攻击</p> <li> <p>沟通</p> <li> <p>工作分解与审查</p> <li> <p>让人们参与决策</p> <li> <p>人员搭配与团队模型</p> <li> <p>众效责任</p> <li> <p>问题员工的管理</p> <li> <p>授权</p> <li> <p>营造宽松的环境</p> <li> <p>去除坏分子</p></li></ol> <p> 如何对我们进行激励： <ol> <li> <p>成就</p> <li> <p>学习与研究的机会</p> <li> <p>参与决策</p> <li> <p>宽松的环境</p> <li> <p>能够获得晋升的机会</p> <li> <p>信任</p> <li> <p>金钱</p></li></ol> <p> 应该要注意什么： <ol> <li> <p>避免钻牛角尖</p> <li> <p>政治</p> <li> <p>人身攻击</p> <li> <p>性格不合</p></li></ol> <p> 对于在团队中，工程师们的行为、领导与管理、激励等有待进一步研究</p> <img src="http://www.cnblogs.com/caidehui/aggbug/1799258.html?type=1" width="1" height="1" alt=""/><p><a href="http://www.cnblogs.com/caidehui/archive/2010/08/13/1799258.html" target="_blank">本文链接</a></p>http://www.cnblogs.com/caidehui/archive/2010/08/13/1799257.html软件开发的主要要素为了有效开发软件，我们必须对其要素进行充分认识，软件开发的要素主要为： 软件开发的要素 产品： 目的、目标、需求与需求管理、配置管理、验证 人与团队 团队构成、领导、激励 过程 方法论、过程、工作方法；可视化建模、迭代、阶段控制 技术 技术选择与技术路线、架构、框架、技术攻关 管理 计划、组织、领导、控制。风险、变更控制、质量控制 只有有效的管理这五个要素，才能持续不断的成功交付软件。2010-08-13T10:35:00Z2010-08-13T10:35:00Zcaidehuihttp://www.cnblogs.com/caidehui/<p> 为了有效开发软件，我们必须对其要素进行充分认识，软件开发的要素主要为： <p>软件开发的要素 <ol> <li> <p>产品： <p> 目的、目标、需求与需求管理、配置管理、验证</p> <li> <p>人与团队 <p> 团队构成、领导、激励</p> <li> <p>过程 <p>方法论、过程、工作方法；可视化建模、迭代、阶段控制</p> <li> <p>技术 <p>技术选择与技术路线、架构、框架、技术攻关</p> <li> <p>管理 <p>计划、组织、领导、控制。风险、变更控制、质量控制</p></li></ol> <p>只有有效的管理这五个要素，才能持续不断的成功交付软件。</p><img src="http://www.cnblogs.com/caidehui/aggbug/1799257.html?type=1" width="1" height="1" alt=""/><p><a href="http://www.cnblogs.com/caidehui/archive/2010/08/13/1799257.html" target="_blank">本文链接</a></p>http://www.cnblogs.com/caidehui/archive/2010/06/02/1750209.html一个典型的软件项目的WBS评析下面是网上流传甚广的一个软件项目的WBS。我相信很多人都使用过自己创建过类似的WBS。 正是由于我们的先辈，先辈的先辈用类似的方法来创建WBS，耳濡目染之下，我们也养成了同样的习惯。 这是一个典型的有问题的WBS。 首先从客户的角度来说，从第一层分解要素来看我们无法看到我们到底要交付给客户什么？你告诉客户，我要交付给你一个系统设计，客户还不得跳楼。因为客户要的是OA系统、财务系统、邮件系统，机房...2010-06-02T10:01:00Z2010-06-02T10:01:00Zcaidehuihttp://www.cnblogs.com/caidehui/<p> 下面是网上流传甚广的一个软件项目的WBS。我相信很多人都使用过自己创建过类似的WBS。</p> <p><a href="http://images.cnblogs.com/cnblogs_com/caidehui/WindowsLiveWriter/WBS_F9F0/image_2.png" rel="WLPP"><img style="border-bottom: 0px; border-left: 0px; display: inline; border-top: 0px; border-right: 0px" title="image" border="0" alt="image" src="http://images.cnblogs.com/cnblogs_com/caidehui/WindowsLiveWriter/WBS_F9F0/image_thumb.png" width="836" height="240"></a></p> <p>正是由于我们的先辈，先辈的先辈用类似的方法来创建WBS，耳濡目染之下，我们也养成了同样的习惯。</p> <p>这是一个典型的有问题的WBS。</p> <p>首先从客户的角度来说，从第一层分解要素来看我们无法看到我们到底要交付给客户什么？你告诉客户，我要交付给你一个系统设计，客户还不得跳楼。因为客户要的是OA系统、财务系统、邮件系统，机房、设备、系统软件。</p> <p>从实施的角度来看，我们大有可能购买现成的邮件系统，或者将邮件系统外包给一家公司，先在我们简单看看，如果我们外包邮件系统，这个WBS是不是就很不方便了。</p> <p>第三个，我们是可交付成果导向，请问项目启动会交付什么呢？</p> <p>这个典型，或者与此类似的WBS还得我们好惨，也导致我们只能管理比较小的项目，对于大项目就束手无策，因为WBS一开始就有错，后面岂不越管越乱。我来对这个WBS做个调整，看是不是好一点。</p> <p><a href="http://images.cnblogs.com/cnblogs_com/caidehui/WindowsLiveWriter/WBS_F9F0/image_4.png" rel="WLPP"><img style="border-bottom: 0px; border-left: 0px; display: inline; border-top: 0px; border-right: 0px" title="image" border="0" alt="image" src="http://images.cnblogs.com/cnblogs_com/caidehui/WindowsLiveWriter/WBS_F9F0/image_thumb_1.png" width="919" height="263"></a> </p> <p>这不是一个完美的WBS，因为我所获得信息只有上面那个WBS那么多，但这是一个非常好的开始，有利于项目管理团队不断的去讨论，包括与客户讨论，从而不断调整。</p> <p>从该WBS我们能够很清楚的看到，我们需要交付的产品与服务。</p> <p>我这里假设财务系统将采购，邮件系统将采购后进行二次开发，OA系统全部二次开发。其中有些环节我已经分到了活动级别，有的还在WBS的工作包级别。如果我们的项目以此为基础进行，那么我们就可以进行后续的进度、职责分配等工作。</p> <img src="http://www.cnblogs.com/caidehui/aggbug/1750209.html?type=1" width="1" height="1" alt=""/><p><a href="http://www.cnblogs.com/caidehui/archive/2010/06/02/1750209.html" target="_blank">本文链接</a></p>http://www.cnblogs.com/caidehui/archive/2010/06/02/1749755.html为什么我们的WBS元素多是活动这个问题思考了一段时间，得到的结论非常可笑。那就是在以前所有的WBS参考书，由于篇幅所限，都是用非常简单的。这些简单的项目，能够非常快的看清楚可交付成果和活动，因此也就一次全部做完了。我们来做一个对比，车库项目，基于可交付成果的方式如下： 基于活动的方式如下： 前者强调的是我们要做什么，后者强调是做。我们知道要完成一件事情，有很多方法，有的时候我们很快就能想到一个方法，所以着急写上去。这是正常的思...2010-06-02T02:11:00Z2010-06-02T02:11:00Zcaidehuihttp://www.cnblogs.com/caidehui/<p>这个问题思考了一段时间，得到的结论非常可笑。那就是在以前所有的WBS参考书，由于篇幅所限，都是用非常简单的。这些简单的项目，能够非常快的看清楚可交付成果和活动，因此也就一次全部做完了。</p><p>我们来做一个对比，车库项目，基于可交付成果的方式如下：</p><p><a href="http://images.cnblogs.com/cnblogs_com/caidehui/WindowsLiveWriter/WBS_8CDF/image_2.png" target="_blank"><img style="border-right-width: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px" title="image" border="0" alt="image" src="http://images.cnblogs.com/cnblogs_com/caidehui/WindowsLiveWriter/WBS_8CDF/image_thumb.png" width="428" height="190" /></a> </p><p>基于活动的方式如下：</p><p><a href="http://images.cnblogs.com/cnblogs_com/caidehui/WindowsLiveWriter/WBS_8CDF/image_6.png" target="_blank"><img style="border-right-width: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px" title="image" border="0" alt="image" src="http://images.cnblogs.com/cnblogs_com/caidehui/WindowsLiveWriter/WBS_8CDF/image_thumb_2.png" width="645" height="210" /></a> </p><p>前者强调的是我们要做什么，后者强调是做。我们知道要完成一件事情，有很多方法，有的时候我们很快就能想到一个方法，所以着急写上去。这是正常的思维逻辑，但是对于复杂事物的把我，要遵循分与合的原则。</p><p>WBS在项目管理中，主要的作用是保证项目做的是正确的事情。至于如何把事情做正确，更多的在活动定义的时候来解决。</p><p>在前面的WBS确定我们要交付车道，我们既可以自己来完成，也可以分包给专门修路的公司。如果是前者，也许你用修建车道这个做法是比较合适，如果是后者，你只要提出对车道修建到什么水平、预算、时间要求等就可以了，其余的都交给外包公司了。</p><p>我们来看看WBS的另外一个作用，就是用在核实范围上，也就是验收。如果你是客户，你和供应商的PM去验收，人家跟你说，我现在验收“修建车道”，我晕。</p><p>我们再来看看管理的场合。PM跟自己的经理的两种报告：</p><blockquote style='border:2px solid #EFEFEF;color:#333333;padding:5px 10px;'><p>A:老板，车道我们建完了；老板，车道要花1万块；老板，车道要用12天。</p><p>B:老板，修建车道我们干完了；老板，修建车道花了1万块；老板，修建车道要用12天。</p></blockquote><p>由于客户一般情况下不关心我们如何去做，或者说客户先关心我们要做什么，然后才会关心我们打算怎么去做，而客户是我们的衣食父母，所以要尽量使用客户能够听得懂的方法。</p><p>下面我将车道部分做进一步的分解</p><p>基于可交付成果的进一步分解，最底层为活动</p><p><a href="http://images.cnblogs.com/cnblogs_com/caidehui/WindowsLiveWriter/WBS_8CDF/image_10.png" target="_blank"><img style="border-right-width: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px" title="image" border="0" alt="image" src="http://images.cnblogs.com/cnblogs_com/caidehui/WindowsLiveWriter/WBS_8CDF/image_thumb_4.png" width="858" height="416" /></a> </p><p>基于活动的进一步分解</p><p><a href="http://images.cnblogs.com/cnblogs_com/caidehui/WindowsLiveWriter/WBS_8CDF/image_12.png" target="_blank"><img style="border-right-width: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px" title="image" border="0" alt="image" src="http://images.cnblogs.com/cnblogs_com/caidehui/WindowsLiveWriter/WBS_8CDF/image_thumb_5.png" width="917" height="363" /></a> </p><p>从上面的分解来看，使用基于可交付成果的分解方式，更利于下层的进一步分解。</p><p><strong>总结：</strong></p><blockquote style='border:2px solid #EFEFEF;color:#333333;padding:5px 10px;'><p>WBS分解时，其元素应该坚持使用可交付成果。也就是名词的形式来进行分解。而不是使用基于活动的方式。</p></blockquote><img src="http://www.cnblogs.com/caidehui/aggbug/1749755.html?type=1" width="1" height="1" alt=""/><p><a href="http://www.cnblogs.com/caidehui/archive/2010/06/02/1749755.html" target="_blank">本文链接</a></p>http://www.cnblogs.com/caidehui/archive/2010/05/28/1746396.html关于好的WBSWBS是项目管理的核心元素，代表了项目要完成的工作。我们可以这么简单的看待有关项目的层次关系： 1.项目的目的。 2.项目要达到的目标。 3.为了达到目的与目标，我们应该做些什么。（工作） 4.我们应该什么时候做，要达到什么样的标准（做到什么程度），要花多少钱。 5.由谁去做？ 6.我们应该如何去做？ 7.会有什么风险与问题？应该如何应对？ 以上是项目计划的制定过程，从第3步开始，我们就是以一个东...2010-05-28T07:55:00Z2010-05-28T07:55:00Zcaidehuihttp://www.cnblogs.com/caidehui/WBS是项目管理的核心元素，代表了项目要完成的工作。我们可以这么简单的看待有关项目的层次关系： 1.项目的目的。 2.项目要达到的目标。 3.为了达到目的与目标，我们应该做些什么。（工作） 4.我们应该什么时候做，要达到什么样的标准（做到什么程度），要花多少钱。 5.由谁去做？ 6.我们应该如何去做？ 7.会有什么风险与问题？应该如何应对？ 以上是项目计划的制定过程，从第3步开始，我们就是以一个东...http://www.cnblogs.com/caidehui/archive/2010/05/28/1746393.html制订好的WBS的步骤WBS是交付成果导向的项目工作分解结构。那我们首先要寻找什么是我们的交付成果。这个问题使我想起了面向对象技术中的一个问题，那就是如何寻找类和对象。寻找类和对象的前提是，我们对系统进行了需求分析。根据需求分析的结果，1． 遍历需求有关文档2． 寻找所有的名词，形成候选的类与对象清单。3． 清理掉那些重复与无意义的候选者4． 确定剩下的类和对象之间的相互关系5． 将他们按照主题组织起来重复上面的过程，...2010-05-28T07:53:00Z2010-05-28T07:53:00Zcaidehuihttp://www.cnblogs.com/caidehui/WBS是交付成果导向的项目工作分解结构。那我们首先要寻找什么是我们的交付成果。这个问题使我想起了面向对象技术中的一个问题，那就是如何寻找类和对象。寻找类和对象的前提是，我们对系统进行了需求分析。根据需求分析的结果，1． 遍历需求有关文档2． 寻找所有的名词，形成候选的类与对象清单。3． 清理掉那些重复与无意义的候选者4． 确定剩下的类和对象之间的相互关系5． 将他们按照主题组织起来重复上面的过程，...http://www.cnblogs.com/caidehui/archive/2010/01/28/1658126.html重构还是结构，开创还是竞争－－面对战略的难题现在是一个战略的时代，对于每个企业，在完成了从创业到生存的阶段后，都想飞速发展壮大，为了飞速的发展壮大，他们需要有一个原则、指导方针来引导自己的企业前进。这个指导方针最好能够管个3年5年，在这个指导方针之下，对自己的企业进行改造－－流程重组、产品调整、管理变革、资源变换、人才改变。这个指导方针我们可以称为战略。 战略在中国历史上，战国时期就更为重要了，这决定了谁将获得最后的胜利，称为统一中国的霸主...2010-01-28T02:31:00Z2010-01-28T02:31:00Zcaidehuihttp://www.cnblogs.com/caidehui/现在是一个战略的时代，对于每个企业，在完成了从创业到生存的阶段后，都想飞速发展壮大，为了飞速的发展壮大，他们需要有一个原则、指导方针来引导自己的企业前进。这个指导方针最好能够管个3年5年，在这个指导方针之下，对自己的企业进行改造－－流程重组、产品调整、管理变革、资源变换、人才改变。这个指导方针我们可以称为战略。 战略在中国历史上，战国时期就更为重要了，这决定了谁将获得最后的胜利，称为统一中国的霸主...http://www.cnblogs.com/caidehui/archive/2010/01/20/1652079.html合同范围与需求分析后范围严重不符问题与分析做为软件开发商，每到需求分析结束的时候，我们就会有感叹，这个需求怎么和合同上的完全不一样呢？做为客户却不能理解，我们不是还是做1－2－3－4这四个事情嘛，有啥不一样的？ 为什么会出现这个问题，我想首先的问题就是，客户的需求是解决其业务问题，从大的方面来说假设分成1－2－3－4，这个一般没有问题，如果出了问题客户也能够同意进行调整。而做需求分析的时候除了业务问题以外，最主要加入进来的确实操作习惯，...2010-01-20T01:27:00Z2010-01-20T01:27:00Zcaidehuihttp://www.cnblogs.com/caidehui/做为软件开发商，每到需求分析结束的时候，我们就会有感叹，这个需求怎么和合同上的完全不一样呢？做为客户却不能理解，我们不是还是做1－2－3－4这四个事情嘛，有啥不一样的？ 为什么会出现这个问题，我想首先的问题就是，客户的需求是解决其业务问题，从大的方面来说假设分成1－2－3－4，这个一般没有问题，如果出了问题客户也能够同意进行调整。而做需求分析的时候除了业务问题以外，最主要加入进来的确实操作习惯，...