软件工程之项目管理

一、项目启动流程规范

1、项目的可行性分析
政策可行性：政策准入、国家政策导向、国家及地方政策支持 以国外的网站为例：YouTube，Google等
市场可行性：项目市场空间调研、拟建项目产品市场预测、拟建项目市场定位、拟建项目产品市场竞争评估
技术可行性：现有技术能否达到产品要求
经济合理性：项目投资估算、项目融资分析、项目财务分析 例：云产品：SAE，BAE，阿里云
总的可以归纳一下，可行性分析六问：
1）项目实施是否和部门目标一致？（为什么花这个钱去做这个项目，有什么需要）
2）项目需要多长时间完成？
3）需要多少人力（团队人数）和硬件资源（服务器、网络）？
4）现有的人力（团队人数）和硬件资源（服务器、网络）是否满足？
5）项目方案实施是否有技术或业务瓶颈？
6）是否违背国家政策的导向？
2、项目文档的编写（只有足够详细的文档才能足够详细的了解项目的细节）

---

二、项目需求管理规范

 目的：
 需求管理的基本原则是在使用方和开发方之间建立对需求的共同理解，维护需求和工作成果的一致性，并控制需求的变更，主要目的如下：
1）保护当前开发不受用户频繁改动需求的干扰，而使进度受挫；
2）便于后期整理和汇总，代表开发业绩；
3）控制和维持需求的事先约定，保证项目开发过程的一致性；
4）建立需求基线，阶段需求，阶段实现，分步骤完成；

1、需求管理和分析的重要性
如果你认真分析每一个失败的项目，导致项目失败的原因都或多或少和项目的需求分析有关。
并且项目需求分析是“业务导向”的
作为项目经理，当你选择技术方案、制定项目规划、确定验收标准时，客户的“业务目标”远比“技术实现”重要的多。首先要搞明白的是为什么做，而不是怎么做。
业务角度例：为什么建立这样一个系统？我们目前遇到的主要业务问题是什么？希望通过这一系统解决那些业务问题？
技术角度例：（客户要建立一个xx系统）要实现那些功能？多少人同时使用？希望使用什么数据平台？IT架构是什么样的？
2、需求管理的流程
获取需求：主要了解使用方的意向。由使用方提交需求文档，双方对需求进行沟通。参与人员包括：开发方接口人，使用方接口人 获取需求文档参见《需求调研表》
需求确认：需求确认是指开发方和使用方共同对需求文档进行评审，双方需求达成共识后做出书面承诺，并确认需求基线 。需求确认人员：开发方负责人，使用方接口人
需求跟踪：需求跟踪是通过比较需求文档与后续工作成果之间的对应关系，实时跟踪，确保产品依据需求文档进行开发。需求跟踪人员：项目负责人
需求变更控制：
1）需求变更流程

2）需求变更应对对策


3）加强需求变更的控制

三、项目计划流程规范（web为例）

1、项目计划的必要性
项目计划本身是给“别人”看的，而且往往是给那些远没有你有经验的人看的。所以作为项目计划，一方面本身要细致、合理（通过争取更多的资源和时间），而且要让“别人”能用。从而保证接下来的工作能够合理有序的进行。
2、项目计划的前期准备工作
1）审定项目级别，发布项目章程，委派项目经理

2）组建项目团队，召开内部启动会议

3、制定项目计划

四、项目设计评审流程规范

目的：优化设计、发现错误、跟踪需求、质量评估、风险规避
1、评审流程
1）评审材料准备：项目组成员准备相关评审材料
2）预评审：预评审是项目组和各评审专家在评审会前的沟通。项目负责人将现有的方案同几位主要评审专家沟通，给各评审专家要留出充分的时间阅读评审材料，提出潜在问题和希望讨论的重点，并初步形成一致意见。
3）评审会议
项目负责人同评审专家进行会议沟通，由专家给予评定。
技术评审三个结论
A、通过：
没有遗留问题和只是一些没有解决风险可以很快解决的问题
B、有条件通过
遗留问题的解决存在一定风险，但不影响下一步活动的启动
C、不通过
遗留问题影响到下一步活动的启动，必须首先解决，然后再次进行技术评审
4）项目经理负责后续问题跟踪和处理，并记录在案
2、项目评审专家人员名单：各领域专家

五、项目实施阶段跟踪项目的进展情况

1、跟踪项目进展的重要性
项目经理做事要找到一种“节凑感”，不要被事情推着走，而是要自己推着项目往前走。
2、跟踪项目进展的讨论
（1）里程碑
对于数项目来讲，里程碑不是没有，而是不够重视。作为一种过程控制的手段，项目经理的观念应该是：没有过程，就没有结果
（2）量化的考核
所有的里程碑节点都对应某些交付，而这些交付必须是可以量化验收的，体现在项目的计划文档当中。这里存在一个普遍的误解，并不是说每一个里程碑都一定要正式验收，但每一个里程碑是否按时做完了，必须是清楚和没有歧义的，也就是说“可以验收”
（3）绩效体系
有时候项目经理会抱怨，很多该做的事（比如文档）没有人做。其实换一个角度想，如果没有影响的绩效体系，换成谁都不会做。针对项目工作的绩效体系必须是针对过程的（也就是里程碑），而不是只对项目结果。严格地说，项目经理的所有浮动收入（奖金），都必须和项目里程碑的完成有一定的关系。
3、控制项目进展的一些具体措施
项目leader在项目实施过程中，应根据收集的信息了解项目进展，及时发现偏差和问题，并及时采取纠正或预防措施；同时项目经理应以收集的信息为依据，向关键项目关系人定期发布项目执行状况报告。
我们在团队内部传递信息的渠道主要有：
1）定期项目内部报告
建议每周四下班前，整理项目周报，并发送给项目关系人
2）项目例会
项目例会的目的是了解项目执行状况，协调执行过程中出现的矛盾，随时发现偏差并及时采取纠正措施，已保证项目能够按照计划顺利完成。项目例会建议每周定期举行，并发送会议纪要。
3）面谈
面谈是一种很随意的方式，可以在办公区、走廊间、吸烟间进行，面谈不仅是一种直接获取信息的方式，同时是一种增加了解、释放抱怨的渠道。
4）项目管理系统
通过项目管理系统自动报表了解项目进展状况。我们使用的就是todo这个系统

六、项目实施阶段的管理项目执行状况

1、项目管理执行状况的一些措施
（1）管理项目范围
（2）管理项目进度
（3）管理项目的质量
（4）管理项目的人力资源
（5）管理项目成本

七、项目实施阶段管理项目风险和问题

可能发生还没发生的为“风险”，已经发生的为“问题”。
1、将项目的风险控制具体落实

八、项目实施阶段管理和控制项目变更

1、项目变更的原因
2、怎样去控制项目的变更
3、业务需求方的变更

九、项目实施阶段 项目沟通管理

1、项目沟通管理的重要性
2、项目沟通的主要内容
3、编制项目报告和管理项目验收

十、项目实施阶段项目的过程控制

1、项目的控制过程的定义
控制的重点：范围变更、质量标准、状态报告以及风险应对
2、项目控制过程的方法
盯住细节的是，工程师；盯住结果的是，老板；盯住过程的是，项目经理。
结果靠过程，对于项目来说，里程碑就是最有效的过程控制手段。
验收节点带来的压力属于“硬性”压力，没有回旋空间，但“里程碑节点”有时是软性的，不属于“燃眉之急”。但忽视项目里程碑的项目，则是一个将压力积累，将风险做实的过程。
所以我们可以这样去做：
在计划过程：合理规划里程节点，使其有可行性，有验收价值
在执行过程：围绕每一个里程碑安排工作，找到项目“节奏”
在沟通过程：将里程碑的压力传递给项目中的每一个人
这里强调：当其他人不重视里程碑节点的时候，你必须重视，而且要用最高的音量、最大的影响力，要求别人像你一样重视。
这是一个重要的项目控制手段。

十一、项目实施阶段 项目计划中的资源冲突

1、什么叫做项目的资源冲突
2、项目资源冲突的几种模式
3、解决的策略和建议

十二、项目实施阶段 web页面制作流程规范

1、代码统一规范的重要性
遵循代码规范的好处：
（1）降低出错概率
（2）加强代码的可读性
（3）提升团队合作意识
2、页面的基本结构
3、IE6的降级说明
4、浏览器的兼容要求
各产品页面必须严格兼容IE6及以上、Firefox3.0及以上、Safart3.0及以上、chrome1.0及以上、Opera10及以上浏览器，兼容指保证页面在要求各浏览器下效果与功能一致。
所有页面在以上浏览器下不得出现源代码、乱码；所有页面在各浏览器默认设置下必须正常显示，不得出现折行、重叠、不能对齐、页面混乱等现象。
独立产品的浏览器兼容性由各自产品线自行定义。
5、文件目录规范
使用SVN进行文件管理和版本控制
在同一目录下的文件数建议不得超过1000个。
静态目录名只能有[a-z,0-9-_]字符组成，禁止包含汉字、空格等非法字符。不能使用大写字母。
Html文件需根据页面功能进行命名，可使用英文。
6、css文件规范
除特殊要求外，css文件采用Link方式外链到页面里
一般情况下，每个页面的css外链数不得超过3个
css文件需按功能或调用页面命名
css文件必须放置在页面顶部区域内部。
css应该按模块功能来划分格式，条理清晰，注释明确
禁止使用css表达式，禁止在css文件中使用全局选择器”*”，尽量少使用滤镜。
7、html文件规范
除特殊要求外，产品页面必须使用 utf-8编码，禁止出现页面与css编码不统一的情况
页面必须根据功能填写title，不允许出现内容和title不符的情况
代码需按照w3c XHTML1.0 Transitional或者strict标准进行制作。
标签名和属性名必须小些，禁止使用错误的标签嵌套方式
页面中禁止出现不闭合标签。图片必须加alt属性
空内容的标签，必须加title属性。其余标签可按需求加title属性。
单选框和多选框的文字描述部分需要使用标签，并使用for属性指向选择框的id
Class命名需使用骆驼法或下划线法，使用可读性良好的Class名，避免过长的Class名。
多行代码的循环项，第一项的开始结束位置要写清注释。
避免多层表格嵌套。一般不超过两层。
html字符要用转义符
8、图片文件规范
图片文件名不能出现大写字母和中文
小图片尤其是图标尽量拼合以减少请求次数。
色彩丰富的大图片使用jpg格式，原则上保存质量不超过70%
低彩小图片使用gif或png-8格式
半透明图片使用png-24格式。尽量不使用半透明图片和图片滤镜
9、js文件书写规范
js文件必须放置在页面顶部区域内部
js外嵌的正确写法
html文件添加js的写法
js里面尽量不要定义全局变量或者全局函数，变量申明尽量写在前面
js文件最好要有注释
10.文件命名存放规范
（1）Title命名规则
例：频道首页的title命名规则是：频道名-频道说明文字
Eg:爱问知识人—Sina旗下中文互动问答平台
（2）最终页的Title命名规则是：页面标题-产品名称
Eg:古时候人们怎样用太阳来判断时间？—爱问知识人
（3）存放的规范和结构
A、css（ishare.css某个专题下的css; iask.css某个专题下的css）
B、img（ishare共享资料图片文件夹；isak爱问知识人图片文件夹）
C、js
D、flash

十三、项目实施阶段PHP代码书写规范

1、排版
1.1使用tab缩进，不使用空格
1.2一条语句过长时应折行，第二行比第一行多一个tab的缩进，之后全部与第二行对齐
2、命名
2.1常量、变量、类、函数名一律使用英文单词全拼，禁止使用缩写（常用缩写xml、url、http等除外），禁止使用拼音。尽量不使用info、list等含义模糊的单词，单词单数形式表示单个对象的类型，单词复数形式表示多个对象的集合
2.2类名称的单词选择“名词”，方法名称的单词选择“动词+名词”，变量名词的单词选择“名词”或“形容词+名词”。命名应选择言简意赅和能自我描述的单词，不使用生僻或过于复杂的单词。
2.3常量一律使用大写字母，多个单词用下划线分隔
2.4变量名称采用Camel风格，首单词全小写，后续单词首字母大写，其它字母小些，多个单词之间不使用任何符号分隔
2.5类名由“目录结构+文件名”组成，采用Camel风格，单词首字母大写，其它字母小写，单词之间使用下划线分隔。一般一个文件中只定义一个类，文件名首字母大写。
2.6类属性名采用Camel风格，首单词全小写，后续单词首字母大写，其余字母小写。private和protected修饰的类属性，在属性名前添加下划线。
2.7类函数名使用Camel风格。首单词全小写，后续单词首字母大写，其余字母小写。private和protected修饰的类函数，在函数名前添加下划线。与Kohanna框架相关的函数遵循kohana的命名规范。
3、运算符
3.1一元运算符与变量之间没有空格 例!$a ,$b++,–$c 3.2二元运算符与变量之间有一个空格 正确示例$a && $b, 错误示例$a&&$b,$a==$b 3.3三元运算符与变量之间有一个空格 正确示例($a > $b) ?$a : $b 错误示例$a>$b?$a:$b 4、语句 4.1每行有且只有只有一条语句 4.2赋值语句等号前后各有一个空格 4.3数组定义语句元素只缩进一个tab 正确示例：$a=array(
‘foo’=>’bar’, //已经缩进
‘key’=>’value’
);
4.4 if、for、foreach等控制结构体时，关键字与小括号之间没有空格，小括号与大括号之间有一个空格，内容从新行开始，大括号不能省略
//正确示例
If($$foo == ‘value’) {
Echo $foo;
}
//错误示例
If($foo == ‘value’){
Echo $foo;
}
4.5 if语句条件较多时应折行，新行以逻辑运算符为起始，第二行比第一行多一个tab的缩进，之后的行全部与第二行对齐
4.6 try…catch语句关键字与大括号之间有一个空格
5、注释
5.1只在关键点和说明不明确的地方做出注释。单行注释使用//，多行注释使用/**，禁止使用#号注释
5.2不要在一行代码结束后使用单行注释
//正确示例
//comment
$foo = “bar”;
//错误示例
$foo = “bar”; //comment
5.3类、类方法和普通函数都需要注释，采用phpdoc格式书写，注释应尽量简单明了，不能过长
//注释示例
/**
*short desc 简介
*
*@package package 包名
*@author namename@home.sise.cn 作者
*@version xxx.xxx.xxx 版本
*/
Class Class_Name {
/**
*short desc
*
*@param integer $var1 参数 *@param float$var2
*@param string $var3 *@param boolean$var4
*@param array $var5 * *@return array 返回值 */ Public function functionName($var1,$var2,$var3,$var4,$var5) {
}
}
6、结构
6.1整体结构按功能分层，降低耦合度
6.2Dao层负责数据库读写操作，每张表对应一个类
6.3Business层不处理与业务逻辑相关的操作
6.4System层为kohana框架代码，不能直接修改
6.5Modules为各项目公用的模块，应尽量保证通用性
7、安全
7.1树立“用户输入的都是有害的”，对接受到的参数要进行判断和过滤才能使用
7.2任何服务器信息都不要暴露给访问者，包括程序信息、调试信息、文件路径、服务配置、资源信息、网络架构等
8、其它
8.1统一使用UTF—8字符集
8.2（建议）适当控制每行代码的长度，一般情况下不要超过80个字符
8.3（建议）空行将逻辑相关的代码段分隔开，以提高可读性
8.4除关键字FALSE、TURE、NULL之外，其它关键字一律使用小写形式
8.5（参考）禁止使用CRLF换行，注意IDE和文本编译器的配置
8.6（建议）控制结构体多层嵌套，最大深度不超过3级
8.7（建议）变量函数的命名应尽量规范统一，优先采用以下名称

十四、项目结项阶段的奖惩制度

十五、项目结项阶段 项目的事物流程规范

十六、SVN的简单使用

十七、关于GIT的介绍及使用

脚注

该文档非原创，仅为本人学习过程中的笔记，如有侵权务必联系第一时间删除[^footnote].

目录

用 [TOC]来生成目录：