软件项目管理工具和实践

[zhongshu]

项目管理管什么

一个好的项目管理工具，应该可以大大提供项目团队的工作效率，而不是降低。从这个角度出发，我们精挑细选进行比较，并开始试用Topo 项目管理系统，在 Topo 中， 我们看到提供了 任务、缺陷、文档、代码四个最基本的模块，正是我们比较看重的几个管理要素。我们希望使用 Topo 项目管理系统，既直观方便，又效率倍升，这是我们对项目管理工具的理解。

好的项目管理工具可以为项目整个团队服务，也就是项目中个的各个角色都可以从项目管理工具受益，企业领导、项目经理、项目参与人员，这些角色对项目的关注重点有所不同，必须从他们各自的角度去考虑相应的功能和 UI 来满足多层次的项目管理需求。

• 企业领导关注多个项目整体的进展。
• 项目经理更关注自己的项目。
• 项目参与人员主要承担项目的具体工作，必然更关注自己的工作，同时也关心项目的进展情况。

项目管理有很多方法，传统派可能倾向于做计划，看甘特图，敏捷派偏向于快速迭代，没有哪一种一定更优，但不同的方法适合不同的团队，比如互联网项目团队因为项目的特点，需求变化快，项目周期紧张，通常倾向于使用快速迭代的方法。Topo 使用了我们比较认可的相对折中的一个方案-严谨的迭代。

任务管理

迭代意味着我们不需要总体的计划，我们倾向于快速制定并分配任务，并随着项目进展，不断更新，团队成员专注于近期任务和目标，严谨体现在我们给任务有确认过程，任务的完成是经过了确认人的判定；任务有历史，所有的操作可以回溯。

为了交互更有效率，Topo 提供了看板的操作方式，看板的方式已经被证明是一个项目进展的好的展现方式，我们也借鉴了看板的优点，看下图：

在看板上，标注了任务的工作量（图中黑色圆圈标注的 15 ），当前处理人（右上角的名字），标签（任务下方的小方块），过期时间（日历图标），这些信息有助于我们快速定位一个任务。

缺陷管理

对于交付产品类项目，缺陷管理是个核心功能。和任务管理的设计思想类似，我们倾向于严谨，Topo 的缺陷有严格的生命周期，从创建-解决-验证-关闭，按部就班跟踪每个步骤，即缺陷不经过验证，是没办法关闭的，有些团队认为这样操作会繁琐一些，但我们认为这样更严谨。

很多人在提交一个新的缺陷报告时，不习惯写出具体的文字，而是习惯贴图，因为贴图可以更直观的表达一个缺陷，Topo 提供了剪贴板的粘贴操作，以支持在提交缺陷时快速贴图，这是一个小的细节。

文档管理

文档是大部分项目的伴生产品，文档管理也成为项目管理的重要组成部分，Topo 提供了树状目录结构的文档管理，项目可以将大部分文档（甚至其他文件）放置在文档管理中，便于集中管理，有别于大部分在线项目管理工具，Topo 提供了文档的多版本记录，每次更新文档之后老版本依然存在，可以方便对重要的文档追溯历史，这其实是我们认为很重要的一个功能，让文档管理变的严谨。

从效率角度，浏览器方式的文档管理在批量操作上显然缺乏效率，大部分人习惯于本地的方式操作文档，Topo 集成了 FTP 访问功能，为什么选择 FTP，而不是 HTTP 或其他协议，是因为 FTP 可以和 Windows 的资源管理器直接集成，通过桌面上的我的电脑，访问 FTP 地址，可以直接访问 Topo 里的项目文档库，这对大部分用户来说是个效率的巨大提升，同时对于大量文档管理 ，也提供了可行性。

代码管理

对于有源代码的项目(软件、互联网等行业)，代码管理成为一个必备需求，恰恰是大部分在线项目管理工具缺乏的一个特性，一些在线项目管理工具比如github，可以支持代码的管理，但是需要使用托管的代码库。对于大多数企业来说，使用托管代码库无论从安全性还是可访问性，都不及本地代码库，因此这也是我们选择本地部署系统的一个重要原因。我们为代码管理划定了几个需求目标：

• 代码的快速浏览和查看历史、变更
• 代码与任务、缺陷的双向关联
• 代码的同行检视

这几点 Topo 都提供了相应的解决方案，参考下图：

通过一段时间 Topo 工具的应用，我们在我们的项目中可以更有效的管理我们的任务、缺陷、文档和代码，同时在 Topo 的网站和公众号里有一些资料，也辅助我们顺利的使用这个系统。

补充代码管理的两张图，一张是代码历史的查看：


这个历史查看和小海龟类似，是实时更新的，但是相对小海龟提供了非常重要的强化信息，即图中右侧 commit 的修改量，我们相信这个信息对于项目经理很有意义，也就是项目经理可以直接判断出一次更改的大概范围，而无需调取 diff。

另一个重要的功能是代码和任务、缺陷的双向关联，双向关联的意义无需解释了，上图中中间的红色标签就是从代码到缺陷的关联，可以直接跳转，同时在缺陷一侧，Topo 会自动记录相应的 Commit，从对应的缺陷可以跳回这里。这个双向关联对于代码管理非常重要，所有的软件项目都应该配备这样的工具。最后是喜闻乐见的统计图了（按人统计的图就不上了），大家都喜欢看 ;)



补充帖子缺省是纯文本，好吧，再补上上面的两张图：

[chemzqm]

> 一些在线项目管理工具比如 github
应该是搞代码托管的社交平台更严谨一些。

[elviscai]

位于 http://www.cloudtopo.com/ 的网页无法加载，因为：

net::ERR_CONNECTION_TIMED_OUT

北京联通 100M 光纤

东西看不到，就说说软文吧——上开就是「我们的实践」，然后画风一转，企业领导和项目经理就是别人家的了……

还有那个 FTP 文档管理……文档版本的协作靠自行约定的文件名来吗？

港真，全文看完，只留下七夕的悲伤。😂

[wshcdr]

还有 wiki 呢

[zhongshu]

@elviscai 确实是软文（如果是硬广不会允许我们发），但希望是对大家有用的软文。 抱歉，我们在更新网站导致了网页打不开，请再尝试打开，如果有合理的意见非常欢迎在这里探讨，无论什么意见都可以。

支持 FTP 的文档管理，是我们的一个特色，可以大大方便大量文档的上传和整理，这点应该没有争议。否则你可以试想一下，如果你的项目有几百份文档，一一上传是蛮繁琐的事情。

[zhongshu]

@wshcdr 谢谢你的建议，我们考虑过 Wiki，从格式上看，绝大多数 Wiki 不如 Markdown 易用（这点不知你是否赞同？）所以我们现阶段优先实现了对 Markdown 的支持，我们也考虑过将 Wiki 和 Markdown 结合起来，可惜的是，暂时我们还没有想清楚格式上如果将 Wiki 的站内链接和 Markdown 结合起来，这个功能也许我们在想清楚之后会考虑实现。

[elviscai]

@zhongshu 我们的文档管理用 @/自己部署的 Seafile，自带版本历史和服务器端的回收站。

[xuezher]

为何没有需求管理？

[zhongshu]

@chemzqm 是的，github 归为”代码托管的社交平台“更严谨一些，谢谢指出，类似的还有 gitlab 等。

[zhongshu]

@elviscai 感谢分享，Seafile 作为一个类似 dropbox 的软件，在共享、同步文件方面非常强，这点项目管理软件确实做不到。我的一点理解是, 如果团队的文档工作比较多，并且需要大量的修改和同步，操作系统类型多（包括移动端），seafile 很合适。反之，项目管理软件这边的优势在于，和项目管理的工作集成在一起，比如按项目隔离，按项目授权等，且通过浏览器或资源管理器访问，使用较简便。 另一个小的差异是项目成员是否介意安装客户端，Seafile 需要安装独立的客户端。

[RyougiShiki]

我原来公司用过 bug 追踪测试软件。还有 worklite 这种比较知名的在线工具。功能比较相似。
然而大家怕麻烦还要再学习那一点新工具。所以还是 QQ 群用的最多。但公司人事和其它部门又要钉钉。
产品人员对接程序员是文档和口头。
技术组长是 excel 甘特图。
感觉就是一个公司从来没统一过，郑州。

[zhongshu]

@xuezher 需求管理有两个问题，一个是不标准化，每个公司对需求管理的想法都不完全一致，比如需求跟踪、需求基线，我们在我们另一个产品上做过，基本上很多客户都需要做一些定制化的工作，这样就不适合做出一个标准产品，当然也可以考虑用简化的方式做一个。 另一个考虑的点是，我们在 Topo 上偏向于使用敏捷迭代的开发方法，通常这类团队，可以用任务完成大部分的需求跟踪，我自己的团队，也是使用这种方式来跟踪需求，不知道你们对需求管理的痛点在哪里，可以继续探讨。。

[zhongshu]

@elviscai 还有一个文档管理方法，是我个人很喜欢的，就是用 Svn，格式试用 Markdown，这种方式最大的好处是多人编辑方便，甚至 Merge 也很方便，但是缺点就是编辑和查看都需要专门工具，我个人还蛮喜欢这个方式，但是整个团队要使用这种方式，需要一点学习成本（格式和工具）。

[zhongshu]

@RyougiShiki 这个情况很普遍，我觉得原因在于管理（领导），领导对工具不重视，或者说领导也不知道该做哪个选择。 从技术上讲，没有哪种工具最完美，选择团队最合适的一个，统一即可。