InfoQ

InfoQ

新闻

我的书签

登录注册 以永久保存书签。

该内容已经被标记书签!

标记书签错误,请重试!

敏捷项目中的跟踪矩阵

作者 Vikas Hazrati 译者 郑柯 发布于 2008年6月27日

领域
语言 & 开发,
过程 & 实践
主题
敏捷 ,
工件和工具
标签
补充实践 ,
精益

有关正式跟踪矩阵的话题,往往能在敏捷社区中激起强烈的反响。Jorge Argus在敏捷测试讨论组发起了一个有意思的话题,讨论在敏捷项目里采用跟踪矩阵的必要性,引发了大家热烈的讨论。

Brad Appleton认为,关键在于理解“可跟踪性”和“跟踪矩阵”的区别。可跟踪性,是指一个项目的某种期望属性,说明了诸多重要信息之间的相互关系,是项目保持一定的透明度和能见度。跟踪矩阵是实现可跟踪性的一种手段。

Michael Bolton发表了类似的看法,他认为在着手采取创建跟踪矩阵的详细措施之前,必须要探究背后的原因。

有人想了解可跟踪性?他们为什么要跟踪这些信息?需要多久为他们提供一次信息?期望哪种形式的信息?什么样的信息格式对他们来说是可以接受的?还有,信息的价值和为此付出的成本是否匹配?

Michael认为,只有公司的重要信息可能被忘记时,才用得到跟踪矩阵。如果不是这个原因,跟踪性可以用多种形式实现,例如谈话、故事、战略主题、历史记录、日志、杂志、源代码、自动化测试、设计文档、每日scrum会议和email等等。

Scott Amber在文章《敏捷需要最好的实践》中,对跟踪矩阵的必要性提出质疑。他认为,通过跟踪矩阵的关联,能够很容易地分析需求变化所造成的影响。矩阵会显现出系统受变更所影响的方面。然而,即使没有矩阵也能很容易做到这点,项目中有许多经验丰富的成员,他们了解各方面的细节。Scott补充道:

根据我的经验,人们对跟踪矩阵评价过高。因为要维护这个矩阵的总成本(TCO)远远超过了它能带来的好处,即使用专门的工具来做这件事情也是如此。要让项目干系人了解真实的成本和收益,再做决定。跟踪矩阵毕竟只是一个有效的文档,可以用来辅助业务决策过程。

[…]

如果有明确的规章管理的要求,那我就对可跟踪性的作用坚信不疑。例如食品和药品监督管理局的联邦法规第21章11 款,你必须遵守这些规定。如果可跟踪性仅仅是由“这是一个好主意”来驱动的话,我很怀疑它能否起到作用。

在Scrum Development讨论组内,Alistair Cockburn引用了一个研究,来支持他的观点。

在一个(企业的IT)项目中,我们特意研究了采用工具进行跟踪,以及通过人工来跟踪信息和更新的成本。我们发现代价高得惊人,客户也因此在合约中取消了对可跟踪性的需求。

Brad Appleton再次重申他的观点,利用人工来创建,更新和维护跟踪矩阵,是展示可跟踪性作用的最耗时的做法。

那么是否有办法确保跟踪矩阵得到自动维护呢?

Ron Jeffries建议,最简单的方法是做些改变,看看哪些地方没有通过测试。这将会让开发人员了解哪些地方受到影响。Mike Beedle也给出了类似的建议

根据敏捷的范式,代码/设计到需求的可跟踪性,是通过单元测试和验收测试来完成的。测试反映了对需求的追踪,因为它们要执行特定代码以实现需求。

Brad Appleton在博客中提到了一种可能的解决方案,他使用TDD进行很短周期的开发。每个周期内的典型任务包括写测试、让代码通过测试、重构代码、提交修改。每次提交要带上将相关的名字和故事ID。Brad Appleton认为,通过这些短周期,可跟踪性会自然得到体现。

在文章《精益跟踪:战略和解决方案浅析》中,cmcrossroads建议,如果敏捷宣言里还需要增加什么,那就增加下面这句话:

值得信赖的透明度超过令人厌倦的跟踪机制

这篇文章中谈到,跟踪性是为了达到透明和一致。要达到这个目标,除了正式的跟踪矩阵,还有其他可行的替代方案。团队需要配合敏捷原则才能达到精益跟踪的要求。文章中谈到如下一些选项:

  • 要了解“可追踪性”和“追踪”并不是一回事
  • 采用版本控制和变更追踪工具
  • 在版本控制和变更追踪之间进行基本的迭代
  • 基于任务的开发(TBD)
  • 测试驱动开发(TDD)
  • 采用简单的工具:Wiki,以及基于Wiki的规范框架
  • 基于事件的追踪性(EBT)
  • 基于搜索的追踪性——不需追踪的可跟踪性
  • 简单基于搜索的可追踪性(“google一下”)

Alistair根据自己的经验,在邮件列表中发表了意见

根据我30年来在商业,工业,研发和部分政府部门的经验,我从未见过采用跟踪矩阵能够收回成本的。

如果你有不同的经验,如果你通过创建和维护跟踪矩阵能够收回你在上面付出的钱,请告诉我们。

很明显,敏捷社区的大部分人相信,维护一个正式的跟踪矩阵有点过火。团队应该寻找建立跟踪矩阵背后的原因,采用精益方法来达到项目的可跟踪性。

查看英文原文:Traceability Matrix in an Agile Project

译者 郑柯 InfoQ中文站总编。做过开发,当过PM,干过销售,搞过市场,最终还是回到媒体。实用的理想主义者,相信:每天改变一点点,这个世界会更好。

深度内容

大规模视频网站的计费与流量管理

本次分享将会就大规模视频网站的计费与流量管理这个话题,从操作层面细细进行讲解和分析,为系统工程师们揭示平日里我们没有关心的另一些内容。同时也希望本次分享能揭示行业中的一些“潜规则”,让互联网行业的流量与带宽管理更为开放与简洁。
本次演讲视频录制于QCon杭州2011

专访Jeffrey Richter:Windows 8是微软的重中之重

Jeffrey Richter以其多本Windows核心技术的经典著作而闻名,同时,他深入掌握微软的.NET等一系列核心技术,2012年1月,Jeffrey Richter在北京接受了InfoQ中文站的专访,谈到Windows 8和WinRT编程,并就异步编程、Windows编程中的可扩展性、性能和安全性方面给出自己的建议。

应用云平台的可用性——从新浪SAE看云平台设计

云计算平台的可用性,相比传统互联网服务而言,更加复杂和困难,也更具有挑战性。本文借助新浪SAE云平台为读者讲述了云平台可用性的定义、如何打造高可用的平台,以及对云计算的用户提出了建议。

JVM定制改进 @ 淘宝

淘宝高度重视Java平台的健康发展,组建了一个团队专注于Java平台的底层部分的性能、功能与稳定性改进;工作主要基于OpenJDK中的HotSpot VM开展,其中一些通用的功能随后也会逐渐反馈给OpenJDK社区。希望能与使用Java平台开发应用的大家交流经验。
本次演讲视频录制于QCon杭州2011

"伤得起"的云计算应用——对云端应用之架构的思考

2011年4月21日至22日是值得云计算从业者纪念的日子。Amazon的IaaS服务出现故障,导致许多商业网站的服务中断,影响非常严重。作为云计算用户,我们需要思考的是,如何保证即便在云服务不可用的情况,我们的应用架构仍然能够屹立不倒?本文正是站在云计算用户的角度试图探讨这一问题。

让交付的速度跟上思考的速度

12人的技术团队,4组刀片服务器,每月20亿的访问量,每日1次准时部署,99.9%的可用性。这可能吗?当然。想知道如何做的吗?百姓网将与您分享他们在DevOps实践过程中的经验和技巧。
本次演讲视频录制于QCon杭州2011

架构之路——穿行在产品和业务之间

篱笆作为一家起源于社区的电子商务公司,反映到技术层面就是同时要面对产品和业务,以及经营战略的变化调整。如何在产品和业务的夹缝之间完成技术架构的抽象与平衡,寻找更有效的价值定位,这当中有些经验教训和个人感悟愿与众人分享。
本次演讲视频录制于QCon杭州2011

特性注入:成功三部曲

本文将对特性注入以及相关方法做一个扫盲性的介绍。我们会解释这个框架的关键要素,并附上实例来证实它们。为了让文章保持相对较短,我们不会深入到某个工具或方法中,而是会给出一些参考资料,以便大家做进一步的研究。