您的位置： >>
　　近日，一些评论员提出了是否可将敏捷方法应用于硬件开发项目中的疑问。 　　在电子工程专辑中发表了一篇文章：
　　他提出了一个问题：
将敏捷方法应用到硬件开发中的做法是否存在争议？那些用来指导敏捷软件开发团队的方法论，在片上系统（SoC，System on Chip）的团队中是否仍旧有着相同的指导意义呢？在这两个截然不同的领域中是否存在很大差异？
　　接着，他在文章中提到了一段关于敏捷宣言（）的讨论，以及其如何使敏捷方法成为软件开发的指导思想。然后引出了他的问题&&在硬件开发中敏捷行为是否适用？他提到：
对于那些将硬件研发作为一个创新过程的团队来说，很难否定敏捷的价值观是否直接受用。但仅仅关注价值观层面显然是不够的。从某种意义上来讲，抽象的价值观需要转变为具体的实践。幸运地是，软件开发团队已经积累了丰富的实践经验，这些实践恰好体现了敏捷的价值，同时也可在硬件开发中发挥指导性的作用。
　　他首先承认了在软件和硬件研发活动中存在的不同有着一定的必然性，然后还鼓励硬件团队要在硬件环境中进行敏捷实践的尝试。
　　接着，他以软件开发中的持续交付为例：
最有代表性的一项实践，就是为客户提供更早地或持续地部署。对于大多数敏捷型软件团队来讲，持续部署对项目的成功起着决定性的作用。不幸地是，在硬件研发中适用性的缺乏，意图打破敏捷的这个特征。尤其对于专用集成电路（ASIC，Application Specific Integrated Circuit）来说，实施持续交付显然不现实。但是，一个实践的不理想并不意味着将整套实践体系否定。没有哪个敏捷型软件开发团队能将敏捷开发的思想实现的淋漓尽致，对于硬件团队，我们也应该持相同的态度。
　　在最后的结论中，他向以硬件为主的组织提出了倡议：
在硬件开发中需要有所改变。不管这是从改变规范、人员调整、团队激励还是技术开始，变化都无法避免。那些为了获得更好成绩而放弃现有思想的团队，在敏捷宣言的带领下，将会在硬件开发领域重振旗鼓，并取得更好的突破。相反，那些墨守成规的团队，将会在现代化的硬件开发大潮下，继续从事着徒劳且低效的工作。
　　于今日也以类似的方式写谈论了关于：
　　他提供了一个列表，在列表中记录了硬件项目中的相关问题以及他的回复，意在以此来引导敏捷思想的实施：
在进行非软件项目时（固件类、电子类、机械类等），敏捷实践的思想和过程是否仍旧有效？
要想使Scrum过程框架在这些项目中发挥作用，需要做哪些调整？
在围绕最小可市场化功能（Minimal Marketable Feature）、紧急设计（Emergent Design）以及保持设计垂直瘦小（thin vertical slices）层面，我们期望有哪些调整？
在用户故事层面，我们期望有哪些调整？
用户故事如何根据为用户带来价值的不同，来确定优先级？
用户故事是我们做需求管理时唯一可以使用的工具吗？
用户故事甚至在Scrum中都没有被列为官方要求，那我们为什么就不能沿用传统的需求调研管理方法呢？
当我们需要将一个电路板（或原型）发送给生产厂商，此时，连一次完整的迭代还未完成，又该如何去做呢？
依赖和关键路径分析如何去做？
或许我们不必持续地做关键路径的分析，但是我们仍然有专家并非永久致力于团队。这种局面我们如何去面对？
　　在每个问题之后，他都进行了简要的回答，然后就实际实践中可能遇到的冲突和如何去解决问题进行了讨论。
　　敏捷实践真的能适用于硬件研发么，要想敏捷的思想发挥作用，还需要做出那些改变呢？
　　查看英文原文：
软件工程热门文章
软件工程最新文章登录以解锁更多InfoQ新功能
获取更新并接收通知
给您喜爱的内容点赞
关注您喜爱的编辑与同行
966,690 九月 独立访问用户
语言 & 开发
架构 & 设计
文化 & 方法
您目前处于：
硬件也敏捷！
硬件也敏捷！
Nancy Van Schooenderwoert
0&他的粉丝
0&他的粉丝
日. 估计阅读时间:
硅谷人工智能、机器学习、互联网金融、未来移动技术架构 ，
相关厂商内容
相关赞助商
Ward介绍到，当新产品理念推进到了特定节点的时候，就需要面对公司内部的官僚流程。为了避免陷入到相应流程带来的文书工作之中，他们俩首先找到一个新颖的产品构思，然后推动另一个团队采用它。接下来，他们重复这个过程，做好新产品构思的快速迭代，并展示足够的可行性，从而使得其他人也开始认识到这一产品构思的价值，并促使其顺利通过内部官僚体系的流程。
结对、简洁、测试优先（test first）等后来演化为TDD的实践和概念就此诞生和成长。就这样，在硬件相关的工作中，基础敏捷实践TDD便应运而生。
在敏捷ASIC设计中引入敏捷软件中的测试驱动开发理念
受到在软件开发中运用TDD的启发，硬件验证工程师Neil Johnson决定在他对SoC（片上系统）进行验证的工作中进行尝试。
为了便于理解验证工程师的工作职责，我们可以观察一下，下面这幅来自另一个不同行业的类似工作模型。在SoC开发过程中，验证工程师与电路设计师并肩工作，采用与女裁缝和时尚设计师的协同方式相类似的工作模式。这幅图片展示了在设计并制作一套全新的外衣时，所需经历的工作步骤。在最后一步里，只有女裁缝完成了自己的工作，而且没有引入任何缺陷的情况下，设计师才能够对设计方案进行问题修正。而如果女裁缝使用了错误的织物，或是未能正确测量模特，那么设计师将不得不应对这些由她的设计方案以外的缺陷所引出的问题。
图1. 验证工程师的工作内容——与时尚设计的工作模型的类比。设计师画出服装的设计图并选择织物。接下来女裁缝测量模特身材，在设计图的基础上打样并缝制服装。最后设计师查看模特服装穿着的效果，并对其设计进行“调试”。
图 2. 验证工程师与电路设计师协同工作时，需要做哪些事情。电路设计师首先使用CAD系统绘制电路，接下来明确标注组件数据。验证工程师编写测试代码，进行仿真设计并检查电路表现。最后电路设计师查看SoC电路表现，并对电路设计进行“调试”。
同样，电子工程师负责设计电路；而验证工程师负责编写测试代码，并对SoC承载的功能进行确认，从而完成设计的验证工作。因此，如果验证工程师编写的测试代码中出现了Bug，那么显然会对测试效果的可靠性造成影响。
如果验证阶段引入了新的Bug，那么整个工作流程中就不得不增加额外的循环来查错和修复，这将极大地增加硬件开发的时间。因此，Neil希望弄清楚，如果在“编写测试代码”的阶段使用TDD，那么与过去相比，他的验证工作能够变得有多“干净”。当Neil花费几周时间将TDD框架落实到位，而后又经过数周时间对TDD工作流进行了熟悉之后，他准备好了对采用TDD进行工作前后的情况进行评估和对比。
Neil对使用TDD前后的结果进行了基准测试，发现当使用TDD的SVUnit框架时，他的测试代码只出现了1个Bug；而在使用传统SoC验证方法的时候，会出现15个Bug。诚然，这个结果只是基于一套数据样本，但依旧展现出了令人惊讶的提升——特别考虑到Neil是一位经验丰富的验证工程师，这一提升尤为显著。
敏捷IC开发——每个Sprint阶段都产出可用硬件
德州仪器德国分部的一位数字设计总监，对于使用Scrum加速定制化IC（用于闪存和铁电存储器FRAM）的交付非常感兴趣。在当时，德州仪器的一般交付周期为12到36个月，而面对这种特殊用途的IC，其最短交付周期是18个月。但一家新客户对交付周期提出了更高的要求。那么，德州仪器将如何使用Scrum来加速IC开发呢？
在项目启动阶段，他们尝试寻找一位能够与之共事的Scrum教练，但却根本找不到熟悉IC领域的人选。不过，他们依旧确信，至少可以将部分Scrum或敏捷实践引入到他们的硬件工作中。
最终，这支团队选择采用以下敏捷实践：
跨职能团队
相对大小估算（与已知特性相比，目标任务更大还是更小？）
每周进行两到三次立会
每个迭代周期中都交付可用硬件
此时，这里的关键问题是，当芯片制造流程超过四周，而且并不在团队掌控之中的情况下，究竟如何在“每个迭代中”将可用硬件交付给客户。除此之外，上述其他敏捷实践则可以非常容易地运用到硬件工作中。
要想以增量方式工作，可以采用的一个方法，是交付经过编程的FPGA——它们具有与完整IC内部的每个IP块非常相似的表现（一般来说，每个IP块的内部循环时间是6到12个月）。团队有能力逐个交付已经完成的FPGA，而且他们主动向客户建议采用这样的方法。不过，虽然这么做能够在一定程度上降低风险，但该外部客户依旧不希望不断被这些中间步骤打扰——他们只想看到完整的IC。
由于不能与外部客户进行共同迭代，数字设计团队找到了愿意配合的内部客户：团队可以向德州仪器内部的软件工程团队交付FPGA——其软件是在进行硅制造前的最后一步。
接下来，数字设计团队开始逐月向软件工程团队交付其FPGA。通过使用可用硬件原型，而不是仅仅停留在设计阶段的方式，团队让Bug难以藏身。其“每个为期四周的Sprint完成一份可用硬件”的目标得以实现，尽管只是通过将FPGA硬件作为IP块原型的方式。就这样，数字设计团队将循环时间从每个IP块“6到12个月”，降低为“每四周”。
那么，面向外部客户的交付周期时间是否也有得到了优化？不幸的是，由于外部商业原因，这个项目在完成前就被终止了，因此我们无从看到数据，来了解面向外部的交付周期被缩短了多少。
除了有效减少IP块的周期时间外，敏捷实践还带来了其他一些意义重大的好处。数字设计团队在工作中需要面对一套全新的平台，仅该平台就极大增加了不确定性和复杂度。如果他们使用瀑布模型的话，意味着在开始工作前需要先投入为期12个月的规范工作。
领导数字设计团队的Tobias Leisgang发现，“规划扑克和相对大小估算，有助于工程师们找出沟通问题以及对范围的误解，同时也让整体工作更具有现实感，而不必经历为期数周的详细规划阶段。跨职能团队确保反馈回路得以缩短，我们不会遇到在制造出一块昂贵的硅片之后，测试工程师才发现模拟电路无法测试的情况。
采用原型电路板的敏捷电气
结合一些前期规划，我们可以采用迭代作为主要战略，特别是对于早期产品原型中的电路板和其他物理组件部分。施耐德电气的一支跨职能团队开发了一套照明控制系统，他们在一个Sprint里，整合了3块电路板和告警灯。
该团队的领导者Timo Punkka，介绍了他们的射频控制照明调光系统是如何在4周Sprint中演进的：
“开发团队由固件、电气、PCB布局和塑料方面的设计者组成。原型产品包括三块PCB板、一套电源、一套控制单元、一套UI以及射频转换器。在第一个迭代过程中，只有电源相关的PCB板就绪了，而其他两块PCB板则通过通用原型板代替。在第二个迭代周期中，所有PCB板均已可用，到了Sprint结束的时候，用于塑料部分的快速原型也已到位。在Sprint回顾中，原型帮助我们体会到，如果选择这一概念，那么产品外观的真实感受会是怎样。另外，固件提供了简单的开关功能。要想做到这一切，我们需要与原型制造商之间建立可靠的合作关系。在这个案例中，原型制造商同意，当按照先期约定的时间收到最终图稿后，就能够在次日交付制造好的硬件原型。
（点击图片以放大查看）
图3. 4周Sprint产出的调光系统原型。
这支团队使用负载弹簧连接器和磁铁，将每个模块连接到一起（类似Mac的电源连接器），以验证他们的想法。他们还试着将射频部分和天线构建在PCB尺寸的SD卡上。这两个实验，都涉及了大量的不确定性——最终这些硬件都能够运行，但没有人能够预先确保这一点。
对团队来说，这些实践的结果推动了实验的前进，结合其他一些敏捷实践的支持，使之成为一次具有前瞻性的尝试：
TDD确保他们能够在早期就尝试测试并持续进行实验，而不会打破早期设计决策。
模块化让他们能够分离出需要进行更多实验的区域。
仿真使得及早进行实验成为可能，从而规避了针对实际目标进行实验带来的高昂成本。
Timo观察到，“实验”或者说“逐步达成（Emergence）”，在敏捷思维中处于最核心的位置。它与“第一次就把事情做对”的思路截然相反。通过在一次Sprint中构建一份原型，让硬件、软件和需求能够以并行的步骤逐步实现。
汽车行业的敏捷研发
Wikispeed项目为我们带来了一部可以合法上路的汽车，它由志愿者打造，且团队每周都会对它进行修订。现在，消费者们就可以购买Wikispeed汽车，而且它的百英里油耗仅为一加仑！面对“需要数年之久才能够将一部新车模型投放到市场”的传统理念，Wikispeed项目向其发起了挑战。Wikispeed汽车的研发仅仅耗时3个月，而且志愿者们持续构建和销售它。该项目的核心策略是模块化。得益于稳定的接口，他们每周都会修订8个模块中的一个或几个并进行快速集成。这要归功于他们采用的交错迭代的方法，它支持在每个模块中并行地进行实验和学习。
图4. Wikispeed汽车分解视图，展现了它的8个模块。
另一个关键策略是在材料类型和数量方面的简洁性：“核心XM（极限制造，eXtreme Manufacturing）实践是只使用那些能够在不超过一周的时间里进行低成本迭代（重新制作）的材料，并确保在实际中采用的材料和工艺的类型都尽可能少，以快速积累丰富的经验。”
Wikispeed团队的领导者是在西雅图工作的软件咨询顾问Joe Justice，这是一支由国际化志愿者组成的团队，他们使用敏捷技术来构建汽车。在2008年，Justice注意到Progressive Insurance X大奖的信息——这是一项奖金额度达到一千万美元的评选，旨在探寻是否有可能构建出油耗低至100MPG（英里/加仑）且符合道路安全规范要求的汽车。他参加了这一活动，并在博客上公布了自己的想法——于是一些读者加入了他的团队。
Joe感到非常吃惊：有如此多的人，愿意努力且免费地工作，只是为了构建一些东西，以开源的方式存在，并且能够让所有人受益。目前，已经有23个国家中出现了Wikispeed商店。其汽车售价大约为两万五千美元；消费者也可以选择花费一万美元，从套件开始自己搭建它。
Joe从Wikispeed团队中获得的第二个关键认知是人们的动机。他表示，与其他志愿者相比， Daniel Pink的思路在目标、掌握力和使命感方面都更胜一筹。他们积极主动地互相学习，并保持互相关注。
Wikispeed汽车由八个模块组成（引擎、框架、碳纤维车身等等）。得益于这些模块之间的松耦合关系，人们可以便捷地替换每一个部分。团队每周都会对八个模块中的一个或几个进行修订。并保证随时都有一部能够运转的Wikispeed汽车版本，同时还能够快速实现任何升级。那些已经拥有Wikispeed汽车的人们，则可以购入新的模块，并自己动手替换原来的对应部分，而无需任何汽车领域的技术背景。
在Progressive Insurance X大奖的竞赛中，Wikispeed在核心组别获得了并列第十名的位置，将超过一百款来自全球各地、得到了企业和大学的充裕资金支持的汽车甩在了身后。
Wikispeed团队在运用“极限制造（XM）”过程中积累的经验，反映了这样一个现象：Joe Justice和团队中的许多志愿者都具有敏捷软件开发的背景，他们把这一方向的背景知识引入到了XM中。当被问起在制造和工程领域运用敏捷方法的过程中，学到了哪些东西时，Joe的回答是：
当我开始与Jeff Sutherland一起进行联合培养的时候，我建议工程师们使用面向对象的架构、契约优先的设计以及测试驱动开发（TDD）。我所学到的第一个要点，是Jeff告诉我，我需要在工程领域打造这些理念——对软件人士而言，这些都是显而易见的知识，但对工程师而言则必须经过“翻译“才能够掌握。
对于进行极限制造（XM）：
第一步也即是第一个Sprint，将产品或服务划分为10个以内的松耦合模块。
第二步：明确面向对象架构、每个模块的输入输出、这些模块在物理上或通过数据如何互相联结、以及冷却等等方面的内容；但要注意，这个阶段应避免涉及任何模块内部的设计或架构。此时应只关注模块之间的接口。
第三步：通过以团队方式对每个模块进行版本搭建和重建，进行迭代；同时以增量的方式从实践中学习。一旦他们开始进行概念验证工作，就会在每个模块中增加“illities（对非功能性需求的一些响应）”，就像持久性、可承受性等等。
大部分工程师团队都会遇到这样一个经典问题：他们希望提前做好全部架构工作——所有的接口及“箱子”（接口背后的子系统）中的全部内在。然而，这将产生巨大的前置时间并造成大量浪费。
还有部分团队希望甩开架构直接投入到具体工作中。这种方式起步固然迅速，但很快就会放缓节奏。
这两类团队都很少采用最佳的方式：预先进行架构设计，但只细化到接口层面，接下来停止架构工作，通过实践并构建“箱子”内部来学习。这似乎是产出可交付产品的最快方式，而且它能够保证持续的速度。
在一款复杂的物理产品中，最好综合运用一些迭代和并行方法。当工作性质中具有“发明部分”的时候，这一点尤为有用。以Wikispeed汽车为例，它的各个模块并行开发，错落添加各项变更，因此这些模块不会同时发生故障。这确保了团队每周都能够交付可用的软硬件。
我们刚才已经浏览了一些硬件开发过程中使用的经典技术：
仿真或原型设计（IC开发领域与电气领域）
模块化（电气领域与Wikispeed汽车）
组成部分的简洁性（Wikispeed汽车）
我们还看到了一些直接从敏捷软件实践中借鉴的内容：
TDD（ASIC验证）
短迭代（IC开发、电气领域、Wikispeed汽车）
面向对象设计（Wikispeed汽车）
长期以来，硬件领域一直向着更具灵活性的方向不断前进。部分硬件现已支持非常迅捷的变更，使得不必提前进行完整规划，即可让良好设计逐步浮现成为可能。而对于尚未达到这样灵活性水平的地方，我们会自然而然地混合运用模拟、模块化和预先规划。提前许久便锁定设计，是极具风险的策略，而综合运用这些技术则能够缓和这些风险。
这里还引出了另一个非常强大的缓和策略——众包（或者称之为：调动团队的集体智慧）能够在一些关键的敏捷实践中发挥作用，例如回顾、结对编程、每日立会、故事编写等等。在任何一支运行良好的敏捷团队中，集体智慧都能够发挥强大的作用。
是的，要想在采用短迭代方式的同时，还保证每次迭代都能产出可用硬件，是件困难的事情。不过，我们刚才讨论了一些有助于团队落实这一方式的策略：
经典的硬件开发技术，例如仿真和模块化，能够极大提高灵活性和开发速度。
可以将诸如TDD和短迭代等敏捷软件实践，引入硬件开发工作中，从而加速实验和学习的过程。
有时候我们需要超越项目要求的范围（例如，在一个月内完成ASIC）去看问题，并满足客户（或是内部客户）更大的需求。激发团队智慧将帮助我们获得达成目标所需的创造力。
借助我们手中的这些“思维工具”，硬件绝对可以“变得敏捷”。
帮助敏捷工程社区浮现！
在硬件开发工作中，你是否使用了一些符合敏捷准则的技术？向社区分享你的经验和心得吧！
敏捷工程项目的目标，是在敏捷联盟内部，收集关于正在使用的技术的简短经验报告，以便为那些专注于软件工程之外其他工程领域的敏捷教练提供支持。这些报告面向所有人免费提供，读者可以点击此以了解更多信息。
作为一位工程师、管理者和顾问，Nancy Van Schooenderwoert率先将敏捷方法运用到嵌入式开发领域。从1998年开始，她一直在苛求安全、高度管制的行业中，引领软件开发领域里的敏捷变革活动，并为客户提供敏捷技术和管理艺术方面的培训。另外，她还是Agile Times和Cutter IT杂志的贡献者，以及IEEE 1648 敏捷客户委员会的成员。她在全球诸多软件会议上发表过演讲，也曾在Agile New England担任大波士顿地区高级敏捷用户组的主席。Nancy创立了Lean-Agile Partners有限公司并出任总裁。可以通过向她发送邮件，或在Twitter上通过@vanschoo与她联系。
Johnson，Neil；测试驱动与硬件验证的新范式（TDD and A New Paradigm for Hardware Verification）；Agile 2014大会，可前往以下网址阅读：
Leisgang，Tobias；如何与足球队一道打篮球（How to Play Basketball With a Soccer Team，论文）；Agile 2012大会。
Tobias Leisgang，德州仪器德国慕尼黑分公司系统工程经理；由作者进行采访。
Punkka，Timo：嵌入式敏捷（Embedded Agile，论文）；发表于2010年嵌入式系统大会。
Denning，Steve，Wikispeed：如何在三个月内开发一部100MPG汽车（Wikispeed: How a 100 mpg Car Was Developed in 3 Months）；福布斯杂志20125月，可前往以下网址阅读/sites/stevedenning//wikispeed-how-a-100-mpg-car-was-developed-in-3-months/
查看英文原文：
Author Contacted
语言 & 开发
25 他的粉丝
文化 & 方法
16 他的粉丝
0 他的粉丝
0 他的粉丝
0 他的粉丝
客户及需求
0 他的粉丝
0 他的粉丝
0 他的粉丝
10 他的粉丝
8 他的粉丝
0 他的粉丝
JavaScript
25 他的粉丝
0 他的粉丝
测试驱动开发
0 他的粉丝
4 他的粉丝
告诉我们您的想法
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
赞助商链接
InfoQ每周精要
订阅InfoQ每周精要，加入拥有25万多名资深开发者的庞大技术社区。
架构 & 设计
文化 & 方法
<及所有内容，版权所有 &#169;
C4Media Inc.
服务器由 提供, 我们最信赖的ISP伙伴。
北京创新网媒广告有限公司
京ICP备号-7
找回密码....
InfoQ账号使用的E-mail
关注你最喜爱的话题和作者
快速浏览网站内你所感兴趣话题的精选内容。
内容自由定制
选择想要阅读的主题和喜爱的作者定制自己的新闻源。
设置通知机制以获取内容更新对您而言是否重要
注意：如果要修改您的邮箱，我们将会发送确认邮件到您原来的邮箱。
使用现有的公司名称
修改公司名称为：
公司性质：
使用现有的公司性质
修改公司性质为:
使用现有的公司规模
修改公司规模为：
使用现在的国家
使用现在的省份
Subscribe to our newsletter?
Subscribe to our industry email notices?
我们发现您在使用ad blocker。
我们理解您使用ad blocker的初衷，但为了保证InfoQ能够继续以免费方式为您服务，我们需要您的支持。InfoQ绝不会在未经您许可的情况下将您的数据提供给第三方。我们仅将其用于向读者发送相关广告内容。请您将InfoQ添加至白名单，感谢您的理解与支持。[原创]如何对Scrum团队进行绩效考核 - 敏捷开发，Scrum实践，真实案例
- 畅享博客
|收藏博客|加入友情链接|给博主留言
我是袁斌 （Andy Yuan），
Scrum、AUP、Agile modeling、XP、Kanban的实践者，
北京迅思威尔（AgileDo）敏捷教练。
迅思威尔 （AgileDo），敏捷培训整体解决方案提供商。
迅思威尔2012年推出了“敏捷开发定制培训”和“敏捷孵化器”服务，已经为包含互联网、移动互联网、游戏、离岸、外包等8个行业近百家客户提供服务
[原创]如何对Scrum团队进行绩效考核
[原创]如何对Scrum团队进行绩效考核
如何对Scrum团队进行绩效考核对Scrum团队的绩效考核，是对整个团队对于commitment的实现的考核，分为以下一些方面讨论：1. 不要对某个人单独考核。a) 团队实现commitment是核心，考核的目标是为了实现这个核心，只有当某个人严重影响了实现commitment，对这个人的考核才会有意义。b) 没有特别有效的指标对个人单独考核。可能某个程序员没有写一行代码，但他解决了大多数的技术难点；某个程序员可能只有很少的Bug，但这是来自于结对编程的搭档。如果一定要有一个指标，应该是对团队的贡献2. 如何对团队进行考核a) 将团队的部分奖金和企业的效益挂钩，目的是使团队考虑commitment时是以商业价值为主，而不是单纯以技术实现为主b) 要么团队全部人员得到奖金，要么全部得不到。其中一个好处：不是单纯PM/SM去督促某个偷懒的人工作，而是团队自己在淘汰其中会影响到commitment实现的成员；同时大家也会主动互相协助3. 不对某个人单独考核，但需要对个人进行career planning，及时沟通他对团队的贡献和不足，提供实在的帮助。Andy Yuan，袁斌，迅思威尔资深敏捷咨询师
迅思威尔－国内专业敏捷项目管理和敏捷开发过程的培训、实践基地，欢迎 访问
&<div class="votes" id="Score
查阅更多相关主题的帖子:
下一篇：上一篇：
您还未登录，不能对文章发表评论！请先}