大道至简 浏览摘摘

一、 编程的精义

程序  = 算法 + 结构

程序的实现：顺序、分支、循环


二、是懒人造就了方法

程序 = 算法 + 结构 + 方法（过程、OOP .......）

 
三、团队缺乏的不只是管理

做管理的起码需要能承担责任，这是最基本的素质

项目成功的评估：完成质量、完成时间（只能靠经验来评估了…真废话;）
难以评估？那么很多项目一开始就是死亡之旅?

体制（不可以破的窗口，一般都是管理者打破的，唉～）：先有组织，再有制度

犯了错误：是否拟定制度（管理者）——是否执行制度（执行者）——是否改之（员工素质）

组织你的团队~有没有角色(不管人也没人管)的角色吗？“枪毙” 了吧。嗯～记得发现一个团队的发现价值也别忘发现问题～（观察吧！）

分工～没有分工的组合是Group，分好工才是Team，弹性分工？明确分工？做管理≠做伯乐 还是明确分工比较妥当。

 
四、流于形式的沟通

沟通方式:第一小节。。客户不会C(咱们程序员)，难道就会UML（业务咨询员），实在看不懂~
UML完整吗？正确吗？你们都懂了吗？还是用客户熟悉的语言和方式吧～

最简沟通之计划：

1．在一个月中，只能跟客户作三次联系；

2.三次联系中，最多只能有一次面谈的机会；

3.一个月后，提交全部的需求调研报告、需求分析和关于该项目的远景规划

最简沟通之分析

开始在网络上查看相关的软件系统的特征以抽取客户所关注的内容；了解该客户的公司、经营理念、组织结构形式以及工作模式；了解同类公司的成功经验和优秀的管理模式，以及客户的竞争对手在做什么和在关心什么

1.    客户在公司层面的外在表现、内部机制和运营管理手段。

2.     客户在项目中既已明确的需求和可能发生的需求，以及客户围绕其公司行为(和方向)所提出的需求

最简沟通之任务

1.     分析用户的每一个表格，以构建基础数据库

2.     分析每一条数据的含义以确定它的上下限，以及数据间的相关性

3.     从工作文档中去了解客户的组织机构及其相互关系，同时确定了每一类使用该系统的角色

4.     从报表中去了解客户关注的数据信息，以及被他们所忽略掉的数据信息。

 
为不存在的角色留下沟通的渠道--以后项目维护者，恩，History

1.需求阶段：与谁联系，联系方式、过程、结果以及由此引发的需求或变更；

2.设计阶段：如何进行设计、最初的构架、各个阶段的框架变化、因需求变更导致项目结构上的变化(有助于了解构架的可扩充性)；

3.开发阶段：每一种技术选型的过程、每一种开发技巧的细节和相关文档、摘引的每一段代码、算法、开发包、组件库的出处和评测；程序单元的测试框架；每一个设计和构架变更所导致的影响；

4.测试阶段：还记得测试用例和测试报告吗？那是最好的history之一

 
还有，代码中的comment（注释），也别忘了留下日期和你的名字。

 
五、失败的过程也是过程

不管你用XP、RUP、RAD还是Waterfall Model，目的只是实现完成项目…不过看起来有点空洞～

 
六、 从编程到工程

语言只是工具，仅仅如此

经验来源于回顾、理解与分析，而不是你将要写的下一行代码。

 
七、  现实中的软件工程

了解这么多公司（IBM、SUM、Microsoft）的营业情况，还分析的不错～
 

关注项目的成本，很重要～

1.不计成本的项目计划不会得到经营者的支持；

2.毫无目的地消耗成本是项目中的慢性毒药；

3.最致命的风险是成本的枯竭

成本因素包括时间、人力、资金和客户成本，还有把客户的数量以及耐心。。。。

 
八、 是思考还是思想

软件工程三要素：工具、方法与过程

角色的关注层面完全不同，BOSS与开发者在坐标的位置上是最远的

 
矛盾：实现目标与保障质量

项目交付了，客户试用了，质量抱怨来了，投诉来了，于是：

需求人员会把所有的责任归咎到开发人员，而开发人员又不停地埋怨需求的不清不楚或者变更的没完没了。又如果正巧需求和开发都是同一个人或者小组来做的，那么他们便会开始埋怨客户的苛刻以及工期的紧张

而事实上可能真的出在源头：我们把目标定错了；项目的平衡三角(时间、资源和功能)中讨论的是目标问题，但并不讨论质量问题！