敏捷宣言

敏捷宣言的誕生： 
　　2001年2月11日到13日，17位軟件開發領域的領軍人物彙集在美國猶他州的滑雪勝地雪鳥（Snowbird）雪場。通過兩天的討論，「敏捷」（Agile）這個詞爲全體聚會者所接受，用以歸納一套全新的軟件開發價值觀。這套價值觀，經過一份簡明扼要的《敏捷宣言》，傳遞給世界，宣告了敏捷開發運動的開始。

咱們一直在實踐中探尋更好的軟件開發方法，身體力行的同時也幫助他人。由此咱們創建了以下價值觀：
      個體和互動   高於 流程和工具
　　工做的軟件  高於 詳盡的文檔
　　客戶合做     高於 合同談判
　　響應變化     高於 遵循計劃

也就是說，儘管右項有其價值，咱們更重視左項的價值。

敏捷開發的12條準則: 

準則1：Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 
　　咱們的最高目標是，經過儘早和持續地交付有價值的軟件來知足客戶。 
準則2：Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 
　　歡迎對需求提出變動——即便是在項目開發後期。要善於利用需求變動，幫助客戶得到競爭優點。 
準則3：Deliver working software frequently, from a couple of weeks to a couple of mouths, with a preference for the shorter timescale. 
　　要不斷交付可用的軟件，週期從幾周到幾個月不等，且越短越好。 
準則4：Business people and developers must work together daily throughout the project. 
　　項目過程當中，業務人員與開發人員必須在一塊兒工做。 
準則5：Build projects around motivated individuals. Give them the environment and support they need, and  trust them to get the job done.  
　　要善於激勵項目人員，給他們以所須要的環境和支持，並相信他們可以完成任務。 
準則6：The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 
　　不管是團隊內仍是團隊間，最有效的溝通方法是面對面的交談。 
準則7：Working software is the primary measure of progress. 
　　可用的軟件是衡量進度的主要指標。 
準則8：Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 
　　敏捷過程提倡可持續的開發。項目方、開發人員和用戶應該可以保持恆久穩定的進展速度。 
準則9：Continuous attention to technical excellence and good design enhances agility. 
　　對技術的精益求精以及對設計的不斷完善將提高敏捷性。 
準則10：Simplicity -- the art of maximizing the amount of work not done -- is essential. 
　　要作到簡潔，即盡最大可能減小沒必要要的工做。這是一門藝術。 
準則11：The best architectures, requirements, and designs emerge from self-organizing teams.  
　　最佳的架構、需求和設計出自於自組織的團隊。 
準則12：At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.  
　　團隊要按期檢討如何可以作到更有效，並相應地調整團隊的行爲。

 

在會議上每一個團隊成員回答三個問題（During the meeting, each team member answers three questions）

1. 昨天你完成了那些工做?（What have you done since yesterday?）

2. 今每天你打算作什麼?（What are you planning to do today?）

3. 完成你的目標是否存在障礙?（Do you have any problems that would prevent you from accomplishing your goal?）

會議準時舉行（The meeting starts precisely on time.）

任何人均可以參加,但只有團隊內部人員發言（All are welcome, but normally only the core roles speak.）

會議時長限制爲15分鐘（The meeting is timeboxed to 15 minutes.）

會議時間地點應該固定（The meeting should happen at the same location and same time every day）

 

評審會議（Sprint Review Meeting）
　　評審會議在每一個迭代結束後舉行，在會議上團隊演示這次迭代中完成了那些工做，通常會有相關的DEMO演示。

　　這個會議演示的內容應該是啓動會議上肯定的那些內容

回顧會議（Sprint Retrospective Meeting）
　　衝刺回顧會議通常限時爲3個小時（The sprint retrospective meeting is timeboxed to 3 hours.）

　　僅團隊成員參加，產品經理和ScrumMaster，產品經理選擇性參加（It is attended only by the team, the scrum master and the product owner. The product owner is optional.）。

　　會議上團隊中每一個成員須要回答兩個問題（Start the meeting by having all team members answer two questions）：

　　1. 這次衝刺中那些地方作得好?（What went well during the sprint?）

　　2. 下個迭代中那些地方能夠改進? （What could be improved in the next sprint?）

　　scrum master記錄每一個成員的答案

　　團隊爲這些改進意見評定優先級（

　　scrum master在回顧會議中不容許給出答案，但要鼓勵成員本身找到較好的辦法

　　這些改進工做能夠添加至下個迭代中，做爲一個非功能性工做，回顧會議最不擔憂的就是變化