谈谈项目管理

2019独角兽企业重金招聘Python工程师标准>>>

一，介绍

    首先介绍下团队使用的项目管理工具。

jira：JIRA 是一个缺陷跟踪管理系统，为针对缺陷管理、任务追踪和项目管理的商业性应用软件，开发者是澳大利亚的Atlassian。

svn：由于历史原因没有使用较为流行的git。

qq：没错，就是qq。沟通大多用的是qq。

jenkins：jenkins据说不是很靠谱。但是简单的上手难度加上丰富的插件，最终还是选择了它。

 

二，开发环境搭建（**）

对新的开发人员，一般都会有开账号，装系统，配环境，跑代码这些过程，我自己发现每次都低估这些工作的耗时，以前就发现有时候不小心就一两天过去了还没跑起来代码，一两周还没搞清楚目前产品的功能。

理想的开发环境搭建是开发人员不必手工进行复杂的配置，编译等工作，项目就可以跑起来。目前开发环境搭建方面做得还是不错的。开发人员只需要checkout代码，npm i 依赖， npm run dev 就可以跑起来。对于代码调试，合并，打包，发布都有进行封装。直接查看写好的script就可以了。每个模块都有对应的文档。

跑起来到能写代码中间还差一个环节就是，开发人员要了解业务。新的开发人员可以通过浏览产品的需求文档来了解产品功能。 目前做法是需求文档保存在wiki，开发任务进度保存在jira。

存在问题：

1. 项目没有一个软件包（svn，node，npm，vscode等），插件列表。开发人员需要自行安装好这些环境后才可以按照上面的方式顺畅的操作下来。
2. 缺乏项目白皮书，让新的人员快速全面的了解系统业务，目前即使有资料，也是残缺而且分散的。

三，代码管理(***)

代码是托管到中央svn仓库的。代码的分支管理，打tag，发布回滚也是有规定的。代码重用是一件说起来容易做起来难的事情。对于个人来讲，我们认为自己实现比直接重用更容易，才会重用。 没有，是认为。不一定自己实现真的容易，完全取决于开发人员的主观认识。 我们经常碰到开发A引入了一个包，开发B引入了另一个相似功能或功能重叠的包，或者开发A引入了一个不安全或者不兼容的包。所以合适的做法是需要加新的组件或者替换正在使用的都可以一起讨论之后加入

存在问题：

1. 代码提交信息杂乱无章，有强行拼字数嫌疑（我几乎不用中文写message的原因就是这个）。使用git的话就不存在这样的问题，因为你代码 添加到本地暂存区，完成一个模块统一commit到中央仓库。
2. svn  和 jira 没有关联，开发完成后需要自己手动的去操作jira，这个还不是重点，重点是如果后端代码写完提交了，忘记和你说了，也没在jira上更新状态，就白白浪费了前端的开发调试时间。如果后端svn 提交一个信息，直接操作jira resolve 对应issue，然后前端就会收到邮件，然后前端就可以去接口列表查看测试接口。但是话说回来，svn 没有本地仓库的概念，让开发者完成全部功能再提交代码也不是很合理。
3. 没有code review 。 代码复用，可维护性无从谈起。更不要说什么代码复用，架构伸缩扩展了。

三，需求管理（**）

下面这种图是我抄的一张图，描述了从需求产生到发布生产的一系列流程。这个流程是比较正规和高效的。

存在问题：

1. 后台提交代码不会自动生成接口列表。

四，开发任务分配与追踪(****)

总结为三点：晨会，周报，sprint会议。

晨会是项目成员了解项目进度的最有效的手段。 周报是对项目整体进度的把控。sprint会议一方面回顾上个版本的问题，一方面计划下个版本的任务，这个阶段进行充分沟通可以充分避免项目人员对项目细节理解的偏差！

存在问题：

1. 会议时间安排完全没有考虑任务依赖关系。比如前端一个任务开发需要10h。 周四计划开始，那么预期测试时间是周一，由于后端接口周五才提供，那么我完成必然要加班。当然这种依赖关系还有很多，比如模块依赖，底层组件依赖等。
2. 会议完成后前后端并不会约定接口，而是等待开发完成后告诉前端接口格式。
3. 晨会时有时无。
4. sprint 讨论不够充分，经常功能做完才发现理解不一致，导致重做，甚至重新设计。

转载于:https://my.oschina.net/wanjubang/blog/887594