re: z9999,敏捷开发

PassByYou

你拿工程语言到小白区讨论，你觉得这些东西有几个人能理解？你提出敏捷就要参与讨论，并且要坚持立场。坚定立场并不是说，要固执己见，你大可以向血泉他们虚心学习，学习对方的优点，但坚持敏捷思想的开发立场。

你能够认识到开源，做这么多贡献，素质很高，为什么还认识不到这些是是非非？


先统一交流语言，我基于以下规范来描述我的工程化结构和思想

软件工程
http://en.wikipedia.org/wiki/Software_engineering

敏捷开发（你的模式，中国80%网游研发都是这种模式）
http://en.wikipedia.org/wiki/Agile_software_development

统一化过程（在你文章中提到的吉比特就是这种模式）
http://en.wikipedia.org/wiki/IBM_Rational_Unified_Process

iso（很多java工程）
http://zh.wikipedia.org/zh-cn/ISO_9000

cmm（很多java工程）
http://zh.wikipedia.org/zh-cn/CMM

在工程中应用最广的语言不是c++
Java，java工程性非常强，工程工具非常多，java就是为工程而设计的语言，随便你怎么说，java现在是最强的工程语言。太多例子了。自己google。

在实际工作中
我使用的正是敏捷，但并不是wiki上严格意义的敏捷，有时还在敏捷中混搭了一些统一化，质标的概念，我也在开源社区混，很多时候我的做法都是实用第一，实用的方法，有效率，容易有结果，在维护和升级中生命力旺盛，这才是做产品的本质。产品做大，系统架构必不可少。用标准的语言来说，这就是一门工程学。

架构在任何地方都非常讲究，尤其在大点的系统上。一个有用的架构，有的是从实践经验直接做出来的，有的设计者花了大量时间研究实现级代码来的。有时我做新架构，不带具体的实现，有的架构我会做上2个月，大部分时间都用在纸上画圈圈，阅读以前记录下来的工程笔记，而有时候做以前做过的，则是轻车熟路，几天就做完。

最好的架构其实没什么特别的，就是中间件，组件，有依赖关系的模块，抽像化模块设计等等概念。

敏捷应用
敏捷它追求的是实用，包括，多个人在一起协同开发（诸如今天我接着前天你的工作继续做），前提是你的工作要有个阶段性的结束，这种小阶段一般划分方式是2-3天工作量的小任务。

模型，控制器，视图的在实际工作中
应用敏捷中，所有模型都基于控制器（框架）和视图（应用，操作，输出层），而控制器和视图又尽力在减少模型设计的复杂度。最大量工作都集中在应用模型的实现上，控制器和视图的工作量，差不多只能占模型的1/10，或则更少

暂时就这么多，睡觉了

免费打工仔

楼主说的很有道理，我会虚心接受的。
我对敏捷一直很推崇，但并未完整的实践过，所以希望自己可以完成一个简单的工程，并加深对敏捷地了解。这里面肯定会有很多错误，还需要楼主以及其他牛来帮助我。

提到血泉，我到和他们老大又有一个有趣的对话，是关于敏捷的。他不接受敏捷，我问他为什么，他说：任何新的东西都需要承担风险，那么我这种小的公司，宁可按照已有的方法去做，也没必要去承担这个风险。我在想，这么说是有道理的，但是如果我可以证明，敏捷对我的项目有很大的帮助，是否可以让类似血泉这种不反对也不敢用敏捷的人走出这一步呢？所以我才希望把自己的实践过程公布出来。这也是另外一种开源吧。

提到小白，我是这么看待的。在我被人叫做小白的时候，我也喜欢喝别人辩论，这本身就是一个很有趣的事情。后来叫我小白的人慢慢少了。我仍然吧我的想法讲给所谓的小白们。我接触Ogre比较早，很多当时的小白现在都是小牛了。不论我曾经和他们讨论的问题对的错的，能让大家有个思考也是好的。

今天也是这样，我不是故意欺负小白，关键是所谓的小白数量很多，发言积极性有很高，这里面学生居多。我认为就如敏捷一样，他们会随着年龄不断对自己的思维重构。终究有一天他们会称为牛人之类的，虽不知道这些讨论是否对它们有价值，但是不论是小白还是牛人的参与，对我来说都是很有价值的，毕竟对于敏捷方面来说我本人也是个小白。

就如楼主的帖子，让我看了之后学到很多东西，我一直相信，知识和其他商品不一样，是可以可以相互共同提高的。

PassByYou

免费打工仔: Re:re: z9999,敏捷开发

楼主说的很有道理，我会虚心接受的。
我对敏捷一直很推崇，但并未完整的实践过，所以希望自己可以完成一个...

怀念一下以前写魔兽地编的美好时光,亲爱的z9999童鞋 [em1]

回到工程的正题上吧.

首先呢,工程模式,不管敏捷,统一化,质标,不管什么模式,工程其实一门关于生产管理的学科,我是觉得,你这样给人死灌概念有点不切实际,对工程学感兴趣的程序员,你根本不用教他,他们自己会想各种法子自学.而普及工程学,一般不同的公司,都有不同的过程方法,完美,吉比特,sohu的工程组,都是统一化模式,吉比特的统一化在这些公司中应该是最专业的,他们直接从外企引进来的实践经验,而中国80%中小网游企业,大部分都是敏捷+质标,各家各有千秋,我的衡量方法:凡是能成功开发出上市产品的工程队伍,无论什么模式,我觉得工程主管都是高水平的实践家.国内的中小企业有不少高手噢.成都这边更是高手成堆,经常都在一起喝茶.

在敏捷开发中,我倒是有许多的经验和感想,信手整理来,其实我在做工作中的大部分时间都处于和各种方法对话的一种二元空间中,这时候我感觉根本不属于这个世界,而我每次做完一个小阶段的工程工作,不管是几小时,还是若干天,我都会警觉,然后在同事和朋友面前我都装成若无其事,其实当时满脑子都是有点哲学倾向的方法,每每经历一次这种过程,我都要花上一两天才能让价值观回到真实世界中.而我每次深入工程,框架,实现和方法时,每次都很自然的会开辟很多新方法,有的是关于享受程序实现乐趣的方法,有的是构架极难,但基于构架又极傻瓜化方法,很多很多,大部分都根据实际需要开辟一些新方法.

敏捷概念在团对中应用很容易失败,主要因为成员的素质不齐,还有就是专业倾向不统一.大部分实例都在各种大大小小的框架中体现出来,专精算法的人,总是喜欢一个过程就一个函数,专精框架的人,总是喜欢写类,写自动化中间层,专精跨平台的人,总是喜欢用些绕大湾的构架.在团队中,敏捷方法唯一出路是基于强而有活力的主框架.中国有个现象,也是一个很简单的例子,有很多开发中小型MMO的主程序员,一个人会写完所有的函数,类,框架,但里面又没有实现代码.我所听闻的,这些框架大部分都注解不详,因为企业要效率,这些整体大部分都是在一个月内死憋出来的.再然后分任务给程序员做,大部分时候都是很简单的文档.这还不包括,和美术,以及策划的接口,一般走敏捷路线的工程都是做到出Demo非常快,但后来,越做问题越多,这些问题,大部分都和框架无关,而是和美术,策划那边的协调,主要因为策划大都不太稳定,没有考虑通盘的能力.

关于敏捷方法,我也是半路出家,我在2000年左右走上的敏捷之路,后来几经磨练,小产品到是开发过不少,敏捷开发小产品非常有效,但不好配合.wiki上的敏捷可以淘汰它,今天的敏捷应该是根据你公司的实际情况,结合统一化,指标,过程分支,模块抽像等等概念,自己来开辟一条适合自己的方法.别人的方法可以借鉴,但切勿切勿死抄,否则不会有好结果.

暂时就这么点多
我们亲爱的z99999,回头再聊,祝你早日学研有成.睡觉了

免费打工仔

虽然我知道你在和我说话，但是我确实不是什么z9999 是否是把我和你的朋友搞混了？

阿往

员外又淘气了.......