敏捷开发----项目管理工具和实践方法

原文地址：https://www.zhihu.com/question/54626462

管理工具：

1.需求管理工具

confluence 是一个基于java企业知识平台，基本上是一个企业博客，他有一些工作流管理功能，也支持很多插件（如UML、思维等等），容易定制。

2.基于敏捷管理的sprint、backlog、开发task、bug管理工具

jira 是一个基于java的issue(问题、事项)管理器，类似的产品有禅道，github也有简单的issue管理，支持很多插件，而且可定制。

 3.代码管理

gitlab 是一个类似于github的东西，它是采用ruby开发的，支持自己的一套智能提交，并且非常开放，易于集成。

4.部署打包

jenkins 是一个java实现的持续集成工具，图标是一个绅士小老头很搞笑，在我这边一般它会工作在触发后执行打包脚本，进行自动化的集成部署，完成后会发送邮件提示，通知结果。后期我这边将它和nexus进行了整合，改变了一些使用方法，但是大致还是这样子。虽然这个是java写的，但是完全可以用作其他语言的持续部署，它很神奇，很省心，也很易用。

费用？

jira & confluence & 插件

也应该看到了，我这边用的是正版，不推荐D版，请支持正版。
官方有费用的介绍，国内有代理，可以开发票是可以比较方便走账的，价格相对而言还是比较可观。
最低有10人10美元授权，其实巧妙分组使用此授权可以在更多人数的团队中使用(就是说不是一套JIRA)，但记得其实人家授权协议中是不同意这样子做的（其实我也没仔细看）。

插件
插件大多支持试用一段时间，大可以装上试用下，感觉好了再付费。
google可以搜到很多人的评价，在 http://stackoverflow.com 和 Hot Questions - Stack Exchange 中也有很多评论可以参考，慢慢搜索就行了。

对硬件的要求？

内存：
在实际使用中发现，jira 和 confluence 很吃内存，分配小内存使用起来效果并不好，我在内部服务器上配置了48G内存，给乱七八糟的服务去使用，使用起来体验还可以。

处理器：
对于cpu等吃的并不厉害。

硬盘：
对于硬盘 iops 相对于内存次要敏感，我这边是配置了两张 ssd 做的 raid1（mdadm做的），使用中感觉还可以。

网络：
延时还是要低些吧，你放到美国的vps上300多ms的延时估计用起来是不会开心的。

在实践中需要应用的其他工具或产品？

linux服务器 应该不是必须的？据说可以用windows？我没考证过，所以写在这里吧。

tomcat 这是apache下的开源项目，是一个 JSP/Servlet 容器（就是跑java网站用的服务端），另外还有jboss等，但是我们用不到ejb，所以tomcat是个好选择。

nginx web服务端，也可以作为反向代理（实际上用作反向代理比较多）

postgresql 一款学院派风格的关系型数据库（虽然也支持nosql），性能很不错，使用起来坑也比较少，对于一些特性他比mysql兼容的好，我这边大量在使用。这个不是必须的，用mysql，sqlserver（这个我没试过）是可以替代的。虽然他支持nosql数据库，但还是不要用的比较好。

双向证书验证 一般的https是单向的，即服务端装证书，客户端验证，而双向证书顾名思义就是双向的，客户端也要有，服务端会验证客户端的证书，没证书，访问不了。
我这边吧服务都放在了公网，虽说代码本身是不怕同僚离职时带走，但是考虑到其他方面这显然不太安全，所以采用了双向认证的方案。
在实施中吧个人证书与自建CA的根证书分发给同僚，进行安装后即可访问，但是没有证书访问页面就会404，制造出没有这个页面的假象。

自建CA 因为采用了公网部署双向证书验证的方案，口袋里又没有钱都去用正规CA的证书，所以这个基本不可少。

可选技术？

docker 这个当下非常火，不必多说了。在实际使用中我尝试过吧这几个项目部署到docker里，但是就体验来说效果不好。在实际使用中主要是吧 docker 来结合 spring cloud 来使用。

nexus 一个开放的自建maven，可以代理中央服务器，也可以上传内部的包让团队成员共享与使用，做java方面的开发这个可谓是不可不用。

ss-local 这个我不展开了，毕竟你懂的。这是一个神奇的梯子工具的客户端，我在内部服务器（即跑这些应用的服务器，而不是内网中的服务器）中进行了部署，连接到东京的linode，来给nexus加速。在安装这一堆乱七八糟的过程中使用此神器可以大大加速下载速度，如果你在国外应该用不到这个。

privoxy 一个代理服务器，ss-local提供的是一个socks5代理，但是毕竟用socks5很多地方不方便，比如终端下并不能简单的使用，而很多应用也只支持使用http代理，所以就用它来进行socks 到 http 的转换。

jira git 插件 一个可以和git库进行集成的插件，对双向证书支持不好，只能在nginx给此插件开小灶不走双向认证。

jira gantt-charts 插件 一个jira展示甘特图的插件，体验很不错，排版容易混乱，但并不影响使用。

confluence http://draw.io 插件 画图用的，基本上常见的图都支持，但是体验一般，可以安装其他插件进行优势互补。

jira 和 confluence 中文汉化包 顾名思义，对于像是我这种只有小学英语水平的人尤为重要。

zsh 一个神奇的shell，用他来增加终端使用git的体验

oh-my-zsh 顾名思义，用zsh几乎必备

如何使用这一堆乱七八糟？

至于集成与账号创建等我会在配置安装章节进行阐述，在此只提供一个用例。

感觉码字好麻烦，只写基于默认的情况下一种符合大多数情况的案例吧，供大家参考：

项目定下来后首先用 jira 建立项目，首推：

这个使用起来效果是很不错的。另外你也可以很方便的建立自己的类型，让他符合自己的需求，但在此不展开了。

然后进行必要的项目配置，这里的甘特图选项请设置好，要不甘特图有些功能会有问题。

创建版本

然后跑到 confluence 建立库，推荐选择这个：
同理也可以建立自己的来用（不复杂，摸索下即可）。
选好项目关联好，并创建:

这时候一般会开个会议大家考虑下战略、任务怎么分配以及怎么下手去干，这时候创建一个会议记录。


对会议内容进行记录。
在参会内容中对参与人员进行'@'即可： 

其他按照模板项进行填充，其中行动项请务必填写，这个很实用。

这样子保存后参会人就会收到提示，如果配置了邮箱提醒还会看到邮件。
然后扫中展示的行动项，建立jira任务：

此时会看到已经关联。
jira中也已经有了
分配好经办人，新建一个sprint并且把任务拖进去将经办人分配好，在此例中分配给我了我自己。如果要拆分子任务也请此时进行。

然后开始sprint，这时在甘特图中已经可以看到了，在active sprints中也可以拖动任务了。

任务拖动到其他阶段后，confluence就会更新，

大家都能看到做到哪里以及做的怎么样了。
在这里因为要求做需求，创建一个产品要求在里面。左侧 产品要求->Create product requirement 把需要的项目都填好。
问题过滤器中这里就直接获得所有没结束的，实际使用中可以按需要获得，比如获得属于这个需求的，等等。
我采用的是列表展示20条，这会导致排版不好看，但是实用些，如果感觉不舒服可以换形式，或者减少展现字段。


剩下的按照模板填写。
保存后就会看到调用的问题
一个比较可用的方案是自定义模板，但是在此就不展开了，有需要可以查看官方教程。
决策日志，和回顾等大同小异我不再赘述。
开发过程中，一定要使用jira的智能提交，这非常好用。
在gitlab中创建版本库，并且添加必要的README等等，另外就是配置好 Project services 集成好jira 

点击 test 试试看是不是配置正确。点击issues 来试试是否能跳到展现页面。
在gitlab里给这个项目加入一个JIRA的新成员
去jira git 插件中查看webhooks 

吧webhooks给设定好（在你的jira中git插件里面查看，就上面那个）
保存测试成功了才可以。
回到JIRA去更新下GIT插件的索引

把项目克隆到本地然后测试一下智能提交，确定ok。
为了方便演示智能提交加上这个项目还没README，所以就拿加入README来演示，首先在JIRA创建一个任务并且开始做这个任务。
然后我们来做这个任务（这里你也看到我用了zsh和oh-my-zsh，其实是可以用ga gp 之类的，你也可以用用看）
这里很显然我配置过key，没有配置请先配置。
（平时我使用了ssh的~/.ssh/config 配置文件来设定服务器的，此处可以直接使用常见的git形式，不必像这里一样去ssh://，此处仅为演示，实际使用推荐还是采取ssh config配置文件+远程地址无关的形式比较好，因为这样子换域名换端口，同僚可以不必一个一个去修改git的config，而是改一个 ssh config 即可）
这时如果你在另外一个屏幕上开着JIRA的话应该已经自动移到Done里面了（并不需要刷新）
甘特什么的也已经更新了，要是关注过问题的人也会收到提醒。
这种神奇的效果就是刚刚那句 commit 命令，这个就叫做智能提交，gitlab-shell会去调用gitlab，gitlab又去通过刚刚设定的web钩子去拽一下jira，jira去刷新库（以下不再赘述运行过程，不必要的感觉），这个实际使用中体验还是不错的。这里用的这个是改变当前状态的。格式是：

git commit -m "JIRA的任务KEY #目的状态 解释"

如果你有多个任务可以用空格间隔重复前半部分，不需要提交多次。
对于智能提交jira官方是有详尽说明的，我放连接，需要的可以去慢慢研究，一般在使用中我是会弄个环境变量或者脚本来方便提交 issue key ，毕竟有的项目会把KEY搞得很长，输入起来并不是很方便，有的同僚是采取IDEA中设定ISSUE的方式，这些都是比较好的办法。
Atlassian Documentation

（如果没有设定过本地 git 的 config 请按照gitlab下面的步骤来做一下，不去设定的话会发现提交后不会关联到对应用户，它是按照邮箱进行的索引，所以邮箱是尤为重要的）

（另外扯一句题外话，我曾经见过一些同行，不知道代码洁癖还是有要求怎么的，git提交错了，push了，消尖了脑袋去改git的提交，莫非跟绩效挂钩？在我看来这是大可不必的，提交错了重新提交一次即可，大可不必在这里钻牛角尖，要不天天改提交，哪天手抖输敲错了就心塞了反而麻烦。至于代码审核也请不要基于提交为单位展开，要不真会逼人去改提交，而且代码审核这种事最好是上下文都要看到才好，不知道上下文的话突然插进来不要谈审核，哪里是那里都不知道。）