- 热门文章:
- · 如何组织软件开发团队
- · 如何组织软件开发团队
- · J2EE项目中开发团队的组建
- · 软件项目中的人员管理和团队…
- · 建立杀手开发团队
- · 选择正确的IT顾问
- · 如何把短期顾问融入到你团队…
- · 如何指导软件开发新手
- · Rational Rose介绍材料
- · 杂谈:项目管理的是与非
- · 软件架构训练基础教程之软件应用实践
- · 软件工程领域中项目管理实施体会
任务管理
任务管理
来自lannuo.533.net
概述
一个工程项目是由一系列的任务组成,合理地安排这些任务单元并保证其按时完成,才能保证整个项目进度能够按时完成。为此我们制订以下方法加强任务管理。
一个任务是包含在一个整体计划环境中的,因此作为个体首先要服从于整体计划。
任务管理方法
任务安排:
采用明确任务、明确责任的方式来安排任务。
下达任务必须书面化。要求负责人明确、时限明确、任务表达明确、优先顺序明确。
明确任务的结果。
方法: 我们定制格式化任务安排表,附录《任务安排工作单》即为一个实例。
协调及控制:
统一协调调度任务,及满足每个人的任务量,又避免超负荷。并监督任务能按时按质完成。
合理安排每个人的长期任务和紧急任务。
协调者必须监督进度的进展,及时地调整或督促。
通过日常检查监控任务的进展。其中应特别关注关键路径上的任务。
对重要任务进行正式评审。以保证其完成质量。
方法:
可以在定期举行的例会上总结汇报工作。
为帮助统一管理任务及人力,我们设计了附录《任务安排汇总表》,将任务、人力、进度三维统一表达,即可以看到一个任务由那几个人来完成,及各自的角色,又可以看到每个人当前所承担的所有任务,便于工作量均衡。进度跟踪便于统计剩余任务工作量。
结果考评:
个人工作成绩通过任务完成情况纪录为依据。
任务等级定义
任务分为几个等级,在安排任务时确定轻重缓急,任务等级作为安排者和执行者间交流的一种简洁的信息,包含了安排者在全局的层次上对任务的一种认识和理解,并将这种理解记录下来,并传达给执行者,有利于执行者能理解并按统一调度执行任务。这样可以更好地控制进度,避免关键或紧急任务被拖后。
对执行者来说,可以有根据当前任务的优先级,有条理地安排工作。
任务等级可从以下方面来考虑:
紧急程度:(对任务过程的时间要求)
宽松:时限十分宽松,可以在其他任务后考虑。
一般:时间比较充裕,可以合理安排进度。
较急:有明确要求的时限,且应该尽快着手尽快完成。一般在关键路径上的任务至少有较急的级别。
紧急:立即着手,以尽快的速度解决问题。一般在任务进度可能造成较大影响时定义该级别,比如影响项目进度或影响客户业务使用。具有较高的优先级别,
特急:立即着手,需要时必须加班,需要赶赴现场时必须以最快的速度到达。需要其他人力配合时立即联系相关人员。一般在对客户业务造成重大影响时定义特急的级别。最高优先级别。
注释:紧急程度可能随着时间变动。
重要程度:(对任务本身的影响及作用的估计)
不重要:任务失败不会造成严重结果,能够容忍。
普通:任务失败会造成一定影响,能通过措施补救,不在关键路径上,不影响整体进度,不影响客户业务。
重要:任务重要,对整个系统或项目影响很大,比如在关键路径上的任务,必须保证其成功完成。一般要在工期和质量上给以充分的控制。
关键:影响整个系统或项目的成败,必须给予最高的重视,对任务进行充分的控制,确保成功完成。
任务排序优先级:(任务执行的先后次序,利于有条理的工作)
暂缓:尽量向后安排
普通:按顺序安排
尽快:尽量向前安排
立即:安排在任务列表最前。
以上作为粗略地优先级别估计,方便于优先级的调整,缺省地,任务排序按照紧急在先、重要在先的原则排列。
| 特急 | 紧急 | 较急 | 一般 | 宽松 | |
| 关键 | *****! | ****! | ***! | **! | / |
| 重要 | ***** | **** | *** | ** | |
| 普通 | / | **+ | *+ | + | |
| 不重要 | / | + | - | ||
表中符号代表分值: *:20 !:10 +:5 -:-5 /:不定义
附件一:任务汇总表(示例) 可打印格式见其word文档 - 任务管理
任 务 汇 总 表 项目简称: 阶段日期:| 任务编号 | 任务概述 | 工作量 | 最后时限 | 人员A | 。 | 。 | 人员N | 计划 | 分析 | 开发 | 测试 | 实施 | 反馈 | 完成时间 |
工作量:
d天 h小时 角色:M负责 A分析 D设计 P编码 T测试 J辅助参与 进度:已完成则打勾
附件二:任务单(示例) 可打印格式见其word文档 - 任务管理
任 务 单 任务编号
| 任务负责人签字: | 任务协调人: | |
| 重要级别:□关键 □重要 □普通 □不重要 | 工作量: | |
| 紧急级别:□特急 □紧急 □较急 □一般 □宽松 | 最后期限: | |
| 概述: | ||
| 任务详述: | ||
| 完成日期: | ||
| 任务负责人总结(如果任务延期或失败,请说明原因): | ||
| 评价:□优秀 □良 □基本满意 □不满意 □很差 | ||
| 备注: | ||
- · 创建能轻松迁移的应用程序指南
- · 软件风险管理,防患于未然
- · 项目管理 数据分析项目中的风险管理
- · 论项目管理中的量化管理
- · Project 2000进行项目管理(一)
- · 用Cactus来测试J2ee应用
- · 测试驱动型开发过程
- · 找错——面向对象软件的测试技术与方法
- · 测试、测试、测试--软件测试的理论和实践
- · 浅谈测试驱动开发(TDD)
- · 嵌入式软件的基本测试方法
- · 感悟测试驱动开发
- · 报告软件测试错误的规范
- · 过程决定质量——清华郑人杰教授谈软件测试
- · SQA到底是什么?
- · Loadrunner性能测试一个实例
- · 基于GUI的自动化测试工具
- · 也谈缺陷跟踪管理
- · 应用软件测试要领
- · 持续集成与测试自动化
- · RUP测试过程实践之测试需求与测试用例
- · J2EE开发平台的软件测试技术
- · 软件测试的现实和理想
- · 关于软件测试
- · Rational Test RealTime软件包介绍
- · 嵌入式测试中数据获取的几种方式
- · 谈谈嵌入式操作系统的调试问题
- · 测试中的可靠性分析
- · 压力测试实例
- · 以设计求质量--启用经济高效的全面组件测试
- · 强化测试用例在测试活动中的作用 改进测试用例…
- · 软件产品的可用性的测试
- · 使用 Rational Robot 实现自动化测试
- · 成功测试管理的九大原则
- · 软件测试的现实和理想
- · 关注性能:压力负载
- · 软件测试的革命
- · 前置测试
