增值项目管理思考.docxVIP

增值项目规范化思考搭建sharepoint服务进行文档和审核管理引言“增值技术这边儿一直挺乱的，最新代码在哪儿，程序部署情况，项目开展情况如何，服务器上都跑有那些程序，数据库中都那些数据还有用，等等一些常规的问题都没人能回答清楚。这即有历史传承的原因，也有人为因素的影响。面临的问题增值部门目前产品多，服务多，文档多，项目没有做配置管理或未能及时维护，产品发布版本不清楚，没有专门的测试，也没有发布计划和发布说明性文档；部署工作是由IT部门去实施，具体部署都是分派到个人，没有人清楚所有的部署，出现问题时，排错困难。大家工作编写的文档一般都用邮件发送，没有统一管理，尤其是对于一些发给客户的接口性文档，只是发件人清楚；人员流动，工作交接不完全，许多问题没人能解释。……以上种种原因造成了目前混乱的局面，我们迫切地需要梳理清楚我们的产品、服务和文档。但在梳理之前，我们更需要规范化我们的工作，否则梳理不久后，又会形成目前的局面。需要规范化什么？我这里借鉴CMM的一些概念，先将我们的管理工作做划分，然后在划分后的子域中，一方面做大致介绍，另一方面分析我们的需要。CMM L2级（可重复级）共有6个关键过程域(kpa),分别是：需求管理软件项目计划软件项目跟踪与监控子合同管理软件质量保证软件配置管理在软件开发过程中，有3个基本管理的对象，软件需求，开发活动和产品，6个kpa是对3个对象的管理。需求管理需求是容易变化的，对需求管理的主要活动有如下几方面:评审初始需求评审需求规格说明书需求跟踪需求变更管理需求管理活动产出或需要的主要文档有：软件需求规格说明书需求跟踪矩阵需求项跟踪表需求变更记录表软件需求规格说明书检查单软件需求规格评审报告需求变更影响分析报告需求变更申请单变更影响分析检查单对于需求的评审我们一般都会进行；需求规格说明书的内容根据实际需要编写，没有固定的规范；需求跟踪和需求变更我们目前可以说没有做，在处理变更时一般都用word文档记录，邮件分发，不能追踪。对于需求跟踪管理还可以利用第三方工具。比较著名的有Telelogic Doors和IBM Rational RequisitePro。前者没找到破解版，后者可以从WORD文档中提取需求，在软件中有各种视图帮助分析，包括矩阵视图。简单的，如果是内部项目，需求变更不会太大，可以考虑利用TestDirector进行需求管理。管理时将需求拆分成一个个的Feature和usecase。用TD有一个好处，能自动生成文档，需求变化时只是修改局部需求，查询方便，但跟踪能力仍是比较弱的。软件项目计划为什么进行？使活动有据可依，有据可查；项目组的行动一致，众人心中有数；通过项目策划提高策划水平。项目计划的活动:确定项目的假设和约束条件；选择生命周期模型；创建WBS; 重用策划；项目估计；风险识别，关键计算机资源分析，支持工具与环境；与相关组件来约定；计划变更与重策划的约定，计划编制与评审。在软件项目计划过程中，产出或需要的文档主要有:软件开发计划软件估计文件（工作量估计表、进度估计表、风险估计表、成本估算表……）立项报告软件项目计划在项目进行中可能会发生变更，不是一成不变的。我们目前对于此类文档的管理是基于VSS的。我们需要规范化什么？我想目前先规范化我们的文档命名即可。软件项目跟踪与监控目的：为项目：建立对项目实际进展的客观可视性；在软件项目性能偏离计划时采取有效措施。为组织：数据积累。作为下一次项目开发的参考。主要活动：进展数据收集、分析、报告召开项目周例会计划变更进行里程碑评审项目总结问题的跟踪主要产出或需要的文档：工作周报会议记录SDP变更及外部承诺规程跟踪表（规模估计跟踪表、工作量估计跟踪表、进度估计跟踪表、成本估计跟踪表、CCR估计跟踪表）SDP 变更申请表变更影响分析检查单项目数据分析及偏差报告项目总结报告我们目前有工作周报和会议记录。在SPTO中，其实不但有文档的需求，还有数据采集和分析的需要。比如工作周报，大家填写完了，项目经理还需要进行统计，更新项目计划，工作量是比较大的。能否减少工作量？子合同管理主要是基于文档的管理，一旦生效，变更不大，由专人保管即可。软件质量保证对于QA人员规范化要求，也有很多审计文档产出，但都可认为是项目附属品，不过多解释。QA人员的文档也存在检索和共享问题。关于测试，我们目前已经应用了TD进行测试用例的管理，但不清楚是否有人编写测试计划？测试计划的编写应该是和开发并行的，在详细设计文档制定之后编写。软件配置管理软件配置管理是一种庇护性活动，它贯穿软件开发的整个生命周期。SCM目的：保证软件工作产品在整个软件开发生命周期的完整性、一致性；协调软件开发过程，使混淆减至最小；SCM工作内容：配置标识——选择有用的工作产品便于控制；配置控制——“维持秩序”；配置审计—