在开发项目时，哪些东西需要被管理？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开发的，所以安装还挺麻烦，不是有点经验的运维人员还真装不起来。