敏捷游戏

敏捷游戏

石新   2012-07-05

        简单地说，敏捷就是“增量+迭代”，但更确切地说，敏捷的核心应该是一种新的游戏规则的建立。

1.       游戏背景

        大家的苦大家懂的，不想赘述。

2.       游戏目标

       产品的最终目的是实现用户价值和商业价值，而有价值的产品必须要有质量的保障，有质量的产品不一定有价值。所以敏捷游戏需要以产品价值最大化为终极目标，辅之以精益的质量保证，二者缺一不可。

3.       游戏角色

       业务分析师、开发人员、测试人员

4.       游戏规则

       以不影响产品的质量为前提，以实现产品的最大价值为目标，从以往的拒绝变化发展为欢迎变化。欢迎变化并不是任其变化，在与客户合作和影响变化的细节上，应合理的地控制客户的期望值，使客户了解变化对系统的影响度，确定变化优先级，对不太重要的的要求推迟到下一个版本中实现。建立IT与客户都认可的游戏规则，既要实现客户的比较满意的目标，又要避免出现项目延期的危险，实现双赢。

5.       团队建设

5.1.      营造气氛

       敏捷的团队应该是主动，高效，有激情的团队，团队内应该充满平等、自由、轻松、快乐的空气。人是团队中最重要的元素，能够有效地发挥出发挥人的能动作用，才是项目成功的关键。敏捷开发比起传统的开发方式，使得开发人员承受了更大的负担与压力，自我约束的同时也是给自己做出了承诺，所以营造轻松、和谐的氛围至关重要，让每一个团队都体会到游戏的乐趣所在。

5.2.      沟通交流

       沟通交流是团队成员与成员之间最好的润滑剂，沟通顺畅也需要轻松的环境气氛。保障团队内外顺利交流应该也是团队建设的重要任务之一。

       敏捷游戏中会有各种约定的交流时间和形式，例如，每天的站立会议。你要说出昨天做了些什么，今天会做些什么，遇到了什么困难是否需要别人的帮助。站立会议鼓励每个人说出事情的真相。作为每一个开发人员都应该做到“放开你的心”，领取的任务进度滞后或者出现其他问题时，都应该在站会中如实的提出来，不要积累任务债务，否则你的工作会变得苦不堪言；不论是系统架构的大问题，还是算法优化的小问题，有了困难就大胆的向你最值得信任的同伴来寻求帮助，没有人会嘲笑你，也没有人会冷漠的不去理睬你的困境。一个自组织的团队，应当是一个温馨而又和谐的集体。每个人都会努力的帮助其他的人，帮他解决他的问题并从中积累更多的经验。

       除了内部的交流，还应注意系统外的交流协作。在我之前参与的项目中，过于清晰地划分了上游系统与和下游系统团队的范围，使得上下游系统之间的交流还是存在障碍，造成有些不必要的问题发生。起初划分两个团队是为了节约会议时间，然而不同参会更屏蔽了上下游系统间的信息流通。

5.3.      激励胜过惩罚

       团队管理的方法有很多，但惩罚的方法的确不可取，因为不是人人平等的惩罚是没有公平可言的。大家每个人的分工职责是不同的，有些人必须在犯错的红线边上走来走去，正所谓“常在河边走，哪有不湿鞋”，而有些人不仅离河边很远，甚至连鞋都没穿。所以我认为，敏捷的团队都应以激励为主，惩罚会让团队成员产生反感情绪，影响激情。况且惩罚可以达到的效果，激励一样可以达到。

6.       游戏大招：

6.1.      持续集成

       尽管持续集成经常与敏捷过程联系在一起，但其并非是敏捷游戏中才有的，它是软件质量的有力保证策略。软件开发是一项要求团队协作性非常强的工作，每个人的工作都有可能影响到系统整体，通过它，开发团队的成员频繁的整合他们之间的工作，并通过时时运行测试，保证软件现有的功能不被破坏，自动分析现有代码的状态并发布相关的报告，及时暴露问题，及时解决，也为持续交付提供有利保证。

6.2.      自动化测试

       自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。因为在持续集成过程中，不仅要不断构建，而且要时时测试。在此过程中，为了节省人力、时间，提高测试效率，便引入了自动化测试。

6.3.       持续交付

       有人说项目初期很难有产品交付，其实是没有认清敏捷游戏中持续交付的产品的标准：可用并非完美。每次交付的产品不一定是最好的，但一定要是可用的，其价值大小应取决于所取得功能实现是否是其关键所在。项目初期应对实现功能要有所取舍，先实现系统关键功能，甚至可以不是全流程的，因为此时的全流程可能连客户自己都是说不清楚的，还是先从清楚的重要的做起吧。但客户是否也认可这个产品可以交付呢？不认可其实还是没有认可这个游戏规则。

       项目初期的迭代要切记不要把“饼”构想的太大。我之前参与的一个项目是一个优化项目，项目初期很大程度上左右了项目初期迭代产出的必需要求，过大的构想了初期产品的实现功能，导致项目初期开发问题频出。其实迭代还是要以主要面向切面，尽量把握平面的开发策略，真正做到稳定持续交付。

7.       联机游戏

       没有客户参与的敏捷开发只能算是单机游戏，技能皆是从单机游戏练起，但长时间单机作战必会感觉索然无味，那么如何才能让客户参与进来这个游戏呢？

7.1.      人在一起

       IT与客户之间的矛盾多是由于二者之间的沟通障碍、互不信任产生，去除IT与客户之间的信任屏障，实现彼此互通透明化才是解决矛盾所在。所以敏捷游戏推崇客户与IT工作在一个环境下，让彼此的工作透明化。

7.2.      心在一起

       共处在同一个工作环境之下，常此以往，客户定会体会到IT的苦，IT也会感受到客户的难。最后客户与IT心在一起，为了大家的共同目标，为了大家的共同利益，共同奋斗。

7.3.      遵守游戏规则

       在整个敏捷游戏中最重要、最有难度的还是让客户认可并遵守游戏规则。在很多场景中，业务部门都以“客户”自居，认为摸索、返工这些事情都是开发组的负担，与自己无关。但实际上，如果开发混乱，真正受害的无疑是业务人员这些终端用户。因此应该以有我的精神，去帮助那些为自己“交付价值”的开发人员，最终自己也将受益。

8.       游戏BUG：

8.1.          文档问题

       在敏捷开发的过程中，并没有明确要求任何形式的文档产出。虽然敏捷开发中不反对文档，但根据它的思想，给了开发人员一个尽量少写或不写文档的借口。瀑布模型的文档驱动方式的确有些矫枉过正，但必要的有价值的文档记录也是极其重要的，否则新进项目的同事或者日后运维的同事就有的苦头吃了。必要的文档资料也为项目人员离职之后可能会产生的知识空白提供了一定的保障。代码就是文档还是过于理想化。

8.2.      敏捷开发模式会使系统整体设计不足

       敏捷游戏迭代的开发方式使得设计只能是面向当前的，而不是面向整个系统的，这样会造成对系统整体设计把握不足，所以，我认为敏捷开发比较适用于轻量级系统项目，大型系统项目中还是要谨慎使用敏捷开发。

9.       游戏心得

9.1.      just do it

       敏捷开发迄今为止也没有一个执行规范，实施敏捷，要以游戏的目标结果为导向，适合自己方法都可以用，切不可生搬硬套，懂得舍弃一些不适合本身的工具方法。实施敏捷，，just do it就好，放弃原来的开发模式中繁琐、冗余的工作，引入敏捷中适合本身环境的工作及方法。假敏捷或者半敏捷的问题其实是一个伪问题，因为敏捷本身就是一种解放的思想。不应该再像传统的软件工程的思想那样束缚我们。不应该在敏捷的大潮中随波逐流，而更应该学会弄潮。

9.2.      去除英文单词

       敏捷过程中不要使用过多的英文单词，开发同事本来就是刚刚接触敏捷，而且大家的英语水平也各有差异，过多地使用英文专业术语，大大增加了沟通难度、理解难度，降低沟通效率。为了体现敏捷而使用了大量敏捷中的英文词汇更是不可取的，因为外国友人本来就很喜欢在一些概念上做文章，其要表达的含义完全可以用简单的中文词汇替代。

9.3.      8小时工作制

       敏捷的效果应该并没有字面上面的意思那样可以让一个项目的工期缩短，想依靠敏捷来“敏捷”的想法是不现实的。一切加班的项目都是有问题的，因为项目的计划当中肯定都是没有“加班”这项工作的。那应该如何解决工期短任务重的问题呢？前文已经说到，需要通过一个新的游戏规则的建立，别无他法。

9.4.      杜绝“竖井式”分工

       在敏捷项目的迭代开发过程中，容易出现团队成员的习惯分工现象，即开发人员领取任务时会挑选比较熟悉的开发内容来做，或者挑选之前已进行过开发工作的任务来做，久而久之，这样的用户故事被拆出来之后，其就会被赋予了一个隐形的标签，这个任务应该由谁来做。这样虽然在某种程度上体现了信息最大化的原则，会提高开发效率。同时，也带来了生产隐患。一部分代码长时间在一个人手里完成，减少了开发人员之间的互通性，代码质量问题也会不易被发现。

       上面的问题可以用结对编程解决，但是这样还是有人为的因素存在。我认为，敏捷游戏中的领取任务并没有太大意义，开发人员被赋予的开发承诺应该实现在评估工时阶段，而不是领取任务阶段，每个人都应该为评估出的工时负责。领取任务可以改为系统随机分配方式，只要保证每人合计工时大致相等即可。这样就从根本上杜绝“事不关己”的问题产生，使大家在迭代启动会议上阐述需求时就开始事事关己，评估工时时更要准确负责，提高会议沟通效率。

10.   小结

       软件工程的游戏官僚，枯燥，束手束脚，而敏捷游戏却十分活泼，有趣，但更难把握。重点在于，我们能否从两个世界中取其精华。