敏捷开发思想谈(一)

标签: 敏捷开发 思想 | 发表时间:2012-01-28 20:39 | 作者:song
出处:http://ucdchina.com/rss/all

       敏捷的原则

      敏捷开发其实并没有标准型的流程。SCRUM也只是众多衍生体中的一个。实际上就算是SCRUM的实际使用也情况千差万别。所以首先,请大家有这么个概念:
       敏捷开发绝对不是一套一成不变的标准化流程。而更多的是一种自适应,自我优化的流程优化理念。

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

      所以:

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

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

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


        迭代 想与得

        为什么我们要迭代?

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

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

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

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

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

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

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

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

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

      当我们清醒地认识到:

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

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


      旋转上升

      什么是迭代

     那么,迭代究竟是什么?

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

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

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

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

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

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


        陀螺的转动

        如何迭代

        迭代的漩涡

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

     

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

        迭代的步骤

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

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

      l  一个迭代的长度

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

      再进一步深入:

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

      l   系统

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

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

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

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

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

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

      迭代的节奏

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

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

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

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

     

相关话题: 敏捷设计和敏捷开发 源地址: http://djt.open.qq.com/portal.php?mod=view&aid=115

相关 [敏捷开发 思想] 推荐:

敏捷开发思想谈(一)

- - 所有文章 - UCD大社区
       敏捷的原则.       敏捷开发其实并没有标准型的流程. SCRUM也只是众多衍生体中的一个. 实际上就算是SCRUM的实际使用也情况千差万别. 所以首先,请大家有这么个概念:.        敏捷开发绝对不是一套一成不变的标准化流程. 而更多的是一种自适应,自我优化的流程优化理念.

敏捷开发思想谈(二)

- - 所有文章 - UCD大社区
敏捷开发思想谈(一)     http://ucdchina.com/snap/11431   .        为什么需要版本.       我们的设计在我们的脑海里,很可能和在别人脑海里得到的认识是不一样的. 或许大家都能有幸得到统一的认识,但是做出来实际体验的时候又不一定能够符合我们的预期.

敏捷开发——Programmers(27)

- plidezus - 西乔的九卦
载于《程序员》杂志2011年第7期. 从这一期起,开始在杂志上登出整P的大幅漫画,需要看大图的同学们,讯猛点击下图. 这个系列的漫画讲述程序员——这种神秘人类的囧事,故事多来源于我身边的程序员朋友,且以互联网开发背景为主. 如果你有什么可乐的关于程序员的故事、对话、代码,愿意通过漫画的形式分享,请给我发邮件.

漫谈敏捷开发

- scotty - ITeye论坛最新讨论
软件开发是一种非零和博弈,意思是某一方的获得不是建立在另一方的损失之上,所以软件开发必须实现双赢,帮助客户成功的同时帮助自己成功. 如:通过软件帮助客户把手上的5块钱变成50块钱,然后从客户那里拿5块钱. 通过软件帮助客户节约50块钱,然后从客户那里拿5块钱. 传统的汽车制造是以计划驱动,如根据往年的经验判断今年应该生产多少汽车,但是这样带来的问题是有可能等汽车生产出来,市场已经不需要了,而这就是一种极大的浪费.

[趣图]敏捷开发:Programmers

- FPb - 草根网
载于《程序员》杂志2011年第7期. 从这一期起,开始在杂志上登出整P的大幅漫画,需要看大图的同学们,讯猛点击下图. 这个系列的漫画讲述程序员——这种神秘人类的囧事,故事多来源于我身边的程序员朋友,且以互联网开发背景为主. 如果你有什么可乐的关于程序员的故事、对话、代码,愿意通过漫画的形式分享,请给我发邮件.

关于敏捷开发(Scrum)

- - 前端攻城师-攻城记
敏捷开发的话题已经由来已久,但是我们如何实施敏捷开发一直成为争结. 很多团队协作性差,产品、技术、测试、运营脱节,我们如何解决这些问题,成为了很多团队面临的问题. 有幸接触到Scrum项目管理,我想如果我们真的把Scrum实施起来,协作一定会上一个层次. 1.一切从产品出发 我一直信奉一个出色的产品经理不应该因为种种原因降低产品质量,不要因为技术难度大,不要因为项目时间紧,不要因为人员不足,领导压力,其实产品要说的就是:“喔.

Android敏捷开发指南

- - 互联网的那点事
本文紧密结合移动开发方法与技术,围绕Android平台的开发探讨提供更高质量移动产品的解决方案. 作者中分析了移动开发中常见的问题,从两方面阐述了ThoughtWorks使用的测试开发方案和相应的架构方法与常用工具应用,并进一步阐述了为移动开发流程所提供的持续发布方案. 随着云计算、移动互联等一系列新技术概念的崛起,新一轮的IT经济正在不断扩大发展.

Scrum敏捷开发简介

- - CSDN博客编程语言推荐文章
       Scrum是一种灵活的敏捷软件开发管理过程. Scrum方法由Ken Schwaber和 Jeff Sutherland 提出,它将软件开发团队比作橄榄球队,全队有明确的最高目标:发布产品的重要性高于一切. 团队高度自治,队员们熟悉开发过程中涉及到的各种技术,紧密合作,确保每个迭代都朝着最高目标推进.

敏捷开发 Scrum 总结

- - 行业应用 - ITeye博客
  最近把之前学习 Scrum 的资料整理为一篇文档,在接下来的团队和项目开发中,根据项目的情况引入 Scrum 的一些实践,提高团队成员之间的协作能力和项目的交付质量.          参考资料:. 《轻松Scrum之旅—敏捷开发故事》、《敏捷无敌》.          Scrum 工具.

敏捷个人和敏捷开发

- beralee - 博客园-首页原创精华区
    自2001初成立了敏捷联盟到现在10年的推广,敏捷开发已日渐成为当前IT行业软件开发的一种主流方法. 没有银弹,任何方法都不可能解决所有问题,反而方法应用本身还会带来新的问题. 我在今年6月份上海举办的ScrumGathering中进行了一场敏捷个人话题的分享,我说到,想要Doing敏捷并不难,只要花上几天功夫学习敏捷知识之后就可以在小范围团队中去实践了,而要做到真正的Being敏捷则并不容易,而导致并不是真正敏捷的原因中,人是一个主要问题之一,这也是为什么现在敏捷社区中对人开始越来越关注的原因.