级别： 初级 Per Kroll, IBM Rational Expertise Development and Innovation 首席架构师, IBM
William Krebs, 敏捷顾问, 工程过程架构师, IBM
2008 年 6 月 16 日 
阅读新的 IBM Rational Self Check for Software Teams 如何帮助您实现自评估以帮助提高团队敏捷性。取代了团队之外的人执行的量度和/或评估，Self Check 授权软件工程师定义并讨论他们自己的重要数据，并改进过程。
来自 The Rational Edge。
 IBM 正处于可能是世界上最大的敏捷转型之中，其 35,000 个软件开发人员在过去的几年一直向敏捷的方法推进。当团队采用新的工作方式时，他们会问问题：我们如何知道我们有多敏捷？我们如何知道采用敏捷的或非敏捷的实践有多好，因此我们可以在需要时调整并采取校正措施？我们如何积极地让开发人员参与变更工作？我们如何能够有效地共享什么有效，而什么没有效，因此我们可以促进敏捷方法的采用？
我们想给出一种简单的方式来回答那些问题。因此我们考虑了两种普通的方法：评估和量度。传统的评估可以帮助回答前两个问题，但当被看作“大哥哥监视”的方法时，常常事与愿违。量度是作用大的，但有时候太复杂而不太有用。我们决定需要其他的方式来回答这些问题。
在 IBM 中，从 2002 年起，我们与 80 个团队一起尝试了不同的方法来改进传统的评估和量度技术。我们发现，小型团队定期回答的，形成一个或两个最初的改进的一组简要的问题（随着辅助水平的提高，还会有更多问题）将使组织进入朝向整个团队健康的正轨。我们还发现进行自我评估的，而不是接受团队外的人评估的团队是十分有效的。这样的团队让团队成员参与，并让他们达到较高层次的常规参与，而不是让他们缺乏兴趣，迟早对大部分变更工作感到苦恼。
为了让客户可以得益于 IBM 在其敏捷转型中所用到的那种方法，我们将启动一个名为 IBM Rational Self Check for Software Teams™ 的服务，或简称“Self Check”。它可以在很多实践中用到，不论是敏捷的，还是不太敏捷的，并且它可以用于支持许多各种各样的方法，包括 RUP、Scrum、XP、OpenUP，和自家的方法。
该服务是一个更广泛的计划，Measured Capability Improvement Framework™（MCIF）的一部分，此计划用系统的方法提供杰出的软件，它是由各种服务产品来支持的。但是，Self Check 可以作为独立的产品使用，要么独立于 MCIF，要么作为较完全地采用 MCIF 的第一步。
向典型的量度和评估说再见
典型的评估是由受评估的团队之外的其他人进行的，而由于这个原因，经常让人有“大哥哥监视”的感觉。与之相反，追溯是更容易进行的，让团队以改进为目的有时间思考他们工作的如何以及他们取得了什么成果。有了 Self Check，我们集齐这两种方式的优点。在生成评估方面，Self Check 提供了一些严格标准，但方法类似追溯。Self Check 提供对团队工作好坏程度的评估，但允许团队使用所有成员都响应的结构化的问题。结果可以让人清楚地了解在带有定义明确的参数的一到十的刻度内，团队处于哪个位置，同时让团队参与并且 100% 认同结果，因为评估是只有他们在做的。
尽管从 2002 年起，我们就已经使用评估和追溯了，但是我们经常遇到将好意的量度变为畸形的问题。举例来说，当团队开始觉得量度本身（而不是团队的改进）是目标时，会引起比积极的效果更多的活动。围绕提高或降低数字的行为通常对长期的结果没什么贡献。
对评估和追溯技术六年的细化让我们经历了自我评估的波动，包括 2002 年的 Shodan 输入度量
2
、2004 年的 Extreme Programming Evaluation Framework
3
4
、2005 年的 Rational Unified Process Evaluation Framework
5
、计分卡，和 2006 年的更多工具。每个都解决了前面模型中观察到的问题。
通过将具体的量度与追溯技术相结合，我们在 2008 年开发了“IBM Rational Self Check for Software Teams”，或 Self Check
1
。这项成果是基于所选择的量度还不足够的这一发现。在不被诱使到一些普遍致命的缺陷（我们将在下面简要介绍）中的同时学习如何使用它们已经和在持续的基础上将 Self Check 并入团队工作同等重要。事实上，通过口头形式已经在我们的开发团队内部传播了 Self Check 的用法，因为目标是现实的，团队自己的，且可实现的。
对于如何避免量度的滥用的开放的团队讨论已经成为我们使用 Self Check 取得成功的一部分。因此，本文中的重点不是案例研究数据和要使用哪些量度，而是目标、要避免的陷阱，和如何让 Self Check 为您的团队工作。
Self Check 产品背后的目标和理念
根据您在软件开发组织中的角色，您对使用该方法的目标将不同。举例来说：
工程师想要
- 了解并记住最佳实践，
- 对团队如何工作发表意见，
- 通过了解其他团队的经验、优缺点来改进过程。
经理想要
- 了解在过程改进工作中，组织处于什么位置，
- 看到组织不断地在改进，
- 在变更工作中让团队成员参与。
指导想要
- 教团队重要的实践，
- 用可定制的现成问题来帮助传播新思想，
- 令追溯如此有效，以至于很容易地让团队经常进行。
不论您在团队中的角色是什么，Self Check 方法着重于显示出团队对他们使用的现有实践的了解有多少的轻量级调查。上面列出的三个角色都可以讨论趋势、平均水平，和人之间的距离，从而减少问题的数量，然后着重于为了改进而进行的行为。重点是团队的所有权。它不是关于评价的，而是讨论的引子。许多团队会选择利用一贯的形式分享他们的经验（包括将哪些实践用到什么程度，关于项目的环境，所选的客观量度，和项目成果）。但分享必须是可选的，因为团队拥有自己的过程。
因为重要的是，让团队感觉到所有权，而不是受控于外部团体，所以我们已经在介绍 Self Check 过程中避免使用术语“评估”。评估不是目的（尽管它可能是可选的副产品）。相反地，“小规模的改进”是 Self Check 工具更实际的目标，并且在我们的经历中，它已经作为团队所使用的描述符较好地工作着。在我们使用量度的过程中的试验和错误已经显露出我们不想让任何人去重复的缺陷和过失。
标准评估的缺陷
我们已经观察到了与团队评估的标准模式相关的五个缺陷，如下面所介绍。
膨胀的量度
数据越多越好，对吗？特别是对于知识丰富的指导来说，这是诱人的，可以让他们想出许多问题或量度。我们早期用过的一种形式是有 100 个问题，每个可回答的有不同的选择，因此参与者不得不读每个答案。而问题后面会跟着一个令人畏惧的“如果没有选择，请解释”的自由形式的框。完成它要耗费太长的时间，以至于不经常进行，并且只由每个团队的少量代表参与。
团队想要进行评估的频率反比于评估所耗费的时间。关键是找到减少对团队的回报的要点。偶然的彻底评估可能有它的好处。但评估与评估之间拖得时间太长是致命的，因为可能太久没有检测过程中的问题了。这造成了产品中存在缺陷或产生其他问题的风险。过程问题需要尽早检测并处理，并且确保及时处理问题的唯一途径是经常“试表”。
如果团队成员不参与的话，他们可能会忘记实践，并且放开提醒他们的机会。数据可能被所选领导者的有色眼镜所扭曲，这会掠夺需要感觉到自己的技术和过程的所有权的授权的团队。
邪恶的计分卡
许多人害怕量度正被用于微小地管理或评判他们。从表面上看，“计分卡”可能是推动变更的好工具。但实际出现的是，团队痛恨填写为其他人所用的数据。许多人将计分卡视为一个棍子，将他们打成管理者决定的某种形状。除此之外，为其他人收集数据的杂活会让人觉得贬低身份，甚至起反作用。您曾经参与过使用绿灯、黄灯、红灯分别比喻为项目处于正轨、试验，危险状态的量度吗？一般直到团队找出如何逃脱这种繁重工作时，数字才变为绿色（表面上改进）。总之，邪恶的计分卡生成有疑问的数据，并且阻碍团队使用这种技术。这一缺陷花费了我们一年时间。
被遗忘的教训
有时候数据被收集并分析了，但提议的行为从未实现。这使得很难产生了解另一轮经验的热情，并且用作放弃收集更多数据的论点。精益的软件开发
6
教导我们关注完整且频繁的小批量工作。部分的工作是没有信誉的，因此所列出的，但没完成的行为是没用的，且浪费改进的机会。当人们没看到变更时，他们会受到阻碍，而不进一步追溯。这个问题会发生在许多追溯技术上，特别是当行动的所有权不清楚时，或者没有被视为团队工作的一部分时。被遗忘的教训又花费了我们一年的时间。
强迫实施过程
有些团队想要按照自己的步调选择实践，而不是被已知的过程所迫。他们可能有避免某些实践的正当理由，并且随着时间的过去喜欢的实践可能变更。举例来说，组织可能从对 XP 的强调转移到将 XP 与 Scrum
7
和可伸缩的 RUP 元素的混合。这使得很难将评估与方法紧密绑定。目标可能是相干的已证实的过程，但是通过自己学习经验而不是被迫采用比一次能处理的更多的方式，团队也可以做得更好。这样的工作抢夺了团队自我指导和拥有其过程的感受。敏捷总是演进着。选择严格的实践令过程本身不敏捷。
不一致的且无来龙去脉的共享
有时候，生成了案例研究和经验报告，但不一贯地评估关键技术的有效性。非正式的报告提供非常紧急的结论，但没有描述了解这些结论可能怎样应用于其他环境所必需的上下文。举例来说，敏捷团队的报告可能说道，随后的迭代过程是好的，但不透露做了多少自动的单元测试。代码被检查，或者使用了对等编程了吗？团队有多大？他们在同一地点吗，并且他们达到政府标准了吗？缺少了一些公共的基线数据，这样的经验报告没有那么大价值。
此外，每个经验报告倾向于从口开始写，缺少用于报告的公共的格式或结构。比起简单的“填表”形式，进行非结构化的方法要花费更长时间，并且实际上更难阅读，因为您不能从报告中看出与您的需求相关的内容。我们还发现基于文本的报告经常缺少设计良好的图形所提供的那种客观的清晰度，特别是当介绍简单的量度时。在许多情况下，带有最少的文本的图形表示可以显示出引人注目的结果，并且为改进提供清楚的推荐建议。
达到目标
在费力经过了缺陷的艰难路途之后，我们已经到达了 Self Check 产品的四个重要的目标，它们是工具设计的基础。
学习
Self Check 中的主观的调查不仅可以快速地收集数据，而且还提醒并教导团队成员有关关键实践的内容。通过这种学习，数据收集为其自己付出代价。无可否认，这些数字是主观的，但是有部分价值。它们的目的是尽可能早地了解团队关于重要实践的“想法”。之后您还可以收集客观的量度，但询问人们“觉得”他们的团队有多留意已知的实践可以帮助提醒他们并了解该实践。这是考虑到了有时候人们忙于自己的代码并忘记这些实践。安静的人可能不知道术语并害怕询问。沉默的反对者可能不敢说出他们的疑问。热情的指导可能认为他们的过程建议多余实际情况地被当真。
改进
团队已经争取执行有效的追溯。他们要么在列出所有行动之前用完时间，要么列出多于能够实现的行动。Self Check 中使用的调查问题可以将讨论缩小到需要注意的那些区域。因此，取代长时间的讨论，团队可以快速地转移到行动的选择上。并且他们仍旧在需要时为将来的分析和指导收集趋势数据。他们可以将问题旋转以更深入地覆盖不同的区域，同时仍旧保持问题列表的小规模。他们可以再询问核心问题来逐步地收集关于公共实践的趋势数据。并且为了多样性，他们可以加入来自例如 Dean Leffingwell、
8
Esther Derby，和 Diana Larson
9
的作者的其他追溯技术或量度。
共享
团队成员开始看到什么东西在逐渐减缓他们对敏捷的担忧？人们经常顽固地认为他们是不同的，特别是在公司环境大而复杂的大型公司，例如 IBM。然而，作为个人，他们可能认为自己是独特的，他们非常易于接受看到来自自己公司的经验。看到来自组织内部的经验报告已经成为将怀疑者转变为相信者的催化剂。
我们已经生成了各种详细级别的经验报告，从单个的 PowerPoint 幻灯片到 10 页的正式文件。根据团队对量度和形式的胃口进行选择对团队来说是有效的。有一个目标是用一个 PowerPoint 幻灯片描述经验报告。如果希望，人们仍旧可以书写十页的文件，但一个幻灯片公式已经加速共享及管理支持。想管理层展示一系列六个一页的经验的幻灯片是有效的时刻。
尊重团队规矩
有一种技术是不向团队外部的人提供数据。避免让 Self Check 过分简单可以增强团队的数据和过程的所有权。只有当团队想要共享时，那些团队之外的人才可以看到经验报告。因此，尽管工具可以快速地总结结果，但我们的指导方针允许团队决定在多大范围内共享结果。
激发您的团队自我评估
我们发现的一般原则下的任务是：限制您的目标。较少的问题，较小的团队，以及对一个或两个行为的关注可以形成比完全地想方设法把事情搞定的议程更好地结果。
问少数问题，但经常问
最好在每次迭代中询问十五个或更少的问题（举例来说，每两周）。经常性的小批量的问题比不经常的大批问题要好得多。由讨论而产生的一系列行动是更易管理的，这促进足够经常地进行调查，从而在恶化前抓住问题。热情的指导和服务性企业很难限制问题，将核心问题从 30 个砍到 15 个用掉了我们两年时间。但过犹不及。调查需要迅速并且是可消耗的。团队主观的经验显示 15（也许较少）个问题是人们对该技术热心关注的上限。
小团队所有权
工作的人们在与变更有利害关系的足够小的组里进行调查。因此 50 人的项目应该在五个十人一组的组中进行调查。团队经常根据组分有自然的子边界，或者是大约七人的 Scrum 团队。这是适合调查讨论的大小。当确定改进行动时，较大的组会让人觉得所有权较少，没什么机会发言，并且可能延迟。
完成一个或两个行动
在担心更多事情之前，您应该选择并完成一个或两个行动，并且在下一个确定新行动的调查之前，您应该完成或取消改进行动。经验表明团队实现不了对过程的一两个以上的变更，主要因为编码、测试，和工程工作需要大量的团队的关注，因此这是适当的。可以通过在尝试更多事之前，每两周内关注一两个行动来建立成功的文化。
虽然收集数字并将它们提到高层次上可能是有用的，但是对于团队来说最重要的事是感觉到数据、过程，和行动的所有权。随着团队不断熟练，他们可以调整“15 个问题、2 个行动，2 周”的公式。但该公式是很好的具体的起始点。
Self Check 如何工作
Self Check 提供两张图的可视的输出，向团队提供关于以下内容的立即的结果： 1）所观察的是哪些实践、观察到什么程度，以及在团队中的变化，和 2）关于已知的软件开发实践的团队力量的整体观点。下图 1 和 2 中显示出这两张图的示例。
图 1：第一幅图显示出所观察的是哪些实践、观察到什么程度，以及在团队中的变化。错误条显示出在平均值上正负的一个标准的偏差，说明团队看法的多样性。
图 2：第二幅图显示出对关于已知软件开发实践的团队力量的深入的观点。
在敏捷的道路上，团队可能选择显示调查数据来表现其进展的特性。数字没有对错，因为图的目的是引发讨论。为了简单地快速完成调查，需要表达所有问题，以便答案可以从 1 到 10，而第 10 个是最佳答案。数字代表百分比：举例，“您的团队有百分之多少的时间做某事”。对于任意一个问题，1 分表示您认为您的团队从未使用该实践（或者少于 10% 的时间），5 表示一半时间工作得很好，或者始终工作得一般，而 10 表示您的团队总是进行该实践，并且没什么余地改进。但任何从 1 到 10 的数字都是有效的分数，虑及了团队成员之间微细的差别。我们建议您的组织采用一组核心实践，并且允许偏离这组核心实践。因此，每个团队都可以添加自己的，但保持 15 个或 15 个以下。
两个实例
要说明 Self Check 的效果，我们提供了 IBM 中两个致力于不同的敏捷项目的团队的数据。我们将看到这些项目处于从“不太敏捷”到“敏捷”的过程中的不同阶段。使用 Self Check 的一个优点是：它允许您跟踪您自己的过程。您还将看到至少一个项目是十分大型的 —— 也就是，如果您了解敏捷，您就了解它有多大！
团队一
团队一是大约有 235 个团队成员，分布在不同大陆上的许多地点上的大型团队。他们用 Java 开发，并且团队初识敏捷方法。该项目有 24 个月之久，并且他们有 8 周之久的“迭代”。
该团队采用的实践如下图 3 中的 Team 1 Self Check Big Picture 图所示。考虑到结果，团队选择讨论自动的单元测试和迭代开发来看看是否存在应该转化为一两个具体行动的任何潜在的改进机会。
图 3：团队 1 的 Self Check 全景
随着他们对迭代开发的讨论，他们更仔细地观察了迭代实践的详细图，如下图 4 所示。该图让团队看到了所选实践的细节，这样他们就可以看到是否该实践反应出平衡的实现。当我们问该团队是否迭代时，他们回答是。但如果我们观察迭代的个人的图柱，就会看到经常错过了一些事。在这种情况下，他们在进行规定时间的迭代，但没有交付工作软件，并且因此他们不能获得关于他们在迭代中的表现的任何有意义的反馈。这是经常由过载的迭代所引起的典型的模式。团队试图做太多的事，并进行“类瀑布”（首先分析，然后实现，测试）式的迭代，相反，迭代开发的推荐方式是基本并行地进行分析、实现，和测试。这种“过载的瀑布”方法的后果是，在迭代结束时，他们有许多半成品代码，而没有真正可用的东西。
该图可能没告诉他们那些他们没注意到的东西，但这不均匀的图将引发团队成员之间的讨论，促进团队采取行动改进他们的工作方式。这是我们看到的 Self Check 对一个个团队产生的积极效果。在这种情况下，团队判定迭代严重超量，并且他们决定要更好地将迭代范围内的事情划分优先次序。
图 4：团队 1 的 Self Check 迭代细节
团队二
团队二是分布的，使用 Java 进行开发的 30 人的团队。他们进行 6 个月的项目，并且每 2 周进行一次迭代。与团队一相比，该团队与敏捷开发更进一步，但他们仍有许多改进的余地。
他们的“全景”图如图 5 所示。如我们所看到的，他们似乎在自动的单元测试上有个弱点。该图不仅显示平均值，还显示团队中的不同意见，如细的黑色错误条所指示。这些表明平均值正负的一个标准的偏差，因此团队的大部分分数落到黑色条中，但界外值不会干扰此图。我们可以看到，对于迭代开发的实践，似乎存在非常不同的意见，这是引发进一步讨论的触发器。
图 5：团队 2 的 Self Check 全景
当我们观察他们对迭代实践的使用时，图 6，我们发现他们有一些弱点，但没什么异常。随着团队对实践的讨论，有价值的信息逐渐清楚了。存在不同的意见是由于开发人员对进行迭代开发的好坏给出高分，而测试人员给出低分。测试人员似乎是过度劳累的，并且他们对团队利用迭代技术取得成功的评价较低。团队需要继续讨论以确定他们是否赞成 1）改进自动的单元测试实践，这样开发人员可以交付更高质量的代码，2）改变资源情况，这样就有更多的测试资源，或者 3）通过 —— 举例来说 —— 促使更多的自动化来改变测试的方式。在进行一些讨论之后，团队确定出两个行动：着重于开发人员的测试以减少测试团队的负担，并且提高他们评估的能力（利用速度），这样他们可以更现实地决定在迭代中干什么。
图 6：团队 2 的 Self Check 迭代细节
定制 Self Check 产品
Self Check 产品可以单独用作“映像”工具。但团队还可以使用通过添加上下文和成果而收集来的信息，参见表 1，这尤其在生成经验报告时有用。
不会存在两个过程指导赞成同一组最佳的问题或量度的，这就是为什么 Self Check 允许您定制。我们确实建议一组轻量的公分母，这样经验报告将给出完全的描述，并且我们建议您从那个起始点开始添加如您希望的那样多或那样少的公分母。此外，在调查过程中收集的来自团队成员的评论十分有用，但只有当它们引起受关注的行动时。
表 1：Self Check 量度
| 类别 | 量度 |
|---|
| 环境 | 团队大小，项目大小（人数），地理（同一地点、分布的，或多国家的），审计需求（CMMI、21 CFR part 11，ISO 等等），迭代长度，发布长度，和技术（Java、C，您是用网络连接 web GUI、设备驱动器、数据库中间件吗？等等）。 |
|---|
| 所做的工作 | 实践调查平均水平和偏差。包括公共的实践和您定制的实践。添加一些客观量度，例如 百分之多少的单元测试代码覆盖率，断言或用户事件，构建之间的时间，和用到了百分之多少的反馈。 |
|---|
| 成果 | 周期时间（安装的观念或客户价值），质量（发布后的 6 和 12 个月），客户满意度。您可能还想度量生产率和灵活性。 |
|---|
经验报告在长度上可以从一个幻灯片到 10 页的正式文件，例如 Sato、Bassi 和 Bravo
10
进行的 XP:EF 研究。两种形式都能有效地不仅告诉您的同事您是否采用了实践，还告诉您的同事您进行每种实践的什么感受有多少。这让您可以随着时间的过去，您从较不敏捷的方法演进到较敏捷的开发方法，获取您正在经历的过程。
结束语
Self Check 令团队的工程师在感觉不到受到了外部团体按它自己的议程进行的“评估”的情况下，讨论自己的数据并改进过程。随着时间的过去，团队可能希望将客观的量度加入 Self Check 中，作为度量实践采用的方法，尽管这可能需要两个或多个环境支持，并且同时运行。
在记得缺陷的同时使用 Self Check 已经对我们的团队有效。当然，在采用任何评估或量度时，团队都应该避免本文中介绍的“倒退”的五个致命的危险。在早期的 Self Check 产品中已经将它们排除。不论您使用 Self Check 还是另一种方法来映射和评估，避免这五个缺陷可以将您的量度或所了解的教训的计划从团队惧怕的东西转变为他们想要的东西，并传播给他们同级的团队。
将这些量度作为您追溯的一部分不能保证项目的成功。团队可以拥有表面上很好的数字，但仍旧失败。这些技术不是防止失败的保险，而是为团队提供的，用于频繁的小步幅的迈向改进的工具。
我们相信我们从六年的痛苦中所了解的教训将帮助加速您的改进工作，并且将令您不在那些我们发现的缺陷上浪费。
致谢
IBM 的 Ted Rivera、Kim Caputo、Kay Johnson、Alma Erika Torres Mendoza、Victoria Thio、Inge Buecker、Brent Hodges、James Jones、Scott Will，和 Millard Ellingsworth 在通过使用和反馈来改进框架方面是十分重要的。从 2002 年起，NC 州立大学的 Laurie Williams 也帮助 IBM 的敏捷团队。
参考文献
- William Krebs 和 Per Kroll。“Using Evaluation Frameworks for Quick Reflections”，AgileJournal.com，2008 年 2 月
- William Krebs，“Turning the Knobs: A Coaching Pattern for XP Through Agile Metrics”，出自 Extreme Programming and Agile Methods - XP/Agile Universe 2002。LNCS 2418，Springer，页码 60-69。
- Laurie Williams，William Krebs，Lucas Layman，和 Annie I. Antón，“Toward a Framework for Evaluating Extreme Programming”，Proceedings of the 8th International Conference on Empirical Assessment in Software Engineering（EASE 2004），苏格兰爱丁堡，页码 11-20
- Laurie Williams，Lucas Layman，和 William Krebs，“Extreme Programming Evaluation Framework for Object-Oriented Languages - Version 1.4”，北卡罗来纳州立大学计算机科学系 TR-2004-18。
- William Krebs，Chih-Wei Ho，Laurie Williams，Lucas Layman。“Rational Unified Process Evaluation Framework Version 1.0”北卡罗来纳州立大学计算机科学系 TR-2005-46。
- Mary 和 Tom Poppendieck，Implementing Lean Software Development，Addison Wesley，2007 年。
- Ken Schwaber。Agile Project Management with Scrum，Microsoft Press。2004 年。
- Dean Leffingwell。Scaling Software Agility，Addison Wesley，2007 年，页码 314。
- Esther Derby and Diana Larsen。Agile Retrospectives。Pragmatic Bookshelf。2006 年。
- Danilo Sato，Dairton Bassi，Mariana Bravo，Alfredo Goldman，Fabio Kon。“Experiences Tracking Agile Projects: an Empirical Survey”。Journal of the Brazilian Computer Society。
参考资料 学习
讨论
作者简介  | 
| | Per Kroll 是 IBM Rational Expertise Development and Innovation 的一名主架构师，这是一个组织改进社区、门户、方法、培训和服务资产，帮助客户和合作伙伴进行软件和系统开发。Per 也是 Eclipse Process Framework Project 的项目负责人，该项目是一个集中在软件实践方面的开源项目，并且他在过去的十年中一直是 RUP 的驱动力量。Per 在供应链管理、电信、通信，和软件产品开发方面有二十年的软件开发经验。他与 Philippe Kruchten 合著了 The Rational Unified Process Made Easy - A Practitioner's Guide，并与 Bruce MacIsaac 合著了 Agility and Discipline Made Easy - Practices from OpenUP and RUP。Per 经常在讨论会上进行演讲，并且还写过许多关于软件工程的文章。 |
| 
| | William Krebs 是 IBM Rational 软件的高级软件转换顾问，从 1982 年开始，他在 IBM 的五个地点从事过开发员、性能工程师以及过程顾问。他从 2001 年开始实践和研究敏捷和精简开发，使用了 XP 和开发 RUP 内容。他展示了 XP/Agile Universe 和 IBM 研究所，并且是第一个在敏捷方面的 IBM 学术技术研讨会的主办者之一。他是 IEEE，Agile Alliance 以及 Agile Carolinas 的成员之一，他目前的工作是在公司范围部署最佳开发实践。 |
对本文的评价
| 
