• Do you provide significant organizational roadblock removal for agile teams? Do they perceive you as a coach and leader more than as a manager?

• Do you use metrics to help teams improve their performance and to help senior leaders make decisions that improve value delivery?

• How are suppliers encouraged to work in an agile way? Does your outsourcing help or hinder your agile teams?

Agile manager更有远见，不是一个仅仅为管理团体完成项目的管理者。Agile manager将帮助Team成员在企业中的职业发展之路上不断进步，消灭掉那些困扰他们职业发展道理上的障碍，从而帮助我们的客户得到满意的产品，对我 们保持客户的满意度，客户清楚的看到的投入是有价值的，获得客户的长期信任。

Are you an Agile manager yet?

但是现在行业中，需求变化太快，不管我们怎么努力去做，发现还是不能满足客户的需要，不管需求搞得多么细，到交付产品给客户的事情，总是有这样那样的问 题，这个时候就不得不去修改我们的软件，这是华为面临的一个挑战，如何解决这个问题？

软件开发中有三个要素：人、过程、技术和工具。对于一个软件项目成功来说，这三个要素都不可省，而在以前大家强调IPD和CMM，更多的是强调大家规范的 把它运作起来，对于人、技术和工具基本上不提了，忽略了，所以后来就反馈出一个问题，就是很多项目，看起来那个过程做的那个漂亮，那个报告写得那个完美， 但是交出去的产品那个烂，其实这三个因素是缺一不可的，你必须得均匀的发展，还有一个是人的方面，因为人是具备创造能力的，所以从华为的教训给我启发，过 度的关注过程而忽视人、忽视技术和工具，我们就得要思考和反省了。

针对这些问题，华为也就提出了敏捷。华为在99年之前基本上都是土生土长游击队的做法，到了2001年的时候就引入了IPD和CMM，到2006年的时 候，就发现了瀑布模型的问题，如交付周期特别长，就是每做一个客户的需求，然后一分析，这样一走半年就过去了，所以就引入了RUP，最初的想法就是加速我 们项目的交付周期，能够快速的给客户响应，但是敏捷实际上已经进入了一个低谷期，所以当时就引入了迭代，实施了一年之后也发现，RUP里面的东西实际上也 是挺多的，所以后来就接触了XP、SCRUM这些方法，这样就从07年开始向敏捷这个方向在走。

有一个图在业界流传比较广泛，也叫洋葱图，共分三圈，也就是从三个不同层面描述了敏捷开发方面的一些最佳实践。XP为什么叫极限编程？如果你觉得这个软件 开发的实践是一个好的实践，那么你就把它发挥到极致。比如，结对编程，一个在编，一个人在看，实际上看的人不会白看，其实起到了一个review的作用， 既然review这个作用有效，那么为什么不把这个作用发挥到极致，所以就采用了结对编程将review这个作用发挥到极致。在敏捷中有一个8个字的原 则：沟通、反馈、交流、勇气。它认为项目团队中的成员这个沟通是比较重要的，既然你非常重要，那么我也要把你发挥到极致，所以两个人一起在干活的时候就会 不停的有交流与沟通，所以，结对编程是一个典型的把review、沟通交流发挥到极致的实践。另外，TDD也可以认为是那刚好够用的事情发挥到极致。我们 以前传统的软件开发的做法是，先做好这个软件，然后去测，看看是不是实现了这样一个功能，但是我们总会发现这里面有很多代码其实是从来就没有用过的，只是 在下代码的时候顺手就把它写了，在分析那些产品的时候发现有的产品这样的没用到的代码高达50%，而TDD的思想是，我既然要实现什么功能，然后我就先写 对应的用例来验证它，然后在开发的时候就开始写代码，使得这个用例刚好通过，这样就使得我们写出来的代码是刚好满足这个系统的功能的代码，这样，前面出现 的50%就可以不用做了，这就是把刚好够用发挥到极致。其他的就不一一讲了。XP在2001年到2003年之间非常的红火，过了之后又相对的沉寂了一点， 现在又冒出来一个新的敏捷的方法论，就是SCRUM。XP是过分的强调将软件开发里面的实践发挥到极致，而这些实践都是同编程实践相关，但是在管理方面就 比较弱，所以，在用了几年之后，大家发挥XP不是起到那么大的作用，所以就开始沉寂下来。这个时候就出现一个流派，就是SCRUM。SCRUM其实就是一 个非常非常轻量的项目管理框架，基本上没有什么编码实践方面的东西，你说看到的都是管理上的活动，这个管理上的活动很多人就会有一种似曾相识的感觉，记得 前不久，同华为的一个项目团队在聊，就谈到这个项目的backlog，一讲，项目团队的人就说其实他就是那样子做的，他以前也没与听说过什么SCRUM， 就是把这些需求一条一条的列出来，镍镉优先级，估个工作量，一看，就是这个东西。SCRUM的核心其实比较简单，2分钟就能讲出来，就是3个3。一、3个 角色。Product Owner，负责决定产品要做什么，做成什么样子；SCRUM Master，保证项目能够遵循SCRUM的方式运作下来；项目团队成员，包含开发、测试、质量等等所有的人。二、3种会议。迭代的计划会议、中间的站立 式会议、迭代的评估会议，属于三个管理的活动。三、3个交付件。待开发的任务列表、待修复的缺陷任务列表、项目的进度图。SCRUM就是通过这3个3将项 目非常简洁的管理起来，有一个思考就是关于PMP里面讲到的9大领域多少活动不一定对这种敏捷项目适用。那么大家可能提出一个疑问，就是项目的进度是不是 就不可视了。其实，敏捷项目的进度可视很简单，就是通过一个白板（进度墙、任务看板），将每个人的进度情况这么一贴，这就是最简单最直接的管理方式，一 看，所有人都知道，就算你去开发一些什么复杂的一些IT支撑系统，可能都起不到这个白板的作用。在华为关于敏捷的一些项目管理工具，用 Scrumworks、Bingo这些管理工具也能够把项目的进度管理起来，但是你要做的就是必须得把电脑打开，要把浏览器打开，这样才能看到你的进度是 什么样子的，而在办公区直接树一个白板就能够很简单、很方便的知道我的这个进度情况。所以，在华为，对于敏捷项目，管理的框架上是采用的SCRUM，指导 如何编码实现上就采用了一些XP的实践，当然XP的实践不会全部去选，会根据项目的实际情况去选一些实践，如果你把所有实践都选的话，实际上的效果是非常 差的。那么如何来选择就得根据项目的实际情况去评价。华为在实践的过程中也引入了精益、消除浪费的思想。比如，在平时的工作中存在停工等活的浪费。什么是 停工等活的浪费呢？比如我们开发在做开发的时候，我们的测试就会轻松一点，那么测试在做测试的时候我们的开发就会轻松一点，大家觉得这样也挺好的，但是你 从整个组织角度去分析，实际上是停工等活的，开发时测试在等着，测试时开发在等着，如果你从精益的角度考虑的话，为何不通过迭代的方式把开发和测试等待的 时候整合在一起来工作，使得效益得到提升。有很多项目团队自己去做了，确实效果比较明显。其实在2006年实践RUP的时候就感觉到这样的好处了是非常明 显的。引入敏捷之后，自然而然的就会想到同公司已有流程之间的关系，原来是IPD+CMM，所以就有同事问到是不是我这个就不用了。分析可以知道，IPD 是决定做不做，决定之后如何去做就可以采用敏捷开发，所以对于敏捷产品的流程就是IPD+敏捷的方式，所以有很多以前采用瀑布型的团队逐步的被敏捷代替 了，还有些团队正在代替中，还有些团队就觉得原来那套玩得很流畅就继续采用原来的方式。所以目前在华为，项目团队是可以自己来选择采用哪种方式进行，现在 可以发现，那些愿意选择敏捷方式走的往往就是原来那些顽固不化的烂项目，因为以前在推流程的时候，那帮人整天在那里叫，有问题，我不干，我不愿意做，实际 上，后来做深入分析发现，他的那种模式并不适合按照瀑布型去做，但现在成了积极分子，所以每个项目的模式是不一样的。

在做敏捷的时候也存在一些容易做的事情和不容易做的事情。比如说SCRUM的项目管理是比较容易去实践的，就是3个3，对于那些想敏捷的，我建议可以先做 这个，还有也会做一些结对编程、持续集成的实践。比较难的，有这么几点。华为从99年开始都是按照开发、测试等团队去运作的，团队与团队之间就会形成部门 的墙（华为有一个外籍员工给起了一个名字叫Chinese Wall），对每个部门来说，希望把这个墙树高一点，这样能获取更多的资源非常顺利的开展工作，所以墙就会越树越高，很多部门甚至还有 checklist，你只要给我什么东西，我就按照checklist打勾，打勾不通过的就要干啥干啥，这样通过约束管理层，罚款的制度就来了，而这个问 题就很难搞，涉及到很多很多的人员，涉及到部门角色定位的问题，这是华为觉得最难的一点。第二难的问题就是TDD，在很多项目都试过，但是试过之后，很多 项目都无疾而终，或者诉苦说这个我实在搞不下去，分析后发现，是涉及人做事情方法的改变，这个挺难的，以前写代码都是边想编写，就能写出来，现在你就得先 想好、验证好等等，然后再想办法填进去，就发现这个很难，这是一个开发习惯的改变，这也是很难的一件事情。第三个，就是Customer Tester，就是要客户参与验证，可能对于互联网企业可以部署一个系统，用户参与测试就可以做起来了，但是对于华为而言，客户是电信企业，而电信是买 方，买了之后再供他们的客户去用，这个里面客户就存在好几层，所以要客户真的参与进来还是比较难的。第四点，也是很难的，我们有一个团队，要到各个团队去 宣传为什么做敏捷，这涉及到观念的转变，所以这也是非常难的事情。（一夜的引入，长时间的改变。）比如你说你这个团队敏捷了，明天就开始站立式会议，但是 你最后会发现，要真正敏捷实际上是一个漫长的过程。

在华为实施敏捷的过程中，也有一些经验性的东西。第一个是QA从警察的角色转变到一个教练的角色。在以前，团队实施CMM的时候，QA更多的是一个警察的 角色，他整天拿着一个checklist、报告什么的到处去团队里面看，你是否ok，不ok就要怎么怎么样，整天就干这个活，但是引入敏捷之后，QA就觉 得有点失落，都敏捷了，我都不知道该怎么下手了，然后，在华为，就把QA转变了一下，将QA更多的充当教练的角色，充当SCRUM Master的角色，他去指导项目团队该如何去开这个站立式会议，该怎么去做迭代的计划等等指导性的工作，这样QA也觉得挺好，这样他能参与到在不同的团 队中去，这样他见得也多，所以在敏捷的实践里面是需要这么一些人来干这么一些事情。第二个就是要营造一个一体化的团队，也就是将所有有墙的部门通通打掉， 直接按照项目型运作，把大家拉到一起，不要考虑你原来是什么部门，先把项目做出来再说，这就是在XP的外圈中的Whole Team实践，因为大家就真正是一条船上的。在很对项目中，总是存在这样的一些人，项目成功不成功对他们是无关紧要的，但是有些人项目不成功对他们是非常 重要的，而真正的敏捷项目就要这些人来挂帅，并且这些人是站在一条战线上的，所以就叫拉到一体化的团队里面来，大家都对交付负责。第三个就是办公环境最好 也能够随着改变。以前大家都是那种小格间的方式，但是这种方式是非常不利于做交流和做项目的。第四个就是现身说法。前面讲到有很多这样的人会到团队中去说 敏捷怎么怎么好，但是如果你让一些对项目成功不成功都不相关的人去讲是没用的，因为大家一听，首先就会质疑50%，所以华为当初经常搞的活动就是让项目经 理他们在讲，将他们当时是怎么开展敏捷的，这样别人一听才能理解到原来你是这么这么做的。

本文来自: 天天测试交流(http://www.365testing.com/bbs/) 详细文章参考：http://www.365testing.com/bbs/thread-13329-1-1.html

Download: http://www.tinypm.com/download

相比较与Version One界面更有趣，颜色不同的story board，就像你的报事贴。user story的管理方面更出色，清晰，用户体验很好.

但Version One针对Srcum的Plan -> Review的过程控制的很清晰。
Tiny Effort, Perfect Management
Lightweight and smart agile collaboration tool with product management, backlog, taskboard, user stories and wiki.
Web-based and internationalized.

The classic metric for an XP/Scrum Team is of course velocity or how much work did the team complete in the last iteration? It was originally created to help a team decide how much they can plan for the next iteration. However the question is frequently asked can we use Velocity to measure the productivity of a team? To compare two teams? Hiren Doshi , points out velocity metric is a very ‘team’ specific metric. In addition, Peter Stevens , Agile Consultant , asks if the teams would have a reason to game the measure: “Is this story a 2 or a 3? That lies purely in the judgment of team. If the team feels a need to deliver as many SP’s as possible, then it’s obviously a three, and maybe a five.”

Dave Nicolette , Agile/Lean Coach , warns us that poorly designed metrics lead to poor outcomes. For example the business that rewards bug fixing and fire fighting – produces people who write bugs and start fires.

In Appropriate Agile Measurement , Deborah Hartmann Preuss, Agile Coach , and Robin Dymond, Agile Management Consultant , offer some heuristics for good Agile measurements:

• Affirms and reinforces Lean and Agile principles
• Measures outcome, not output
• Follows trends, not numbers
• Belongs to a small set of metrics and diagnostics
• Is easy to collect
• Reveals, rather than conceals, its context and significant variables
• Provides fuel for meaningful conversation
• May measure Value (Product) or Process
• Encourages “good-enough” quality

What are good Agile Measures?

Ron Jeffries has offered Running Tested Features:

1. The desired software is broken down into named features (requirements, stories) which are part of what it means to deliver the desired system.
2. For each named feature, there are one or more automated acceptance tests which, when they work, will show that the feature in question is implemented.
3. The RTF metric shows, at every moment in the project, how many features are passing all their acceptance tests

Peter Hundermark , Scrum Coach , suggests that Running Automated Tests are one measure:

Within limits, the more running (i.e. passing) automated tests a team has in place is a positive
measure of quality. Beyond a certain level, this will cease to be true, but we have not yet met a
team that has reached this point. (We hope to!)
…
Anecdotally, this was one of the prime metrics that salesforce.com put in place during its bigbang
transition to Agile.

In addition he offers Work In Progress:

Items (stories) in-progress is a productivity metric. It seeks to help a team track whether they
are working collaboratively or not. The idea in an Agile team is for the whole team, as far as is
reasonably possible, to collaborate on a single work item until it is ‘done’. This increases the
rate of output, quality and cross-learning. It decreases the risk of unfinished items at the end of
the Sprint, which results in waste.
Simply by tracking on a daily basis how many items the team has in-progress will make visible
the extent to which they are collaborating. The chart tracks stories in-progress against days. It
is agnostic of Sprint boundaries. It should trend towards 1 over time. Any value higher than 2 is
cause for action by the ScrumMaster.

Finally Deborah and Robin remind us when designing a metric we should consider not only when to use it, but when to stop using it and how can it be gamed.

出于这样的目的，我们会在这篇文章中审视SOA和敏捷开发的相容性。在此之前，让我们先简短地定义两个概念。

面向服务架构是一种架构风格，其目的是使用交付业务价值的服务来实现业务机动性。

敏捷开发是一种软件开发方法论，其关注点是人们可以快速地交付业务价值。

敏捷、SOA和管理

面向服务架构和敏捷开发过程问世的时间都不太长，并不符合象科学管理或官僚机构这样的传统管理范式[Taylor、Weber、Simon]。

我甚至认为它们超越了同时代的管理理论，如权变（Contingency-）（Vroom）和系统理论（Checkland）。两者代表了人们做事 和看待事物方式上的根本改变：

• 组织（‘职能和官僚政治’ VS ‘跨职能和以流程为中心’）
• 所有权（单一 VS 共享）
• 责任（‘强加和划分’ VS ‘承担和共享’）
• 管理（‘自上而下和权力’ VS ‘中层会师和促进’）
• 以及最重要的看待人的方式（‘作为组织资源的人’ VS ‘人即组织’，[P. Senge，M. Buelens]）。

因此，我们讲它们有很多共同之处：让我们来检验前提，对比12条敏捷原则（http://agilemanifesto.org /principles.html）和SOA原则。看看彼此的匹配程度，以及哪些地方存在潜在的失配。

不象敏捷原则，SOA原则并没有一个统一来源，因此我们选择一个架构师经常用到的来源，即Thomas Erl已经发布的那些原则。（http://www.soaprinciples.com/default.asp）。

通过及早并持续地交付有价值的软件来满足客户是我们最优先关注的事情。

这条原则不象在我们的世界中看起来那样容易理解。在盎格鲁-撒克逊国家（USA、UK），客户就是最终顾客，即买产品的那个人。在荷兰国家（挪威、 德国），客户不见得必须是公司的顾客。例如，若是你为一个在线书店构建软件，客户可以是这家在线书店的销售部，而不是买书的人。

“有价值”一词往往被误读了。在书店这个例子里，如果书店的顾客可以用它来方便地买书，或是由于并不需要书库，因此书更便宜，那软件就是有价值的。 取决于公司的经营模式，我们需要的是一个便宜的解决方案或是一个非常复杂的解决方案。

“及早”同样也经常被误读。如果在线书店提供在线支付，要是你交付的软件缺乏适当的安全性或是经常变动用户界面，书店的顾客就会不满意。但是客户 （销售部门）需要及早不断地交付来划定需求优先级、运行beta测试、调整销售流程等。因此，对我们来说，这条原则讲的是让软件对业务有价值。

SOA关心的是企业架构，使用服务作为定义概念。服务是给流程增加价值 的活动。这个活动可以由一段软件代码自动化，可以是一个人类活动或者是二者的结合体。将软件绑定到服务，可以确保它增值，因此这条原则非常适合SOA。但 是，区别仍然存在：在SOA里，你会在构建服务之前先检查服务是否已经存在（http://www.soaprinciples.com/service_reusability.asp ）， 即便重用服务可能要比重新构建它要花更长的时间。开发时间并不见得是最重要的因素，而只是一个快速进入市场的重要因素。在SOA中，你会对企业采用一种全 局的方法，而不是局部开发的视角。这意味着许可证费用、维护成本和可使用性（Reusability）都在考虑之列。因此，你有时可能会因为它没有给业务 带来任何价值而决定不构建任何东西。然后，你去配置目前已经有的东西。

尽管敏捷更关注于（单个）项目或产品，SOA则重点将服务和企业作为整体对待，但是这条敏捷原则和SOA原则是完全一致的。

欢迎需求变更，即便是在开发的后期。敏捷过程利用变更为用户创造竞争优势。

将SOA作为一种实现业务价值的方法，我们创造了一个由更小型、可跟踪的服务组成的世界，这让你可以根据市场和顾客需要不断地装配业务流程 （http://www.soaprinciples.com/service_composability.asp），重新调整和组合它们。由于代码没 有跟各流程发生紧密耦合（松耦合，http://www.soaprinciples.com /service_loose_coupling.asp），并且服务是自治的（http://www.soaprinciples.com /service_autonomy.asp），所以你可以轻易地重用服务。SOA的一个重要业务驱动力就是公司的机动性。通过解耦服务提供者和消费者， 让实现的变更更简单；使用标准，实现变得更容易改变；使用分离关注点，同样也让实现更方便修改。SOA讲的全是变更……正如敏捷之于开发。

本文的编辑想让我谈一谈‘泛化（Generalization）’，因为这两种方法似乎在该主题上有矛盾。光从字面上来谈，对于“何时进行泛化”这 一问题，SOA的回答会是“任何时候”。这当然没有任何意义。有时，问题对于某个部门或能力非常特殊，或者是它才刚刚出现。在两个情况下（当它非常特殊的 时候，或者是问题还没有被很好理解的时候），泛化解决方案根本没有意义。对于同一问题，敏捷开发的答案会是“从不”。这同样也没有意义。有时，问题在企业 中非常普遍。比方说要得到消费者的数据。假如你已经可以从一个开放、运行良好的应用里获得这些数据，那在每个需要消费者数据的应用里复制这些数据当然毫无 意义。集成现有应用，把重点放在手头的业务问题要简单得多。

那么，敏捷和SOA的极端都有不利之处。结合两者，将消除两种方法的风险。

附带说一句，SOA不只是关心重用和泛化；它还关心创建交付价值的小型单元（服务），而不是去创建难以改变的筒仓。这种方法同时简化了变更和重用。 这条设计原则非常类似敏捷经常用在软件开发中的设计原则（分离关注点，避免浪费等）。

总而言之，我们可以从两者学到很多：SOA的了解整体情况，敏捷的小步交付（大处着眼，小处着手；全面考虑，局部行动）。这把我们带到了另一个敏捷 原则。

频繁交付可工作的软件，时间周期从几周到几月不等，优先采用小时间段。

为了得到大量的动力和证明服务有效，你最好定期交付可工作的软件和褒奖，这有助于对人们产生激励和动力。这是通过迭代递增地工作来实现的。

得到由上而下的支持，依次识别有价值的业务流程，把它们转换成（非常值得一提）可重用的技术转化物和数据服务。从小处做起，一次实现一个服务和一条 流程来构建你的SOA。

在敏捷软件项目里，通常交付的是小（基本）的服务。Standish Group把这些称为踏石（stepping stones）。为了确保这些踏石确实在把你引向要去的方向，而不是原地打转，这就需要坚持相当严格的原则。服务的目标架构和方针可用于这个目的 （http://www.soaprinciples.com/standardized_service_contract.asp for example）。这意味着架构需要由产品负责人考虑，而且是产品Backlog的一个约束。由于SOA里的松耦合 （http://www.soaprinciples.com/service_loose_coupling.asp），技术可以在具体问题出现时才选 择，但是架构是针对全局的方针。通过一个一个地定期频繁地在你的敏捷项目里交付这些踏石，你可以逐步构建你的SOA。一个大型组织的面向服务架构不可能一 次就建成。举个著名的类比：吃掉大象的方法就是一次一口。再次提醒，要千里之行始于足下。

来自敏捷开发的一个好实践就是每次努力都会立刻给消费者带来价值。如果我们把它应用到SOA，我们只构建企业所需项目背景下的必要服务。识别服务既 可以采用自顶向下，也可以自底向上。但是它们总是在拥有端到端需求的项目环境下构建。这减轻了任何SOA项目的风险：构建大量从来不会被用到的服务。

敏捷和SOA的共同挑战是将迭代计划与编程管理和组合（Portfolio）管理集成起来。将发布调整为运营、业务用户和管理员所能管理的单元同样 也具有挑战性。这些环境往往需要根据交付的不同步骤和更小的功能块（服务）进行调整。

业务人员和开发人员平时在整个项目中必须一起工作。

这条原则暗示了软件开发过程。你可以声称这也同样适用于架构；业务人员和架构师平时必须在一起工作。信息和技术在很多行业里对战略的重要性越来越 大，如政府、金融服务、公共事业公司等。因此，业务和IT必须一起 组成公司的战略。项目只有在多学科的人一起 工作的前提下才能成功。服务只有在IT和业务中的人合作 的前提下才能实现。服务对业务很重要，必须要有业务价值；架构师、开发人员和测试人员必须理解这一点才能给企业交付这些宏伟的服务。这应该应用于任何项 目。一套公共词汇或共识 可以全方位帮助沟通。

因此，合作是敏捷开发和SOA都认同的。当然，一些重大区别还是存在。最大的区别在于，架构是一个过程，而非项目。当然，你可以启动项目部分地实现 架构，架构也是一个项目的重要组成。SOA在这一点上的附加价值就是，架构师和其他业务人员一道讨论和工作，而不仅限于项目干系人。这可以让他们发现产品 Backlog中特性里的潜在改进和不一致。

围绕被激励起来的个人构建项目。给他们提供需要的环境和支持，相信他们可以把工作做好。

敏捷明确地提到人的价值和他们的技术。只有清晰理解愿景、使命和符合公司目标的战略，以及被他们的领导同事鼓励和促进的被激励的人才能把工作做好。 但是，SOA并没有提到这点，毫无疑问，不同流程及领域的所有者只有被激励才会使用彼此的服务。为了协同和重用服务，你需要相信所做决策，依赖他人交付的 服务。在具体项目中，要重用不是由自己设计的服务，开发者需要相信同事的专长。服务契约本身或强制的重用永远无法替代激励或信任。这是生活中再明白不过的 道理。

在现实生活里，‘敏捷’和SOA都面临因不了解而带来的恐惧，怀疑敏捷和SOA原则对实现而言是否是正确的东西。因此，你必须教导和培训，然后让你 信任的人决定如何实现。

向开发团队以及其内部传递信息最有成效的方法是面对面交谈。

对于良好的沟通，这是必须的。开发团队内部，面对面交流的效果相当好。团队之间（不论是时间上还是地点上），你需要以不同的方式交流。重点是你只是 增加价值。为了可以重用服务，可发现性是一条重要原则（http://www.soaprinciples.com /service_discoverability.asp）。你记录他人重用你的产品和服务时必需的任何文档。不多，也不少。同样，这是关于产品 Backlog的另一术语。当然，这并不是你为了确保人们理解服务内涵必须做的全部事情。架构师应该把他们的时间大部分花在面对面沟通上。与业务交流，了 解战略和目标；与开发者交流，在快速交付和易于维护之间权衡、解释现有服务的含义和用例等等。高度面向技术的SOA人员的缺点是他们认为SLA和注册库可 以代替人类交流。然而SOA不仅讨论成功的条件，就像其他成就一样，它还依赖面对面的交谈。

可工作的软件是首要的进度度量指标。

在项目里，为了实现服务或SOA，最终目标是构建给业务带来价值的业务流程。这可以由一段软件代码来实现，也可以由人工服务来完成。在SOA里，你 不用构建任何东西就可以取得进展，而只需改变某些人工活动就行了。这种进度指标是业务指标：就像销售量、利润率或成本消减。

因而，这就是一个范围问题：敏捷开发讲究的是软件开发。要是你构建软件，可工作的软件应该是首要的进度度量指标。SOA讲的是企业架构，因此，进度 是由整体所取得的业务目标来度量的。

敏捷过程提倡可持续的开发。发起人、开发人员和用户应该能够持续维持一个恒定的步调。

这条原则讲的是让工作者的生活变好还是变坏。快乐的工作者，不论他们是架构师还是开发者，只要他们不必在压力之下工作，不必工作很晚，不必同时参与 多个项目，或是工作时间超过影响其健康的限度，要成功得多，工作得更聪明，而且交付的工作质量更好。这条原则应该在任何项目中提倡。这非常合理，不于 SOA发生冲突。

持续关注提高敏捷的技术优势和优秀设计。

敏捷团队要让技术满足业务的预期并使之工作：普遍存在和可靠。SOA需要高级别的技术优势和设计，因为它要求松耦合、可使用性和抽象。这些原则要求 额外的关注和学习。敏捷开发者不仅需要设计他们的类和方法，他们还必须通过帮助架构师和业务设计整个系统，亲自参与到整个系统的设计之中。这给敏捷设计会 话设置了一个强制性目标：眼光要超越单个项目的范围。

某些开发者告诉我，高等级的标准化（在这里指的是架构）可以被认为是一个不必要的约束，它吞噬了他们的生产力。这里再做一个类比：如果你需要一个包 裹尽快地快递，没有限速可能会更好。对于各快递公司而言，无视所有规则似乎可以更快。但对于订购该包裹的顾客来说，生命要比单纯地快递一个包裹要重要得 多。他也期望你的孩子能安全的步行到学校。因此，尽管包裹快递公司可以达到技术优势和好的设计，他们还要把环境作为整体因素来考虑。这便是SOA可以发挥 作用的地方。由于小单元的概念，只有少数方针才需要每个项目去遵守。当然，这些方针需要随时被评估和改进。标准本身的作用应该是促进，而不是限制。将这跟 瑞典做个比较，当地人觉得在路右侧驾驶要更方便些，就像欧洲的其余国家一样。当这是一件正确的事的时候，他们改变了规则。

对SOA和敏捷两者来讲，一致且有序地应用和采用实践和原则都非常重要。

简化（最大化不完成工作量的艺术）是必须的。

SOA把服务定义为主要的可交付件。这是一种简化的实现，拥有符合某些原则（松耦合、自治、可组合性等）的小型构造单元。这种方法也帮助定义了实际 需要软件的时间和类型。当你只构建对已识别但尚未实现的服务进行支持的软件的时候，你才能最大化不完成工作量。我们有句话：“Je gaat niet iets bouwen als je het ook op de achterkant van een sigarendoosje kunt bijhouden”. 它字面上的意思是：“如果某件事你通过把它记在烟盒背面就能跟踪，那么你就不会打算去构建它（软件）”。我们同样可以把它应用到我们的SOA实践之中。

最好的架构、需求和设计产生自自组织团队。

这条原则既适用于敏捷软件开发，同样也适用于SOA。事实上，SOA本身并没有规定它应该如何实现。你可以通过自组织团队来完成这件事，也可以通过 规定采用由CIO颁布的架构来完成。

实现SOA，如同其它成就一样，需要来自多学科且在各自领域拥有丰富经验的人。如果他们喜欢彼此合作，这样的人不需要去驾驭。协调业务人员、架构 师、流程建模人员、测试人员和服务开发者是必需的，而且综合学科的团队也需要成立。这里的重点在于，架构是必需的，因为解决方案（服务）必须符合整体蓝 图。架构必须是自组织团队的一部分。这必须以某种方式组织起来，团队和团队之间所采用的方法各不相同。单单的敏捷实践和自组织无法解决这些架构挑战。

例如，解决方案架构可以经由应用敏捷方法，通过重构、小步增量设计，以及主要以代码形式表达。接着架构就浮现出来了。这是由下而上的架构部分，它与 自顶向下的部分在中间层会师。

团队定期就如何变得更敏捷进行反思，然后相应地调整其行为。

由于SOA并没有论及任何关于实现它的方式，仅仅讨论了我们需要的原则和构造单元，这条原则可以轻易地被应用到架构工作中。

通常来说，为了设计和构建可重用有价值的服务，你必须持续测试和评估你的劳动成果、度量质量、不断学习和重构。某些高级但是确定的质量标准必须就 位。SOA让团队有具体的产品（服务）去讨论，以及一组原则去度量其质量。集中对构建服务的回顾可以包括类似的问题：

• 我们如何改进可使用性？
• 我们如何让我们的服务在干系人（消费者）眼中更有价值？
• 系统的哪部分可以让我们用现有服务代替？我们怎样才能更快更好地交付下个服务？
• 我们可以进行泛化吗？

每天站立会议，持续集成和迭代演示不仅可以帮助软件开发，也可以有助于架构的检查和改进。

总而言之，敏捷如同手套中活动的手指。SOA则是这个手套，范围便是整个企业，敏捷开发关心的是那些由软件支持的部分的开发方法。SOA和敏捷的大 多数原则并不矛盾。当它们同时出现的时候，它们会相互促进。敏捷开发若是缺乏清晰的目标愿景和公司目标就会徒劳无获。SOA要是不知道如何利用敏捷原则使 目标成为现实，将会浪费时间和金钱。

SOA和敏捷都关心机动性。（这适用于大量不冲突的原则）SOA关心的是架构结构，敏捷开发关心的是快速交付。这种方法让它们彼此保存平衡。两者缺 一不可。

John Goodsen 认为不能编码的Scrum Master很少能与团队丝丝入扣，他说：“好的教练应该能玩好他们指导的游戏。你知道有几个优秀的体育教练在从业之前没有亲身参加过比赛？”。在 John看来，好Scrum Master需要知道如何在代码级别进行指导，他们因而也就需要有构建软件的经验。

Alan Dayley 认为Scrum Master是团队的教练，而不是某一个团队成员。他们的目标是帮助球队变得更好，在某些情况下这需要技术方面的知识。在其他情况下，深厚的技术知识则可 能是一个不利因素，因为团队会迷失在细节中，错过团队的其他需要。

Mark Woyna 指出团队负有提高自身技术实践的责任，而Scrum Master的角色是帮助团队遵循开发的过程。

Adam Sroka 对Scrum Master这个角色总体持怀疑态度。如果他们在排除组织障碍方面富于效率，他们值得重量等身的黄金奖赏，但他看到许多Scrum Master并不能做到。最后，Adam归纳在两种情形下，Scrum Master无法带来好处：

1. 在表现杰出的自组织团队中，Scrum Master无法添加更多价值。在这种情形下，他希望团队意识到他们不再需要Scrum Master。
2. 团队面对的障碍超出了Scrum Master能够消除的能力。在这种情形下，他认为Scrum Master需要指导团队，指导他们寻求帮助、培训或支持。

他接着说：

如果团队存有Scrum Master可以消除的障碍，Scrum Master不一定必须精通技术才能对团队有价值。对于新近实施敏捷的团队，他们有必要拥有技术方面的顾问，因为技术方面的改进需要以更小步伐、更快增量 的方式进行。

技术教练是任何敏捷实践得以成功实施的重要原因，但其他不同类型的专家也非常有用，精明的Scrum Master在识别指导团队付出以最大化产出成果的机会方面可能非常有用。Scrum Master不需要对如何达成这一点的特定方面知道太多，虽然这对于有效的领导者（注意，我并没有说“经理”）至关重要。

Hariprakash Agrawa 认为：Scrum Master技术能力的重要性与团队在敏捷实施上走得多远更为相关。团队越新，他们遇到的障碍更可能属于技术方面的问题，在这种情况下，他更倾向于技术方 面的Scrum Master。而即便在这种情况下，他也依旧认为人际交往能力比技术知识更重要。他认为错误的人即使有技术，也能创造很多损害。

English： Do ScrumMasters need to be Technical?

¨        Automated Testing Improvement

With the growing of network equipment, the port density and intelligentized degree are already enhanced so much. In this case, the test point is already transferred from the physical link layer to the network layer even to the higher protocol; and the test object has also turned from error rate to multilayer transport and routing test.

In this case, OPD China introduced automated testing since 2009 and applied it to the projects of all PUs step by step. We dedicate to:

î      Enhance test automation competency,

î      Increase the automation coverage

î      Save effort on tests execution

î      Improve product quality

î      Shorten the time-to-market

A clear work mode was established for experience sharing and improvement opportunities identification. In the mean time, the agile development mode was also to be piloted at automation development. Till now, the test efficiency and automation coverage have been significantly improved owing to all automation members’ hard working.

测试是改善持续集成的关键环节，因为应用程序的构建时间大部分都是用来执行测试的。结构混乱的测试栈会导致构建陷入困境，而开发团队就不得不扔掉先 前已经 达成共识的持续集成实践，来换取用于编码的时间。这种所谓的捷径就又会使得“红色（表示失败）”构建频繁，进一步演化成为“门窗全毁 ”的场 景，从而导致“红色”构建比正常构建的频率要高的多，以至于无法判断代码质量。而出现严重的产品问题的风险也会随之提高，最后开发人员就不得不进行长期的 预发布测试，延长了部署时间。
在本章中，作者描述了以下种种主题及其之间的关系：

• 自动化单元测试
  将单元测试自动化，特别是可以使用NUnit或JUnit这样的单元测试框架。单元测试不应该依赖于文件系统或者是数据库这样的外界条件。
• 自动化组件测试
  使用JUnit，NUnit这样的单元测试框架来将组件测试自动化，如果你在使用数据库的话，还可以使用DbUnit或是NDbUnit。这些测试会包括 更多的对象，也通常要比单元测试花费更多的时间。
• 自动化系统测试
  系统测试比组件测试要花更长的时间运行，通常会有多个组件参与其 中。
• 自动化功能测试
  我们可以通过Selenium（用于Web应用程序）和 Abbot（用于GUI应用程序）来完成自动化功能测试。功能测试是从用户的角度来执行的，基本上算是自动化测试栈中所需时间最长的测试。
• 将开发者的测试进行分类
  把测试按照种类划分开来，就可以让速度慢的测试（比如组件 测试）和速度快的测试（比如单元测试）按照不同的时间间隔来运行。
• 首先运行较快的测试
  单元测试要先于组件、系统和功能测试运行，通过按种类划分测试 就可以做到这一点。
• 为缺陷编写测试
  基于新的缺陷来编写测试，保证该缺陷不会再一次为团队带来痛苦，测 试代码的覆盖率也会相应提高。
• 让组件测试可重复执行
  使用数据库测试框架来保证测试数据一直处于“已知的状态 下”，这可以帮助组件测试做到可重复执行。

本章以一系列的问题作为收尾，开发团队可以用这些问题来评估自己的CI测试过程：

你是否把自动化测试进行了分类，例如单元测试，组件测试，系统测试和功能测试？你是否对CI系统做过配置，以使它可以在不同的构建阶段来运行不同种类的测试？

你是否在为每一个缺陷编写自动化单元测试？

你的测试用例中有多少断言？你是否限制每一个测试只有一个断言？

你的测试是可以自动化运行的么？你的项目是否会把提交过的自动化测试代码放到版本控制仓库中？

在这一章里，作者还以各种测试框架中的例子进行了翔实说明，这些测试框架包括 TestNG，Ruby，DbUnit，StrutsTest，Selenium和JUnit等。

摘录：“第 六章：持续测试” ，同时您还可以在O’Reilly Safari上看到完整的目录 ， 从而对全书所讲述的其他主题有大致的了解。

See English at： Book Excerpt: Continuous Integration means Continuous Testing

创造一个健康的团体

Chris Corrigan 认为自己是一个“过程艺术家、教师、面对面交流社会技术的推动者”。最近他在博客中谈到了Meg Wheatley 的保证团体健康发展的12个原则：

1. 大家拥护所要共同创造的东西
2. 当人们在乎结果的时候，会变得更加负责
3. 交谈能够帮助人们达成思想一致，在交谈中人们会发现共同的思想
4. 通过改变交流的对象来改变交流的内容
5. 期待领导从任何地方出现
6. 关注可行性，探求可能性，而不是过度关注问题
7. 群体智慧
8. 任何事情在没有结束之前都不能算作成功，在整个过程中都可能发生变化
9. 学习是让我们变得更加聪明的唯一方法
10. 有意义的工作有很大的激励作用
11. 作为一个团队，人们能够承担一切任务
12. 社区里面最重要的因素包括：宽宏大量、宽容和爱。

凝聚力造就团体

Johanna Zweig & César Idrovo写了一系列文章，分析了团体凝聚力以及具有凝聚力的团体如何取得超 高生产率

他们发现有凝聚力的团体所共同具有的五个特征：

• 个体的创造性与团体创造性的关系：个体的创造性服务于团体创造性。 在有凝聚力的团体中，每个成员的创造性都能得到充分自由地发挥。这些创造性在自主管理的团队中会得到充分利用。敏捷方法提倡让开发人员与业务人员、系统架 构师以及技术专家一起密切合作开发功能，从而从过程上保证每个人都能在这个自管理的团队中充分发挥创造性。
• 状态转变：活力水平的转变（就像水变成蒸汽或者水变成冰）。 伴随着状态转变，人们会发现在敏捷团队中，根本无需管理层指示、视觉以及听觉的提示，个体之间能够互相取长补短，彼此默契以及信任度也会获得提升。
• 结合状态：当团队具有凝聚力时，团队中的每个人都将紧密联系在一起。 每个个体并不会因为在团队中自由地表达思想而受到伤害，这大大提高了团队的自主能力，从而迅速找到解决方案。而社会活动成为工作中协作的延伸。
• 神游：团队成员之间频繁交互和交流会大大提升团队的活力。 在团队讨论中团队成员之间的交流得到加强；成员之间相互协作。
• 感受团体凝聚力。 信任团队领导力；感受工作的激情；乐于共同面对挑战。

有意义的目标能够激励团队

同样的，Steve Denning 指出了设定有意义的宏 伟目标的重要性，以及这些目标怎样能够对个体和团队产生激励，从而使得工作更加有效。他认为：

• 工作的意义并不在于我们正在烤的面包，而在于看到我们的客户享用面包
• 工作的意义并不在于演员的朗诵，而在于听众对这些的反应
• 工作的意义并不在于我们组装在一起的玩具，而在于儿童脸上的微笑
• 工作的意义并不在于我们建造房屋的砖块和砂浆，而在于因为切实满足了住户的需要而产生的喜悦之情
• 工作的意义并不在于我们所写歌曲的音符，而在于感受到了听众心目中的憧憬。
• 工作的意义并不在于我们发布的保险政策，而在于我们为父母及他们的孩子提供的保障
• 精品酒店的意义并不在于他的房间和各种设施，而在于那种给客人带来的宾至如归的感觉
• 我们开发的软件的意义并不在于那些比特和字节，而在于用户可以利用我们的软件做很酷的事情
• 我们工作的意义在于我们目标客户的反应

设定目标，使之能够清楚地表明它能给目标客户带来的价值。

English version： Agile Teams as Cohesive Communities

学习型游戏着重使用游戏和练习去传授和演示概念。参与者模拟一系列极限编程的游戏，通过识别和降低瓶颈学习约束理论。这些练习适合希望学习更多敏捷 概念的人，同样也适合寻找工具的敏捷实践者。

提高型游戏更为开放，注重团队及个人的回顾、反思和改变。大家一起找出适合自己的过程，提高他们的生产力，反思遇到困难的情况，甚至实践一些即兴方 法。这些练习适合敏捷实践者，帮助他们的敏捷实践进入更高的层次。

工作型游戏不仅可以用于学习和反思，还可用于团队的日常工作。许多敏捷团队早已熟知诸如计划扑克之类的方法。参与者一起探索了其他游戏和练习，排列 软件功能的优先级、精炼产品愿景、计划发布等，以期把团队的工作做好。这些练习可以帮助敏捷团队及个人，使用更加协作的方法去互动和执行。

Tobias Mayer主导了一个非常有趣的游戏——敏 捷操场（Agile Playground） ，这个游戏有助于建立团队和协作。它可以帮助我们了解我们的行为会对团队有什么样的影响。这个游戏有 3轮，以不同的方式去模拟与他人的交互。可以很方便地让大家进行换位思考，并关注团队表现。

黄砖路：通过同侪教练^[1] 产 生新鲜的见解 由Portia Tung发明，在此次会议期间，他分享了这个游戏。该游戏通过实践同侪教练，教授大家成为有效教练的必要技能和资源。游戏中，大家轮流扮演3种角色：客户 （持有问题）、教练以及观察者。客户提出自己在工作中遇到的问题。教练练习聆听问题并提出自己的问题，他们发现，聆听也需要练习实践，因为我们习惯于跳进专 家意见 和解决方案 的怪圈；同时，我们也需要练习提出不同类型的问题，比如开放型问题、控制型问题和确认型问题。观察者则提供真知灼 见，通过亲眼目睹和旁听，他们可以掌握实际情况，观察实际上是一种非常有用的调试技术。

Michael McCollough和Don McGreal主持了一个关于如何自己创建游戏的工作坊。他们一直在创造简单、有趣的游戏，TastyCupcakes 上 有许多非常好的游戏。他们开发游戏有一个特别的风格——简单。这与极限编程游戏 和业务价值游戏 等复杂游戏 不同。简单游戏都始于某个问题，你发现了什么问题？你如何让你的团队更好的理解问题？然后是目标。选择1到3个你想让游戏参与者学习的东西。接着，当我们 在脑海里搜刮主意的时候，要做螺旋式的思考，这里有一些约束原则，那就是挖掘点子时要始终遵循目标 ，并保持简单 。从卡片、气 球以及其他行业的游戏中可以得到灵感。Michael和Don的口头禅是“乞讨、借用、窃取”，取其精华，演变为自己的东西。从我们的参与者那里学习—— 只要聆听，他们会道出很多有价值的观点和信息。最后，我们应该拿出勇气去尝试，尽早开始并进行迭代。记住，核心是听取。给参与者空间，让他们去发现。

会议期间还有很多其他有趣的游戏 ，大家可以挑选合适的尝试一 下，在轻松的游戏氛围中总会有所收获。同时也可以根据实际需要试着创造自己的敏捷游戏。

^[1] 同侪教练（Peer Coach）是一种教师工作在一起，形成伙伴关系，通过共同阅读和讨论、示范教学，特别是有系统的旁听与反馈等方式，来彼此学习新的教学模式或者检讨修正 已有的教学技巧与策略。