1.世上充滿無數的選擇和努力。但對於成功，選擇大於努力。敏捷開發

是一種選擇。

2.傳統的開發方式有時候會阻礙產品的發展，甚至人的成功。

3.個體和互動重於過程和工具

敏捷方法認為人是軟體開發中最重要的因素，開發團隊成員之間有效的

交流、溝通與協作，比單純的程式設計能力更重要。人與人之間面對面的交

流，是最有效、最迅速的交換資訊方式。

4.可以工作的軟體重於面面俱到的文件

   最根本的文件就是原始碼。文件應當短小精悍、易於維護、主題突出

5.客戶協作重於合同談判

6.隨時相應變化重於循規蹈矩，敏捷開發方法的核心思想是“適應變化

”和“以人為本”

 （1）敏捷開發方法是面向人而非面向過程的

 （2）敏捷開發方法是“主動適應的”而不是預先設定的

7.招聘啟事是從些招聘啟事開始的。而不僅僅是面試。敏捷開發的核心

是人，招到合適的人是所  有開發環節中最重要的。

8.極限程式設計（XP）

  XP注重的核心是“溝通、簡明、反饋和勇氣”，用一句話來概括XP的

這4個核心價值觀就是：通過充分的交流和溝通，使產品的設計儘可能簡

單明瞭；通過客戶經常性的反饋，生產負荷客戶要求的軟體產品，並且

有勇氣迎接需求的改變。

  XP的12個實踐方法：

     客戶計劃的制定、小版本釋出、隱喻、結對程式設計、測試驅動開發

、重構、穩定的進度、程式碼共享、編碼規範、簡單的設計、持續整合、

現場客戶

9.統一過程（RUP）

    RUP試圖總結現代軟體開發過程中所有好的實踐經驗，形成一種有

很強適應性的軟體開發過程。

     它包括了軟體開發中的6大經驗：迭代式開發、管理需求、視覺化

建模、使用基於元件的軟體體系結構、驗證軟體質量、控制軟體變更。

    RUP的9個核心工作流：阿爺無大兒建模、需求、分析月設計、實現

、測試、部署、配置與變更管理、專案管理、環境

10.（精益軟體開發方法）Lean

    消除浪費，將所有的時間花在能夠增加客戶價值的事情上；

    延遲決策，在一個複雜多變的環境中進行軟體開發，需要根絕實際

情況保持可選方案的開放性，但時間不能過長。

    儘早交付，交付週期越快，使用者需求越清晰，軟體應對需求變化的

靈活性就越高，讓客戶的需求來推動工作的進展

    加強學習，承認變化的存在及不可預見性。加強反饋和交流，在實

踐中發現問題，解決問題，並最終形成解決方案。

    授權給團隊，正確的決策取決於準確的資訊，讓開發團隊參與決策

，讓團隊成員充分發揮自己的潛力    

11.SCRUM

  SCRUM是一種靈活地敏捷軟體開發管理過程，

  在一個採用SCRUM的專案中，首先要將所育需要完成的工作列在一個

Product Backlog中，專案開發過程中的需求改變也要寫進去。在每個

Sprint開始前，要召開一個Sprint計劃會議。在Sprint計劃會議中，產

品負責人為Product Backlog中的各項功能確定優先順序。隨後Scrum團隊

按照優先順序，從Product Baklog中挑選他們認為能在這個Sprint中完成

的任務，並把這些任務從Product Backlog中挪到Sprint Backlog中去。

在Sprint的進行過程中，Sprint團隊每天都舉行一個簡短的每日Scrum會

議，一邊團隊中的成員瞭解開發進度。在這個會議上每個Scrum成員要回

答三個問題，分別是從上一次會議到現在我完成了什麼工作，這個會議

後我要完成什麼工作，完成工作的過程中我遇到什麼問題。一個Sprint

結束後，需要召開Sprint評審會議和Srpint回顧會議。開發團隊要在

Sprint評審會議上把這個Sprint的開發成果展示給大家。在Sprint回顧

會議上，團隊成員們會回顧剛剛過去的這個Sprint，從中總結經驗和教

訓。

12.在專案開始制定一個有效的溝通計劃至關重要，對敏捷開發尤其如此。

13.如果真的遇到一個特別大的Story，應該適當地將Story分解

14.在混亂中建立秩序，是Scrum開始階段的目標。

15.敏捷開發倡導面對面的溝通。可以工作的軟體勝過面面俱到的文件。

16.敏捷和Scrum倡導團隊的自我管理，在任務分配上提倡每個人按照興趣和能力自主選擇人物。

17.每日Scrum會議是Scrum的精髓，最簡單又最複雜，如何更有效的召開，需要不斷的改進和探索。

18.固定的時間和固定的地點也有助於團隊把每日Scrum會議堅持下來，至於召開的時間則沒有定論。大多數團隊會選擇早上一上班的時間，因為頭腦清醒。

19.在很多組織中，敏捷開發都是從下到上推行的，儘可能多的得到上層支援是墳場關鍵的。出氣採用敏捷開發的團隊對於迭代開發的實質（可以工作的軟體而不是開發完成功能）要求很容易忽略或者難以達到，不妨循序漸進。

20.由於Scrum具有高度的可視性。所以團隊中誰的狀態都隱瞞不了。關於任務Done的標準是個非常重要的問題，在一開始總以為程式碼完成了就Done了，其實這離Scrum標準還很遠。

21.發現問題不是壞事，Sprint評審可以幫助團隊今早的發現問題，儘早的使用反饋。

22.Sprint回顧會議通常是最容易被忽略的。然而，Sprint回顧會議其實是非常有用的，他是整個Scrum框架中第二重要的事件，因為他是讓Scrum團隊成長起來的最好機會。如果不開Scrum回顧會議，不久後你就會發現，你的團隊在不斷的犯著同樣的錯誤。

23.不應該有理由和藉口拋棄團隊。

24.不要隱瞞團隊的技術實力，否則很難做切合實際的計劃和評估

25.wiki是個不錯的敏捷專案文件管理工具

26.善於尋求幫助是個好習慣，不僅僅是針對敏捷開發專案

26.Prodect Backlog，User Story 和Task的區別。

產品要完成的功能清單叫做ProductBacklog，每一個Backlog項叫做Story，因為它是由User Story來描述的，一個Story是由一個完整的User Story來描述的，有時候，一個比較複雜的Story可以分解若干個更小的Story。Task是任務，在具體實現每個Story時候都要將其分解成具體的任務，比如編碼、測試、調研、程式碼評審等，這些都是任務，而不能成為Story

27.撲克牌背後的敏捷思想是團隊中沒有絕對的權威，每個人都有可取之處，要避免少數服從多數。

28.類似升級機器這類雜七雜八的事情可以算在計劃預留的緩衝時間裡面。

29．機械地實施敏捷是一開始比較容易犯的錯誤。敏捷並不是一種過程。

30、燃燒曲線（burndown chart）是衡量團隊進度的重要工具，但是不要過分依賴它作為監督和考核依據。否則就會變味。因為團隊會把重點放在生成漂亮的曲線上，而不是專案本身。

31．Scrum Master要有敏銳的嗅覺，及時發現團隊成員遇到的問題。

32.敏捷開發可以使專案具有高度的可視性，並能夠及時發現問題。

33．Sprint評審會議實際上是非正式的會議，但是可以要求高層參加。會議的氣氛可以活躍一點，避免程式設計嚴肅的報告會。Sprint評審會議上要避免過多的談論技術細節，而是關注最後的成果。

34.敏捷強調面對面的溝通，創造一個有利於敏捷溝通的工作環境至關重要，有時候動動腦筋就會不大一樣。

35.避免不必要的浪費是精益軟體開發的思想，也同時是敏捷開發所倡導的。Sprint計劃會議還要確定Sprint最後演示的時間和每個Story的演示方式。

36.Sprint Goal是個鼓舞士氣的好工具。

37．Sprint計劃會議的時間拖得再長也難有好的結果，應該果斷結束。在Sprint計劃會議之前應該有所準備。

38．在Scrum中，實際上要求Scrum團隊是跨職能的。一個Scrum團隊應該包括開發人員、測試人員、美工及文件人員。敏捷的開發流程迫切需要一個跨職能的團隊。

39.結對程式設計的阻力在於人，沒有嘗試到結對程式設計的好處之前對其不理解也是正常的。

40．將投資和回報最大化，快速反應市場的風雲變換，敏捷開發是應對未接的最好武器。

41.面對面的溝通是最有效的方式。在一個異地開發專案的初期，核心人員進行面對面的接觸是非常必要的，儘管費用會增加一些。但是從長期效果來看，這樣會節省很多溝通成本。

42.Scrum Master要能夠排除開發人員和產品負責人之間的障礙，確保Scrum達成目標，實現投資最大化，確保團隊進度、確保退隊狀態具有高度的可視性，激發團隊創造力，提高團隊的開發水平，採用各種優秀的工程實踐，提高生產力等。

43.Scrum專家建議對Scrum團隊整體進行考核，不過在現實操作中，還是會對每個人進行考核。

44.Scrum的可視效能夠保證及時發現問題。不要隱瞞風險。要用非技術語言給客戶提供足夠的資訊以便他們能夠及時決策。

45.兩個Sprint之間設定一定的緩衝時間，為兩個Sprint起到承上啟下的作用。

46.Team Pulse Survey的各項實際上告訴我們應該如何成為一個成熟的Scrum團隊。

47．按照產品整合部門可以大大提高執行效率，開發和測試在行政上屬於一個部門有利於是他們結合成一個真正的Scrum團隊。

48.效能測試也是系統測試的一種。關於系統測試的介入時機，常見的作風是在第N+1個迭代測試第N個迭代的功能。

49．Scrum要求在一個Sprint中團隊成員高度穩定。

50．無論以什麼方式，儘早讓客戶參與到Sprint中來，無疑可以增加成功的砝碼。

51.持續整合是敏捷開發中核心的工程實踐，它是敏捷產出可以工作的軟體的有力保障。

52. 當開始研發新產品或者已有產品的新模組時，由於各方面的原因，整個團隊沒有能力在Sprint的開始就做出一份非常詳實的計劃，因此，採用“照明彈”策略絕對不失為一個好辦法。

53.對於每一個STORY，都要儘可能瞭解他的需求                                   

54.在開發過程中，為了提高交流的效率，要儘量避免把精力浪費在不必要的文件上，取而代之的是要提倡團隊之間面對面的直接交流。

55.在實際工作中，Scrum團隊自我管理，在任務分配時每個人都可以按照自己的興趣來選擇任務。

56．團隊成員的技能培訓在做Sprint計劃的時候就應該考慮在內的。

57. 經理應該充分信任開發團隊，不要把每日的Scrum會議當成每日彙報。

58.在Scrum工具的使用上，一定要確保每天都進行準確的更新，只有這樣才能讓團隊的其他成員及專案經理掌握及時、準確的專案進度資訊。

59.通過Burndown Chart，Scrum將給專案帶來更多的可視性。

60. 在每日Scrum會議上不要過多地討論技術難題的細節，如果有團隊成員遇到無法解決的困難時，Scrum Master應該將其記錄下來，會後再調配資源去解決。

61．Scrum如何解決開發與測試工作同步的問題？

62.每個Sprint結束後，最基本的目標是應該得到一個可以工作的產品，Sprint結束時的Sprint評審會議和Sprint回顧會議都至關重要。

63.在Sprint計劃會議中，ScrumMaster應該主動約Product Owner一起制定和討論這個Sprint的工作。

64．在Sprint計劃會議中，ScrumMaster不應該拋棄團隊成員，團隊成員必須全體參與到計劃的討論中去，並且及時對不明白的地方以及使用者需求等進行提問。

65．在Sprint計劃會議中應該如何制定具體的計劃？

66．在Sprint進行過程中，遇到臨時員工變化，比如請假，該怎麼辦？

67. Scrum不鼓勵加班。

68．對於不好演示的功能，可以用執行測試用例等其他方式在Sprint評審會議中進行演示。

69.建立一個敏捷的工作環境，讓每個Scrum團隊成員都坐在一起工作。

70. 敏捷開發的思想之一也包括避免不必要的浪費，在做Sprint計劃時應該放棄實現一些不必要的功能。

71.嘗試結對程式設計。

72. 在敏捷開發中，應該儘可能地尋找有效的工具提高效率。“工欲善其事，必先利其器。”

73．採用Scrum回顧模板“團隊聽診工具”進行Scrum回顧。

74．利用演示工具有效地傳遞Sprint需求。

75．採用Scrum後的新部門組織結構。

76．如果測試人員不習慣自身的角色轉換，應該鼓勵他們轉變思維方式，主動參與開發過程。

77. 測試新功能前要對老功能做迴歸測試，以保證新功能不會破壞老功能。

78. 關於自動化測試，應該盡力而為，但不能急於求成。

79．一個產品的成功與否需要市場來檢驗。在產品正式釋出之前，如果能有客戶儘早地參與到開發過程中進來，無疑會增加成功的砝碼。

80. 如何管理素質較低的團隊？

SCRUM中的工具：

1．  任務板

在一塊白板上按一定規則張貼任務卡片。如下：

2.什麼是ProductBacklog？什麼是Sprint Backlog？

 Product Backlog是根據初步需求分解出來的任務列表，包括功能性的和非功能性的所有功能，有Product Owner為Product Backlog中的任務確定優先級別，當開發團隊開始某個任務的時候，再精確定義和分解這個任務。

Product Backlog是產品所具備的所有功能的總綱，當一個專案剛剛開始的時候，沒人能實現預見到所有的任務和需求，併為之制定一個充分、詳細而又包羅永珍的計劃。可行的方式是，先為之一個專案寫下所有它應該具備的顯著特徵和功能。數量不必多，做好讓團隊的第一個Sprint有活可幹。

     隨著Sprint的進行，生產出可釋出的產品增量，客戶對產品的直觀認識也會隨之加深，他們可以據此建議更改或新增產品Backlog中的任務。

     在Sprint計劃會議上，產品負責人為ProductBacklog中的任務制定優先順序，並向Scrum團隊描述這項任務，Scrum團隊隨後根據團隊的整體情況，確定他們能在這個即將來到的Sprint中要完成哪些功能，並把它們挪到Srpint Backlog中去。

3. Scrum中的角色。分別是產品負責人（Product owner）、Scurm Master和Scrum團隊。

產品負責人（Product owner）

產品負責人需要確定產品的功能和完成時間，並對產品的收益負責，要根據市場的需求確定產品功能的優先順序。在每個Sprint開始之前，產品負責人可以修改功能需求和優先順序。而且產品負責人有權決定是否接受各個Sprint的工作成果。

產品負責人的佳色通常由市場部的人員或開發部門內部主要使用該產品的人員來擔任，主要工作是市場需求確定產品功能，將其列入Product Backlog中，併為這些工作確定優先順序。

Scrum Master

Scrum Master的職責是：負責監督整改Scrum專案程序，調整專案計劃；確保開發團隊成員的能力能夠勝任產品的開發；促進團隊中不同角色的成員間充分交流和溝通，並負責為專案的進行掃除障礙；保證開發團隊不受外力的干擾和阻撓；掌握產品開發進度，參與每日的Scrum會議、Sprint計劃會議和Sprint評審會議

Scrum Master通常由傳統開發中的專案組長來擔當。

Scrum團隊

     一般由5-10個能全職工作的成員組成較為理想。

     團隊成員橫跨各個職能，通常包含開發、測試、文件設計人員等。

     User Story

     Sprint Backlog裡的專案我們通常用User Story 來描述。User Story是從使用者的角度對系統中的某個功能模組所做的簡短描述。一個User Story描述了專案中的一個小功能，以及這個功能完成之後將會產生什麼效果，或者說能為客戶創造什麼價值。

    User Story要有stakeholder來編寫。通常把User Story寫在一張小卡片上，同時在卡片上標明它的優先順序和預計完成時間，以便開發人員根據任務的優先順序來制定Sprint Backlog。而且，Stakeholder可以隨時更改一個Story的優先順序，那麼此時開發人員就應該相應地調整Story的開發次序

一個User Story的大小和複雜度應該異能在一個Sprint中開發完畢為宜。如果User Story太大，可能會導致對它的開發橫跨幾個Sprint，這種情況是需要避免的，此時就應該將這個User Story 分解。

User Story有一個通用的公式格式： 作為《某個角色》，我可以《做什麼》，以完成《什麼目的》，例如：作為一個病人，我可以預約一個醫生，讓他給我看病。

為了能及時、高效地完成每個Story，Scrum團隊會把每個Story分解成若干個Task，每個Task都是可以再明確的時間內完成的，而且時間是以小時為計量單位的。每個Task最好不要超過8小時，就是要保證一個工作日內完成。

4.Sprint計劃會議

  在每個Sprint開始之前，需要召開Sprint計劃會議，會議時間一般為4-8小時。參加人員有產品負責人、ScrumMaster、Scrum團隊和其他感興趣的人，比如管理層和客戶代表。Product Owener從Prduct Backlog中挑選高優先順序的任務，並與Scrum團隊一起這個Sprint中需要完成多少功能。Scrum團隊將這些任務分解成小的功能模組。Scrum團隊成員相信討論如何能按需求完成這些功能模組，並估計完成每個功能模組所需的大概時間。

5.每日Sprint會議

  即團隊的每日例會，由ScrumMaster主持。條件允許的情況下，每天都應該在同樣的時間和地點，組織所有成員站立舉行，時間控制在15分鐘左右。只有團隊成員可以在每日Scrum會議上發言，其他人員如果對專案進度有興趣的話也可以參加，但是隻能旁聽，不能發言。

會議上所有成員輪流回答一下三個問題：

A． 昨天我完成了什麼工作？

B． 今天我打算做什麼？

C． 我遇到了什麼障礙？

6.Sprint評審會議

Sprint評審會議在Sprint結束時召開，由開發團隊展示這個Sprint中完成的功能，長度為兩個小時左右，不需要PPT，一般是已經完成功能的DEMO，而且客戶、利益相關者、管理層、Product Owner以及其他開發人員都可以參加。

7.Sprint回顧會議

  Sprint回顧會議由ProductOwner，Scrum團隊和Scrum Master參加，會議中需要討論有哪些好的建議或方法應該被採納，在Sprint 中有什麼做法不可取，有哪些做法效果和好，應該繼續下去。宗旨是Scrum團隊如何在下一個Sprint中做的更好。

   Scrum Master首先個大家看SprintBacklog，總結這個Sprint。大家討論這個Sprint中發生的一些比較重要的事件，與會人員輪流發言，每個人都有機會發表自己的意見。還要對比Sprint Backlog中各個Story的估計值與它們的時間發成時間，如果差距很大，就應該好好分析出現這種情況的原因。

8.Burndown Chart

Burn Down Chart是常用的衡量團隊進度的視覺化工具。敏捷開發可以給專案提供更多的可視性。

Burn Down Chart有Sprint BurndownChart和Release Burndown Chart之分。Sprint Burndown Chart的橫軸表示整個Sprint的總時間，縱軸表示Sprint中所有任務。其單位可以是小時、人天等。Release Burndown Chart橫軸表示這個專案的所有sprint，縱軸是指在各個Sprint開始前尚未完成的工作，她的單位可以是Story的數量，人天等。

9.計劃撲克（Planning Porker）

  所謂計劃撲克是一種標有各種數字的撲克牌。參加遊戲的人每人各拿一疊撲克牌，牌上有不同的數字。

客戶或者產品負責人為大家挑選1個Story（Backlog），並簡單解釋其功能，以供大家討論。

每個遊戲參加者按照自己的理解來估計完成這個Story所需的時間，從自己手中的牌裡選一張合適數字的牌，併發給大家看。遊戲參加者各自解釋選擇這個數字的原因，尤其是數字最大和最小的人。

根據每個遊戲參加者的解釋，重新估計時間並在此出牌，直到大家的估計值比較平均為止。

這個遊戲中需要注意的是：首先，這不像普通的撲克遊戲，不是輪流出牌，而是大家考慮好了後同時出牌，這樣就可以避免後出牌的人唄先出牌的人干擾；其次，要告訴團隊成員，他們需要估計所有的Story，而不僅僅是他們要做到那些部分，不如測試人員不能只估計測試工作所需要的時間。

10．Sprint

Sprint代表Scrum的一次迭代，週期通常是30天，期間不能給Team增加額外的需求，以確保迭代結束時能夠獲得預期的結果

11. Stakeholders

利益相關者，是專案成敗對他們影響不大的一類人，他們參與提出產品的需求並積極提出反饋意見。