Liv Wild：一种高效的项目启动方式——QuickStart

一种高效的项目启动方式——QuickStart,该方法用以确认在项目开始之前理解项目的关键驱动因素。来自ThoughtWorks英国分公司的Liv Wild为现场观众介绍QuickStart的理念与实践。

主持人：有请Liv Wild做主题演讲，演讲的题目是“一种高效的项目启动方式——Quickstart”。

Liv Wild：今天下午我要谈的是需求的收集，特别会谈到敏捷行。希望跟大家有个交流，希望大家下午玩儿的愉快，如果你们有问题的话也可以问我。首先做一简单自我介绍，然后会谈需求由谁收集我们的客户是谁？谁来做需求分析？在敏捷的环境里面怎么结果需求的收集，接下来是ThoughtWorks如何帮助你们也效的在信息通信项目里对信息进行的收集。

　　我有八年咨询工作的经验，过去为一非常大的纽约软件咨询公司工作，我是一个软件开发员，后来做业务咨询，现在在投行、金融、零售等领域做咨询服务。另外我也参与过很多项目，都是数百万的这样一些项目，另外还有一些ICT的管理和电子政务的实践应用等等。

　　我们的工作都是非常有效的。来到ThoughtWorks之后我的这个团队的这些人就是想有更好的数据收集的方法，我们今天早晨都谈到了ThoughtWorks，我们是一个全球的业务服务企业。我们在全球有700名员工，下面是列出了财富500强的公司客户。

　　过去30年ICT领域总结一下经验：首先要知道用户的需求，把所有东西写下来找个人签字，然后严格执行我们的计划，所以进程一开始大家把需求进行评估。我们看到在美国、欧洲有一些非常有意思的ICT的项目，有个非常有趣的例子，比如美国的丹弗机场有一个行李自动吞吐的系统，这么高级的只有一个机场利用它，很浪费。美国的一个这样的系统是花了3680万美元，拖延了三年才完成，英国也是一样我们有一个国家航空交通服务系统，就是空气航空交通的。是96年上马，准备花3.5亿英镑，但是最后花了差不多6亿英镑。我们要想为什么有这些问题呢？项目收集需求方式重要的是没有帮助大家满足这样的要求，在这样的项目中我们是过去瀑布式的开发方式，软件要进行分析、设计、测试最后实施，最后发现撞车了。我们的需求是只是在项目开始收集一次就完了。横向是一个时间轴，时间非常长，根本无法反应客户真正的需求。如果有一万个需求，你怎么理解这么多呢呢？对于一个人来说很难理解真正的需求到底是什么？

　　看一下敏捷如何处理需求的？这是一个时间轴、分析、然后设计、然后迭代1、迭代2。分析和设计在整个项目过程中都是贯穿的，贯穿于整个项目生命周期中。最后要想有一个“新车”的就真的能做出一辆“新车”。（演示）这个案例是帮助客户首先了解需求，但是没有很好的解释我们的需求从何而来？首先客户是谁，谁来确定这些需求？我们所称的客户是有共同意愿的个体或者群体，他们告诉我们程序员软件怎么写？他们可以确定一些功能，并且解释为什么这个功能是必要的。然后可以把这个功能进行量化，每一个需求都对它的业务有价值贡献。并不是永远都可以把功能能够量化，当然你还是可以努力去量化，实在没有量化也没有办法。我们的客户应该在项目周期里腾出一些时间和开发团队进行交流。

　　当然不能非常清楚的解释我们在一些业务流程中的一些问题，我们在业务开始的时候要考虑业务有多大，作为咨询公司我们要问自己是不是有资格解决这样的问题？或者说我们愿不愿意解决这种问题，很可能这种问题它不符合我们的理论，很可能我们也没有什么特别的能力去解决。另外，你如何找到解决的方法？是不是现在有想法，有了想法怎么融入进开发中。我们刚才谈的都是故事，我们要谈客户的故事从哪儿来、成本是多少、要花多长时间，解决方案交付结构式什么样？如何让大家改变自己的思维方式？如何与客户建立初期的关系？对我们ThoughtWorks来说我们要管理好与客户之间的关系是非常重要的，这有利于我们咨询工作的展开。当你听到敏捷行的话，很可能都听不到BA，我们是谈客户和开发者。我就是一个BA，我每天干什么呢？我从来不与客户交流，因为对中国客户来说好像不愿意花太多时间根据我们倡导的模式跟我们交流，他们每天都有自己的事情要做。我们希望他们能抽出时间跟我们交流。BA希望客户时间能够花的物有所值。我们要从客户这边知道为什么开发这个软件？我们要确保我们的客户知道自己到底要什么而且明确的表达。即是过程中根据我们的分析，他们改变愿望，产品最终符合需求。敏捷行有各种各样的方式帮助客户参与到我们的开发过程中。它和传统的方式相比有很多优势，我们BA是帮助客户了解有什么样的问题，然后帮助客户解决这些问题。这就是为什么我们ThoughtWorks把信息收集的方法叫快速QuickStart。QuickStart是为了了解需求从何而来，它是用敏捷行提供一个项目产品，把项目规模处理好，要建立项目的需求关系，要确保这项目是有最大成功的可能性。

　　所以我们个Quickstart方法优势，是它完全反应业务真正的需求。有时候项目初期的需求和最终的需求是不一样的，我们是可以解决这个问题的，作为业务本身来说我们要了解好问题和解决的方法。我们在不同的项目中可能大家都有自己的想法，对解决方案的想法也不一样，所以他们应该共同分享对不同问题的看法，这种理解也是共享的。与实施项目的人是共享的，比如说IT部门。对需求来说就是要看需求如何符合业务的价值，敏捷是能够很好的促进这种理解并最后加以实施。每一个需求是与某种业务目标能够关联的，也就是说不仅仅是IT做什么就做什么，而是每一个需求都是功能驱动的，都可以满足某一个特定业务的目标。作为Quickstart还有一个快速接触的功能，就是分析阶段非常迅速大家都可以参与其中，都可以理解他们要做什么我们有一个坚定的基础最后把项目交付。各种改变我们都是拥抱改变的，这些改变都能够整合到过程中，这种改变还是受到大家鼓励的，这就是我们项目的开始。

　　有些业务项目常常有这样的情况，我们的业务员工、IT员工和用户他们很可能互相都不交流也不关注，大家也不是特别友好。他们之间是对抗的关系，而且他们的沟通也是有缺陷的，这样最终对用户来说是一个大麻烦，最后不能拿到自己想要的产品。Quickstart可以帮助改变这种关系，把瓶颈消除，最后都能更好的交流，来自业务，IT和最终用户能够协同合作。最后所有的相关方都有一个共识，互相都可以了解对方的需求是什么。我们看一下Quickstart到底是什么样？它是包容性的，也是合作型的，我们有很多讨论会，有来自于IT部门和最终用户的代表，他们都能达成共识，同时也是能快速实现的。Quickstart一般来说花四个星期的时间，四个星期之后大家都有共识了我们这样做速度是非常快的，我们不一定要有非常快的交换。如果大家有改变的想法必须要告诉我们，我们的模式是互动性的，也是非常可视化的，不是通过文本来做的。另外我们也经常用图片，这样就更加有互动性。我们讨论所有东西在成本上都有关注。也就是说来自业务的人们他就会告诉我们他们需要的是什么，来自我们开发部门人会说，这么做需要什么样的成本等等。我们做出的都应该是合理的决定，这些决定取决于我们的业务到底是什么，这么做的成本是什么？这是前期的分析。前期的分析和过去的瀑布模型的开发方式是不一样的。

　　我们是持续的进行贯穿项目周期的分析，这是Quickstart的特点。（图）这是工作的场景，可以看到都是由故事卡片组成，（图）这是我们的例行会议，客户讨论他们的需求到底是什么，然后我们有四个礼拜，每个礼拜末都有最终展示，最后有一个终极展示。我们差不多每天都有一个展示，这样能从客户那边获得他们的反馈。

　　Quickstart它是可以量身定制的，你可能有自己的想法随着你对问题理解的改善很可能把原来的需求改变，开始的想法和最后的初衷可能完全不一样。我们是拥抱这种改变，也鼓励这种改变，我们希望大家解放思想，不是简单的重复已经有的系统，而是要进行创新。我们每天都要讨论和研讨，每天也只有在今天工作完成之后通过讨论才能知道我们明天要做什么。

　　而且在工作讨论中我们将会对内容进行修剪，并且保证我们用的分析方法是最适合我们的需求的。这样可以保证工作人员能够使用这些工具。尤其是我们看到了如果用以前非常传统的需求收集工作的方法，不太适宜不断变化的情况。我们必须要把这种业务的价值体现出来。这就必须在每一次做总结的时候都有一个产品出来。大家可以看到我们有一个项目，而且我们有每一个计划的出台，希望每一次开始的时候都非常迅速，对所收集到的信息进行分析和进行再一次的处理。最后我们将会进行回顾。然后再开始第二次反馈，对于上一次的结论进行评价，评价以后对有用的信息留下来，为下一次交流做铺垫。Quickstart它实际上并不是完全的替代分析和设计，我们所做的迭代式的分析没有一个现成的发展规划可以提供。分析过程中不断有新的需求出现，所以每一次都是反复实验之后得出结果，在根据这个结果做下一次实验。我们第一次迭代中出现了一些问题，新的问题可能会加入我们的故事卡中。Quickstart是以模式为基础的，人是有不同的思维模式的。比如说这个人想的模式跟另一个人就不一样，当一个人对某一件事情进行评述和描述的时候可能和其他人的描述方式不一样。即使读同一样的东西表达方式也是不一样的。我们要做的事情就是在图表上或者在黑板上写出来他们对此问题的看法。或许这些看法是不一样的，但是在板子上所表达出来的内容是有一种更好的集中性，而且会经过反复实验将最终的共识能够表现出来。

　　我们现在所使用的模式都是基于Quickstart，我们是基于一些优先项目目录进行的，并且还有一些构架式的模式作为基础。我们在这种投资的时候必须根据优先项目进行优先投资。而且我们这种原形也必须要反映这种优先。写编码的时候也要表现这种模式，因为每一个模式都在不断的变化和更新。所以做更新的时候有不同的方法，每一个模式都会随着要求的改变而不断的改变。首先从业务角度来看，首先有一些目标，这些目标是什么，比如说呼叫中心我们的目的就是每一个迭代周期之内要非常明确我们的目标是什么，把这些目标优先的项目列出来。

　　还有我们也有一些业务个案，这些个案可能使用的是比较低容量的渠道，这是一种金融的模式。我们在这个过程中会区分出低层次和高层次的分析过程，这种分析的过程都包含了一种优先效能的体现。尤其是我们的目的在不同的层次上都会有体现。时间上也有不同的要求。这些都是在功能上的需求，而且对每一个案来说要求都是不一样的，甚至时间的要求都不一样，我们做的时候这些需求都要列出来。从开发者角度来看我们必须把所有的这些层次连接起来，而且要了解每一个要求和某一个业务目的都是息息相关的，不是孤立的。

　　Quickstart中通常是这样做，要列出我们的要求，低层次故事的要求，同时开发者有没有什么特殊的需求，同时要找到项目本身如果要完成有个性化的需求。这种分析并不是传统的分析，也不是我们经常做的方式，因为有不断的变化，只有变化是不变的。如果我们一开始就做了大量的话也许最后是一种浪费，所以是在变化不断过程中进行分析。尤其是高层的运作过程中我们必须有一个明确的目标，当目标不变的情况，也许情况发生变化我们也不会改变初衷。而且必须了解这个层次中有什么样的限制？我们同时在整个过程中也会出现迭代情况，我们所使用的举证应该是体现一种价值。我们的能力是可以拓展到哪一步，应该从哪个角度拓展都应该要考虑到它是否能体现更多的价值。

　　Quickstart并不会做特别大量的分析工作，所以我们要不断的进行讨论。而且我们进行小组的讨论和分析工作是非常具体的。我们也可以将现在所使用的分析功能或者分析手段用于下一步，但是分析的功能也是不断变化的。我们也要进行最后的审查，比如说商业目标是否达成了？验收项目成果，然后看一下这些优先目标是否得到了体现？我们的路线图是否能够更好的得到体现和遵循？当我们的产品出台的时候我们所要做的并不是项目本身是否完成，而是项目它本身的要求和目的是否得到了体现和实现。还要非常清楚的看到目前的现状和今后可能会发生的变化。尤其是有些项目是跨越一些领域的，在整个过程中也许每一个步骤和每一个分析功能是特定的，不可能做长远的拓展。所以这种迭代的过程是非常复杂的。还要有一个非常好的架构模式，尤其是使用高效率原形体现的时候，可能在现实生活中我们编程人员面临着非常具体的工作。但是，我们所使用的技术有些时候可能不适于消费者真正的需求，所以要做的就是先把技术放一边，先看客户需要什么？尤其是我们还要分析一下主故事链或者故事目录是哪些？然后才能找到最重要的需要花功夫的地方，最后运作出一个非常高层次的计划。也许我们不可能在很短时间内把所有的项目和要求得到满足。但是我们是在不断的变化过程中的，而且这总比花很多力气在一大堆文件中分析更好，因为人们的判断是非常短期的，尤其是短期的价值或者它的期待值和一开始所做的分析以及其所获得的结果是不一样的。我们能够提供什么样的服务？比如说我们有很多文件，我们就必须运作出一个业务模式。然后进行一个小结，就是我们最主要做的工作是哪些，如何保证目的能够达成。如果没有达到的话我们就必须做一个决定：是否这个计划应该按原计划进行下去？比如说一个业务的流程，在过程中我们必须确定有哪些会参与其中，他们的需求是哪些、限制是哪些，然后画一些列表出来。这些需求目录列出来以后可以看到了哪些是主要的，哪些是次要得？谁做这个工作呢？我们经常所做的就是由客户和核心小组对分析进行收集和整理，比如我们有BA、QA和开发员，每个人都各司其职，每天都必须要做分析的工作和协调工作。还要在整个运作过程中必须要做一个协调，每个人对自己手上的工作都必须非常明确，BA、QA、和开发员要有很好的沟通。我们可以让BA保证这些需求能很好的互通，每个人都了解自己的工作是什么。当然我们还有一个领域专家，这个领域专家要知道自己说的是什么，也要知道这个项目的走向。比如每天工作八个小时，八个小时之内每个人工作要达到目的是什么，每天结束的时候工作目的是否达到？中午休息的时候也许他们还可以进行进一步的交流。我发现这种沟通的方式能够让组员不断的知道什么叫敏捷？过程中也许有一些技术性的问题，他们也可以在谈话的过程中进行解决和磨合。

　　项目的工作人员他们有些时候对某些方面持有固有的想法，但是这种固有的想法可能比较偏激，如果要进行全面的沟通，做评估的话就可以知道具体磨合这种偏激要花多长时间，工作中的每个环节，每个星期要花4个小时进行沟通。Quickstart是什么意思？这是一个时间表，表示了Quickstart的走向。它们进行定期的会议，每天早上从10点钟开始，之后整个早上他们都会看自己要做什么，而且在中午吃饭的时候何以选择这个进行进一步的交流。每天下午的时候他们都要对当天的工作做一个回顾，保证工作流程非常速度和无障碍。来自业务的这些工作人员也可以参与其中，这样在整个过程的最后可以得到令各方都满意的结果，而且每一个展示过程中也可以表现出每一个工作小组的成果，这种小结是非常全面的。

　　接下来有一个核心小组分析工作，下午有一个小组分析。来自业务和技术的人员进行沟通，我们也有一个大家都站着回顾的过程，时间非常简短。这意味着我们的工作不可能做到每一次都非常迅速，但是这是我们的目标。我们必须了解消费者的心理、客户的需求，这是最重中之重的地方。谢谢，最后看一下大家有什么样的问题？

问：您刚才谈到需求是不断的更迭，我想请问在敏捷设计方法里，需求是如何和设计进行相互跟踪的？

Liv Wild：分析和需求是同时进行的我们有技术人员保证他们的设计。在分析中的设计是不断的重复出现的，我们的反馈可能是来自客户的、技术人员的，这些技术人员要非常迅速的零拖延的获得这种需求，从而保证整个设计过程中需求和分析之间不会出现时间的落差。

问：一般传统的设计方法开始肯定有一个需求规范书，客户最终会根据这个需求规范书验收整个项目。如果说整个需求不断的更迭，什么阶段能形成一个需求的文档供可了解整个系统的状况和验收这个系统。因为对于一个企业级的项目，比如银行项目一个人可能都不一定能搞清楚整个项目，可能每个人只是负责局部，最后整个项目是根据什么来验收呢？什么阶段出需求最终形成和整个需求对应的实际文档？

Liv Wild：我们是确保需求和分析每一个迭代期都在做。没有一个所谓的签发期，每一个迭代期都是要做决定的。比如说在迭代4，很可能和迭代0的时候是不一样的，是互相矛盾的，这样一个周期都是永远自己给自己有反馈。也就是说做决定的时候就应该是正确的决定。

熊节：我们一会儿安排ThoughtWorks中国同事跟大家交流。感谢Liv Wild的精彩演讲！