|
作者
Amr Elssamadisy
译者
金毅
发布于
2009年7月18日
- 过程 & 实践
- 主题
-
Scrum
,
-
敏捷技术
,
-
敏捷
Dave West为InfoQ撰文，提议到，如果将软件开发看做理论构建（theory building）的话，backlog是非常重要的。这篇文章已经有一些忠实的拥趸，他们对此完全赞同。随后，在leanagile Yahoo!小组上又掀起了一场讨论。不论这篇文章观点正确与否，关键在于，我们能否从进一步的研习中获益。
最终，InfoQ联络了几个业界大师：Mary Poppendieck、Ron Jeffries、Jeff Patton、David West、Steve Freeman和Jason Yip，来进一步探究这个议题，请他们就以下几个要点做了阐述：
- 你认为backlog的作用是什么？
- 你会怎样定义一个backlog？
- Backlog什么时候/情况下会被认为没用？
- Backlog什么时候/情况下是必不可少的？
- 有没有一些我该提及却没有提及的问题呢？如果有，请提出并做答。
这里是他们的回答：（注：Mary Poppendieck的答案在一篇名为《重新定义Backlog》的随笔中，并被附在本文末尾。）
1) 你认为backlog的作用是什么？
Steve Freeman：
为了让团队认识到他们当前的状态和未来可能的走向。而这些应该得到团队的足够重视。
Ron Jeffries：
可能有很多作用。我想说两个，因为它们价值不同：
1. 对将来有一天可能要做的事做备忘。
2. 跟相关人员交流他们提出的请求的状态。
Jeff Patton：
对我来说，backlog有两个作用：首先它能帮助我理解我正在做的产品的“形状”，即它是什么，它将能做什么，它为谁服务。我从宏观角度来理解这个“形状”，或者说是看看故事的全貌。这使我与Dave的描述产生了共鸣，他引用了Alistair的书中由Nauer提出的“理论构建”一说。没错，确实应该是这样，我们就该这么做。我把backlog看作“故事地图”，以此来展开探讨理论：
http：//www./blog/the_new_backlog.html
但是，我们迟早要决定做什么，理想情况下，一旦需要马上就决定。随后stories就变成了backlog，包含已计划好的工作，但仅包含我已经明确选定的工作。
至少，story和backlog是两回事。当用backlog一词来做些理论探讨的时候，这一名字就不那么传神达意了。正是由于这个糟糕的名字，而且需要一些技巧和理解才能用它来表述理论，我认为大多数人做不到。
David West：
Backlog的用途起源于user story的用途。User story曾被设计为一种用户（或客户）授权机制。它曾经用很草根的形式写过，用对话形式写过，用来从系统中捕获过一些用户想要的东西，即用非正规的方法 描述用户想要的行为或职责。story也可以用来分解并且关注工作，因此story是可估计的、在一个迭代中可完成的，如果定义得太大就要重构等等。
一个story卡片可以提醒用户和开发人员，他们之间的对话已经开始并将继续，直到完全实现了这个详细的story。在此过程中也会产生其它一些或短或长的提醒方式：像白板上的模型、测试、编写的代码。这一切，包括story卡片，没有任 何其它目的，它们切实地提醒着：用户想要什么，用户怎样理解她想要的东西，开发人员怎样解释了她想要的东西。对用户和开发人员间难以共识和沟通的内容，它 们可以作为一种有形的、可追溯的证据。
一组User story卡片是一个独立对话（meta-conversation）的有形证据，这时，它们大部分是用户专有的。每个独立story(meta- story)关系到优先级（这个story在业务中有多重要？）、共用性（我是不是唯一想要这个的人？）、情节和特征演化（虽从不同的视角出发，你的X目 标和我的Y目标却完全相同）、可选择性、变动性等。每个独立对话会根据每个story完成所得到的反馈信息做改动，并且在软件项目的整个过程中持续进行。
综上所述，对正在进行的会话来说，一组story卡片相当于有形的备忘录：用户想要什 么？它能怎样帮助他们和他们的组织？如果你把一组story卡片看成一个backlog，你将置身于危险的境地——你在语义上搞错了，即把那组卡片强制看 成一些别的东西。但如果你坚持要那样认为，那么：对一个多人参与，并发进行的软件系统来说，backlog也成了有形的备忘录。
Jason Yip：
假设Sprint Backlog可以为当前Sprint提供一致认可的、详尽清晰的工作目标，再假设产品Backlog可以指示产品的潜在功能。那么，它可以用来表达整个 产品的愿景，但典型的简单backlog在这里完全不起作用。使用故事图、停车场图、流程图等工具来放置backlog项，相比之下会更好。
2) 你会怎样定义一个backlog？
Steve Freeman：
1) 一个可以帮助团队理解他们和客户之间关系的思考工具。
2) 一个我们所能理解的需要提供哪些特性的粗略列表。
Ron Jeffries：
backlog是一个已计划的功能项的清单，针对“backlog所有者”当前的优先级做排序。
Jeff Patton：
重申一下，我痛恨backlog这个名字。
它们根本就是两回事。
组织级story列表是我们对产品理论高层次认识的详细描述。
优先级story列表是已计划工作的backlog，但不包括那些未被正式提交的story。
就是说，你必须知道组织backlog和为=backlog区分优先级是不同的。
David West：
“产品backlog”是一组story，用于表示目前我们对用户想从软件系统里面获 得什么的最好的理解，当然这会变化的。“迭代backlog”是我们（开发组）按照迭代计划的，在一定时间内打算完成的一组会话。迭代backlog确实 承担了待完成清单（to-do）的作用，是一种工作清单。每个story会话都会产生一些额外提醒，来促使我们继续前进，并且保证我们获得反馈以便持续追 踪状态。除了它原来的使命（即作为正在进行的动态会话的有形标记），一个迭代backlog承担着更多的职责（即支持迭代管理和跟踪）。
backlog不是一组需求。
backlog也不是未完成工作的详细目录。
Jason Yip：
一个潜在要做的工作的队列。如果backlog被排好序，结合了任务、工艺流程、总体产品愿景等上下文，而且随着项目进行逐步细化，那么backlog会更有效。
3) Backlog什么时候/情况下会被认为没用？
Steve Freeman：
再声明一下，当维护它所花的成本大于它带来的价值的时候。
比如说，在做维护/支持相关工作的时候，快速做出决定比去挖掘一大堆可能的需求来得更有效。如果需求经常有的大变化，更是这样。
Ron Jeffries：
我认为backlog不会完全是浪费。它就是一个清单。由于它是按优先级排序的，也不需要频繁的关注很多项，就看看前面几项就可以了。
也就是说，处理于一个较长的backlog无疑要比较短的backlog花更多的时间，可见，放弃那些优先级不是很高的是合情合理的。我很期待在backlog方面有种智能曲线，可以提示我80％“自然发生”的项可能不怎么重要，就算舍弃掉影响也很小。
要是backlog没提供什么价值，它们就是种浪费，有投入无产出的活动。要是公布出来的backlog在误导大家，让项目干系人幻想他们的想法正被实施中，而实际上他们等啊等，可能永远等下去，那真的是太不厚道了。
我为什么要说他们可能永远等下去呢？因为backlog上没有被选来做的项比已选的价值低。也就是说，新出现的主意非常有可能也比待选项更有价值，它们会被插在待选项之前……就这样周而复始。
其实在backlog靠前的位置确实有根曲线的，如果你在这根线之后，你的主意将永远不会被实施了。在这种情况下，更好的做法是告诉大家可能不够走运，得完全放弃那些排在后面的。这也给提出主意的人相应地留出了更多决策空间，例如用其它的方式提出主意。
Jeff Patton：
当一份工作真的很有价值去做，你又非常深入地理解它，而且已经很详尽地安排了未来要做的一切的时候，你就不需要backlog了。
David West：
在两种状况下，（项目或迭代）backlog变得没用。
一，每当它变成“文物”。我的意思是说，当story已经沦落到跟我们交流讨论时做的 记号一样。一组story只能反应项目初期我们对系统的理解。这时的story变成了一个“石碑”－－一个无法修改的、纯语法的、没上下文的陈述，所以没 什么语义。于是那些story成了历史文档证明我们早先的无知程度，此外什么都不是。
二，当一组story（backlog）被强制用于有关“管理”或“产品跟踪”的目的 时。敏捷确实是一个新范式（老套的说法）。敏捷是种与众不同的文化。习惯的力量、懒惰的力量以及来自我们身边的形式主义文化的压力，一直力求将敏捷和敏捷 实践打回原点，回到由结构性的/工程的/理性的/科学的开发和“泰勒主义”管理的文化中。
Jason Yip：
backlog总是没用的。
4) Backlog什么时候/情况下是必不可少的？
Steve Freeman：
当你需要了解还有多少剩下没做的时候，比如当你不得不跟诸如市场部或者实施人员需要长期交流的时候。
我认为我们值得去区分一下不同层次的backlog，就像Scrum里面区分产品 backlog和Sprint backlog那样。可能你要求产品人员只关注前面5项(因为前5项包含更广)有点不合情理——但这些可能就是开发团队需要做的。如果我们真的想要比较汽 车生产，就好比比较丰田产品开发体系和生产体系的不同。前者有着更多的浪费，因为它依赖于设计的按时完工。
Ron Jeffries：
必不可少的？这世上可能几乎没有必不可少的东西。
只有当Backlog表达真正要去做什么时才有价值。一旦远离真实，它的价值也会降低。建议比较短的backlog更好。
Backlog有助于考虑下一步可能做什么、怎么选择以及精化所要实现的东西。
Backlog能够作为列表提醒人们不要忘记一些事情。很多人在列表上可能有很多事情，但实际需要去做的并没有那么多，但这多少能给大家带来方便。
Jeff Patton：
对Backlog的理解是不可少的。如果你把backlog作为一种辅助理解工具，那么它总是必不可少的。如果你不知道怎么使用它，那么就不是必须的。
David West：
如果你正在致力于敏捷开发，当你需要来表述你对所从事领域的深入理解的时候，当你想让你的软件能帮助支持真正的客户，在真实世界里，真正地工作的时候。
Jason Yip：
我们需要知道下一步做什么，不管它能不能给出更大的产品目标。对产品可能的样子有个总体的广泛认识是很有帮助的。如果你们不选择Scrum这种形式的backlog，就得选点别的。
5) 有没有一些我该提及却没有提及的问题呢？如果有，请提出并做答。
Ron Jeffries：
做backlog，好的和坏的方式各是什么？
将backlog存放在电脑里听上去很吸引人，但却是危险的。电脑能保存数量庞大的信息，而结果几乎不可避免的是：太多东西被太详细地写了下来。如果不管不顾，这些就是垃圾。如果关注了，它们大多浪费时间。
用索引卡（index card）记录backlog有很多优点：
你不能带着很多索引卡（index card）到处走，因此backlog的大小有先天限制。
个人或小组就能给一堆索引卡（index card）按优先级排序，只要把它们放在一张桌子上摆来摆去就行了。过程简单，有效，参与度又高。
你不能在索引卡（index card）上写很多，所以那些不需要的细节就被去掉了。
撕掉一张卡，用新的替代很容易。这使得更新非常容易。
如果需要，我还能继续说出不少优点。每个人都“知道”为什么这些东西“应该”被保存在电脑里。但更多的时候，用简单的方法几乎各个方面都更好。
Jeff Patton：
你怎样用backlog来理解产品的“理论”？有别的什么能够帮助理解产品理论么？
（Jeff没做答。）
David West：
为什么每个人都不对？（这假设，当然我是对的。）或者，换句话说，“为什么我们大家对story、backlog还有敏捷的理解如此大相径庭？”
简言之：我们是在计算机科学与软件工程专业接受了教育的技术人员，而那里除了“正规的 ”东西什么都不尊重，那里的工作文化根本就看不起非正规的东西，以及那些所谓“神秘”的东西。大体上说来我们都已经不再理会Brooks关于“概念构建” 这一关键特性的慷慨陈词以及他对数学、理学、方法论和模型缺陷的评论。我们都忽视了Naur提出的理论构建的思想、理论的不可言喻性、方法和文档的缺陷 性。我们大家都喜欢抽象数据类型而忽略了对象思想。我们大家都遗忘了Alexander提出的建筑的永恒之道（Timeless Way of Building）以及无名的质（QWAN），而喜欢把那些因为不能理解设计艺术而引出的问题的解决方案写成文档。我们大家都在用旧的思维模式来生搬硬套 敏捷文化、哲学和价值观。
Mary Poppendieck在题为“重新定义backlog”的随笔中，通过重申这个问题，给出了他的答案。
我想由“backlog”这个名词来谈开，据我所知，它是通过Scrum被引入到软件开发界的。我试图避免使用Scrum术语，特别是一些类似 “backlog”已经有多种不同用途的单词。我相信是时候再来谈谈精确定义术语的问题了。例如，标准精益概念中，像队列(queues)、知识创造 (knowledge creation)和基于集合的开发(set-based development)。一个“backlog”就能涵盖这三个东西了，而且通常混在一起。
队列(Queues)在这样的环境中最适合拿来讨论：有人希望改进自己的工作，因此不断有一些小的需求给软件公司来做。那么你做的越快，客户就 越快认识到他们要寻找的价值。这种情况下，控制你接受的请求的数量，以你现有的资源在短时期内完成它们，几乎总是最优方案。这原因来自于队列理论 （queuing theory），特别是Little’s 法则：完成需求的平均时间与队列的大小是直接成比例的。
这样，当相对比较小的需求犹如涓涓细流，从客户那里涌来时，你的响应时间将和你队列的长度也将成正比。如果队列短，你就能很快响应，比较及时地 解决客户提出的需求。如果你总是能够在较短时间内给出响应，并且结果可靠，那么客户会逐渐依赖你的响应时间。如果你的响应时间值得信赖，那么客户们就会在 要结果之前尽可能搞清他们的问题，因为他们知道，即使他们的问题发生变化，提出的请求也不必排等待很久。限制了队列长度，你就要在客户提出需求时诚实地给 他们快速反馈：你会搞定他们的问题，或说不能做。如果你说要做，客户就大概知道这个问题什么时候可以解决掉了。如果你说不能做，客户会认为你很诚实，而为 解决这个问题给些其它条件。他们也能很快明白，需求实现是有限度的。
用这种方式，对客户真诚以待，客户也会信赖团队。团队用坦诚和守时向客户表示尊敬。团队与客户紧密地联系在了一起，并致力于不断给客户带来价值 ──正如精益理论中，客户利益至上。知识创造是精益思想中另一个有巨大价值的东西。因此，知道你将迎来什么，不断跟踪一下你已经考虑过的东西，了解对未来 的种种可能，是非常棒的。每个客户的问题都是一个学习机会，你和你的客户搭档，站在他们的立场上来理解他们所考虑的未来。当客户和开发团队成为最佳拍档 时，他们也会一起花时间来经常看看各自的问题，从做过的各种尝试中提取些经验，对未来市场和技术的趋势保持警觉。
知识创造还有另一个好时机，就是当你在做一个很大的项目时，想要找到路标，即项目前进的大致方向。这是一个很不错的思想。我敢肯定，如果你不多 花点时间在方向操控上，而是一头扎进成堆的小事中，随之而来的只有返工。事实上，只要能从实践中学到足够的东西，也算只是创造了。知识总是好东西。有很多 手段可以追踪知识。精益（Lean）理论中所推荐的一个工具是A3文档（A3是一种纸的规格，大约11×17英寸，不过美国不用这种规格标准）。做法是将 所有关于某个特定话题的想法都汇总到一张A3文档上。用一个A6纸做索引，因为在软件开发中，大家发现这个大小的纸张用来捕获客户价值信息最适合。其实是 A3还是A6根本无关紧要，重点是你要让潜台词明朗化，用有效的方式捕获它们，这样你就不必再反复研究就能做出更有理有据的决定了。这是精益（Lean） 理论的精髓所在。
基于集合的开发(set-based development)是一种以不同意见作为基础来进行开发的方式。当遇到一旦做出觉得很难挽回这种棘手情况，它可以被用来获取更多的知识。意思就是说 你提出很多不同的选择，随后根据知识创造所获得的信息，来决定哪个最佳。你可以提出2到3套理论解释到底怎么工作的，随后进行些实验，来比较结果。如果结 果跟理论不一致，你需要去改进你的理论。如果结果跟理论完全吻合，那就太完美了。
通过实验来改进认知的想法对于工程改进也十分有效。比如，理解理想中队列长度的最好方法是建立一个理论，解释队列长度将怎么影响一些重要数据点的，随后去尝试不用的队列长度，看看到底怎么影响那些数据点的。
读者可以看出，我们对backlog还远没有达成一致。但是我们还是发现了一些重要的共同点：
- 对你将要做的事情有个整体认识非常重要。
- 明白你现在状态也是很重要。
- 从（1）和（2）中可知，关键是要维护和并让每个人都知道backlog。
- 如果一个列表太长或者内容陈旧，它的浪费远大于价值本身。
|
