什麼是 Agile Software Development（敏捷軟體開發）？
由於邀請人數有限，麻煩各位知友幫忙邀請大牛。
敏捷編程即軟體行業力圖適應現代商業環境的具體表現！
首先說點歷史，隨著軟體行業的迅猛發展，軟體系統的規模越來越大，複雜程度越來越高，開發周期與開發成本失控的問題愈發嚴重，同時軟體的可靠性也無法保證。為解決這一系列問題，軟體行業很自然的求助於傳統的工程學、管理學方法。「軟體工程學」 由此因運而生。以「瀑布模型」為代表的傳統軟體開發模型針對軟體生命周期的各個階段提供了一套規範, 以期使工程的進展達到預期的目的。核心強調在軟體開發活動中, 所有的活動計劃, 日程安排, 交付工作都要直接或間接的和需求保持一致, 同時強調軟體需求必須形成「 文檔」 。這種基於計劃的生命周期的軟體開發方法曾極大地促進了軟體行業的發展，但現如今卻愈感「有心無力」。為了適應現代的商業環境與之對應的「敏捷編程」的開發方法提了出來。包括諸如「極限編程」、自適應軟體開發和功能驅動開發等。其他答案已從定義上給予了說明，我就結合敏捷軟體開發宣言從商業環境探究這一開發方法的本質與起源。
- 個體和交互 勝過 過程和工具
敏捷開發強調把關注點回歸到「人」上，其背後的哲學思想可追溯到康德的「人即目的」。
同時，主張面對面交流和客戶參與開發, 彌補了缺少文檔而產生信息流通不暢問題, 認為開發人員之間、開發人員和客戶之間相互協作、相互信任、彼此尊重是保證溝通成功的必要條件。背後的商業環境現實就是——開發過程中的人力資本的高企。
一個典型的項目花在人力上的金錢是花在硬體上的時間的20 倍, 這意味著一個項目每年要花2 0 萬美元在程序員身上, 而僅僅花10 萬美元在電腦設備上。很多聰明的程序員說: 「 我們如此聰明, 發現一種方法可以節省20%的硬體開銷」 , 然後他們使得源程序大且難懂和難以維護, 他們會說: 「 但是我們節省了20%或者2 萬美元每年, 很大的節省」 。但財務事實告訴我們，如果程序簡單而且容易擴展, 我們將至少節省10%的人力開銷，這將是一筆更大的節省。同時，軟體開發的職業本身也決定了數量少但精幹的團隊的效率與產出大於臃腫、混亂的大團隊。敏捷開發一般適用於20-40人、甚至更少。- 可以工作的軟體 勝過 面面俱到的文檔
區別於傳統的軟體開發模式，客戶只有在系統被開發完成以後才能真正去體會它。敏捷編程通過要求不斷交付可用的軟體, 周期越短越好，加強客戶的反饋來縮短開發的周期, 同時獲得足夠的時間來改變功能和獲得用戶的認同。
背後的商業環境現實就是——「快魚吃慢魚」的競爭模式。
區別於工業社會的利用流水線、規模化的生產模式，信息時代更強調對用戶需求的快速響應。標準化生產所帶來的低成本、高可靠性的特點不能直接保證市場的高份額。相反，對用戶需求的細膩把握和快速響應卻是以用戶為導向的服務型公司的生命線！- 客戶合作 勝過 合同談判
敏捷開發要求在項目過程中, 業務人員與開發人員必須在一起工作，參與開發，採用高效信息的交互平台以及能夠減少歧義溝通和交流的方式進行支持。敏捷方法完成了從重視文本到重視對話,從重視書寫到重視理解的轉換。
背後的商業環境現實就是——用戶無法對其自身需求進行有效描述
最經典的例子莫過於蘋果的iPad、iPhone了。在喬布斯沒有推出iPhone之前，用戶是不知道他們需要智能機，更準確地來說就是無法對智能機的需求進行有效描述的。這也就是為什麼諸如諾基亞、摩托羅拉等公司失敗的原因之一。他們不是沒有市場部門，不是沒有進行市場調研、用戶需求分析，問題在於一般用戶在缺乏相關知識與指導的情況下是無法對自身需求（特別是潛在需求）進行有效描述。這一缺陷在市場競爭隨著節奏的加快顯得愈發致命！
- 響應變化 勝過 遵循計劃
敏捷開發的口號是擁抱變化，即歡迎對需求提出變更，甚至是在項目開發後期。要善於利用需求變更, 幫助客戶獲得競爭優勢。
背後的商業環境現實就是——試錯成本低、執行力要求高現代社會最重要的特點就是多元化，用所謂的「互聯網思維」說就是「去中心化」，具體到個人應該就是 Open mind。這一社會現實反應在軟體開發上就是 試錯成本變得相當較低。但與此同時，快速變化的商業大環境也對執行力提出了高要求，而執行力的關鍵指標就是對變化的快速響應！課上剛講過，來答一記~
一、概念
敏捷軟體開發：又稱敏捷開發，是一種從1990年代開始逐漸引起廣泛關注的一些新型軟體開發方法，是一種應對快速變化的需求的一種軟體開發能力。 它們的具體名稱、理念、過程、術語都不盡相同，相對於「非敏捷」，更強調程序員團隊與業務專家之間的緊密協作、面對面的溝通（認為比書面的文檔更有效）、頻繁交付新的軟體版本、緊湊而自我組織型的團隊、能夠很好地適應需求變化的代碼編寫和團隊組織方法，也更注重軟體開發中人的作用。二、 敏捷聯盟
2001年初，由於許多公司的軟體團隊陷入了不斷增長的過程的泥潭，一批業界專家聚集在一起概括出一些可以讓軟體開發團隊具有快速工作、響應變化能力的價值觀和原則。他們稱自己為敏捷（Agile）聯盟。敏捷聯盟宣言：
我們正通過親身實踐以及幫助他人實踐，揭示更好的軟體開發方法。通過這項工作，我們認為：? 個體和交互 勝過 過程和工具
人是獲得成功最重要的因素。 一個優秀的團隊成員能很好地和他人合作，即合作、溝通以及交互能力要比單純的編程能力更重要。 合適的工具對成功很重要，但不要過分誇大工具的作用。 團隊的構建比環境的構建重要得多。? 可以工作的軟體 勝過 面面俱到的文檔
沒有文檔的軟體是一種災難，但過多的文檔比過少的文檔更糟糕。 對團隊而言，需要編寫並維護一份系統原理和結構方面的文檔。? 客戶合作 勝過 合同談判
成功的項目需要有序、頻繁的客戶反饋。不是依賴於合同或者關於工作的陳述，而是讓軟體的客戶和開發團隊密切地在一起工作，並盡量經常提供反饋。 那些為開發團隊和客戶的協同工作方式提供指導的合同才是最好的合同。? 響應變化 勝過 遵循計劃
響應變化的能力常決定一個軟體項目的成敗。 計劃不能考慮過遠。 較好的做計劃的策略是：為下兩周做詳細的計劃，為下三個月做初略的計劃，再以後就做極為初略的計劃。三、敏捷原則（這是敏捷實踐區別於重過程的特徵所在）- 最優先要做的是：通過儘早地、持續地交付有價值的軟體來使客戶滿意。（獲取有質量軟體的理念）
- 即使到了開發後期，也歡迎改變需求。敏捷過程利用變化來為客戶創造競爭優勢。 （關於態度的聲明）
- 經常交付可工作的軟體，其時間間隔可以是幾周到幾個月。 交付的時間間隔越短越好。（項目規劃的理念，涉及如何處理文檔和軟體項目開發之間的關係）
- 在整個項目開發期間，業務人員和開發人員必須天天在一起工作。（團隊組成和精神問題）
- 不斷激勵開發人員，開展項目的有關工作。給他們提供 所需要的環境和?支持，並信任他們能夠完成所承擔的工作。（ 「領導」的含義-涉及管理功能）
- 在團隊內部，最有效果的、最有效率的傳遞信息的方法，就是面對面的交談。（獲取開發信息（需求、技術信息和項目信息等）的途徑）
- 首要的進度度量標準是工作的軟體。（進度度量的理念）
- 敏捷過程提倡可持續的開發速度。責任人、開發者和用戶應該能夠保持一個長期的、恆定的開發速度。（項目「持續發展」的能力）
- 不斷關注優秀的技能和設計，增強敏捷能力。（提高敏捷能力的一種途徑）
- 簡單是根本的。（使未完成的工作最小化的藝術）
- 最好的體系結構、需求和設計，出自自己組織的團隊。（團隊觀念----一種軟體項目管理的理念）
- 每隔一段時間，團隊對如何才能有效的工作進行反省，然後對自己的行為進行適當的調整。（自我調整和適應）
注：以上12條是敏捷開發的實踐原則。實踐的語義比過程更寬泛，包擴活動以及與活動相關的人和基礎設施。
敏捷方法和敏捷是不同的，敏捷是一種方法論，而敏捷方法是把這些理論落地的具體實踐這有點像類和對象的關係。所以在敏捷的框架下有很多方法，比如XP、Scrum、Crystal等，你也可以根據你自己的理解進行改良和優化。比如在響應變化 勝過 遵循計劃這條原則下Scrum的方法是通過短期sprint和
retrospective 兩種實踐來達到相應變化的目的，當然你也可能覺得retrospective的方式不一定用會議的方式，那麼你完全可以改良它。所以敏捷很大程度上取決於你對它的理解，而不只是生搬硬套的使用它。最後，很多公司陷入了一種奇怪的循環，似乎是為了敏捷而敏捷，總是刻意的追求方法，在我看來任何方法如果對業務生產和目標如果沒有任何幫助，那麼它都是失敗的。
既然題主問的是「Agile Methodology」,那麼便應該比限定在「軟體開發」領域要更加寬泛。本回答從「敏捷開發」出發，嘗試解讀究竟什麼才是「敏捷」。
「敏捷」概念的引入最先是從軟體開發領域引入的。傳統的軟體開發採用的是瀑布式開發的流程，把整個開發過程分成了收集需求、定義、設計、編碼、測試、發布等階段，每個階段設定明確的目標和標準，達成後再進入下一個階段，整個過程沿著可預測性逐步增加的方向前進，可以避免資源的無效投入，並有效地保證開發質量。
但問題在於瀑布式開發這種預定義過程的方法，每個階段之間都有強烈的依賴關係，前一個階段被視為後一個階段的輸入，如果輸入質量不高，便會嚴重影響後續階段的輸出質量。同時，如果前一個階段未能達到標準，也會造成後續階段的停滯，導致開發周期拉長。並且，項目早期即作出承諾導致對後期需求的變化難以調整，代價高昂。
所以敏捷開發就是在提出這樣一個問題的背景下所誕生的。有數據顯示有70%採用瀑布式開發方法的軟體開發項目均已失敗告終。原因便在於，市場的需求瞬息萬變，很難實現產品需求的明確且完整地收集；同時，技術的發展也日新月異，對於所定義功能的可實現性也面臨著多重不確定性的因素。所以當需求收集和產品定義工作無法得到很好地完成，瀑布式開發方法自然無法擺脫高失敗率的命運。
所以從需求的明確性和工程實現的確定性兩個緯度出發，當需求的不明確性和工程實現的不確定性均超出一定範圍之後，呈現出複雜系統（Complex System）的特徵，瀑布式開發這種結構化的開發方法便不再實用。而敏捷開發方法正是在這樣的背景下誕生。
敏捷開發的一個核心思維模式的轉換便是：從瀑布式開發所代表的「Fix Scope, Flex time」（固定範圍，彈性時間）轉向「Fix time, Flex Scope」——固定時間，彈性範圍。 在市場變化和技術變化的背景之下，既然市場需求和產品定義所代表的「範圍」無法實現固化，因而無法確定應該投入多少資源來完成，那不妨固定好已有資源的，以資源為約束，實現「範圍」的最大化實現。因此從「計劃驅動」轉向為「價值驅動」。
而在敏捷開發的思維模式提出後，一方面誕生了「個體與交互勝過過程與工具」、「可以工作的軟體勝過面面俱到的文檔」、「客戶協作勝過合同談判」、「響應變化勝過遵循計劃」這樣的代表敏捷價值觀的「敏捷宣言」，充分發揮「人」作為代碼編寫者在軟體開發過程中的價值。
同時在敏捷宣言的指引之下也產生了多種多樣的敏捷開發方法，如衝刺和迭代式的「Scrum」方法，更進一步通過具體的實施手段展現「敏捷宣言」所代表的敏捷價值觀。
從「敏捷開發」可以看出，敏捷不僅僅簡單只是一個形容詞，更代表了一種方法，那麼究竟什麼才是「敏捷」呢？
1. Complex System Context 以「複雜系統」為背景
敏捷並不是一個普世的方法，而是具有一定語境和背景的，如同敏捷開發的誕生，也是在市場瞬息萬變和技術日新月異的背景之下而產生的。
「敏捷典型」是以「複雜系統」為背景。作為一種方法，最終都是被「人」所採納並實施。而人對於世界的認知和理解始終朝著減少未知「Unknown」和不確定性「Uncertainty」兩個方向前進，對於未知需要逐步理解（Understandable），而對於不確定性，通常是提前預測，通過反饋，來獲得判斷（Predictable）。因此可理解和可預測也成了人認知世界的兩個緯度。
但無論科學技術如何進步，對世界的很多事物已經達到可理解、可預測的地步，但依然還存在非常多的不可理解或不可預測的事物。特別是每個人的認知能力也存在差異，相同的事物對某些具有足夠認知能力的人來說是可理解、可預測的，但如果認知能力不足，便會出現既無法理解、也無法預測這樣的「混亂系統」（Chaotic）。
而複雜系統（Complex）也是同樣，當相對於人的認知而言，對可理解性和可預測性均提出一定高度的要求，便呈現出複雜系統的特徵。如同敏捷開發所產生時的背景，市場瞬息萬變，需求變得不可預測；技術日新月異，對某些需求的技術可實現性也變得越來越難以理解。但這種不可理解性和不可預測性並沒有遠遠超出人的認知潛能的範圍，沒有到達徹底混亂的地步；同時，通過過程中不斷地反饋和學習，也可以逐漸消除未知和不確定。因此，對於這樣的複雜系統，運用敏捷方法，將可以更好地獲得對系統的理解和預測。
2. Human-Driven 以人為核心驅動
敏捷的另一個特徵是「以人為核心驅動」——Human Driven。
對於適用敏捷方法而言，其最終的目的是為了理解所處的複雜系統，激發複雜系統所具有的能量。更強調「系統」對於「人」的價值，而非單純地承認其「複雜」的特徵。
同時複雜系統又是一個相對的概念，是相對於人的認知能力而言。而對於複雜系統，其認知的過程依然會沿著「可理解」「可預測」兩個方向發展，這其中「人」將扮演主要的角色，需要充分挖掘「人」的潛能。
無論對「目的」而言，還是「過程」而言，在運用「敏捷」方法時，「人」都是認知和運轉「複雜系統」過程中的核心驅動力。
所以這也對運用「敏捷」方法的「人」提出要求，需要思維模式和價值觀的支撐，才能真正理解並運用「敏捷」方法。在《管理3.0》一書中，作者Jurgen Appelo給出了一個具有六隻眼睛的異形生物，並取名為「Martie」，代表了運用「敏捷」方法的人應該所具備的六種思維模式：
- Energize People 有效激勵
- Empower Teams 賦能團隊
- Align Constraints 調和約束
- Develop Competence 發展能力
- Grow Structure 結構成長
- Improve Everything 全面改善
3. Adaptive Empirical Process Control 具有適應能力的經驗性過程式控制制
「敏捷」的第三個特徵便是：「敏捷」實際上是一種經驗性的過程式控制制方法。作為一種方法，通常都具有一定的目的性，而為了達成目的，勢必要實施一定的過程式控制制，才能提升達成目標的幾率。而在「複雜系統」的背景之下，「瀑布式開發」所代表的預定義過程式控制制（Predefined Process Control）已不再適合，而以人為核心驅動的經驗性過程式控制制（Empirical Process Control）將具有更高的適應性和靈活性，同時也能充分發揮「人」的潛能和價值。
人類在進化過程以及認知、改造世界的過程中始終都面臨著各種「未知」（Unknown）和「不確定」（Uncertainty），所以人類的歷史天然就是一個「敏捷」的過程。
讓我們藉助一部經典動畫片《瘋狂原始人》中的人物和場景，來更好地表達「敏捷」這樣一個經驗性過程式控制制方法需要遵循哪些原則。
Rule1:適應性原則。Keep Relevant-時刻保持與背景「複雜系統」的關聯，適應「複雜系統」的變化。
Rule2: 靈活性原則。Always be optional-擁有多重選項，根據環境的變化進行靈活選擇。
Rule3: 利用系統的「原力」——Leverage the Gravity。人的力量畢竟微弱，需要充分挖掘「複雜系統」自有的力量並加以利用。
Rule4: 模式識別——Patterns Recognition。識別「複雜系統」中所呈現出的「模式」，基於「模式」，逐步理解「複雜系統」。
Rule5: 「自下而上」原則（Bottom-up）。由於「複雜系統」的未知性和不確定性，在缺乏必要信息的情況下，無法通過「自上而下」（Top-down）的方式來理解系統。因此，從基本的「模式」出發，並在過程中學習和認知，不斷地向上發展更高層的「模式」，才能最終實現對「複雜系統」的全面認知。
三、總結
所以，「敏捷」（Agile）代表的是一種方法，是在「以人為核心驅動」（Human-Driven）的「複雜系統」（Complex System）背景下，一個具有適應性的「經驗性過程式控制制方法」 （Adaptive Empirical Process Control）。
http://weixin.qq.com/r/HDkcBNnEnITjrZ1n92wO (二維碼自動識別)
作者：Waterwalker鏈接：什麼是敏捷？ - 敏捷銷售 - 知乎專欄來源：知乎著作權歸作者所有。商業轉載請聯繫作者獲得授權，非商業轉載請註明出處。人是一種需要持續能看到行動的正反饋的動物，只有持續地有正反饋人才能堅持重複一個過程。嗑瓜子就是持續有正反饋，長期學習計劃之所以很難堅持也是因為沒有足夠快的正反饋
敏捷編程就是想辦法製造儘可能快的正反饋給程序員，這樣他們不至於很快疲掉，以至於沒有人想繼續工作在這個項目上了人和交互 重於 過程和工具
可以工作的軟體 重於 求全責備的文檔
客戶協作 重於 合同談判
隨時應對變化 重於 循規蹈矩
=================分割線====================
其中位於右邊的內容雖然也有其價值，但是左邊的內容更為重要。
天朝的軟體工程教育只教給大家一種軟體生命周期模型，就是大家所熟知的瀑布模型。真相是，當初提出這個模型，只是為了做個靶子，由此建立了對軟體工程的研究。實際上，美利堅國的長期開發實踐早已拋棄了瀑布模型。有各種各樣的模型，他們都有一個共同特徵：迭代。區別，只是不同的迭代規則，不同的迭代周期，不同的驅動力，不同的決策過程而已。可是他們之中，在天朝流行起來的只有三種。第一種，叫做極限編程。第二種，叫做敏捷開發。第三種，叫做精益開發。為什麼？因為名字起得好！迎合了天朝老闆的心理需求：最大限度壓榨員工。加班到極限，釋放出你的生理潛能！我心浮氣躁，馬上就要，你快點給我出東西！不僅要發揮你的潛能，不僅要快，而且要做精品！精益開發流行比較晚，而且也沒有形成氣候，因為它本質上缺乏對壓榨員工的想像，缺乏對管理者浮躁心態的迎合。所以，要回答這個問題：敏捷是什麼？就不能只回答敏捷在理論上是什麼，那個可以自行百度；還得回答：在大量低水平管理者心目中，敏捷就是快，就是天天加班趕快把東西做出來，就是快快快不要停，啊，終於出來了！
敏捷和速度是兩個不同的屬性。要理解敏捷的概念可以看看凌波微步是什麼樣的。
當你把屬性點加到速度上時你單位時間裡可以寫更多的代碼。當你把屬性點加到敏捷上時你可以更快的轉變方向。傳統：你想清楚你具體要個啥？敏捷：你再看看還有啥要改的。
敏捷，呵呵，快速構建原型，展示給客戶，根據反饋不斷迭代完善……no zuo no die
簡單的說，敏捷開發就是1.迭代中持續交付可用軟體2.在迭代中設立短期目標3.重構概念
傳統的是整個項目我都做完了提交客戶，然後有什麼意見我再回去改。敏捷是我做出一個相對完整的模塊來就給客戶看，然後改進。這就是一個迭代周期
首先你要認識一種生物叫做：項目經理。（蛋疼的磚家【完整】）他們是怎樣的呢？他們認為10個人懷孕一個月就能生出小寶寶。他們甚至有些連打代碼都沒做過。但是確實時間、項目管理的磚家。這就是所謂的敏捷開發的本質：多快好省建設。。。。（水表已拆。我反正覺得敏捷開發無非就是個概念。我現在看到的東西是：敏捷開發是項目經理的一種「方法(approach)」。然後下面有各種各樣防止你延誤工程。時間安排。以及各種各樣的「技能(skills)」。（聽英文學的不知道有沒有錯誤）然後我表示。其實就是把經驗總結成了知識。但這個有沒有靈感，編程快不快不是知識能解決的問題。所以這玩意兒某種程度上就是玄學。反正我學我蛋疼。
別人把我們做事的方式稱作敏捷。
在做一個來自加拿大的教授的作業的時候搜到了這個問題，敏捷開發更注重代碼。
而傳統的開發過程更加註重文檔，是面向過程的，好像文檔寫好了說明我這一步確實做好了。基於北美背景，主要是因為程序員會頻繁的更換工作，在一個公司待一兩年就換地兒，新來的只要看文檔就可以了解到這個公司在做什麼，做到哪個階段了。
而敏捷開發廢棄了傳統的無盡無止的文檔，文檔寫不寫都是可以的，唯一的要求就是產品做的好，是面向產品的。而且可調整性很高，不需要等一個產品的所有功能都實現了才能發布，只要把能盈利的功能做完了，通過測試就可以發布第一個版本，後面的功能按照優先順序接著做，做好了再更新。一個功能可能在預先設想的時候是有的，等前面的幾個功能做完了發現這個功能不需要了，Ok,棄掉。或者在開發過程中發現了新的很必要的功能，那做完手頭這個就做這個新的。
但是這就要求high skilled 和high motivated的員工。
關於團隊管理，要求team leader作為領隊人而不是管理者，團隊每個人都平等但是項目負責人比重更大，共同做出決定，每個人在自己的領域發聲，但是這並不代表這個團隊無組織無紀律。
項目負責人需要找到合適的團隊成員，闡述產品的願景，並且鼓勵大家，保持大家的積極性。雖然開發過程是可調整的，但是負責人要保證這個產品不能完全跑偏。
什麼是敏捷軟體開發?
敏捷軟體開發是一個概念意義上的框架，用來取代軟體工程項目的概念;它強調在項目的整個生命周期中，擁抱並促進由於軟體進化式的發展所帶來的變化。
在項目的整個生命周期中：這就涉及到了【敏捷項目管理】、【敏捷需求獲取】、狹義的【敏捷軟體開發】三個主要的領域和過程。要注意的是，上述三個過程並不是互相分開的，而是你中有我，我中有你。
擁抱並促進變化：世界上唯一不變的是變化。不論在任何領域，漠視、甚至否認、抗拒變化，都不是一個理性，嚴肅的人所應有的態度。學會如何識別變化的大勢，並在可能的時候，促使變化向好的方向發展。這才是面對變化的正確應對之法。
軟體進化式的發展：雖然上面提到促進變化的發展，但是軟體的演化過程，我相信是有其自身內在邏輯的，存在一些根本規律和指導方針;並不是完全以人的主觀意識為主導。
老子講「順勢而為，無為無不為」，我認為是對上述後兩點的精確概括與指導。
了解更多詳情：ACP敏捷介紹
承認不可能一次設計好 不如一點點改好
我覺得是，如果你要開發一個軟體，軟體要實現很多功能，在第一個幾周里，你能主要實現第一個功能的開發測試，成功後，第二個幾周里，再實現第二個功能的開發測試，再來個集成測試。以此類推。總而言之，就是把一個大的軟體開發周期時間分割成很多小份時間，每一個時間段內又是一個完整開發周期。這是我的理解，也許還有錯誤，請大家多多指正。
敏捷開發的精髓是開發人員時刻保持溝通，以解決問題為驅動力而不是設計系統，把任務細化到極致，保證每一天，每半天，甚至每一個小時的工作量都能用一個確切的標誌來描述。另外還包括很多延伸出來的實踐準則，比如保證任意一個時間點，代碼都是可以編譯的。以前聽蘋果的軟體工程師說過，他們系統每兩個小時自動在後台編譯一次。當然還需要有自動化工具作為輔助，比如編譯失敗後會通過代碼文件、行數等確定是誰的改動導致編譯失敗，然後自動在ticketing system里生成ticket，並assign給這個人，等等。
推薦閱讀：
※二分法調試代碼具體指什麼？
※zipline和rqalpha對比？
※面向對象編程為什麼沒有在科學計算領域獲得普及？
※學 C 語言時，有沒有遇到過讓你「痛不欲生」、「揪心」或「不得要領」的術語？現在又是怎麼理解它的？
※寫程序需要編譯器，編譯器是程序，輸入輸出也需要驅動，驅動也是程序，那麼第一個在電子計算機運行的程序是怎麼產生的？