<a></a>
<b>閱讀目錄</b>
<a href="http://www.cnblogs.com/OceanEyes/p/Scrum-Solution.html#_label0">什麼是靈活開發</a>
<a href="http://www.cnblogs.com/OceanEyes/p/Scrum-Solution.html#_label1">為什麼說是以人為核心</a>
<a href="http://www.cnblogs.com/OceanEyes/p/Scrum-Solution.html#_label2">什麼是Scrum</a>
<a href="http://www.cnblogs.com/OceanEyes/p/Scrum-Solution.html#_label3">什麼是Sprint</a>
<a href="http://www.cnblogs.com/OceanEyes/p/Scrum-Solution.html#_label4">Scrum開發流程中的三大角色</a>
<a href="http://www.cnblogs.com/OceanEyes/p/Scrum-Solution.html#_label5">使用者故事描述</a>
<a href="http://www.cnblogs.com/OceanEyes/p/Scrum-Solution.html#_label6">如何進行Scrum開發</a>
靈活開發(Agile Development)是一種以人為核心、疊代、循序漸進的開發方法。
怎麼了解呢？首先，我們要了解它不是一門技術，它是一種開發方法，也就是一種軟體開發的流程，它會指導我們用規定的環節去一步一步完成項目的開發，而這種開發方式的主要驅動核心是人，它采用的是疊代式開發。
我們大部分人都學過瀑布開發模型，它是以文檔為驅動的，為什麼呢？因為在瀑布的整個開發過程中，要寫大量的文檔，把需求文檔寫出來後，開發員都是根據文檔進行開發的，一切以文檔為依據，開發完成後将進行測試，評審，最終部署到正式環境。瀑布流模式每一步往往依賴前一環節的結果，一旦某個環節擱置了，有可能會影響整個軟體開發進度。瀑布流模型如下所示：
而靈活開發它隻寫有必要的文檔，或盡量少寫文檔，靈活開發注重的是人與人之間，面對面的交流，是以它強調以人為核心。同時，靈活開發以沖刺（Sprint）的形式在最短的時間裡完成一次計劃的疊代，包括計劃，實施，測試，評審，
Scrum是一種疊代式增量軟體開發過程，通常用于靈活軟體開發。在這個架構中，整個開發過程由若幹個短的疊代周期組成，一個短的疊代周期稱為一個Sprint，每個Sprint的建議長度是2到4周(網際網路産品研發可以使用1周的Sprint)。在Scrum中，使用産品Backlog來管理産品的需求，産品Backlog是一個按照商業價值排序的需求清單，清單條目的展現形式通常為使用者故事。Scrum團隊總是先開發對客戶具有較高價值的需求。在Sprint中，Scrum團隊從産品Backlog中挑選最高優先級的需求進行開發。挑選的需求在Sprint計劃會議上經過讨論、分析和估算得到相應的任務清單，我們稱它為Sprint Backlog。在每個疊代結束時，Scrum團隊将遞交潛在可傳遞的産品增量。 Scrum起源于軟體開發項目，但它适用于任何複雜的或是創新性的項目，Scrum的流程圖如下所示：
正如上述那樣，Scrum是一種疊代和增量式的産品開發方法。Scrum通過Sprint來實作疊代，Sprint是短距離賽跑的意思，這裡面指的是一次疊代。一個Sprint是指一個1周－4周的疊代，它是一個時間盒。Sprint的長度一旦确定，保持不變。Sprint的産出是“完成”的、可用 的、潛在可釋出的産品增量。Sprint 在整個開發過程中的周期一緻。新的 Sprint 在上一 個 Sprint 完成之後立即開始。 Sprint 包含并由 Sprint 計劃會議、每日站會、開發工作、Sprint 評審會議和 Sprint 回顧會議構成。
Scrum團隊中包括三個角色，他們分别是産品負責人（Product Owner）、Scrum Master和開發團隊。
産品負責人是管理産品待辦事項清單(Product Backlog)的唯一責任人。産品待辦事項清單的管理包括:
清晰地表達産品代辦事項清單條目(文法：作為..想..以便于)
對産品代辦事項清單中的條目進行排序，最好地實作目标和使命
確定産品代辦事項清單對所有人可見、透明、清晰，并且顯示 Scrum 團隊的下一步工作
確定開發團隊對産品代辦事項清單中的條目達到一定程度的了解
為保證産品負責人的工作取得成功,組織中的所有人員都必須尊重他的決定。産品負 責人所作的決定在産品待辦事項清單的内容和排序中要清晰可見。任何人都不得要求開發 團隊按照另一套需求開展工作,開發團隊也不允許聽從任何其他人的指令。
Scrum Master 負責確定 Scrum 被了解并實施。為了達到這個目的,Scrum Master要確定 Scrum 團隊遵循 Scrum 的理論、實踐和規則。Scrum Master是Scrum團隊中的服務式上司。
Scrum Master 幫助 Scrum 團隊外的人員了解他們如何與 Scrum 團隊互動是有益的。 Scrum Master 通過改變這些互動來最大化 Scrum 團隊所創造的價值。
開發團隊包含了專業人員,負責在每個 Sprint 的結尾傳遞潛在可釋出的“完成”産 品增量。隻有開發團隊的成員才能創造增量。
使用者故事是從使用者的角度來描述使用者渴望得到的功能。一個好的使用者故事包括三個要素：
角色：誰要使用這個功能。
活動：需要完成什麼樣的功能。
商業價值：為什麼需要這個功能，這個功能帶來什麼樣的價值。
使用者故事通常按照如下的格式來表達：
英文：As a , I want to , so that .
中文：作為一個<角色>, 我想要<活動>, 以便于<商業價值>
舉例：作為一個“網站管理者”，我想要“統計每天有多少人通路了我的網站”，以便于“我的贊助商了解我的網站會給他們帶來什麼收益。”
需要注意的是使用者故事不能夠使用技術語言來描述，要使用使用者可以了解的業務語言來描述。
我們首先需要确定一個Product Backlog（按優先順序排列的一個産品需求清單），這個是由Product Owner 負責的
Scrum Team根據Product Backlog清單，做工作量的預估和安排；有了Product Backlog清單，我們需要通過 Sprint Planning Meeting（Sprint計劃會議） 來從中挑選出若幹個User Story作為本次疊代完成的目标，這個目标的時間周期是1~4個星期，然後把這個Story進行細化成Task，形成一個Sprint Backlog
Sprint Backlog是由Scrum Team去完成的，每個成員根據Sprint Backlog再細化成更小的Task（對應于Worktile上稱為檢查項），當團隊成員完成任務時，務必需要在Worktile和靈活白闆上同步更新狀态
在Scrum Team完成計劃會議上選出的Sprint Backlog過程中，需要進行 Daily Scrum Meeting（每日站立會議），每次會議控制在15分鐘左右，每個人都必須發言，并且要向所有成員當面彙報你昨天完成了什麼，并且向所有成員承諾你今天要完成什麼，同時遇到不能解決的問題也可以提出，每個人回答完成後，要走到黑闆前更新自己的 Sprint burn down（Sprint燃盡圖）；
做到每日內建，也就是每天都要有一個可以成功編譯、并且可以示範的版本；
當User Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，這時，我們要進行 Sprint Review Meeting（示範會議），也稱為評審會議，産品負責人和客戶都要參加（最好本公司老闆也參加），每一個Scrum Team的成員都要向他們示範自己完成的軟體産品（這個會議非常重要，一定不能取消）；
最後就是 Sprint Retrospective Meeting（回顧會議），也稱為總結會議，以輪流發言方式進行，每個人都要發言，總結并讨論改進的地方，放入下一輪Sprint的産品需求中
了解了Scrum開發流程之後，我們使用Worktile 和靈活白闆這兩個工具來進行靈活管理，使用Worktile 可以進行任務的配置設定、歸檔，如下所示：
使用靈活白闆來跟蹤任務，如下所示:
值得注意的是，當完成任務時，務必要及時更新狀态，以便于團隊了解整體進度。
本文轉自木宛城主部落格園部落格，原文連結：http://www.cnblogs.com/OceanEyes/p/Scrum-Solution.html，如需轉載請自行聯系原作者