#
簡介
外包從本質上說可以用一個英文單詞－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點是本人對本人對幾年來在工作中遇到的問題與對經驗的小小總結。歡迎大家有不同意見的和我來探討一正，大家共同進步。