#
简介
外包从本质上说可以用一个英文单词－Arrangement－来界定（有的时候也可以用outsourcing），即它表明的是对当前业务流程的一种“安排”或另外的一种“诠释”，其目的是希望通过引入外部（有时这种外部的力量是通过内部力量起作用）来进行一种更加有效率的资源配置！
编辑本段
优势
外包将您解放出来以更专注于核心业务。外包合作伙伴为您带来知识， IT外包增加后备管理时间。在执行者专注于其特长业务时，为其改善产品的整体质量。最近外包协会进行的一项研究显示外包协议使企事业节省9%的成本，而能力与质量则上升了15%。 公司需要获得其内部所不具备的国际水准的知识与技术。外包解放了公司的财务资本使之用于可取得最大利润回报的活动。
外包使一些新的经营业务得以实现。一些小公司和刚起步的公司可因外包大量运营职能而获得全球性的飞速增长。
一方面，有效的外包行为增强了企业的竞争力
企业在管理系统实施过程中，把那些非核心的部门或业务外包给相应的专业公司，这样能大量节省成本，有利于高效管理。
举例来说，一个生产企业，如果为了原材料及产品运输而组织一个车队，在两个方面其成本会大大增加：
1、管理成本增加，因为它在运输领域不具备管理经验；
2、因管理不善，运输环节严重影响生产和销售环节的工作，从而导致生产和销售环节的成本增加。如果把运输业务外包给专业的运输企业，则可以大幅度降低上述成本。
另一方面，企业也因市场竞争的激烈面临巨大的挑战
市场竞争的加剧，使专注自己的核心业务成为了企业最重要的生存法则之一。因此，外包以其有效减低成本、增强企业的核心竞争力等特性成了越来越多企业采取的一项重要的商业措施。美国著名的管理学者杜拉克曾预言：在十年至十五年之内，任何企业中仅做后台支持而不创造营业额的工作都应该外包出去。
如：经济不景气时，企业会裁掉一些非核心业务的部门，这往往是不得矣而为之，负面影响很大，团队的稳定、额外支出等，但如果一开始这些非核心业务就是外包给专业的组织去做，那么损失一定会减少到最小。
据IDC统计，1998年全球外包服务方面的开支为990亿美元左右。IDC估计，到2003年全球资源外包服务开支将突破1510亿美元，此时期全球外包服务市场的复合年增长率为12.2%，亚太地区则为15.1%。
尽管2001年全球市场低迷，但中国市IT服务市场却是一枝独秀，增长率高达46.3%，IDC预测，到2006年，中国IT服务市场规模可望超越103亿美元，2001～2006年年复合增长率为53%。
IDC表示，目前中国IT服务市场以常规服务，包括系统集成、硬件支持、安装及客户应用软件管理为主。较为高端的服务项目，如咨询、外包等服务项目有发展潜力。
总之，外包能够使企业避免组织过度膨胀，集中人力资源降低成本，提升利润，降低成本，资金可做更高效益，投资致力企业竞争力,提升效益与客户满意度 ，不受限既有的专业知识技能，企业运作更灵活。接受外包这种新的经营理念是一种必然趋势，外包服务势在必行。
编辑本段
外包分类
按地理分类
外包根据供应商的地理分布状况划分为两种类型：境内外包和离岸外包。
1.境内外包
境内外包是指外包商与其外包供应商来自同一个国家，因而外包工作在国内完成。
2.离岸外包
离岸外包则指外包商与其供应商来自不同国家， 外包外包工作跨国完成。 由于劳动力成本的差异，外包商通常来自劳动力成本较高地国家，如美国、西欧和日本，外包供应商则来自劳动力成本较低的国家，如印度、菲律宾和中国。
虽然境内和离岸外包具有许多类似的属性，但它们差别很大。境内外包更强调核心业务战略、技术和专门知识、从固定成本转移至可变成本、规模经济、重价值增值甚于成本减少；离岸外包则主要强调成本节省、技术熟练的劳动力的可用性，利用较低的生产成本来抵消较高的交易成本。在考虑是否进行离岸外包时，成本是决定性的因素，技术能力、服务质量和服务供应商等因素次之。
按工作性质分类
外包的范围按工作性质可分为“蓝领外包”和“白领外包”。
1、“蓝领外包”指产品制造过程外包。
2、“白领外包”亦称“服务外包”，指技术开发与支持其他服务活动的外包。
其中技术开发与支持的外包一般采用一次性项目合同的方式寻求第三方专业公司的服务，称为“合同外包”；其他服务活动的外包多通过签定长期合同的方式交由专业外包提供商进行，称为“职能外包”。
编辑本段
适合业务
通常外包的业务内容，主要包括信息技术，其次是人力资源、财务和会计。外包适合于各种领域，外包的价值与效应需要相应的市场需求和行业监督体系来考证。
编辑本段
全球IT外包商青睐者
印度目前是IT离岸外包市场的中心，据称至少80%的全球外包业务都去了印度。其它外包目的地则遍及 外包亚洲、欧洲、非洲和南美洲，包括中国、菲律宾、俄罗斯、墨西哥、新加坡、爱尔兰、北爱尔兰、以色列、南非、东欧和巴基斯坦等。这些国家的排序比较模糊，因为每个国家都有其自身的优势和缺陷。
根据McKinsey的调查，印度是迄今为止最受离岸外包业务青睐的地区，这主要得益于其在成本和质量上的综合优势。爱尔兰和以色列可以提供良好的基础设施和多语言人才，但费用过高。有些国家则是质量和成本之外的因素较为突出。例如，中国可以提供较低成本和有特殊技能的软件专业人才，以完成那些文档已丢失的项目。与印度相比，中国的竞争优势在于劳动力成本，但在质量上远远落后。
编辑本段
业务外包
在21世纪初期，世界已进入了知识经济时代。工作时代流水线所体现出的企业分工协作已经扩展到企业、行业之间，那种传统的纵向一体化和自给自足的组织模式可以说不灵了。将公司部分业或机能委托给外部公司的业务外包正成为一种重要的商业组织方式和竞争手段。 业务外包业务外包的英文为Out Sourcing，也有人将之译为外部委托，或者资源外包。尽管业务外包这种经营形式至今仍没有一个统一明确的定义，但其本质是把自己做不了、做不好或别人做得更好、更全面的事交由别人去做，准确一点讲，业务外包是一种管理策略，它是某一公司（称为发包方），通过与外部其他企业（称承包方）签订契约，将一些传统上由公司内部人员负责的业务或机能外包给专业、高效的服务提供商的经营形式。业务外包被认为是一种企业引进和利用外部技术与人才，帮助企业管理最终用户环境的有效手段。
今天，全球竞争中的成功者已经学会把精力集中在经过仔细挑选的少数核心本领上，也就是集中在那些使他们真正区别于竞争对手的技能与知识上。通过业务外包--即把一些重要但非核心的业务或职能交给外面的专家去做，而企业的领导人能把公司的整体动作提高到世界最高水平，而所需的费用则与目前的开支相等或者有所减少，与此同时，他们还往往可以省去一些巨额投资。
编辑本段
人事外包
人事外包(HR Outsourcing Managed Service)即企业将人力资源管理中非核心部分的工作全部或部分委托人才服务专业机构管（办）理，但托管人员仍隶属于委托企业。这是一种全面的高层次的人事代理服务。人才服务机构与企业签订人事外包协议以规范双方在托管期间的权利和义务，以及需要提供外包的人事服务项目。 人事外包它是策略地利用外界资源，将企业中与人力资源相关的工作与管理责任部分或全部转由专业服务机构承担。
这包括二个方面内容：
一是策略地利用，即是指企业必须有选择性地将组织内的部分或全部予以外包，而不是与代加工性质一样的外包；
二是外包的工作或项目必须由专业服务机构来完成，这依赖于专业人力资源机构的快速发展及其专业化。
从这个概念出发，实施人力资源外包有二个前提。
一是人力资源管理的一些工作在操作上具有基础性、重复性、通用性的特点，这使人力资源外包成为可能；
二是人力资源专业服务机构的发展，为人力资源外包提供必要的外部条件。
编辑本段
人事外包项目
国外通行的外包服务项目，包含了很多方面，有些企业相当于将所有有关人事管理方面的服务都外包出去，一般来看，流行的外包服务，主要有以下几种：
人事外包项目 1．员工招聘：即代企业寻找、招聘合格员工；
2．员工培训：代企业进行相关的各种培训；
3．人事代理：代发工资、福利、四金交纳、人事档案管理、员工证明、护照等；
4．人员外包：即人才租赁或人才派遣；
5．人事相关咨询：包括薪资调查、政策咨询、离职面试（国外通行的方法，以了解员工满意度）、员工满意度调查、组织规划……；
编辑本段
人事外包的决定因素
影响人事外包发展主要的因素首先是企业观念。目前国内人力资源管理，多数企业依然停留在“人治”方面，不规范、不合理的企业管理制度随处可见。很多企业认为人力资源管理本身不需要投入太多，随意化的管理，带来的不仅仅是对公司的损失，同时也是对人才的浪费，只有企业管理者转变了观念，真正认识到“人”的重要性，才能够认识到人事外包服务的必要性；
其次是企业的成本控制和人员编制问题。当前企业没有规范人事管理的观念，一些企业的人事管理部门都是简单拼凑起来的，更不会在人力资源管理方面大量地投入了，这也直接影响了企业是否会接受外包服务；
第三是服务商的规范经营和专业化程度。虽然国内的人才机构发展突飞猛进，但是也带来了负面影响，如从业人员素质参差不齐、专业化程度不高等等，加上一些非法经营的中介机构的违规经营，使服务商的诚信度大打折扣；
第四是法律法规的健全、网络化、系统化的流程管理、统计分析等配套的综合因素，对人事外包的实施都有很大的影响。
编辑本段
IT外包服务
IT外包简单的说就是公司在内部专职电脑维护工作人员不足或没有的情况下，将公司的全部电脑、网络及外设的维护工作转交给专业从事电脑维修维护的公司来进行全方位的维护。 IT外包服务深入的讲还包括搞技术含量高附加值的应用系统和业务流程外包服务，协助企业用较低的投入获得较高的信息化建设和应用水平，选择IT外包服务，可以节省65%以上的人员开支，并减少人力资源管理成本，使您公司更专注于自己的核心业务，并且可以获得更为专业，更为全面的稳定热情服务。例如烽火猎聘这类发展较早的猎头公司都提供类似服务
企业要想在激烈的市场中立足，必须更加专注其核心业务，IT环境对任何一家企业来说，并不是其专注的内容，但随着IT技术的迅猛发展，他越来越渗透到企业的核心业务中，从而IT对企业的可靠性，可用性，快速适应性提出了越来越高的要求，这与企业要求较低的IT运营成本，高效的工作效率，专业的技术支持能力存在着巨大的矛盾。
IT基础架构管理
局域网的维护于改造
电脑硬件及外设的维护、维修、升级
桌面系统的维护
软件故障的维护
IT环境管理
IT资源管理
IT环境分析，优化，安全管理
桌面系统的优化
系统资源的管理
咨询服务
为企业的ERP系统的建立、运作、和管理以及企业其他信息化的建设提供咨询及建议
培训
为企业提供网络以及相关软件的使用培训
预防性定期维护
紧急故障处理
远程电话支持服务
专人驻场式服务
初级评审 阶段与客户建立融洽的工作关系，制定出最适合客户的服务管理模式，最大限度的保障客户的资源使用。
实施阶段 具备满足客户要求的服务人员提供有针对性的服务
有效反馈 周期性的从客户处反馈服务质量，针对系统现状和客户意见与客户方管理人员共同商定下阶段维护工作重点和改造措施
Q&A巡检 公司服务质量监督人员到客户处做技术巡检，调整服务过程，提高服务质量。
编辑本段
软件外包
所谓软件外包就是一些发达国家的软件公司将他们的一些非核心的软件项目通过外包的形式交给人力资源成本相对较低的国家的公司开发，以达到降低软件开发成本的目的。众所周知，软件开发的成本中70%是人力资源成本，所以，降低人力资源成本将有效地降低软件开发的成本。 软件外包软件外包已经成为发达国家的软件公司降低成本的一种重要的手段。目前，全球软件的销售额为60,000亿美元，而其中软件外包的销售额即达到 5000～6000亿美元。预期到2012年软件外包的销售额将达到10,000亿美元。软件外包的大幅度增长为人力资源成本相对较低的印度和中国带来了新的发展机会。
编辑本段
外判或称外包
外判(Outsourcing)或称外包，于1980年代流行起来的商业用语，是商业活动决策之一，指将非核心业务下放给专门营运该项运作的外间第三者，原因是为了节省成本、集中精神于核心业者、善用资源、获得独立及专业人士服务等。 外包和离岸外包经常被混用，但是外包主要是与组织的重组相关，而离岸外包更强调的是国家。当然，在当今全球化的前提下，这两个概念并不是互斥的。从根本和历史上讲，外包是一个有关在团体内和团体间对劳动力进行组织的术语。
"外包"指将一个业务功能的管理控制和/或业务决策转移或者共享给外部的供应商。这将产生一定程度的双向信息交流和沟通，外包供应商和客户之间的协调和信任。这种不同经济个体间的关系与传统的服务买家和卖家的关系有着本质的不同。在外包关系中，双方动态的集成和共享对于劳动力流程的管理控制，而传统的买卖关系保持双方的完全独立。经常被外包的业务领域包括：信息技术，人力资源，物业设施管理，房地产管理和会计。很多公司也外包客户支持(英语：Customer Support)、呼叫中心(英语：Call Center)等业务，以及工程和制造。现在有一些争论，一些是针对外包的利益和成本，一些是针对如何对外包进行分类。
外判又分为大判、二判及三判等，他们之间可能有专业分工，不幸的结果是剥削。
编辑本段
电子商务外包
电子商务外包是一种新的商业服务。电子商务本身是一个复杂的过程，需要技术和市场营销的双重支持，在网络日渐重要的当今社会，中小企业一方面迫切希望能通过网络开展电子商务，另一方面又受到经验少、专业人才缺乏和成本高企的限制。因此电子商务外包服务应运而生，企业以合同的方式委托专业电子商务服务商为企业提供部分或全部的信息技术、产品或服务功能，从企业在互联网上的“包装”、“宣传”和“销售”三个要点出发，提供以网站建设、网站推广和网上贸易为重点，相关服务为辅助的一系列服务。
编辑本段
外包术语表
应用服务提供商(application service provider 、ASP)
ASP是提供计算机网络应用网络的企业、如电子邮件服务、薪金流程管理、ERP应用等
业务流程外包(BPO)
业务流程外包是指对前台功能以及后勤服务实行外包、尤其是指外包哪些由白领、文职人员的岗位工作、例如会计、人力资源以及医疗编码和医疗转录等
竞争性外包(competitive insourcing)
竞争性内容是指企业内部员工与极富竞争性的第三方力量竞标企业某一具体业务的过程、参见内包(insourcing)
委约生产(contract manufacturing)
委约生产是指将某项生产性工作外包给境内或境外的第三方、被委托者拥有受理合约的设备设施和生产技术
协力式外包 (co-sourcing)
协力式外包是指企业的业务功能由内部员工与拥有专业知识的外部力量共同完成、如咨询公司等
设备管理(facilties management)
设备管理是一项具体的外包解决方案、是指客户选择某一外包提供商对其一项或者多项设备的运行和维护进行负责、
内包(insorcing)
内包是外包的一种应变措施、是指将外包功能完全交给企业的内部另一部门来执行、换句话说、就是籍由改善某一区域的运营来承担来自其他部门的工作、在美国、该术语也被用来指哪些美国投资的外资公司雇佣美国本土员工
近岸外包(nearshoring)
近岸外包是指企业将业务外包给境内公司、其特点为距离短、联络方便、在相同或相近的时区
离岸外包(Offshoring)
离岸外包是将业务外包给境外公司、将业务外包给近邻国家的公司、有时候也会被视为近岸外包、见上一条
服务级别协议(service level agreement SLA)
SLA是指一份外包外包合同的附件文件(或单独合约)、它规定了外包服务的类型、价值以及提供条件、一般来讲、SLA是对质量的规定、如反映时间、有效性、速度、等等
共享服务(shared services)
共享服务是指将企业其他部门所共需的业务功能包给内部的一个拥有特别技能的部门或团队、例如、制造公司的采购部门、就可以为公司的所有生产单位提供采购服务、共享服务也可以外包给第三方服务公司
编辑本段
物流业务外包
所谓物流业务外包，即制造企业为集中资源、节省管理费用，增强核心竞争能力，将其物流业务以合同的方式委托给专业的物流公司（第三方物流）运作。外包是一种长期的、战略的、相互渗透的、互利互惠的业务委托和合约执行方式。
这些天里工作的环境发生了一些微小的变化，可能以后对基层开发的程序员也会有更加具体的影响。上周参加 Open Party 时，重点听了《那些失败的项目们》，分析了一个项目的提出、实施，直到最后失败的过程。我也在想一个技术团队究竟应该用怎样的一种管理方式，才能让技术团队的效率达到更优。
长沙软件开发分了几个小主题，下面一一讲来。
一个程序员一天有多长时间在高效率地工作？
虽然现在绝大部分 IT 公司都声称是 8 小时工作制，但作为开发一线的程序员们一天里真正在高效工作的时间，绝少能超过 4 个小时，甚至一般只有两个小时左右。这是我这两年半以来对我自己和跟一些朋友交流得到的结论。而对于一个有经验的程序员来说，高效率时段和心不在焉的情况下，工作效率可以差上10倍或者20多倍。我曾经有过用两个多小时的时间把半个星期的任务都完成的经历。
因为真正高效的时段非常少，所以加班在我看来是根本不必要的。如果团队里的人个个都精力十足，能力超群，一天能高效工作4个小时，那是非常了不起的。不过这样就引出了下一个问题，既然加班是不必要的，那为什么会时常不得不加班呢？
为什么要加班
一句话来概括，之所以需要加班，是因为白天的时候程序员们都没有好好干活。
那些主管、老板们听到这话时先不要着急去找程序员算账，先想想自己的管理方式有没有问题。程序员们的工作特点是，他们要面对各种细节问题、权衡各种实现方案、测试已实现的功能。这是一种很需要细心和耐心的工作，典型的脑力劳动。要让程序员们进入这种状态，你需要为他们提供必要的条件。在我看来，这条件是如此地简单，那就是：不去打扰他们。
当你全神贯注地做一件事的时候，有人跑过来问了你一个问题，你花了5分钟去给他讲，等你讲完时，却发现很难再进入到刚才那种全神贯注地状态了。有些程序员们对这种事情极为反感，有些则是会用极简洁的语言给对方讲，因为一旦啰嗦起来，程序员们可能就再也做不下去了。也因此，这些人经常会被人认为是“缺乏沟通能力”。依我看，这不是沟通能力的问题，这反而是对工作负责任的态度。
做为程序员的上司，应该想想，在你的公司里，程序员的工作是支持别人（为别人答疑解惑），还是开发产品。如果是后者，你是否又过于强调了沟通能力？要知道如果程序员的工作是做出高质量的软件产品，那你就应该让他专心做好这一件事，别让他又写代码又当客服。程序员不专心，白天的沟通太多，就不能做完工作。只好等到晚上加班，别人都走了，他在没有干扰的情况下才有可能进入高效的状态（注意我说的是有可能）。
我所理解的“沟通能力”
我不认为仅仅能够耐心地给别人讲问题就算是沟通能力强。我认为对于程序员来说，沟通能力首先表现在你写的代码要容易读懂，当别人接手你的代码时，不至于让对方过于旨解。同样地，你也要善于读懂别人的代码，程序员的思维、设计全部都体现在代码里。可以说，只要你有代码，你就应该尽量自己弄明白原作者的意思，尽可能不去动不动就问别人。理由同上面所说，减少对他人的干扰。
其次，沟通能力还应该体现在所写的文档中。如API接口文档，把每一个API的功能、参数类型、返回值类型、异常情况等等都用简洁的、没有歧义的语言描述出来。这样让后来的人有据可查，不用到处咨询他人就可以在你的基础上开发。对于程序员来说，文档不要求生动形象，但必需要没有歧义。有这样的文档，当有人再来回跑来跑去问你问题时，你可以直接让他去看代码或者文档，你需要专心地做手头上的工作。
少开会
我曾经参加过一个兼职的项目，项目的负责人找来的几个人也都是兼职的，在不同的公司工作。有一次商量设计方案，负责人说要聚在一起讨论，也就是开会。对于我们这些人来说，从不同的地方坐半天地铁跑到一块，就为了开一个1小时的会，这实在太不合算了。我当时说其实根本没有必要让大家抽出晚上的时间跑过来，直接在网上说就足够了。不过那个负责人说面对面的沟通效率高。呃……我为了过来和你面对面的沟通1小时，要花1个半小时的时间在路上，反正我是不相信这种方式的效率会高……
在《Rework》里看到一种观点，说你把10个人叫到一块，开了1个小时的会，就相当于浪费了10个小时。其实远不止10个小时。参会的人要准备，听会的人被打断工作，加起来有可能浪费超过20个小时。
关于结对编程
结对编程是在敏捷开发中提到的一种编程方法，即两个人共用一台电脑，一个人写代码，另一个人对他的代码实时检查。我一向不主张这种做法，在我看来，这种做法有两个弊端：
首先是违背了我前面所说的，不要去打扰工作中的程序员。结对编程恰恰是对工作中的程序员不停的打扰。试想一下，当你在实现一个比较复杂的逻辑时，你旁边的人不停地在说“可能有更好的办法……”、“变量名写错了”之类的话，你还能专心地写下去吗？反正我是觉得不能了。我甚至感觉，如果在我写程序的时候背后有人在盯着我，我都没办法写下去。
另一个弊端是，在旁边监督的人往往不如亲自写代码的人想得仔细，因为他不写代码，没有亲自参与到开发一线中去，就不会很专心，容易形成敷衍于事的情况。搞结对编程，不仅极大降低了其中一个程序员的开发效率，还几乎白白浪费了另一个程序员的人力。
不要以加班为荣
领导往往容易认为，肯加班的员工就是好员工。要我说，完全不是这回事。首先加班是不必要的，前面已经说过。如果出现了不得不加班的情况，那就是领导没当好，程序员没几个愿意晚上加班的。恰恰相反，如果一个员工很少加班的话，说明他的效率高、能力强，反而应该给予奖励。而目前的薪酬制度，使得加班多的能多拿加班费，受到领导的重视；而真正的高效率员工往往被视而不见，只能拿基本工资。加班干活的员工不一定是好员工（但加班自学深造的一定是好员工）。（以上由长沙软件开发编辑整理于网络，如想获知相关信息请访问www.sjin.cn ）
行业对下一代开发技术的恐惧随处可见，它出现在饮水机上、出现在杂志中，人们在游戏开发者大会和《游戏开发者》杂志上讨论这个话题。随着硬件性能的不断增强，游戏逐渐变得更加昂贵和拟真化，所有的东西都在增加：团队大小、资产需求、时间投入和需要投资者提供的支持资金。用户也期望能获得更好的产品。他们想要更多有着更好功能和技术深度的机制，更密集的多边形艺术，更高的分辨率纹理，更复杂的AI以及更多的测试和QA等。
这种对下一代的恐惧不仅限于行业从业者。这种压力来源于用户，也在用户中蔓延。游戏站点FiringSquad.com说道：“行业内众多游戏发行商和开发商都在抱怨开发成本的攀升，主要原因在于需要大幅扩张美术团队来制作出所有可行的内容。”行业面对的多数问题的本质是他们采用了不当的产品方法论。近百人的团队还在使用10人团队的开发方法。我们其实可以更改和替换开发方法。
传统游戏开发使用的产品方法论是，花大量前端时间来确定意向功能，通常会同时执行机制和关卡等重要元素，最后进行润色。这种通常称为“瀑布”的方法论类似于生产线，前端负责将产品的各个部分拼接起来，后端等待对拼接完成的产品进行润色。这种等待便会产生问题。设计师和发行商无法得知游戏的真正感觉，比如他们最初对机制的评估是否准确，或者功能的执行与原计划是否存在偏差。这样的因素会影响到产品质量。
有个替代方案可以处理传统游戏开发方法论带来的这些问题。这种产品R&D过程和团队管理方式称为“敏捷方法论”。敏捷强调直接将游戏的可论证迭代融入制作过程中，将最关键的元素和功能的迭代优化提前。这种方法还强调了团队的组成和关系，以及团队必须计划和实现项目目标的循环。游戏开发团队会面对许多挑战，美术、工程和设计等不同层面面对的挑战也各不相同，他们需要合作。通向游戏项目完结的道路也非常漫长，较小的游戏需要开发1到2年时间，较大的游戏需要3年或更多的时间。
本文长沙软件开发将分析敏捷方法和Scrum方法论，能够直接处理这些问题，它们可能特别适合于面对下一代主机游戏开发的综合性游戏开发者和设计师。
方法论
瀑布(Waterfall)
多数游戏设计或游戏开发书籍对方法论的叙述并不多。作者认为多数开发者使用的都是相同的方法，也就是所谓的“瀑布”。在瀑布方法中，工作持续朝一个方向发展，比如从项目需求或设计阶段到制作和执行阶段。早期阶段的迭代很少，评估的机会并不多。而且，就如同流水一般，但一旦展开工作，就难以颠倒。
在瀑布游戏开发中，游戏设计师或设计小组会先编写游戏设计文件，陈述游戏的许多功能和机制。随后，设计文件被分为许多部分，制作人从中找出所需的功能和资产。这些资产和功能元素的需求由参与项目的各个团队来满足。
因而，一旦展开瀑布方法，需求会流向动画、编程、关卡艺术、角色美工、QA和FX等。随后，每个个人或团队完成一项功能，然后提交成品。比如，设计文件中的角色被递交给制作人或项目主管。然后，它会被分解成各个成分：角色的纹理、动画、被击中时角色呈现出的效果以及攻击或空闲时的模样，最终用AI技术来强化角色。每个部门专注于完成属于自己的成分，然后执行，直到其完成。
然后，结果会回到设计师手中进行调整，递交给QA完成测试，提交给关卡设计师放入关卡中，然后回到各部门手中完成漏洞调试工作。在这个角色的制作过程中，其他个人和团队正致力于完成他们手中的机制。同一天的时间里，单个开发者可能需要处理多种不同的机制。这种方法论的本质是逐渐渗透，游戏的许多机制从0开始，随着时间渐渐完善。
敏捷
上世纪90年代末期，许多新的软件开发方法论开始出现，这些方法论来源于从网页applet开发到系统动力NASA航空等各种团队。每种方法论都有其自身的优点和缺点，尽管各有不同，但是多数方法论之间都存在许多共同点。
2001年，许多曾参与过这些方法论制作的人在犹他州召开大会。此次大会得出了一个中心思想体系和一则宣言：
1、一个可运行软件的价值要高于陈述软件功能的文件。
2、与客户定期合作的价值要高于陈述产品功能的合约。
3、个人解决问题的价值要高于进程或工具。
4、最重要的是，它们的价值随计划的进展而改变。
执行凌驾于文件记录之上、利用客户合作以及解决问题和改变的能力，这就是敏捷性。敏捷方法论的中心原则很简单，但是却有着丰富的内涵，它可以用于任何复杂的产品开发系统中。
Scrum
随着敏捷开发使用的普及，出现了各种不同的方法论。有些来源于敏捷，有些是已经被人用过却从未完全定义或运用到软件开发中的系统。scrum便是此类方法，这种生产R&D的方法来源于日本汽车和消费电子制造业。从定义上来说，scrum指橄榄球比赛中的一种调遣方法，即队伍中的每个人都参与到移动球的动作中。
作为一种方法论，这种精神也可以被运用到产品开发中，项目团队被重新划分组织成小团队，这些小团队密切配合，完成项目的某个具体成分。迭代开发受到重视，项目被划分成可被呈现、测试和功能评估的“可运载”成分。
scrum的主要原则之一是，团队中的每个人都参与到过程中。scrum将制作过程分解成短期工作循环，称为sprint。在每个sprint开始时，这个项目团队确定目标，自我组织进入小scrum团队。scrum团队由不同类型的成员组成，包括美术设计师、设计师和程序员。每个团队的目标由项目管理者、制作人和发行人在计划会议上确定，但团队可以自行决定实现sprint目标的方法和途径。一旦进入sprint，团队就可以完全自行管理他们的日常计划和任务执行。
熟悉scrum的人经常会提到，项目会因这种方法也受到拖延。对于这种情况，sprint期间各scrum团队召开每日会议便成了scrum方法的重要成分。会议可以短至5到10分钟，其目的是确保工作朝着正确的方向、识别过程中遇到的各种障碍以及每日取得的进展能够被参与项目的所有人所了解。这样的做法会让团队成员产生归属感，项目进展的透明性也会让团队成员明白自己的义务，最终使制作效率得到提升。
因为团队都是自发组成的，所以日常的评论能够让所有团队锁定正确的目标，让所有人都能够了解产品最真实的现状，包括外观和表现。每个sprint完成后，团队阐述其获得的成就，他们的产品拥有者或“客户”(游戏邦注：比如工作室管理者和发行商)可以对这个过程进行评估。随后，客户决定需要在下个sprint优先完成的目标。
在接受他们客户的评论时，这些团队的目标是展示游戏的“垂直分片”(vertical slice)，比如关卡集、完整的可玩机制或协调适当的功能。尽管单次迭代无法完成所有机制，但是团队可以专注于一项机制。比如，AI角色很难在单次srint内完成。但是该AI角色的单个行为可以在单次sprint中编程、制作动画、配音和添加到关卡中，最终得到可以被测试的产品。
记住这两个元素，客户可以查看产品，了解已经完成的内容、正在进展中的工作以及产品开发进展速度。客户不需要猜测或盲目信任，他们能够看到直接的成品，而且往往可以拿起控制器体验游戏结果，而不是盯着数据表或线框图。scrum还让客户可以更自由地处理多个迭代进程。
如果制作和评估的成品与预期效果有出入，客户在sprint期间有空间改变项目目标。因为scrum的迭代过程和sprint的短期工作循环，重新确定项目目标几乎不会导致大量工作和时间的浪费。
瀑布与scrum
瀑布开发给游戏设计师带来的问题是，只有当对象的所有元素都构建完成并拼接起来时，他们才能从全局来衡量对象的效果和价值。比如，设计师或许需要构建文件中描述的围绕AI的关卡。参考设计文件，设计师发挥自己的想象和猜测，让经验丰富的人给自己提建议和评估成果，最终将关卡提交给美术人员开始构建各种元素。设计师及其主管知道没有人真正体验过角色，但是为了保证制作的流畅开展，设计师和关卡美术设计师必须假定AI能够像预想的那样发挥作用。但是，尽管工作继续开展下去，问题依然存在。
假如负责制作角色的程序员发现，文件中陈述的AI机制无法实现，那又如何呢？如果AI运转良好，但动画无法让机制恰当地呈现出来，那又如何呢？如果负责角色的设计师意识到，某个功能并不有趣，那又如何呢？对于这些问题，答案无疑是浪费共更能、浪费精力和时间、浪费开发预算甚至导致团队成员对项目失去信心。从开发进程的角度来看，最可能出现的结果可总结为：产品质量下降。
瀑布方法产生的另一个问题是，当部门相互赶超，会出现“匆忙和等待”的情况。每个人都在尽可能快地完成自己的任务，然后等待下一个目标。可以想象下，这条装配线上带子的移动速度不时发生变化，有时完全停下来，有时以合理的速度和节奏运行，偶尔却会显得格外疯狂。生产过程中这种不规律的节奏对制作人、财务负责人和所有项目参与者都不利。对于设计师来说，它会从根本上影响他们的工作。反复无常的流程会影响产品的功能和质量，尤其是需要融合多种不同元素的功能。
比如，思考下游戏中的恐怖机制，玩家因忽然遭遇邪恶的BOSS而受到惊吓。这样的机制需要靠细微之处的设计才能获得成功，设计团队需要测试、评估、迭代并完善美术、音效和剧本。这些过程绝对不能在团队对产品整体情况毫不知情的情况下完成。
瀑布方法总是会让设计师处在不良的情境中，虽然游戏的篇幅和广度在项目初期就已经确立，但镜头、控制和AI等组成游戏最重要动态的深度却渗透缓慢，只在接近项目末期时才呈现出完整的形态。
上述情景是项目的典型传统做法。完成游戏的预制作后，他们投入到设计文件所列举的机制和资产制作中。根本问题在于，所有人都以为这些机制最终的结果都将同设计文件保持一致。
描述瀑布项目进程的另一种方法是，用曲线来呈现产品已完成功能随时间的进展情况，如图3所示。项目时间线右侧是提交给发行商的时间，它是固定的。随着开发的进展，在项目进入至关重要的末期阶段时，游戏机制开始呈现出最终的形态和功能。
假如当项目几近结束，需要提交时，却发现某些至关重要的成分无法发挥之前计划的功能，那又怎么办呢？因为提交时间是固定的，所以出现上述情况要么意味着需要加班加点，要么就是删除项目中与这些功能相关的所有资产和内容。最终导致的结果是，团队浪费了资源、资产和经历，产品质量也受到了影响。
scrum和瀑布的最根本性差别在于，scrum的交流层次是建立在日常协作的基础上，项目期间各团队都会开展交流和商讨。在上述瀑布范例中，我们的设计师在围绕AI构建关卡时，使用的是描述角色样式的文件和自身的想象力。如果在同样的范例中使用scrum，设计师就能够同团队其他成员合作。比如，设计师说出了自己的目标：我需要能够让我更容易进行导航迭代的AI。那么，下个阶段就是直接通程序员合作实现目标。
设计师和程序员配合，尝试不同的做法，寻找最佳的技术，以使AI表现出意向行为。如果程序员遇到了障碍，因为设计师也参与到这个过程中，所以他可以直接更换其他解决方案。这种方法并不局限于设计师同程序员间的合作。同样的方法还可以运用于，设计师同动画师配合完成对角色移动的设计，或者同环境美术人员配合完成关卡布局工作。最终的结果是能够得出较好的解决方案，因为scrum确保了所有任务参与者都能够协调配合。
scrum的想法是，负责制作和执行的人对目标和可能遇到的障碍最为熟悉。对于角色移动所需的动画的了解，谁能够超越动画师？对于如何让AI移动到特定地点的了解，谁能够超越程序员呢？
通过明确设计最终目标，它让设计师和执行功能或关卡的人之间有了交流的机会，同时让所有参与者都能够有机会提出实现目标的最佳方法。对于技术和美术的了解，设计师不及程序员和美术人员。我们能够做的就是确定短期目标，并在数周的时间里配合团队完成制作，然后对最终结果进行评价，决定是否使用。这种对小片段快速迭代的强调使最终产品和设计师均获益匪浅。
presubmission quality(from gamaustra)
通过快速迭代，设计师可以在短时间内看到完整的机制。这让设计师可以迅速发现机制的状态以及游戏开发的前进方向。对于首席设计师和项目主管来说，他们每数周就能够了解项目的进展情况，在每月与团队的交流中就能够发现他们的努力是否会满足自己的最终目标。
因为每个独立的功能都由某个团队来完成，所以如果被删减不会影响到之前已经制作完成的内容。在独立功能被融入整个开发流程之前，对其进行更改不会导致工作时间和精力的浪费。
对于关卡设计师来说，这也意味着他们可以围绕已证实有效和有趣的机制来构建关卡。设计师随后可以回到某个关卡或区域，为其添加新功能，但在此之前游戏也可以先期推向市场。
finished functionality(from gamasutra)
专注于单个机制而不是分别制作并相互渗透，这种做法似乎会令人感到害怕。但是，应当注意到是，基础机制和关卡构建是游戏走出工作室必要条件。额外的功能能够为游戏填色，但是并非如此至关重要。优先构建最重要的东西而不是将其放在项目末期，意味着内容制作者(游戏邦注：比如设计师)能够直接围绕具体功能构建关卡。
此外，在项目早期获得功能性中心机制意味着，游戏无需依赖于那些可能被删减的机制，这些内容可以根据客户的需要进行删减或扩展。而且，产品拥有者和设计师可以决定哪些功能对游戏最有效，然后将其确定下来，包括更多用来呈现游戏中功能出众之处的内容。
随着时间的不断延长以及未尝试技术和硬件等更多因素的出现，发行商和投资者面对复杂情况时的思维逐渐从“让我们来尝试下!”转变为“我也不知道该怎么做。”下一代游戏开发的成本会进一步增加，所以出现上述反应是合理的。
如果使用scrum，产品拥有者和发行商可以通过多次迭代来规避风险。如果未曾证实有效的功能或游戏概念确实无法发挥作用，那么团队可以迅速进行重新评估并做出改变。如果那些功能有非凡的表现，团队和产品拥有者可以决定专注于游戏的这些层面，甚至让游戏开发朝全新的方向发展。
而且，随着开发时间的增加，产品面向的市场也在不断发生变化。新颖的想法会迅速变得稀松平常，因为其他同类产品会迅速在市场中出现。scrum让发行商和设计师带领产品远离竞争，同时将转变的风险降到最低。如果产品功能需要发生改变，或者出现游戏项目需要完全取消这种最糟糕的情景，发行商失去的也就是两周到两个月的时间，而不是两个季度或两年。
总结
在scrum这样的敏捷方法论中，游戏设计师能够获得众多的好处。项目主管和首席设计师可以定期看到项目的整体进展情况，他们要面对的不是抽象的表格和数据，而是可以亲身体验。对于关卡设计师，他们可以专注于围绕现有机制构建关卡。如果使用scrum，关卡设计师可以使用完整的机制，也就不用进行无谓的猜想。
scrum可以让游戏开发中的所有人受益，不只是设计师，因为它可以讲“死亡竞速”降到最小。发行商和项目主管可以审核每次迭代中的团队表现，意味着他们可以安全的预测团队未来的表现情况。
最重要的是，使用敏捷方法论和scrum让设计师可以同执行功能和技术的人协调配合。对话、提问和交流能够使问题实现有机的跨部门解决。这样团队就可以事先排除可能导致浪费时间和精力的臆断，通过协作让游戏开发产生最佳结果。
通过快速迭代，设计师可以在短时间内看到完整的机制。这让设计师可以迅速发现机制的状态以及游戏开发的前进方向。对于首席设计师和项目主管来说，他们每数周就能够了解项目的进展情况，在每月与团队的交流中就能够发现他们的努力是否会满足自己的最终目标。
因为每个独立的功能都由某个团队来完成，所以如果被删减不会影响到之前已经制作完成的内容。在独立功能被融入整个开发流程之前，对其进行更改不会导致工作时间和精力的浪费。
对于关卡设计师来说，这也意味着他们可以围绕已证实有效和有趣的机制来构建关卡。设计师随后可以回到某个关卡或区域，为其添加新功能，但在此之前游戏也可以先期推向市场。
finished functionality(from gamasutra)
专注于单个机制而不是分别制作并相互渗透，这种做法似乎会令人感到害怕。但是，应当注意到是，基础机制和关卡构建是游戏走出工作室必要条件。额外的功能能够为游戏填色，但是并非如此至关重要。优先构建最重要的东西而不是将其放在项目末期，意味着内容制作者(游戏邦注：比如设计师)能够直接围绕具体功能构建关卡。
此外，在项目早期获得功能性中心机制意味着，游戏无需依赖于那些可能被删减的机制，这些内容可以根据客户的需要进行删减或扩展。而且，产品拥有者和设计师可以决定哪些功能对游戏最有效，然后将其确定下来，包括更多用来呈现游戏中功能出众之处的内容。
随着时间的不断延长以及未尝试技术和硬件等更多因素的出现，发行商和投资者面对复杂情况时的思维逐渐从“让我们来尝试下!”转变为“我也不知道该怎么做。”下一代游戏开发的成本会进一步增加，所以出现上述反应是合理的。
如果使用scrum，产品拥有者和发行商可以通过多次迭代来规避风险。如果未曾证实有效的功能或游戏概念确实无法发挥作用，那么团队可以迅速进行重新评估并做出改变。如果那些功能有非凡的表现，团队和产品拥有者可以决定专注于游戏的这些层面，甚至让游戏开发朝全新的方向发展。
而且，随着开发时间的增加，产品面向的市场也在不断发生变化。新颖的想法会迅速变得稀松平常，因为其他同类产品会迅速在市场中出现。scrum让发行商和设计师带领产品远离竞争，同时将转变的风险降到最低。如果产品功能需要发生改变，或者出现游戏项目需要完全取消这种最糟糕的情景，发行商失去的也就是两周到两个月的时间，而不是两个季度或两年。
总结
在scrum这样的敏捷方法论中，游戏设计师能够获得众多的好处。项目主管和首席设计师可以定期看到项目的整体进展情况，他们要面对的不是抽象的表格和数据，而是可以亲身体验。对于关卡设计师，他们可以专注于围绕现有机制构建关卡。如果使用scrum，关卡设计师可以使用完整的机制，也就不用进行无谓的猜想。
scrum可以让游戏开发中的所有人受益，不只是设计师，因为它可以讲“死亡竞速”降到最小。发行商和项目主管可以审核每次迭代中的团队表现，意味着他们可以安全的预测团队未来的表现情况。
最重要的是，使用敏捷方法论和scrum让设计师可以同执行功能和技术的人协调配合。对话、提问和交流能够使问题实现有机的跨部门解决。这样团队就可以事先排除可能导致浪费时间和精力的臆断，通过协作让游戏开发产生最佳结果。（以上由长沙软件开发编辑整理于网络，如想获知相关信息请访问www.sjin.cn ）
把SEO与爱情扯在一起，其实是一件很可悲的事情。很多人都说做SEO就等于远离了爱情这扇窗，因为SEO那没日没夜的对着电脑，码着文章，发着外链，对着数据，苦逼的生活莫过于此。俗话也说：鱼和熊掌不可兼得。那把这句话放在SEO与爱情上呢?二者可以兼得吗?我给的答案是肯定的，因为我既要面包，也要爱情。接下来先让笔者分享一段令人深思的情节吧!
不知道为什么，我们习惯了盯着蓝韵的电脑屏幕，但我知道绝对不是因为蓝色好看;
不知道为什么，我们习惯了敲打破旧的鼠标键盘，但我知道绝对不是因为声音好听;
不知道为什么，我们习惯了望着窗外默默地发呆，但我知道绝对不是因为景色优美。
“老公，做什么呢?”
“更新网站呢”
“今天是周末哎”
“没办法啊，最近百度有大更新啊”
“又是SEO，我恨SEO，都没时间陪我了”
一次又一次，已经再也没有这个甜美的声音在耳边萦绕，总觉得少了些什么。我们在等待百度，爱人在等着我们。爱人等久了也许就走了，我们等久了就不舍得放弃了，让百度等久了我们就完蛋了。
“老公，给我写封情书吧。”
“有时间就给你写好吗?”
“可我天天都看你在写文章啊，顺便给我写封呗”
“宝贝，别闹啊，更新网站呢”
“好吧，到底是我重要还是你的网站重要，哼”
一天又一天，我们写着无数篇不符合我们内心的文章，给一个从来不认识你的蜘蛛机器人看，却没有时间给爱人写出一封让她能继续等着你的情书。
“老公，很晚了，睡觉吧”
“你先睡吧，凌晨4点百度会有变动”
“可是我很想跟你一起睡呢”
“今天你先睡哈，明天陪你好了”
“明天你肯定还是这个样子”
一夜又一夜，我们为了百度的一丁点变化而让最爱的人孤枕难眠，从黑夜到白天脑子里好像钻了虫子把百度放在前面，最爱的人放在后面。
终于有一天。
“我们分手吧”
“为什么?”
“你想的只有百度，去和“度娘”结婚去吧”
“我是真心爱你的”
“可是我看不到，更感觉不到”
“别走，好吗?”
“我和百度，你选择一个”
“、、、、、、、、、、、、、、、、、、、、”
多少次、多少天、多少夜，我们守在电脑旁等待百度的更新，做好改版后又有谁不是时刻关心百度对自己网站的变化。每做一次变动后都要几天甚至一个多月才能看出来成果。是百度让我们学会了等待，是百度练就了我们不骄不躁的性格，是百度让我们早已习惯了等待。
女孩们请不要放弃我们。因为我们习惯等待，不会计较你每次约会的迟到;因为我们会等待，我希望会给你个更好的未来;因为我们会等待，你走后，我依然会踟蹰在原地等你回来。我真想大声喊一句：去你妈的百度，我不要你再左右我的生活!
看完这段情节后大家作何感想呢?笔者是感触颇深。也因此触发了笔者写这篇文章的灵感。或许在外行人眼里，会觉得没有什么大不了的。但是，只要从事过SEO行业的人都亲身体验过其中的艰辛和无奈。
相信很多SEOER都是夜猫子，甚至有时候为了一个破网站而被弄得焦头烂额也是家常便饭。他们这么辛苦的维护着网站，不为别的，只是专注于这个行业，追求于心中的那份梦想，也一定会更加钟情于你。 记得笔者之前写过一篇《SEO伴侣，请多一点包容和等待》的文章。对于从事SEO工作者的伴侣来说，支持与理解是对他最重要的肯定。所以，SEO对工作和梦想的专注精神，不是更应该拥有一份爱情吗?或许SEOER们由于工作的原因对你有所忽略，但是既然你选择了，就请你给予多一点包容和等待。
其实很多时候，SEOER的情人就是电脑，每天和电脑在一起的时间比老婆的时间还长。从而忽略了对她的关心。请SEOER们在陪“度娘”的时候，也不妨抽空多陪陪她吧。
或许有些女孩会说：SEOER每天和电脑在一起的时间比自己女友的时间还长，都没有时间陪我和关心我。我需要的男友是不管在我开心或难过，他都能够在第一时间陪我一起分享快乐与忧伤，而不是自己独自默默的承受。或许她的想法很自私，但是我们也不得不承认她的想法确实很真实。
此时不禁令笔者想到军人的故事。别人都说军人最光荣，军人为什么光荣呢?原因想必大家都知道。那么SEO工作者呢?笔者认为SEOER也同样伟大，他们日夜奋战在互联网的最前线，做出的牺牲远远大于得到的回报。假如没有了这些勤劳的SEO工作者们，我们的互联网将大失色彩。这么伟大的SEO工作者们，难道他们不该拥有一段完美的爱情吗?
记得速途网主编丁道师《写给中国互联网最可爱的人—站长》的文章中有这么一段话：亲爱的朋友们，当你们早晨泡上一杯茶打开新闻网站查看每天的最新资讯动态的时候，当你们在各大文学网站阅读到优美的小说的时候，当你们和朋友一 起免费观看热门影视大片的时候，朋友，你是否意识到自己是在幸福中，并且这一切都是理所当然呢?朋友，这一切的背后都在有这样一群特殊的人在奋斗，这就是——站长，他们确实是中国互联网最可爱的人。
是啊!如果没有这群可爱的互联网站长们的辛勤付出，就没有我们今天美好的互联网生活。这群兢兢业业的站长们难道不应该拥有一份美好的爱情吗?SEO工作者所付出的，是我们常人想不到的，他们辛苦的坚持维护一个网站，耐心的守候“度娘”的情，执着的掀起百度的爱。像这种SEO工作者，难道他们对爱情会不真诚吗?难道他们对爱情会不坚信吗?这是一群可爱，可亲，可敬，敢言，敢怒，敢打抱不平的互联网之人。难道会得不到一份真挚的爱情?难道就不该拥有爱情?
很多时候做SEO看似没有情感，其实他们的情感都不会轻易表露出来，做SEO的人要么沉默无语，要么高调成形。放心，SEO的浪费之处，绝对不局限于现实生活的情情爱爱，他们更多的是用行动告诉你，你才是他最重要的人，情书算什么，SEO人一码就能码上一万字的情书给你，网站算什么，SEO人动手就能亲身建一个属于你的网站给你。他们不屑于鲜花，他们只知道付出行动才是真情实意!
写到最后，笔者是带着深厚的情怀去写的，为了SEO，我坚信我的爱情一样精彩，我更坚信，SEO与爱情是可以兼得的，SEO同样可以优化自己的爱情，收获那一份最真的感情。我再次为这群可爱的SEO们坚挺一下，亲爱的SEOER，美好的爱情正在远方等待着你们。面包会有的，牛奶也会收获到的，如果你身边有这样的可爱站长，就请你赶紧嫁了吧!(以上由长沙IT外包编辑整理于网络，如想获知更多相关信息请访问www.sjin.cn )
其实这个问题不应该成为一个问题，因为一个真正意义上的的项目经理是不需要去做需求分析的，而应该是让专职的需求分析人员去做。我的理解，项目经理在工作过程中，与需求沾边的工作应该是对于项目范围的定义：确定哪些是在项目中要做的，哪些是不用去理会它的，清楚地定义项目的边界。除此之外，其它的工作都应该交由专门的人员去进行专业的信息采集与处理。但大家都知道，在实际的工作中，项目经理往往是既当爹来又当妈，一个人做Ｎ个人的活，尤其是当项目不大的时候，项目经理更是要一马当先地什么都做，几手都要抓，同时，老板对你的期望又是几手都要硬。因此，从现实的角度考虑，这个问题还是要探讨一下的。
记得我刚从学校毕业到公司的时候，曾无知地告诉老板说我对需求分析还是很有经验的，老板当时就笑着对我说，其实要想成为一个有经验的需求分析人员，起码要有十年的工作经历。当时只是觉得老板嫌我刚出道罢了，但做了一些项目之后，我对于需求分析这件工作有了更深刻的认识，也清醒地了解到需求分析真不是一件容易做的事。
首先，是我们对领域知识的缺乏。客户所在的领域并不都是我们所熟知的，这不像是在学校里做课程设计，不是图书馆管理系统，就是学生管理系统，连蒙带猜也能编出来。行业的多样性必然会导致需求领域知识的多样性，面对这样的困境，又怎么能要求我们在与客户短短的几次交谈中就获取足够的信息来完成一个复杂的软件产品呢。
其次，客户对需求的理解与传达不足。需求很明显是由客户传递给项目组的。客户在解释需求的时候，有时就会带有很大的含混性，而且客户对需求的说明不能做到完全的正确。如果是与外国人交流，那信息的损失就会更大。在与外国客户的交往中，英语国家的人可以用母语与你交谈还算是庆幸了，遇到了母语不是英语的国家的客户与你交谈，那两个人都要非母语进行交谈，双方都够把心里想的东西表达出７０％以上就算是非常成功的交流了。同样，分析人员在对需求进行吸收的时候也会产生误解，一些信息也会被遗漏掉。靠这样获取的需求进行开发，结果是可想而知的了。
要解决上述的问题，似乎没有什么比经验更好的办法了。对于某一行业领域的熟悉，需要一定时间的积累，了解了一定的知识之后，就能更容易得与客户进行有效的沟通，获取项目中需要的信息。需求对于项目的重要性不用多说，一个项目至始至终都是为了达到让客户满意的目的，满足客户的需求，其实是一种对需求含混性降低的过程。为了达到这一目的，还有一些称为方法的步骤可以让我们减少对需求的误解：
１． 细晰地划分项目干系人（Stakeholder）：尤其是分清什么是客户，什么是使用者。在了解需求的时候，我们能从哪些人中获取信息。同时还要注意到，获取的信息是否得到负责人的确认。
２．需求分析会议：与客户的会议当然必不可少。从中尽可能多的找出不清楚的地方，及时的提出，如果客户允许可以进行录音，不过这一招估计很难做到，大部分时候客户可不想留下自己的话柄。与项目组成员的开会是为了在组内加深对需求的了解，集思广义，再用点头脑分暴之类的东东，可以发现更多的求知问题。（以上由长沙软件开发编辑整理于网络，如想获知相关软件开发的信息请访问www.sjin.cn ）
net framework又称 .Net框架。是由微软开发，一个致力于敏捷软件开发、快速应用开发、平台无关性和网络透明化的软件开发平台。.NET是微软为下一个十年对服务器和桌面型软件工程迈出的第一步。.NET包含许多有助于互联网和内部网应用迅捷开发的技术。.NET框架是微软公司继Windows DNA之后的新开发平台。
.NET框架是以一种采用系统虚拟机运行的编程平台，以通用语言运行库为基础，支持多种语言的开发。NET也为应用程序接口（API）提供了新功能和开发工具。这些革新使得程序设计员可以同时进行Windows应用软件和网络应用软件以及组件和服务的开发。.NET提供了一个新的反射性的且面向对象程序设计编程接口。.NET设计得足够通用化从而使许多不同高级语言都得以被汇集。.NET Framework中的所有语言都提供基类库(BCL)。
.Net框架的历史
1. NET Framework 1.0
完整版本号 - 1.0.3705这是最初的.NET构架，发行于2002年。它可以以一个独立且可重新分发的包的形式或在一个软件发展工具包集中被获得。它也是第一个微软Visual Studio .NET的发行版的一部分（也被称作Visual Studio .NET 2002）。
.NET Framework 1.1
完整版本号 - 1.1.4322这是首个主要的.Net Framework升级版本，他发行于2003年。它可以以一个独立的可重新分发的包的形式或在一个软件发展工具包集中被获得。它也是第二个微软Visual Studio .NET版本的一部分（也被称作Visual Studio .NET 2003）。它也是首个被Windows Server 2003所内置的.Net Framework版本。
.NET Framework 2.0
完整版本号 - 2.0.50727.42，发行于2005年10月27日。
.Net Framework 2.0的组件都包含在 Visual Studio 2005和SQL Server 2005里面。通过MSDNUniverse版可以免费下载RTM版本。自1.1版本以来的改进：大量的API变更。新的API让需要管理.NET运行库实例的非.NET的应用程序可以做到这点。这个新的API对.NET运行库的各种功能，包括：多线程、存储器分配、代码加载等，提供了很好的控制。它最初是为Microsoft SQL Server能够有效率的使用.NET运行库而设计的，因为Microsoft SQL Server拥有它自己的日程管理器和存储器管理器。NET框架 2.0 SP1随.Net Framework 3.5同时发行，请参看.Net Framework 3.5一节。.Net Framework 2.0 SP2随.Net Framework 3.5 SP1同时发行，请参看.Net Framework 3.5 SP1一节。
.NET Framework 3.0
Windows Presentation Foundation（WPF）：提供更佳的用户体验，用来开发Windows Forms程序以及流览器应用程序.Windows Communication Foundation（WCF）：提供SOA（面向服务的软件构架）支持的安全的网络服务（Web Service）框架。Windows Workflow Foundation（WF）：提供一个设计与发展工作流程导向（Workflow-oriented）应用程序基础支持的应用程序接口。Windows CardSpace：提供一个SSO的解决方案，每个用户都有各自的CardSpace。.Net Framework 3.0 SP1随.Net Framework 3.5同时发行，请参看.Net Framework 3.5。.Net Framework 3.0 SP2随.Net Framework 3.5 SP1同时发行，请参看.Net Framework 3.5 SP1。
.NET Framework 3.5
这个版本将包含一个支持C#和VB .Net中心的语言特性的编译器，以及对语言集成查询（LINQ,Language-Integrated Query）的支持。该版本随Visual Studio 2008一起发布。
同时，.Net Framework 3.5自动包含.Net Framework 2.0 SP1以及.Net Framework 3.0 SP1，用于为这两个版本提供安全性修复，以及少量新增的类库（如System.DateTimeOffest），此版本提供的新功能有：
扩展方法（Extension Method）属性（Attribute），用于为扩展方法提供支持LINQ支持，包括LINQ to Object、LINQ to ADO .NET以及LINQ to XML表达式目录树（Expression Tree），用于为Lambda表达式提供支持与语言集成查询 (LINQ)和数据感知紧密集成。借助这个新功能，您可以使用相同的语法，在任何支持LINQ的语言中编写相关代码，以筛选和枚举多种类型的SQL数据、集合、XML和数据集，以及创建它们的投影。利用asp .netAJAX可以创建更有效、更具交互性、高度个性化的Web体验，这些体验在所有最流行的浏览器上都能实现。用于生成WCF服务的全新Web协议支持，包括AJAX、JSON、REST、POX、RSS、ATOM和若干新的WS-*标准。Visual Studio 2008中面向WF、WCF和WPF的完整工具支持，其中包括支持工作流的服务这一新技术。.Net Framework 3.5基类库 (BCL)中的新类可满足许多常见的客户请求。[编辑].Net Framework 3.5 SP1 .Net Framework 3.5 SP1自动包含.Net Framework 2.0 SP2以及.Net Framework 3.0 SP2。
该版本新增的ASP .NET功能，随Visual Studio 2008 SP1发布，此版本提供了下列的新功能：
新增的ASP .NET功能包括ASP .NET动态数据和ASP .NET AJAX附加功能，前者提供了无需编写代码就可实现数据驱动的快速开发的丰富支架框架，后者为管理浏览器历史记录提供了支持（后退按钮支持）。ADO .NET Entity Framework。对SQL Server 2008的数据提供程序支持。.Net Framework客户端配置文档是完整版.Net Framework的子集，面向客户端应用程序。这改善了尚未安装.Net Framework的计算机上的安装体验。改进Windows Presentation Foundation的性能，其中包括启动速度的位图效果性能的提高。为Windows Presentation Foundation增加的功能包括对业务线应用程序的更好支持、本机闪屏支持、DirectX像素着色器支持以及新的WebBrowser控件。ClickOnce应用程序发布者可以根据具体情况决定是否取消签名和散列，开发人员可以以编程方式安装显示自定义署名的ClickOnce应用程序，ClickOnce错误对话框支持指向网络上特定于应用程序的支持站点的链接。用于SQL Server的.Net Framework数据提供程序 (System.Data.SqlClient)完全支持SQL Server 2008数据库引擎的所有新功能。有关.Net Framework对SQL Server 2008的支持的更多信息，请参见SQL Server中的新功能 (ADO .NET)。ADO .NET数据平台是一种多版本策略，它使开发人员能够针对概念性实体数据模型进行编程，从而减轻他们的编码和维护工作。此平台提供了ADO .NET Entity Framework、实体数据模型 (EDM)、对象服务、LINQ to Entities、Entity SQL、EntityClient、ADO .NET数据服务及实体数据模型工具。Windows Communication Foundation现在提供了改进的互操作性支持，增强了部分信任方案中的调试体验，并扩展了集成协议支持以更广泛地应用于Web 2.0应用程序，进而使DataContract串行化程序更易于使用。Microsoft.VisualBasic.PowerPacks命名空间引入了新的DataRepeater控件，该控件以可自定义的列表格式显示数据。此命名空间还包含新的矢量形状。
.NET Framework 4.0
4.0主要增加了并行支持，英文版于2010年4月12日推出。
企业基础 .NET提供开发软件的独立平台，自带高度安全的网络系统，相当倚重软件组件以及组件导向程序。在这方面它完全取代前者（COM1）。
NET Framework 4.5
.Net Framework 4.5尚未正式发布，目前为开发者预览版，详细信息见.NET Framework Developer Center
(以上由长沙软件开发编辑整理于网络，如有想获知相关信息请访问www.sjin.cn )
软件开发过程分为5个阶段：
分析
软件需求分析就是对开发什么样的软件的一个系统的分析与设想。它是一个对用户的需求进行去粗取精、去伪存真、正确理解，然后把它用软件工程开发语言（形式功能规约，即需求规格说明书）表达出来的过程。本阶段的基本任务是和用户一起确定要解决的问题，建立软件的逻辑模型，编写需求规格说明书文档并最终得到用户的认可。需求分析的主要方法有结构化分析方法、数据流程图和数据字典等方法。本阶段的工作是根据需求说明书的要求，设计建立相应的软件系统的体系结构，并将整个系统分解成若干个子系统或模块，定义子系统或模块间的接口关系，对各子系统进行具体设计定义，编写软件概要设计和详细设计说明书，数据库或数据结构设计说明书，组装测试计划。在任何软件或系统开发的初始阶段必须先完全掌握用户需求，以期能将紧随的系统开发过程中哪些功能应该落实、采取何种规格以及设定哪些限制优先加以定位。系统工程师最终将据此完成设计方案，在此基础上对随后的程序开发、系统功能和性能的描述及限制作出定义。
设计
软件设计可以分为概要设计和详细设计两个阶段。实际上软件设计的主要任务就是将软件分解成模块是指能实现某个功能的数据和程序说明、可执行程序的程序单元。可以是一个函数、过程、子程序、一段带有程序说明的独立的程序和数据，也可以是可组合、可分解和可更换的功能单元。模块，然后进行模块设计。概要设计就是结构设计，其主要目标就是给出软件的模块结构，用软件结构图表示。详细设计的首要任务就是设计模块的程序流程、算法和数据结构，次要任务就是设计数据库，常用方法还是结构化程序设计方法。
编码
软件编码是指把软件设计转换成计算机可以接受的程序，即写成以某一程序设计语言表示的"源程序清单"。充分了解软件开发语言、工具的特性和编程风格，有助于开发工具的选择以及保证软件产品的开发质量。
当前软件开发中除在专用场合，已经很少使用二十世纪80年代的高级语言了，取而代之的是面向对象的开发语言。而且面向对象的开发语言和开发环境大都合为一体，大大提高了开发的速度。
测试
软件测试的目的是以较小的代价发现尽可能多的错误。要实现这个目标的关键在于设计一套出色的测试用例（测试数据与功能和预期的输出结果组成了测试用例）。如何才能设计出一套出色的测试用例，关键在于理解测试方法。不同的测试方法有不同的测试用例设计方法。两种常用的测试方法是白盒法测试对象是源程序，依据的是程序内部的的逻辑结构来发现软件的编程错误、结构错误和数据错误。结构错误包括逻辑、数据流、初始化等错误。用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果。白盒法和黑盒法依据的是软件的功能或软件行为描述，发现软件的接口、功能和结构错误。其中接口错误包括内部/外部接口、资源管理、集成化以及系统错误。黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。 维护 维护是指在已完成对软件的研制（分析、设计、编码和测试）工作并交付使用以后，对软件产品所进行的一些软件工程的活动。即根据软件运行的情况，对软件进行适当修改，以适应新的要求，以及纠正运行中发现的错误。编写软件问题报告、软件修改报告。
一个中等规模的软件，如果研制阶段需要一年至二年的时间，在它投入使用以后，其运行或工作时间可能持续五年至十年。那么它的维护阶段也是运行的这五年至十年期间。在这段时间，人们几乎需要着手解决研制阶段所遇到的各种问题，同时还要解决某些维护工作本身特有的问题。做好软件维护工作，不仅能排除障碍，使软件能正常工作，而且还可以使它扩展功能，提高性能，为用户带来明显的经济效益。然而遗憾的是，对软件维护工作的重视往往远不如对软件研制工作的重视。而事实上，和软件研制工作相比，软件维护的工作量和成本都要大得多。
在实际开发过程中，软件开发并不是从第一步进行到最后一步，而是在任何阶段，在进入下一阶段前一般都有一步或几步的回溯。在测试过程中的问题可能要求修改设计，用户可能会提出一些需要来修改需求说明书等。
：
分析
软件需求分析就是对开发什么样的软件的一个系统的分析与设想。它是一个对用户的需求进行去粗取精、去伪存真、正确理解，然后把它用软件工程开发语言（形式功能规约，即需求规格说明书）表达出来的过程。本阶段的基本任务是和用户一起确定要解决的问题，建立软件的逻辑模型，编写需求规格说明书文档并最终得到用户的认可。需求分析的主要方法有结构化分析方法、数据流程图和数据字典等方法。本阶段的工作是根据需求说明书的要求，设计建立相应的软件系统的体系结构，并将整个系统分解成若干个子系统或模块，定义子系统或模块间的接口关系，对各子系统进行具体设计定义，编写软件概要设计和详细设计说明书，数据库或数据结构设计说明书，组装测试计划。在任何软件或系统开发的初始阶段必须先完全掌握用户需求，以期能将紧随的系统开发过程中哪些功能应该落实、采取何种规格以及设定哪些限制优先加以定位。系统工程师最终将据此完成设计方案，在此基础上对随后的程序开发、系统功能和性能的描述及限制作出定义。
设计
软件设计可以分为概要设计和详细设计两个阶段。实际上软件设计的主要任务就是将软件分解成模块是指能实现某个功能的数据和程序说明、可执行程序的程序单元。可以是一个函数、过程、子程序、一段带有程序说明的独立的程序和数据，也可以是可组合、可分解和可更换的功能单元。模块，然后进行模块设计。概要设计就是结构设计，其主要目标就是给出软件的模块结构，用软件结构图表示。详细设计的首要任务就是设计模块的程序流程、算法和数据结构，次要任务就是设计数据库，常用方法还是结构化程序设计方法。
编码
软件编码是指把软件设计转换成计算机可以接受的程序，即写成以某一程序设计语言表示的"源程序清单"。充分了解软件开发语言、工具的特性和编程风格，有助于开发工具的选择以及保证软件产品的开发质量。
当前软件开发中除在专用场合，已经很少使用二十世纪80年代的高级语言了，取而代之的是面向对象的开发语言。而且面向对象的开发语言和开发环境大都合为一体，大大提高了开发的速度。
测试
软件测试的目的是以较小的代价发现尽可能多的错误。要实现这个目标的关键在于设计一套出色的测试用例（测试数据与功能和预期的输出结果组成了测试用例）。如何才能设计出一套出色的测试用例，关键在于理解测试方法。不同的测试方法有不同的测试用例设计方法。两种常用的测试方法是白盒法测试对象是源程序，依据的是程序内部的的逻辑结构来发现软件的编程错误、结构错误和数据错误。结构错误包括逻辑、数据流、初始化等错误。用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果。白盒法和黑盒法依据的是软件的功能或软件行为描述，发现软件的接口、功能和结构错误。其中接口错误包括内部/外部接口、资源管理、集成化以及系统错误。黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。
维护
维护是指在已完成对软件的研制（分析、设计、编码和测试）工作并交付使用以后，对软件产品所进行的一些软件工程的活动。即根据软件运行的情况，对软件进行适当修改，以适应新的要求，以及纠正运行中发现的错误。编写软件问题报告、软件修改报告。
一个中等规模的软件，如果研制阶段需要一年至二年的时间，在它投入使用以后，其运行或工作时间可能持续五年至十年。那么它的维护阶段也是运行的这五年至十年期间。在这段时间，人们几乎需要着手解决研制阶段所遇到的各种问题，同时还要解决某些维护工作本身特有的问题。做好软件维护工作，不仅能排除障碍，使软件能正常工作，而且还可以使它扩展功能，提高性能，为用户带来明显的经济效益。然而遗憾的是，对软件维护工作的重视往往远不如对软件研制工作的重视。而事实上，和软件研制工作相比，软件维护的工作量和成本都要大得多。
在实际开发过程中，软件开发并不是从第一步进行到最后一步，而是在任何阶段，在进入下一阶段前一般都有一步或几步的回溯。在测试过程中的问题可能要求修改设计，用户可能会提出一些需要来修改需求说明书等。 以上由长沙软件开发编辑整理于网络，如想获知更多信息请访问www.sjin.cn
软件开发工具包（Software Development Kit，即SDK）一般是一些被软件工程师用于为特定的软件包、软件框架、硬件平台、操作系统等建立应用软件的开发工具的集合。
它或许只是简单的为某个程序设计语言提供应用程序接口的一些文件，但也可能包括能与某种嵌入式系统通讯的复杂的硬件。一般的工具包括用于调试和其他用途的实用工具。SDK还经常包括示例代码、支持性的技术注解或者其他的为基本参考资料澄清疑点的支持文档。
软件工程师通常从目标系统开发者那里获得软件开发包。为了鼓励开发者使用其系统或者语言，许多SDK是免费提供的。SDK经常可以直接从互联网下载。有时也被作为营销手段。例如，甲产品或许会免费提供构件SDK以鼓励人们使用它，从而会吸引更多人由于能免费为其编程而购买其构件。
SDK可能附带了使其不能在不兼容的许可证下开发软件的许可证。例如一个专有的SDK可能与自由软件开发抵触。而GPL能使SDK与专有软件开发近乎不兼容。LGPL下的SDK则没有这个问题。以上文章由长沙软件开发编辑整理于网络，如想获知更多相关信息请访问www.sjin.cn |
1. ORACLE
oracle能在所有主流平台上运行（包括 windows）。完全支持所有的工业标准。采用完全开放策略。可以使客户选择最适合的解决方案。对开发商全力支持.oracle并行服务器通过使一组结点共享同一簇中的工作来扩展windownt的能力，提供高可用性和高伸缩性的簇的解决方案。如果windowsNT不能满足需要，用户可以把数据库移到UNIX中。Oracle的并行服务器对各种UNIX平台的集群机制都有着相当高的集成度。oracle获得最高认证级别的ISO标准认证.oracle性能最高， 保持开放平台下的TPC-D和TPC-C的世界记录oracle多层次网络计算，支持多种工业标准，可以用ODBC、JDBC、OCI等网络客户连接。长时间的长沙网站建设开发经验，完全向下兼容。得到广泛的应用。完全没有风险。
Oracle在兼容性、可移植性、可联结性、高生产率上、开放性也存在优点。Oracle产品采用标准SQL，并经过美国国家标准技术所（NIST）测试。与IBM SQL/DS，DB2，INGRES，IDMS/R等兼容。 Oracle的产品可运行于很宽范围的硬件与操作系统平台上。可以安装在70种以上不同的大、中、小型机上；可在VMS、DOS、UNIX、WINDOWS等多种操作系统下工作。能与多种通讯网络相连，支持各种协议（TCP/IP、DECnet、LU6.2等）。提供了多种开发工具，能极大的方便用户进行进一步的开发。Oracle良好的兼容性、可移植性、可连接性和高生产率是Oracle RDBMS具有良好的开放性。
Oracle价格是比较昂贵的。据说一套正版的oracle软件早在2006年年底的时候在市场上的价格已经达到了6位数。所以如果你的项目不是那种超级大的项目，还是放弃Oracle吧。
2. SQLSERVER
SQL Server 是Microsoft推出一套产品，它具有使用方便、可伸缩性好、与相关软件集成程度高等优点，逐渐成为Windows平台下进行数据库应用开发较为理想的选择之一。SQLServer是目前流行的数据库之一,它已广泛应用于金融,保险,电力,行政管理等与数据库有关的行业.而且,由于其易操作性及友好的界面,赢得了广大用户的青睐,尤其是SQLServer与其它数据库,如Access,FoxPro,Excel等有良好的ODBC接口,可以把上述数据库转成SQLServer的数据库,因此目前越来越多的读者正在使用SQLServer.
Sqlserver由于是微软的产品，又有着如此强大的功能，所以他的影响力是几种数据库系统中比较大，用户也是比较多的。它一般是和同是微软产品的.net平台一起搭配使用。当然其他的各种开发平台，都提供了与它相关的数据库连接方式。因此，开发软件用sqlserver做数据库是一个正确的选择。
3. MYSQL
MySQL不支持事务处理，没有视图，没有存储过程和触发器，没有数据库端的用户自定义函数，不能完全使用标准的SQL语法。
从数据库行家听说的第一件事就是MySQL缺乏transactions，rollbacks， 和subselects的功能。如果你计划使用MySQL写一个关于银行、会计的应用程序，或者计划维护一些随时需要线性递增的不同类的计数器，你将缺乏transactions功能。在现有的发布版本的MySQL下，请不要有任何的这些想法。（请注意，MySQL的测试版3.23.x系列现在已经支持transactions了）。
在非常必要的情况下，MySQL的局限性可以通过一部分开发者的努力得到克服。在MySQL中你失去的主要功能是subselect语句，而这正是其它的所有数据库都具有的。换而言之，这个失去的功能是一个痛苦。
MySQL没法处理复杂的关联性数据库功能，例如，子查询（subqueries），虽然大多数的子查询都可以改写成join
另一个MySQL没有提供支持的功能是事务处理（transaction）以及事务的提交（commit）/撤销（rollback）。一个事务指的是被当作一个单位来共同执行的一群或一套命令。如果一个事务没法完成，那么整个事务里面没有一个指令是真正执行下去的。对于必须处理线上订单的商业网站来说，MySQL没有支持这项功能，的确让人觉得很失望。但是可以用MaxSQL，一个分开的服务器，它能通过外挂的表格来支持事务功能。
外键（foreignkey）以及参考完整性限制（referentialintegrity）可以让你制定表格中资料间的约束，然后将约束（constraint）加到你所规定的资料里面。这些MYSQL没有的功能表示一个有赖复杂的资料关系的应用程序并不适合使用MySQL。当我们说MySQL不支持外键时，我们指的就是数据库的参考完整性限制--MySQL并没有支持外键的规则，当然更没有支持连锁删除（cascadingdelete）的功能。简短的说，如果你的工作需要使用复杂的资料关联，那你还是用原来的Access吧。
你在MySQL中也不会找到存储进程（storedprocedure）以及触发器（trigger）。（针对这些功能，在Access提供了相对的事件进程（eventprocedure）。
Mysql+php+apache三者被软件开发者称为“php黄金组合”。
以上由长沙网站建设编辑整理,如想获取更多相关知识请访问www.sjin.cn
在当前社会，信息技术的更新速度是惊人的，
长沙网站建设程序员的职业生涯则是一个要求不断学习的过程，如何才能成为一名合格的程序员，一名合格的程序员需要掌握哪些技能呢？
长沙网站维护程序员应该如何提高自身的水平与能力呢？笔者根据自己几年的
长沙软件开发经验，总结出了以下3点。
一、坚持“学无止境”的思想。
技术的发展是飞快的，特别是在计算机这个专业上，不论是硬件还是软件，新技术和新内容是日新月异。就拿笔者使用的.net开发平台来说，自从我2006年接触.net以来，.net framework与开发工具就已经从当时最开始的1.0版本+VS2003，到2007年的2.0版本+VS2005，2008年的3.5版本+VS2008直到当前的4.0版本+VS2010,基本上是以一年一个新版本的速度在更新；而听说5.0版本也正在研发中，不久的未来也将揭开它神秘的面纱。与此同时，各种新的开发技术与专业词汇也是层出不穷。 如：2.0的泛型；3.5中的Linq；4.0的silverlight等。所以，我们做程序员的，就是要不断的学习，学习这些新的东西，并将他们用户到实际的工作中去，这样才能跟得上软件行业如此飞速的发展速度，我们开发出来的软件产品才能在市场上有更大的竞争能力。
二、要学会手脑并用，把理论与实践相结合
上面说到时程序员只有不断学习，才能跟得上软件行业如此飞速的发展速度。但是如何是学习，怎么样才是正确的学习方法，怎样才能把学习到的东西应用到实际中去，也许这也是很多程序员感到迷惑的地方。根据笔者多年的学习经验，在这向朋友们提出的学习方法就是一定要学会手脑并用，把理论与实践相结合。现在有很多人说现在的软件公司看重的是员工的动手能力，根本不会看员工的理论知识水平，因此他们在学习过程中，就只注重动手而忽略理论知识的学习。对于这个观点，我是极力反对的。一个理论知识不好的程序员，他永远不会成为一个优秀的程序员。笔者就曾经看到过这样的
长沙网站建设程序员。动手能力很强，在键盘上敲代码是飞快，甚至是连NHibernate的配置代码都能手写出来，但是一问理论知识他们就成哑巴，做了一两年coder，竟然分不清数据库的左连接与右连接；分不清数据结构中的堆栈与队列的区别。这样的程序员写出的软件质量也就可想而知了。所以说我们在学习过程中理论与实践一定要相结合，这样才能成为一个优秀的程序员。
三、要忘记Ctrl+C与Ctrl+V
俗话说“熟读唐诗三百首，不会做诗也会吟”。因此，在程序员学习成长的过程中，多在网上下载一些别人优秀的代码参考学习也是个非常好的学习方法。但是我们从别人的程序中看到一段适合自己的代码以后，如何把他他用到自己的工作和程序中去，这也是一个值得说说的问题。笔者认识的大多数程序员朋友在这方面和做法就是不顾一切的一把复制粘贴，只要程序能调试通过就万事大吉，一切OK。其实这是一个很不好的学习习惯。只是这样简单的复制粘贴，它里面的精髓根本就没有进入到你的脑子中去，也就是说他它并没有真正成为你自己的东西。因此我认为，如果硬要粘贴上去，不如自己照着人家的代码，一个个字符的敲一遍，这样才能在一定程度上更多的理解程序内部的东西与机制，以后还能举一反三，并且在代码不适合自己项目的情况下能够快速的做也适当的修改，让人家的东西真正成为自己的东西。
以上3点是本人对本人对几年来在工作中遇到的问题与对经验的小小总结。欢迎大家有不同意见的和我来探讨一正，大家共同进步。