什么是年费法 年费法（Annual cost method)是通过计算、比较“年费”的方法来比较选择设备投资方案的方法。适用于难于单独计算投资收益的设备投资。年费法的计算 “年费”可用下式计算： 其中： I——设备初期投资费 i——年利率 C——设备每年维持费 n——设备使用年限(经济寿命) CI——年总费用 “年数”是考虑了资金时间价值的年均支出费用。年费高低，表示从成本的角度考虑不同方案之优劣。年费法的步骤 ①计算设备寿命周期总费用； ②依设备寿命周期，换算成相当于每年费用； ③进行比较、分析、选择最优设备。相关条目投资回收期法现值法
什么是平均报酬率 平均报酬率（简记为ARR）是投资项目寿命周期内平均的年投资报酬率，也称平均投资报酬率。 平均报酬率是用投资项目寿命周期内的年平均现金流入量取代年平均会计利润，用初始投资额取代平均投资额。 为了解决平均会计利润率指标存在着的问题（指标用会计利润取代现金流量，其经济意义存在着明显的失真。），人们引入了平均报酬率指标(Average Rate of Return)。平均报酬率的计算公式 其计算公式为： 采用平均报酬率指标虽然解决了以会计利润取代现金流量的问题，但并没有解决第一，第二两个问题。即： 第一，平均会计利润率指标没有考虑资金的时间价值，将不同时期发生的会计利润给予同等的价值权重。 第二，平均会计利润率指标的取舍标准是人为确定的，缺乏可靠的科学依据。平均报酬率的优缺点 平均报酬率的优点是简明、易算、易懂。其主要缺点是没有考虑资金的时间价值，第一年的现金流量与最后一年的现金流量被看作具有相同的价值，所以，有时会作出错误的决策。
平均会计利润率的计算 平均会计利润率是投资项目经济寿命期内的平均税后利润与平均投资额之比。即： 式中：AAR—平均会计利润率 I—初始投资额 S—投资项目的残值 在进行投资决策时，需要确定一个企业要求达到的平均会计利润率的最低标准，然后将有关投资项目所能达到的平均会计利润率与这一标准比较。如果超出这——最低标准，则该投资项目是可取的；如果达不到这一标准，则应放弃该投资项目。在有多个投资项目的互斥选择中，则选择平均会计利润率最高的项目。平均会计利润率的优点与不足 以平均收益率作为投资决策指标具有简明易懂，计算简单的优点，但这一指标同时也存在着一些明显的问题，主要表现在以下几个方面： 第一，这一指标没有考虑资金的时间价值，将不同时期发生的会计利润给予同等的价值权重。 第二，这一指标的取舍标准是人为确定的，缺乏可靠的科学依据。 第三，这一指标用会计利润取代现金流量，其经济意义存在着明显的失真。
什么是差额投资内部收益率法 差额投资内部收益率法又称“差额投资内含报酬率法”，是指在计算出两个原始投资额不相等的投资项目的差量现金净流量的基础上，计算出差额内部报酬率，并据以判断这两个投资项目孰优孰劣的方法。 采用此法时，当差额内含报酬率指标大于或等于基准收益率或设定贴现率时，原始投资额大的项目较优；反之，则投资少的项目为优。差额内含报酬率与内含报酬率的计算过程一样，只是所依据的是差量现金净流量。 该方法适用于原始投资不相同但项目计算期相同的多个互斥方案的比较决策，不能用于项目计算期不同的方案的比较决策。">编辑] 差额投资内部收益率法举例说明 某企业有两个可供选择的投资项目的差量净现金流量，如表1所示。 表1 投资项目差量净现金流量表 单位：万元 假设行业基准贴现率为10％。要求就以下两种不相关情况选择投资项目：该企业的行业基准贴现率i为8％；该企业的行业基准贴现率i为12％。 根据所给资料可知，差量现金净流量(甲项目的现金净流量－乙项目的现金净流量)如下： △NCF0=－100万元，△NCF1 − 5=26.70万元， （P/A，△IRR，5）＝1 000 000/267 000＝3.7453 △NPV指差额净现值；△IRR指差额内含报酬率。用试误法可求得，甲乙两方案的差量内含报酬率△IRR＝10.49％在第(1)种情况下，由于差量内含报酬率大于8％，所以应该选择甲项目。在第(2)种情况下，由于差量内含报酬率小于12％，所以应该选择乙项目。 参考文献 ↑ 1.0 1.1 1.2 张阳华.《现代企业财务》.复旦大学出版社,2002-04
什么是时间—成本平衡法 时间—成本平衡法是一种用最低的相关成本的增加来缩短项目工期的方法。该方法基于以下假设： 1）每项活动有两组工期和成本估计：正常时间（normal time）是指在正常条件下完成某项活动需要的估计时间。应急时间（crash time）是指完成某项活动的最短估计时间。 正常成本（normal cost）是指在正常时间内完成某项活动的预计成本。 应急成本（crash cost）是指在应急时间内完成某项活动的预计成本。 2）一项活动的工期可以被大大地缩短，从正常时间减至应急时间，这要靠投入更多的资源来实现。 3）无论对一项活动投入多少额外的资源，也不可能在比应急时间短的时间内完成这项活动。 4）当需要将活动的预计工期从正常时间缩短至应急时间时，必须有足够的资源作保证。 5）在活动的正常点和应急点之间，时间和成本的关系是线性的。 时间—成本平衡法的运用 缩短工期的单位时间成本可用如下公式计算： 1)如果仅考虑正常工期估计。 2）如果全部活动均在它们各自的应急时间内完成。 3）用时间—成本平衡法压缩那些使总成本增加最少的活动的工期，确定项目最短完成时间。 为了将项目的工期从18周减至17周，首先必须找出关键路径C－D。然后，才能确定关键路径上哪项活动能以最低的每周成本被加速。 再次将项目工期缩短1周，从16周降至15周。有两条关键路径。为了将项目总工期从16周减至15周，必须将每个路径都加速1周。 从15周降至14周。有两条相同的关键路径。必须将两条路径同时加速1周。 项目总工期减少l周，项目总成本将增加5000美元；项目工期减少2周，项目总成本将增加l1000美元；项目工期减少3周，项目总成本将增加23000美元。
数据包络线（DEA） 企业管理者如何评估一所快餐分销店、银行支行、健康诊所或初等学校的生产力？衡量生产力有三重困难：第一，什么是系统适当的投入（如劳动力时间、材料金额）及其度量方法？第二，什么是系统适当的产出（如现金支票、存款凭证）及其度量方法？第三，正确衡量这些投入产出之间关系的方法是什么？ 1. 衡量服务生产力 从工程学角度看，衡量组织的生产力和衡量系统的效率相似。它可以表述为产出和投入的比率。 例如，再评估一个银行支行的运营效率时，可以用一个会计比率，如每笔出纳交易的成本。相对于其他支行，一个支行的比率较高，则可以认为其效率较低，但是较高的比率可能是源于一个更复杂的交易组合。运用简单比率的问题就在于产出组合没有明确。关于投入组合，也能作出同样的评论。广泛基础上的指标，如赢利性和投资回报，和全面绩效评估高度相关。但它们不足以评估一个服务单位的运营效率。比如，你不能得到以下的结论：一个赢利的支行必定在雇员和其他投入的使用上是有效的。赢利性业务的比率高于平均水平比资源运用的成本效率更能解释其赢利性。 2. DEA模型 目前，开发出一种技术，通过明确地考虑多种投入（即资源）的运用和多种产出（即服务）的产生，它能够用来比较提供相似服务的多个服务单位之间的效率，这项技术被称为数据包络线分析（DEA）。它避开了计算每项服务的标准成本，因为它可以把多种投入和多种产出转化为效率比率的分子和分母，而不需要转换成相同的货币单位。因此，用DEA衡量效率可以清晰地说明投入和产出的组合，从而，它比一套经营比率或利润指标更具有综合性并且更值得信赖。 DEA是一个线形规划模型，表示为产出对投入的比率。通过对一个特定单位的效率和一组提供相同服务的类似单位的绩效的比较，它试图使服务单位的效率最大化。在这个过程中，获得100%效率的一些单位被称为相对有效率单位，而另外的效率评分低于100%的单位本称为无效率单位。 这样，企业管理者就能运用DEA来比较一组服务单位，识别相对无效率单位，衡量无效率的严重性，并通过对无效率和有效率单位的比较，发现降低无效率的方法。 DEA线形规划模型建立如下： 1) 定义变量设Ek（k=1，2，……， K）为第k个单位的效率比率，这里K代表评估单位的总数。设uj（j=1，2，……， M）为第j种产出的系数，这里M代表所考虑的产出种类的总数。变量uj用来衡量产出价值降低一个单位所带来的相对的效率下降。设vI（I=1，2，……，N）为第I种投入的系数，这里N代表所考虑的投入种类的综合素。变量vI用来衡量投入价值降低一个单位带来的相对的效率下降。设Ojk为一定时期内由第k个服务单位所创造的第j种产出的观察到的单位的数量。设Iik为一定时期内由第k个服务单位所使用的第i种投入的实际的单位的数量。 2) 目标函数 目标是找出一组伴随每种产出的系数u和一组伴随每种投入的系数ν，从而给被评估的服务单位最高的可能效率。 （*） 式中，e是被评估单位的代码。这个函数满足这样一个约束条件，当同一组投入和产出的系数（uj和vi）用于所有其他对比服务单位时，没有一个服务单位将超过100%的效率或超过1.0的比率。 3) 约束条件 （**） k=1,2,……,K 式中所有系数值都是正的且非零。 为了用标准线性规划软件求解这个有分数的线性规划，需要进行变形。要注意，目标函数和所有约束条件都是比率而不是线性函数。通过把所评估单位的投入人为地调整为总和1.0，这样等式（*）的目标函数可以重新表述为： 满足以下约束条件： 对于个服务单位，等式（**）的约束条件可类似转化为： k=1,2,…,K 式中 uj≥0 j=1，2，…，M vi≥0 i=1，2，…，N 关于服务单位的样本数量问题是由在分析种比较所挑选的投入和产出变量的数量所决定的。下列关系式把分析中所使用的服务单位数量K和所考虑的投入种类数N与产出种类数M联系出来，它是基于实证发现和DEA实践的经验：
敏捷开发概述 敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。">编辑]敏捷开发的路线 图：敏捷开发的路线图 Test-Driven Development，测试驱动开发。 它是敏捷开发的最重要的部分。在ThoughtWorks，我们实现任何一个功能都是从测试开始，首先对业务需求进行分析，分解为一个一个的Story，记录在Story Card上。然后两个人同时坐在电脑前面，一个人依照Story，从业务需求的角度来编写测试代码，另一个人看着他并且进行思考，如果有不同的意见就会提出来进行讨论，直到达成共识，这样写出来的测试代码就真实反映了业务功能需求。接着由另一个人控制键盘，编写该测试代码的实现。如果没有测试代码，就不能编写功能的实现代码。先写测试代码，能够让开发人员明确目标，就是让测试通过。 Continuous Integration，持续集成。 在以往的软件开发过程中，集成是一件很痛苦的事情，通常很长时间才会做一次集成，这样的话，会引发很多问题，比如 build未通过或者单元测试失败。敏捷开发中提倡持续集成，一天之内集成十几次甚至几十次，如此频繁的集成能尽量减少冲突，由于集成很频繁，每一次集成的改变也很少，即使集成失败也容易定位错误。一次集成要做哪些事情呢？它至少包括：获得所有源代码、编译源代码、运行所有测试，包括单元测试、功能测试等；确认编译和测试是否通过，最后发送报告。当然也会做一些其它的任务，比如说代码分析、测试覆盖率分析等等。在我们公司里，开发人员的桌上有一个火山灯用来标志集成的状态，如果是黄灯，表示正在集成；如果是绿灯，表示上一次集成通过，开发人员在这时候获得的代码是可用而可靠的；如果显示为红灯，就要小心了，上一次集成未通过，需要尽快定位失败原因从而让灯变绿。在持续集成上，我们公司使用的是自己开发的产品CruiseControl。 Refactoring，重构。 相信大家对它都很熟悉了，有很多很多的书用来介绍重构，最著名的是Martin的《重构》，Joshua的《从重构到模式》等。重构是在不改变系统外部行为下，对内部结构进行整理优化，使得代码尽量简单、优美、可扩展。在以往开发中，通常是在有需求过来，现在的系统架构不容易实现，从而对原有系统进行重构；或者在开发过程中有剩余时间了，对现在代码进行重构整理。但是在敏捷开发中，重构贯穿于整个开发流程，每一次开发者check in代码之前，都要对所写代码进行重构，让代码达到clean code that works。值得注意的是，在重构时，每一次改变要尽可能小，用单元测试来保证重构是否引起冲突，并且不只是对实现代码进行重构，如果测试代码中有重复，也要对它进行重构。 Pair-Programming，结对编程。 在敏捷开发中，做任何事情都是Pair的，包括分析、写测试、写实现代码或者重构。Pair做事有很多好处，两个人在一起探讨很容易产生思想的火花，也不容易走上偏路。在我们公司，还有很多事都是Pair来做，比如Pair学习，Pair翻译，Pair做PPT，关于这个话题，钱钱同学有一篇很有名的文章对它进行介绍，名为Pair Programming (结对编程)。 Stand up，站立会议。 每天早上，项目组的所有成员都会站立进行一次会议，由于是站立的，所以时间不会很长，一般来说是15-20分钟。会议的内容并不是需求分析、任务分配等，而是每个人都回答三个问题：1. 你昨天做了什么？2. 你今天要做什么？ 3. 你遇到了哪些困难？站立会议让团队进行交流，彼此相互熟悉工作内容，如果有人曾经遇到过和你类似的问题，那么在站立会议后，他就会和你进行讨论。 Frequent Releases，小版本发布。 在敏捷开发中，不会出现这种情况，拿到需求以后就闭门造车，直到最后才将产品交付给客户，而是尽量多的产品发布，一般以周、月为单位。这样，客户每隔一段时间就会拿到发布的产品进行试用，而我们可以从客户那得到更多的反馈来改进产品。正因为发布频繁，每一个版本新增的功能简单，不需要复杂的设计，这样文档和设计就在很大程度上简化了。又因为简单设计，没有复杂的架构，所以客户有新的需求或者需求进行变动，也能很快的适应。 Minimal documentation，较少的文档。 其实敏捷开发中并不是没有文档，而是有大量的文档，即测试。这些测试代码真实的反应了客户的需求以及系统API 的用法，如果有新人加入团队，最快的熟悉项目的方法就是给他看测试代码，而比一边看着文档一边进行debug要高效。如果用书面文档或者注释，某天代码变化了，需要对这些文档进行更新。一旦忘记更新文档，就会出现代码和文档不匹配的情况，这更加会让人迷惑。而在敏捷中并不会出现，因为只有测试变化了，代码才会变化，测试是真实反应代码的。这时有人会问：代码不写注释行吗？一般来说好的代码不是需要大量的注释吗？其实简单可读的代码才是好的代码，既然简单可读了，别人一看就能够看懂，这时候根本不需要对代码进行任何注释。若你觉得这段代码不加注释的话别人可能看不懂，就表示设计还不够简单，需要对它进行重构。 Collaborative Focus，以合作为中心，表现为代码共享。 在敏捷开发中，代码是归团队所有而不是哪些模块的代码属于哪些人，每个人都有权利获得系统任何一部分的代码然后修改它，如果有人看到某些代码不爽的话，那他能够对这部分代码重构而不需要征求代码作者的同意，很可能也不知道是谁写的这部分代码。这样每个人都能熟悉系统的代码，即使团队的人员变动，也没有风险。 Customer Engagement ，现场客户。 敏捷开发中，客户是与开发团队一起工作的，团队到客户现场进行开发或者邀请客户到团队公司里来开发。如果开发过程中有什么问题或者产品经过一个迭代后，能够以最快速度得到客户的反馈。 Automated Testing ，自动化测试。 为了减小人力或者重复劳动，所有的测试包括单元测试、功能测试或集成测试等都是自动化的，这对QA人员提出了更高的要求。他们要熟悉开发语言、自动化测试工具，能够编写自动化测试脚本或者用工具录制。我们公司在自动化测试上做了大量的工作，包括Selenium开源项目。 Adaptive Planning，可调整计划。 敏捷开发中计划是可调整的，并不是像以往的开发过程中，需求分析->概要设计->详细设计->开发 ->测试->交付，每一个阶段都是有计划的进行，一个阶段结束便开始下一个阶段。而敏捷开发中只有一次一次的迭代，小版本的发布，根据客户反馈随时作出相应的调整和变化。 敏捷开发过程与传统的开发过程有很大不同，在这过程中，团队是有激情有活力的，能够适应更大的变化，做出更高质量的软件。敏捷开发的特点 敏捷方法主要有两个特点，这也是其区别于其他方法，尤其是重型方法的最主要特征: （1）敏捷开发方法是“适应性”(Adaptive)而非“预设性” (Predictive)。 这里说的预设性，可以通过一般性工程项目的做法理解，比如土木工程，在这类工程实践中，有比较稳定的需求，同时建设项目的要求也相对固定，所以此类项目通常非常强调施工前的设计规划。只要图纸设计得合理并考虑充分，施工队伍可以完全遵照图纸顺利建造，并且可以很方便地把图纸划分为许多更小的部分交给不同的施工人员分别完成。 然而，在软件开发的项目中，这些稳定的因素却很难寻求。软件的设计难处在于软件需求的不稳定，从而导致软件过程的不可预测。但是传统的控制项目模式都是试图对一个软件开发项目在很长的时间跨度内做出详细的计划，然后依计划进行开发。所以，这类方法在不可预测的环境下，很难适应变化，甚至是拒绝变化。 与之相反的敏捷方法则是欢迎变化，目的就是成为适应变化的过程，甚至能允许改变自身来适应变化。所以称之为适应性方法。 （2）敏捷开发方法是“面向人” (people oriented)而非“面向过程”(process oriented)。 Matin Flower认为：“在敏捷开发过程中，人是第一位的，过程是第二位的。所以就个人来说，应该可以从各种不同的过程中找到真正适合自己的过程。”这与软件工程理论提倡的先过程后人正好相反。 (续致信网上一页内容) 在传统的软件开发工作中，项目团队分配工作的重点是明确角色的定义，以个人的能力去适应角色，而角色的定义就是为了保证过程的实施，即个人以资源的方式被分配给角色，同时，资源是可以替代的，而角色不可以替代。 然而，传统软件开发的这些方法在敏捷开发方式中被完全颠覆。敏捷开发试图使软件开发工作能够利用人的特点，充分发挥人的创造能力。 敏捷开发的目的是建立起一个项目团队全员参与到软件开发中，包括设定软件开发流程的管理人员，只有这样软件开发流程才有可接受性。同时敏捷开发要求研发人员独立自主在技术上进行决策，因为他们是最了解什么技术是需要和不需要的。再者，敏捷开发特别重视项目团队中的信息交流，有调查显示：“项目失败的原因最终都可追溯到信息没有及时准确地传递到应该接受它的人。” 敏捷开发的价值观 实际上敏捷开发运动在数年前就开始了，但它正式开始的标志是2001年2月的“敏捷宣言”（Agile Manifesto），这项宣言是由17位当时称之为“轻量级方法学家”所编写签署的，他们的价值观是：个人与交互重于开发过程与工具；可用的软件重于复杂的文档；寻求客户的合作重于对合同的谈判；对变化的响应重于始终遵循固定的计划。 个人与交互重于开发过程与工具的原因：一个由优秀的人员组成但使用普通的工具，要比使用优秀的工具但由普通人组成、紊乱的小组做得更好。多年来人们花了很多时间试图建立一种过程，以便把人当作机器上的一个可以替代的齿轮，但结果却并不成功。敏捷过程是承认每个人都有特定的能力（以及缺点）对之加以利用，而不是把所有的人当成一样来看待。更重要的是，在这样的理念下，几个项目做下来，每个人的能力都从中得以提高。这种人的能力的提高，对公司是无价之宝。而不至于把人当成齿轮，随着时间的推移，人的能力慢慢被消耗掉，最后变成留之无用、弃之可惜的尴尬人物。 可用的软件重于复杂的文档的原因:可用的软件可以帮助开发人员在每次迭代结束的时候，获得一个稳定的、逐渐增强的版本。从而允许项目尽早开始，并且更为频繁的收集对产品和开发过程的反馈。随着每次迭代完成软件的增长，以保证开发小组始终是处理最有价值的功能，而且这些功能可以满足用户的期待。 寻求客户的合作重于对合同的谈判的原因:敏捷开发小组希望与项目有关的所有团体都在朝共同方向努力，合同谈判有时会在一开始就使小组和客户出于争执中。敏捷开发追求的是要么大家一起赢，要么大家一起输。换句话说，就是希望开发小组和客户在面对项目的时候，以一种合作的态度共同向目标前进。当然，合同是必需的，但是如何起草条款，往往影响到不同的团体是进行合作式的还是对抗式的努力。 对变化的响应重于始终遵循固定的计划的原因：敏捷开发认为对变化进行响应的价值重于始终遵循固定的计划。他们最终的焦点是向用户交付尽可能多的价值。除了最简单的项目以外，用户不可能知道他们所需要的所有功能的每个细节。不可避免地在过程中会产生新的想法，也许今天看起来是必需的功能，明天就会觉得不那么重要了。随着小组获得更多的知识和经验，他们的进展速度会比开始的时候期望值慢或者快。对敏捷开发来说，一个计划是从某个角度对未来的看法，而具有多个不同的角度看问题是有可能的。项目的敏捷开发方法 敏捷方法很多,包括 Scrum、极限编程、功能驱动开发以及统一过程（RUP）等多种法，这些方法本质实际上是一样的，敏捷开发小组主要的工作方式可以归纳为：作为一个整体工作； 按短迭代周期工作； 每次迭代交付一些成果； 关注业务优先级； 检查与调整。下图是典型的敏捷过程总图，下面介绍其有关的特点。 1、敏捷小组作为一个整体工作 项目取得成功的关键在于，所有项目参与者都把自己看成朝向一个共同目标前进的团队的一员。“扔过去不管”的心理不是属于敏捷开发。设计师和架构师不会把程序设计“扔”给编码人员；编码人员也不会把只经过部分测试的代码“扔”给测试人员，一个成功的敏捷开发小组应该具有“我们一起参与其中的思想”， “帮助他人完成目标”这个理念是敏捷开发的根本管理文化。当然，尽管强调一个整体，小组中应该有一定的角色分配，各种敏捷开发方法角色的起名方案可能不同，但愿则基本上是一样的。第一个角色是产品所有者，他的主要职责包括：确认小组成员都在追求一个共同的目标前景；确定功能的优先等级，以便总是处理最有价值的功能；作出可以使项目的投入产生良好回报的决定。产品所有者通常是公司的市场部门或者产品管理部门的人员，在开发内部使用的软件的时候，产品所有者可能是用户、用户的上级、分析师，也可能是为项目提供资金的人。 2、敏捷小组按短迭代周期工作 在敏捷项目中，总体上并没有什么上游阶段、下游阶段，你可以根据需要定义开发过程在初始阶段可以有一个简短的分析、建模、设计，但只要项目真正开始，每次迭代都会做同样的工作（分析、设计、编码、测试。等等）。迭代是受时间框限制的，也就是说即使放弃一些功能，也必须结束迭代。时间框一般很短，大部分是 2～4周，在 Scrum中采用的是 30个日历天，也就是 4 周。迭代的时间长度一般是固定的，但也有报告说，有的小组在迭代开始的时候选择合适的时间长度。 3、敏捷小组每次迭代交付一些成果 比选择特定迭代长度更重要的，是开发小组在一次迭代中要把一个以上的不太精确的需求声明，经过分析、设计、编码、测试，变成可交付的软件（称之为功能增量）。当然并不需要把每次迭代的结果交付给用户，但目标是可以交付，这就意味着每次迭代都会增加一些小功能，但增加的每个功能都要达到发布质量。每次迭代结束的时候让产品达到可交付状态十分重要，但这并不意味着要完成发布的全部工作，因为迭代的结果并不是真正发布产品。假定一个小组需要在发布产品之前对软硬件进行为期两个月的“平均无故障时间”（MTBF）测试，他们不可能缩短这两个月的时间，但这个小组仍然是按照 4 周迭代，除了MTBF测试，其它都达到了发布状态。 4、敏捷小组关注业务优先级 敏捷开发小组从两个方面显示出他们对业务优先级的关注。首先，他们按照产品所有者制定的顺序交付功能，而产品所有者一般会按照组织在项目上的投资回报最大化的方式来确定优先级，并且把它组织到产品发布中去。要达到这个目的，需要综合考虑开发小组的能力，以及所需功能的优先级来建立发布计划。在编写功能的时候，需要使工能的依赖性最小化。如果开发一个功能必须依赖其它 3 个功能，那产品所有者这就很难确定功能优先级。功能完全没有依赖是不太可能的，但把功能依赖性控制在最低程度还是相当可行的。 5、敏捷小组检查与调整 任何项目开始的时候所建立的计划，仅仅是一个当前的猜测。有很多事情可以让这样的计划失效：项目成员的增减，某种技术比预期的更好或更差，用户改变了想法，竞争者迫使我们做出不同的反应，等等。对此，敏捷小组不是害怕这种变化，而是把这种变化看成使最终软件更好地反映实际需要的一个机会。每次新迭代开始，敏捷小组都会结合上一次迭代中获得新知识做出相应调整。如果认为一些因素可能会影响计划的准确性，也可能更改计划。比如发现某项工作比预计的更耗费时间，可能就会调整进展速度。也许，用户看到交付的产品后改变了想法，这就产生反馈，比如他发现他更希望有另一项功能，或者某个功能并不像先前看得那么重。通过先期发布增加更多的用户希望的功能，或者减少某些低价值功能，就可以增加产品的价值。迭代开发是在变与不变中寻求平衡，在迭代开始的时候寻求变，而在迭代开发期间不能改变，以期集中精力完成已经确定的工作。由于一次迭代的时间并不长，所以就使稳定性和易变性得到很好的平衡。在两次迭代期间改变优先级甚至功能本身，对于项目投资最大化是有益处的。从这个观点来看，迭代周期的长度选择就比较重要了，因为两次迭代之间是提供变更的机会，周期太长，变更机会就可能失去；周期太短，会发生频繁变更，而且分析、设计、编码、测试这些工作都不容易做到位。综合考虑，对于一个复杂项目，迭代周期选择4周还是有道理的。 MIT Sloan Management Review（麻省理工学院项目管理评论）所刊载的一篇为时两年对成功软件项目的研究报告，报告指出了软件项目获得成功的共同因素，排在首位的是迭代开发，而不是瀑布过程。其它的因素是： 1、至少每天把新代码合并到整个系统，并且通过测试，对设计变更做出快速反应。 2、开发团队具备运作多个产品的工作经验。 3、很早就致力于构建和提供内聚的架构。 从这个报告中所透露出的信息告诉我们，认真研究敏捷过程对软件项目的成功是非常有意义的，它的意义在于： 1）给开发小组的自组织提供了机会 经典项目管理就好比一个具备中央调度服务的航空管理系统，这个系统是自治的，而且是封闭的，但现实中更庞大的系统，似乎并不属于中央调度控制系统，但也同样也是有效的。假如我们开车到某个地方，我们可以任意选择所需要的路线，我们甚至不需要准确计算停车，只要我们遵守交通法规，驾驶员可以临时根据路况改变某个转弯点，在驾驶游戏规则的框架内，依照自身最大利益做出决策。成千上万的驾驶者，并不需要中央控制和调度服务，人们仅仅在简单的交通法规的框架内，就可以完成综合起来看是更庞大的目标，很多事情从管理的角度只要抓住关键点，并不需要多么复杂的规则，往往会更有效。随着系统复杂度的提高，中央控制和调度系统面临崩溃。仔细研究交通系统的特点，我们会发现这样的系统中独立的个体在一组适当的规则下运行，并不需要设计每个个体临时变更的方案，而每个个体只需要知道目标和大致的状况，他们完全可以利用自己的聪明才智来决定自己的行为。 2）缩短了反馈通道 敏捷过程有效运作的另一个原因是，它极大的缩短了用户与开发者、预测目标与实施状况、投资与回报之间的反馈回路。在面对不断变化的市场、业务过程以及不断发展的技术状态的时候，便需要有一种方法在比较短的时间内发展完善。事实上，所有的过程改进都不同程度的使用着戴明循环，以研究问题、测试解决方案、评估结果，进而根据已知的事实来进行改进，这就称之为基于事实的决策模式，我们都知道，这比前端预测的决策方式更加有效。 3）易于集思广益 敏捷过程能有效应用的另一个原因在于，它可以就一个问题集思广益。我们的经验告诉我们当一个问题发生的时候，总有某些人员知道问题所在，但他的观点却遭到忽视。例如航天飞机在起飞阶段发生爆炸，事后分析出了各种原因，但这种调查也提供给我们一个惊人的事实，就是部分工程师早就意识到这些潜在问题，却无法说服他人重视这个担忧。对这些事实的深入思考，促使我们研究我们应该采取何种管理系统，使前线工作人员的经验、观点及担忧得到充分的重视呢？对敏捷开发的误解 误解一：敏捷对人的要求很高 很多人在尝试实施敏捷时说：敏捷对人的要求太高了，我们没有这样的条件，我们没有这样的人，因此我们没法敏捷。可是，敏捷对人的要求真的那么高么？软件归根到底还是一种创造性活动，开发人员的技术水平和个人能力对软件的质量还是起着决定性的作用，各种过程与方法只是帮助开发人员、测试人员等角色能够更好的合作，从而产生更高的生产力。不管用什么方法，开发人员的水平永远都是一个主要的因素。 从另一个角度来看：过程和方法究竟能帮开发人员多大忙？对于技术水平较低的开发人员，敏捷方法和传统方法对他的帮助是差不多的，因此看不到显着的效果，甚至有些时候还有反效果；而随着开发人员技术水平的提高，敏捷方法能够解开对人的束缚，鼓励创新，效果也会越来越显着。 敏捷对人的要求并不高，而且会帮助你培养各种所需的能力，当然前提是你处在真正敏捷的环境中。 误解二：敏捷没有文档，也不做设计 这个误解从XP开始就没有停止过，XP鼓励“在非到必要且意义重大时不写文档”。这里面提到的“必要且意义重大”是一个判断标准，并不是所有的文档都不写。例如，用户手册是不是“必要且意义重大”？这取决于客户的要求，如果客户不需要，那就不用写,如果客户需要，就一定要写；再如，架构设计文档要不要写？复杂要写，不复杂不用写。通常架构设计只需要比较简单的文档，对于有些项目，一幅简单的UML图就够了。因此，写不写，怎么写，都要根据这个文档到底有多大意义，产出和投入的比例，以及项目的具体情况决定。实际操作时可以让项目组所有人员表决决定，尽量避免由某一个人（比如lead）来决定。 至于设计，XP奉行的是持续设计，并不是不设计。这实际上是将设计工作分摊到了每天的日常工作中，不断的设计、改善（重构），使得设计一直保持灵活可靠。至于编码前的预先设计，Kent Beck等人确实实行着不做任何预先设计的开发方式，但是对于我们这些“非大师”级开发人员，必要的预先设计还是需要的，只是不要太多，不要太细，要有将来会彻底颠覆的准备。 误解三：敏捷好，其他方法不好 有些人一提到敏捷就大呼好，只要是敏捷的实践就什么都好，而提到CMMI等方法就大呼不好，不管是什么只要沾上边就哪里都不好，似乎敏捷和其他方法是完全对立的。牛顿说过，我是站在了巨人的肩膀上。敏捷同样也吸取了其他方法论的优点，也是站在了巨人的肩膀上，敏捷依然保持了很多历史悠久的实践和原则，只是表现方式不同罢了。 从另一个方面来看，方法本没有好环，好与坏取决于是否适合解决你的问题。每一种方法都有他最善于解决的问题和最佳的发挥环境，在需求稳定、软件复杂度相对不高的时代，瀑布模型也可以工作的很好，而敏捷恰好适用于变化快风险高的项目 － 这恰恰是现在很多项目的共性。 因此选择一个方法或过程，并不是根据它是否敏捷，而应根据它是否适合。而要了解一个东西是否适合，还是要尝试之后才知道，任何没有经过实践检验的东西都不可信。 误解四：敏捷就是XP（极限编程），就是Scrum XP 和Scrum只是众多敏捷方法中的两种，还有很多其他的敏捷方法。龙生九子各个不同，敏捷的这些方法看起来差别也是很大的，可是他们之所以被称为敏捷方法，就是因为他们背后的理念和原则都是相同的，这个原则就是《敏捷宣言》。学习敏捷不仅仅要学习实践，还要理解实践后的原则，不仅要理解怎么做，还要理解为什么这么做，以及什么时候不要这么做。 即使将XP或Scrum完全的应用的你的项目中，也未见得就能成功，适合别人的东西未必就适合你。敏捷的这些实践和方法给了我们一个起点，但绝对不是终点，最适合你的方式还要由你自己在实际工作中探索和寻找。 误解五：敏捷很好，因此我要制定标准，所有项目都要遵循着个标准 没有哪两个项目是一样的，客户是不一样的，人员是不一样的，需求是不一样的，甚至没有什么可能是一样的。不一样的环境和问题，用同样的方法解决，是不可能解决的好的。方法是为人服务的，应该为项目团队找到最适合他们的方法，而不是先确定方法，再让团队适应这个方法。因此也不存在适合所有项目的统一的方法。任何企图统一所有项目过程的方法都是不正确的。 同时，对于同一个团队，随着项目的进行，对需求理解的深入，对技术理解的深入，一开始适合项目的过程和方法也会渐渐的不适合。这时候也需要团队对过程进行及时的调整，保证项目的质量和效率。敏捷是动态的，而非静止不变的，因为这个世界本身就是变化的，在变化的世界使用不变的方法，是不现实的。银弹从来就没有过，在有限的将来也不会存在。参考文献↑ Bluse Huang's cnblogs
什么是敏感性分析法 敏感性分析法是指从众多不确定性因素中找出对投资项目经济效益指标有重要影响的敏感性因素，并分析、测算其对项目经济效益指标的影响程度和敏感性程度，进而判断项目承受风险能力的一种不确定性分析方法。 敏感性分析有助于确定哪些风险对项目具有最大的潜在影响。它把所有其他不确定因素保持在基准值的条件下，考察项目的每项要素的不确定性对目标产生多大程度的影响。 敏感性分析法的目的 1、找出影响项目经济效益变动的敏感性因素，分析敏感性因素变动的原因，并为进一步进行不确定性分析(如概率分析)提供依据； 2、研究不确定性因素变动如引起项目经济效益值变动的范围或极限值，分析判断项目承担风险的能力； 3、比较多方案的敏感性大小，以便在经济效益值相似的情况下，从中选出不敏感的投资方案。 根据不确定性因素每次变动数目的多少，敏感性分析可以分为单因素敏感性分析和多因素敏感性分析。">编辑] 敏感性分析法的分类 根据不确定性因素每次变动数目的多少，敏感性分析法可以分为单因素敏感性分析法和多因素敏感性分析法。 1、单因素敏感性分析法 每次只变动一个因素而其他因素保持不变时所做的敏感性分析法，称为单因素敏感性分析法。 例：（计算题）某公司规划项目的投资收益率为21.15%，财务基准收益率为12%。试对价格、投资在±20%，成本、产量在±10%范围进行敏感性分析。 解：价格变化±1%，投资收益率变化-0.67%～0.62%。其他如上。 单因素敏感性分析在计算特定不确定因素对项目经济效益影响时，须假定其它因素不变，实际上这种假定很难成立。可能会有两个或两个以上的不确定因素在同时变动，此时单因素敏感性分析就很难准确反映项目承担风险的状况，因此尚必须进行多因素敏感性分析。 2、多因素敏感性分析法 多因素敏感性分析法是指在假定其它不确定性因素不变条件下，计算分析两种或两种以上不确定性因素同时发生变动，对项目经济效益值的影响程度，确定敏感性因素及其极限值。多因素敏感性分析一般是在单因素敏感性分析基础进行，且分析的基本原理与单因素敏感性分析大体相同，但需要注意的是，多因素敏感性分析须进一步假定同时变动的几个因素都是相互独立的，且各因素发生变化的概率相同。 例:某项目投资170000元，寿命10年，残值20000元，基准利率为13%，预计现金流入和流出分别为35000元和3000元。试对现金流入和流出作双因素敏感性分析。 解：设x和y分别为年现金流入和流出的变化率，则净现值为： NPV =-170000(A/P,13%,10)+35000(1+x)-3000(1+y)+20000(A/F,13%,10) =-170000*0.184+35000(1+x)-3000(1+y)+20000*0.054 =1757+35000x-3000y 只要NPV＞0，即y<0.6+11.7x方案就可行。 敏感性分析法是一种动态不确定性分析，是项目评估中不可或缺的组成部分。它用以分析项目经济效益指标对各不确定性因素的敏感程度，找出敏感性因素及其最大变动幅度，据此判断项目承担风险的能力。但是，这种分析尚不能确定各种不确定性因素发生一定幅度的概率，因而其分析结论的准确性就会受到一定的影响。实际生活中，可能会出现这样的情形：敏感性分析找出的某个敏感性因素在未来发生不利变动的可能性很小，引起的项目风险不大；而另一因素在敏感性分析时表现出不太敏感，但其在未来发生不利变动的可能性却很大，进而会引起较大的项目风险。为了弥补敏感性分析的不足，在进行项目评估和决策时，尚须进一步作概率分析。 敏感性分析法的步骤 1、确定敏感性分析指标 敏感性分析的对象是具体的技术方案及其反映的经济效益。因此，技术方案的某些经济效益评价指标，例如息税前利润、投资回收期、投资收益率、净现值、内部收益率等，都可以作为敏感性分析指标。 2、计算该技术方案的目标值 一般将在正常状态下的经济效益评价指标数值，作为目标值。 3、选取不确定因素 在进行敏感性分析时，并不需要对所有的不确定因素都考虑和计算，而应视方案的具体情况选取几个变化可能性较大，并对经效益目标值影响作用较大的因素。例如：产品售价变动、产量规模变动、投资额变化等；或是建设期缩短，达产期延长等，这些都会对方案的经济效益大小产生影响。 4、计算不确定因素变动时对分析指标的影响程度 若进行单因素敏感性分析时，则要在固定其它因素的条件下，变动其中一个不确定因素；然后，再变动另一个因素（仍然保持其它因素不变），以此求出某个不确定因素本身对方案效益指标目标值的影响程度。 5、找出敏感因素，进行分析和采取措施，以提高技术方案的抗风险的能力。敏感性分析图表龙卷风图（Tornado diagram） 龙卷风图是项目管理中用于在风险识别和定性分析之后，进行定量风险分析的技术----敏感性分析技术中最常用的一种图表技术。 敏感性分析最常用的显示方式是龙卷风图。龙卷风图有助于比较具有较高不确定性的变量与相对稳定的变量之间的相对重要程度。它因其显示形式象龙卷风一样而得名。">编辑]敏感性分析在电网规划经济性评估中应用 (1)确定具体经济效益评价指标作为敏感性分析的对象 评价1个项目的经济效果指标有多个，如净现值、净年值、内部收益率、投资回收期等等。但对于某个具体的项目而言，没有必要对所有的指标都作敏感性分析，因为不同的项目有不同的特点和要求。选择的原则有2点: 1)敏感性分析的指标应与确定性分析的指标相一致; 2)确定性经济分析中所用指标比较多时，应选择最能够反映该项目经济效益、最能够反映该项目经济合理与否的1个或几个最重要的指标作为敏感性分析的对象。一般最常用的敏感性分析的指标是内部收益率和净现值等动态指标。本文采用净现值作为敏感性分析的指标。 (2)选择需要分析的不确定因素 影响电网规划方案经济性的不确定因素很多，严格说来，几乎所有影响到规划项目决策的因素都带有某种程度的不确定性，但事实上并不需要对所有的不确定因素都进行敏感性分析。因为，有些因素虽然具有不确定性，但对经济效益的影响很小。一般来说，可以遵循以下原则:找出那些在成本、收益构成中所占比重较大以及其他预计可能会对规划项目经济效果评价指标有较大影响的、同时又是在整个规划项目寿命周期内有可能发生较大变动或者在确定性分析中采用的该因素的数据准确性较差的因素，作为敏感性因素。 经过分析可知，一般对电网规划方案经济性影响较大的因素有:电价、固定资产投资以及电网运行成本等等。 (3)确定经济效果评价指标对各种敏感性因素的敏感程度 电网规划方案经济性对不确定因素的敏感程度可以表示为:某种因素或多种因素同时变化时，导致经济效果评价指标的变化程度。常用的计算方法是，假定除敏感性因素外，其他因素是固定不变的，然后根据敏感性因素的变动，重新计算有关的经济效果评价指标，与原指标值进行对比，得出变化的程度，这样即可得出该指标对该不确定因素的敏感程度。 (4)通过分析比较找出项目的最敏感因素 根据上一步的计算分析结果，对每种敏感性因素在同一变化幅度下引起的同一经济效果评价指标的不同变化幅度进行比较，选择其中导致变化幅度最大的因素，为最敏感因素;导致变化幅度最小的因素为不敏感因素。参考文献↑ 第三节 敏感性分析↑ 贺静 韦钢 张一尘 钱珞江.电网规划方案经济评估方法研究.《华东电力》.2004年7期
登录
工商服务
危机公关
金融律师
app开发
财税服务
金融牌照
网站建设
知识产权
企业征信
审计评估