敏捷开发系列学习总结(6)——你用什么工具管理项目

在开发项目时,哪些东西需要被管理?1,当然是需求、设计说明。2,界面原型。3,项目进度。4,bug。我团队目前就是这些资料需要被管理。读者们有其他的好东东,就在评论里分享吧。这些资料跟git上保存的代码不同,大多是文档式的。项目进度和bug的管理,这些就属于开发流程管理了,更需要专门的工具进行管理。

我们一直用敏捷方式开发项目,既然就敏捷,就需要短、平、快。当时,在挑项目管理软件时,小编我是试用过好几个。比如开源的kanboard(看板),这个是白板式的,但唯一不足的是创建的任务不能移动。比如我今天这个任务创建了,状态是待开发。几天后,我觉得时机成熟,这个任务应该移到开发栏中,但就是移不了,只能在开发栏中新创建。于是,我放弃了。国内开发的chan道,我还买了他们的云服务,但用了后发现总体是不错的,功能丰富,但问题也在丰富上,一丰富,就繁琐了。比如,我创建了一些bug,会发生自己都找不到的情况,而且要学会这个工具,还得花不少时间。敏捷嘛,就需要短、平、快,工具嘛最好就一操作就会,还需要我们花心思学,在知识爆炸的今天,我是没这个心思去学一个管理工具了,于是我也放弃了。

Redmine,我后面用了是这个工具。这工具确实不错,简单易懂,一操作就上手,而且功能也蛮丰富。

1、分配任务Task

负责人可创建Task及其子Task,并指派给相应的人,在Task描述里写清任务的具体内容。Redmine可绑定邮箱,相关人就会收到任务通知。技术员对不理解的、有疑问的地方进行回复询问,然后等待负责人的解答。而且大家都可以检索到什么时候做了什么事?遇到了哪些问题?等等。

2、任务跟踪

计划,最重要的是什么?当然是执行,执行最重要的是什么?我觉得是监控,实时修正。在软件开发中,千万不要做甩手掌柜,任务布置了就不管,然后快到交付了,才发现下面人做得东西不行,方向错了。或者,发现时间不够用,要延迟。如果项目负责人无法做到及时的延期风险控制,那是非常不专业的。

Redmine的甘特图能帮上你。技术员每天下班前更新自己的任务进度,登记工时,并写上今天完成的内容。负责人可以随时看到这些进度和任务内容,通过项目甘特图,就能及时发现风险并对其进行事先规避。

3、令人反感的周报

一般程序猿们对写周报是很反感的,每次都要浪费时间回忆这周做了什么,还要计算好工时,没事就编故事,滥竽充数让老板知道你没偷懒。

因为Redmine每天的工作有Task记录,并有工时记录,所以周报只需要点下鼠标就能导出周报了,上面有本周详尽的工作内容及消耗的工时。

4、项目文档管理

Wiki,我就不介绍了,反正这工具用来分享文档还是挺不错的。

Redmine它内部是集成Wiki的,所以Redmine有一个明显的好处是它的Wiki和项目、版本、具体Task是结合在一起的。比如在某个Task中需要出一个小文档,那就可以写一个Wiki页面,并附在Task中。

5、线上系统操作

线上系统的升级、维护、事故处理等都需要严格的操作手册,特别是与Money有关的服务。如果谁一不小心,公司就会损失大把银子,操作人可能会被挨一顿骂,项目负责人自然也会被连坐,要求加强流程管理。

线上操作人可创建一个Task,写清操作的目的、步骤、以及每一步的检查。写完后他可找其他人进行Review,检查步骤是否合理?是否有遗漏?有问题就回复--提出建议,没问题就回复--Review通过。

通过后线上操作人就严格按步骤执行,关键操作时,最好也让审核人在旁边监督操作,完成后让审核人检查执行结果。

这样双人的“结对编程”,一旦出现问题,能做到有据可循,以后追责,改正都是非常便捷的。

当然,工具能否发挥积极作用,根本的原因还在于人。一是项目组的成员需要习惯用Redmine记录自己的工作;二是负责人要不断去检查Redmine,有问题就指正,并把使用Redmine推进项目进展作为一种理所当然的事情。

Redmine有点不好,是它是基于Ruby开发的,所以安装还挺麻烦,不是有点经验的运维人员还真装不起来。

转载于:https://www.cnblogs.com/zhanghaiyang/p/7212766.html

你可能感兴趣的:(敏捷开发系列学习总结(6)——你用什么工具管理项目)