博客园_HeroBeast

腾讯资深产品经理谈敏捷开发于游戏

2012-02-09T02:08:00Z

敏捷开发思想谈

敏捷的原则

敏捷开发其实并没有标准型的流程。SCRUM也只是众多衍生体中的一个。实际上就算是SCRUM的实际使用也情况千差万别。所以首先，请大家有这么个概念：

敏捷开发绝对不是一套一成不变的标准化流程。而更多的是一种自适应，自我优化的流程优化理念。

并没有一定的流程，而是需要大家有对任何自己觉得不对的，不正确的，效率低下的事情的警觉性，和将之提出来并进一步改正的行动力。其次，敏捷之于游戏开发，则更要体现人对游戏本身品质的把握，而非对各种文档的审核，这就是和传统软件开发区别最大的地方。所以，没有最好的流程，只要是合适并且能够持续优化的流程就是好的。

所以：

l 不一样的项目经理会有不一样的流程

l 一样的项目经理，不一样的团队，也会有不一样的流程

l 一样的项目经理，一样的团队，每隔一段时间，都还会有不一样的流程。

迭代想与得

为什么我们要迭代？

进行游戏开发，首先请大家对此铭记于心：

l 我们的设计不一定是我们真正想要的

l 文档内容在我们想象中和实际体验版本时的感受不相等

l 我们没法100%的思考到所有需要思考的角落

同样，要理解为什么要使用迭代，我们需要明白迭代开发从何而来。最初，软件开发行业中，一般都由需求方提需求，开发方拿到需求开始分析设计，一次性开发成型交付。随着行业的发展，软件复杂度的增大，需求变化的增加，大家发现一次成型的版本往往无法满足需求方的需要，于是返工。当这样的情况多了之后，返工就成了一种标准化的流程，系统化的返工其实就是我们所谓的迭代了。当然这是一种比较民间的解释，但是在游戏产业中，这也说明了：

l 迭代的目的是为了应付需求的变化。

这里的需求变化需要我们的额外注意：

l 游戏产业中的需求变化，并非只是指策划或需求方在中途站出来说自己的想法有变。更多的时候，是自己在进行游戏开发的过程中，出于对开发的游戏的认知的加深产生的需求设计的变化。一般来说游戏的需求来源于设计，但是我们的设计却往往并不是我们真实的需求。或者说，我们的设计往往不能满足我们真实的需求。

例如，我们需要一个激烈爽快的单体攻击技能，那么我们的设计可能会涉及到，这个技能的功能，伤害，消耗，动画播放等。这个设计还会涉及到表现：比如技能的动作如何，特效如何，播放速度如何，镜头如何。当我们看到这些设计，我们是否就能确定这些设计能够满足我们的需求？进一步，就算我们看到设计之后，认为能够满足了我们的需求了，但是否在游戏版本中我们实际体验的时候，实际效果能100%符合我们的预期？

当我们清醒地认识到：

l 无论我们在设计上花多少时间，我们都无法完全消除设计的实际效果和预期的差距。甚至在超过某种程度之后，我们花在设计上的时间将会形成浪费（这就是所谓的OVER-DESIGN）。

我们就应该开始考虑，什么时候设计应该停止，什么时候我们就应该开始先做，然后预留足够的时间，把那些可能出现的，和必然出现的问题，留给我们后续的迭代来发现和解决。而不是把这些问题试图在一开始全部解决掉，第一，不现实，第二，不科学。

旋转上升

什么是迭代

那么，迭代究竟是什么？

首先要申明一点是，其实我们现在谈论的迭代并不是纯粹的迭代，而是迭代加增量开发。纯粹的迭代是指没有新需求的加入，第一个版本实现的内容就已经完整，之后的版本只是之前内容的优化。而增量，则指下一个版本是在上一个版本基础上增加内容的开发形式。

那么，迭代加增量开发的意思就显而易见了，而我们需要的开发模式就是这种：

l 在不断以版本为基础的增量功能开发的基础上，不断对已经有的功能进行完善和优化。这就是狭义的迭代

进一步来讲，广义的迭代，则不仅限于我们的功能开发。而且还要对于我们本身的流程，工具，工作方式，方法，习惯等等所有可以改变，可以优化的地方进行优化，进行修改。最终的目的就是通过一个个版本迭代开发，不只功能品质在变好，团队效率，团队流程等各个方面都会变得越来越好。最终形成一个真的具有战斗力的团队。

周期总结会议，以及一系列的问题改正，优化提高事项，以及平时提倡的交流，对于变化的拥抱等等，都是为了这个目标而发生的。所以，

l 敏捷开发是一种精神，而不是一种固定的形式。我们需要有一切都是可以改变的心态和准备，并且真的可以着手去改变任何我们觉得有问题的东西，这样才能真正发挥敏捷迭代开发的优势。

陀螺的转动

如何迭代

迭代的漩涡

首先，我们抽象一下，以便大家能简单的明白迭代的形式。迭代就像是一个漩涡，从漩涡中心开始旋转，越转越大。而处于迭代最中心，所有的东西都围绕它来转动的那个核心，就是我们的产品订单（故事清单）。

而那条旋转的线，就是我们的版本。版本永远围绕着我们的故事清单来开发，（故事清单，抽取于我们的游戏的设计），版本总是由故事清单里寻找需要完成的功能，再将根据实际版本得到的反馈，并更新故事清单。于是功能清单的功能越发的有价值，而版本本身也会越来越有价值。

迭代的步骤

那么，我们的版本该如何围绕我们的功能清单来画这个漩涡？

首先，漩涡是一个环绕的圈，所以我们先确定圈的长度：

l 一个迭代的长度

在这段固定长度中，它其实是一条单向封闭线性的线段，有始有终。有始有终的过程才能被量化和计划。在线段开始时我们从产品清单中取得信息，在结尾会释放一个版本并向产品订单反馈信息。

再进一步深入：

在这线段的开头，我们要从产品订单中取得什么？故事。什么样的故事？价值（优先级）总和最大，且大小（故事点）不超过我们一个周期工作量的故事。仅仅如此么？当然不是，首先，有一个重要的概念：

l 系统

也许有几个故事隶属于同一个系统下，它们共同组成了这个系统，它们全部完成，或者至少关键部分完成。这个系统才是完整的。当系统不完整的时候，这些功能的乐趣根本无法体现。

那么，有可能当我们选择这个周期开发某个高价值功能时，没有开发相应的属于一个系统的其他低价值功能。于是周期末的版本我们发现，由于系统的不完整，这个功能乐趣甚微。如果对这种涉及系统的问题没有认识，那么我们很可能就会对这个高价值功能有错误的认识。（关于系统理论的知识，请参见WIKI系统学一词）

如何避免这个问题？这个时候人的作用就体现出来了。当然我们可以在故事列表上增加一列系统属性，提醒我们。但根本的方法还是一个或者多个对整个故事列表有着足够把握能力的人来进行掌控。

我们需要有人能够全面的了解设计意图，并且对我们的故事列表进行把关，对我们周期开始的需求选取进行主导。有一点大家应该明白，规则和标准都是人制定的，那么我们究竟是依靠标准和规则来更好的控制结果，还是依靠人本身？是完善更好的标准，还是培养出更能把握质量的人？

接下来，线段中的开发过程，本质上其实就是分析需求，制定计划，开始开发。或许会周期内分为更细小的周期进行迭代。但是这些小迭代其实依然是瀑布式开发，这点毫无疑问。区别只是在于，这样的小周期内，我们开发的思想和方针是以敏捷开发的思想为指导的，我们更注重版本，更注重交流，更注重结果。而不是预定义式的开发流程（pre-defined)。

在线段的结尾，一个周期结束了，我们需要做两件事情，第一是将我们体验版本之后的反馈，反馈回故事清单中。或许我们体验某个功能之后会觉得加上另一个功能会更好玩，于是我们提升这个功能的优先级。或许我们会觉得这个功能很无聊，于是我们把同类型的功能优先级都降低。再或者我们添加，甚至删除一些全新的故事（不推荐）。

迭代的节奏

在迭代中，我们还需要注意我们迭代的节奏，什么时候该松，什么时候该紧。什么时候我们允许大家的发散和更多的思考。什么时候我们应该专注于我们的目标并且忽略其他的一切以得到我们最终的版本。这些都是有所讲究的。

这节奏包括各个方面。那么究竟这样的节奏应该如何来走呢？

在一个迭代之内，我们的节奏应该是先松后紧。当然不是说迭代开始时我们的效率可以放缓。这里的先松，是指在一开始时我们可以有更多的想法和思路，更多的探讨和研究。本来我们的迭代工作就是从粗到细，从模糊到精确的进行。在迭代中，我们也如此一步步明确我们的工作。

一旦目标明确，那么迭代周期SPRINT的名称的含义就出来了：我们向着我们的目标冲刺而去。到了这个阶段，我们需要收缩我们的讨论和想象，一切以最后的版本和质量为前提。以尽可能快的速度来开发我们的功能，提高我们游戏的质量，得到我们需要的结果。至于具体的迭代方式，各有不同，我的方式大家可以参加之前发出的那个VISIO图表。某些细节接下来还会讲到。

版本持续统一的意志

为什么需要版本

验证乐趣

我们的设计在我们的脑海里，很可能和在别人脑海里得到的认识是不一样的。

或许大家都能有幸得到统一的认识，但是做出来实际体验的时候又不一定能够符合我们的预期。

就算符合了我们的预期，也许我们玩的时候会发现一些新的点子可以很容易的加入到游戏，并且大幅度的提高游戏性。

所以，多个迭代版本的目的，首先就是为了：验证我们的功能是否符合我们的设计预期。因为:

l 没有实际玩到之前，永远不要相信自己的设计是OK的。

我想强调的是，这里的设计预期不仅仅涉及到我们的功能，事实上作为游戏开发，功能开发永远只占其中的一小部分，还有大部分的时间我们需要用来调整，优化，修改，以达到我们的真实预期。

换一种说法，这里的预期除了功能以外，还有我们对它的感受，也就是这个功能到底好不好玩。而我们关注的重点，也是在好不好玩上。如果只是关注于功能是否完善，那么我们的版本就还离成品有一大段路要走。

所以迭代版本应该是计划功能均可玩，并且没有会阻止我们体验所有需要体验内容的BUG的游戏版本。它是我们评判一切的依据，因为一切功能，一切资源，一切玩法，在进入版本可以被我们体验之前，都存在不确定性，只有最后经过版本的体验，这一切的不确定性才能消除。

持续集成

其次，敏捷开发的要求是快速迭代。但是这里的快速迭代其实远比大家想象的还要快速。或许大家觉得正确的快速迭代就是每一个周期，或2周，或一个月就需要一个版本出来。迭代速度比起传统开发确实快了许多，版本也多了许多。但是事实上的快速迭代远比一个周期要短的多。理想的快速迭代，应该是：

l 每个功能，每个改动完成之后都有一个版本能够立即对功能进行验证，进行体验。

让我们对游戏的改变把握得更直接和高效。让大部分对游戏方向的修正都发生在开发当中而不仅仅发生在周期的开头或者末尾。原因就如我所说，每一个功能从完成，到有乐趣，都需要有一个打磨的过程。在打磨之前，很有可能这个功能根本没有乐趣。所以实际上，我们一周要开发一个功能，很可能我们前4天就需要把功能开发完毕，周四出一个版本进行体验。然后周五针对周四的反馈进行一些BUG修正和反馈修改。之后乐趣才出的来。

是的，如果是理想情况的话，每一个功能无论大小都应该是这样的一个流程。哪怕是一个只有半天开发周期的功能，我们在3个小时开发后也需要出一个版本对功能进行验证，并提出反馈改进（如果有的话）。之后优化到大家觉得这个功能合格或者有存在的价值之后，我们才会继续下一个功能。

这样的过程当然过于理想化，每一个功能我们都可以几乎无限的优化下去。所以我们也需要对优化的程度进行取舍。这样取舍的标准还是最终会基于我们开发者自己的个人能力和标准上。更重要的是，我们需要建立每一个功能和变动都需要一个版本进行验证的意识。进而才能追求我们的版本质量和效率。

冲刺的艺术

效率

敏捷开发绝对不是牺牲效率追求品质的开发模式。

相反，在每一个迭代当中：

l 效率才是需要追求的第一位。

唯有在尽可能快地发布版本之后，我们才能根据版本的反馈，进行修正。进而得到更好的版本质量。大部分时候，我们需要的仅仅是以最快的速度得到我们需要的原型。验证我们的设计。为此我们需要尽可能的追求效率。

那么，如何得到我们需要的效率？

范围

首先，永远不要做多余的事情。一旦目标明确，那么我们的目标就是所有我们要做的，在目标范围内的质量优化，必要的代码改善，必要的体验优化，都是可以做的。但是离开了我们目标范围的事情，一件都不要做。

这里的范围，则是一个度量。而这个度量的划分，则又一次，需要依据我们这些人来判断。它需要我们深刻的理解到，我们制定这些目标的意义，我们要实现的究竟是什么，我们应该优化到什么程度？

我们有多少时间，那么我们就只能设计到什么程度，做到什么程度。而更多的次要的需求，我们有时间再考虑，更多的兼容性想法我们可以想，前提是我们这个版本还有时间。我们需要画一条基准线，在有限的时间里，我们能做多少内容，该做哪些内容？一切行动都需要以我们的目标为准则。当然，我们还需要考虑量产和下个阶段的准备工作等等（然则，这些其实如果规划的好，应该可以算作这个周期内的目标之一）。但这些都需要服从于当前版本的开发。全力开发我们需要的内容。

因此我们需要避免过度设计，过度开发，以及过度优化。我们需要将效率作为我们开发的准则。

人员

永远只涉及必要的人。为什么我们要进行小组化开发？因为人员牵扯一旦扩大，唯一的结果就是效率降低。各种意见难以统一，管理变得困难，计划难以统筹，任务分配变得困难等等。所以最佳的小组规模应该在7人前后。

仅仅如此么？当然不是，我们不但要确定小组规模并且将小组开发与外界的干扰屏蔽开。我们还要确定我们项目开发的流程中，每一个步骤所要参与的人员，哪些是真正必须的，哪些是不必参加的。确定人员的职责范围，首先他们需要专心于负责的部分，之后才涉及力所能及的部分。

在这里，需要解释的一点就是，敏捷开发并不是所有的决定和步骤都要大家来参与，以增进组员责任心和归属感的。为了最大化效率，我们永远只让必要的人来做必要的事情。比如故事分解为任务，只需要小组成员，和相应的主程主美主策。比如故事本身的优先级划分，只需要核心组成员（更加通常的情况是只有PO）参与即可，小组成员没有必要参与。再来，版本体验会，我们需要的是真正的指导性的意见和重要的人的声音，如果需要专门组织一个会来听小组成员对版本的反馈，我觉得那小组成员平时就不知道是干什么去了。我们需要在组织每一场会议的时候都考虑到，是不是每一个到会议的人都是必须到的，因为我们找他来开会的时间，都本来应该是他开发和工作的时间，而那才是我们的重点。

高效会议

最后，我们需要有一个清醒的认识，过多的会议永远都是高效率的开发的大敌。一个会议10个人，一小时，意味着我们会损失10个人时的工作时间。而实际上一周的工作中，我们一个人时都是损失不起的。当然，这并不是意味着我们不要开会。而是我们需要意识到我们的会议究竟是否有必要，如果有，那么会议效率是否足够？我们是否有足够的会议准备和计划，能够保证我们会议的效率？还有我们是否有相应的会议章程，会议时限？这些都是我们需要考虑的，用以高效化会议，减少时间浪费的重要方法。

所以，当我们思考效率的时候，不妨真的来看看我们现在的开发，分析一下一周的工作中，究竟开发的时间有多少？其他的时间又有多少。看看到底是什么在影响着我们的开发，是否有方法，或者措施，能减弱这些影响。最终进一步加快我们的开发？

开发的脉络

交流

非正式沟通

交流，在敏捷开发中，是永远都谈不够的东西。也是永远会存在问题的地方。在敏捷开发中，我们会重视交流而轻文档。原因？只是因为交流永远比文档更高效。

并非我们就此放弃文档，文档最终会变成记录我们讨论交流结果的工具，便于未来查阅。高效的原因是，在交流的过程中，我们就可以共同修正分歧，修正个人的错误，并且将信息传达给对方。当然，一切都还仅仅是基础的东西。

进一步的是，究竟如何能让我们的交流高效？首先，必须明确一点，会议并非是高效率交流的良好方式。更好的交流，应该更多来自于更频繁的，更多的非正式的沟通。把所有人拉到一起，强迫他们发言，或者收听，并非能很好的传递信息或者进行讨论。而鼓励他们进行自发的讨论、交流、在每天，在所有的闲暇，都可以进行一些思想，一些想法的发散、讨论。这才是最好的情况。

我们当然也可以就此进行推动。更多的不是人为的设置一些刚性讨论需求，而是制造一种推崇各自讨论的氛围。

邮件

其次，是我们交流的方法。我们有没有真正考虑过，哪些内容我们应该放到正规会议上进行宣讲？哪些内容我们只需要发一封邮件，并收集回信的反馈？哪些内容，我们只需要找到相关的人，非正式地谈论一下就可以得到解决？这些分类一旦清晰，能够为我们的团队节约多少时间？

从另一方面来说，有多少内容我们甚至连邮件都没有发出，完全变成了个人的地下行为？在这里，我想强调一下关于邮件的作用，在原来的公司，我们被要求尽量少使用邮件，因为某个时期，员工们甚至把所有需要面谈的内容都用邮件来代替了。距离5米的两个人甚至一周几百封邮件却没有一次谈话。

而在现在的环境中，邮件却变得相对冷落，很多应该有邮件作为记录，或者应该由邮件发出的内容都借由其他的方式或者没有以任何方式发出。比如现在很多的策划文档，每一次更新，只有一定几率会有邮件通知到大家。比如会议纪要，当然这都还是表现的比较好了。再比如不太重要的设计文档，这些都可以借由邮件发送来让需要知道的人了解，并且相比专门的宣讲会，节约很多的时间。大家只需要看完之后，把反馈意见用邮件发回就可以了。所以，我们可以考虑是否完善我们对于邮件的使用？更重要的是，是否我们可以进一步提高我们对于邮件使用的意识？我相信，这会是一个很漫长的过程，但是必然能够极大提高我们办公的效率。

其实终究，还是我们考虑问题的方式，我们是否能够意识到我们现在的交流方面的不足，是否能够开始改进？这将是我们是否能够继续成长的关键。

项目的基石

人

谈到人，其实就是谈到整个流程和过程中最关键的地方，最关键的元素，也是决定一切事情成败的根本。无论多好的制度，流程，如果没有相应的，合格的人来执行，也只会是失败的结局。那么，在敏捷开发中，或者说在游戏业的敏捷开发中，我们需要什么样的人，我们需要什么样的素质和要求，才能更好的运作这个模式，更好的做，并且做出更好的游戏呢？

迭代的意识

首先，是改进的意识。永远记住，没有完美的东西。我们需要保持清醒的认识，认识到我们的项目；我们的流程；我们的文档；我们的游戏等等，都还有可以改进的地方，都还有很多可以改进的地方。改进是没有终点的，我们需要能够找到这些可以改进的地方，我们还需要可以找到改进的方法，并且切实的推行下去。这样，我们才能在一次次迭代中，得到更好的项目，更好的版本，更好的团队，等等。意识到我们有问题，我们才能够改正这些问题。从某种意义上来说，其实这也是迭代的意识。

效率的意识

其次，我们需要效率的意识，我们要明白，最终，我们是在开发商品。我们是在进行商业运作，所以效率是我们需要真正关心的。而效率的重点并不是每天在公司里花了超过8小时，而是我们的时间是否都真正被有效利用起来了。我们是不是真的在需要的时间内，给出了需要的成品。是否这些成品能够合格。每天做的事情是否有意义，是否能够给予我们的工作和项目帮助？我们是否能够抓住我们工作的重点？而不是浪费在无关痛痒的地方。我们需要考虑我们的工作是否是向着目标前进的，是否足够，是否有效率。要做到效率，我们就需要首先明确我们的目标，其次清醒的意识到我们在做的事情，最后再反省是否有无效或者被浪费的地方。是否我们能做的都做了，是否我们把不需要做的也做了？

理解游戏

再次，我们需要有对游戏的把握。毕竟，我们做的是游戏，如果做的人都不知道什么是游戏，那么如何能保证我们做出来的游戏能被人喜爱？甚至，我们如何能保证我们做出来的游戏，是游戏，而不仅仅是一个选择播放的技能地图预览器？所以，首先，我们大家都需要了解游戏，了解什么是游戏，游戏包含了什么；游戏性是什么；核心玩法是什么；主要模式是什么；画面表现是什么；音效是什么；故事是什么，它们是如何结合的，是如何组合成一个游戏的。不同的游戏类型里，这些要素又以什么比例组合，哪一个更加重要。这些都是游戏开发者所需要了解的基本。进而，开发者才能明白，我们现在的游戏已经有了哪些元素，还差哪些元素，已经有的元素是否足够，是否还有所欠缺。这时，合格的游戏开发者们，才有能力说出，我们的开发方向在哪里，应该补充什么元素，有什么欠缺的地方。这样，我们才有能力，做出一个至少完整的游戏。

开发者的野心

进一步，我们如果还有野心，并非只是做一个完整的，良好的游戏，我们还想要有创新，想要做一款让人眼前一亮的游戏。那么我们就不只要了解什么是游戏，我们还需要对游戏有自己的理解和想法，我们需要有自己对这个游戏的未来的想象，并且时常将之拿出来讨论，碰撞，最后留下那些可行的，优秀的方案来实现。我们每个人都需要对我们的游戏有所希望，并且这些希望都是需要时常在我们的大脑里酝酿的。这才是游戏开发最有趣的地方，我们总是可以实现我们脑海中大胆的想法，我们总是可以把我们有趣的意见，点子说出来，如果能够得到大家的赞同，就可以实现到游戏里去。做游戏应该是有趣的，而不是每天重复枯燥无聊的劳动。所以，我们需要思考，并且说出我们的想法。

快乐地制造快乐

用心制造快乐，是不够的，还需快乐地制造快乐。让我们并不仅仅是麻木的工作着，而是真的有趣的去做有趣的事。这才是做游戏的本意，这才是大部分人最早加入游戏公司制作游戏的本意。如果我们做的东西连我们自己都无法说服自己，“那是有趣的。”那做出来的真的能有趣么？我们在做游戏，之后才是工作。如果整个游戏，都没有一点自己的心思在里面，那我们就真的只是在勤劳的上下班了。

而且也只有相互间的思想，想法在碰撞，才会做出有意思的游戏。游戏的设计并不仅仅是策划的事情，游戏的需求也不仅仅是由策划提出。只有大家每个人都可以针对游戏的缺陷，乐趣，玩法能有自己的见解，每天争的面红耳赤，那才是真正做好游戏的取胜之道。在游戏性的讨论上，根本没有策划美术程序之分。

对游戏工业化开发的把握

最后，我们还需要有对游戏开发的把握，对整体的把握。我们是否知道我们现在处于游戏开发的哪个阶段？这个阶段应该重视那些东西？应该注意那些东西？这个阶段我们应该完成那些东西？对于这些我们是否有清醒的认识，清醒的计划？

我们是否有对我们项目的整体规划？知道我们现在要做什么，知道我们下一步还要做什么，这才能让我们明白我们现在做的是否有意义，是否有效率，是否正确。我们的目的，绝对不是过GR1，2,3,4,5.这一点大家应该明白，我们始终都是在做游戏，如果我们的方法正确，计划正确，那么这些评审对我们产生不了任何影响，那么既然我们每次都需要针对这些评审改变我们的流程计划，那么是不是也意味着我们本身的计划也存在一些问题？这个问题大家也许可以思考一下。不要让问题找到我们，而是我们去寻找问题。

故事WHY ME? WHY STORY?

为什么要使用故事？

我们为什么要使用故事？要理解这个问题，首先要理解故事的作用。那么故事的作用是什么？

消除理解误差。

早期软件开发的需求方往往不懂任何技术，开发者的功能清单却往往难以让需求方有直观的对最后成品的认识。比如，或许一个功能描述是，“战斗场景分为5层可以根据摄像机的移动而相对运动”，但对于非专业人士来说，他们可能无法理解这样的描述意味着什么。于是故事开始发挥了它的作用：以一种大家都认可的方式让所有人对我们要做的功能目标有清楚的认识。

所以：

l 只要能够让全体人充分意识到我们功能开发的目标以及内容，那么它就是一个很好的故事。

对我们来说，这样的共识需要在策划，美术，程序等人员之间达成，所以我们的故事也需要以一种大家都能理解的方式来表达。而更重要的，不是故事的方式，而是确实所有人都能够完全理解。具体怎么写，其实真的怎么写方便都可以。

整体统筹估计和管理。

由于故事是从系统和结构的层面，以一定的高度来描述我们整个项目的框架功能，所以我们可以以较快的速度全面了解我们的功能点，而对于这些功能点，我们还可以进一步快速的给出粗略的估算。进而得出整个项目的大概工期或者每个迭代我们可以完成的故事数量。这里的估算往往是由不准确慢慢到准确的。

l 每一个周期，每一个项目的历史数据都可以让我们之后的估计更加精确。

而且这样划分的工作，可以更好的交付给不同的小组完成。小组内部进一步自行组织计划，使得我们的管理工作可以分散到小组，降低管理难度。

创意管理

本质上，游戏就是已有的同类游戏的完整功能点，加上我们独特的创意。完备的前者能让我们的游戏成为一款合格的游戏，而后者的加入则让我们的游戏变得独特。引入故事后，我们可以总是在一个层面，对功能开发和创意尝试的投入进行平衡，相互以取舍。我们可以总是以功能和创意的价值来判断真正对我们有价值的开发顺序。

故事在讲什么？

什么是故事?

首先，故事本质上依然是功能点，依然是从需求中抽取出的一个个系统功能。只是以一种所有人都能理解的形式进行描述。所以，为了能够让所有人能够理解，故事仅仅只从实现功能的目的来描述这个功能：

l 故事是对功能的目的的描述

同时，故事是在讲述这个功能究竟是发挥什么样的作用。所以它本身价值只是简单描述和给予一定参考。

l 它不是，不能也不需要详细的描述这个功能的所有细节和玩家对此的感受。

因为前者有相应的策划文档，后者难以文档化以标准衡量。

所以，当我们要验收某个故事的时候，并不是我们比照着一个个故事，来体验游戏。看一个个故事是否在游戏中完整的实现了。

正确的故事验收，应该是在这个故事在组内达成统一之，所有人就应该知道要做成什么样子之后。将单个功能的验收在周期内

就实时完成。而在最后版本发布之时，对功能进行检验，检测这个功能的最终效果是好还是坏。

我们的目的不只是要看是不是功能A,B,C,D已经完成了，我们应该再深入一步：

l 关注于功能是否得到了很好的效果，符合了我们的预期

l 在游戏开发中，则是，是否有了乐趣

l 是否有其他想法，能够让这个游戏更有趣

因为仅仅是功能的集合，并不能成为合格的游戏。

因此，我们也需要改变我们对于设计目的的定义：

l 我们的目的并非仅仅是完成某个功能，而是功能能否达到我们需要的乐趣。

带着这样的思路，我们才能真正的在版本回顾的时候，给予能够指导我们开发方向的反馈，而非仅仅是针对我们功能开发的完整与否，发表意见。

作为核心组成员，或者，作为整个游戏项目的一员：

l 我们不应该仅仅关心于完成情况，各种细小的错误。我们应该看得更远，思考的更远，给予我们的开发真正能提升最终质量的帮助。

最后，故事包含对它大小的估计，我们可以使用这个估计来对将来的工作和计划进行评估；对它本身价值的估计，让我们在选择他们时可以参考。简单的来说，就是另一些附加的功能。

用好你的武器

如何使用故事

故事的来源

第一，从已有的游戏设计文档或者框架中抽取的，比如，我们已经知道我们要做的是一个回合制战斗的游戏，那么我们就可以抽取出，基础战斗指令，回合制战斗流程之类的故事。

第二，新出现的创意性质的内容，比如，今天我突然想到在回合制战斗中加入行动顺序条或许是个很有趣的点子，我告诉大家，大家也觉得这个东西很好，于是我把它加入到清单中。

第三，当我玩到某个游戏的版本的时候，发现，某个功能给我的反馈不是很好，或者我觉得可以如何改进，能够让这功能变得更好，那么也可以放进到故事清单中。

故事的使用

首先，我们有一个用来维护故事的列表，术语叫做产品订单，里面罗列了所有我们已经完成或者没有完成，重要的或者不重要的故事。我们可以在里面清楚的看到：

l 故事的描述

l 故事点（大小）

l 优先级（价值）

l 当前状态

于是，在每个迭代开始的时候，我们都将故事从大到小排列起来，依据上个版本我们能完成的故事量（以故事点来衡量）来选取我们这个版本需要完成的故事内容。

故事选取完成后，下一步，则是让整个小组对故事的内容达成统一。也可能只是统一目标，而某些细节在完成的过程中确定。这过程的形式，依然并不固定。

当大家对故事的内容都有所了解之后，我们可以开始对故事进行分解。得到相应的详细的任务。任务又成了计划，在对计划进行评估和检验之后，每个周期的工作内容就如此确定。

故事的作用就基本到此结束，剩下的内容是当单个故事完成的时候，对版本中功能进行体验，如果通过，则这个故事就此完成，最后进行归档之类的收尾工作。

当然，在故事的具体使用中还有一些细微操作，比如如果一个故事在一个周期中制作时发现比估计的大很多要放到两个周期来做才能完成。那么我们还需要对故事进行拆分之类的操作。这些细微操作还是需要在针对不同的情况进行不同的处理。

版本体验会

当我们一个周期的开发内容完成，每个版本功能都已经在周期内得到了验证，并且已经有了一定的优化。为什么我们还要有一个版本体验会呢？

首先，我们每个人负责的领域不同，我们有的人对于美术质量很关注，有的人对于代码质量很关注，有的人对于设计文档很关注。也许我们中的一些人参与了一些功能的开发，但是我们并不能对于这个周期的所有功能，所有的改动有所了解。就算对此有所了解，我们也许也不明白每一个功能的设计用意。最后，为了让所有人对最终结果达成统一的认识，我们需要一个正式的展示会议，向核心组或者高层进行我们这个阶段的成果展示。在展示我们的版本新增功能和内容的同时，核心组也会对这个版本的各个细节和内容进行考察和审核，确定这样的改变是否符合对于游戏性和乐趣的追求，是否符合我们对我们游戏的希望，这样的发展方向是否是正确的。

而在这样的会议中，最重要的是，我们需要得到来自各个方面的反馈。作为开发者，这可能本身就局限了我们对于我们的版本的认知和看法。我们对于我们的版本过于熟悉，有可能自动的忽略掉了一些很重要的问题，或者会错误的认为一些难以被接受的游戏性具有很大的乐趣。而这样的会议，则是指正我们类似问题的恰当时机。针对这些反馈，我们可以更好的修正我们的工作思路和计划。给予我们下一个阶段更好的目标。

所以，在这里，核心组需要给出的，更多，更重要的，还是对于我们游戏的方向性的，涉及到我们目前开发功能的游戏性和表现上的改进意见或者反馈和一些指导性的意见。因此，我们需要要求我们核心组本身更了解游戏，更明白游戏性，并且自己对于我们要开发什么样的游戏，有清醒的认识和思考。

周期总结会

自适应，自我优化的流程，需要有两个要素才能真正的进行自我改进。首先最重要的是其中的人要有对流程中的问题，需要优化的地方，甚至是对优化本身有清醒的认识和意愿。其次，就是这样的人推动的一个优化行动。而周期总结会，就是SCRUM中设立的一种针对流程自身优化而进行的一种行为。

项目总结是游戏业的一个普遍工作习惯，在每一个游戏项目结束的时候，会进行一次全项目级别的总结会议，对于整个项目过程当中，做的好，有典范价值的事物，或者在过程当中发生的有范例价值的问题，甚至是还没有解决的问题进行系统的总结和提炼。之后将之发表，可以成为团队，甚至其他团队将来工作时的依据和帮助。

而每一个周期一次的周期总结，则是将这一行为加快，频率加高，在项目进行中不断反复。以此达到更快速的寻找总结目前我们的优缺点，针对我们目前的缺点问题寻找解决的办法，并且开始行动。总的来说，就是以更快的频率不只是迭代我们的版本，将我们的版本改进的更好。同时也是迭代我们的行为，优化和让我们自己更加的进步。

其实设立一个这样的会议并不难，每一个周期我们都会有这样的总结会。而会议也总会有这样那样的缺陷和需要优化修改的结果。难的是我们需要切实的推行那些问题的修正措施，难的是我们需要能够直面我们的不足，并且将其提出。我们要能对或许难以开口的问题更直白。鲁迅先生有云，真正的猛士，敢于直面惨淡的死生。我们必须承认我们的工作都是不完善的，都是需要优化的。但是这些问题都不是阻止我们开始修正和改革的借口。敏捷开发的意义也就在于，知道一开始的我们不足以成功，甚至肯定会出现问题，会有失误。但是正是在一次次快速迭代中，我们快速的磨合，快速的修正，最后在一次次的改正与进步中，我们才会得到一个完善的团队，一个良好的流程以及一系列适合我们的方法。

这也才是周期开发的意义所在。所以，敏捷开发，并不是一个需要在一开始就有完全的准备的过程，并不是一个需要完整规划，好好考虑的过程。我们只需要有一定的东西可以开个头，哪怕还不算成熟，但是我们依然可以在接下来的过程中，对我们的目标愈发的清醒，越发的明确，并且我们本身也会越发的成熟，最终共同达到目标。

一开始，游戏功能不明确？没问题，我们可以先从知道一定会做的开始做，然后开始探讨我们最后要做的目标，再根据每一个迭代的版本反馈修正我们的目标。

一开始，我们开发团队磨合不够？没问题，我们可以先让他们从开发简单的底层功能做起，并且同时进行磨合，将磨合过程中需要解决的问题一一提出并改正，最终优化得到一个完善的团队。

一开始，我们的工具不够？没问题，我们可以先用最快的方式开发原型，同时分析原型制作的方式和需求，进行工具制作。并且在工具可以使用之后，再根据使用者的反馈和项目的进展进一步的优化和改进。

... ...

我们可以做的东西很多，而那些还没有做的，也同样不能成为我们开始做的障碍。

原文：http://djt.open.qq.com/portal.php?mod=view&aid=115

本文链接

js矢量图类库：Raphaël—JavaScript Library

2011-12-20T10:23:00Z

官方网址：http://raphaeljs.com/

Raphaël is a small JavaScript library that should simplify your work with vector graphics on the web. If you want to create your own specific chart or image crop and rotate widget, for example, you can achieve it simply and easily with this library.

Raphaël ['ræfeɪəl] uses the SVG W3C Recommendation and VML as a base for creating graphics. This means every graphical object you create is also a DOM object, so you can attach JavaScript event handlers or modify them later. Raphaël’s goal is to provide an adapter that will make drawing vector art compatible cross-browser and easy.

Raphaël currently supports Firefox 3.0+, Safari 3.0+, Chrome 5.0+, Opera 9.5+ and Internet Explorer 6.0+.

最近在做一个关于客户与品牌，客户与代理关系的展示，由于用二维表展示不是很直观，所以就想做个比较直观的，在网上搜到了Raphael，就小试了一下，感觉不错；

下面是试用结果截图：

源码如下：

var data = {
                   "customer": "方正电子",
                   "brands":
                   [
   		            { "brand": "经略广告" },
   		            { "brand": "文韬采编" },
   		            { "brand": "飞腾创艺" },
   		            { "brand": "畅享全媒体" }
   	            ]
               };

               var r = Raphael("holder", 500, 500);
               angle = 0;
               var interval = 36;
               if (data != null && data.brands.length > 0) {
                   if (data.brands.length < 13) {
                       interval = 360 / data.brands.length;
                   }

               }

               var centerX = 250;
               var centerY = 250;
               var mc = Raphael.getColor();
               mc = Raphael.getColor();
               // mc = Raphael.getColor();
               var index = 0;
               while (angle < 360) {
                   var color = Raphael.getColor();

                   (function (t, c) {
                       r.circle(centerX, 400, 50).attr({ stroke: c, fill: c, transform: t, "fill-opacity": .4 }).click(function () {

                       }).mouseover(function () {
                           this.animate({ "fill-opacity": .95 }, 500);
                       }).mouseout(function () {
                           this.animate({ "fill-opacity": .4 }, 500);
                       });

                   })("r" + angle + " " + centerX + " " + centerY + "", color);


                   var path_transform = "r" + angle + " " + centerX + " " + centerY + "";
                   r.path("M" + centerX + "," + centerY + "L" + centerX + ",350z").attr({ stroke: mc, fill: mc, transform: path_transform + "," + mc, "fill-opacity": .4 });
                   var brandName = r.text(centerX, 400, data.brands[index].brand).attr({
                       font: '16px Arial',
                       fill: '#000',
                       transform: path_transform + "," + mc
                   }).toFront();
                   brandName.rotate(0 - angle, brandName.x, brandName.y);



                   index++;
                   angle += interval;
               }


               var s = r.set();

               s.push(r.circle(centerX, centerY, 60));


               s.attr({ stroke: mc, fill: mc })

               .mouseover(function () {
                   this.animate({ "fill-opacity": 1.75 }, 500);
               }).mouseout(function () {
                   this.animate({ "fill-opacity": 1 }, 500);
               });
               s.push(r.text(centerX, centerY, data.customer).attr({ font: '16px Arial', fill: '#fff' }));

var data = {
                   "customer": "联想集团",
                   "agents":
                   [
   		            { "agent": "中关村在线" },
   		            { "agent": "苏宁电器" },
                       { "agent": "国美电器" },
                       { "agent": "京东商城" },
   		            { "agent": "淘宝商城" }
   	            ]
               };
               var containerW = 500;
               var containerH = 500;
               var r = Raphael("holder", containerW, containerH);
               var boxW = 70; //方框宽度
               var boxH = 30;  //方框高度
               var subBoxY = 150; //代理框的y坐标
               var paddingY = 10; //图的内边距 

               var angle = 0;

               var interval = 10;
               if (data != null && data.agents.length > 0) {
                   if ((parseInt(boxW, 10) * data.agents.length) < containerW) {
                       //间隔=（containerW-代理个数*boxW)/代理个数+1）
                       interval = ((parseInt(containerW, 10) - (parseInt(boxW, 10) * data.agents.length)) / (data.agents.length + 1));
                   }

               }
               var mainColor = Raphael.getColor();
               mainColor = Raphael.getColor();
               //画当前客户框
               var mainBoxX = ((parseInt(containerW, 10) - parseInt(boxW, 10)) / 2);
               var mainBox = r.rect(mainBoxX, paddingY, boxW, boxH).attr({ stroke: mainColor, fill: mainColor, "fill-opacity": .4 })
               .mouseover(function () {
                       this.animate({ "fill-opacity": .95 }, 500);
                   }).mouseout(function () {
                       this.animate({ "fill-opacity": .4 }, 500);
                   });
                   //写客户名称
                   r.text(mainBoxX+(boxW/2), paddingY+(boxH/2), data.customer).attr({ font: '12px Arial', fill: '#fff' })
               //画中间横线
               var mX = (interval + ((parseInt(boxW, 10) / 2)));
               var mY = ((parseInt(subBoxY, 10) - parseInt(paddingY, 10) - parseInt(boxH, 10)) / 2) + parseInt(paddingY, 10) + parseInt(boxH, 10);
               r.path(Raphael.format("M{0},{1}L{2},{3}z",
               mX,
               mY,
               (containerW - mX),
                mY));

               //画当前客户和横线的连接线
               r.path(Raphael.format("M{0},{1}L{2},{3}z",
               (parseInt(containerW, 10)/2),
               mY,
               (parseInt(containerW, 10) / 2),
                parseInt(paddingY, 10) + parseInt(boxH, 10)));

               angle = interval;
               $.each(data.agents, function (i) {
                   //生成多个代理框
                   var color = Raphael.getColor();

                   var box1 = r.rect(angle, subBoxY, boxW, boxH).attr({ stroke: color, fill: color, "fill-opacity": .4 }).click(function () {

                   }).mouseover(function () {
                       this.animate({ "fill-opacity": .95 }, 500);
                   }).mouseout(function () {
                       this.animate({ "fill-opacity": .4 }, 500);
                   });
                   //画线
                   r.path(Raphael.format("M{0},{1}L{2},{3}z",
                   (angle+(boxW/2)),
                   subBoxY,
                   (angle+(boxW/2)),
                   mY));
                   //写代理名称
                   r.text(angle + (boxW / 2), subBoxY + (boxH / 2), data.agents[i].agent).attr({ font: '12px Arial', fill: '#fff' })
                   angle += parseInt(boxW, 10) + interval;
               });

本文链接

关于生成id的问题

2011-12-09T07:18:00Z

表明	表最大id

方法1：

GO
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
ALTER PROCEDURE [dbo].[getserial] @serialname char(30) AS
begin
declare @serialno int
begin transaction
select @serialno = SV_nSerial from SystemVariable with(TABLOCKX HOLDLOCK) where SV_strName = @serialname
if @serialno is null
begin
commit
raiserror 50010 'SystemVariable lack record'
end
else
begin
update SystemVariable set SV_nSerial = @serialno+1 where SV_strName = @serialname
commit
select @serialno+1
end
end

方法2：

declare @max int
select @max = SV_nSerial from SystemVariable where SV_strName = @serialname

update SystemVariable set SV_nSerial = @max+1 where SV_strName = @serialname and SV_nSerial = @max

本文链接

SSL为Windows server 2008 IIS7进行加密连接

2011-11-21T07:45:00Z

运行“Internet信息服务(IIS)管理器”，单击服务器名字：ITPUB个人空间WV@dv:`9A~LPj

双击中间栏内的“服务器证书”:ITPUB个人空间!e$A^3I1t4e3s

在“服务器证书”的右栏内单击“创建自签名证书”：ITPUB个人空间jP6wP/db E

为创建的自签名证书指定一个好记名称。

回到“Internet信息服务(IIS)管理器”单击想要进行SSL加密连接的网站:
WZia'}jZ/E_ L0

单击“绑定...",弹出网站绑定对话框:
c_ q2bf0

单击“添加...”按钮弹出“添加网站绑定”对话框：
z#acJ {bB0

在对话框中的配置如上图。IP地址：选择你的服务器IP地址，SSL证书是刚才创建的“自签名证书”。

可以看到已绑定的网站：
"E3PlrsF,yz0

打开浏览器，在地址栏内输入：https://192.168.0.117，当打开网站时会弹出如下提示：客户端浏览器由于不能辨别证书的合法性，所以提出警告，并给出三个选择：ITPUB个人空间4sx(\9?|`5Y:M

选择第二个选项。

再次提出安全警告，怀疑安全证书不可靠：
)H6X&@r'rQ Ec^^0

点击“确定”按钮，加密连接到IIS服务器:ITPUB个人空间`Q&^iVa N H

这只是其中的一种方法。和Windowsserver2003相比，配置要简单些，图形化界面。

本文链接

详解HTML

2011-11-18T01:20:00Z

1. 详解HTML

标签和属性

在HTML中，通常标签都是由开始标签和结束标签组成的，开始标签用“<标签名>”表示，结束标签用“</标签名>”表示。

元素指的是包含标签在内的整体，除去标签的部分叫做内容。

属性要在开始标签中指定，用来表示该标签的性质和特性。通常都是以“属性名=”值””的形式来表示，用空格隔开后，还可以指定多个属性。指定多个属性时不用区分顺序

颜色的指定方法

用HTML指定颜色有两种方法

1、用16进制数值来指定：在#号的后面，把RGB的各个选项用十六进制的数值来表示，数值保持两位数。

2、指定颜色的名称：可以对基本的16色用名称来指定其颜色

指定文件的位置

在对某部分设置链接的时候，需要指定链接端HTML文件的位置；同样，如果想在该处显示图像也需要指定图像的位置。在HTML中，这个位置用URL来表示，有以下两种表示方法：

1、绝对URL：绝对URL就是用Web浏览器查看网页时，地址栏中显示的以http://开头的路径

2、相对URL：相对URL是在同一站点内进行设置，类似于在同一磁盘上管理文件的形式。这种方法是以当前文件的位置为基准。使用相对URL时，如果要指定的文件在当前文件的下级，就从目录名开始一直写到要指定的文件名，中间用“/”符号隔开。如果在当前文件的上级，每上一级就加一个“../”符号

2、基本内容

显示HTML的版本

<!DOCTYPE~>

HTML的版本表明HTML文件是按照哪个版本进行编写的（标明该HTML文件遵循的DTD文件），不同的版本和种类都有固定的书写格式，要按照固定的格式输入文件开头，然后在文件开头处写明版本，按照这种版本的规定格式进行编写

必须使用的标签

HTML文件的开头写有<!DOCTYPE~>的部分，代表HTML的版本，其后是必须存在的四种标签

首先，<!DOCTYPE~>后面的整个都要用html标签(<html>~</html>)括起来，其中要按照head标签(<head>~</head)和body标签的顺序(<body>~</body>)的顺序进行排列。

在head标签中填写与该文件相关的信息，body标签中填写世纪要在浏览器上显示的内容。另外，在head标签中，只能有一个代表文件标题的title标签

设置页面的文字颜色

设置页面的背景颜色

设置页面的背景图像

按照目的设定范围

插入注释

<!—注释语句-->

3、设置文件信息

添加标题

title标签用来给HTML文件添加标题

这个标签一定要位于<head>~</head>圈定的范围内。在这里指定的标题除了可以在通常的浏览器窗口的标题栏中显示以外，还可以作为加入收藏夹时的标题

显示文件编码

meta标签的charset属性表示该HTML文件是用什么文字编码编写的

注意，该标签一定要位于<head>~</head>范围内

添加关键字、内容介绍及作者姓名

这些信息都不会在画面上显示出来，但是搜索引擎在收集信息时要用到

注意，该标签一定要位于<head>~</head>范围内

设置样式表和脚本语言的种类

在HTML文件内可以设置样式表和脚本的默认语言

注意，该标签一定要位于<head>~</head>范围内

设置进入网页

rel：在本页看到的，与URL标明的网页之间的关系

rev：在URL标明的网页中看到的，与本页之间的关系

link标签表示的是该文件和与其相关的其他文件之间的关系

注意，该标签一定要位于<head>~</head>范围内

设置标准URL

base标签用来设置将该页中使用的相对URL的标准指向成绝对URL，指定了这个标签之后，在该页指定的相对URL就会全部认定为已在这里指定的绝对URL。如果不进行这项设置，就以当前页的位置为标准，如果指定了Target属性，就可以指定打开链接地址网页的默认框架和窗口

注意，该标签一定要位于<head>~</head>范围内

设置自动倒入网页功能

在经过数秒后，自动开始导入网页。如果指定了要移动到的URL，就会导入URL指定的网页。如果没有指定，就会再次导入相同的页

注意，该标签一定要位于<head>~</head>范围内

4、设置文本类型

设置各级标题

…

设置段落

p标签表示的是该部分为一个段落

设置联系地址

address标签表示的内容是该网页制作者的联系地址和有关网页内容的咨询地址等信息

设置强调内容

这两个标签所圈内容表示该部分是强调的内容

设置较短的引用文字

q标签代表的意思是该部分为较短的引用文，在引用段落的某一部分的时候使用，如果使用cite属性，还能够把引用页的URL显示出来

设置较长的引用文章

设置文字内容的出处

设置缩略语

title：不处于省略状态下的词汇（字符串）

设置添加的内容

设置需要删除的内容

突出显示段落中的术语

表示与程序关联的文本

<kbd>~</kbd>：输入文本

<samp>~</samp>：输出样本

<code>~</code>：源代码

<var>~</var>：变量

显示特殊符号

&lt：<

&gt：>

&quot：”

&amp：&

5、设置显示方式

设置文字的换行

<br>

添加了br标签之后，文本就会再该处换行。即使在HTML代码中已经换行了，在浏览器上显示的时候却反映不出来，因此如果想在浏览器上换行的话，就要使用br标签

添加不同横线效果

<hr>

加入了hr标签后，就可以在其标注的地方显示横线

设置文本格式

<b>~</b>：黑体字

<i>~</i>：斜体字

<tt>~</tt>：等大字体

<sup>~</sup>：上标

<sub>~</sub>：下标

<u>~</u>：下划线

<s>~</s>：删除线

设置空格和换行

<pre>标签可以保留文字在源代码中的格式，使得页面中显示的内容和源代中的格式完全一致

设置居中效果

center标签用于将指定范围内的内容设置为居中

设置行对齐方式

使用align属性可以设置标题、段落以及指定范围内的行对齐方式

设置文字颜色

设置字体类型

设置字体字号

相对改变字体大小

<big>~</big>：增大

<small>~</small>：减小

<font size=”+n”>：增大n号

<font size=”-n”>：减小n号

设置字号的基本大小

size：1~7

6、设置链接相关的属性

链接到其他页面

a标签的href属性能把指定的范围链接到其他页面上，链接部分的词语要设置得让人看到这个部分就能联想到链接网页上的具体内容

另外，在链接图像的时候，一定要插入替代的文字（alt=”~”）使用户能够很明确的了解到链接的目标

链接到当前页的特定位置

<a href=”#位置名”>~</a>：指定链接文件（从什么位置开始链接）

<a name=”位置名”>~</a>：指定链接的地址（要链接的位置）

如果一页上的内容非常多，可以在一个网页中给特定的位置命名，然后再链接到该位置（跳转）。在给链接对象位置命名的时候要使用name属性。然后，在链接的时候，要用href属性在链接地址名称的前面加上#号

设置链接到其他页面的特定位置

<a href=”URL#位置名”>~</a>：指定链接源（从什么位置开始链接）

<a name=”位置名”>~</a>：指定链接的地址（要链接的位置）

在链接到其他网页上的时候，可以先给那一页上特定的位置命名，然后链接到该位置。在给链接对象位置命名的时候要使用name属性。然后，在链接的时候，要用href属性设置成”URL+#+位置名”这样一种格式

设置链接文字的颜色

link：还没有看见的链接部分的文字颜色

vlink：已经看见的链接部分的文字颜色

alink：鼠标单击链接部分的文字颜色

body标签用于设置网页整体链接部分的文字颜色

在新窗口中打开链接网页

利用target属性可以设置打开链接窗口的方式

通过设置链接来启动邮箱

7、制作不同类型的列表

为列表添加不同类型的标记

ul标签的作用是将列表（条款形式）加上圆点或方括号的标记。列表的整体要在<ul>~</ul>标签范围内，在这之间的各个项目要在<li>~</li>标签之内

更改列表标记

标记的种类包括disc、cicle和square

制作带序号的列表

改变序号的样式

改变序号的顺序

制作包含专用语和解释的列表

8、设置表格

表格的基本形式

<table border=”边框的粗度”>~</table>：整个表格

<tr>~</tr>：单独一行

<th>~</th>：单元格：标题用

<td>~</td>：单元格：数据用

表格的整体要圈在<table>~</table>之间显示，表格当中某一个单元格用<th>~</th>表示或者<td>~</td>表示。每个单元格都在表的单独以行，放置在<tr>~</tr>中。也就是说，table标签的内容是由tr标签构成的。各个tr标签的内容是由表示单元格的th或者td标签构成的。th标签代表这个单元格的内容是标题。td标签代表这个单元格的内容是数据

为表格添加标题

caption标签用来给表格添加标题

该标签一定要放在table标签的紧后面。标题的显示位置（即对齐方式）可以指定在表格的上部，或者表格的下部

指定表格的大小

宽度：针对像素或者窗口的百分比

指定单元格大小

合并单元格

垂直方向的合并数：从当前单元格开始向下合并的单元格数

水平方向的合并数：从当前单元格开始向右合并的单元格数

设置单元格之间的距离

设置单元格边框与内容之间的距离

设置单元格中的行对齐方式和列对齐方式

align属性用于设置单元格内的行对齐方式，valign属性用来设置单元格内的列对齐方式

禁止在单元格内换行

设置表格和单元格的背景颜色

bgcolor属性用于指定表格和单元格中的背景颜色

设置表格和单元格的背景图像

background属性用于指定表格和单元格中的背景图像

设置表格外框的宽度

设置表格外框的显示形式

设置表格内补边框线的显示形式

定义表格中的横行

<thead>~</thead>：表头部分

<tbody>~</tbody>：表体部分

<tfoot>~</tfoot>：表底部分

thead标签、tbody标签和tfoot标签都是用来定义表格的横行（tr标签）的

这样组合之后，就可以针对该组合的整体来应用属性和样式表。

使用这些标签的时候，一定要以thead标签、tfoot标签和tbody标签的顺序进行排列。在一个表格里，只能放置一个thead标签和一个tfoot标签，而tbody标签可以根据需要放置多个

利用纵列设置表格属性和样式表

col标签不仅可以用来改变表格的纵列结构，还可以用来根据纵列，来综合指定宽和行对齐方式等属性以及样式表

该标签放置的位置要在caption标签的紧后面（如果没有caption标签，就放在table标签的开始标签的紧后面），以及thead标签和tr标签的前面

设置表格居中

将表格嵌入到文本中

位置：left,right

将table标签的align属性指定为left或者right后，就可以将表格以居左或居右的方式嵌入到文字中间

如果想要解除嵌入状态，可以使用<br>标签的clear属性

解除表格的嵌套

left：解除左侧表格的嵌套

right：解除右侧表格的嵌套

all：解除两侧表格的嵌套

设置表格与嵌套文字之间的距离

垂直距离：表格的上下框与文字间的距离

水平距离：表格的左右框与文字间的距离

9、设置图像与多媒体

插入图像

使用img标签，可以把图像插入到HTML文件中

图像的格式一般可以使用GIF格式、JPEG格式和PNG格式

不管图像实际的大小如何，都会按照在这里所指定的宽度和高度来显示

alt属性是在不能显示图像的情况下，指定替代图像所使用的文字

设置图像的边框

设置图像与文字的垂直位置关系

在同一行中，如果有图像和文字，那么就可以用align属性来设置图像和文字的垂直位置关系

制作图像热区

在map标签中，用来设置实际单击的区域和链接地址的是area标签

在area标签中，一定要指定表示链接地址的替代文字，之后要用image标签的usemap属性指定定义后的image map的名称（名称前面要加#），这样图像就可以作为image map产生相应的效果

将图像嵌套在文本中

位置：left,right

解除图像的嵌套

设置图像与周围文字之间的距离

放置Java小程序

applet标签是嵌入Java小程序时要使用的标签

如果使用param标签，在执行java小程序时，需事先指定一些必要值。这时，param标签要位于<applet>~</applet>范围的最开始部分

10、制作不同类型的表单

制作填写表单

URL：用来处理发送后表格的程序的URL

发送形式：get,post

MIME类型：以post方式发送内容时的MIME类型

窗口名称：先是发送结果的窗口或框架名

form标签表示在表单中填写的内容是可以发送的

制作发送按钮

标签：在按钮上显示的文字

名称：按钮的名称

将input标签的type属性设置为submit，再根据form标签的设置，可以制作发送填写在表单中数据的按钮

制作重置按钮

制作通用按钮

通用按钮通常与JavaScript等脚本语言组合使用

利用图像来制作发送按钮

通常，发送按钮都使用input type=”submit”代码，不过图像也可以作为发送按钮，具有发送功能。这时，图像被单击的位置将和表单的内容一起被发送

制作不同功能的发送按钮

类型：submit,reset,button

button标签是用来制作按钮专用的

通过指定type属性值，就可以产生具有不同功能的按钮，包括发送按钮、重置按钮和通用按钮。另外，在<button>~</button>中放置相应的内容，可以作为按钮的标签显示出来。在需要进行其他处理并设置多个发送按钮的情况下，根据name属性和value属性所显示的值，接受方就可以分辨出单击的是哪一个发送按钮

制作单行文本框

制作多行文本框

制作输入密码的文本框

插入隐藏域

制作单选按钮

将input标签的type属性设置为radio，可以用来制作单选按钮。单选按钮是多个选项当中只能选择其一的按钮。作为公共项目的选项而使用的单选按钮，要把它们都指定为同一名称。另外，发送数据的时候，为了识别所选的是哪一项，要用value属性来指定相应的值

制作复选框

将input标签的type属性设置为checkbox，可以用来制作复选框。复选框可以在多个选项当中进行多项选择。作为公共项目的选项而使用的复选框，要把它们都指定为同一名称。另外，发送数据的时候，为了识别所选的是哪一项，要用value属性来指定相应的值

制作菜单

<select name=”名称”>~</select>：菜单整体

<option value=”发送值”>~</option>：菜单项

<option selected>~</option>：菜单项

select标签用来制作菜单

菜单的整体要在<select>~</select>范围之内显示，然后按需要的数量在其中放置表示选项的<option>~</option>。<option>~</option>范围之内要写上实际菜单要显示的选项的名称。另外，如果省略了value属性，在这里记录的文字本身就会作为所选值发送

组合菜单选项

<optgroup lable=”组合名称”>~</optgroup>：制作组合菜单

<option lable=”次选项”>~</option>：组合内的选项

组合名称：第一级显示的组合标题

次选项：对应组合名称下面的在第二级显示出来的选项

制作的菜单选项可以利用<select>~</select>标签组合起来

制作下拉列表

<select size=”行数” name=”名称” multiple>~</select>：下拉列表框

<option value=”发送值”>~</option>：菜单项

<option selected>~</option>：菜单项

在用于制作菜单的select标签中指定了size属性后，就可以显示下拉列表框

添加选择文件的功能

将input标签的type属性设置为file，可以自动做成能够选择发送表单数据的文件按钮和文本框

综合利用菜单选项

<fieldset>~</fieldset>：组合

<legend align=”对齐方式”>~</legend>：组合的标题

field标签用来把填写在表单中需要包含的输入内容和选项组合起来

在<fieldset>~</fieldset>的最开始部分放置legend标签，并且给该组合加上标题

将标签文字与项目一体化

参照ID：添加了标签的对象的id属性值

lable标签的作用是在输入项和选项及其标签文字之间建立起明确的关联，并使其一体化

11、利用框架布局网页

设置框架整体结构

高度：在垂直方向上分布的多个框架的高度，按从上到下的顺序依次用逗号隔开来指定

宽度：在水平方向上分布的多个框架的宽度，按从左到右的顺序依次用逗号隔开来指定

URL：作为框架内容显示的HTML文件的URL

框架名称：在指定链接等显示目标的时候使用的名称

使用框架功能可以把窗口横竖切割开，然后在不同的块区域中显示其他的HTML文件。在指定了框架的文件中，原来body标签所在的位置，要放置frameset标签，这主要是由于在框架页面中不能使用body标签

在<frameset>~</frameset>的范围中要按照顺序填入分割后框架内要填写的内容。如果不需要再分割，就用frame标签指定要导入的HTML文件，如果还要继续分割的话，就需要放置frameset标签（作为嵌套放置在里面，并且指定盖框架如何分割）

设置框架的显示方法

设置是否显示边框

frameborder属性用来设置分割开相邻框架的边框是否显示

去除分割框架的边框

在不支持框架的环境中显示所需内容

这个标签要在<frameset>~</frameset>范围的最开始或者最后处放置一个。在<noframes>~</noframes>范围内要首先放置body标签，并在其中填写所要显示的内容。

指定链接目标在哪一个框架内显示

如果对框架内的文件中指定的链接不进行设置的话，就会在原来的相同框架中显示链接目标，如果想使这个链接目标在其他框架中显示的话，就需要指定target属性值，用想要显示（frame标签）的那个框架的name属性来指定框架名称

插入内嵌框架

iframe标签不仅可以放置分割窗口形式的框架，还可以在窗口中放置独立显示的内嵌框架。在框架内还可以显示src属性所指定的内容

如果浏览器不支持这种框架，要在<iframe>~</iframe>之间指定要显示的内容

12、关于脚本

在HTML中插入脚本

在HTML文件中编写脚本的时候要用到script标签，脚本语言要写在这个标签的范围内

这时，在不支持这个标签的浏览器上会在画面上显示出脚本的部分，为了避免这种现象，通常把脚本整体作为HTML的注释。这个标签可以放在<head>~</head>和<body>~</body>范围内的任意位置上

在不能执行脚本的环境中添加所需的内容

在脚本不能运行的时候，可以使用noscript标签来指定替代显示的内容

这个标签要放置在<body>~</body>的范围内

http://www.cnblogs.com/ustcwhc/archive/2011/11/09/2243056.html

本文链接

dhcp分配不到IP地址的解决方法

2011-10-18T02:50:00Z

netsh winsock reset

本文链接

使用CruiseControl+SVN+ANT实现持续集成之三

2011-09-16T01:18:00Z

在上一节中我们介绍了环境搭建和配置介绍，并快速启动CC查看集成结果，在本节中我们将详细介绍CC构建操作及监视。
1. 启动CC服务器
通过执行其根目录下的cruisecontrol.bat文件来启动CC。控制台显示“BuildQueue - BuildQueue started”，则说明CC服务器已成功启动。

在启动服务器之前，我们可以打开cruisecontrol.bat文件并修改倒数第三行相应功能的端口数值来指定服务器占用的系统端口，在本例中我们将默认8080端口。

2. Report管理方式
在前一节中介绍CC有两个入口可以管理集成项目，其中CC较早之前提供了Report方式控制主界面，通过http://localhost:8080/cruisecontrol/ 进入，界面如下：

在列表中显示了各个项目的相关信息，包括当前状态、上次失败时间、上次成功时间、构建次数等信息，同时Build按钮可以让CC立即检测工程状态。点击相应工程名称，则可以进入该工程的详细页面首页，首页清晰明了，主要包括了构建历史信息、最近构建结果、最近构建版本信息等，该页面可以让我们对当前工程的集成信息一目了然，便于我们对不同的集成结果做出相应的处理。页面上部的导航按钮可以让我们进入不同信息的查看界面，包括构建结果、测试结果、XML详细日志文件、状态统计、应用配置、控制台配置等信息。这些导航按钮根据工程设置的不同扩展任务而有所不同。

2.1. 构建结果
在第一个tag页上最上方显示的是该项目最新构建的基本信息（包括构建日期、时间、项目文件最近修改时间）、编译中的警告和错误、自动化测试结果以及本次项目变化具体的明细。

2.2. 测试结果
该tag页显示了自动化测试结果，该结果按照测试类分类，在每个测试类下显示了每一个方法的测试结果以及用时。每一个测试类中都有控制台输出日志，点击进入”system.out” 可以查看具体日志信息。

2.3. XML详细日志文件
记录该项目所有构建信息，如下图所示。
在该文件中记录了项目的基本信息、最后构建时间、最后成功构建时间、构建时间等信息，另外也包括项目配置信息，如JDK版本、构建操作系统等。

2.4. 状态统计
该tag页面通过不同类型图形显示了项目构建状态信息，在tag页面上方显示了页面总构建次数、成功次数和失败次数，接下来通过饼图显示成功与失败次数对比等统计信息。

2.5. 应用配置
CC支持在页面是配置Config.xml文件，首先可以通过“Reload from server”加载该应用的配置信息，配置内容包括Listeners、bootstrappers、Source Controls、Schedule、Log、Publishers等节点，修改完毕后点击“OK”按钮保存配置信息。

2.6. 控制台配置
在该tag页中可以对该项目控制进行配置，具体包括构建轮询时间、版本标签号、发布包命名格式等信息。

3. Dashboard管理方式
我们现在比较常用的(也是CC推荐)是通过Dashboard界面来管理项目集成，其地址为 http://localhost:8080/dashboard。该方式以不同颜色的色块表示不同项目构建的状态，能够直观地观察到不同项目当前状态，当把鼠标放在小方块上时，会显示该项目的主要信息。在页面的右边显示了构建项目的状态统计，能够了解构建概况。另外几个小工具，提供了RSS连接以及更加人性化页面配置工具。
在介绍Dashboard之前我们熟悉CC中项目的状态， CC把项目分成三类，Discontinued(停止)，Inactive(不活动)，及Active(活动)。

Discontinued(停止)表示CC可以找到该项目的日志文件，但在配置文件(Config.xml)中并没有该文件。所以CC不会去构建它，但你可以看到这个项目过去构建的历史信息。如果想把这个项目从CC中删除，只有把该项目的日志目录删除才行。如果该项目名为"petclinic"，目录当该是${CruiseContor.Home}/logs/petclinic。
Inactive(不活动)表示CC在配置文件(Config.xml)中发现了该项目，但是没有发现关于这个项目的任何历史信息，即在CC的日志目录中还没有该项目的日志文件，或日志文件被人为删除了。CC会根据配置信息对这个项目进行检查新版本并进行构建，当第一次构建完成后，CC就会生成日志，这个项目状态就会转为Active了
Active(活动)表示CC即可以找到该项目的日志文件，又在配置文件（Config.xml）中可以发现它。此时，这个项目可能是构建成功，也可能是构建失败，还可能是构建中。

Dashboard主要有四个tag页面，它们分别是Dashboard，Builds，Build Details和Administatiorn。
3.1. Dashboard
在Dashboard tab页面左边可看到所有项目的状态，不同颜色色块表示不同的构建状态

红色方块表示该项目最近一次构建是失败的
绿色方块表示该项目最近一次构建是成功的
灰色方块表示该项目可能是Inactive的，也可能是Discontinued。

另外在页面的右边看以看到对所有构建项目的统计信息，不同图标、数目表示所处不同状态项目的个数。

3.2. Builds
在该tab页面左中部显示了所有构建项目状态统计信息，右中部则是不同工具的链接，页面底部以列表方式展示了所有项目构建信息。

在每一笔构建信息中点击可以看到所有构建，点击图标可以查看所有成功构建。如果你将Force Build配置为true，在列表右侧有一个按钮，点击该图标可以强迫该项目进行构建，而不必等到其下一次检查，也不必等到它有版本变化。点击后在Builds页面和Dashboard页面可以看到正在构建图标。

另外可以通过有工具图标进行该项目RSS和JMX控制台配置，其操作见Report管理方式1.2.6部分

3.3. Build Details
此tab页面会列出该项目某次构建的详细信息，包括项目文件最近修改记录、构建日志、自动化测试结果、构建警告和错误，如果构建成功的话，在配置文件(config.xml)中配置的Artifacts也会在名为Artifacts的tab页上看到。
右侧的列表是该项目所有历史构建列表，点击其中一个构建，你就可以得到该次构建的详细信息。

3.4. Administration
该页面你可以看到About和Configuration两个子标签。
在About子标签中，你可以看到CC所用的环境信息，如CC的版本号、所用的操作系统和JDK版本等。

在Administration子标签中，你可以看到CC的Dashboard-config.xml文件内容。

本文链接

使用CruiseControl+SVN+ANT实现持续集成之三

2011-09-16T01:01:00Z

在启动服务器之前，我们可以打开cruisecontrol.bat文件并修改倒数第三行相应功能的端口数值来指定服务器占用的系统端口，在本例中我们将默认8080端口。

2.6. 控制台配置
在该tag页中可以对该项目控制进行配置，具体包括构建轮询时间、版本标签号、发布包命名格式等信息。

Discontinued(停止)表示CC可以找到该项目的日志文件，但在配置文件(Config.xml)中并没有该文件。所以CC不会去构建它，但你可以看到这个项目过去构建的历史信息。如果想把这个项目从CC中删除，只有把该项目的日志目录删除才行。如果该项目名为"petclinic"，目录当该是${CruiseContor.Home}/logs/petclinic。
Inactive(不活动)表示CC在配置文件(Config.xml)中发现了该项目，但是没有发现关于这个项目的任何历史信息，即在CC的日志目录中还没有该项目的日志文件，或日志文件被人为删除了。CC会根据配置信息对这个项目进行检查新版本并进行构建，当第一次构建完成后，CC就会生成日志，这个项目状态就会转为Active了
Active(活动)表示CC即可以找到该项目的日志文件，又在配置文件（Config.xml）中可以发现它。此时，这个项目可能是构建成功，也可能是构建失败，还可能是构建中。

红色方块表示该项目最近一次构建是失败的
绿色方块表示该项目最近一次构建是成功的
灰色方块表示该项目可能是Inactive的，也可能是Discontinued。

另外在页面的右边看以看到对所有构建项目的统计信息，不同图标、数目表示所处不同状态项目的个数。

3.2. Builds
在该tab页面左中部显示了所有构建项目状态统计信息，右中部则是不同工具的链接，页面底部以列表方式展示了所有项目构建信息。

另外可以通过有工具图标进行该项目RSS和JMX控制台配置，其操作见Report管理方式1.2.6部分

在Administration子标签中，你可以看到CC的Dashboard-config.xml文件内容。

本文链接

使用CruiseControl+SVN+ANT实现持续集成之二

2011-09-16T00:55:00Z

1. 环境搭建
1.1. 下载及目录介绍

从官方站点http://cruisecontrol.sourceforge.net/download.html下载一份最新的 CC 压缩包，最新的版本号为2.8.4

下载了cruisecontrol-bin-2.8.4.zip 直接解压到E盘下，文件结构如下图：

apache-ant-1.7.0：CC中使用ANT工具
artifacts：CC编译生成发布包
etc：自带容器Jetty对应的配置文件
lib：自带容器Jetty所需要到的Jar包
logs：各项目生成日志存在文件夹
projects：存放各项目文件目录，进行程序的编译
webapps：CC自带应用程序存放目录
cc-config：用于CC环境变量配置
cruisecontrol：主应用程序CC目录
dashboard：用于编译结果发布程序
documentation：CC相关文档
config.xml：用于CC编译配置文件，通过修改配置文件引入不同的插件，执行不同的编译流程
cruisecontrol.bat：在WINDOWS环境下进行启用CC批处理脚本
cruisecontrol.sh：在Linux等环境下启动CC脚本
dashboard-config.xml：Dashboard配置文件

1.2. 运行环境
使用JAVA开发的CC，当然需要运行在JDK下并通过Web容器进行发布，具体要求如下：

CC需要运行在至少JDK 1.4环境中，在环境变量中设置有JAVA_HOME，并把java/bin加入到path中；
CC已经内建集成了ANT，不需要单独引入；
CC可以运行在多种应用服务器中，在自带压缩包中捆绑了一个开源应用服务器，那就是Jetty 6，下面为了尽快建立我们的环境，以下将使用该容器。

1.3. 快速启动CC
运行根目录下批处理文件cruisecontrol.bat，出现如下界面：

运行成功后，我们可以在浏览器输入 http://localhost:8080/cruisecontrol/ 来验证一下结果（采用Jetty默认的设置，端口号为 8080）

如果看到上图结果，恭喜你已经成功启动CC。
另外CC提供了更加人性化结果展示Dashboard界面，在浏览器输入 http://localhost:8080/dashboard/

2. 配置介绍
当CC服务器启动时，会自动检测配置信息中的任务信息，并对其进行校验和初始化，之后所有的工作，都是依据该配置信息进行的。
CC的配置使用了其安装目录下的config.xml文件，我们可以通过文本编辑器打开该配置文件，编辑各种配置信息。配置信息的定义遵循了标准XML文件格式，同时遵循了ANT自动构建配置信息的规则。

config.xml
<cruisecontrol>
<project name="connectfour">

     
     <listeners>
             <currentbuildstatuslistener file="logs/${project.name}/status.txt"/>
         </listeners>

         
          <bootstrappers>
             
                 <antbootstrapper anthome="apache-ant-1.7.0" buildfile="projects/${project.name}/build.xml" target="clean" />
          </bootstrappers>

         
         
          <modificationset quietperiod="30">
             
             <filesystem folder="projects/${project.name}"/>
          </modificationset>

         
          <schedule interval="300">
             <ant anthome="apache-ant-1.7.0" buildfile="projects/${project.name}/build.xml"/>
          </schedule>

         
          <log>
             <merge dir="projects/${project.name}/target/test-results"/>
          </log>

         
         <publishers>
             <onsuccess>
               
                 <artifactspublisher dest="artifacts/${project.name}" file="projects/${project.name}/target/${project.name}.jar"/>
             </onsuccess>

        
         <htmlemail
           charset="UTF-8"
           mailhost="test163.com"
           defaultsuffix="@xxx.com"
           username="xxx@163.com"
           password="xxx"
           returnname="CruiseControl"
           returnaddress="xxx@163.com"
           subjectprefix="构建日志"
           xsldir="webapps/cruisecontrol/xsl"
           css="webapps/cruisecontrol/css/cruisecontrol.css">
           <always address="xxx@xxx.com.cn"/>
           <failure address="xxx@xxx,yyy@yyy.com.cn"/>
         </htmlemail>
         </publishers>
     </project>
</cruisecontrol>
build.xml

<!-调用ANT执行集成流程，包括清空目录、编译、休眠、测试、打包 -->
 <project name="connectfour" default="all">
     <target name="all" depends="clean, compile, sleep, test, jar"/>
 
     <!-- 1. 删除根目录下target 目录-->
     <target name="clean">
         <delete dir="target" quiet="true" />
     </target>
 
     <!-- 2. 编译程序，创建目录并编译程序，编译输出为target/classes目录下-->
     <target name="compile">
         <mkdir dir="target/classes"/>
         <javac srcdir="src" destdir="target/classes"/>
     </target>
 
     <!-- 3. 在创建前等待60秒，用于Dashboard观察进程-->
     <target name="sleep">
         <echo message="Sleeping for a while so you can see the build in the new dashboard" />
         <sleep seconds="60" />
     </target>
 
     <!-- 4. 进行自动化测试，依赖任务为compile-->
     <target name="test" depends="compile">
         <mkdir dir="target/test-classes"/>
         <!-调用junit进行自动化测试-->
         <javac srcdir="test" destdir="target/test-classes">
             <classpath>
                 <pathelement location="target/classes"/>
                 <pathelement location="lib/junit.jar"/>
             </classpath>
         </javac>
 
         <!-创建测试结果存放目录-->
         <mkdir dir="target/test-results"/>
         <junit haltonfailure="no" printsummary="on">
             <classpath >
                 <pathelement location="target/classes"/>
                 <pathelement location="lib/junit.jar"/>
                 <pathelement location="target/test-classes"/>
             </classpath>
             <formatter type="brief" usefile="false"/>
             <formatter type="xml" />
 
             <!-测试文件所在文件地址-->
             <batchtest todir="target/test-results" >
                 <fileset dir="target/test-classes" includes="**/*Test.class"/>
             </batchtest>
         </junit>
     </target>
 
     <!-- 5. 程序打包，依赖与compile任务-->
     <target name="jar" depends="compile">
         <jar jarfile="target/connectfour.jar" basedir="target/classes"/>
     </target>
 </project>

2.3. 执行配置解析
一个持续集成项目是从project节点开始的，对该项目进行的操作都会作为子节点存在与该根节点之下。对于每一个project节点，CC系统都会将其当作一个处理单元，并在最初建立该项目的时候进行初始化操作。
name是project节点常用的属性，也是必设且值唯一的属性，该属性的值会在整个CC系统使用，包括配置文件的${project.name}变量值。
在一个项目节点中，我们可以定义监听器、本地目录位置、变更轮询目录位置、轮询间隔、任务执行、单元测试、日志记录等多种项目操作，同时CC系统支持插件扩展功能，这些扩展插件可以直接在一个项目中使用。
2.3.1. 轮询版本控制系统
版本库轮询机制是使用modificationset进行配置的。CC系统内置的轮询模块会根据设定的时间段对版本库进行检测，一旦发现版本库发生变更，就会调用Check Out Build Test Publish等一系列的操作，对最新的代码进行集成，并运行一系列预先设定的任务。
CC支持十多种版本控制系统，比如CVS、SVN、Starteam、VSS等，对这些版本控制系统的调用，只需要配置相应的节点名称即可。本文以SVN版本管理系统为例。在modificationset节中，我们看到唯一的一个子节点：

<svn localWorkingCopy="projects/CM/${project.name}/src/${project.name}"/>

该节点使用了svn关键字，表示当前工程使用的版本控制系统是SVN，localWorkingCopy属性的值是告诉CC本地的拷贝目录，其余的工作则由CC内置的操作模块进行。
2.3.2. 执行构建脚本
实质上，执行构建脚本也是CC的一个可定制任务，但由于自动构建是持续集成的一个重要组成部分，因此在此单独提出。
CC的自动构建是使用ANT工具来进行的，当然我们也可以使用其它的自动构建工具来替代（比如Maven），这些的工具仅仅是体现在一个任务配置语句上，在此，以ANT工具为例。
在schedule节，我们同样使用了一个子节点来描述自动构建工作：

<ant anthome="ant6" buildfile="projects/CM/${project.name}/src/${project.name}/build.xml"/>

该节点使用了ant关键字，表示该任务使用了ant来进行自动构建任务，anthome属性则指定了ANT工具的具体位置，buildfile属性则指定了ANT进行自动构建所使用的配置文件Build.xml文件的路径。
这样，在CC决定进行自动构建任务时，会根据设定找到执行所使用到的信息。
2.3.3. 执行单元测试
CC可以自动侦测自动构建配置文件中单元测试的任务，并在代码集成完毕将执行结果反馈到相应的模块。
ANT支持xUnit系列的单元测试框架，只需要在配置文件中加入一个target节，即可在自动构建完成之后，进行单元测试工作，有关的详细配置，请参阅ANT官方文档。

本文链接

使用SVN+CruiseControl+ANT实现持续集成之一

2011-09-16T00:49:00Z

在前面的文章中，介绍自己当时所在团队的处境(使用.NET开发)，一个不到十个人的研发团队在保证正常开发进度同时需要并发支持四、五十个项目问题处理，经常为了程序版本冲突、日常测试版本、发布版本提供等重复枯燥无味的手工劳动，导致团队成员身心俱疲。经历这样痛苦的一段时间，终于忍受不了，通过命令行实现了包括获取、编译、发布过程的集成，大大减轻版本编译的时间，此时还能见到团队成员一边编译程序一边聊天轻松的笑脸，这就坚定了自己持续集成的做法，不过可笑是当时自己对持续集成没有任何的概念，只是当时的状况逼自己走了集成之路。
这个工具在经历半年使用进行了一次升级，提供了更多的选项功能，参见升级版本介绍。另外随着公司业务的发展，2009年自己负责推出一个基于JAVA的产品平台，这个平台中包括了七八个子系统。一个困难就出现在我们面前，为了保持以前每周一次发版，每次编译发布都需要两三个小时，为了摆脱这种困局找了很多资料，学习了很多新的思想，对比了很多工具，最终使用了基于CruiseControl(以下简称CC)实现持续集成。

1. 持续集成概念

对于持续集成（Continuous Integration）这个术语源自 XP（极限编程）的一个最佳实践，随着XP近几年的推广持续集成被大家认可并实践，但持续集成并非 XP 的专利，持续集成完全可以应用在采取非XP 方法的项目里面。持续集成也不是一个新的概念，在这个术语出现之前，日创建（daily build）提供同样的含义，这个典型的代表就是微软，他们每天的工作都开始于每日零点的版本构建。持续集成和日创建主要区别就在于实施的频率上，随着 XP 社区的大师级人物 Martin Fowler等人所著《Continuous Integration》为其正名，持续集成这个术语就越来越多地出现在原来日创建出现的位置。

2. 持续集成优点

在传统开发模式中项目按照模块进行划分，等开发完成后再集成到一起进行测试，这种开发方法在小规模程序开发过程中并没有太大的不足。但随着软件技术的发展，软件规模也在扩大，软件需求越来越复杂，软件已经不能简单地通过划分模块方式来开发，因为很多Bug在项目早期就存在了，如果在最后集成的时候才发现问题，开发者需要在集成阶段花费大量的时间来寻找Bug，由于软件的复杂性，需要花费大量的时间进行定位，甚至有些需要调整底层架构。在这个阶段的除虫会议（bug meetings）特别多，会议的内容基本上都是讨论 bug 是怎么产生的，最后往往发展成为不同模块的负责人互相推诿责任。
持续集成最大的优点是可以避免这种传统模式在集成阶段的除虫会议。持续集成主张项目的开发人员频繁的将他们对源码的修改提交(check in)到一个单一的源码库，并验证这些改变是否对项目带来了破坏，持续集成包括以下几大要点：

访问单一源码库，将所有的源代码保存在单一的地点（源码控制系统），让所有人都能从这里获取最新的源代码，提倡开发人员频繁提交修改过的代码。
支持自动化创建脚本，使创建过程完全自动化，让任何人都可以只输入一条命令或者几次点击就完成系统的创建。
测试完全自动化，要求开发人员提供自测试的代码，让任何人都可以只输入一条命令或者几次点击就运行一套完整的系统测试。
支持自动化部署，能够按照不同的要求发布到测试、发布服务器，提供测试环境和发布程序包；
自动提供集成信息，按照不同情况提供通过邮件、报告等方式提供每次集成结果，并且提供发布平台大家能轻易看到集成的进度和结果

持续集成的关键是完全的自动化，自动读取源代码、编译、测试、部署、信息发布。对于每次成功的创建，要求在这个自动化过程中的每一步都不能出错，而最重要的一步是测试，只有最后通过测试的创建才是成功的创建。
在持续集成里面创建不再只是传统的编译那么简单，创建还应该包括自测试，自测试的代码是开发人员提交源码的时候同时提交的，是针对源码的单元测试，将所有的这些自测试代码整合到一起形成测试集，在所有的最新的源码通过编译之后还必须通过测试集的测试才算是成功的创建。这种测试的主要目的是为了验证创建的正确性，McConnell 称之为“冒烟测试”，在持续集成里面，这叫做集成验收测试Build Verify Test，简称 BVT。BVT 测试是质量的基础，QA 小组不会感受到 BVT 的存在，他们只针对成功的创建进行测试（如功能测试）。
持续集成有一个与直觉相悖的基本要点，那就是“ 经常性的集成比偶尔集成要好”。Martin Fowler 认为对于持续集成来说，集成越频繁，效果越好，如果你的集成不是经常进行的（少于每天一次），那么集成就是一件痛苦的事情，如果集成偶尔才进行一次（一周甚至一个月），等到集成阶段发现bug，然后找原因解决bug，会耗费你大量的时间与精力，而且这种方式有点像传统的集成模式，这违背了持续集成的初衷。
根据 Martin Fowler 的观点，项目 bug 的增加和时间并不是线性增长的关系，而是和时间的平方成正比，两次集成间隔的时间越长，bug 增加的数量越是超过你的预期，解决 bug 付出的工作量也越大，而你越觉得付出的工作量越大，你就越想推迟到以后去集成，企图到最后一次性解决问题，结果 bug 产生的就更多，导致下一次集成的工作量更大，你越感觉到集成的痛苦，就越将集成的时间推后，最后形成恶性循环。
需要注意的是从项目的一开始就引入持续集成可以尽早的发现 bug，但是并不代表持续集成可以帮你抓到所有的 bug。持续集成的排错能力取决于测试技术，众所周知，无法证明已经经过测试的代码就已经找到了所有的错误。
前面列举了持续集成这么多优点，但是创建一个持续集成的环境技术上是比较复杂的，也需要一定的时间，关键是在于持续集成可以“及时”抓到足够多的 bug，从根本上消除传统模式的弊端，这就已经值回它的开销了。
ThoughtWorks 公司开放了其持续集成的工具CC的源代码，持续集成对于大部分开发人员来说就不再只是停留在口头上的漂亮的术语，任何人在掌握了持续集成的基础理论后，都可以使用CC来体会持续集成在项目开发中的巨大威力。

3. 集成框架
下个图描述持续集成的硬件环境，图中包括了一台独立的源码库服务器以及开发人员的终端（同时也是源码库服务器的客户端），出自对性能的考虑，建议CC 在一台独立的服务器上运行。当然你可以将 CC 放在发布服务器上甚至某个开发人员的终端上。

4. CC内部工作架构
下图是CC系统内部工作架构图：

CC主要依赖Build Loop循环构建实现，通过读取Config.xml配置文件信息，在每次轮询中完成源代码的检测、编译，然后把编译的版本发布Web容器中，以此同时把日志信息、发布结果通过RSS、邮件、网站等形式发布给干系人。
4.1. Build Loop
前面在讨论持续集成的时候讲到其最重要的特征之一是自动化，而 CC 的 Build Loop 就是为支持自动化而设计的，Build Loop 也是 CC 的核心。
Build Loop 从字面上理解就是循环创建的意思，CC 提供了一个守护进程( daemon)，该进程自动根据配置的时间间隔（也可以指定某个具体时间）读取 CC 配置文件并进行循环创建（build cycle），每次 CC 都会重新加载配置文件（修改了配置文件不用重新启动 CC）。
Build Loop 过程中所做的工作如下：访问源码控制系统，查看是否有代码被修改，如果有，获取源码的新版本，并根据配置对源码进行一次 Build，创建一个日志文件，最后向开发人员通知 build 的结果，活动图如下：

因为 Build Loop 是根据配置文件的内容来进行的，根据上面 BuildLoop 所做的工作，我们可以猜出配置信息主要应该包括：定时创建的时间和源码库的访问信息（检查源码变化情况），创建任务信息（如指定 Ant 文件），记录日志（创建结果），通知（通知的内容可以定制）。
4.2. CC 插件（Plugin）
CC 设计思想是one-size-fits-all，也就是CC 是由一个很精小（但是很强大）的核心（ Build Loop）以及一些外部插件组成，这给使用者提供了很大的扩展空间，使用者可以根据需要扩展 CC的功能（提供新的插件），而且 CC 是开源项目，你还可以查看源码并修改CC提供的插件。CC提供了六种不同类型的插件：Listener、Bootstrappe、Modificationset、Schedule、Log以及Publisher，CC 的配置是围绕这些插件展开的，下面对这些插件进行一个简单的介绍：

Listener：用于处理一些项目有关的事件；
Bootstrapper：在 CC 进行创建之前运行，是创建前的准备工作
Modificationset：访问源码控制系统（如 CVS，VSS，ClearCase 等等），查看源码自上一次 Build 之后是否被修改过，并据此决定是否需要进行下一次 Build。
Builder：对项目进行创建，熟悉 ANT 的使用者应该很清楚创建的含义，这里简单提一下，一次典型的创建包括了对项目源码的编译，测试，打包
Schedule：设置轮询时间并且指定使用ANT编译所使用的配置文件地址
Publisher：用于发布创建的结果，可以通过 email 的方式通知开发人员。

本文链接