——管理措施
最近老板让我做一个软件项目组的管理措施，搜集了多方资料和平时的一些经验得出以下的一些知识：
在一个软件产品发布并使用之后，其中肯定有许多地方不如意和值得改进的地方。客户在使用的过程中会发现一些问题，提出更高的需求，市场也在发生变化，我们的竞争对手也在发展，新的技术不断地产生，这些因素推动着我们的产品不断地向前发展，使软件版本不停地往上增长。这些发展的需求不是一下子提出来的，在客户使用的过程中发现某些不如意不方便的地方，他们会向我们提出宝贵的意见，而技术人员会把这些需求记录下来，以便修改或成为下一个版本的新特性或需求。
一个软件的开发主要分为需求、设计、编码、测试、维护几个重要的阶段，下面就每个阶段的一些管理措施提点愚见：
1． 需求管理
在进入正式开发之前，必须先从用户处获取准确的需求。在这上面花费相当时间是很必要的。在软件项目的开发过程中，需求变更贯穿了软件项目的整个生命周期，从软件的项目立项，研发，维护，用户的经验在增加，对使用软件的感受有变化，以及整个行业的新动态，都为软件带来不断完善功能 ，优化性能，提高用户友好性的要求。在软件项目管理过程中，项目经理经常面对用户的需求变更。如果不能有效处理这些需求变更，项目计划会一再调整，软件交付日期一再拖延，项目研发人员的士气将越来越低落，将直接导致项目成本增加、质量下降及项目交付日期推后。这决定了项目组必须拥有需求管理策略。
在整个开发周期中期望用户的需求一直保持不变是不大可能的，因为用户对于如何应用计算机软件并没有一个成熟的经验。需求变化的原因很多，如：
一开始没有调研全，需要增加需求；
客户需求发生了变化，需求必须变化；
需求错误；
需求不清楚。
基于上述的问题，必须对需求进行管理，使需求能够真正成为软件工程和管理的基线。 一种比较明智的方法是在签定开发合同（协议）时把用户需求的改动和经济利益挂钩,如果用户增加或改动了需求,那么软件的交付日期可以推迟,费用也应增加。
需求是一项复杂的工作，使用的方法也很多，不同的开发方式有不同的方法，这里简单介绍一些相关的方法：
可行性分析：在允许的成本、性能要求下，分析每项需求实施的可行性，提出需求实现相关风险，包括与其它需求的冲突，对外界因素的依赖和技术障碍。
快速原型：当用户自身对有的需求不十分清楚时，我们可以建立一个系统原型，用户通过评价原型更好地理解所要解决的问题。
图形分析模型：绘制图形分析模型是编制软件需求规格说明重要手段。它们能帮助分析人员理清数据、业务模式、工作流程以及他们之间的关系，找出遗漏、冗余和不一致的需求。这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。
数据字典：数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员使用统一的数据定义。在需求阶段，数据字典至少应定义客户数据项，确保客户与开发小组是使用一致的定义和术语。
2． 设计管理
项目经理把功能模块分配给每个开发人员，每个开发人员把自己相关的功能模块收集起来，同时预估时间，其中主要包括写文档的时间、开发时间和单元测试的时间，一般要求精确到工作日。这些信息返回给项目经理，项目经理再把本小组人员的任务和预估时间发送给管理层，由管理层对此任务及进度进行评估审核，管理层会根据产品发布时间及客户需求、市场因素等方面作出选择，可能某些功能由于时间紧急会被推迟到下一个版本中去。若预估出来的时间同预计的产品发布时间有较大冲突，而且此功能是本版本中必须得做的，则开发小组会被要求重新预估时间，加快开发速度来达到这个要求。
虽然这个开发进度时间是一个大概的估计时间，但我们要尽力按照这个开发进度来执行。作为开发人员每个星期写一篇周记，描述自己本周所做的工作，根据自己的描述来评估我们自己的工作，每个人手上的工作是否按照这个进度在走，是否有人延后了，是否延误了别人的工作。在周记里每个人都要报告自己的进度，同时还要报告上个星期做了什么，正在做什么，以及下个星期打算做什么。通过这个周记，会让你觉得有人在监督你，无形之中迫使你不断地督促自己不要使任务延后，如果有延后的迹象也会尽早发现而赶上。若某些经过努力不能赶上，那也没有办法，只能修改原先的进度表，因为那是我们的估计与现实发生了偏差，我们必须使我们的进度表符合实际情况。
3． 编码管理
进入编码工作之后，可能会发现前面分析或设计阶段的某些错误，这时应返回到前面的阶段进行必要的修改。由于我们用asp.net(c#)语言进行开发，因此我们借助了VS2005工具。关于代码风格，我们基本上套用VS2005中自动的代码格式编排。良好的编码习惯有利于我们提高整个团对的开发效率，比如变量的命名、写代码时要对类及函数提供详细的注释及说明等，基本做到看它们的说明就能知道这个变量、类或函数的功能以及主要算法的实现原理。在开发过程中对主要的模块要编写单元测试，同时要单元测试先行，当所有的单元测试代码通过时，此功能也就基本上完成了。
我们采用VSS进行代码管理控制，其中存放了此产品的所有源代码，各个部分存放在不同的目录中。每天早上要求开发人员从VSS中获取最新的源代码，然后进行编译并开始一天的工作。在下班之前理论上要求员工签入所有当天修改的代码，在签入之前要保证编译是能通过的。若有谁签入的代码导致运行失败则会被要求某些惩罚措施或警告。有时我们编写的代码涉及到多个文件，而且此改动是比较复杂需要花费多天的工作量，如果现在签入进去可能会导致项目测试通不过，因为有些代码没有完全完成，而之前的代码能测试通过，而且这些代码基本上不会涉及到他人，在这种情况下可以不签入进去，直到全部代码完成能提交测试时再一起签入进去。
我们的开发是基于网络的，在互联网高速发展的今天，代码的安全也是一个不容忽视的问题，我们要注意代码的泄漏和丢失，除了掌握一些基本的安全知识以外，还要进行代码的备份（局域网备份和存储设备备份），这样在出现意外的情况下可以及时的恢复系统的正常运行。
4． 测试管理
在开发人员完成了功能模块后，测试人员开始了测试规划，确定需要测试哪些方面，如何测试及进度安排。测试人员需要写许多测试用例、测试报告等，有些测试代码需要集成测试，有些可能需要进行单独的测试，目的都是为了使产品符合要求，使开发人员容易找出问题所在并改正。产品功能是否符合了要求，是否能被发布是由测试人员决定的，因此测试人员也比较辛苦，责任重大。通过了每天的测试，还有一些性能测试、兼容性测试、灾难测试等需要在产品发布前进行。在完成这些测试之后由测试人员决定本产品是否能发布出去了。
由于我们每天进行着测试，因此经常有BUG被测试人员发现，一旦发现了新的BUG，就会被添加进测试报告中，同时注明紧急程度，以便开发人员可以及时进行错误BUG的修改。需要指出的是我们对BUG的定义比较广泛，一些新功能也可以作为BUG被提出，只不过这些BUG级别比较低，让它们进入到下一个版本中去实现。因此BUG的创建者也可以是技术支持人员、市场人员甚至开发人员本身。关于开发人员本身，因为他可能会找出一些BUG，有些是其他开发者的，有些可能是此开发者本身的，把这个BUG添加进测试报告中可以帮助开发人员在以后产生新问题时或类似的BUG时有一个借鉴和思路。
5． 维护管理
后期的软件维护和管理也是一个非常重要的任务。定期的升级服务和培训会让客户对软件有个良好的映像。
6． 组织（团队）管理
软件项目开发过程中注重的是团队精神的发挥，我们的目标是一个软件、系统而不是几个模块的简单组合。在软件开发管理中，不能采用明令制度的方式来要求何限制开发人员，必须要有办法激励人的内动力，而激励人的内动力最好的办法是将付出和收益紧密的结合。团队精神的凝聚主要的是信任与尊重。正所谓“用人不疑，疑人不用”，如果没有基本的尊重与信任，哪里来的凝聚力，何谓团队精神？
软件项目开发人员应该本着态度第一、效率优先的工作原则，在平时的日常工作和生活中，大脑的休息和充足的睡眠可以保证开发人员有个良好的心态和精力。也许在IT行业来说，程序员加班已经成为一种佳话，一种习俗，但我们要制止长期的加班和无效率的加班，在项目不紧张或者无项目的情况下可以适当的放松、休息来调节个人的情绪和精力。
作为软件开发人员的大部分时间是在公司里度过的，因此公司的生活成了大家主要组成部分。员工之间关系的融洽，交流的畅通显得非常重要，同时大家也不想自己的生活这样枯燥乏味，一直同机器打交道。沟通无处不在，交流随时发生，有许多关系是在工作之外建立起来的。软件公司内是很容易产生各种矛盾的，因为这是由你的工作性质所决定的，比如测试人员或用户会对你的实现不满意，提出各种要求时，我相信你有时会有所抱怨的，无形之中就产生了对立，发展到后来会有抵触心理。我相信大部分人都会有此感受，这不是你的错，这主要是由我们的工作性质决定的。如果你的工作是把财富带给对方，则对方会非常欢迎你的到来，把你奉为财神爷来对待，同你的关系会非常融洽友好。因此我们需要在工作之外来消除这种对立矛盾的关系，建立一种融洽的工作氛围。我们在平时吃饭的时候饭桌上大家互相聊天沟通，说一些幽默笑话之类的，给我们紧张的工作增加点轻松的氛围。隔断时间大家可以组织一下活动，增加了公司的凝聚力。一个产品发布后组织一次活动，让绷紧的神经松弛一下，更好地迎接下一个挑战。
团队的每个成员都会养成写Blog的习惯。经常写写Blog，一是可以让大家都知道自己在做什么事情，二是项目结束时方便写最后的工作总结（许多工作自己当时不纪录也忘记了），三是利于提高自己的水平（工作和学习写点总结会系统的总结和归纳思路，进步很快）。
附件：
1． C#编码规范.doc
2． 个人周记.doc
3． 项目组周报.doc
4． 项目总结报告.doc
5． 测试文件.xls
项目附件下载
来源：https://www.cnblogs.com/huangwen/archive/2007/03/16/677135.html