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

原文地址: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 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的提交,莫非跟绩效挂钩?在我看来这是大可不必的,提交错了重新提交一次即可,大可不必在这里钻牛角尖,要不天天改提交,哪天手抖输敲错了就心塞了反而麻烦。至于代码审核也请不要基于提交为单位展开,要不真会逼人去改提交,而且代码审核这种事最好是上下文都要看到才好,不知道上下文的话突然插进来不要谈审核,哪里是那里都不知道。)




©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页