软件开发综合项目管理实施专项方案Word下载.docx
《软件开发综合项目管理实施专项方案Word下载.docx》由会员分享，可在线阅读，更多相关《软件开发综合项目管理实施专项方案Word下载.docx（10页珍藏版）》请在冰豆网上搜索。
和需求提出方代表进行需求讨论，明确项目标目标、价值；
确定项目范围、功效及优先级。
组建项目团体，尤其要搞清楚项目标keyperson（对产品有决定权人）。
项目开启会议，相关利害关系人员全部必需参与。
该阶段完成后结果：
确定后最终软件需求规格说明书文档。
2、分析设计阶段
依据确定后软件需求规格说明书，制订项目进度计划，工作任务分解（WBS）；
资源申请，项目包含到开发资源、测试资源、设计资源（包含人员和软硬件资源）；
数据库设计；
系统设计；
文档（包含UseCase、Demo系统原型、TestCase等）；
评审会议。
A、UserCase（系统用例）；
B、DEMO（系统原型）；
C、系统设计文档（概要设计和具体设计）；
D、数据库设计文档。
最终对完成结果，包含UserCase和设计文档等进行评审。
3、实施阶段（开发和测试）
准备开发环境、测试环境；
跟踪，推进项目按计划进行；
以周报形式通报项目标进展情况。
对项目标阶段结果进行评定，以确保该阶段完成质量，包含代码审核、SQL审核等。
对需求变更进行控制管理；
对项目风险进行管理；
测试阶段BUGFIXED及改善、搜集反馈意见。
4、公布阶段
包含制订项目公布计划，用户培训，公布上线。
5、上线后监控
数据监控（日志、服务器状态），依据监控出现问题，立即进行BUGFIXED及改善或做补丁升级。
6、结束阶段
产品交付，项目总结会。
第四：
基于以上三个问题所做应对细则
要做好项目管理，并能确实处理好以上三个问题，实现目标、推行职责、完成工作中具体内容，从我个人这几年工作经验和面临部分问题，还有所积累部分项目管理中部分知识和自己观察和思索角度看，应该要努力做好以下这多个方面具体工作：
1、项目开发时间估算
制订项目进度时间表时候，需要估算每个任务所需时间，其中开发任务中模块分配和时间估算是其中最关键部分；
在分配模块和估算开发时间时需要遵照标准和目标：
1、确保项目整体进度。
2、有利于确保开发编码质量。
3、有利于提升开发编码速度。
在企业现有技术框架下，开发人员关键工作是投入在具体商业逻辑上。
通常每个模块所需开发时间取决于以下三个原因：
1、所负责模块商业逻辑复杂程度。
2、开发人员技术水平和对项目所在应用熟悉程度（包含对框架和应用熟悉程度）。
3、该模块技术实现上是否有技术难点；
这里所谓技术难点定义是：
在现有系统中还未实现、开发人员本身也未没接触过技术。
对于这么难点，开发者没有相关代码能够参考，自己也没有经验，所以需要投入部分时间研究处理。
模块分配和开发时间估算步骤：
1、在划分好模块后，首先自己先估算一下每个模块所需要开发时间。
2、然后召集全部开发人员，讨论模块分配和开发时间估算。
将划分好模块，让开发人员从中挑选她们感爱好模块。
这么做能够提升开发人员主动性和参与性。
在分配模块时候还需从以下几方面考虑，以确保开发速度和质量：
A、相同类似模块由同一人负责开发，比如用户管理增删改由同一开发者负责。
这么做好处就是开发者对相关逻辑会愈加熟悉，同时接口定义也会比较明确，沟通成本比较低，同时功效实现缺点也对应会降低。
B、技术难度比较大模块由技术水平比较高人负责。
C、业务逻辑比较复杂由对这块逻辑比较了解人负责。
3、模块分配完后，开发人员评定自己负责开发模块所需要时间。
在此过程中最好做到要和开发者比较具体讨论每个模块技术实现，方便使时间估算愈加正确。
4、对开发人员估算时间进行确定。
在确定过程中作为项目管理者应参考以上提到三个原因，同时将自己估算时间和开发人员估算时间进行比较。
这其中差异当然会存在。
对于那些差异比较大，将和技术人员探讨其中缘由。
对于时间周期比较长任务，尽可能将任务经过再细分手段细化任务，争取每个任务最长时间不超出3天；
时间周期越长任务，不确定性越高，风险也越高，越有可能成为项目标瓶颈，影响项目标进度。
2、CodeReview
CodeReview是确保项目中代码质量很关键一个步骤，在这一环中我们企业做很欠缺，把关不严格；
这是造成每次测试后出现大量bug关键原因，这一环需要纳入绩效考评中，实施责任追究制，实施关键监控。
出现这么微弱步骤，造成这么原因，我想也是有很多原因造成；
比如开发人员对需求不是很明确，以自己比较主观原因去完成任务；
还有对整个系统业务逻辑没有正确清楚认识原因，和对项目组组员培训不到位原因等众多原因纠集在一起才产生。
怎样做好这方面工作？
首先编码要有“编码规范”文档，CodeReview要有“代码审核规范”文档：
统计代码实现应该遵照标准。
经过这两个文档来规范开发人员代码实现，代码编写者必需要严格根据规范来进行；
代码审核者依据这些标准来CodeReview代码，同时在CodeReview过程中不停完善该文档。
在做好这些前期工作前提下，分以下多个步骤来实施：
1、检验开发者代码实现是否遵照了编码规范。
2、从代码易维护性、可扩展性角度考察代码质量，提出修改提议。
3、代码编写者和代码审核者坐在一起，由代码编写者根据UseCase依次讲解自己负责代码和相关逻辑，从Web层-到Manage层再到Dao层；
4、代码审核者在此过程中能够随时提出自己疑问，同时主动发觉隐藏bug；
对这些bug统计在案。
5、代码讲解完成后，代码审核者给自己安排多个小时再对代码审核一遍。
代码需要一行一行静下心来看。
同时代码又要全方面看，以确保代码整体上设计优良。
6、代码审核者依据审核结果编写“代码审核汇报”，“审核汇报”中统计发觉问题及修改提议，然后把“审核汇报”发送给相关人员。
7、代码编写者依据“代码审核汇报”给出修改意见，修改好代码，有不清楚地方可主动向代码审核者提出。
8、代码编写者bugfixed完成以后给出反馈。
9、代码审核者把CodeReview中发觉有价值问题更新到"
代码审核规范"
文档中，对于尤其值得提醒问题可群发email给全部技术人员。
假如经过以上步骤，还因
为是代码编写者原所以出现严重缺点问题，将经过绩效考评来加深代码编写者印象，并在周报会议上做通报批评。
3、需求变更管理
需求变更管理也是项目管理中最关键一个步骤，对需求变更管理有效性将直接影响项目标成功是否。
对待需求变更态度：
1、需求变更是不可避免。
2、需求变更要必需被管理。
3、主动发觉引发变更原因，促进变更尽可能早出现，减低变更带来风险。
需求变更管理目标：
1、相关干系人必需清楚地了解发生变更。
2、变更处于有效管理中。
3、尽可能降低变更带来风险。
经过制订需求变更步骤，确保项目中需求变更有效地进行，实现上述目标。
需求变更步骤：
1、确定需求基准线。
将以UserCase作为需求基准线，在UserCase确定以后任何需求改变，全部需要走需求变更步骤，这一步骤我们基础没有，期间有时候使工作很混乱，也就是因为没有一个规范变更步骤而造成；
假如建立了这么一个步骤规范和机制，需求变更没有走这个步骤将不被认可。
2、项目管理者接收到需求变更要求。
需求变更提出者能够是项目中任何人包含产品经理、市场人员、开发人员、测试人员等。
3、项目管理者评定该需求变更。
针对接收到需求变更要求，召集相关人员讨论该需求变更合理性、可行性，实施代价和对项目标影响。
包含可能影响项目范围，进度，费用，质量等计划。
项目管理者作为项目标责任人，对项目标成功是否负相关键责任。
所以需求变更决议者应该由项目管理者负担。
4、需求变更确定后由专员将需求变更统计下来，通知给项目中全部组员。
其中以下人员对需求变更是紧密相关，她们必需知晓并认可此需求变更。
包含（用户方，需求分析人员，测试人员，相关开发人员）。
需求变更统计格式以下：
序号
变更提出时间
变更描述
变更类型（是对原有需求修改还是新增需求）
原因
变更提出者
开发人员
对进度影响（工作量）
1
2
5、确定变更责任人。
负担需求变更具体工作，比如基线控制，对需求变更统计，并通知相关人员。
6、相关人员接收到确定需求变更后，做以下事情。
需求分析人员修改需求说明书和UserCase相关内容。
测试人员修改测试用例相关内容。
开发人员修改代码中相关部分。
7、根据变更后计划实施项目，并进行检验，跟踪，对变更后实施反馈和可能出现问题立即沟通和处理。
8、需求冻结。
项目越到后期，需求变更对项目标影响就越大，所以在一定时候要进入需求冻结阶段，不再接收新需求或需求变更。
4、风险管理
风险管理是项目管理者最关键工作之一。
风险管理是一个连续过程，贯穿于整个项目过程中，风险管理包含风险识别、风险评定、风险处理和风险管理策略。
在项目标实施过程中需要不停地识别和应对风险，并加以有效控制，风险管理好和坏直接影响项目标实施效果，从某种意义上讲，项目实施对于项目管理者就是识别、分析、应对、控制风险过程，使项目标约束性目标和质量目标朝有利方向发展。
项目不一样于日常任务，它有明确起止时间和目标，要在明确范围、时间和成本约束下，达成对应质量标准，并取得用户满意。
影响项目成败原因包含方方面面，而且风险伴伴随项目标一直，是客观存在，作为一个项目管理者，应该含有良好风险控制意识，善于识别风险并分析风险影响，从中发觉影响目标风险点，并施加影响或采取应对方法，把风险负面影响降到最低，而且风险控制应该贯穿项目一直。
风险引发负面后果集中表现在进度延后、成本超支、质量不达标等方面，造成这些问题原因关键包含目标和需求不明确、范围蔓延和需求变更、代码质量或返工风险、人员技能和资源不足、缺乏良好团体协作等。
下面将具体描述一下这些问题和出现这些问题时应对方案：
1、目标和需求不明确
为了市场竞争或内部管理决议需要，业务部门提出需求往往要求时间比较紧迫，需求提出大多停留在几张纸或口头传达上，没有形成正式业务需求文档，在没有明确需求范围情况下，有时为了迎合业务部门口味急忙开工，过程中用户不停地提出新想法，技术人员开始疲于奔命和应付，极难确保项目标进度和质量，也难以取得业务部门认可。
所以，在项目标前期一定要采取对应手段或方法，和业务部门共同明确项目目标、需求范围，充足考虑现有时间和资源约束，将需求排定优先级，对于关键需求优先实现，其它辅助性依据过程中具体情况进行滚动式计划，并取得业务部门书面确定。
在此过程中要重视挖掘用户隐性需求，能够经过引导、系统原型等手段让用户在前期充足暴露自己想法和需求。
2、范围蔓延和需求变更
在有了明确目标和需求范围情况下，需求变更还是不可避免，业务部门在看到具体系统真实雏形以后，源源不停地要求、新想法随之产生，假如不对此加以控制，新需求加入通常会影响已实现需求，而且对项目进度和成本产生很大影响。
项目管理者针对这种情况一定要采取严格变更控制步骤，不能碍于面子，不然最终结果往往是出力不讨好。
针对用户提出新需求，根据正式步骤提出变更申请，组织相关团体组员进行分析及评定，作为是否实施依据，变更控制责任人依据分析结果判定是否同意，假如同意，那项目组能够安排实施，不然，正式拒绝用户请求，当然实际情况下能够采取部分软方法缓解矛盾。
需求变更风险：
需求已经打上了基线，但以后仍然有变更发生，对项目造成影响。
怎样降低这类风险发生？
前期需求讨论要具体、充足。
需求文档中需求范围要明确、功效描述要清楚。
找出项目中需求决议者（通常会是产品经理、相关职能主管、用户），全部需求要经过她们认可。
用户在项目过程中全程参与有利于降低这类风险。
需求讨论、需求确定、UserCase确定、测试阶段用户验收等步骤，全部要要求用户参与。
在发生需求变更时，严格根据需求变更步骤实施。
在分析设计阶段中确实定和评审也是降低这类风险关键手段。
3、代码质量或返工风险
质量风险关键指开发代码质量。
怎样提升开发人员开发质量？
在制订项目计划时，对开发时间评定要尽可能适宜。
合理开发时间对开发质量影响也很大。
有时开发人员为了赶进度在比较担心时间需要完成指定任务，可能就存在很大开发质量问题。
开发要有一套严格可行代码规范，编码时严格遵守，到现在为止，我们这个方面做不是很规范，做也很不足，大家编写代码随意性比较大，代码编写者主观意识性比较强。
要建立一套大家认可而且规范可行编码规范和考评规范，codereview时严格考评。
在编码前，开发人员要对框架熟练掌握；
一份好系统设计文档对指导开发很关键。
返工是项目组最不愿意看到，既浪费人力、物力和财力，又影响团体主动性。
需求不明确或范围没有有效控制全部可能造成返工，另外造成返工原因是质量没有达成用户要求。
往往有这么一个情况，每个团体组员根据项目计划汇报进度全部是100%完成，但一到最终系统交互测试或集成时候就会发觉一大堆问题，不得不花费很大精力回头排查、修改程序，造成这种情况关键原因是过程中质量确保没有做到位，把大部分问题留在了后面。
这就需要在项目实施过程中采取有效方法来规避返工风险，通常做法有同行评审，比如概要设计完成以后，邀请其它项目组技术教授进行技术评审以发觉架构设计问题；
管理评审，经过组织级质量审计看产品和实施过程是否满足质量要求；
代码走查，在编码过程中加入最少一次代码走查，排查不符合规范或性能要求代码，走查通常能够发觉50%-70%错误；
每日构建，这是一个很有效方法，能够避免把各部分集成问题拖到最终，而且能够立即发觉对应错误，日构建通常在项目标中后期开始，天天自动从版本服务器上获取源代码进行自动编译和测试。
4、人员技能和资源不足
项目实施过程中因为人员技能欠缺造成进度延后和软件质量问题并不少见，一个熟练技术人员完成一样一个任务需要3天，但一个生手可能就需要7-10天。
项目管理者应该在前期就分析清楚项目所要采取技术和对应人员技能要求，针对不一样角色，立即采取对应技能培训，以确保项目标顺利实施。
假如对于项目中一些部分专业性尤其强或新技术，短期内又不能快速建立技能情况，能够考虑将该块任务外包，借鉴合作商力量降低实施风险，当然要进行外购人力成本和自建人力成本效益分析。
开发过程中碰到技术难题，造成开发时间延迟或需求不得不发生变更。
在项目开始前技术评定阶段，明确技术难点，提前安排人员进行攻克。
假如在可预期时间内无法处理，假如能够，将向需求提出方要求变更需求或寻求可替换方案。
这么风险应该在项目标前期阶段就应该处理在萌芽状态来避免这么风险在后期或中期出现。
项目所需人力资源无法按时到位，造成资源风险。
这个就需要在项目计划制订时候提前申请确定资源，并在项目过程中不停沟通协调。
5、缺乏良好团体协作
软件项目实施属于知识型，要发挥团体组员发明力，不一样于制造业计件生产，各模块最终要集成在一起形成一个有机整体，这就需要各小组之间亲密配合，界定清楚工作界面及接口关系，并在实施过程中连续地沟通交流和共享，首先团体要融为一体，产出软件才能融为一体。
这是一个团体软实力，团体之间协作好坏也将是个潜在风险问题，在项目开启和团体组建时候就应该加以规避这么风险出现。
项目风险管理关键点：
1、上述我们所说风险管理全部是指能够预期将要发生风险，那些不可预期将要发生风险不属于风险管理范围。
这也将是考验一个项目管理者经验和知识对能否管理好风险至关关键内容。
2、对不可预期风险，项目管理者要有潜在风险意识评定，做好部分可操作性预案准备。
3、具体明确项目计划、和项目实施过程中每个关键点质量确保是降低项目风险必需条件。
4、风险汇报是项目团体和领导了解项目风险一个有效手段。
风险汇报格式：
风险介绍
对项目标影响
处理方案或对策
5、团体管理
团体就是一组个体为实现共同目标而相互依靠、一起工作共同体。
团体工作顾名思义就是团体组员为实现这个共同目标而付出共同努力，项目团体工作是否有效直接关系到项目标成败。
团体管理是个渐进过程。
世界上只有完美团体，没有完美个人。
好高效团体不是管理出来，而是营造出来。
团体组员需要有大家可认同团体文化，这需要大家共同努力。
1、营造良好工作环境和气氛。
2、建设优异或鲜明团体文化。
3、保持高效沟通。
6、项目会议
组织会议是项目管理者日常工作中一项很关键工作任务，项目过程中很多关键决定全部是在会议中做出，也有很多因为不成功会议而对项目本身造成了不好影响。
首先看看不成功会议常常表现为哪些形式：
1、会议气氛不好，参与者讲话不踊跃；
2、会议讨论常常偏离专题；
3、会议没有取得预期结果；
4、会议时间常常一拖再拖。
这些不成功会议最终结果就是：
既浪费了大家宝贵时间又没有达成会议目标，大家全部对这么会议全部有抵触情绪，对此也是深恶痛绝。
以下是组织会议时应该注意问题，也可看作组织会议最好实践。
在列出最好实践之前有三点我们必需要清楚：
1、会议是否会取得成功很大程度上取决于会议组织者。
只有组织得有力，会议才有可能取得成功，这是会议成功充足条件。
2、会议组织者和参与者想法通常是不一致，有时候甚至会大相径庭。
所以不要期望会议参与者和你一样，对会议有着如此期待，对大多数参与者而言，在会议中她只是一个发表想法人，她不用对会议成功负担责任。
3、以下十一条最好实践是形式上约定，具体实施能够依据实际情况来做。
组织会议十一条最好实践：
1、只有需要开会时才开会。
有时候两三个人单独小范围沟通会愈加有效。
2、提前发出会议议程，方便会议参与者知道她们来做什么。
3、请对人很关键，不要把非必需人召来开会，当然也不要遗漏那些关键人物。
在确保必需人物全部在情况下一次会议参与者越少效果越好。
4、提前预约参与者时间，以确保她们能按时到场。
5、会议开场很关键。
会议组织者要在开始前做好几件事情。
通常我提议有几点要在开场时说：
A、再一次强调会议目标，我们来做什么。
B、强调会议专题和基调。
比如：
此次会议是一个需求确定会，而非需求讨论会，关键是讨论做还是不做和通知大家我们要做什么，而不要把太多精力放在讨论怎样做上面。
C、说明一下会议规则。
如要讲话，请举手；
不要有小圈子讨论；
不要打断她人讲话，等她人说完你再说等等。
6、会议过程中时刻注意引导和控制会议，以确保会议根据目标进行。
一次会议气氛是否良好，讨论是否充足，好引导至关关键。
比如多提部分开放式问题。
7、会议统计很关键，把部分结论和有价值内容统计下来，这些是此次会议关键结果之一。
8、会议要有结论。
我们常在会议上听到有些人说：
"
大家讨论了这么半天，结论呢？
。
没有结论会议是没有意义。
9、会议后别忘发会议纪要，和部分Action，什么人什么时候做什么。
10、会议后action实施情况反馈很关键。
反馈是对会议参与者尊重，同时也通知了会议效果。
不然会让大家感觉到这是一个可无可无会议，大家以后参与主动性也会降低。
很多会议往往全部不注意这一点。
11、按时结束会议会受到全部些人欢迎。
7、版本控制
版本控制也是项目管理者一个关键工作内容之一，一个项目或产品完成不可能是一步到位，在项目完成后期可能会有多个不一样版本公布（开发版本，测试版本，公布版本等）。
需要做好版本管理和控制。
8、项目总结
在项目完成后，总结整个完成项目标过程和经历，为下一次项目开启提供参考经验，完善不足，避免在类似项目中出现可能存在相同错误发生。
升级会员 