维护项目的管理策略案例
发布于 2024-10-02
1069
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
麦哲思科技任甲林
扫码关注公众号
扫码阅读
手机扫码阅读
维护类项目的定义和特点
维护类项目主要涉及对已交付软件的少量功能增加、局部需求变更以及bug修复。这类项目的特点包括短工期、客户响应速度要求快、人力投入少、容易影响现有功能并引入新bug、沟通和测试工作量大、维护请求多及不可预测性强。
维护类项目管理策略
在管理维护类项目时,应采用如下策略:
- 评估变更影响范围,并识别成本、工期和技术风险,以决策是否接受维护请求。
- 指定维护请求的责任人,负责项目全程。
- 跟踪管理维护请求的进展状态。
- 新增需求应使用功能需求描述加界面原型的方式,功能变更需明确描述。
- 与客户电话确认需求,并发送确认邮件,包括角色、功能、目的及验收标准。
- 内部沟通策划会议,包括需求交底、快速设计、工作量估算。
- 定义WBS分解模板,以识别任务并确保任务颗粒度。
- 维护成本核算,记录每日完成任务和工作量。
- 监控项目进展,每周公司级例会汇报。
- 确保新增代码通过静态检查,项目经理抽查是否修改必须改的错误。
- 指定人员进行代码比对和代码评审。
- 系统测试要先测试所有修改或新增的功能,其次是其他功能,最后是全面回归测试。
- 周期性发布版本时定义发布计划。
- QA人员在项目过程中和结束时审计,总结经验教训。
麦哲思科技任甲林
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
425 篇文章
浏览 567.3K
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
麦哲思科技任甲林的其他文章
系统测试缺陷检出密度越大越好吗?
这是一个很有意思的话题。很多人对此困惑。困惑在什么地方呢? 从开发的角度看,是希望系统测试发现的缺陷越少越好,那意味着在开发阶段都把缺陷找干净了。 从测试的角度看,是希望系统测试时把缺陷找干净了,不要遗留给客户去发现。在潜在的缺陷数恒定的前提下,找到的缺陷越多越好。 在组织级确定质量目标时,这个系统测试缺陷检出密度到底是定义为越高越好,还是越小越好呢?系统测试缺陷检出密度的大小能代表产品质量吗? 产品质量只能通过上线后的缺陷多少来衡量,上线后的缺陷密度越小越好...
使用Gompertz模型拟合上线后缺陷收敛趋势
采用Gompertz模型预测缺陷的收敛趋势,简单易行,拟合效果很好!
“大海捞针”式相关性分析的错误
实施CMMI高成熟时需要建立过程性能模型,如果采用了回归分析的方法,则其前提是x与y是相关的,首先要找到与y相关的x。而有的组织在寻找与y相关的x时,采用了一种“大海捞针”式的建模方法,即罗列出来所有采集的度量元数据,指定其中一个度量元作为y,然后在MINITAB中直接建立其他所有的度量元与该y的相关性分析矩阵,从中选择出与该y相关的变量,再去尝试建立回归方程。这种海选式建立回归方程的方法费时费力
正式评估时被访谈人员应该注意什么?
在进行CMMI的正式评估时,被访谈的人员应该快速、准确、条理清楚回答评估组成员的问题,这样才能在比较短的时间内让评估组成员做出正确的判断。根据我的访谈经验,被访谈人员应注意如下的问题: (1) 听清楚问题,再回答问题。 有的被访谈人员可能是由于紧张,没有听清楚评估组的成员问的是什么问题,就答非所问,浪费时间。当你不能确定提问者的问题的含义时,可以要求评估组的成员对问题做出进一步的解释
不练基本功,遇事多返工
俗话说,练拳不练功,十年一场空!基本功与天赋决定了一个人做事成功的概率,决定了一个人成功的层次。
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线