敏捷開發入門

概念解釋

Scrum是一種兼顧計劃性與靈活性的敏捷開發過程，原詞來自於橄欖球中的「帶球過人」。在橄欖球比賽的每次衝刺前，都將有一個計劃安排的過程，但衝刺開始後則由隊員在原計劃的基礎上隨機應變。 不一樣於瀑布模型將開發過程劃分爲需求、設計、編碼、測試等階段，Scrum將整個開發過程分爲屢次迭代（稱爲Sprint，衝刺），通常爲期2～4周。

圖解敏捷開發

關鍵詞

三個角色，三個工件，四個流程（五個事件），四大支柱，五大價值觀

三個角色

Product Owner

產品負責人負責的事項：

• 清晰地表達產品代辦事項列表條目
• 對產品代辦事項列表中的條目進行排序,最好地實現目標和使命
• 確保開發團隊所執行工做的價值
• 確保產品代辦事項列表對全部人可見、透明、清晰,而且顯示 Scrum 團隊的下一步工做
• 確保開發團隊對產品代辦事項列表中的條目達到必定程度的理解

Scrum Master

Scrum Master 負責確保 Scrum 被理解並實施。爲了達到這個目的,Scrum Master要確保 Scrum 團隊遵循 Scrum 的理論、實踐和規則。Scrum Master是Scrum團隊中的服務式領導。 Scrum Master 幫助 Scrum 團隊外的人員瞭解他們如何與 Scrum 團隊交互是有益的。 Scrum Master 經過改變這些交互來最大化 Scrum 團隊所創造的價值。

Scrum Team

開發團隊包含了專業人員,負責在每一個 Sprint 的結尾交付潛在可發佈的「完成」產 品增量。只有開發團隊的成員才能創造增量。

開發團隊由組織構建並受權,來組織和管理他們的工做。所產生的協同工做能最大化 開發團隊的總體效率和效力。開發團隊有如下幾個特色:

• 他們是自組織的,沒有人(即便是 Scrum Master 都不能夠)告訴開發團隊如何把產品 代辦事項列表變成潛在可發佈的功能。
• 開發團隊是跨職能的,團隊做爲一個總體擁有創造產品增量所須要的所有技能。
• Scrum 不承認開發團隊成員的頭銜,不管承擔哪一種工做他們都是開發者。此規則無一例外。
• 開發團隊中的每一個成員能夠有特長和專一領域,可是責任歸屬於整個開發團隊
• 開發團隊不包含如測試或業務分析等負責特定領域的子團隊。

三個工件

分別指的是產品待開發項，衝刺待開發項（開發角度），可交付軟件（文檔）

四個流程

四個支柱&&五個價值觀

四個支柱

• 迭代開發
• 自組織團隊
• 高優先級的需求驅動
• 增量交付

五個價值觀

• 承諾 – 願意對目標作出承諾
• 專一– 把你的心思和能力都用到你承諾的工做上去
• 開放– Scrum 把項目中的一切開放給每一個人看
• 尊重– 每一個人都有他獨特的背景和經驗
• 勇氣– 有勇氣作出承諾，履行承諾，接受別人的尊重

前置條件

敏捷的團隊

敏捷團隊要求其成員具備如下的一些基本特色。

• 具備多年工做經驗，在本身的負責領域有專業的認知和獨立完成能力
• 有較好的執行力，對本身允諾的事情能完整的完成
• 有較好的溝通反饋能力，對敏捷自己的正確理解，在遇到問題、風險、不肯定性、協做等時能快速的經過溝通完成溝通的目的
• 對其餘技術棧或者專業領域有必定的認知，有較少的認知壁壘，較快達成共識
• 團隊在此以前有至少半年到一年的磨合

比較固定的流程，文檔，需求

• 需求是控制穩定性的根本，對於需求必定是總體可控的，而且是能夠由迭代內進行調整的，而不是定死的
• 流程是指什麼時間什麼人該作什麼事是高效的，明確的
• 文檔是指每一個流程階段具備可交付或者可查閱參考文檔，不是口頭或者我的評定

可靈活調整，容許試錯

• 檢查

檢查是指在天天的站會中檢查每一個人的工做狀態，是否能完成本身的任務，存在什麼問題，完成效果如何。另外就是保證總體在天天的進度，是否有有總體效果，若是沒有完成今天的總體效果，須要檢查是否符合總體迭代。

• 調整

調整是指檢查發現迭代的進度或者外界環境發生變化時，及時調整當前迭代的開發任務，保證迭代最終產物的準確及時性變更。固然，這種變更是不容許太多的，通常狀況下在需求沒有作詳細分析時，不接受；在當前有風險的狀況下，撤銷某些需求；其餘狀況不作描述。

• 試錯

正是因爲檢查以及調整的策略，保證了迭代的靈活性，咱們能夠在敏捷團隊中嘗試一些較革新、新的功能點或者技術點，若是實驗成功則能夠對外拓展；若是不行，能夠快速切換方案。

適用場景

• 不肯定的開發流程，技術方案
• 不成熟的產品
• 產品快速多方面優化
• 產品新特性研發
• 技術重構

問題場景&&錯誤認識

• 一個團隊閉關開發一個項目就是敏捷

正確理解：敏捷不等於閉關，只是可能坐一塊兒效率更高，其倡導的是什麼時候均可以發生溝通，並準備一白板能夠隨時討論方案；敏捷團隊質量以及效率高於通常團隊；敏捷團隊開發的是以迭代爲單位，不是項目；

• 有了任務細分，開發白板，站會就是敏捷

正確理解：任務細分、白板、站會都是其形式，關鍵仍是其將迭代的內容進行細化，可執行化，用高頻的溝通反饋提升開發、溝通、理解的效率。

• 把最好的成員都攢一塊兒了就是敏捷

正確理解：這些成員除了各自的專業水平還須要各自的磨合，溝通水平，對其餘職能的必定的瞭解。

• 開發很快，快速交付的是敏捷

正確理解：開發快、快速交付產物只是敏捷的一個特色，也要深入理解其交付的只是一個迭代的，並非一個完整的產品。

• 只有軟件開發團隊纔有敏捷

正確理解：符合能夠將任務明細，具備一個可執行團隊，一個監督者，均可以嘗試敏捷的管理。

• 敏捷團隊沒有特殊前置條件

正確理解：前面有講到敏捷對團隊，需求，文檔，流程，調整等都有比較完整的規定。

• 敏捷團隊作的事情沒有差異性

正確理解：敏捷完成的任務具備明細化，分階段性，可調整性。因此在開發相關任務時，也具備相似的特色。

• 敏捷團隊會完整完美的交付產物

正確理解：敏捷在迭代結束只交付該階段的可交付產物，極可能不完整不完美，對於可交付也有不一樣的理解。

更多

有興趣能夠持續關注的後續講解，會針對用戶故事、需求管理、跟蹤反饋等多角度分析執行敏捷的要點。

參考文檔

• 《火星人敏捷開發手冊》
• scrum中文官網