全文6360字，阅读约需12分钟 

0/ 前言

上一次我们讲的是在进入设计阶段前，在立项环节我们要做好哪些准备以及与团队沟通项目的可行性。现在，就是正式进入我们游戏的开发阶段！在这一阶段我们会不可避免的遇到一些情况，例如程序、美术、策划之间的日常推进项目时的沟通，每天定时的进度站会等等。所以，这里是我新整理到的一些对项目开发有帮助的内容。 

本文处于游戏设计生命周期的：

1/ 敏捷开发（Agile Development）

1. 什么是敏捷开发

在谈论敏捷开发之前，我们应该先了解什么是“敏捷”。同样重要的是，我们将讨论“敏捷”不是什么。

很多事情都被称为“敏捷”，尤其是那些销售们。如果你问卖纸的什么是“敏捷”，他们会告诉你在便签纸上写下用户故事就是“敏捷”。如果你问咨询顾问，你会听到“敏捷”是一种软件开发的方法流程。如果你跟互联网厂商交谈，你会了解到“敏捷”的关键，是开会的时候每个人都要站起来。

但“敏捷”的实际定义其实来自于「敏捷宣言」，该宣言明确指出“敏捷”不只是一种方法论，也不是开发软件的具体方法，更不是一个框架或一个过程。事实上，大多数宣称自己的是“敏捷”的东西，实际上并不敏捷！

“敏捷”是一套价值观和原则，围绕着敏捷的大部分讨论，都与以下事情有关：各种理论方法，甚至特定的敏捷开发软件。尽管这些东西可能会帮助一个团队建立起“敏捷”的概念，但这些方法和工具本身并非敏捷。例如，虽然一个团队可能认为每日站会应该很有帮助，但之所以有这种开会形式只是因为团队遵循了“敏捷”的原则和价值观。

当你明白这一点时，就很容易看出敏捷实际上是一系列理念。在软件开发过程中，团队可以用这个理念来更好的做决策。这意思是指，当我们提到敏捷的时候，大家会提到这样或那样的方法，这其实恰恰让敏捷偏离了本质的含义。不过，如果你真的明白了敏捷是什么，就会发现敏捷用起来其实非常灵活。敏捷并不会为你做出决定，但恰恰相反的是，这一理论帮助了团队在开发软件的过程中树立了一种优质的决策原则，从而让团队有开发出更好软件的可能性。

2. 「敏捷宣言」

敏捷宣言只有68个字（原版英文），并且始终遵循一个简单的原则，即只需要让左侧的原则比右侧更受认可我们就能更好的开发软件。

在敏捷宣言中它是这样说的：我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下的价值观：

也就是说，尽管右边的各项都有其价值，但我们会更重视左边各项的价值。

除了宣言之外，这里还有12条需要遵守敏捷宣言原则。当然，这些原则也都是具有普适性的，它们不会告诉你具体怎么做，而是让你能够在特定情况下做出正确的决策。这些原则是：

1. 我们最重要的目标，是通过持续不断的及早交付有价值的软件来让客户满意。
2. 欣然面对需求变化，即使在开发后期也一样。为了让客户获得更多的竞争优势，敏捷开发的过程中需要面对各种变化。
3. 经常的交付可工作的软件，相隔几星期或一两个月。当然，这里我们应该更倾向于采取更短的周期。
4. 产品与开发人员必须相互合作，在项目开发中的每一天都不例外。
5. 激发个体的斗志，以他们为核心搭建项目，并提供所需的环境和支援，给予他们足够的信任，从而达成目标。
6. 不论团队内外，传递信息效果最好同时效率也最高的方式是面对面交谈。
7. 可工作的软件是进度的首要度量标准。
8. 我们在敏捷开发的过程中应倡导可持续开发。负责人、开发人员和用户要能够共同维持其步调稳定延续。
9. 坚持不懈的追求更卓越的技术和更良好的设计，这也将增加团队的敏捷开发能力。
10. 一切以简洁为本，毕竟这是一项关于极力减少不必要工作量的艺术。
11. 最好的架构、需求和设计往往来自于有良好「自身驱动力」的团队。
12. 开发团队也应该定期的反思如何能更好的提升效率，并以此为依据调整各组员自身的举止表现。

由于敏捷开发是套价值观和原则的集合，所以它实际上是人们开发软件时做决策的最好基础。例如，我们可以想象一下，一个新的项目正在讨论如何从客户那边获得需求。一般常规的做法是在正式开发软件之前，让产品经理写下所有的需求。但一个“敏捷”的团队应该会想到：“虽然这样看起来也是行得通的，但这是我们的价值观吗？即“客户合作 高于 合同谈判”？ 这样做是否违背了我们的原则，即开发人员应该每天与产品经理一起工作？我们如何以符合我们价值观和原则的方式做出这个决定”？ 或者我们可以想象另一种情况，一个从程序员正在为客户开发一个产品功能，但程序员在开发过程中发现他需要一个数据库才能实现该功能。他的程序直觉告诉他应该先暂停该功能的开发，并优先构建一个强大的数据库功能，这个数据库将为新功能的开发提供了必要条件，同时也可以为以后其他的功能开发提供支持。但如果这个程序员信奉敏捷的价值观并试图遵循敏捷的原则，他就会想到：“构建新的数据库意味着这个软件的价值将不得不延迟交付给客户看到，如果我能找到一种方法来搞定开发此功能所需的要求，那么这个方法会更好的符合我的原则”。

3. 不要陷入敏捷的误区

当你的团队都在遵循敏捷的原则时，他们每周都会按照这种思维来做出数百项决策，这才是敏捷真正带给你的价值和意义。

在做每一个决策时，都要让团队遵循敏捷的原则和价值。这样的决策过程很重要，因为你不能总是指望着通过别人的决策来让事情变得简单，而你只是像个工具人一样盲目的执行别人的决策。

只是简单的去模仿其他团队的行为和做法并不会让你的团队更敏捷。这里我也想到一个很经典的故事，在太平洋战争之后，美拉尼西亚群岛的土著们想起了在战争中看到运输机空投补给品的景象，于是他们仿造了一个完整的飞机场，希望某一天也能有运输机投放补给品到岛上。他们砍掉森林，并使用稻草铺垫地面，制作了一个标准的飞机跑道。他们甚至还用竹子制作了一个类似塔台的建筑，并让同伴坐在里面戴上用椰子壳制成的耳机等待飞机的到来，最后的结局你也可以猜到，他们什么也没有得到。所以当谈到敏捷时，大家很容易产生这样的模仿行为，因为你很容易看到强大的敏捷团队是如何工作的，但是他们的工作方法是遵循敏捷原则和价值观的结果，他们在用什么方法工作并不重要，重要的是要去了解他们为什么使用这些行为？

事实上，随着时间推移，一个优秀的敏捷团队可能会改变和完善他们在用的做法。例如，一个团队可能一开始在使用“Scrum”模式，后来发现“看板”才是一种更好的向客户交付价值的方法；一个团队可能开始的时候每天都要站立着开会，但后来还是决定让所有人都坐着，因为坐着开会的效果更好；另外一些团队还可能先使用计划扑克(Planning Poker)来估算用户需求的开发量，后来决定不再看用户的整体故事，而是简单的将用户故事分割成几个大致相同的开发量。当然，这并不是说了解那些优秀的团队是如何实践没有用，但你不能直接让你的整个团队去套用一个所谓的“敏捷模板”，你必须找到那些支持敏捷原则和价值观的操作并告诉你的团队，只有确实遵循了敏捷原则和价值观才能让团队真正的实现敏捷。你选择的实践操作方式将决定你团队的敏捷与否，如果你选择了某种做法，是因为它好像遵循了敏捷原则，这看起来就是一个不错的开头。但如果原则是错误的，即使是一样的实践操作也并非会带来好的结果。

所以这里最后让我们来总结一下敏捷的主要概念：

• “敏捷”到底是什么？——敏捷是一套价值观和原则；
• 怎样成为敏捷的团队？——遵循敏捷的价值观和原则来做决策；决策的过程就是成为敏捷团队的秘诀！
• 敏捷的价值观和原则足够普适，可以让不同类型的公司和团队根据自己的情况来设计如何开发软件，并提供清晰的方向来帮助团队发挥最大潜力。

4. 板块(Scrum)与看板(Kanban)

4.1. 什么是板块(Scrum)

首先，我们先来看看Scrum与传统瀑布式开发之间的区别。瀑布式开发通常会花几个月时间来规划产品，然后再花几个月时间研发产品，接着进行产品测试、评审，最终发布产品。

重点是，如果市场需求或技术环境发生变化，你此时研发出的产品很可能无法满足市场需求。瀑布式开发在遇到这种变化时会出现很多问题。首先，产品规划必须早于后续工作之前完成，但在绝大部分案例中，大多数人在规划环节结束时并没有完全理解项目，但研发工作就已经开始或完成了。通常情况下，遇到这种问题必须把整个项目送回规划阶段，然后从头再来，否则研发人员就会因为不明白产品规划而受到批评。并且同样的问题还会反复出现在后续阶段，比如产品研发完成了，进行后续产品测试，这时发现问题的话也得重新开发，有时甚至要重新规划产品。这很可能导致产品发布时间跳票，短则几个月，长则数年。

当我们使用Scrum来实施敏捷开发时情况就大不相同了，因为整个项目会被分解成不同的小部分。首先，我们要围绕最小化可行化产品的特性进行产品规划，然后把最小化产品开发出来。接下来，我们测试和评审这个产品，直到准备发布。循环这整个过程，我们就会得到一个可发布的产品，这个过程通常只需要1~3周左右。我们不断重复这个过程，以减少从产品规划到开发测试每个阶段的时间。让我们有足够详细的规划来完成下一个增量式发布，而你此时得到了几个增量式版本，我们通常称为Sprint（冲刺），一个Sprint通常需要一到三个星期，而你只是不断重复Sprint直到你的产品功能齐全。有时你可能会在第二次Sprint之后，或者第三次、第四次，甚至更久的时候，最终构成你的产品。但不过怎么说，最后你有了一个可发布的版本。

另外，在Scrum中有三种常用的可视化文档。第一种文档是，产品需求列表（Product Backlog）。产品经理会先从众多用户故事中筛选出优先项，并把它们列入产品开发列表中。需求列表会随着每次的Sprint而产生迭代和更改。用户故事，是一种表达产品需求的语言格式，格式为「作为一名____用户，我需要____功能，所以____能够」，产品经理通过用户故事来了解需求的细节，为Scrum团队合理制定任务的优先级。先将最优项的用户故事放入Sprint代办列表中，再继续评估剩下的任务优先级，交到下次Sprint中。燃尽图（Burndown Chart），用以展示整个Sprint代办列表的进度，当燃尽图曲线接近于0时，也就意味着这次的Sprint即将完工。

所以简单来说敏捷Scrum的工作框架就是首先由客户和干系人提出需求和想法，授权由唯一一位产品负责人带领其他需求分析人员，将这些需求梳理和排序并形成产品待办列表，建立统一的产品目标。然后在Sprint计划会上，开发者们创建Sprint待办列表，定义Sprint小目标，并对任务拆解和分工，形成短期的工作计划。然后开发者们在固定长度的时间盒（Sprint）内进行研发工作，并且参加每日站会来检视并调整工作进度。同时ScrumMaster帮助团队聚焦于最高优先级工作，帮助团队成长。同时在Sprint末尾，该产出应该是潜在可交付的，符合完成的定义的产品。最后整个团队举行针对产品验收的评审会和针对过程改进的回顾会，分别在事和人两个维度进行反馈，以便前置风险，平衡组内信息管理。接下来大家选取下一个Scrum工作项，如此循环往复便算是一个完整功能的流程了。

4.2 什么是看板（Kanban）

Scrum讲完了，我们来看看什么是看板（Kanban）方法吧。看板不像Scrum有那么多的条条框框，它看起来非常简单。首先是看板中没有迭代的概念，也没有Scrum开发团队中固定的成员角色，更没有Scrum中要求的种种仪式。

看板最注重的两点是，可视化工作流程和限制在制品的数量。通过这两点来保证团队不会超负荷工作，也能增加团队完整的完成一项任务的效率。看板对比Scrum最大的变化是其核心——“灵活的响应变化”，即不需要等待本轮迭代周期完成后才进行功能的新增、删除和修改。开发团队通过可视化看板，随时更新目前的需求进度。如果有一个环节的工作量少于应该有的预期，我们就得去上一个环节拉需求，这样一个一个将需求从流程的左端拉到右端来完成整个任务。为什么要这么操作呢？这里就需要提到在制品（WIP，Work in progress）这个概念，在软件或其他项目中，在制品指的是所有正在进行的，还未交付的任务或产品，需求明确的是，在制品占用了资源，但却并未形成价值。限制在制品的本质，其实就是控制资源浪费。过多的在制品不仅阻塞了流程，更表现出整体上资源的浪费；过少的在制品又反应了产能的闲置，需求端的供应不足。在完成以上两点之后，看板项目里还需要留出一定的空闲时间（Slack time）,完成任务之后留给自己一些自由时间，去处理一些优化的小任务，解决一些紧急的小BUG，帮助组员处理一些阻塞的小问题。这些事情远比一个新的任务要重要的多。

看板里面最核心的一个字就是流（Flow），任务像河流一样在看板上从左向右流动，如果有环节阻塞了那就需要大家一起来疏通；如果有环节干涸了那就需要从上个环节引流。所以在了解完看板的概念之后，其实际应用也很简单。

1. 整理项目的流程——例如，待办、设计、开发、测试、发布、完成
2. 可视化任务——用便签纸把任务放置在对应的流程下面
3. 设置在制品限制——例如在测试环节WIP不能多于3个，在设计环节WIP不能少于3个
4. 扩展流程——增加各大项前的预备环节作为需求池，例待开发、待测试项

4.3 Scrum与Kanban的好处

先说在前面，这里讨论的两种方法，无论是哪一个都没有绝对的优劣之分，更没有对错之分，有的只是我们对该理念的掌握程度，如何选择还是得根据实际情况来定。当然，这里的实际情况也主要是以团队技术水平，团队凝集力和项目愿景（Vision）为立足点来分析的。技术水平和团结程度这个这两个点当然是每个团队会有自己的思考在里面，剩下的项目愿景也是唯一一个较为客观的可分析的点。

愿景一般也指客户或者老板清楚自己要什么，我们的OKR或是KPI是什么，是创新型产品还是服务好客户？这里就说到选择管理框架的第一个维度，我们是创造（Build）还是服务（Support）。如果让团队专心实现一个新产品，那么Scrum就是一个好选择；如果团队灵活相应客户的需求，那么看板则是一个完美的好工具。举个例子，公司决定推出一个战略级产品，并且产品的目标很明确，我们需要配合市场部门调研的结果，在明年情人节当天推出市场。这样的情况下Scrum会是个好选择，产品每个迭代的目标非常明确，日期也很确定，团队能够自组织迭代、反馈、调整，也能把握住整体开发的节奏。另外一个例子，团队为一套平台产品提供产品维护和升级服务，用户的满意度将作为最重要的参考指标，但产品的目标并不明确，我们只要能够平稳的运行同时用户满意就好，这样的情况下看板会是个好选择。因为灵活相应也是满意度的一个重要维度，团队不需要自组织，只需要保证好任务通畅流通就好了。

所以我们初略的总结一下就是：

Scrum：

• 如果创建目标明确的新产品
• 如果拥有更多自主权，保证开发不被打扰
• 如果可以持续创新或熟练设置目标

Kanban：

• 如果产品目标不明确，属于支持维护的话
• 如果无法对项目做最终性决策
• 如果对每次迭代的目标不清晰

上图只是一个粗暴的区分方式，真正的敏捷理念是一个需要长期培养的技能，理念到位了，工具的选择其实并不重要；同理，如果理念不到位，不是换某个管理框架就能解决根本问题的。

2/ 结语

本来像一口气把本周的所有内容全部都讲完，但结果才刚把完敏捷开发讲完就发现已经洋洋洒洒写了6k多字了 

所以为了避免文章过长导致的阅读不便，就将Week2的内容便拆分成上下两章吧

下篇的内容主要包括游戏团队中的各个角色职责，我们为何游戏的基本理论，以及一些团队制作中需要注意的特别问题

那么本篇也就到此先结束了，我们下篇周记再见   希望本鸽子能早日肝出下一章