以人爲本，以價值爲導向，注意要靈活變化和調整
- 選擇大於努力，敏捷開發是一種選擇
- 敏捷開發可以及時發現錯誤，及時調整方向
- 敏捷開發是面向人的而非面向過程的
- 敏捷開發是“主動適應的”而不是“預先設定的”
- 敏捷開發的核心是人，找到合適的人是所有開發環節中最重要的
- 照明燈，當你不知道該從哪下手時，先確保方向，然後找那些已經明確知道要做的東西下手。
- 好的開始等於成功了一半，所以開始做之前，如果有不明確的地方，一定要溝通清楚，不要想當然（這個問題我遇到不少，在新手身上特別容易犯）。
- 雖然敏捷開發強調自我管理，但要注意讓領導理解和支持，你懂的。
- 發現問題不是壞事，越早發現越好，因爲越早發現，越早解決，問題帶來的損失就越小。
- 不應該有理由和藉口拋棄團隊
- 不要隱瞞團隊的技術實力，否則很難做切合實際的計劃和評估
- 善於尋求幫助是個好習慣，不僅僅是針對敏捷開發項目
- 團隊裏沒有絕對的權威，每個人都有可取之處，要避免少數服從多數
- scurm master要有敏銳的嗅覺，及時發現團隊成員遇到的問題
- 敏捷強調面對面的溝通，創造一個有利於敏捷溝通的工作環境至關重要
- 避免不必要的浪費是精益軟件開發的思想，也同時是敏捷開發所提倡的
- sprint goal（可以制定成順口的口號）是個鼓舞士氣的好工具
- 敏捷本質上也是一種先進的管理思想
- 將投資回報最大化，快速反應市場的風雲變化，敏捷開發是應對危機的最好工具
- scrum的可視性能夠保證及時發現問題，不要隱瞞風險
- 注意保留緩衝時間，緩衝時間在兩個sprint之間起到了承上啓下的作用
- 無論以什麼方式，儘早讓客戶參與到sprint中來，無疑可以增加成功的砝碼
- 持續集成是敏捷開發中核心的工程實踐，它是敏捷產出“可以工作的軟件(working software)”的有利保障
- scrum 不鼓勵加班
4個重於
- 人和溝通重於過程和工具
- 可以工作的軟件重於面面俱到的文檔，因爲最根本的文檔就是源碼
- 客戶寫作重於合同談判
- 隨時響應變化重於循規蹈矩
scrum實施過程中的3個會議
- scurm計劃會議：所有成員一起討論下個sprint的需求，並排好優先級。如果有需求不清晰或過於龐大，相關開發人員要對需求進行拆解。每個需求的時間以小時爲單位，且最好不要超過8小時（一天）。
- 每日scrum站會：各個成員相互同步項目進度，讓每個成員對項目進度都有清晰認識。主要內容是“昨天做了什麼，有沒有遇到什麼問題，今天準備做什麼”，如果有問題，站會後相關人員要商討解決方案。scrum站會不要超過10分鐘
- scurm總結會：總結上一個sprint遇到的問題，商量解決這些問題的方法，避免這些發生過的問題再次發生。scrum總結會的宗旨是：scurm團隊如何在下一個sprint做得更好。
scurm中有3種角色,他們是產品負責人（product owner）, scurm master 和scurm團隊，他們各自的職責如下：
- 產品負責人：客戶需求的代言人，確定產品的功能和完成時間，並對產品的受益負責，要根據市場需求確定產品功能的優先級。在每個sprint開始之前，product owner可以修改功能和優先級。而且，product owner有權接受或否決各個sprint的工作成果。在實際工作中，一般是產品經理來擔當。
- scrum master：爲scurm團隊服務，監督整個scrum項目進程，調整項目計劃，確保開發團隊成員的能力能夠勝任產品的開發。促進團隊中不同角色的成員間充分交流和溝通，並負責爲項目的進行掃除障礙，保證開發團隊不受外力的干擾和阻擾，掌握產品開發進度。在實際工作中，一般以開發組的leader來擔當。
- scurm團隊：一般由5~10個全職工作的成員組成。團隊成員橫跨各個職能，通常包含前後端開發，測試，運維等等
scurm管理工具：scrum works，IBM RationalTeam Concert，XPlanner等等，Excel也是一種。
敏捷開發的理念
敏捷開發的理念是信任開發團隊，信任每一個人。因爲“指揮-執行”模式是極其低效且會導致結果質量低下。敏捷開發提倡充分調動參與項目人員的主動積極性，讓他們自我組織，自我管理，由團隊自身來掌握項目進度，比老闆整天催促反而更有效率。敏捷開發也需要管理，但這些管理是非命令式的，而是戰略指導和服務性質的。
敏捷開發不是可以解決所有問題的銀彈。在實際項目中，不要一成不變地遵循這些條條框框，遇到困難時應該靈活地調整策略，這樣才真正地達到了敏捷的目的。