注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

秒大刀 博客

好好学习 天天向上

 
 
 

日志

 
 
 
 

读《软件开发经济学》  

2011-08-19 12:45:26|  分类: 读书 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
读《软件开发经济学》 - 秒大刀 - 秒大刀的城堡
描述很理论化,看的人想睡觉。有点像政治课本,看起来没劲。
标题党,没有看到太多关于“经济学”的知识,而更多是在蹩脚的为迭代开发做“广告”。
最后的“附录A 迭代式项目管理起步”写的还行。
——感谢CSDN赠书一读

正文之前
  1. 如果你执着于出发前设计好的那份严格的计划,那么游览的质量肯定会受到损害
  2. 良好的经济性意味着有效的管理有限的资源以获得最优结果
  3. 你不能管理你不能度量的东西
第一部分 软件驱动的经济
第1章 软件项目管理的挑战
  1. 我们应当从一开始就把软件和用来创建软件的过程看作是业务价值链中不可或缺的一部分。真正被集成到公司商业过程中的软件可以改变和提升整个运作
  2. 这个世界不会自己实现在数字化方面的潜力,除非软件系统的能力在今天的计算机硬件和网络条件下提高到一个新水平
  3. 新的软件开发方法与那些较传统的方法之间最主要的差别:新方法代表的是迭代式的增量开发的实践,而旧方法代表的是瀑布式的开发实践
  4. 软件项目中不确定的项目要素:
    • 问题。用户真正想要或需要的是什么
    • 解决方案。用什么样的架构和技术组合最合适
    • 计划。成本和时间上的约束、团队组成、利益相关人的沟通、理想的阶段等等
  5. 通过在项目开始时旷日持久的需求收集工作来建立精确的需求只会延迟我们在构建系统时更全面的理解那些在前期植入的真正问题——架构级的重大问题
  6. 对于大多数利益相关人来说,在看到一个能用的东西之前,他们并不真正指导自己想要的是什么
  7. 如果项目经理们只关注于其专业化团队及其成员的活动,而不关心结果,那么软件项目通常就会失败。达成结果比完成过程中的活动更重要。结果可以分阶段的达成,通过可工作的软件可以在最终系统完成之前很早就展示这些阶段性成果
  8. 在构建系统之前全面理解真正的问题,才能发现和解决“架构级的重大问题”
第2章 达成结果:软件经济学的案例
  1. 不确定性是软件项目本质所固有的
  2. 在开发团队对问题理解得不透的情况下,要求设计有很高的精确度只会适得其反
  3. 按照进度和预算交付创新成果需要迭代式的生命周期、始终如一的风险管理、客观的监督和一种“引领”式的领导艺术,这种领导艺术要能够唤起团队上下的创造力,无论团队是大还是小
  4. 基于结果的软件开发的十大原则:
    1. 使用架构优先的方式
    2. 及早应对风险
    3. 建立一个变更管理的环境
    4. 通过协作环境来增强变更的自由
    5. 使用严格的基于模型的标记法来设计软件
    6. 以客观的质量控制为目标编制过程文件
    7. 采用基于演示的方法进行进度和质量的中间性评估
    8. 根据详细程度的演进来制定发布计划
    9. 建立一个具备伸缩性的可配置过程
  5. 成功的软件开发过程的最突出的特点就是明确定义了“研发”活动和“生产”活动之间的区别
  6. 应该像考虑电影的摄制那样考虑软件项目
第二部分 提高软件开发的经济效益
第3章 软件经济学的趋势
  1. 几乎没有项目能够表现得比预期更好
  2. 工作量和规模之间所表现出的是非规模经济(随着规模变大增加成本费用)。与大多数制造过程的规模经济相反,你所构造软件的规模越大,单位成本就越高。应该尽可能降低项目的规模和复杂度
  3. 降低要开发的软件的规模或者复杂度
  4. 理解业务需求,仅交付对于满足需求绝对必不可少的那些需求,一次来降低开发的代码量
  5. 评估低效率的区域和无效率的区域,并改进相应区域的习惯做法
  6. 通过高层次的自动化来提高人员生产力
  7. 消除认为错误的来源
  8. 先解决风险,然后通过自动化来降低人为错误
第4章 降低软件项目的规模或者复杂度
  1. 降低完成一个软件解决方案所需人工编写的代码的规模和复杂度
  2. 某些需求的实现可能并不会产生与其所用工作量成比例的价值,另外一些需求则可能十分有价值
第5章 改进开发的过程
  1. 最小化管理性活动对于人员和进度安排的影响
  2. 进程改进是否能产生深远影响,关键在于是否将传统的(瀑布式)工作方式转变为现在的迭代式的工作方式
  3. 在被证实设计“清白”之前,设计是“有罪”的:在达到延时的目标之前,项目不会向下一步继续进行
  4. 20%的需求消耗了80%的工程工作。不要在时机未成熟时就努力追求整个需求集的高精度和完全可追溯性。相反,在为全面开发提供资源之前,要尽量理解起驱动作用的需求
  5. 20%的组件消耗了80%的软件成本。应优先细化那些对成本影响大的组件,以便能在生命周期的早期就透彻的理解成本驱动因素的计划和控制
  6. 20%的组件导致了80%的错误。应优先细化那些对可靠性影响大的组件,以便于评估活动有足够的时间来达到必要的成熟度
  7. 20%的变更导致了80%的软件废品和返工。应优先细化那些对变更敏感的组件,以便在项目灵活性很大时进行那些影响广泛的变更
  8. 20%的组件消耗了80%的资源(执行时间、磁盘空间、内存)。应优先细化那些对性能影响大的组件,以便尽量在生命周期的早期完成对于可靠性、可变性和成本效益的工程性权衡
  9. 20%的人完成了80%的工作。要确保制定项目计划和设计架构的那个最初团队是一支高质量的团队,将合格的计划和架构交给一个平庸的构建团队也能取得成功。但如果是一个不合格的设计或者架构,即便是交给一个专家级的构建团队,也有可能不会取得成功
  10. 过程改进的首要目标:在最小化与非生产性活动相关的管理开销的同时改进结果
  11. 过程改进最重要的特征:
    1. 使用迭代式的过程
    2. 优先应对重大的风险
    3. 逐步改进团队的软件工程实践
第6章 提高团队效率
  1. 几乎每个成功的软件项目和软件组织,他们都强有力的保证做到了配置一个规模最小但最有能力的团队。大多数遇到了麻烦的项目所配备的人数都多于需要
  2. 成功的团队关注的是获得结果,根据获得结果的需要可以放松角色的正规度和过程的严格性
  3. 管理者必须培养一种团队协作和追求结果的文化,而不是一种推崇个人成就的文化
  4. 高效团队的协作比个人的技能和努力更重要
  5. 管理得当的项目即便使用工程技能一般的人员也能取得成功
  6. 管理不当的项目即使使用由专家组成的工程团队也不可能成功
  7. 由技能一般的软件开发人员组成的团队能够完成一个架构很好的系统的开发工作
  8. 即使团队成员都是专家级的开发人员,想要完成一个架构很差的系统也只能是一番苦苦挣扎
  9. 最好使用团队的性能曲线来度量组织级能力,而不要用关键过程域的检查单、过程审计之类的东西
  10. 对于每一次工程冒险来说,真正的产品是智慧财产。因此其中占支配地位的生产力要素应该是人员技能、团队协作和激励机制
  11. 提高个人绩效、改进项目的团队协作和提高组织级能力是获得更高的团队总体效率的三个重要目标
  12. 一个关注于结果而不是注重遵循过程的团队可以以较小的规模实现更强的能力
  13. 要为每个有天分的人找到最佳的位置
  14. 增量式的提高组织级能力是团队效率和项目性能的一个更真实的度量,它比检查单和过程审计更能揭示真相
第7章 通过集成工具来提高自动化
  1. 采用自动化的方式或者使用集成工具来改进自动化的方式,从而提高某些步骤的效率
  2. 标准化工具的重要性随着软件开发组织的规模的增长而增长
  3. 与使用手工方式相比,高效的使用工具和自动化能够为软件工程减少20%~40%的工作量
第8章 通过常识来加速文化的改变
  1. 软件行业的记录是四分之三的项目没有成功。项目经理和组织往往会“进行防守”,而这样做通常的结果是过分强调文档跟踪,以便于在失败时能够提供证据证明自己没有做错什么。那些真正在改进自己的软件经济效果方面取得了巨大成就的组织都展示了审慎的风险管理和聪慧的成功管理,他们采取的是进攻的方式,以一种有进取心并且平衡的方式来对付复杂度、过程、团队和工具这四个维度的风险
  2. 在转而使用新技巧和新技术的过程中,总工会有对失败的恐惧和忧虑。人们通常认为维持原有状态和依赖现有方法是最安全的方法。在软件产业中,维持原有状态不总是安全的
  3. 重大的组织变更依赖于最优秀的员工和坚定的中层经理
  4. 成功的软件管理是一项艰苦的工作
  5. 低中级管理者是关键的执行者
  6. 如果经理既不编写计划,也不是计划的负责人,那么就预示着项目将遇到麻烦
  7. 需求、设计和计划要可变并且具体
  8. 鼓励进行雄心勃勃的演示
  9. 在生命周期的早期进行演示的目的是揭示设计瑕疵,不是为了装点门面
  10. 利益相关人不应容忍团队在解决问题时缺乏坚持到底的精神。如果不能满怀热情的解决消极趋势,那么到了后期他们就会造成严重的混乱。执着的坚持到底的精神是解决问题所必要的
  11. 项目性能的好坏在生命周期的早期更明显
  12. 实际的项目经验一次有一次的向我们展示:项目的早期阶段决定了项目的成败
  13. 一定要用一个绝对合格的创办团队来完成早期的计划和架构活动
  14. 几乎每个成功的项目在生命周期的早期都能客观的洞悉性能上的问题。这是一个设计不成熟的信号,也是一个设计过程成熟的信号
  15. 详细完整的工件在早期不太重要,在后期比较重要
  16. 真正的问题会系统化的出现,也应系统化的加以解决
  17. 选择正确的项目、正确的人、正确的目标
  18. 成功的组织都是用最重要的项目和最有才能的人员,给他们充足的资源,并且要求他们得到一个更好的结果
第三部分 软件工程的使用度量
  1. 在很多时候,你不能直接度量你想要真正了解的东西
  2. 人们会注意哪些被度量的东西,并且想当然的认为那些被度量的东西很重要。即便是在度量与奖励没有直接关联的情况下,人们也会设法在那些他们觉得会被度量的方面提高自己的绩效
第9章 实用的软件开发度量观
  1. 度量工作会给人们一个这样的暗示:“被度量的东西是重要的东西”,而软件开发团队也会从这些度量工作中寻找一些线索,以了解“什么是重要的事情”。对于这些信心,软件开发人员会做出自己的诠释,而且通常也会据此改变自己的行为,以便于交付一些他们认为做度量工作的人想要的东西。要消除度量工作这种不期而至的后果,最好的方法是彻底弄清“要度量什么”和“为什么度量它”这两个问题。这需要你完全弄明白“项目的目标是什么”和“度量与项目目标有什么关系”
  2. 预测是件很困难的事,尤其是关于未来的预测
  3. 从统计的角度看,项目的结果是随机变量,而目标是对此随机变量期望值的一种估计
  4. 先搞明白项目应该在哪里结束,然后在整个项目中都灵活的引领项目团队向着这一目标不断前进
  5. 创建并努力完成一个在项目早期就制定好的详细计划是错误的:
    1. 确定项目活动并对项目技术工作进行实践分配需要有足够的技术深度,而期望项目经理具有这样的技术深度是不现实的
    2. 项目早期的具体行为方式具有很高的不确定性,因此即使是由开发团队所创建的详细计划也只是推测
    3. 根据项目早期制定的详细计划进行度量非常危险,常常会使项目注定要失败
  6. 任何仅由项目经理完成的“计划”充其量也就是一次推测
  7. 项目早期的特点是缺少关于“需要解决什么问题”和“需要达到什么样的目标”的可靠信息,在这种缺少信息的情况下指定详细的计划完全就是浪费时间
  8. 让人们负责有瑕疵的错误计划,会打击人们根据所获得的信息采取正确行动的积极性
  9. 早期制定详细计划所鼓励的是错误行为
  10. 迭代给软件开发带来的主要好处之一是:它做了一些有意识到工作,能使误差随着项目的进展逐步降低
  11. 在健康的项目中,风险会随着时间的推移而被逐步消除,偏差也会逐步变小,因此项目也会向着一个成功的结果发展。在不健康的项目中,计划变成了一种关于“成功可能会是什么样”的预测。而管理层的重点也从计划转移到了度量偏差,而不是引领项目向着成功的结果前进。如果管理制度对脱离计划的行为进行惩罚,那么在没有遵循计划的时候,团队成员往往只能创造一种他们在遵循计划的假象。
第10章 在起始阶段度量什么
  1. 起始阶段的目标:
    •  明确并规避业务、项目以及资金上的风险
    • 评估项目的可行性,包括技术和财务两方面
    • 就项目的范畴和目的达成一致
    • 为后续工作形成一个整体计划
  2. 很快就能得到的收益要比未来才能得到的收益有价值得多
  3. 决定不对项目进行投资也是起始阶段的一个完全可以接受的成果。只要这一决策是基于将要交付的商业价值和技术上的可行性而做出的,就不要把这种结果看作是一种失败。实际上,如果这一决策能够将资源放给其他更有价值的项目,那么决定不对项目进一步投资可能是一个最好的结果
  4. 起始阶段的结果决定了是否要对项目进行投资,这一结果必须是从收益和项目成本两方面测算得出的——只有这样才能对“项目是否该继续进行”做出一个理由充分的决定。如果利益相关人不能一致同意对于时间和成本的估计都是可靠的,那么可能最好是放弃这一项目而把注意力转到更有价值的工作上
  5. 对于估计值来说,应该问的最有价值的问题不是“它是否精确”,而是“这些值的变动范围可能有多大”
  6. 通常以“净现值(NPV)的最差情况是否在一个可接受的范围内”为基础才能决定“项目是否应该继续进行”
第11章 在细化阶段和构造阶段度量什么
  1. 在经历了一系列迭代之后不能规避风险,这就说明必须对于工作方式进行重大修改
  2. 只有在成功通过测试之后才能将一项工作记为已完成工作
  3. 团队仅在完成某场景的开发工作时不能记为完成:
    1. 会夸大项目进展,那些被记为已完成事项的任务实际上可能会因测试而被要求返工
    2. 会掩盖项目可能没有配备足够的人员来完成测试工作的事实
  4. 需要随开发的进行而进行测试,测试是唯一一种能使你真正了解自己是否完成了某件事的方法。测试总能发现一些需要完成的事情,所以如果不能保持测试工作的同步跟进,你就会落后
  5. 已完成场景的测试覆盖率必须达到100%
  6. 不要把交付阶段变成一个可以把backlog继续做完的“扫尾”阶段。在部署应用方面有足够多的工作需要我们来做,但场景的实现不在其中
  7. 细化阶段往往是探索性的,配备的是一个关注于探索解决方案中的技术风险的较小的团队。度量工作必须关注的是技术风险是否在降低
  8. 迭代式项目的团队应该频繁的进行构建。如果构建常常失败,那么你可能走得不会像你想象的那么远
第12章 在交付阶段度量什么
  1. 在到了交付阶段以后,绝对不要再实现什么新特性或新场景。如果这么做,那么你完全就是自欺欺人的相信自己已经走出了构造阶段。在交付阶段中,唯一的关注点应该是让解决方案做好部署的准备,然后就实际的去完成这一部署
  2. 不要关注于追究责任,要关注需要做什么才能使下一个项目变得更好
  3. 大多数问题都是系统化的问题,在根本原因得到解决之前问题会不断的重复出现
  4. 我们每个人都需要从成功和失败中学习,因此不要把错误藏着
  5. 要从经验中学习知识并与其他人交流,这样其他项目团队也能从你的经验中获益
第13章 在嵌入规则的项目中度量什么
附录A 迭代式项目管理起步
  1. 期望的结局不会自己跑出来。人们必须去发现它们,相信它们,促进并执行它们
  2. 只有理解了目标,才能将目标分解成行动,而你和你的团队才能采取这些行动
  3. 如果没有紧迫感,对于改变的渴求就不会很强烈,以至于不能克服对改变的阻力。人们会变得满足于现状,让他们改变很困难,除非他们感觉这种改变能使他们从中受益
  4. 在改变的早期阶段,只有很少人会感到需要改变。只要改变不大,影响的只是少数人,那么就可以推进这一改变了
  5. 选择正确的项目和正确的团队成员很重要
  6. 在前几个迭代中,要将项目保持在较小的规模上,之后再展开
  7. 目标越是精确,越是可以度量,也就越容易达到
  8. 愿景传达的失败是改变工作失败的关键因素
  9. 如果你试图做的改变太多太快,就会失去稳定性,并且使事情变得更糟
  10. 大多数人对于改变的步伐都有自己能够承受的阈值——如果将改变推动更快一点,所有努力就会都化为乌有
  11. 如果改变过大,人们可能会对改变能否成功失去希望,因而放弃改变
  12. “我们承认改变不可避免,而我们采用的正是一种承认改变不可避免的工作方式。我们会为我们的进展设定目标,我们会针对这些目标对自己进行度量我们还将根据新的信息来改变我们的工作方式,而不是假设自己在项目一开始就掌握了所有问题的答案,你知道这也是不可能的”
  13. “我们会在早期(在我们还能对风险做点什么的时候)关注那些较大的风险,并且采取一些明确的行动来降低这些风险。如果我们的初次尝试不起作用,我们将一直关注这些风险,直到把他们解决掉为止”
  14. “我们将关注于在一个商定的时间段内交付出业务真正需要的最重要的东西,但不是交付出他们想要的所有东西。对于我们过去的工作方式来说,这是一个重要的改变”
  15. 对于迭代的渴望一般都来自于开发团队内部
  16. 无论项目看起来有多大,都要时刻记住下面几点:
    • 在开始时要假设项目很小。如果启动一个大项目,他就会一直是个大项目,而一般来说,项目越大,其失败的可能性也越大
    • 尽你所能将项目保持在较小的规模上。如果不努力使事情保持“不变大”,那么事情自然就会变大
    • 对计划进行分层,保持这些计划的简洁性及各自的关注点。若想要计划容易被人理解,就要让计划短小。要利用迭代式项目所固有的层次划分来避免在为工作编制计划时追求那种没必要的精确性
  17. 你需要确保首次迭代有一个适度的目标:不论你做什么,都不要设置一个大胆的近乎荒谬的目标,这会让你和你的团队最终走向失败
  18. 在迭代中要时刻注意进展情况,并且准备好在迭代中期就削减此次迭代的目标,从而保证有时间对结果进行评估
  19. 要为了遵守迭代的时间限制而把某些内容从当前迭代移动到下一次迭代中
  20. 对于能得到什么,你不要设定一个不切实际的语气。迭代开发未必比传统开发更快,但你能更确定的在可接受的时间范围内交付出正确的结果。
  21. 迭代式开发最大的作用之一是它为持续的过程改进提供了一个平台
  22. 迭代开发的基础思想在于:将项目管理的关注点从“创建详细的计划并根据这些计划对活动进行度量”提升到面向结果的项目管理。应将注意力关注在“为每次迭代设定正确的目标上,然后根据这些目标对成果进行度量”
  23. 学习的5个阶段:
    1. 知识——概念和事实等基础知识
    2. 理解——能够展示对于概念的理解
    3. 应用——能将概念应用到一些简单的情形中的能力
    4. 评价——对于“在较复杂的情形中何时以及如何应用概念”能够进行评价的能力
    5. 创新——将概念扩展到新情境中的能力
  24. 人们不喜欢改变,但如果他们能够看到改变所产生的积极成果,他们就会改变。改变工作通常必须能使大多数利益相关人获得积极成果,这才算得上是成功的。积极的结果出现的越快,对于改变的支持力也形成的更快
  25. 即便是积极的改变,在改变之初也是有破坏性的,在极少数更糟糕的情况下,改变所导致的不稳定还不仅仅出现在最初的阶段。在改变行动中始终都一直展示成果是维护改变动力的不可缺少的环节
  26. 只有改变了人们的日常习惯,才算进行了真正的改变;而只有通过时间和实践才能改变习惯
  27. 在引入新工作方式时,支持知识传递和新想法应用很重要。研讨会是一种能够提供这种支持的有效方式,因为它使人们能够在做真正工作的情况下学习,它们也能加快人们高效使用新技术的速度
  28. 在任何改变过程中都会产生挫折,而团队恢复力使得团队成员能够从这些不可避免的挫折中恢复过来
  29. 利用体验性学习,教练使团队能够关注于“执行”而不是过程的定义
  评论这张
 
阅读(1064)| 评论(0)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017