【IT168 评论】随着云计算带来的低创业门槛、大数据潮流的盛行，越来越多的人加入了这场创业风暴。然而众多的淘金者中，真正满载而归的却是少之又少。这里为大家分享 HighScalabilty创始人Tod Hoff结合南极穿越之争带来的成功软件架构经验，及成功团队需具备的一些特性。

　　每个软件打造的核心都存在一次漫长的探险，或许你会觉得夸张，但是在 皇家卑诗省博物馆参观Race to End of Earth(罗威探险家 Roald Amundsen和英国海军官员 Robert Scott于1911年-1912年完成的 穿越南极之战)展览时，两支队伍采用的不同途径让我备受启发——那些同样存在于软件开发过程中决定成败原则。

　　我希望我可以重现参观时的体验。随着参观的进行，我不断的对Scott的选择产生质疑，并叹服于Amundsen的老道，其中核心直指开发的两个极端Agile(Amundsen)与Waterfall (Scott)。

　　首先我们看两个比赛的背景知识

　　简而言之，率先抵达南极的队伍获胜。两个领队以完全不同的途径去完成这一目标，方法源于他们不同的目标、经验以及气质。比赛的结果是 Amundsen比Scott早33天抵达，同样队伍的状态上Amundsen更是远胜Scott。归途中，Amundsen队伍无损，而Scott小队全军覆没。

　　1. 单一的目标

　　这点让我感受颇深：Amundsen唯一的目标就是以最快的速度抵达目标，而Scott则要兼顾科学研究。

　　对于Scott来说，科学研究这个使命甚至优于资源与人员配备。而Amundsen的所有目的都是赢得比赛，还有平安归来。

　　想比之下Scott的双重目标存在很多矛盾。不错，那时确实不乏悠久的帆船科学研究历史(比如达尔文)，然而达尔文并不是进行比赛，他们的船很大，同时科学研究只是附加目标，而环境也远没有南极那么恶劣及荒无人烟。

　　Fred Wilson在谈专注的力量时 经常引Steve Jobs为例——“我们专注于打造一个适合所有场景电脑的生产线，然后逐渐关闭其它的生产线”。专注是类似Minimal Viable Products及 time box scheduling产品背后的原动力，Amundsen专注在比赛上，所以一切策略都以这个为目标展开。

　　2. 使用简单，已被验证的技术

　　比赛中最难以接受的就是Scott的计划选择了一组复杂且未经验证的运输技术。

　　Amundsen的计划是简单的，他们选用狗拉雪橇;而在那时，狗拉雪橇的这个技术无疑是得到论证的，因此奇怪的应该是不选用狗的人。

　　然而在早先的旅行中Scott对狗有着非常不好的体验，所以他并未选用这个运输途径。取而代之的是，Scott选用了motor-sledge， 这是机动雪橇的早期版本。在那个时候，这还是个试验中的技术，最终3架motor-sledge都在途中损坏。然而当下的问题不是讨论他们为什么有那么差 的体验，而土著人民却非常善于用狗，而是缺乏对事物的详细了解并往下定论。

　　小马的任务是搬运补给，但是很小的蹄子让其不能胜任工作，因为它很容易受到潮湿和冰冻的侵害。9匹小马在旅行开始时就失去了作用，然而马和motor-sledge的补给只能储存在船上。对比而言，狗无疑更适应战场，它们可以吃南极洲捕获的企鹅和海豹肉。

　　使用人力拉沉重的雪橇，本来只作为应急，但是马和motor-sledge的缺失让这个方案执行了3/4的旅途。而雪橇还在不停变重，因为沿途他 们不得不收集一些岩石以作科学研究。这样，问题就在于他们根本没有足够的食物以支撑整个过程。他们并不清楚，一天吃4000卡路里的他们却需要消耗 6000到10000卡路里的能量。

　　3. 定制、测试、重复

　　Amundsen的计划很周密，不留任何漏洞。当他发现设备达不到需求时，会自己动手，他亲自做了防风镜、滑雪板、犬绳及肉干。这种自力更生正是开发者需要具备的品质：

　　所有Amundsen的工具都出自自己的工坊，并经过一次又一次的提炼。Amundsen在制造工具时使用了两个信条：第一，远甚于批量生产的设备;第二，参与制造，可以确保设备在比赛中的表现。