维护项目的管理策略案例
发布于 2024-10-02
1359
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
麦哲思科技任甲林
扫码关注公众号
扫码阅读
手机扫码阅读
维护类项目的定义和特点
维护类项目主要涉及对已交付软件的少量功能增加、局部需求变更以及bug修复。这类项目的特点包括短工期、客户响应速度要求快、人力投入少、容易影响现有功能并引入新bug、沟通和测试工作量大、维护请求多及不可预测性强。
维护类项目管理策略
在管理维护类项目时,应采用如下策略:
- 评估变更影响范围,并识别成本、工期和技术风险,以决策是否接受维护请求。
- 指定维护请求的责任人,负责项目全程。
- 跟踪管理维护请求的进展状态。
- 新增需求应使用功能需求描述加界面原型的方式,功能变更需明确描述。
- 与客户电话确认需求,并发送确认邮件,包括角色、功能、目的及验收标准。
- 内部沟通策划会议,包括需求交底、快速设计、工作量估算。
- 定义WBS分解模板,以识别任务并确保任务颗粒度。
- 维护成本核算,记录每日完成任务和工作量。
- 监控项目进展,每周公司级例会汇报。
- 确保新增代码通过静态检查,项目经理抽查是否修改必须改的错误。
- 指定人员进行代码比对和代码评审。
- 系统测试要先测试所有修改或新增的功能,其次是其他功能,最后是全面回归测试。
- 周期性发布版本时定义发布计划。
- QA人员在项目过程中和结束时审计,总结经验教训。
麦哲思科技任甲林
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
471 篇文章
浏览 820.9K
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
麦哲思科技任甲林的其他文章
读的感触点
1 开发人员的快乐: 创建事物, 开发对他人有用的东西, 组装的魅力, 持续学习的快乐, 在易于驾御的介质上工作 开发人员的苦恼: 追求完美 由他人设定目标 对他人有依赖 查找修改BUG 过时的很快 2 BROOKS法则:向拖期的项目追加人手,只能让项目更拖期 3 设计人员要少而精 4 开发人员如何避免画蛇添足 5 非正式交流,正式交流,
需求文档化的真理与谬误
如果是2个公司之间的供求关系,请将需求文档化; 如果是2个部门之间的供求关系,请将需求文档化; 如果是2个小组之间的供求关系,请将需求文档化; 如果是2个人之间的供求关系,请将需求文档化; 这是真理. 再好的合作关系,当发生分歧的时候,也会互相追究责任,在追究责任的时候,请拿出你的依据:文档. 道德是感性的,证据是理性的.道德是合作的基础,但并非有了良好的道德就一定能合作成功,因为分歧并非仅有道德
过程改进不能这样啊
过程改进是长期行为: 公司的高层对软件规范管理的认识有一个过程. 公司负责过程改进的人员对规范管理的理论的理解也需要一个过程. 公司的规范体系的推广需要一个实用化的过程. 公司的开发人员认识规范管理也需要一个过程. 公司的管理问题的解决从认识到制定措施,落实措施,优化措施也需要一个过程. 公司的管理体系真正制度化也不是短期内能做到的. 任何事情都有其发展的必然规律.违反了客观规律是要摔跟头的,
给程序员的18个忠告
1 想清楚,写清楚,说清楚,才是真正的清楚!2 多花点时间沟通清楚需求,才能把握正确方向!3 修复需求错误的成本是代码错误的几十倍!4 程序员最大的坏习惯就是:急于动手写代码! 5 提高开发效率的捷径:一次做对,不返工!6 写代码之前三件事: 弄清楚做什么; 说清楚怎么做; 想清楚怎么测!7 职业的程序员设计程序,业余的程序员调试程序;8 拷贝粘贴式的作业方式,最容易导入b
高成熟度的软件估算应该是什么样的?
1 估算基础 1)对估算对象(需求、任务等)的拆分颗粒度定义了上限与下限,以提升估算的准确度。 2)完备识别了估算对象,没有遗漏的需求或任务。 3)估算人员经过了估算方法的系统培训。 4)定义了组织级的估算方法。2 规模估算 1)从不估算规模或经验估算规模升级为客观度量规模,比如采用国际标准的功能点方法或自定义的规模度量方法,无论是哪种方法,规模与工作量之间应该是强相关的才是合理的。 2)如...
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线