扫码阅读
手机扫码阅读
维护项目的管理策略案例
195 2024-10-02
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
查看原文:维护项目的管理策略案例
文章来源:
麦哲思科技任甲林
扫码关注公众号
维护类项目的定义和特点
维护类项目主要涉及对已交付软件的少量功能增加、局部需求变更以及bug修复。这类项目的特点包括短工期、客户响应速度要求快、人力投入少、容易影响现有功能并引入新bug、沟通和测试工作量大、维护请求多及不可预测性强。
维护类项目管理策略
在管理维护类项目时,应采用如下策略:
- 评估变更影响范围,并识别成本、工期和技术风险,以决策是否接受维护请求。
- 指定维护请求的责任人,负责项目全程。
- 跟踪管理维护请求的进展状态。
- 新增需求应使用功能需求描述加界面原型的方式,功能变更需明确描述。
- 与客户电话确认需求,并发送确认邮件,包括角色、功能、目的及验收标准。
- 内部沟通策划会议,包括需求交底、快速设计、工作量估算。
- 定义WBS分解模板,以识别任务并确保任务颗粒度。
- 维护成本核算,记录每日完成任务和工作量。
- 监控项目进展,每周公司级例会汇报。
- 确保新增代码通过静态检查,项目经理抽查是否修改必须改的错误。
- 指定人员进行代码比对和代码评审。
- 系统测试要先测试所有修改或新增的功能,其次是其他功能,最后是全面回归测试。
- 周期性发布版本时定义发布计划。
- QA人员在项目过程中和结束时审计,总结经验教训。
想要了解更多内容?
查看原文:维护项目的管理策略案例
文章来源:
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
425 篇文章
浏览 105.2K
麦哲思科技任甲林的其他文章
敏捷方法中采集的度量数据
在敏捷方法中,要求度量的数据少之又少,可谓简单实用:规模:(1)故事点:用以估算工作量、度量开发效率。工作量: (2) 计划的工作量:用以排定项目计划。 (3) 剩余任务的计划工作量:用以跟踪项目进展。效率:(4)开发速度:每次迭代完成的需求的规模(如故事点),用以估算项目需要的迭代次数。其他度量元根据项目组的实际情况,可以由项目组自己定义。
先敏捷再规范
先敏捷再规范,先做到再写到,先短期利益再长远利益,先实效再完备。 这个策略源于实践。因为一步到位直接采用规范的方法,阻力比较大,效果难以持久,很可能事倍功半,敏捷方法以其短期内可以见效、对已有的开发过程调整幅度小等特点易于开发人员接受,所以可以先敏捷再规范,将敏捷作为通向规范的一个阶段。 芸芸众生,大都是凡人。凡人都是注重短期利益的。只有那些领袖、那些思想家才是目光如炬,站的高看的远。过程改进要从
项目里程碑评审的关注点
(1) 项目工期情况 关键路径是否按计划完成了? 如果没有按计划完成: 提前或拖期的原因是什么? 在后续阶段如何采取改进措施? 对后续阶段的工期有什么影响? (2)任务进展情况 计划完成的任务情况: 计划完成的任务有哪些? 提前完成的有哪些?提前完成的任务工作量有多少? 未完成的任务有哪些?未完成的任务工作量有多少? (3)工作量投入 计划投
四段论提问让ChatGPT更懂你心!
请记住这个四段论的提问模式:场景-目的-任务-验收标准!试着用这种方式来优化你的提问吧。
如何确定测试的重点?
测试投入不足是大多数项目都面临的棘手问题。在此前提下,如何最大限度的提升软件的可靠性呢?本文给出了一个简单框架,帮助组织与项目组定义自己的测试策略、测试重点。
加入社区微信群
与行业大咖零距离交流学习
软件研发质量管理体系建设
白皮书上线