关于Jara和Zentao的个人观点
个人使用禅道大约有三年左右,之前也到处找合适的项目管理工具,当时在尝试Scrum实践,用了一堆号称支持Scrum的,除了好多个纯粹从模仿Scrum看板入手的项目管理工具,也是听说了禅道,然后拿来试用,然后就一直使用到现在,目前在事业部内部所有基于互联网分发的软件产品都用禅道来实施产品开发项目。
因为早几年也简单评估Jira,虽然现在不用了,不过貌似很多同行对这个感兴趣。现搜现聊,说下我对于两者的理解。
先说说几个概念
1、企业级系统 & 部门(团队)级系统:这两个词应该有其它意思,不过这里的概念是我编的,企业级系统有专门的企业层面的运维部门负责采购、支持,帮助企业实现业务收入或运营保证,而部门(团队)级系统通常是使用部门运维,帮助部门(团队)实现工作效率提升价值,这两个概念的不同,一方面是系统展现出来的功能和逻辑差异,另一方面是包装的力量。所谓的“企业级解决方案”是Sales喜欢的热词之一。
2、产品定位:产品定位是供应商(或开发商)对产品功能、价值的确定,产品定位终被用来圈定客户和用户,在产品生命周期中,需要不断的策划产品功能取舍,所有举棋不定的功能背后,高判断依据就是新功能是否和产品定位相符,或者反过来说,到底要不要调整产品定位以适应新的市场变化。
Jira的历史和定位
现在可以来看看Jira的历史的,Jira曾经好的缺陷管理系统之一,Jira的忠实用户中有很多是软件测试领域的管理者,另外,缺陷分析图表是所有开发管理者感兴趣的,通常这些报表都是测试管理人员提供给更高级管理者的。看Jira官网首页产品宣传文字“
JIRA is the project tracker for teams planning, building and launching great products.Thousands of teams choose JIRA to capture and organize issues, work through action items, and stay up-to-date with team activity.”
从这段话,尤其是后半断,仔细看下,Jira的核心诉求还是围绕issue展开的,以issue驱动管理、分工、以及团队协作,进而实现项目的规划、建设,终完成产品开发。
Jira的这个产品定位表达的非常清晰,这个系统的竞争力一定是从Issue展开,在软件工程中,issue这个词汇可以表达问题、缺陷、错误、功能、任务,甚至一个小项目,就这方面来说,从系统解决问题的方法看,issue本身几乎是无差异的。这的确是海外很多项目管理系统的一大特点(参考redmine的特性),但是issue在常用的预警中,主要指的还是缺陷(国内习惯称bug)
也就是说,Jire是在issue管理的思路下逐渐完善项目管理,而不是一开始从项目管理工具强化缺陷管理功能,他的切入点是issue。历史上他的定位就是部门(团队)级系统,但是单凭issue管理系统的产品定位,市场未必认可,因此,调整产品定位,将部门(团队)级系统升级成企业级系统是必然之路。
禅道
嗯,这个……,在禅道的地盘怎么说都有拍马屁的嫌疑,我就不说了,只是讲几个禅道几年来我感觉的变化
1、初纯粹的Scrum项目管理:除了也许是技术上当时没搞定的“Scrum看板”,禅道几乎是为Scrum量身定做的,这也是我一开始就喜欢的东东,自下而上的,什么管理者报表、工程师日志,只要不是Scrum元素中的东西都不应该出现,乃至于有人提出建议要做,必然被WCS打发回去学习Scrum精要,堪称Scrum原教旨工具:)
2、扩大外延:我猜在禅道的忠实推动者中,主要有两大类主流角色,一大类是主要关心需求的,相当于PM,一大类是测试相关,而开发人员相对来说没有前两类这么多,呼声这么强烈。之所以这样想是因为用例和测试用例的功能逐渐丰富。这两块功能,背后隐藏的是从原教旨Scrum,开始逐步开放,兼容并蓄,Scrum的知识不再是初学必读。
3、管理版块:免费的软件部门、团队就可以直接使用,但商业化的运作,应该加强的是管理特性,甘特图、工时统计等特定就逐渐加强。
Jira和禅道的选择
对这两个系统的选择,个人建议其实无须专注在功能的有无和强弱上,因为彼此都在发展,很多功能都可能同质化,一个企业每2年换一个作业系统是不靠谱的、不专业的浪费行为,即使免费的也不合适。
每个系统的核心业务逻辑是不会发生颠覆性变化的,客户量越大的企业越承担不起重构产品逻辑的风险。
Jira是从Issue入手,所有事项都通过设置不同的issue逻辑,得以形成闭环,这就是他的核心逻辑,因此,Jira针对issue驱动的项目管理非常有效,基于多年来的插件积累,可以展现非常强大的交互、统计视图,纯粹项目管理使用Jira的确是个不错选择,缺点是各种issue大体相当的逻辑的确不太容易被国人接受。
禅道核心逻辑还是Scrum,只是包含在非常内里,不再口口声声强调(优秀的软件一定有其理论指导思想),本质上是通过需求(Feature)生命周期为其核心逻辑。对于互联网产品开发而言,的确是非常好的作业管理系统。
总结上面的说法,Jira是贯穿业务核心线索的是“项目-Issue”,而禅道贯穿业务核心线索的是“产品-需求(Feature)”
这也是我在事业部内部推广禅道的重要原因,”好的迭代产品开发项目管理系统“,这是我做为一个用户,内部推广时的定义:)
可以的,可以先了解下禅道的基本使用流程。如果有不清楚的地方,也可以直接联系官网顶部商务QQ,邀请加入技术交流群。群里沟通。
先创建一个产品,产品人员与客户沟通,整理可以直接用于研发的需求录入到产品-需求中,然后到产品-计划页面创建计划关联要做的需求。
以一个计划对应一个项目的方式创建项目,在项目-需求页面关联当前项目要做的需求,然后分解任务指派给相应的人员。
开发任务完成后创建版本,关联要测试的需求和bug,提交测试部门测试。
提交版本会生成测试单,在测试单中关联要执行的用例执行。
测试通过后到 产品-发布 页面 进行发布(发布上线或者交付给客户)。