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