zoukankan      html  css  js  c++  java
  • 人月神话读后感2

    祸起萧墙(进度管理和监控的方法)
    慢性的进度偏离是士气杀手,这里核心思想就是要意识到进度滞后往往如温水煮青蛙一样让我们难以应付,最重要的就是要防微杜渐。重大灾害是比较容易处理的,它往往和重大的压力、彻底的重组、新技术的出现有关,整个项目组通常可以应付自如。 但是一天一天的进度落后是难以识别、不容易防范和难以弥补的。
    进取对于杰出的软件开发团队,同优秀的棒球队伍一样,是不可缺少的必要品德。 为了加强我们对进度的监控,里程碑的定义就至关重要了。里程碑的选择只有一个原则,那就是,里程碑必须是具体的、特定的、可度量的事件,能够进行清晰定义。以下是一些反面的例子,例如编码,在代码编写时间达到一半的时候就已经“90%完成”了;调试在大多时候都是“99%完成”的;“计划完毕”是任何人只要愿意,就可以声明的事件。
    里程碑有明显边界和没有歧义,比它容易被老板核实更为重要。如果里程碑定义得非常明确,以致于无法自欺欺人时,很少有人会就里程碑的进展弄虚作假。但是如果里程碑很模糊,老板就常常会得到一份与实际情况不符的报告。毕竟,没有人愿意承受坏消息。这种做法只是为了起到缓和的作用,并没有任何蓄意的欺骗。
    在进度跟踪和管理上,必须要在整个团队中树立这种观念,就是要尽可能早的完成相关的任务,而不是拖到了最后在来做。类似于关键链进度管理中始终强调的一个重点内容就是要压缩前面的开发周期而在项目后期预留缓冲。
    当进度出现偏差后,项目经理往往把问题掩盖起来,而且经常主观的认为可以通过各种赶进度的手段来挽回进度损失,但是往往情况并不是这么简单。因为很多时候 引起进度的偏差往往存在一些问题的根源,而这些根源往往是需要老板提前介入并采取一些行动,因此老板必须仔细区分状态报告、毫无惊慌地接收报告、决不越 俎代庖,将能鼓励诚实的汇报。

    没有银弹:没有任何技术或管理上的进展, 能够独立地许诺十年内使生产率、可靠性或简洁性获得数量级上的进步。现代软件系统中这些无法规避的内在特性:复杂度、一致性、可变性和不可见性。那么软件开发总是非常困难的。天生就没有银弹。没有神话般的解决方案, 以及将来也不会有。

    复杂性: 软件系统与计算机、建筑或者汽车大不相同,后者往往存在着大量重复的部分。由于软件产品特有的复杂度导致了成员之间的沟通非常困难,带来了软件产品的进度,质量和成本多方面的问题。特别是在软件规模增加的时候复杂度往往成倍上升。同时复杂度不仅仅导致技术上的困难,还引发了很多管理上的问题。它使全面理解问题变得困难,从而妨碍了概念上的完整性。(在软件产品开发工厂化的过程中,我们要注意到仍然解决的是次要因素,比如加大公用组件开发,加大平台和框架的建设,而业务功能本身导致的复杂性是无法避免的。)

    一致性:在某些情况下,因为是开发最新的软件,所以它必须遵循各种接口。另外一些情况下,软件的开发目标就是兼容性。在上述的所有情况中,很多复杂 性来自保持与其他接口的一致,对软件的任何再设计,都无法简化这些复杂的特性。

    可变性:系统中的软件包含了很多功能,而功能是最容易感受变更压力的部分。所有成功的软件都会发生变更。现实工作中,经常发生两种情况。当人们发现软件很有用时,会在原有应用范围的边界,或者在超越边界的情况下使用软件。功能扩展的压力主要来自那些喜欢基本功能,又对软件提出了很多新用法的用户们。简言之,软件产品扎根于文化的母体中,如各种应用、用户、自然及社会规律、计算机硬件等等。后者持续不断地变化着,这些变化无情地强迫着软件随之变化。(软件开发的过程必须要考虑如何适应变化,在需求,设计和编码过程中都需要考虑如何快速响应变化,如何提高软件产品的可扩展性。我们在软件开发生命周期模型上强调增量迭代的思路,强调测试驱动的思路其根本目的就是为了快速响应变化,降低变化带来的风险。)
    不可见性:除去软件结构上的限制和简化方面的进展,软件仍然保持着无法可视化的固有特性,从而剥夺了一些具有强大功能的概念工具的构造思路。这种缺憾不仅限制了个人的设计过程,也严重地阻碍了相互之间的交流。(我们推荐快速原型法仍然是为了进来去解决软件不可见性的问题。

    对没有银弹的感触转载http://blog.sina.com.cn/s/blog_493a84550100bhp9.html

    1.现在有很多快速开发平台,但是真正能够不写代码就完成业务功能的开发平台基本上没有成功的,特别是在业务场景比较复杂情况下,编程自动化基本是不可能的事情。唯一看到有所突破的是关于统一框架和技术平台等方面的建设,在原有的框架基础上我们来构建一个产品开发平台,将跟业务关系不大的权限模型,工作流引擎等集成进去,将常用的可复用组件集成进去,加快开发速度。
    2.不要在追求自动编程平台上下功夫,可以在加强组件复用和技术平台建设上下功夫。
    3.要多从开发模式的改进上来解决没有银弹所提出的各种实际问题,虽然不能够彻底解决,但是可以通过努力来改进。比如增量迭代的开发模型,快速原型法,测试驱动,高级语言和图形化编程等。

  • 相关阅读:
    [leetcode]687. Longest Univalue Path
    [leetcode]543. Diameter of Binary Tree二叉树的直径
    [LeetCode]Subtree of Another Tree判断一棵树是不是另一棵树的子树
    [leetcode]508. Most Frequent Subtree Sum二叉树中出现最多的值
    [leetcode]450. Delete Node in a BST二叉搜索树删除节点
    [LeetCode]652. Find Duplicate Subtrees找到重复树
    MySQL 数据库
    javaScript
    Css 笔记
    Html 笔记
  • 原文地址:https://www.cnblogs.com/hhw12345/p/14157610.html
Copyright © 2011-2022 走看看