《软件工程之美》材料地址: https://time.geekbang.org/column/article/87787
1 困惑与感悟
困惑:
- 任务不好量化难以估算
- 项目成员对当前项目进度缺少直观感受
- 管理者要花大量时间在任务管理上
感悟:
一切管理问题,都应思考能否通过工具或技术解决,如果当前工具或技术无法解决,暂时由流程规范代替,同时不停止寻找工具和技术。
2 项目管理工具软件发展史
(1) 没有项目管理软件工具的年代
手工WBS分解,再排计划,工作量大,需要很多人。比如阿波罗登月项目巨型计划
(2) 最初的项目管理工具:项目计划工具
MS project 适用于瀑布模型,不适合于管理变更
侧重于项目计划跟踪
(3)基于 Ticket 的任务跟踪系统
侧重于某个计划阶段的项目任务跟踪
ticket的内容
- 标题
- 类型:bug、需求、任务
- 详细内容
- 创建人
- 优先级
- 状态: 未开始、处理中、已解决、重新打开、关闭…
- 指派给人
- 历史记录
- 创建时间
- 附件
- 标签
- 版本
- sprint
- story point
- …
燃尽图( burn down chart)
(4)基于看板的可视化任务管理
侧重于某一个阶段的任务直观跟踪
4 工具选择
- jira https://www.atlassian.com/software/jira
- 微软的Azure DevOps (以前叫 TFS)https://visualstudio.microsoft.com/zh-hans/tfs/?rr=https%3A%2F%2Fshimo.im%2Fdocs%2F5A0wCnmLwn0nCjE9
- github https://github.com/
-国内的如:禅道、worktile、TAPD(腾讯,整合企业微信和腾讯云),云效(阿里巴巴,钉钉和阿里云)DevCloud(华为)
5 我的留言
ms-project这样的计划工具,适合于项目整体计划的把控,人财物的协调。
ticket系统适合于每个阶段任务的安排、变更和任务跟踪。
两者一个全局一个局部,在敏捷项目里应该结合起来使用会比较好。项目整体计划抓大的WBS ,不作过度深入的WBS,而ticket系统可以跟踪管理局部的变更,是计划管理的子集。
所以我的经验往往是先做一个全面的迭代计划(用甘特图),基于此做人员安排和工作安排,并拿此作为汇报的依据向领导汇报。
当然,这种模式适用于项目整体目标清晰,时间节点容易规划、每一阶段工作都容易估算的项目。
6 精彩留言
(kirogiyi)完全手工方式管理的优点在于自由空间大、项目结构松散,比如临时添加需求、临时添加人员、临时改变策略等。一旦管理者没有足够的能力去驾驭项目的整体架构,随着项目时间的推移,项目不是越做越简单,而是越做越难,可能到处都是窟窿,根本没法持续下去,并且责任和义务大部分集中于项目管理者。
尽量采用软件工具管理的优点在于对需求、人员、进度、里程碑等可以进行事无巨细的分解或者组合,明确每个人的职责,明确每件事完成的要求,既可以让参与人员看到长期目标,也可以让他们看到短期目标,而不是遥遥无期。可以这样讲,没有路标的100公里总是比有路标的100公里来得费尽得多,还有就是很容易让参与者失去信心,丧失斗志。
(刘晓林)我觉得辅助计划工具是从项目规划和任务分解出发,以任务之间内在逻辑关系为依据组织任务,优点是能够清晰地看到整个项目的蓝图,缺点是结构化程度太高,不够灵活,不能适应项目执行期间遇到的变化。基于tickt的管理跟踪系统是从项目执行的角度出发,以执行周期为依据组织任务(如一个sprint),注重任务的状态跟踪,优点是灵活,缺点是缺乏结构化,各任务之间的关系不明确,容易只见树木不见森林,因此不适合做项目规划和任务分解。因此,需要将二者结合起来用,在规划和任务分解阶段,用项目规划工具,生成蓝图,最后把分解后的任务做成一个个tickt,做项目跟踪