于今夕之何夕，唯读书以自省

我们希望系统解决的问题通过需求得以体现。GUI设计是要体现出GUI如何引导用户使用系统以解决他们的问题。很多项目都将GUI设计混同于需求的假面之下，这很让人讶异。如果你的项目总是陷于无尽的需求工作之中，看看问题是不是出在GUI设计上。

GUI是设计，不是需求

凯伦，程序经理

我在一家新公司工作时，试图拯救一个陷入“需求地狱”的项目。需求文档已经达到300多页，而且远未完成。

阅读这些文档后，我找到了原因。所有的GUI设计都被记录在需求文档中。GUI设计没有放在项目的设计阶段，业务分析人员和GUI设计人员试图将所有的GUI需求都放在需求文档中。他们使用了功能强大的图形设计工具，并在需求文档中定义GUI。

我向他们询问原因，他们看着我，说道：“这些是GUI需求。”我建议他们认真看看GUI设计，并且考虑这些设计是否应该跟希望系统解决的问题放在一起。GUI设计不应放在需求文档中。

最终，他们同意采纳我的建议，我们也可以逃离需求地狱了。而且，由于我按照逐个功能重新组织了项目，GUI设计也就跟各个功能结合在一起了。我们定期检查整个GUI的一致性，但是这与需求无关，这属于设计。

人们很容易在项目开始阶段设计GUI，并称其为需求。如果要这么做，项目就永远无法找到自己的节奏。它会一直陷于需求的泥沼之中，直到最后，无法完成任何客户需要的功能，虽然到时候能够得到精美无比的GUI。

要减少不必要的代码，有一个好方法：想想谁会使用系统，又该如何开发用户需要的系统。

有很多项目都试图通过定义功能性和非功能性需求来确定需求。可是这些需求没有说明一个人如何使用系统，以及一个功能在何种场景下必须运行。需求收集的方法应该为项目团队提供上下文，这样才能深入理解需求。

谁需要那个支票账户？

克拉丽莎，资深经理

我的项目团队陷入困境。他们实现了一堆只开发完一部分的功能，可是没有哪个能够真正运行。我召开了一个会议，以决定接下来该做什么。

在会议上，我想知道：为了完成项目，哪些用户是他们的首要服务对象。他们看着我，脸上毫无表情。“你们看，我们是一家银行。我们希望年满18岁、将要进入大学的人们首先使用我们的服务。还有住在郊外的妈妈们，她们还有其他资产，75岁的老奶奶，以及年方15已经靠做家务挣得零花钱的孩子们。我们可以为他们提供不同的理财服务。如果他们走进来，我们希望他们成为我们的客户。对于这些不同类型的客户，我们真地想过要给他们提供什么样的产品么？”

他们以前太过专注于系统的内部功能，忽视了系统真正要为之服务的用户。我们把期望捕获的用户重新进行了排序，项目团队因此得以完成需求定义，并完成系统的功能。

人，总是人的因素，不是么？ 

只要大家了解需求的上下文，开发人员、测试人员和文案人员就能知道如何开发、测试、编写文案。如果他们不能了解，要是需求以功能性和非功能性需求的方式罗列，他们也可以问一些更好的问题，从而深入了解需求。

Google Translation Toolkit 是google刚刚发布的在线翻译平台，初步评测结果如下：

说明：在settings里面有两个选择：

第一种：让目的文档中填充它翻译的结果；

第二种：在目的文档窗口中直接放置原文

以下测试方式，选择第一种设置：

已尝试如下三种方式：

1、提供英文页面urll，直接让其翻译，

结果：翻译质量不行，而且格式乱掉，它自己加了很多span

2、将英文web页面另存到本地，再上传文件让其翻译，

结果：同上；

3、提取html标签内容，另存为word文件，再上传，让其翻译

结果：格式同样乱掉，它自己很“智能”地处理了一些标签，结果更乱了。。..-_-|||||..

当setting中选择显示原文时，上述第一和第二种方式生成的文件同样含有n多span，无法使用。

第三种方案翻译起来相对比较方便，但是如果要调整html标签的位置相信比较麻烦（要调整，是因为语序上的变化），

===============

如果在环境中选择show toolkit，屏幕下方会有工具箱出现，目前看来，

• 字典比较方便，但是解释比较简单，
• computer translation：如果你愿意，结果可以直接上到目的文档窗口。
• glossary时间短， 还没有尝试。

结论:

一言以蔽之，这是一个初具雏形的翻译IDE。该平台最有用之处在于方便翻译的对照和审校，可以显著提高多人翻译写作效率，但是翻译质量，仍然不能恭维。简单说，就是给翻译提供了一个IDE。 如果能像Eclipse那样开放API或是开源,我相信很多做这个协作翻译平台的公司就要开始冒冷汗了~~~

ps：

另外，不知道大家有没有注意到，在选择要翻译的东西时，google提供的第四个选项：Knol

http://knol.google.com/k

这似乎是google自己做的知识平台……

Google真得是强悍啊。。。

邀请团队成员相互复查工作。复查的形式并不重要，结对编程（pair programming）、伙伴复查（buddy review）、同行复查（peer review）、走查（walk-through）、正式代码检查（formal code inspection）都可以。复查能够为项目方方面面带来好处。项目经理要为团队提供多种方法。这些方法以特定顺序介绍：从最不正式到最正式。以我的经验来看，这也可以从最有效和易于保持的，到最没有效果和难以维系的。

结对编程。先不要假定“这里没人愿意这么做”，要允许大家这么做。（而且可以提醒大家，他们已经完成过结对调试了。）我会问大家谁自愿进行结对。我建议他们在开始之前，先去阅读一些相关资源，比如［WK02］和［SH06b］，还有http://www.pairprogramming.com。

不出意外的话，会有人愿意尝试结对的。相对独自工作来说，他们可以学到如何通过结对编程使工作变得更有效率。

除了减少缺陷、加快开发速度外，结对编程还能带来很大的好处：有两个人完全熟悉并知道如何处理同一块代码。而且，如果人们经常切换不同的结对对象，他们就会深入了解目前团队正在开发的系统的各个部分。此外，对代码作者的反馈也没有延迟。

用哪种生命周期都没有关系。结对这种技术总是可以用来让更多人了解代码。

伙伴复查。伙伴复查无法达到与结对编程同样的学习效果。没错，每个人都可以了解产品某个功能的代码，但是不会像作者那样深入。作者得到的反馈也会有一点点延迟——即完成复查所需的时间。

同行复查。同行复查与伙伴复查的意思差不多（把你的代码给别人看看），但是很多人倾向于一次复查一个完整的模块，不管是一个文件还是几个文件。复查大量代码要更难，很难找出需要进行复查的大块时间，而且很难记住脑子里面所有的想法。

同行复查很难达到与伙伴复查同样的学习效果。以我的经验来看，这样做经常只能复查代码风格，而不是内容。对于作者的反馈延迟可以长达一星期。

走查。用走查的方式，一些人会集中在一个房间之内，由代码作者说明产品，过一遍文档。这里几乎没有团队学习的过程，而作者得到反馈的延迟时间也相当长——也就是用来组织会议需要的时间。

正式检查。如果做得好，正式检查可以帮助团队通过讨论了解产品。不过我很少看到正式检查能够在组织内长久实施下去。即使是启动检查的人，也很难维持检查的动力。

维持检查很困难，因为检查别人的代码会打乱每个人的节奏，还有项目的节奏。要想进行一次费根式（Fagan-style）的检查[1]，人们必须离开自己的工作任务上下文，详细阅读产品代码，准备评论自己看到的东西。我发现，为了一次两小时的检查会议，要花上几小时甚至一天的时间去准备。

[1] 费根式检查（Fagan inspection）是一种在开发文档中试图发现缺陷的结构化过程。这些文档可以包括代码、需求说明、设计文档以及其他软件开发过程涉及的文档。其命名来源于迈克尔·费根（Michael Fagan）——正式软件检查的发明人。详情可查看：http://en.wikipedia.org/wiki/Fagan_inspection。——译者注。

文中图片来自：http://www.flickr.com/photos/pezz/

 

逐个功能进行实现和测试

哈威、维贾、道、兰迪、肯和梅布尔，负责提醒功能的团队

我是哈威，团队的头儿。我们的开发人员包括维贾、道、兰迪和肯，梅布尔是测试人员。我们在GUI、平台、硬件集成以及几个方面都有专家，而梅布尔无所不知。（背景中传来笑声。）

刚开始的时候，我们试图先把架构开发出来，再制订规范，告诉大家我们在做什么。我们每个人各自负责一块，最后再放到一起。可是一切都没有按计划进行。因为即使我们有规范，在开发各自的组件时，我们总会改变些什么。

梅布尔曾经听过有关按功能实现的说法，并告诉了我。我问大家是否愿意组建一个基于功能的团队。嗯，其实是基于功能集合的团队。我们开发所有的提醒功能，一次完成一个，从前端到后台。梅布尔会负责测试。

开始时有点儿困难，不过习惯之后，我们添加功能的速度让人惊喜不已。我们不再是每个人开发很多代码然后再集成到一起，而是只添加每个提醒功能需要的代码，再进行测试。梅布尔保证我们不要出现系统级别上的问题，我们保证每个提醒功能不要出问题。

我们的开发速度如此之快，不久就有新的功能需要开发了。现在，有些其他组也在尝试我们的做法。整个项目的进度都加快了，而且客户也能知道我们在开发哪些功能，反馈也由此而来。

很多项目团队都是按照架构进行组织的，比如基于Web的产品会分平台组、中间件组和GUI组。可是如果按架构进行实现，项目经理就很难知道开发完的功能是否可以正常运行，除非等到整个产品集成完毕。如果按架构实现，就很难进行持续集成了，因为无法构建和运行测试。在开发的开始阶段，没有哪个功能是完全实现的，都要等到快结束的时候才能做完。而且，项目经理也无法将任何功能视为完成。

所有已经完成的开发工作都是在创建“浪费”［MP06］，没有产生任何有价值的东西。一旦完成某些功能，就可以开始计算价值了。可是在此之前，这些价值无法衡量。

按架构实现会打乱项目的节奏，因为得到的都是部分完成的功能。不到开发完成，项目经理看不到完整的功能，而这时得到的反馈对开发人员来说就太晚了。如果按功能实现，开发团队只要针对某个功能的要求利用架构进行实现就好了。假如要开发Web应用，项目经理可以组织一个小型的基于功能的跨职能团队，其中包括一些了解平台的人员、一些了解中间件的人员和了解GUI的人员，他们各自负责自己擅长的工作，并且只针对团队负责的一个特定功能。要是团队人员拥有不同的兴趣和技术技能，比如擅长GUI和固件方面的技术，这些人就可以按照功能逐个应用他们的技能。（项目经理应该帮助他们组织好各自在项目中的工作时间。）

有些团队认为，应该在项目前期预先细化需求（Big Requirements Up Front，BRUF），并进行大量设计（Big Design Up Front，BDUF）。这样的团队要想切换到按功能实现的方式，就没那么顺利了。这时，可以跟他们说明一个功能应该是什么样子（它应该有多小），并让他们知道自己不应该做什么（参见5.3节），帮他们了解实现的功能要具备足够的架构完整性，从而在实现后续功能时也不会有问题。要提醒这些团队，他们在调试和测试的时候，都是按功能进行的，因此不会陌生。

有些人可能仍持反对态度，说他们在考虑一个功能之前，仍需要知道整体架构没有问题。这种情况下，架构草稿会有所帮助（参见3.5节）。不过不要坚守其中的架构，除非团队已经实现过不少功能了。

9.3.1. 首先实现具有最高价值的功能

在按功能实现时，要先实现最有价值的功能。把风险最高的功能先往后放一放。如果运气足够好，也许根本不用开发这些高风险的功能。这样一来，测试人员和开发人员就能对整个系统有足够的了解，他们就可以保持自己的节奏了。

有些团队不愿意按功能实现，因为他们不知道先开发哪个功能。团队中有些人会希望先开发风险最高的功能，有些人希望先开发最有价值的功能。如果没人愿意排定需求的优先级顺序，那就很难知道哪个功能最有价值了。

如果没有客户或是客户代理的参与，你作为项目经理，就要在团队的辅助下，担起制订和发布产品待办事项列表的责任（参见16.6.1节）。项目经理要判断出各个功能的实现顺序。

如果有人愿意判定各个功能的价值，那就按价值高低进行实现，即便会给架构带来风险也要这么做。

如果功能的价值和完成度越高，项目经理就能在当前项目中为自己和团队带来更多灵活性。你也许可以尽早发布（如果高风险的功能无法使用当前架构），这对很多客户都是很有价值的。推迟开发高风险、低价值的功能，可以保持项目的节奏，并降低当前版本的风险。

9.3.2. 按功能调试

有些团队坚持按架构实现。到了测试的时候，测试人员却是逐个功能进行的。这么一来，团队在调试的时候也得按功能进行了，即使他们构建产品的方式与此不同。

为了按功能调试，项目经理要构建跨架构团队（要么就得能够接触到所有团队成员）。如果从来没有组建过跨越架构的团队，项目的节奏会因此而扰乱。不过，要是没有跨越架构的团队，问题是无法解决的。

要是到了项目尾声，发现团队在按功能调试，那还是考虑在一开始就按功能实现吧。这会减少项目的干扰，同时项目节奏也更平稳。

9.3.3. 按功能测试

测试人员会按照功能测试系统，有时是因为需求的编写方式，有时是因为这就是测试人员访问系统的工作方式。当测试人员报告问题时，他们很少会单独报告各个小架构组件上的问题。实际上，他们会在测试用例中提出问题，比如，“当我试图打开一个银行账号时，我可以看到数据穿过中间件进入到数据库中，但是我看不到返回的确认。”测试人员在这里报告了一个中间件的问题，但是没有明确指出是在哪里。

开发人员已经习惯于看到这样的报告了（不管是与调试还是测试相关），也惯于回溯问题，以判断功能是如何与架构交互的，从而理解问题。按功能实现，开发人员就可以在设计和编写代码时看到潜在的问题，不至于到开发尾声才发现。

不管使用持续集成与否，都应该为构建产品创建自动化冒烟测试。冒烟测试仅仅是为了验证要构建的版本没有问题。你想添加多少回归测试都可以，我不拦着，但是使用冒烟测试，是要知道当前的构建版本是否对大家有用。

有了自动化冒烟测试，项目团队就可以知道是不是有人破坏了当前构建版本。如果能尽早知道一个构建完成了，你就可以在其基础上做些自己想做的工作。要是必须依赖其他开发人员或是测试人员才能知道当前构建版本出了问题，那你就不能以最快的速度修复当前构建版本了。

别让烟跑出去！

梅瑞狄斯，资深测试人员

作为测试人员，寻找问题是我的职责所在。而且，我也很擅长这个。我有一句座右铭：“别让烟跑出去。”

有一次，我加入了公司的一个新项目。开发人员以前从没有与专业测试人员一起工作过。我拿着一张有15个缺陷的列表，走到他们中一个人的面前，然后说：“你得说说这是怎么回事，要不我把这些问题提交到缺陷跟踪系统里面如何？”他们都惊呆了。

我向他们说明，这些缺陷通过一个自动化冒烟测试都可以找出来。没有哪个缺陷需要靠我的专业知识和经验才能发现。我不想浪费时间找出这些易于发现的缺陷，而是要找出更捣蛋的缺陷——时而发生的问题、系统可伸缩性上的问题和可靠性问题。我想钻到代码之中，把高难度缺陷一个个都揪出来，直到它们全部显形。

那个开发人员脸色发白，屏住呼吸说道：“呃，好吧，我希望你也能那么做。需要我配合你什么？”

我解释了我的座右铭：“你的工作是尽量保证不出问题。我的职责是尽量让问题血淋淋地暴露出来。明白了么？”他表示同意。我想我听到他跟别人说我有点嗜血倾向。不过，管他的，我对此毫无意见。

我签入了我的测试代码，开始构建自动化冒烟测试框架。开发人员开始一点儿一点儿地加入冒烟测试。如果我找到了一个冒烟测试应该发现的问题，就会冲到加入这个缺陷的开发人员跟前，对他说“别让烟跑出去”。不久之后，大家只要一看到我走向开发人员的小隔间，就会有人大叫：“是谁把烟放出去的？”

我们现在合作得非常好。这些开发人员的工作表现非常好，而且他们也让我能很好地完成自己的工作。我们的产品NB极了！（这么说没事吧？）

让构建版本正常工作，这对建立并保持项目的节奏大有裨益。能够第一时间发现构建版本出现问题，也使得项目经理可以将项目带回正常的节奏，或者发现是什么使得团队无法保持节奏。

实际上，如果项目的产品要在多种型号的计算机、数据库或固件上运行，要确保团队每天都为所有的平台编译并构建产品。如果不这么做，到了项目结束的时候，项目经理就得忙着解决那时才能发现的问题了。在项目中越早发现兼容性方面的差池，就越容易应对，而且开发人员在后面的工作中也能将其牢记在心。

（正文图片来自：http://www.flickr.com/photos/arciteka/）

第9章 保持项目节奏

项目经理不但要用管理实践掌控项目，还可以欢迎团队改变自己的技术实践，从而获得更大收益。本章包含的一系列实践，能为项目带来很多好处。项目经理和团队要根据自身的实际情况，判断如何调整、使用这些实践，而不要强制推行。如果你认为它们有所裨益，不妨将其介绍给团队，并欢迎团队积极尝试。

9.1 在项目中使用持续集成

开发人员用一两个小时编写一段代码，对其进行编译，测试，复查，构建，运行冒烟测试，并验证做出的改变不会破坏现有系统代码，再将其签入到代码库中。持续集成就这么发生了。[1]

持续集成可以让开发人员马上得到所做工作的反馈。他们开始考虑将大任务拆分成更小的部分（这可以让他们以更快的步伐前进），还能尽早识别出项目的集成风险。持续集成让开发人员每天都能有所收获，帮助项目团队找到符合自己的节奏。

开发人员只有在完成了某个功能的代码后才将其签入，这就是按阶段集成的方式。有些开发人员一周签入一次代码。有些更糟糕的项目，开发人员一到两个月才签入一次代码。按阶段集成会打断项目的节奏。构建时出现的问题，会中断设计和编写新功能代码的人们的思路。他们不得不记住很多小细节，而这些小细节覆盖了从项目开始直到进行集成的各个阶段。如果忘记了这些细节，项目进度会放缓，因为团队发现了缺陷，而且必须想起可能是几个月前所写代码的细枝末节。这其实是一种同时处理多任务的方式，而且特别不容易发现。人们是在做同一个项目的工作，而且手上的任务可能也相关，但是思考问题时的抽象层次却有所不同（设计比调试的抽象层次更高），而且也不再是处理同一个功能的问题，思考问题的上下文由此发生了变化。所有切换上下文的代价都发生在这里（参见16.7.3节），在设计下一个功能时，开发人员可能会因此而丧失好的想法，还可能增加向设计中引入缺陷的潜在风险。

如果项目经理不能将变更后的代码集成到代码库中，你可以采取持续集成的变种。假设你管理一个项目团队，大家的任务是扩展一个已存在产品的设计。团队目前正在处理的部分产品代码是整个产品的基础。如果这部分代码无法运行，那整个产品都不能运行。你现在不想签入代码，因为这样会破坏现有的产品，而且会占用三个月的时间来添加和替换产品的现有功能。你该怎么做？

应该选择现有状况下的最佳方案。你可以将主代码库做一个分支版本，并让所有开发人员在这个分支版本上开发。他们每次签入一些代码，都会与主线代码进行同步，保证自己的分支代码是最新版本。这使得开发人员总是在最新和最全的代码版本库上进行开发，而且他们一直都在进行集成。当他们完成各自工作后，就会将所有代码都合并回主线。

这是持续集成的一个变种。如果必须重写已经存在的代码，而且在开发变更代码时不想破坏现有系统，可以采用这种方式。如果项目经理管理的项目所提供的服务要为一组产品使用，比如一个程序库或是一个平台，这种方式同样适用。

[1] 见http://www.martinfowler.com/articles/continuousIntegration.html。

（图片来自：http://www.flickr.com/photos/cuppini/）

节奏，无所不在。春夏秋冬，日升月落，这是大自然的节奏；日出而作日入而息，朝九晚五，这是人类社会的节奏。生活有了节奏，人体的各个构成部分、乃至各个细胞才能正常运作，以保证整体的健康。社会中有节奏，而不是朝令夕改，大家才能安居乐业。

项目管理同样如此。《Manage It！》第8章“掌控项目”第1节就名为“掌控项目的节奏”。其中说到：

节奏，每个项目生而有之。有些项目节奏混乱，进展缓慢。有些项目就像坐上了火箭，倏忽间，团队就完成了更多工作。所有的项目都有节奏，不过它会随时间而变。观察节奏是项目经理的职责，你还要看出来哪些实践是否能够帮助项目建立并维持合理的节奏，保证项目取得成功。

项目的生命周期越接近于顺序式生命周期，项目的节奏就越有可能随阶段发生变化［Rot04a］。在早期阶段，项目看起来就像遭受了很多痛苦，项目经理也不知道需求何时冻结、设计何时稳定。有些项目会“神奇地”找到出口，在进入实施阶段后，节奏逐渐显现出来，而且日趋稳定，因为该做的决策已经做了，而且得到了实行。假定没有人手方面的问题，项目就可以顺利完成。如果项目总是混乱不堪，项目经理在整个生命周期中都会找不到方向，也难以发现令人舒服的节奏。

在敏捷生命周期中，在迭代规划阶段也许会观察到混乱的状况。不过迭代规划只会持续几个小时，团队在迭代开始后可以找到像鼓点一样的节奏。（如果你曾见过敏捷生命周期找不到节奏的状况，很可能是因为团队没有遵循敏捷的价值观，或是错误使用了敏捷实践。）

下面这些打断项目正常节奏的问题，是我亲眼所见的。

• 不知道要先完成哪些需求。
• 允许项目的需求收集阶段持续过长时间。
• 允许GUI随时发生变化，而GUI相关人员在项目中不知该如何是好。
• 没有架构的整体描述，不知道各个部分如何构成。
• 无法及时向项目中加入必要的人员，使得他们很难取得成功。

在第8章中还提到了一些管理实践可以帮助项目找到稳定的节奏，包括“中途回顾”、“为需求排序”、“用时间盒限定需求相关的工作”等等。

接下来，我会逐节放出第9章“保持项目节奏”的内容。欢迎大家就译文和内容提出宝贵意见。

[Rot04a]:Johanna Rothman. Got good rhythm? Software Development Magazine, 12(6), 2004. http://www.drdobbs.com/dept/architect/184415151.

下星期二，来自总部的大人物就要来视察了。或者你可能要在十个星期后做上市演示。不管怎么样，你要面对一个不可改变的日期、一系列充满野心或是不可能实现的功能集合，而且这些功能必须要在那个日期之前完成。无论是否已经测量过团队的开发速度，你知道团队是无法在截止日期来临之时完成所有的功能了。看起来团队面对着日程，都已经处于恍惚的状态了。有时，这就是团队对于“幸福日期”的回应。

图6.16 令人恍惚的日程

首先，要创建项目的仪表板（dashboard，见第11章），再测量进度，从测量开发速度开始。然后考虑采取如下行动。

• 如果还没有用迭代式开发，赶紧把剩下的项目分解成迭代吧，迭代时间越短越好。如果在不可改变的截止日期前有10个星期的时间，项目最少要分解成5个迭代，最好是10个。每周一个迭代，这可以帮你不断调整工作的优先级。迭代的目标是要完成某个功能或一组功能，这包括功能的开发、文档、测试，以及其他产品对于“完成”的要求。如果上市演示需要在线帮助，除非一个功能具备了在线帮助，否则它就不算完成。
• 在一个迭代中要集中精力，每日站立会议对此会有所帮助。项目团队的目标必须放在要完成的工作上。当完成足够多的细分任务之后，就可以得到一个完整的功能或是产品了。不要让团队中的人们受其他项目、未来工作或是技术债务（见附录B）的干扰，除非技术债务使得当前迭代的工作无法完成。
• 如果还没有准备好，就按功能逐个实现吧。这样可能会产生不完整的系统架构，不过不必担心。如果一个功能需要架构提供某些方面的支持，团队会实现的。如果功能上不需要，那就没有人会用它。

通过使用“游击队式敏捷”（guerilla-agile） [1] ，可以消除很多上述的日程安排游戏。如果能够以不超过四周的时间盒来组织项目，按功能逐个实现，随进度集成，并测量进展速度，项目经理就可以中止这些游戏。如果总是能以这样的方式管理，那就可以完全避免绝大多数的日程安排游戏。

[1] Guerilla agile 是作者Johanna Rothman在Agile 2007大会上的演讲题目，指的是非正式的敏捷实施方式，演讲提纲下载地址：www.agile2007.org/downloads/handouts/Rothman_383.pdf。——译注

这两天在上班路上听了Linda Rising这个有关personal agility视频的录音，虽然不是直接与软件开发相关，但还是有一些收获，记录如下：

• 当人类社会进入到工业时代之后，有饮用咖啡和茶的习惯的人可以及时起床，赶去上班，以满足严格的时间要求。从而超越习惯于日出而作日入而息的人们，获得更多机会。
  • 引申问题：现在，如果懂得很多敏捷的原则和实践，能够身体力行Clean Code的人，是不是同样会获得更多机会？我想是的。
• 工业时代Command and Control的管理方式，也打乱了人们以往日出而作日入而息的生活方式，我们不得不依靠咖啡因来提神。
• 古代的一个有趣谚语：
  • In wine there is wisdom
  • In bear there is freedom
  • In water there is bacteria(guess this is just a joke :)
• 时钟的发明和咖啡因的广泛使用改变了人们的生活。
• 对成年人来说，只需要1个小时，咖啡因就可以从血液进入到大脑中，并达到峰值效果
• 咖啡因会阻止腺苷酸的催眠效果，让人清醒。
• 不同人对咖啡因新陈代谢的时间比较，以半衰期为标准：
  • 对一般成人来说，咖啡因的半衰期为3.5小时
  • 服药的女士：5.5小时
  • 怀孕的女士：10小时
  • 胎儿或新生儿无法吸收咖啡因
  • 很多发达国家的孩子生来体内就含有咖啡因（..-_-|||||..）
  • 婴儿时期的半衰期是100小时，并会逐步变短，但只有到1岁之后，婴儿才能开始吸收咖啡因
• 咖啡因和尼古丁会互相起到促进作用。
• 最初的咖啡屋供男人们互相抽烟、喝酒聊天而用。
• 咖啡因使我们难以得到足够的睡眠，从而无法最大限度发挥我们的体力、精力和感情，同时导致我们的早衰。
• 巴尔扎克甚至靠吃咖啡粉来产生灵感。。。
• 万恶的资本主义制度让他们国家可怜的孩子们从小就喝可口可乐，从而过早接触了大量的咖啡因。
• 为了让孩子们无法抵抗可乐的诱惑，万恶的资本家们想尽办法，用圣诞老人当幌子。。。
• 此后还有诸如红牛这样的“能量饮料”，其实就是咖啡因含量高。。。
• 在进化生物学家看来：
  • 有一些本能让我们能够生存至今
  • 我们生而灵活、有耐力、而且敏捷
  • 我们构建了一个技术世界，迫使我们僵化而没有耐性
  • 我们是不是用咖啡因构建了一个不适于我们生存的环境？
• 咖啡因适于那些需要警惕性的工作。
• 相对于完全放松休息十五分钟对人的效果来说，咖啡因就完全不值一提了。
• 良好的睡眠可以提升效率、情绪、警惕性，而且效果比咖啡因带来的效果更为持续。
• 咖啡因可以提高人们从事简单任务的效率。
• 要完成复杂的任务，咖啡因能够提升外向性格人士的效率，而内向人士的效率倾向于变差。
• 注射了药物的蜘蛛的表现：
  • 
  • 第一排从左至右：正常（未注射）、大麻、苯丙胺（一种苏醒剂）；第二排：咖啡因、水合三氯乙醛（一种催眠剂）【想干好活，喝咖啡还不如抽大麻呢】
• 似乎我们总是想假定在工业时代适用的方法同样适用于现在……

这个名为“Agility：Possibilities at a Personal Level”的视频，与Linda Rising的另外一个视频“Perfection Is An Unrealistic Goal”正好互为补充。感兴趣可以猛击之。

擅长于管理和组织模式的Linda Rising，总是可以通过浅显的内容，给人意想不到的启发。更多与其相关的的内容，请猛击这里。她的主页请猛击这里（被墙了，上面的地址包含代理，原地址是：http://www.lindarising.org）。