朱雀雀的巴士站

嘿嘿，不好意思，又拿以前做得事情来充数了，我最近一定好好的总结总结自己，写写自己的心得，我发誓

  InfoQ 上的书评链接在这里 http://www.infoq.com/cn/news/2008/10/agile-adoption-patterns-br

个人认为，除了翻译中所说的那么多适用情况，其实这它还非常适合拿去给别的企业做敏捷指导的时候使用，倒是本从传统软件开发向敏捷过度的好书

摘要

Ryan Cooper对Amr Elssamadisy的新书发表了评价，并认为书中提供了一种为实施敏捷量身定做的框架。本书并没有给出一种人人可用的敏捷方法，而是为读者提供一些模式和工具，用以找出哪些敏捷实践可以最有效地达到该组织机构的特定目标。

正文

在AmrElssamadisy最近的一本书《敏捷模式──指向成功的路标》 中，他使用了一种概念框架，用这个框架把具体应用环境和敏捷策略一一对应。他没有建议人人都使用一系列相同的实践方法，而是针对公司所想达到的目标，帮助 你找出哪些实践方法是最适合的。这些实践方法不但会引领你走上敏捷的道路，而且会将迁移过程的花费，以及所出现的失望情绪降至最低。

成功实施敏捷开发方法，对于一个企业而言，将会获益匪浅。敏捷过程提供更为精确的项目评估；在项目正在进行的同时也能给予更好的控制（提供更有用的功能， 而不只是需求文档上所要求的）；产生更高质量和更易于维护的软件产品；以及提高开发团队的士气和信心以及彼此之间的信任。不幸的是，正如我们许多人在敏捷 开发者社区里所了解到的，从传统的软件开发过程迁移到敏捷软件开发过程非常困难。针对具体的企业环境，找到合适的敏捷方法并进行实践，是一件很让人头疼的 任务。因此，许多企业在转换过程中经历了很多困惑和失望，而且许多企业在发现敏捷开发方法的益处之前，就放弃尝试了。

Elssamadisy在书中提供了一些行之有效的方法，可以帮助你避开在实施敏捷中的种种陷阱。举例来说，尝试“大跃进”式的迁移是很常见的错 误，而作者为你提供了一种逐步进行、迭代采纳敏捷开发方法的计划。他鼓励使用敏捷的方式来实施敏捷：在（希望是）正确的方向上小步前进，利用短期回馈来收 集信息，用于调整方案和确定下一步的计划。同时，作者会帮你达到投资回报率最大化，他提供的技巧可以找出对组织最重要的商业价值，并且告诉你如何选择一开 始采取的实践组合，以强化这些价值。

如果你对敏捷有所了解，而且希望知道如何在真正的项目中卓有成效地实施敏捷，这本书就是你的不二之选。如果你非常愿意帮助采用传统软件开发方法的企业转而实施敏捷开发，那么这本书非常适合放在你的书架上。

上下文驱动的实施方式

该书的前两部分（第一部分：关于软件开发的想法；第二部分：实施敏捷的艺术）是全书的核心。

第一部分介绍了两个可供敏捷指导者采纳的指导原则：

• 原则1：学习是瓶颈。
  对于给定的流程和任务，如果不知道如何实施，要找到可以加快学习速度的途径。Elssamadisy主张使用敏捷实践者普遍采用的一种方法─周期性得信息回馈 ：
  

  1）设立目标 2）采取有助于达成目标的行动 3）将行动结果与目标进行比较 4）调整行动并回到步骤2
  学习的过程发生在步骤3，并在步骤4中得以应用。

  Elssamadisy同时强调了沟通对于强化学习效果的重要性，个体之间的信息传播，可有效地使他们融入软件开发过程。

• 原则2：个体敏捷性
  Elssamadisy借用了Chris Avery的“责任过程模型”， 以帮助读者在组织变化的过程中，保留富有成效的想法。该部分提出的建议包括：如何避免常见的陷阱，包括盲目指责、妄下结论、自怨自艾、羞愧难当，以及自感 无助而没有主控权的状况。为了产生（并且保持住）责任感，必须创建“思想上为自己负责的状态。用行动解决我们不喜欢的东西。这就是达到个体敏捷性的起点。 ”

该书的第二部分是我最喜欢的。它阐述敏捷实践的方式，是我不曾在其他书中看到的。它明确描绘了各种各样的“业务价值”（就是诸如“缩减生产时间”和“提高 质量”这样的目标），这些价值及其目标可以利用敏捷方法达成。如此描述方式，可以帮助读者在采纳敏捷时，照顾到组织的客观环境：首先，确定对于组织最重要 的业务价值；然后，根据上述的目标来应用敏捷实践，从而提升业务价值。

Elssamadisy同样描述了一些经常碰到的“坏味道”，利用敏捷方法可以有效的去除它们。（一般来说，坏味道比业务价值更易于发现。因此，从企业目前的坏味道开始，确定采用哪种敏捷实践，通常是一种相对简单的途径。）

进一步地，Elssamadisy解释了各种敏捷方法的联系。很多时候，如果不首先实施某种敏捷方法，那么很多基于它的敏捷方法就很难实施下去。针对特定的商业价值和坏味道，Elassamadisy提出了一个草图，用于排序和分组对应的敏捷实践。

这种以上下文驱动来实施敏捷的方式，是敏捷出版物中早就应该出现的，我非常高兴地看到它成为本书的核心。由于体验过许多艰难的过渡经历，我可以断言：以基于上下文的、迭代的方式实施敏捷会大行其道，尤其适合于大型组织机构。

敏捷模式

敏捷模式的章节几乎包含了敏捷领域中所有的模式。它们被分成五个群组：

• 目标和周期：
  两个基本的模式构成了许多敏捷实践的基础。
• 信息反馈实践：
  迭代、启动会议、待办事项列表、规划扑克、站立会议、完成状态、演示、回顾、时常发布、“联合驻扎”团队、自组织团队、跨职能团队、客户作为团队成员、唤醒式文档、用户故事、用例、和信息辐射器。
• 技术实践：
  自动化测试、测试后行开发、测试先行开发、重构、持续集成、简单设计、功能测试、代码集体所有制、结对编程。
• 辅助实践：
  指导、加入社区、阅读周期、研讨会、教室式培训。
• 模式集群：
  迭代集群、沟通集群、演化的设计、测试驱动开发、测试驱动需求。

辅助实践也包含于其中，是非常令人高兴的。从本质上来讲，它们不是敏捷实践，而是帮助学习新知识的方法。但是，如果忽视了这些实践，将会使学习举步维艰。

每个模式都包含一些有用的工具,有助于判断这个模式的实践是否适合于你的敏捷实施计划。这些工具包括：对当前模式所提升的业务价值的解释，特定模式 适用环境的介绍，和对于某些模式试图解决的阻力的深入说明。仔细阅读每个模式的上述内容，读者可以确定在自己所处的环境中，实施特定的模式会有多少价值。

拿“演示”模式为例，列举一些帮助你判定该模式是否“合身”的内容：

 

•  
  • 将需求和设计用文档记录是可以的，但是不足以提供信心，让组织相信应用可以满足他们的需要。
  • 通过增强项目透明度，并且提供定期演示的流程，可以增强信心。
  • 可工作的软件会给投资者树立信心，让他们看到不断推进的、卓有成效的工作成果。
  • “我们完成了需求和设计的编写和复查，这就表示完成了30%的工作量”，类似的片面完成度统计是错误的。开发者们一向过于乐观。
  • 完成可工作的软件所付出的努力，还包括在软件开发的后续阶段减少许多瑕疵。
  • 越早发现缺陷，修复付出的代价越小。
  • 查找和修复缺陷是一个学习的过程，而学习是软件开发过程的瓶颈。
  • 一些早先设想的解决方案并不总是我们真正需要的。有时候虽然软件开发完成并通过测试，而且是完全按照需求完成的，但不能解决真正的问题。
业务价值：
“演示”增加了项目对于干系人的透明度，让客户评估具体的系统，这也增加了产品的实用性，同时对迭代也是支持。迭代可以直接提升业务价值，而演示在这方面起到了二次影响。

上下文：
你处在一个开发团队中，此团队施行迭代开发，投资者在开发团队之外，但对项目的进度感兴趣。

阻力：

接下来，关于模式的章节介绍了如何帮助你有效实施敏捷方法，同时避免很多实践者曾落入的陷阱：

因此：
当前模式的描述。该模式如何解决已知上下文环境下的种种阻力。

采纳方法：
步骤，顺序，一些实施当前模式的建议。

但是：
采用当前模式可能产生的消极结果。

变种：
该模式的变种，不同于“因此”部分的描述，同样能成功实施。

引用：
深入阅读资料。

这些部分用精炼的语句总结了许多敏捷社区诞生的智慧，并且与实际问题丝丝相扣。如果你正在进行某种实践的尝试，但是并未体会到它提供的任何价值，那么这些部分可以帮助你进行调整，以从实践中获得更多的价值。

我非常喜欢“但是”部分。很多常见的敏捷实践都非常容易出错，而且经常很难找到有关这些错误的描述。阅读这一部分的内容，新的敏捷实践团队就可以设置切合 实际的目标（不是一切都能顺利推进，实施敏捷实践时有很多歧途），这部分内容还能给新的团队以警示，确保他们不走弯路。大多数情况下，“但是”部分会包含 很多建议，告诉你要是走错了路该如何扭转局势。由于许多敏捷实践都曾在这些情况下出了问题，能看到相关内容实在是读者的一大福音。

实例研究

该书的第三部分，研究了两个应用敏捷实践的真实案例。有关敏捷的出版物中，常会描述一种“完全敏捷”的团队，这样的团队与缓慢向敏捷迁移的团队大相径庭。很多倡导敏捷的人都是通过看书学习的，可他们却很难像书中描述的一样马上达到收效，也因此而遭受打击。

敏捷在真正实施时，并不是一帆风顺的，能够读这些真实的情况使人耳目一新。现实世界中，尤其在大的企业，改变个人和组织的习惯是一个长久、艰难的过 程。事情不会一帆风顺，但是只要假以时日，那些持之以恒的个人和团队总会获益匪浅。这两个敏捷案例清晰刻画了目前的现实情况。帮助组织机构向敏捷迈进的过 程是漫长而又艰难的。相信别人也曾遇到类似的问题，这会让你摆脱疑虑，从而看到自己正在取得卓有成效的改进。

结论

这本书并不适用于所有人。我不会将它推荐给完全不了解敏捷的人。Elssamadisy认为，本书适合对常用的敏捷实践和原则有所了解的读者。所以 初学者可能会发现这本书在某些方面缺乏细节描述。我同样不会给资深的敏捷教练推荐这本书；他们很可能对本书的绝大部分内容烂熟于心了。

不过，如果你已经阅读了大量的书籍，并且对敏捷软件开发充满好奇，却不知道从哪里着手，那么这本书对你再合适不过了。如果你对敏捷实践有一些基本的 了解，但对于自己能否成为团队中的敏捷专家没有信心，这本书同样适用于你。如果你身在一个敏捷团队中，已经实施的敏捷实践对你来说似乎没有产生预期的好 处，你也可以好好读一读这本书。

注意：这本书同样可以通过Safari在线书店获得。

关于作者

Ryan Cooper是一位敏捷软件开发者和教练。他是Ryan Cooper咨询公司的创立者。在他的家乡Halifax，他还是敏捷用户小组的创建人之一。他的博客可以通过www.onagile.com访问。

 

接触敏捷相关的知识也快有两个年头了，但是真正体会到敏捷开发或者说真正的软件开发流程，是最近的这四个月。这四个月（精确点来说还不到四个月）是我人生的第一份工作（以前在学校勤工助学和在外面作项目不算的吧），在ThoughtWorks 度过的这几个月让我真真正正体会到软件开发的正确流程，远远不是书本所能够教给我的

记得当初在实验室，由于老师的信赖，手里同时管着几个项目，平时又喜欢拿书本上才看到的软件技术和开发方法做试验，因此在实验室是应用过敏捷的。可是效果那就真得不敢说了，第一次毫无经验的去尝试敏捷，的确吸取了不少经验教训，经过这几个月的锤炼，逐渐发现自己曾经错在哪里了。趁这篇Blog 好好总结一下经验

 先说一下现在从事的项目情况：Mingle 项目是ThoughtWorks Studio 的第一个产品，历时已经超过两年了，获得广泛的好评，是很注重用户的体验和实用性的一个软件。不是我夸张，这绝对是我做得最令自己自豪的软件产品了，产品的质量控制和用户体验可以说是发挥到了极致！当然对一个新人来说，一个做了两年多的软件产品，几十万行的代码量的确是有挑战性的。Mingle 的团队是典型的分布式团队，一个团队在美国San Francisco，一个团队在北京，7 个Developer，3个Quality Analysts，2个Business Analysts 1个Project Manager 共13 个人组成。人员构成 Senior Devs 4个，Junior Dev 就我一个（汗呀），Senior BA 2 个，Senior QA 1个，Junior QA 2个，其余的都是Middle Level 的。这就引出了我的下一个敏捷重要的特点，团对人员组成，和工作方式──人的因素很重要

  Mingle 团队在我看来是一个健康的敏捷团队，在上述的分析中，可见Senior人员占绝大多数，这就使得放进去少数的几个新人，在同一时间内既可以保证项目的进度，同时也可以让新人得到很多的帮助，从而让新人非常快的成长，从而尽快的对项目作出贡献。其实这也是我这两年多接触敏捷软件开发以来一直坚信的一个原则，就是敏捷软件开发对人的素质要求非长高。一个从未有敏捷软件开发经验的团队，如果自身团队构成又是新手居多，是绝对不可能获得成功的。我想这就是为什么，有的软件公司应用敏捷软件开发喜忧参半的最终原因。这里不得不提到一个敏捷的最佳实践原则，Pair Programming，我在Mingle 团队的这两个月（其实还不到）每天都会写代码，但是不是我单独写，身边总会有一个Senior Dev 跟我一起Pair，他们不但会给我介绍一些技术上的最佳开发实践，同时也会给我介绍敏捷开发的一些思想，还会给我介绍项目本身的代码结构，同时我们还能完成项目的正常进度，真的是一举四得。跟这些Senior Pair 的同时，我不仅学到了技术相关的知识，更学到了他们的工作方式，最重要的还学到了他们遇到问题和解决问题的思考方式。这些Senior Devs 总会启发我，假如我遇到这样的问题，我自己会怎么做，然后再告诉我他们是怎么做得。这样的后果就是，导致我每天都很累（大脑高负荷运转，哈哈），当然每天也都很有趣。其实，这还只是开发者的部分，仔细想想，团队中Senior BA 和QA 给Devs 的支持是非常有效果得，例如我们在做一个Story 的时候，我们小组的Senior BA 给我们分的任务就很清晰，考虑很周到，系统什么最重要，要多长时间来完成，具体的细节要注意哪些，都非常清晰，这就使得我们总是知道下一步要做什么，而Senior QA 总能即时的发现Bug，从而减少了代码发臭变腐的周期，使得代码和软件总是处于一种比较健康的状态。仔细思考一下，在学校作项目的时候，我和师弟师妹们Pair 的时候，有的时候总是不知道如何下手，一方面这真的跟经验有关，另一方面，由于团队的构成基本上任何人都是BA、QA同时又是Dev，所以划分Story的能力实在是不敢说，总是处于，一种不知道什么重要，不知道下一步该怎么办的状态，大部分有价值的时间都被困惑过去了。果然呀，21世纪啥最重要？人才！同样适用于敏捷团队的构成

对开发流程使用正确的控制手段也非常的重要。以前在学校开发的时候，一个团队坐在一起，先划分用户素材，我们使用Mind Map 作为记录头脑风暴结果的工具，但是记录后的结果就是放在那里，照模照样的开发了，忘记了这些素材是有状态的，它们是可以在不同的状态之间进行迁移的，我们也需要对这些状态进行控制。加入ThoughtWorks 之后，发现大家都使用卡片作为载体，卡片通常分为New, In Analysis, In Dev, In QA, Ready for sign off 等一些状态，这就是把一个庞然大物的软件，分成许许多多细小的部分，而每一个部分都是可以展示，都是可以运作的。非常的合理也非常的巧妙，而这些卡片在迁移的同时，也表示了你这个团队当前的状态，及时的反映了团队健康与否。在开发流程的控制中，还有一点给我印象非常深刻，就是持续集成。在学校的时候，SVN就意味着持续集成，现在才逐渐明白了什么才是真的持续集成。最简单的持续集成是什么？是你每次将你的测试通过后，提交的那些代码，这个流程通常是这样的（以RoR开发为例），我们从Story 中找到一小块功能，像播洋葱一样，从外到里，先写一个Controller 测试，描述或暴露出需要完成的问题，这就导致了Model 层会引起一系列的变化，这时候我们添加Model 测试来继续细化这个问题，好了，到此测试部分完成，但是都没通过，剩下的任务就是写代码来通过测试了。当所有测试通过了，你可能修改了以前的代码，怎么能保证软件仍旧处于可用的状态呢？你需要从SVN（或者别的版本控制工具）下载当前最新的代码（注意，服务器上的一定是能工作的），然后在你本地跑测试，确保原本的功能，和你新增的功能都正确无误，那么可以将你的系统同步到服务器上了。这是最基本的持续集成，其实还包括对数据库的持续集成等等。持续集成的下一个环节，是使用Cruise来进一步运行测试。这时候就有疑问了，我们本地测试都通过了呀？为什么在服务起上还要运行一次？正确答案是，你的开发环境并不代表使用环境，我们开发环境都是Mac 的开发环境，可是用户很可能使用Windows；我们使用的浏览器是Firefox，但是偏偏那么不好用的IE 占据市场绝大多数的份额，还有人喜欢使用Safari；如果你的软件又要支持多种数据库，那么就有更多的运行环境了（这就2*2*2=8 了不算Safari）。所以，我们怎么能让21世纪最重要的人才来手动处理这些事情呢？当然使用自动Build 的软件啦！这就是持续集成很重要的第二个环节，其实在Cruise 上还会运行你本地所无法跑得Acceptance 测试，比如说Selenium 的测试，这些是利用行为方式来进行测试的，很费时间，却代表了用户最终的使用价值，因此重要而必须，我们完全可以让服务器来帮我处理这件费时费力的事情。持续集成的第三个环节其实就是短期的Showcase 和Swich Pair 保证团队每个成员的知识体系也是持续集成的──代码共有和对系统的整体认知。

健康敏捷团队的最后一点──回馈信息。无论是在TWU 的日子，还是回国后的工作，回馈信息绝对是敏捷开发团队健康发展最重要的因素之一。软件开发是高脑力劳动，也是当前世界上聪明人最多的一个行业，大家对一个软件开发的流程和技术，都有很多思考，也有很多的价值，及时地团队交流和信息回馈，就会创造一个大家乐于工作，乐于开发的环境，人开心了，代码质量自然就上去了，是不是？

看吧，这篇Blog 就不是一个持续集成的好例子，长时间不总结自己，结果要说得东西太多，步子太大，又都没讲清楚！哈哈哈！

 好了，今天就写到这里吧！