项目管理和软件开发的边界

引言

程序员的人生就是和一个个的软件项目打交道的人生。

不能管理好项目过程的程序员不是好的开发人员。

项目管理是对成功地完成一整个软件项目过程中地一系列目标相关地活动（譬如任务）的整体监测和管控，软件开发是软件项目过程中最重要的一个组成部分之一。

在互联网公司做项目，一边强调要敏捷开发，一边要交付成果。所以如何区分好项目管理和软件开发的边界，统筹好二者才是一个好的互联网项目管理和软件开发过程。

最简单的项目管理

每周都要写周报

周报里面应该写点什么？最简单地要写当前我要关注哪几个项目，各个项目是处在什么开发模式中，对应的开发进度分别进入到了哪个层面，进度和进展分别是怎样的。有哪些风险。难于解决的问题在哪里。

每天都要写日报

那怎样来监控和衡量项目的进度的问题呢，项目管理和项目开发的边界在哪里？

很大程度上取决于所选择的软件开发模式。

对于瀑布型的软件开发模式，进度比较好衡量。需求分析、设计、编码、集成、测试、维护每个阶段都有对应的产出。

迭代型开发：主体框架稳定的情况下，加功能就是迭代型开发。每一个迭代周期里面，就是一个小的项目开发，这个时候的项目开发进度应该也比较好衡量，对于项目开发的进度管控有些孰能生巧了，有时候就会忽略掉一些步骤，比如设计文档、测试case、单元测试相关的交付。

螺旋开发：如果面对未知的风险，每次项目都要评估风险，每次结束后都需要重新提出修正建议，制定下一步计划，更像是再搞研究。每一次迭代对应效果的衡量其实是不那么确定的，以成果认英雄式的进度略微不好衡量。

敏捷开发：频繁交付新的软件版本，这个边界比较模糊，适合于需求非常不确定型，经常需要调整的项目，强调大家齐心协力把事情做好，需求经常可能调整，进度相对不大好衡量，敏捷管理对项目管理和软件开发人员的要求最高。

不同软件开发模式

瀑布型开发：

需求分析、设计、编码、集成、测试、维护，强调每一个阶段都需要有相应的产出。

迭代型开发：

整个开发工作被组织成为一系列短小地、固定长度（如3周）地小项目，被称为一系列地迭代。每一次迭代都包括了需求分析、设计、实现语测试。

迭代式开发的优点：

1、降低风险

2、得到早期用户反馈

3、持续的测试和集成

4、使用变更

5、提高复用性

螺旋开发：

快速原型

1、制定计划：确定软件目标、选定实施方案，弄清项目开发的限制条件；

2、风险分析：分析评估所选方案，考虑如何识别和消除风险；

3、实施工程：实施软件开发和验证

4、客户评估：评价开发工作，提出修正建议，制定下一步计划。

螺旋模型由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助将软件质量作为特殊目标融入产品开发之中。但是，螺旋模型也有一定的限制条件，具体如下：

1、 螺旋模型强调风险分析，但要求许多客户接受和相信这种分析，并做出相关反应是不容易的，因此，这种模型往往适应于内部的大规模软件开发。

2、如果执行风险分析将大大影响项目的利润，那么进行风险分析毫无意义，因此，螺旋模型只适合于大规模软件项目。

3、软件开发人员应该擅长寻找可能的风险，准确地分析风险，否则将会带来更大的风险

4、一个阶段首先是确定该阶段的目标，完成这些目标的选择方案及其约束条件，然后从风险角度分析方案的开发策略，努力排除各种潜在的风险，有时需要通过建造原型来完成。如果某些风险不能排除，该方案立即终止，否则启动下一个开发步骤。最后，评价该阶段的结果，并设计下一个阶段

敏捷开发：

测试驱动开发

scrum

强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。

1、人和交互 重于过程和工具。

2、可以工作的软件 重于求全而完备的文档。

3、客户协作重于合同谈判。

4、随时应对变化重于循规蹈矩

实际工作中，除了瀑布型开发流程很好区分，另外几种开发模型比如迭代型和螺旋型和敏捷开发都不是很好区分。于是发现了下面这个对比文章，其中明确地把敏捷开发和其它开发流程区分开来，说敏捷开发就是用来做互联网项目的管理的，迭代模型是敏捷开发的一个组成部分。看起来要靠谱得多。

不同软件开发模式的对比

其中有一段如下：

迭代开发是 一种 软件开发的 生命周期模型 ,与其对应的还有瀑布模型、螺旋模型等等

敏捷开发是 多种软件开发 项目管理方法的集合,其中 包括了XP、Scrum等十几种开发模式,这些开发方法有些共同点,比如重视响应变更,重视实现客户的价值,重视开发人员的自身发展等等,其核心体现在他们著名的四句原则中.这些开发方法基本都倾向于采用迭代的软件开发生命周期模型.

简单来说, 迭代模型是敏捷开发普遍使用的软件生命周期模型, 敏捷开发所包含的内容比迭代模型宽泛的多.

明白自己所处的开发模式下面，可以更好地知晓项目管理和软件开发的边界，以及预期自己的产出对于管理者会是什么。

所以，有的时候软件开发人员觉得自己做了很多事情，但是个人的成果不那么被认可，不一定是个人没做好，也可能是因为个人落在了敏捷开发这个区间，而且关注点在软件项目的实现上。这个时候可以选择放慢进度，适度补充一些相对稳定的流程产出和文档产出。这个时候的开发成果和瀑布型开发的成果也是不大一样的，这个也需要知晓

回想过去两个月的工作，最后要交付的时候有点狼狈：

原因当然有很多：

比如：中间插进来的项目打断了原有计划，快速原型的追求的同时，失去了更详细的需求分析。

另外就是因为没有清楚地明确自己手头上有哪几个任务、每个任务的时间点和优先级是怎样的。这个永远是top piority。

当然时间的预算也不够准，最近一直在调整自己的状态、没加班，这下预算时间人天数偏少，以及中间的其它意外。

越往敏捷上靠，管理越不那么精确可控，越容易在交付成果上容易被人诟病，也是正常情况，所以也不用太自责。

软件开发路漫漫其修远，项目管理显阶段性成果。