查看文章 |
近期读了一些InfoQ的文章，也顺手参照实际情况提出一些想法或是意见，可能日志中会出现比较集中的读后感类的内容。 由于最近在编制持续集成的系统，要管理的是一组分布式子系统整合起来的一个逻辑上的大系统，所以这方面考虑的事情相对多一点，而阅读方面自然也就对这方面的内容比较关注一些，InfoQ前天时候出了一篇文章，叫《扔掉Bug跟踪系统？》，令我很是有些惊疑，毕竟手上正在开始整理这样的一套东西，因为如jira或是teamworks之类的总是有或这或那的不适合的地方，随着手上团队磨合的越来越好而越来越令人难以接受。于是读了一下，原来是引了一个叫Elisabeth Hendrickson的一篇讨论敏捷环境中Bug的文章，于是读了一下，也顺手译了一下，不过未推敲文字。 要文中，Elisabeth Hendrickson并没有关注于Bug跟踪系统，而只是要界定到底什么是Bug，其意见就是与需求相违背的才是，否则就不是，一切以需求为准，与需求无关的可以忽略不考虑。因为在实际开发过程中，经常会出现“离题”的情况，浪费时间而对项目开发本身并无实际好处。 在我所经历的项目中，就有这类情况出现，但一般我的处理就是每隔一段时间（以工作阶段为界， 即每个阶段都会确定特定的工作任务）就会将遗留下来的且并不一定需要解决的问题全部关闭，而至下一个阶段则有可能仍会提出类似的问题，如果有时间且方便解决，则会解决上些E.H.所说的那些于项目需求无明显好处的问题，否则就做前述处理。 如此，想来也算是所见略同，只是我还没有界定的那么清楚吧。建模的思想体现的淋漓尽致，忽略非重点，仅关注重点，这样即可以专注又可以节省时间罢。 在译文中有一个词比较难找到与其相适合的，“Product Owner”，虽然文中也对该词做了一些说明，但我胡乱想了一下，也没有想到与其相适合的角色，这个角色根据文描述，应该是项目经理吧，关注于业务以及团队实现结果的项目经理，其确认所有的项目需求，并交由团队进行开发，在国内的大部分开发团队中，这个角色一般并不是很明确的，大多情况下项目经理即关注业务同时也关注技术，即包含了需求、业务分析，以及系统、技术分析的事情，因为乱，所以乱，角色不必太多按排…… 附录： 敏捷环境下的Bug处理 我有幸参加了本周软件质量协会丹佛会议的会餐和学习小组，其中有一个关于在敏捷环境下的问题归类的议题，这里就是我的回答，要比在小组中的更详细一些。 当我这样说的时候，人们通常会摇着头说，“哦，不，你显然不是生活在现实世界中”。但我确实是生活在现实世界中的。关于这个，我做一个定义，就是什么时候问题才算作是一个问题？ 在敏捷环境中，我这样定义一个Bug，即在一个完成的功能中，有行为与产品经理的实际预期不相符。 当然，对此也有很多模棱两可的说法。所以，下面我详细说明一下。 就从“产品经理”开始，不过不是所有的敏捷团队都会用这个词。那么，这里定义一下“Product Owner”，这个标题或是名称所替代的，就是在你的组织中，负责确认软件要做什么的那个人。这个人可能是一个业务分析员、一个产品经理，或是一些其他的业务关联者。 这个人不是负责实现的团队中的一员。当然，对于是不是一个Bug，测试人员或程序员都会有自己的看法，而负责实现的团队也可以向产品经理提出相关的建议，但是这个要由产品经理做最终决定。 这个人也不是最终用户或是客户。当然当最终用户或是客户在实地操作中遇到问题时，我们要听取他们的意见。产品经理会将他们的意见、喜好及需要考虑进去，但在客户发现系统中某些功能与其预期有不同时，只有产品经理可以对此做最终决定，即是否做软件实现。 当然，这样说会给产品经理的增加了很多责任，但这也是应该的。定义软件该做什么和不该做什么，是业务上的，而不是技术上的决策。 说到预期（其实应该就是需求分析后的结果），这里就多说一些。 当产品经理界定了功能，他们就会对其完成后的结果有了一个预期。实现团队就需要参照其提出的验收准则或验收测试所明确表达的预期来进行工作。 可以很容易的知道软件与这些明确的预期是否相符。然而，隐式预期则有点难度，而产品经理会有隐式预期是很正常的，但在验收测试中没有办法照顾到所有预期的每个细节。 另外，有一些预期是无法考虑周全的。如产品经理所说的，“永远不能破坏数据或是丢失用户的工作”，或者是“永远不能危及用户的安全”。我们可能无法建立一个足够完善的验收测试，能考虑到上述说法的每一种可能性。 最后，让我们说一下“完成”。完成意味着已经实现、测试、整合、核对过，并已准备好出售或部署。完成不仅仅意味着完成了编码，它意味着完全的结束，都准备好了且提炼过的。 在我们声明功能“完成”之前，如果发现有些地方与产品经理的预期有所不同，那就修正它。不需要讨论，争辩或是筛查，只需要修正它，即对Bug的零允差（应该是对前述定义的Bug做到零Bug，毕竟前面定义的Bug其实就是不满足需求）。这样我们在代码的基础上就能保证其洁净、扩展性和可维护性。就可以避免积累技术上的缺陷。 发现它们就修正，这些事情不需要一个名称，设立优先级，也不需要在Bug跟踪系统中进行跟踪，只需要改好就好。 关于这点，必然会产生一些疑问，“我们不需要跟踪修正的过程？不需要收集相关数据？”，对此我的回答是，“为什么需要？发现并修正了它，也为它增加了测试，保持这个问题的记录有什么商业价值？这是很明显的事情，再分析它其实并不会有更多的改进”。 如果我们不确定是否有些事情有违产品经理的预期，那么就去问，不要猜测。展示给产品经理看，产品经理可会有三个结果：“哦，这是一个问题”，或者是“这已经不在这个功能的范围了，我会把它记一下”，又或者是“酷，这正是我想要的！”，如果产品经理说这是一个问题，那们我们就修正。 如果产品经理说，“从技术上，这是一个Bug，但处理它也没有什么好处，所以现在标记一下，暂不处理”，那么我们会告诉产品经理，这属于备忘的事情。我们也会向产品经理解释这不是一个Bug，因为软件的表现并没有违背他们当前的预期。 有人通常也会说到这一点，“但是，即使产品经理说这不是一个问题，难道我们就不应该保留一个记录么？” ，通常保留这种不需要修正的问题的记录，主要是用于事后如果产品经理说“为什么没有发现这个问题？”，我们也可以从问题库中找出来说，“早就找到了，但是你说不需要修正，就这儿……”。如果敏捷团队需要保留这个记录，那么在Bug跟踪时，这就会成为他们的一个问题。 另外，这种记录也是高成本的。 我工作过的大部分传统的团队(在我参与敏捷团队工作之前)都有Bug库，最后我们被从来不会修正的问题所淹没。通常这些问题都是团队里面的人报告的，一般是测试人员，并且标记优先级为“Cosmetic”和“Low Priority”。 这些低优先级的问题不会增加价值：我们从不会对它们做任何处理。但因为我们有一个错误的信念，所以仍会把它们在一个个发布中带下去，这个信念就是记录跟踪每一次报告的挑出来的，即使在业务上并不关注的问题，也认为其是有价值的。 这个数据库更多的像是安全毯，而不是项目的价值。我们花费了很多时间在会议上讨论这些事情，列出要修正的问题，调整严重程度和优先设置，但是当有下一个关键的特性处理或是Bug出现的时候，这些讨论的结果又没了下文。如果这个场景听起来很熟悉，那就必须得承认：这些信息对项目的发展是没有什么帮助的。那就不要再做这类事情，事倍功半，所得甚少。 那么在敏捷环境中什么时候报告Bug呢？ 当功能完成并被接受后，我们可能会发现在一些情况下已经完成的功能与产品经理的预期并不符合，这时就有了Bug。 如果我们做的正确，这种情况应该不常见。但如果每时每刻都会五个问题存在的话，那么在一个设想的Bug库中区分并跟踪问题是没有用的。产品经理会将这些问题与备忘中的条目根据优先级排定解决的顺序，项目则继续进行下去。 如果我们没有做对，可能就会发现会有很多很多小东西被漏掉。那时我们就会知道在过程中真的出现问题了。这样我们就需要回头来找到出现这种情况的原因所在，从源头上解决，而不是花时间来尝试控制这些小东西。 |
