软技能-开发管理

• 提倡外科手术式的团队组织：
  在软件开发组织上的过份民主，往往带来的是没有效率和责任，参与其中的人想法太多，层面参差不齐。所以，软件开发的组织，应该借鉴外科手术式的团队方式，有一个主要的负责人，其他人都是分工协作的副手，这样效率最好，结果最好。
  也就是说软件项目的核心概念要由很少的人来完成，以保证概念的完整性。少就是多，项目的定位需要和功能多少的权衡。太多的想法，使项目没有焦点，什么都要放进去，结果什么都做不象；

• 项目所需人手：
  项目的时间依赖于顺序上的限制，人员的最大数量依赖于独立子任务的数量；成本的确随开发产品的人数和时间的不同，有着很大的变化，进度却不是如此。因此我认为用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。它暗示着人员数量和时间是可以相互替换的。
  人数和时间的互换仅仅适用于以下情况：某个任务可以分解给参与人员，并且他们之间不需要相互的交流。这在割小麦或收获棉花的工作中是可行的；而在系统编程中近乎不可能

• 测试，测试后的开发量通常是原本开发量的3倍。

  • 当交给独立于项目之外的开发人员去做测试。写一个单元测试代码，集成测试的方法。
  • 给外部人员测提供一个更精妙的一种方法是**“文档化的bug”**。它声明当构件单元所有的缺陷已经被发现，但还没有完全被修复时，就已经做好了系统调试的准备。在系统测试期间，根据该理论，测试人员知道这些缺陷造成的后果，从而可以忽略它们，将注意力集中在新出现的问题上。测试规格说明。在编写任何代码之前，规格说明必须提交给测试小组，以详细地检查说明的完整性和明确性。系统各个组成部分的开发者都会做出一些假设，而这些假设之间的不匹配，是大多数致命和难以察觉的bug的主要来源。

• 交流和组织的技能需要管理者仔细考虑，相关经验的积累和能力的提高同软件技术本身一样重要。
• 项目规模本身很大，缺乏管理和沟通，以至于每个团队中的成员以为自己是争取小红花的学生，而不是构建软件系统中的成员，为了满足目标，每个人都在局部优化自己的程序，很少有人会停下来，考虑一下对客户的整体影响，对大型项目而言，这种导向和缺乏沟通是最大的危险，在整个实现的过程期间，系统结构师必须保持持续的警觉，确保连贯的系统完整性，在这种监督机制之外，是实现人员自身的态度问题，培养开发人员，从系统整体出发，面向用户的态度是软件编程，管理人员最重要的职能。
• 所有软件系统都应该以增量的方式开发，即，首先系统应该能够运行，即使未完成任何有用功能，只能正确调用一系列伪子系统。接着系统一点一点被充实，子系统轮流被开发，或者是在更低的层次调用程序，模块，子系统的占位符（伪程序）等。
• 开发的最终都是数据，细思考程序的数据，最终获得非常好的结果。
• 产品负责人和技术负责人是不同的。我们技术负责的通常会主导技术的开发，而产品的应该是需求的提出。技术主管作为总指挥，产品负责人充当其左右手：这是对小型团队最好的选择。
• 有关开发思路的转变。项目规模本身很大，缺乏管理和沟通，以至于每个团队成员认为自己是个争取小红花的学生，每个人都在局部优化自己的程序，很少有人会停下来，考虑一下对客户的整体影响。培养开发人员从系统整体出发，面向用户的态度是软件编程管理人员最重要的职能。
• 类编程 详见：设计模式 https://www.runoob.com/design-pattern/design-pattern-intro.html
• 有关演示的想法：每次我在临近演示都会因为紧张而肚子疼，但是我觉得演示的最终形态应该是。将最新的效果转换为行动。
• 成功管理的本质是每个人向同一个方向努力。
• 管理者应该赢得大家尊敬，成为一个导师角色最好了