浅谈Atlassian产品搭建的敏捷管理体系（一）概述

翟永超
敏捷管理
DD的博客全面升级，阅读体验更佳（尤其是系列教程），后续不再通过这里发布新文章，而是改到 www.didispace.com 发布啦，奔走相告！点击直达～

准备把敏捷管理的专题在今年完成，主要谈一下Atlassian的实践，先做一下搬运工，讲去年写的两篇弄过来。

Dream big, work smart, deliver fast

使用Atlassian的产品已经有三年多，但是大部分主要以JIRA和Confluence为主，2015年年初加入一创业团队负责技术团队的搭建，从零开始通过部署Atlassian产品、制定开发流程，由于创业团队人手不够，自身也参与了大部分的开发工作，开始有一些考虑不周的地方，随着工作的展开不断调整，通过半年的努力也引来了第一轮的投资，可能创始人国企非技术出生背景的关系，在对技术团队的价值看待上分歧很大，最后还是选择了离开。机缘巧合，马上又加入了另外一个创业团队，依然主要负责技术团队的搭建。这次吸取了之前碰到的一些经验进行改进，并且加入其他一些想法。下面主要就这两次经历，简单谈一下Atlassian的使用经验，可能还有不少问题存在，还请各位大牛指点！

目前我们使用的Atlassian产品

  • JIRA：用来做项目管理、流程控制、缺陷跟踪、版本管理等

  • JIRA Agile：JIRA的插件，主要用来做Scrum敏捷管理

  • Confluence：团队协作工具，文档管理，任务管理，资源管理

  • Fisheye + Crucible：用于做代码评审

  • Bamboo：用于构建持续交付的测试环境

  • HipChat : 用于团队沟通，主要看中可以整合JIRA和Confluence等的实时提醒

其他工具

  • SVN：代码版本库

  • Nexus：私有的Maven仓库，通过VPN快速下载JAR包（天朝网络大家都懂的）

产品安装

安装过程比较简单，这里不加赘述，主要说一些可能要注意的点(大家若在安装中有疑问问题，欢迎留言交流)：

  1. 由于用户不多，这里没有使用Crowd做统一用户管理，所有用户都使用JIRA的用户管理，因此先安装JIRA，然后再安装其他的产品，并将用户管理配置到JIRA的服务器上。
  2. 默认的安装包中不包含mysql的驱动，需要自己复制到lib目录下，并重启服务
  3. Bamboo单独安装一台服务器，作为持续交付的测试服务器。（具体的部署机器的分配视具体配置和资源使用而定）

产品使用

我们采用Scrum的敏捷管理模式，达到快速迭代的效果。下面通过从产品设计开始到开发、测试的过程描述整个软件过程中产品的使用方法

准备工作
: JIRA中创建Project，每个Project管理一个产品
: 修改流程，增加Code Review步骤
: Confluence中创建对应的Team Space
: SVN中创建项目版本库，并在Fisheye中配置该库
: Bamboo所在机器上安装Maven、Java、Tomcat、Nodejs等需要的产品运行环境，并将Maven的仓库路径配置到我们的Nexus服务器所在位置
: 为JIRA、Confluence等根据需要配置邮件提醒

产品设计（Confluence）
: 产品经理在Confluence中完成所有产品设计，编写产品需求文档，每个产品需求文档为一个Epic、多个Story（新版Confluence支持在Confluence中直接创建JIRA的Issue，非常便捷）
: 为达到快速迭代的预期，每个Epic的开发测试的周期尽量控制在1个月，其中具体执行分2-4个Sprint完成开发。
: 附上产品设计原型

会议纪要（Confluence）
: 产品设计完成后，需要经过多次迭代修改，最终定稿，所有会议内容需要记录和转换任务
: 每次会议前创建会议页面，并指定参加者和编写会议讨论内容，只要配置过confluence的邮件提醒，会给参与者发送邮件提示。
: 会议过程中实时记录会议讨论结果或转化的后续任务，并设定任务的执行人和截止时间，用于跟踪任务情况

开发预估（JIRA + JIRA Agile）
: 完成产品设计后，开发经理在JIRA Agile中对Epic中包含的Story先做Story Point评估，有需要再分割的任务创建Sub-Task并分配具体执行人。
: 同步进行UI设计和实体设计

冲刺制定（JIRA + JIRA Agile）
: 完成开发预估之后，开始执行阶段冲刺（我们采用1-2周一个冲刺），根据评估进行分配。
: 每次冲刺结束后，需要创建冲刺回顾文档，分析本次冲刺中好的部分和做得不够的部分，以指导下一次冲刺指定的标准

持续交付（Fisheye + Crucible + Bamboo）
: 冲刺制定之后，进入开发阶段，开发人员的代码提交，通过Crucible完成Code review
: Bamboo构建策略采用定时构建，我们设置在晚上12点进行构建，从SVN中检出代码，跑单元测试，打包，自动部署到Tomcat上，并发送构建报告给项目成员，第二天产品经理和测试人员就可以通过测试环境对完成的任务进行测试，若发现问题，则进入JIRA创建BUG，待后续迭代修正

产品购买渠道

相比之下，官网更便宜一些，第一次搭建的时候在CSDN购买，后来发现了后者，第二次搭建的时候部分产品在官网购买了，相差不大，大家自己考虑咯。

总结

本文主要描述一下各个产品在我们目前团队的过程管理中起到的作用，可能真正用的时候读者还会有不少疑问和不解的地方，欢迎留言交流，后续有空时候针对每个产品再详细写一些经验分享。比如：Bamboo的中文资料一直很少，可能对初次使用有一些迷惑。

本文由 程序猿DD 创作
版权声明：自由转载-非商用-非衍生-保持署名 (CC BY-NC-ND 3.0)
原创不易，转载请注明出处，感谢支持！如果本文对您有用，欢迎转发分享！