吉拉是一种反模式-王其杉博客|程序员|科技新闻
亚特兰西的吉拉作为一种bug追踪工具开始了生命。然而,今天,它已经成为一个敏捷规划套件,“计划、跟踪和发布伟大的软件”。在许多组织中,它已经成为软件项目的主要地图,所有开发的中心,臭名昭著的“真理之源”。
地图不是领土,这是老生常谈。唉,这对吉拉来说尤其如此。它作为一个bug跟踪器的起源,以及它最终使用“票据”作为它的基本定义单元,使得它的地图特别难以理解。JIRA1的使用频率太高,以至于在不经意间,它成为整个行业的“反模式”,即“对经常出现的问题的共同响应,该问题通常无效,并且有高度反生产力的风险”。
编写优雅的软件与艺术具有一个共同点:它的制作者应该对项目的整体宏观前景保持了解,同时他们正在致力于其最小的微观细节。吉拉,唉,隐含地教导每个人忽略更大的视野,同时关注细节。没有完整的。最多有一个“史诗”——但是史诗的整个要点是要分解成更小的片段来独立工作。吉拉鼓励宏观愿景的瓦解。
此外,特性驱动的JIRA并不容易支持不映射到单个特性的项目范围基础设施的概念。整个项目中使用的数据模型。跨多个页面使用的复杂组件。第三方接口的缓存层。提供跨多个屏幕的实时数据的后台服务。当然,您可以将这些嵌入到JIRA的票证范例中……但是依赖关系的蜘蛛网对任何人都没有帮助。
然而,最糟糕的是,无休止的隐含的压力要求门票被标记完成,并传递到下一阶段。在JIRA的心态中,门票被拿走,专注直到完成,然后传递,再也看不到了。它们有一个单向生命周期:规范;设计;开发;测试;发布。这听起来有点…嗯……水洼Y?敏捷开发不应该与瀑布式开发完全不同,而不是简单地用一千个小瀑布代替一个大瀑布?
这是一个类比。设想一个城市规划工具,它使得设计城市地图变得容易,包括塔、住宅区、公园、商场和道路……但是它不能轻易地支持诸如水厂、下水道、地铁隧道、电网等只能通过笨拙的方式嵌入其中的东西。黑客,如果有的话。
现在假设这个工具被用作构建蓝图,其中隐含的烘焙假设a)邻里是城市构建的基本单元b)城市一次构建一个邻里,一次构建一个街区。更重要的是,只有当最后一个完全完成时,人们才会被激励去进行下一个,直到花朵在中间地带生长。
现在想象一下,城市的开发商、工程师和建筑工人被要求纯粹根据有多少个街区和街区已经完全建成,以及每个街区有多远来估计和报告进度。你认为这是一种特别有效的城市规划模型吗?你认为你愿意生活在它的结果中吗?或者,在实践中,你认为最好的方式来种植一个城市可能只是多一点有机?
让我们来扩展这个比喻。假设你开始把城市建设得更加有机,这样,在某个重要的时刻,你的市中心充满了临时的和永久性的建筑物;摩天大楼的基础被奠定(即,技术不确定性得到解决);许多核心基础设施被建造出来;一些集群。指中心社区的初始建筑和郊区的棚户区;机场所在的脏机场;所有这些地方的交通往返。换言之,你已经建立了一个粗陋但运转良好的“造中城市”,它的骨架已经建成,准备充实。做得好!
但如果以绝对完工的街区和社区数量来衡量,根据城市规划师的艺术再现,你的进展如何?按照这个标准,你的进步是零。
所以JIRA不是激励你去工作的。这看起来像是一个巨大的进展中的专栏,而没有完整的栏目。那看起来太可怕了。相反,JIRA鼓励您完成整个街区,然后是下一个街区;整个街区,然后是下一个街区;销毁尽可能多的不同的门票,标记它们完成并传递它们,即使事实之后将它们拼接在一起比将它们构建成w.ORK首先放在一起。
(如果你喜欢小尺寸的模型,就换个位置吧:城市_公寓楼、邻里_楼层、街区_单元等等。)
因此,人们拿票,按照书面形式实现,将它们传递给工作流程中的下一个人,认为他们的工作做得很好,即使并行处理分散的组可能更有效……并且从来没有考虑过更大的目标。“执行上传按钮”,门票说,所以这就是一切。该票据没有解释Upload按钮的更大目标是让用户备份他们的工作。实际上,从技术上讲,自动上传每个状态更改可能更容易,这样用户就可以得到自动无按钮备份以及完整的撤消/重做堆栈。但是所有的票都是:“执行上传按钮”,这就是全部。
通常情况下,人们唯一担心整个项目的愿景的时间是在刚开始的时候,那时工作过度的项目经理开始处理将整个项目分解成票林的不知疲倦的任务。但是敏捷开发的全部要点是接受项目总是随着时间而变化,并且尽管在较小的程度上,对于多个人,团队中的每个人,项目将帮助促成这种变化。吉拉已经成为一个工具,它实际上反对这一点。
(甚至不要让我开始要求工程师评估另一个人分解的项目,将其分解为分区感觉不自然的子组件,在计划会议期间给每个特性大约30秒,然后将整个项目计划建立在那些手动操作的基础之上)。未经研究的半盲猜测,从来没有重新审视过它们,也没有为更深入的分析提供时间。那个反模式不是吉拉的错……没错。但吉拉的结构有助于它。
我不是说吉拉没有位置。当你把事情分解成小块并按顺序完成时,这很好。而且,毫不奇怪,鉴于它的历史,它非常擅长追踪问题。
让我重申:要编写优雅的软件,您必须同时在脑海中保持宏观和微观的视野。吉拉擅长管理微件。但你需要其他的宏。(不,可单击的原型是不够的;这些很重要,但它们也需要描述性的上下文。)
请允许我提出一些令人震惊和革命性的东西:散文。是的,这是对的;连续的话;深思熟虑的段落。我不是在谈论巨大的需求文档。我说的可能是一个10页的概述,详细描述了整个项目的愿景,以及一个6页的建筑文档,解释了软件基础设施——城市的水、污水、电力、地铁和机场都位于哪里,以及它们是如何工作的,以扩展这个隐喻。或者。众所周知,当亚马逊需要6页的备忘录才能召开会议时,这似乎并不需要太多要求。
简单地停止将JIRA视为项目完成的主要地图和模型,就削弱了它的大量隐含反模式。使用它来跟踪迭代开发和错误修复,完全可以。这很好。但是这个工具完全不适合作为项目总体愿景或基础结构的映射,并且它从来都不是真理的源泉——真理的源泉总是运行的代码。在软件中,就像在艺术中一样,微观的工作和宏观的视野应该总是相互影响的。让JIRA映射微观工作,但是让好的老式的朴素语言描述宏观视野,并试图更多地关注它。
1Atlassian在7.9和7.10版本之间似乎已经将JIRA斩首了,但是从描述上看,所有上限似乎仍然更常见。