Effective C++: 55 Specific Ways to Improve Your Programs and Designs
More Effective C++: 35 New Ways to Improve Your Programs and Designs

如想成为一名合格的C++程序员，有许多经典的书籍可以推荐；然而，若想成为一名高效的C++程序员，就绝对不能错过Scott Meyers的这两本名著。Meyer几乎掀起了Effective编程的热潮，例如之后的Effective STL，以及继承了同样风格的Bill Wagner之Effective C#，都是这一系列的佼佼者。人们津津乐道于书中的条款，运用在编程实践中，并深深为Meyer的技术涵养所折服。现实正是如此，运用C++语言开发项目，就好似要穿过一片雷区，战战兢兢，带着撞大运的思想硬着头皮冲锋陷阵，一不小心，就会出师未捷身先死。Meyer的这两本著作，是帮助我们穿越雷区的探测器，可以提醒我们避开危险的地雷，甚至帮助我们撤除地雷，使得我们可以安然通过，到达胜利的目的地。

我在编写C++代码时，常常会翻阅这两本著作。我无法将它们束之高阁。每当我遇到C++的陷阱而无法自拔时，都需要从书中找到解决问题的利器。这是C++程序员案头必备之书，即使对于Java和.NET程序员来说，阅读这两本著作，仍有裨益。虽然GC可以帮助我们规避许多内存陷阱，不至于因为内存泄漏而导致系统崩溃；然而从高效的角度来看，无论何种语言，都有其相通之处，书中的议题可以说是放之语言的四海而皆准。例如在Effective C++中，对设计、实现、面向对象等诸多概念的深入剖析；在More Effective C++一书中，对于多态、异常、效率以及其他的杂项讨论，完全可以脱离具体的C++语言，从通用的编程角度获得收益。

所谓“经典”，意味着经久不衰，不因时间的流逝而失去其存在的价值。语言的变迁在这数十年内，让人应接不暇，但C++的魅力仍然不减。我想，即使在将来C++走向了末路，这两本书仍然不会过时，它会继续爆发出强大的生命力，因为，它抓住了软件设计与开发的本质。

Pragmatic Programmer: From Journeyman to Master

Ward Cunningham说：“如果我在管理一个项目，这本书的作者就是我想要的人……如果办不到，我就会要读过他们的书的人。”这样的赞誉初看似乎有些夸张，仔细思考，却又恰如其分，因为本书反复要证明的其实仅有一个论调，那就是注重实效的哲学。我们这个行业，正需要注重实效的程序员。

我并非为了得到Cunningham的雇佣而阅读本书，更不是奔着从小工到专家的噱头宣传来吹捧本书。我阅读它，是因为它值得阅读；我推荐它，是因为它值得推荐。本书得到的赞誉实在太多了。Kent Beck、Martin Fowler、Kevin Ruland……他们都是这个行业的大师级人物。有他们的推荐难道还不够吗？站在他们的面前，我不过是一个小工而已。但不要忘了，本书面对的读者，不是专家，不是大师，就是普普通通的程序员小工。

记得石头汤吗？记得破窗户理论吗？源代码被猫吃了吗？这就是Andrew Hunt与David Thomas二人书籍的特点。生动、活泼、浅明、扼要，可是仔细沉思，这些比喻无不包含隽永的意味，印象深刻，可以作为编程的箴言或者座右铭。

本书不只有精巧的比喻，Hunt与Thomas兜售的不是文学理论，也不是华丽哲学，而是编程之道。如果说Martin Fowler的《重构》是与代码的坏味道做斗争，那么本书就是向编码旧习与陋习的宣战。它既有战略层面的思想与决策，又有战术层面的技巧与招式。整体而言，它提供了程序员修炼的法则，努力遵循这些法则，你将有机会成为专家。本书涵盖了编程与项目管理的方方面面——如何锤炼经得起时间考验的代码，如何开始卓有成效的开发，如何解决丑陋的重复与僵化，如何克服合作的傲慢与偏见，如何提高算法的效率与质量，如何构建易于测试的代码……

成为专家的梦想在远方漂浮不定，本书会成为你的瞄准器。好的，瞄准，开枪，中靶，红心！

Art of UNIX Programming

Unix是Geek们肆意徜徉的欢场，这里面有老牌的黑客，也有新锐的斗士；有资深的科学家，也有怪诞的不合群者。他们在这里纵横着才气，并以此度过黄金的青春。本书是Eric S. Raymond在这欢场中浪荡的行吟诗，如荷马史诗一般的沧桑、不朽与荡气回肠。之所以给我这样的印象，因为本书第二章的内容，正是以史诗的风格回顾了Unix的起源与历史变迁。

许多读者很容易被本书的书名所迷惑，以为这又是一本大部头的讲述Unix内核与开发的百科全书。若这样想，你或许会失去一位重要的良师益友。尤其对于Windows操作系统下的开发人员，不要因为Unix而排斥它，或者敬而远之，编程艺术是没有操作系统界限的。

好罢，让我们首先来看看本书给出的Unix哲学。诸如：使用简洁的接口拼合简单的部件，清晰胜于机巧，策略同机制分离，设计追求简洁，健壮源于透明与简洁……这是在谈论Unix吗？Raymond貌似醉翁之意不在酒啊！

让我们再来看看本书的第二部分与第三部分。封装和最佳模块大小，紧凑性和正交性，Unix接口设计模式，谈谈复杂度，重用：论不要重新发明轮子……好了，我们可以得出结论——Radmond不过是假Unix之名向受众传播设计之艺术，他是Unix文化的布道者，优雅设计的先驱与导师。我对Unix一窍不通，可我却宁愿花去我闲暇时间的二分之一阅读本书，直到自己深深烙上Unix文化的符号。我收获的经验是，完成本书的阅读，实则是走向耶路撒冷的一次朝圣。我的景仰并非献给Art of UNIX Programming，献给Eric S. Raymond，而是二十世纪最伟大作品之一的Unix。

最经典的书籍不一定最容易懂，正如阳春白雪之于下里巴人。在设计模式的世界中，GOF的《设计模式》永远都是人们推崇的经典，然而真正能够将开发人员引入设计模式殿堂的，或许还是《深入浅出设计模式》（或其他类似书籍）。前者是永恒的经典，后者则是入门的经典。学习一门技术，正需要这样面向不同读者群的两种经典。

领域驱动设计（Domain Driven Design，DDD）同样如此。

作为领域语言的奠基人，Eric Evans在领域驱动设计的地位，相当于Eric Gamma在设计模式中的地位。他的著作《领域驱动设计——软件核心复杂性应对之道》，可谓领域驱动设计的奠基之作。要讨论领域驱动设计，就不可能绕过Eric Evans；正如要讨论重构，就不可能忽视Martin Fowler。

那么，有多少初学者可以在一开始阅读该书，就能够很好掌握领域驱动设计的核心概念？我想，能有如此收获的，绝对是凤毛麟角。原因无他，Evans的讲述过于深奥。如果在领域驱动设计的基础之上，还要加上Martin Fowler提出的企业应用架构模式，以及XP中的测试驱动开发，我们还能找到一本好书吗？答案是Jimmy Nilsson的《领域驱动设计与模式实战》。

Jimmy Nilsson不一定是一名优秀的设计思想家，但在项目实战方面绝对造诣非凡。软件开发正是这样的一门科学，用最专业、最简练、最准确的语言描述，不一定能让读者醍醐灌顶；阅读几行代码，分析几幅UML图，读者反而会触类旁通，有一种豁然开朗的感觉。本书的优秀正在于此。

本书的特色可以从章节的分布窥见一斑。全书分为四部分，分别为：背景知识，应用TDD、应用PoEAA以及下一步骤。

正如书中原文所述，“第一部分是有关布置场景的。”世间万事万物都不可能脱离其上下文而单独存在。领域驱动设计与企业应用架构模式，并不是孤立的两门技术，也不是凭空产生的超级理论，它们离不开软件设计知识的厚积薄发。书中的第一部分是本书的纲领性篇章，内容涵盖架构、领域驱动设计、测试驱动开发、重构、模式与持续集成。

我很喜欢Nilsson在书中的示例方式，他总是尝试着给读者几个不同的方案，通过仔细地分析与比较来说明各种方案的优劣。他没有将自己的意志强加于人，而是循循善诱。因为，设计本无绝对正确的方案，不同的应用场景，决定了不同的解决方案。他只是对自己的选择给出恰如其分的建议。例如本书第二章中关于状态模式的实例，就提出了四种不同的解决方案，并以大量的代码来演示其实现。

另外一种好的示例方式是完整，将每个过程都细致地表现出来，从而给人一种真实项目的感受。在第三章中，关于测试驱动开发和重构的示例，正是以完整的案例演示了测试驱动开发的过程。其中包含有对测试的尝试，工具的选择，以及设计的优化。

本书的精华集中在第二部分和第三部分。第二部分关注领域驱动设计，它能够帮助我们正确地建立以领域模型为中心的设计思想。这部分的内容主要介绍了基于领域驱动设计分层中领域层的相关设计。首先通过分层架构模式，廓清了领域驱动设计的架构思想和架构风格。这一点非常关键。如果不明确架构的层次关系，就很容易将领域知识与数据访问混杂在一起，从而导致设计目的的不明确与混乱。所谓“领域驱动设计”，即表明领域是设计的驱动力与导向，如果不能正确地建立以领域模型为中心的设计思想，那么所谓的领域驱动设计，就只能是空中楼阁，或者是“挂羊头卖狗肉”。有过编程经验的开发人员已经习惯于从数据库开始的设计方式，即使明确领域建模的重要性，在设计过程中，数据库总会像一团幽灵一般不停地来困扰我们的思想。在分析领域模型时，我们总是会不由自主地想起，对于这样一个领域实体，在数据表中究竟该如何表示，对象之间的关系是如何通过主/外键建立关联的，数据表的字段如何进行数据的存储？……诸如此类的问题，总是会纷至沓来。Nilsson并不讳言这一点，他自己也经历过如此的转变。正因为这样的宝贵经验，他才能够在书中给予我们正确实施领域驱动设计的真知灼见。

领域驱动设计从来不是一蹴而就的，书中的内容非常准确地表达了这样一个观点。如何精化领域模型，方法就是测试驱动开发。书中的第5章完整地描述了这一过程，从编写第一个测试用例，到引入领域模式，细化流程，以及对基础架构实现的考虑。书中的代码包含两部分：测试代码与实现代码；书中的UML图也分为两种风格：随手涂鸦的草图和UML工具绘制的类图。这样的示例演示过程如此之真实，给读者的感觉不是在阅读书籍，而是亲临项目组，与Nilsson一起讨论设计方案，共同推进领域驱动设计。这种阅读感觉是无比美妙的。

勿庸讳言，Martin Fowler提出的企业应用架构模式并不易于应用，即使是设计老鸟，在选择企业应用架构模式时，也会陷入迷茫、彷徨或者进退失据的境地。Martin Fowler在设计方面具备的归纳、总结以及抽象的能力已经登峰造极。他总能化腐朽为神奇，或者发现常人所未见的技巧与思想。《重构》如此，《企业应用架构模式》同样如此。然而，令人遗憾的是，《企业应用架构模式》一书虽然有了很好的归纳与分类，但模式种类的繁多仍然会让人无从做出选择，所谓“乱花渐欲迷人眼”。而书中仅限于“玩具项目”的引入，并以片段而非整体的方式进行案例介绍，总会给人一种隔靴搔痒的感觉。Nilsson的《领域驱动设计与模式实战》正好弥补了这一缺陷。在应用企业应用架构模式时，他仍然延续了第二部分的案例，并结合领域驱动设计的分层模式，重点讲解了在实现基础架构过程中如何应用和选择企业应用架构模式。

当然，本书的这一部分内容还不够完美，因为他主要针对的是领域模式的应用，至于其余企业应用架构模式，例如分布式、并发、服务等诸多内容，则浅尝辄止，颇有几分意犹未尽的感觉。以第三部分的第9章《应用NHibernate》为例，固然考虑了应用和实践，完整地展示了NHibernate处理ORM的过程；却正因为如此，显得深度不够，没有很好地将企业应用架构模式和领域驱动设计进行深度挖掘，反而像是一篇介绍NHibernate入门的低级读物。

事实上，不仅是这一章的内容，整个第四部分《下一步骤》都给人这样的感觉。或许因为这部分内容并非Nillsson的创作，使得在叙述风格产生了不统一。当然，这未免有些吹毛求疵了。如果割裂开来看这些内容，每一篇都算得上是介绍软件设计应用与实践的佳作。这些内容涵盖的面也非常广泛，包括SOA、控制反转与依赖注入、AOP、MVC模式等内容。我在阅读这些内容的时候，总觉得作者还没有完全把这些内容展开，只能说浮现出冰山一角。这让我感觉不甘。可若是真的能做到这一点，恐怕本书就会变得和砖头一般的笨重了。

回过头再来思考本书，它是面向初学者的入门级读物吗？我想不是。没有足够的设计能力和思想的积累，很难真正读懂本书。但它给予的实践性设计指导，却无疑简化了它的阅读难度。据我的阅读经验来看，若希望掌握领域驱动设计，比较好的阅读途径是：首先阅读Eric Evans的《领域驱动设计——软件核心复杂性应对之道》（前提是你了解足够多的设计模式知识，以及与设计相关的知识，例如UML、重构以及测试驱动开发）。是的，这本书相对较难，我们很难读懂。但我的建议是可以读书“不求甚解”。遇到不明之处，做个标记，然后放过它，以迂回的方式往前走。这其中，可以适当参考InfoQ的迷你书《领域驱动设计精简版》，它对实体、值对象、聚合、服务、工厂以及资源库等领域对象和模式的描述实在是简明扼要，令人印象深刻。在对领域驱动设计已经有了比较直观和深入的概念之后，再阅读Nilsson的《领域驱动设计与模式实战》一书，你一定会有一种豁然开朗，如曲径通幽的感觉。我想，当你阅读完本书之后，一定会迫不及待地尝试使用领域驱动设计来完善或重构旧有的设计。不过，千万不要奢望从此之后你就能一马平川，真正遇到领域驱动设计相关知识的疑惑，还是需要回头阅读Eric Evans的著作。此时的你，一定能从该书中找到你希望知道的答案。

当我看到什么速成或者多少天学会某种技术时，我泰半会采取怀疑的态度。这属于典型的标题党。那么，重构能够在31天速成吗？能，前提作为读者的你必须具备非常扎实的设计技能，以及丰富的项目经验。如果真是这样的读者，恐怕一周就能速成了吧。

开个玩笑。实际上我是想推荐一本书，它的名字叫31 Days of Refactoring。这本书其实讲的并不是什么速成技巧，而是重构技术的经验荟萃。它利用大量的代码实例（C#代码）演示了各种重构模式的应用。这些示例很简单，简单到初学者都可以看会。至于重构模式的讲解，就更直观了，没有冗长的理论描述，更没有让人乏味的重构步骤，甚至没有让人小心翼翼的单元测试，只有初始与结果。重构之前是什么样，重构之后又是什么样，全部用代码来说话。干脆，直接。

最关键的，本书完全免费！！你可以通过这个链接在线阅读每一章节，也可以通过这个链接下载本书的PDF电子版。

还犹豫什么，快行动吧！Enjoye it:)

设计模式最经典的书籍自然是GOF的《设计模式》，但很多人的反应是这本书太难理解了，并不适合初学者阅读。这话说得在理。一方面，本书使用的C++示例难倒了一大群Java和.NET的开发人员；另一方面，这本书的风格过于专业化，更偏向于学术论文的风格（事实上，本书的雏形就是来源于GOF中Erich Gamma的博士论文），因此就显得有些晦涩难懂了。

基本上，本书可以作为我们参考的标准，是经常查阅的文献资料。如果你对某个设计模式还有困惑不解之处，阅读本书，然后细细品味，总会给你一些豁然开朗的感觉。夸张点说，这本书可以说是设计模式的红宝书，即使人手一册，也不为过。说句题外话，我还是喜欢外版书的封面设计，给人一种艺术的美感，让人看着就有想买的冲动。国内专业书籍的装帧与设计，做得好的，真的很少。

对于设计模式，这几年被人广泛推崇的还是这本Head First Design Patterns，中文版被译作《设计模式深入浅出》。书名就代表了本书的性质是面向初学者的。而它的著作风格才是真正引人注目和称道的。专业书籍的风格通常会存在迥然不同的两种风格。一种风格深入浅出，趣味盎然，阅读过程轻松愉快，而给出的实例也多以生活中的例子进行类比，帮助读者对书内容的理解。这本书就是这一类书籍的个中翘楚。去年在国内计算机图书界，独领风骚的一本《大话设计模式》，同样属于这样的风格。程杰也因为该书在去年荣获了51cto的年度IT图书的最佳原创作者奖。该书的成功就在于它继承了这样一种集娱乐与技术为一体的独特风格，让技术人员看到，原来，技术书籍也可以这样写，读起来也可以这样有趣。至于另一种写作风格则偏向于循规蹈矩，描述技术问题胜在其条理清楚，如山涧流水，优雅而从容，却最终能够融汇成一条大河。很难说两种风格孰优孰劣，前者胜在趣味，后者胜在严谨。我并不是说有趣的书就一定不严谨，只是相对而言，一本书若要有趣，就必须给出生动的比喻或者隐喻，而这样的修辞总会或多或少使其本质发生小小的变形。然而这两种风格，若要成功，最关键的还是要看著者的技术功底和笔力。

虽然设计主要还是要看思想，但很多读者还是比较在意每本书的代码载体。Head First Design Patterns一书给出的是Java示例，而《大话设计模式》则是C#。还有一本面向初学者的好书是阎宏先生所著的《Java与模式》。本书利用中国传统文化来阐述设计之道，又引入了大量的Java实例，尤其是对Java的API或框架进行了深入分析。所以读来既有趣味，又有文化的底蕴，同时还不乏实际的例子给出标准的范本。我以为，对于初学者，本书是再合适不过的了。

若要理解UML，并将软件开发和设计有效地与UML结合起来，那么最佳的选择是阅读Craig Larman的经典著作Applying UML and Patterns。本书已经出版到第三版。一本书若是能够再版、三版，绝对有其值得称道之处。该书全面地介绍了RUP开发模型，并将UML与开发过程、设计模式等有效地结合起来。随着本书章节的逐步演进，读者的能力也将得到逐步的提高。本书的中文版名为《UML和模式应用》，似乎现在仅出版了第二版的中文版本，不由不让人感叹我们总是在追着技术前进的步伐在跑，甚至是优秀书籍的出版，我们也是在后面追赶着，却始终追赶不上。

将敏捷、面向对象思想、设计模式有机结合起来，会是哪一本书？还用问吗，自然是Bob大叔的巅峰之作Agile Software Development: Principles, Patterns, and Practices了。本书中文版的译者邓辉先生功底扎实，比较好地将原书的神韵传达了出来。

若要问哪些书（当然是指技术书籍）可以让我重读不厌？那么这本书一定要排在前列。实际上，像这一类的书籍都是值得反复阅读的，因为每一次阅读，它都会给我们新的启发与体会。所谓“读书百遍，其义自现”。技术书籍本身存在一定的难度，不同水平的人阅读同一本书的收获是大不相同的。而在不同阶段的同一个人，因为技术水平的变化，自然每次都能够读出新意来。本书附带的代码是Java，同时还包含少量C++代码。之后，Bob大叔又推出了该书的C#版，算是满足了广大的C#开发者的强烈需求。

即使是最优秀的设计师，也不可能总是在第一次就能将设计做好，因而我们需要重构。讲解重构技术的书籍中，最声名显赫的无疑就是Martin Fowler的Refactoring: Improving the Design of Existing Code。正是本书开创了重构在软件开发中的光辉地位。这本书的优秀自然不用我再来饶舌了。Martin Fowler先生是全球知名的软件大师，他的每一本著作都给业界带来了深远的影响。我在一次和Fowler先生的面对面交谈中，曾经问他至今最满意的著作是哪一本。他没有丝毫的犹豫，就回答是Refactoring。

本书的中文版名为《重构：改善既有代码的设计》，译者为侯捷和熊节。熊节是敝同乡，我和他有过一次面谈，谈起过这本书的翻译。那些翻译的往事也让他感触颇多吧。本书真正称得上是软件书籍中的名著名译。熊节的中文和英文造诣都很厉害，所以阅读本书的中文版，你几乎感觉不到有“隔”了一层的晦涩。通篇阅读下来，就是那么流畅。顺带提及，本书是少有的中文版封面设计优于原版设计的特例。

虽然说Martin Fowler是重构技术的集大成者，书中提到的重构方法也多数用到了设计模式，但真正将重构与模式结合起来的，还是Joshua Kerievsky，他的著作Refactoring to Patterns 也曾经荣获了第15届Jolt大奖。书中强调：“‘通过重构实现模式、趋向模式和去除模式’，而不再是在预先设计中使用模式，也不再过早地在代码中加入模式。”实际上，这样的论调恰恰迎合了敏捷社区的需要。极限编程的实践就要求简单设计和设计改善，改善的方法就是利用重构合理地引入设计模式，以期改善程序的结构，使其具有更佳的可复用性和可扩展性。此外，本书还是Refactoring: Improving the Design of Existing Code一书的补充，增加了诸如用Factory Method引入多态创建、将聚集操作搬移到Collecting Parameter等重构方法，明确地把设计模式作为重构技术的一等公民。本书在大陆的中文版为《重构与模式》，而在台湾则被候捷和陈裕城译作《重构-向范式前进》。虽然名字不够精简，但却真正地代表了作者创作本书的含义，就是从Refactoring到Patterns。

虽然Martin Fowler最看重Refactoring: Improving the Design of Existing Code一书，但我个人认为，他的Patterns of Enterprise Application Architecture一书（中文版名为《企业应用架构模式》）价值更高，因为它为我们设计人员给出了全面、深入、权威的企业级设计指引。

在所有的软件大师中，或许Martin Fowler是最善于总结的一位。他虽然没有提出具有独创性的方法与思想，但很多独创性的方法与思想到了他的笔下，都能化腐朽为神奇。本书最好地印证了这样的奇迹。在本书诞生之前，实际上关于分层设计、并发处理、对象关系映射、表现模式以及分布式处理，已经有了许多非常优秀的实践。但只有Martin Fowler凭借自己丰富的技术经验与无与伦比的创作能力，将这些散落的珍珠串联在了一起，最后形成了一串璀璨夺目的项链。透过本书，Fowler将自己善于总结的能力发挥得淋漓尽致，真可以说是“笔落惊风雨，书成泣鬼神。”

Martin Fowler的早期著作中，Analysis Patterns提出了领域逻辑的诸多建模原则和模式，不过真正对领域建模、分析和设计产生奠基作用和推动作用的，还是Eric Evans的大作Domain-Driven Design，中文版名为《领域驱动设计》。本书的诞生推动了一种设计方法，改变了传统通过数据设计驱动开发的模式，而是将核心关注点放在了领域逻辑上，而这应该说才是真正的软件设计的正道。

Martin Fowler在本书的序中，这样写道：“控制复杂问题的关键是建立一个好的领域模型，它越过问题域的表象介绍其底层的结构，给软件开发人员提供所需要的方法。”毋庸置疑，当我们面对复杂多变的领域逻辑时，领域驱动设计已经成为了我们手中的利器。掌握领域驱动设计，并不能保证所有复杂的设计问题都能够迎刃而解，但这种思想却能够帮助我们像庖丁解牛一般，即使面对纷繁复杂的领域逻辑，也能够做到“以神遇而不以目视，官知止而神欲行”。

本书堪称经典，正如Kent Beck的推荐：“每个有思想的软件开发人员，其书架上都应该珍藏这样一本书。”说起来，我也是Kent Beck提到的“有思想的软件开发人员”了。

双方前锋紧紧地站在一起，裁判哨声响起，球被掷出，双方球员奋力拼搏，反复地冲刺，竭尽全力向自己的目标冲去。这是英式橄榄球中Scrum的场景。 然而这样的活动，却被Ken Schwaber和 Jeff Sutherland巧妙地借助隐喻的方式引入到敏捷项目管理中，仔细思索，却又如此的恰如其分。在橄榄球运动中，固然需要强健的体魄与迅捷的速度，但更 重要的却是组织、协作、交流，以及一位优秀的指挥官。虽然二者的方式不同，然而赢得比赛与成功交付产品的目标其实是完全一致的。

Scrum是一种灵活的软件管理过程，它可以帮助你驾驭迭代、递增的软件开发过程。Scrum方法最初实践于Easel公司，现已被数十家公司数百 个项目开发中应用，适用于需求难以预测的复杂商务应用产品的开发。作为一种项目管理方法，Scrum与其它方法颇有不同之处，规则与名称也自成一套体系。 在Scrum管理活动中，包含三种不同的角色：Scrum Master，Product Owner，Team。Scrum的每一次迭代被称为Sprint，意为“冲刺”，生动形象地展现了项目开发活动的迭代过程。Scrum将功能需求称之为 Product Backlog，它们通常是由Product Owner提出。Product Backlog会在Scrum Master主持的Sprint Planning Meeting中确定，并在确定了Sprint之后，形成Sprint Backlog。Scrum非常重视团队成员的交流，除了Sprint Planning Meeting之外，还要求召开Daily Scrum Meeting，以及Sprint Review Meeting与Sprint Retrospective Meeting。

More...