组织结构

在游戏的开始先将每摞牌洗匀并让玩家了解它们。在整个游戏中会使用4类牌：

编码牌：这是最容易识别的牌，因为牌的后面被涂了颜色，一半蓝一半红。这摞牌包含所有玩家会在其软件项目中使用到的代码牌。

文档牌：小一点的一摞牌，这个包含蓝色空白或红色并标了“不清楚”字样的纸牌。这些牌将放在玩家们的中间。

项目牌：这摞牌仅有9张并有唯一的，相反图形。当开发项目被选择之后，实际上就能放到一边了。

主牌：这是最大的一摞牌。它包含所有剩下的牌，它们被标注了“设想”和“程序员”，还有很多被上了色的“问题”卡。将这摞牌放在玩家们的中间。

稍后在游戏中，当需要废弃某些牌的时候，将那些要废弃的牌面朝上放在它原来所属那摞牌的旁边，成为一摞废弃牌。

重要：在游戏过程中任意一摞牌如果用完了，玩家们需要将那些废弃的牌洗一下，然后重新使用。

游戏开始的第一件事就是在项目牌中随机选出一其中的一张。这个项目将会是两个玩家比赛中使用的项目。将这张牌放在两位玩家玩牌区域的的中心地带。其他项目牌暂时不需要了,可以放在一边。牌上的项目信息在牌的两端都有显示，所以面对而坐的玩家都能清楚了解项目的要求。这些信息很重要，包括：

复杂性：这是一个程序员做出一组好的代码所需要的时间点（time points）

长度：这是玩家完成并整合项目所需代码卡的数量。

质量：这表示客户对最终产品的软件错误的要求。

预算：这是你能花在项目上的金费并将成为对你能聘用程序员数量的限制。

在你第一次的游戏中，简单的项目如“臭气收集”(Pong Collection)可能是一个很好的选择。不要担心有些项目内容可能一点实际意义都没有，但他们在之后的过程中将会更细致地被介绍。

当玩家们有了他自己的项目之后，每个玩家在主牌中抽出5张牌（最大的那摞背后没印有蓝红相间图案的卡片）

快速看一下你自己抽的牌。主牌有3种牌：程序员、问题和设想。每种都有几个重要的特征，详细情况描述如下：

程序员

程序员是你项目实现阶段的核心，并且对完成编码和完成工作是必不可少的。有3个属性玩家必须在决定聘请他们前仔细阅读：

当你出“程序员”牌的时候，将这张牌放在你的游戏区域play area[1]面前右下角,你已有的程序员卡的最右边。当你选择任何程序员卡之前请确认你这样做不会使所有程序员工资的总数过于高昂造成超过你项目的预算。

当所有玩家都熟悉这些牌的时候，游戏就可以开始了。年纪最轻的玩家先开始。每个玩家按顺时针顺序轮流玩牌。

瀑布模式

      在问题和程序员游戏中，玩家从左到右排牌来代表通过瀑布模式的顺序依次进行他们的工作。你不必要严格按照这个模式，但是你可以用它作为一个指引。

出牌轮替方法

你每轮的出牌包括5个不同的阶段。在每个阶段里你需要完成特定的工作。包括从摸牌，到使用牌到废弃牌的一整个流程。

你的每轮出牌包括:

1)问题阶段Problems Phase: 这个阶段是你在游戏的前几轮出牌中可以跳过的一个阶段。如果你有任何代码牌，在每一次你轮到出牌的一开始，你将极易受到攻击。任意一个其他玩家都有可能在你进入特定状态的情况下向你出问题牌 。机会是，在最初的几圈出牌里面，你可能还没有开始进行编码，这时候你还可以享受一段安全时间。

2)摸牌阶段Draw Phase:  如果你手上只有少于5张牌，你现在需要补足5张牌。

3)行动阶段Action Phase: 这个时候你需要开展一项工作。这些行动代表典型的软件开发过程中的一些开发工作，将会在下面进行介绍 。

4)玩牌阶段Play Phase: 在这个阶段你可以将手中任意数量的程序员牌和设想牌放进游戏区域（只要你这样子做不超过你的预算就可以了。

你可能已经发现，你在这个轮流出牌的规则下，限制了你解雇和聘请程序员的能力。你可能会发现，从预算空间考虑，聘请一个程序员并让其真正完成他的工作往往需要整整3轮的时间才能够达到。这是有意设计成这样的；因为这样子可以虚拟聘请一个新程序员并让他正常工作的一个过程。
你毫无疑问的会对我们刚才提到的行动阶段感到有些疑惑。在这个阶段里，你可以进行一类行动，你可以选择的行动是：研究需求，进行设计，进行编码，整合源码或交付项目。由于在同一个时间你可能可以进行多项行动，所以按照瀑布模式进行已被证明是最好的方法。
　

在你的行动阶段，你可以选择进行以下任意一个行动:

研究需求Work on Requirements: 使用或替换2张需求卡，废弃一张设计卡。

在这个行动里，你最多可以使用2张新的需求卡。将这些卡面朝上放在你游戏区域的最左边，如上图所示。你可以用失去一次放新的需求牌到桌面的机会来换取将已经放在桌上的需求牌交换还在牌摞里新牌的机会。你如果愿意的话，这个可以进行两次，将两张已经在桌上的需求牌换新牌但是你不能将换回来的新牌出到桌面上。

虽然桌上需求牌的数量完全由你自己的喜好决定，但是你需要记住的是最大数量最好是6张。我们有针对少于一张需求牌的问题牌，也有针对少于2张的，依次类推，在这种情形下，你很容易受到对方攻击。但当你有6张需求牌的时候，你需要担心的就只有还没有被搞清楚的需求了。也就是说，最好替换不清楚的文档unclear documentation，因为他们会使你受到一些问题卡的攻击。

如果你手里有设计卡的时候，你需要使用，也就是废弃其中的一张，来重新研究新的需求。 

进行设计Work on Design: 使用或者替换2张设计牌，废弃最多2张代码牌。

在这个行动里，你可以从文档摞纸牌里拿出2张，将他们面朝上放在任意需求牌的右边，如上图所示 。跟需求里一样，你可以抽一张或两张来替换桌面上的不清楚的文档unclear documentation。 

同样的，6张设计牌应该足够用来防止几乎任何针对设计阶段的问题牌了。如果可能的话最好还是尽量替换掉不清楚的文档unclear documentation来防止受对手攻击。

如果你选择进行这一个行动，并且你有代码卡的话，你必须选择出其中的两张并废弃他们，如果只有一张就只废弃一张。

实现Implement: 创建、检查和调试你编辑的代码。

当你选择了这一个行动的话，每个你控制的程序员将进行自己的工作。一个程序员的技能决定了他有多少个时间点time points ，从而决定他们能做的事。程序员每轮有四项选择，每个选择使用一个时间点time points.。只要有足够的时间点time point，他们能使用任意组合的行为选项。四个选项包括:

•  编辑好程序 (代价 = 项目复杂度)

从代码卡摞取一张牌并将其面朝下放在你要使用的程序员卡前面，并且也要在这个程序员已有的所有代码卡前面。因为这是好代码将牌背面的红色对向程序员的方向。

• 编辑匆忙的代码 (代价 = 项目复杂度的一半，累计)

跟上面一样，但是将蓝色那面面向程序员。

• 检查代码 (代价 = 1 time point)

将你选定的程序员的一张面朝下的代码卡翻过来，注意记得那段代码是好代码还是匆忙的代码（蓝或红对着程序员）如果这张卡是一张Bug卡，这将可能会在项目完成前造成问题（还记得你的质量需求吗？）。 任何被找到的严重的Bug（nasty bugs ）会使其上面的代码卡被废弃掉然后立即被另一张同样质量的代码卡取代。

• 修正一个错误 Fix a Bug (代价 = 1 time point)

这个程序员可以用一个时间点time point来修正一个简单的错误a simple bug。 从代码卡摞取一张新的同样质量的代码卡来代替。一个常规的错误 normal bug 现在就被“修”好了（通过交换其上面的代码卡），或者如果这时最顶上的一张，这个错误将最终被解决掉。 所以进行多次的错误修正来去除常规错误是必须的。最后，记住nasty bugs 一旦被找到，替换它是不用任何时间点的，也不用被修正。Bug可以以任何顺序来进行查找和修改。

修正错误能在游戏的最后符合质量需求时为你创造奇迹。

那么, 举个例子, 一个有4个Skill的程序员和一个有2个复杂度的项目，程序员能：

编两个好的程序（每个需要2个时间点的代价）

编一个好程序并检查2个代码卡 (2 + 1 + 1)

检查2个代码卡并解决2个简单错误simple bugs (1 + 1 + 1 + 1)

等等……

在一轮里面，程序员不用使用完他全部的时间点。

最后，不做常规行动的话，程序员也可以帮助 help。在这个情况下，这个程序员能帮其他程序员编代码，就像做他自己的工作一样。但是每次的帮助行为必须要付出2分的处罚代价。所以，一个四点技能skill的程序员在这种情况下只能做相当于2点技能的工作了。 几个程序员能累积他们的时间点来同时做一个代码卡或进行其他工作只要他们之间有足够的时间点就行了。

帮助行为是唯一会因为解雇程序员而造成影响编程工作的。所以记住一定要保留那些能力强的程序员。

记住，如果你有代码卡，玩家就可以向你出问题卡，所以确认你已经准备好迎接挑战了。

整合Integrate: 将一个程序员的代码卡移至整合列。

在这个行动里，将一个程序员的所有代码卡移入右边的新的一列里，面朝下，如上图所示。这代表你整合了的代码，这将不能再改动，而且将不被任何其他玩家所影响。

注意: 小心！移动时不要改变代码卡的布局，代表好代码和匆忙的代码的牌的布局仍然十分重要，注意卡的正反。

交付项目Submit Project:检查代码的Bug并尝试赢取游戏。

注意: 你只有在已整合完的代码长度与项目定义的产品长度一致时才能进行这个阶段。

这很有可能是你最后一个阶段的动作。将所有整合的代码面朝下（同样保留原来的布局）你现在要洗乱他们的顺序（注意牌的朝向） 你的对手能选择切一次牌。最后按照你的质量需求从上向下翻牌 如果没有Bug，你就胜利了。

如果任何牌翻过来之后是nasty bugs ，你就输了 you lose the game. 这些是能造成产品完全无法工作的严重Bug，这些使得你的客户不愿意接受你的产品。这种情况下，整个项目被取消并无法修补，所以你输了游戏。 

如果发现任何简单simple bug或普通normal bug，这个产品就是有缺陷的，但是缺陷能被修复。在这个情况下，你需要将所有的代码卡放在你选定的同一个程序员的上面 。你可以挑程序员，但是你的对手可以决定你的代码牌排列的顺序 。当然，这个时候你暂时不能交付你的产品了，而且你必须要重新整合那些代码。一点点修复，然后提交会比较好。

出牌轮替方法：

1)你如果有代码牌，对方就会出问题牌Problems 给你。

2)抽Draw 最多5张牌

3)选择进行任意一个行动 action ：

• 需求Requirements: 使用或者替换2个需求requirements cards,，费掉一张设计卡design

• 设计牌Design: 使用或替换2张设计卡，费掉2张代码卡。

• 实现Implement: 让程序员编代码，检查并修复bug。

• 整合Integrate: 将一个程序员的代码牌全部面朝下摆放到整合区。

• 交付Submit: 交付代码并接受审核。

4)使用（出）Play 牌

5)废弃Discard 牌（从桌面上拿走）放进废弃堆。

程序员行动:

你的每个程序员所有的时间点与他本人的技能点相同，这些时间点能被用于:

• 编一段好的代码=项目复杂度

• 编一段仓促的代码=项目复杂度的一半

• 检查代码:1个时间点time point

• 修正bugs:1个时间点time point

Bugs 类型:

• 简单缺陷Easy bugs: 一个程序员需要使用一个时间点来修复这个bug，将这张牌换成一张新的，同样质量的牌，面朝下放在原来这个bug的位置。
• 普通缺陷Normal bugs: 程序员需要使用一个时间点的代价将这张卡与它上面那张代码卡交换位置，直到这张错误牌到达最顶端为止。这个时候这张牌就能被当作一个Easy Bug处理了。
• 严重缺陷Nasty bug: 当这张牌被发现后，它上面的那张代码卡需要立即废弃，并且这张牌被替换成相同质量的代码牌并面朝下放在原来的位置。

• 废弃Discard – 将牌放入废弃堆（放废弃牌的一摞牌）。

• 协助Help – 当一个程序员将他的时间点给他人的时候，需要付出一个罚2点的代价。

• 损失X进度Lose X Progress – 废弃X张你选定对手的代码牌。将其放入废弃堆。

• 好代码Good Code – 如果面朝下的时候，代码牌的红段指向程序员。

• 阶段Phase – 每次出牌轮替中的五个部分之一。

• 匆忙代码Rush Code –如果面朝下的时候，代码牌的蓝色段指向程序员。