V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
爱意满满的作品展示区。
zhongshu
V2EX  ›  分享创造

软件项目管理工具和实践

  •  
  •   zhongshu · 2017-08-28 10:47:51 +08:00 · 4480 次点击
    这是一个创建于 2678 天前的主题,其中的信息可能已经有所发展或是发生改变。

    项目管理管什么

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

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

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

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

    任务管理

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

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

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

    缺陷管理

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

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

    文档管理

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

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

    代码管理

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

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

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

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

    第 1 条附言  ·  2017-09-01 16:35:06 +08:00
    补充代码管理的两张图,一张是代码历史的查看:

    ![代码历史]( http://upload-images.jianshu.io/upload_images/7397268-1d635f0184afe3a0.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

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

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


    ![代码统计]( http://upload-images.jianshu.io/upload_images/7397268-c1343b3583b698c4.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
    第 2 条附言  ·  2017-09-01 16:39:04 +08:00

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

    代码历史

    代码统计

    13 条回复    2017-09-04 13:02:36 +08:00
    chemzqm
        1
    chemzqm  
       2017-08-28 18:28:57 +08:00
    > 一些在线项目管理工具比如 github
    应该是搞代码托管的社交平台更严谨一些。
    elviscai
        2
    elviscai  
       2017-08-29 00:06:43 +08:00 via Android
    位于 http://www.cloudtopo.com/ 的网页无法加载,因为:

    net::ERR_CONNECTION_TIMED_OUT

    北京联通 100M 光纤

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

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

    港真,全文看完,只留下七夕的悲伤。😂
    wshcdr
        3
    wshcdr  
       2017-08-30 12:18:29 +08:00
    还有 wiki 呢
    zhongshu
        4
    zhongshu  
    OP
       2017-08-31 20:38:45 +08:00
    @elviscai 确实是软文(如果是硬广不会允许我们发),但希望是对大家有用的软文。 抱歉,我们在更新网站导致了网页打不开,请再尝试打开,如果有合理的意见非常欢迎在这里探讨,无论什么意见都可以。

    支持 FTP 的文档管理,是我们的一个特色,可以大大方便大量文档的上传和整理,这点应该没有争议。否则你可以试想一下,如果你的项目有几百份文档,一一上传是蛮繁琐的事情。
    zhongshu
        5
    zhongshu  
    OP
       2017-08-31 20:42:56 +08:00
    @wshcdr 谢谢你的建议,我们考虑过 Wiki,从格式上看,绝大多数 Wiki 不如 Markdown 易用(这点不知你是否赞同?)所以我们现阶段优先实现了对 Markdown 的支持,我们也考虑过将 Wiki 和 Markdown 结合起来,可惜的是,暂时我们还没有想清楚格式上如果将 Wiki 的站内链接和 Markdown 结合起来,这个功能也许我们在想清楚之后会考虑实现。
    elviscai
        6
    elviscai  
       2017-09-01 00:47:51 +08:00 via Android
    @zhongshu 我们的文档管理用 @/自己部署的 Seafile,自带版本历史和服务器端的回收站。
    xuezher
        7
    xuezher  
       2017-09-01 09:18:37 +08:00
    为何没有需求管理?
    zhongshu
        8
    zhongshu  
    OP
       2017-09-01 09:21:33 +08:00
    @chemzqm 是的,github 归为”代码托管的社交平台“更严谨一些,谢谢指出,类似的还有 gitlab 等。
    zhongshu
        9
    zhongshu  
    OP
       2017-09-01 10:18:55 +08:00
    @elviscai 感谢分享,Seafile 作为一个类似 dropbox 的软件,在共享、同步文件方面非常强,这点项目管理软件确实做不到。我的一点理解是, 如果团队的文档工作比较多,并且需要大量的修改和同步,操作系统类型多(包括移动端),seafile 很合适。反之,项目管理软件这边的优势在于,和项目管理的工作集成在一起,比如按项目隔离,按项目授权等,且通过浏览器或资源管理器访问,使用较简便。 另一个小的差异是项目成员是否介意安装客户端,Seafile 需要安装独立的客户端。
    RyougiShiki
        10
    RyougiShiki  
       2017-09-01 12:57:47 +08:00
    我原来公司用过 bug 追踪测试软件。还有 worklite 这种比较知名的在线工具。功能比较相似。
    然而大家怕麻烦还要再学习那一点新工具。所以还是 QQ 群用的最多。但公司人事和其它部门又要钉钉。
    产品人员对接程序员是文档和口头。
    技术组长是 excel 甘特图。
    感觉就是一个公司从来没统一过,郑州。
    zhongshu
        11
    zhongshu  
    OP
       2017-09-01 15:42:08 +08:00
    @xuezher 需求管理有两个问题,一个是不标准化,每个公司对需求管理的想法都不完全一致,比如需求跟踪、需求基线,我们在我们另一个产品上做过,基本上很多客户都需要做一些定制化的工作,这样就不适合做出一个标准产品,当然也可以考虑用简化的方式做一个。 另一个考虑的点是,我们在 Topo 上偏向于使用敏捷迭代的开发方法,通常这类团队,可以用任务完成大部分的需求跟踪,我自己的团队,也是使用这种方式来跟踪需求,不知道你们对需求管理的痛点在哪里,可以继续探讨。。
    zhongshu
        12
    zhongshu  
    OP
       2017-09-04 08:56:13 +08:00
    @elviscai 还有一个文档管理方法,是我个人很喜欢的,就是用 Svn,格式试用 Markdown,这种方式最大的好处是多人编辑方便,甚至 Merge 也很方便,但是缺点就是编辑和查看都需要专门工具,我个人还蛮喜欢这个方式,但是整个团队要使用这种方式,需要一点学习成本(格式和工具)。
    zhongshu
        13
    zhongshu  
    OP
       2017-09-04 13:02:36 +08:00
    @RyougiShiki 这个情况很普遍,我觉得原因在于管理(领导),领导对工具不重视,或者说领导也不知道该做哪个选择。 从技术上讲,没有哪种工具最完美,选择团队最合适的一个,统一即可。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   948 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 28ms · UTC 21:01 · PVG 05:01 · LAX 13:01 · JFK 16:01
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.