刚接手了一个团队，接到通知需要在公司领导面前说一下自己的研发和管理思路，总结了这几年的思想，写了如下的记录；已经在公司领导前讲过了，得到了还不错的反馈。

1 做软件

原则：

模块原则：使用简洁的接口拼合简单的部件；

清晰原则：清晰胜于技巧；

简洁原则：设计要简洁，复杂度能低则低；

透明性原则：设计要可见，以便审查和调试；

健壮原则：健壮源于透明和简洁；

（摘自《The art of UNIX programming》 第1章哲学）

单一职责原则：单一职责：就是一个对象只做一件事。

OCP :开闭原则：对修改关闭；对扩展开放。

（面向对象5大原则）

注：这是被证明了的有效原则，是一个很好的研发参考，软件源于西方，很多我们的困惑外国人早就体验过，也找到了不错的解决办法，我们要做的就是多去看看经典的书籍，发现为我们所用的思想。 这些不是编出来的，是实践证明有效的。

重视设计

生命周期：产品设计，软件设计，软件实现，测试发布，维护，（后续开发，后续测试，后续维护)

重视设计：设计和用来表述设计的文档：

研发的设计文档包括什么？

1 设计方案：你打算怎么做来实现这个需求？

2 详细设计：具体描述实现之后软件的样子

  （例如界面由几部分组成？每一部分的细节是什么？软件要实现的功能点有那些？）

问：设计结束了吗？很多设计到这里结束了，开始编码，因为软件要实现要求已经说的很明白了。但是会存在一个问题，把这个文档交给不同经验的人去实现，软件的质量会差距很大，经验比较丰富的工程师质量会不错，bug会少，便于维护和后续开发；经验相对少的工程师实现的软件质量会难于把握，bug数量，维护和后续开发都难于把握。所以需要把具体实现的设计也仔细考虑。

3 实现设计：在目前的系统里，

            设计中包含了多少个功能点？

            实现这个功能需要写多少个类？

            这些类之间的关系和接口如何定义？

            新功能与系统的接口如何定义？

            每个实现类包含多少个方法？

            这些类实现后运行的效果是什么样的？

            哪些类实现了哪些功能点？（方法的注释）

            (表达方式：UML 类图和时序图，或者能明确表达设计者意思的图)

注：实现设计里面需要考虑的问题是早晚都要去思考的问题，很多人习惯写程序时再思考，想到哪里写道哪里，既然早晚都要思考这些问题，晚思考还带来难于把握的未来，好的解决办法是：没想好，别动手写。

4 项目核心人员确认，工程师完全理解设计意图，设计类和结构满足要求，工程师开始编码。

一切思路设计完成，实现只是很简单的工作。

好处：

1 程序实现是可控的，交给经验丰富和相对不丰富的工程师实现，软件的质量差距很小，整个软件看起来像是一个经验丰富的人写的；

2 把难点细分为若干简单的部分，每个部分的设计难度降低，实现难度降低，bug出现几率也降低；出现问题可以迅速定位问题；

3 大大增强代码的可读性和可维护性（后续的工程师可以很快进入角色，而不是到处去问，和猜测这段代码是做什么的）；

4 列出需要实现的功能列表（1 与需求和设计人员沟通方便 ， 2 自测使用，3 绩效统计参考）；

5 锻炼工程师抽象思维能力；

6 避免不清晰和复杂的程序结构，得到透明和简洁的程序；

实现设计谁来做？

根据个人能力会设计大小难度不同的模块来设计；SE和主管把关

谁来分解难点？

主管和SE，

注释和文档的作用：

软件的生命周期中时间最长的是维护周期，良好的文档和注释，更好的可读性和可维护性，软件的生命力在于别人去读和使用，很难懂的软件是缺乏生命力的软件，避免未来的重复工作。

文档的要求：

不必面面具到，要突出重点；

软件版本的交付：

响应变化，持续性的交付可以使用的软件版本，变瀑布式开发为敏捷开发；

（运气球游戏形象说明两种开发的特点）前边讲述的设计更贴近敏捷开发的设计思路；

如何添加新功能

OCP原则：对修改关闭；对扩展开放

为什么这么做？可以更好得隔离变化，自测和测试组测试都很方便；只测变化和与变化相关的地方即可；经过多轮测试的软件是好的软件，如果不加控制去修改和添加，造成整个软件安全系数降低，测试人员前期的工作就浪费了，增加了整体的工作量。

2 团队建设

管理的发展方向，更开放,更透明

主管的责任：

1：帮助大家顺利优质的完成工作；

2：优秀的团队思想得以执行；

3：提高团队成员的能力；

4：打造一个使团队成员的知识和能力得到最大的发挥的环境；

团队成员的责任：

对自己做的工作心理有底；就是在你心里对自己做的东西有清晰的认识，

心理有底是有什么：

就是有长时间的技术和心理积累下来的东西，用两个词可以概括：经验和信心，归纳为一个词：能力；

能力是如何积累的

每天的工作当中，在工作的同时你也在做另一件事：积累自己的能力；

为什么大家每天同样工作能力的增长却有差异？

因为每个人的工作的方法和态度有很大不同，方法和态度是能力是否增长很重要的因素；

什么方法是有效的方法：就软件开发角度：以上说过的就是被实践证明很有效的，比较合适的，可以增长能力的方法；

什么态度是很好的态度？

如何面对困难：

其实工作会经常遇到大大小小的困难，对待困难的态度就很重要，什么是正确的态度？

（Martin Flower的例子，面对一个很臃肿的系统，重新改写了之后变得高效和易扩展，而且还写了一本java的经典《重构》，成为很有名的大师级人物）

总结，把困难变成发展的机遇，让自己更强；

战胜困难带给人什么？

变的更强，强者的好处是什么？在生活上选择很多；困难是变强的机会；

坦诚的面对自己的错误

每个人都会犯错，不回避自己的错误，坦率的面对自己的错误是很好的态度；不再犯相同类型错误的人是很厉害的人；

关注点在事情上面

      关注点在事情上面，多阐述自己对事情的看法，而不是对人的看法；我们会讨论什么是好什么是坏，而不是讨论谁好谁坏；

80/20效率法则

接到任务之后，先审视以下，找到重点的部分，先完成重点，不要胡子眉毛一把抓，从重要的事情开始做；

（推荐 重要紧急象限图）

保证每天大部分时间处理的是“重要 不紧急”的事情；

提倡的

1：不要抱怨；

2：多做事，不要怕犯错误，及时改正错误；

3：高效率，勤奋；

4：以简洁为美；

5：多去了解计算机的起源，发展和背后的文化；

6：要熟悉面向对象的思想；多去看看设计模式；

7:  空杯与海面心态；

8：持续的进步；

9：工作中发挥自己的优点；

10：沟通的时候抓住重点；

11：有困难找你的主管；

用什么考核员工的绩效

目标：团队成员重视自己的贡献；

1：有效的工作量（做了多少事，无效的工作主管有义务去纠正）

2：做了什么都会被记录（放在大家都可以查看的地方），工作量是排名很重要的依据；

3：经验不多，目前不能做太难的怎么办？ 多解决简单的问题也能体现自己的工作能力，因为想要获得能力的质变，一定的量变积累是非常必要的。

（设计的时候就会估计工作量，真正开发完成会核对估计的工作量，这个工作量是代码的行数；）

个人在团队中的位置:

每个人在企业中会最终找到属于自己的位置, 位置和能力和贡献关系密切。

备注：

1：80/20效率法则：

20％的人占有80％的社会财富；（帕累托）

     “在因和果、努力和收获之间，普遍存在着不平衡关系。典型的情况是：80％的收获来自20％的努力；其他 80％的力气只带来20％的结果。”（里查德•科克）

    目前中国是不到10％的占有80％的社会财富（文国庆）；

2: 空杯与海面心态

一进公司就要忘记自己从那里来，名校只代表过去，不要念念不忘。进来就要从头学习，倒完水，成为空杯，以海绵的心态虚心学习。公司每周开周会，学习相互经验，从错误中吸取教训。用自己的错误学习是一种方式，代价很大，更要用别人的错误学习。（BENQ曾文琪）

3：运气球游戏

国外公司（ThoughtWorks）在让员工体会 瀑布式开发和敏捷开发不同时的一个游戏；从屋子的一端将气球搬运到另一端，每一组有两个人在一端负责装运，两个人另一端负责撑袋子，一个人负责搬运，哪一组能在最短的时间内，

将最多的气球从一个口袋中运到另一侧的口袋中就算胜利，如果过程中任何气球掉在路途中，则不可拾取。第一次的规则是只能运一次，整个过程给人的感觉就是搬运的人花了很多的时间，承担了过多的责任，而其他的四名队员起不到任何的作用，只能边喊边焦心的等待。

第二次的规则几乎与第一次一样，但搬运人可以多次的运输。

 结果第二次，团队不但出色的运输了所有的气球，而且还比第一次所花的时间更少。

 第一次运输就好比传统的瀑布式开发，开发人员承担了许多的压力，缺少沟通和其他人员必要的帮助，

闭门造车造出来的东西，往往并不是客户心目中想要的东西；

 而第二次运输就好比多次迭代的开发过程，开发人员得到更多的信息回馈以及业务分析员和测试人员的帮助，

因此能够开发出更好的软件产品。      

4 马丁.福勒（Martin Flower）

ThoughtWorks首席科学家的马丁-福勒先生是当今世界软件开发领域最具影响力的五位大师之一。敏捷软件开发方法的早期开拓者；知名的作家、软件顾问兼演讲大师，他凭借16年丰富的经验帮助各企业将前沿技术应用于关键业务信息系统中；他大力倡导业内最先进的软件开发技术，如统一建模语言UML(Unified Modeling Language)、极限编程XP(Extreme Programming)、重构 (Refactoring) 与分析模式 (Analysis Patterns) 等

5：埃里克•雷蒙德（Eric Raymond）

    自由软件运动的倡导者和理论家

    2004年时，出版了《Unix 编程艺术》（The Art Of Unix Programming），本书主要介绍了Unix系统领域中的设计和开发哲学、思想文化体系、原则与经验，包括Unix设计者Ken Thompson在内的多位领域专家也为本书贡献了宝贵的内容 。

参考资料：

《敏捷软件开发 原则模式和实践》 Robert C.Martin 2003

《Unix编程艺术》 Eric S. Raymond 2006

《帕累托80/20效率法则》

研发团队管理