咱們是這樣轉向敏捷開發的

「瀑布式開發是一種老舊的，正在過期的計算機軟件開發方法。最開始的軟件行業廣泛採用這種方法，可是這種方法套用自傳統工業生產，不適應計算機軟件開發的具體狀況。」來自百度百科的一段話，確實它用在軟件開發會出現不少問題。
使用瀑布式開發經歷過二、3個產品的研發，問題頗有共同性，《30天軟件開發：告別瀑布擁抱敏捷》幫我完美總結：

• 版本發佈所需時間愈來愈長。
• 沒法按時發佈。
• 在版本發佈的最後階段，軟件達到穩定狀態須要的時間愈來愈長。
• 制訂計劃的時間太長，並且計劃得不許確。
• 在版本發佈中期很難作更改。
• 質量持續惡化。
• 「死亡行軍」損傷士氣。

正由於這些問題，因此渴望開發流程的改變。偶然（或許是必然的結果，只是時間點的問題）的機會，讓個人團隊轉向敏捷開發。

敏捷開發是什麼？

本節內容基本上都是摘自《30天軟件開發：告別瀑布擁抱敏捷》。
敏捷開發以用戶的需求進化爲核心，擁抱變化，採用快速迭代、按部就班的方法進行軟件開發。衡量整個過程的三個指標：

1. 生產效益：指團隊開發的效率。
2. 質量：指產品增量的質量。
3. 價值：指開發出來的產品增量的市場價值。

流程如圖：

1. 從「願景」開始，只有時時刻刻銘記迭代的初心纔不會偏離航向。
2. 由產品經理梳理需求，造成「產品待辦列表」。
3. 在「Sprint計劃會議」上，產品及開發團隊一塊兒討論出最優先的需求造成「Sprint待辦列表」進入迭代。
4. 在按期的迭代週期中，天天同一時間同一地點的進行「每日站會」，交流上一天作什麼，下一天作什麼，遇到什麼問題，其目的是讓團隊知道總體進度。期間禁止超期（包括插入其餘事務）或修改驗收標準。
5. 最終造成一份可發佈的產品增量。
6. 客戶、產品經理、開發人員等涉及人員進行「Spring評審會議」，主要是開發人員進行Demo演示，產品經理驗收需求是否達標，未達標則產生新的產品待辦項。客戶觀察是否達到本身的要求。
7. 最後，開發團隊本身進行「Sprint回顧會議」，對該迭代出現的問題進行分析及總結，避免下一迭代中出現。

文章最後附上敏捷開發的3個角色、3個工做和5個事件。

咱們怎麼落實？

通常來講，都是團隊按照一個標準流程執行。由於團隊中都是對敏捷開發只知其一;不知其二的，這樣的話，得統一學習，而後一塊兒制定流程，而後在按照流程執行。這樣既耽誤時間又耽誤版本發佈。因此咱們就反過來，讓流程也來個迭代。
要實施敏捷開發，對人的要求挺高，能不能落實很大取決於Scrum Master，落實得順不順利很大取決於開發團隊，落實得好很差很大取決於Scrum Master和開發團隊。

第一階段：人

讓團隊有敏捷開發基礎，這樣反過來執行流程，不少問題就迎刃而解。

自身

做爲團隊的Leader，也就理所固然的落在Scrum Master這個角色上。我得從如下方面提高：

1. 首先，得有一個接納、積極的態度。打內心堅信我能夠帶着這個團隊成功轉型。遇到問題，我有這個能力解決。
2. 其次，提升自我認知、我在團隊的定位及與下屬的關係。我花1個月時間精讀《30天軟件開發：告別瀑布擁抱敏捷》，以它做爲藍本進行入門。我也認識到個人主要精力應該由考慮方案變成幫助團隊實現他們的任務。他們，纔是主力！
3. 最後，我得改變方式。我慢慢讓本身淡出，把機會留給團隊的每個人。我讓他們本身提方案，我參與評估。我審視團隊的每一個人，我把迭代過程當中看到的問題記錄，而後找合適的時間跟他們面對面而且很直接的溝通。

團隊

因爲團隊人員能力良莠不齊，作事方式也都不同。比較有共性的就是養成惰性習慣，因此主要從兩方面提高：

1. 提升執行力，聚焦於任務。遇到問題給他們引導技術方向，梳理方法以提升執行力。死盯任務，卡死2周的迭代時間，曾經好幾回加班到深夜二、3點，目標就是想代表一個態度——時間是神聖的，不可侵犯，來打消惰性及退縮。
2. 提升「自組織」。執行力提升以後，慢慢培養他們的積極性，把主觀能動性激發出來，讓他們本身思考。

第二階段：流程

一開始，咱們的流程只有：需求評審->迭代->發佈，加上拖了好久的總結。恰好咱們團隊接到公司一個內部工具的新研發，咱們在這個工具的開發上嘗試。當進度和質量可控時，咱們調整流程讓它往標準的敏捷開發靠近。
咱們把總結放在迭代時間內，不在隔好久。當咱們信心滿滿，咱們落實在舊的產品研發上時，雖然團隊仍是這個團隊，可是由於團隊接手舊的產品也才二、3個月，因此需求評估有誤，致使延期一週。從結果上看咱們失敗了，可是這個延期咱們深刻的分析，總結出不少改進的點，其中就包括需求評估不明確。因此咱們在流程上，把需求評審拆成產品經理講需求，而後開發團隊理解需求、理需求涉及代碼的系統流程、最後需求反講產品經理確認。在接下來的迭代中，果真按時發佈。以後，咱們又陸陸續續加入「每日站會」、「Sprint目標」、「Sprint評審會議」，還制定了完成核心編碼、開始測試、完成編碼的參考時間點。也規範了最終除了產品增量還有「測試用例報告」、「核心功能測試報告」、「Sprint回顧報告」、「項目日誌」和「版本迭代檢查表」。在加入每一項以前，我都會跟團隊分享它是什麼，有什麼做用。最終制定了咱們的流程規範v0.1：

固然，在過程當中會遇到不少問題，好比任務作不完，咱們預留了幾個需求做爲彈性需求。再好比開發團隊以爲需求不夠明確，咱們就跟產品經理溝通等等。方法總比問題多，擁抱問題，不斷迭代優化。

第三階段：規範化

這個階段處於計劃階段，還未執行。打算嚴格按照流程規範來執行，而後對每個過程進行精細化管理，造成規範。這樣後續能夠經過一些源數據進行分析問題。

咱們遵循什麼原則

原則及是一種態度！以前有一個版本在週五時面臨難產，一位開發人員理不清一段邏輯的思路，而下一週還沒安排事情。此時他很大程度上以爲下週作也沒事。可是我堅持，我幫他寫了邏輯（不會出現下次），那天咱們測試到凌晨三、4點搞定。以後跟他私底下聊天，他說確實是以爲下週作也沒事，可是通過那晚，一直壓着的壓力一會兒釋放，而後版本又能夠發佈，感受挺好。因此，原則仍是要有。
原則1、時間和質量不可侵犯
保證質量的前提下，2週一個版本的迭代時間不會變，能夠調整需求。
原則2、堅持原則一
時時刻刻提醒本身和團隊、堅持原則一。

總結

敏捷開發有人說好，有人說很差，對於咱們來講，沒有好與很差，只有適合不適合。能讓咱們團隊成長，持續產出，就是適合的。咱們會堅持，也堅信咱們能夠作到v1.0。

---

附

敏捷開發的3個角色

產品負責人：負責最大化產品以及開發團隊工做的價值。決定每一個迭代要開發的功能，並在每一個Sprint結束時評審軟件增量是否符合要求。

• 清晰地描述產品待辦列表項
• 對產品待辦列表項進行排序，最好地實現目標和使命。
• 優化開發團隊所執行工做的價值。
• 確保產品待辦列表對全部人可見、透明、清晰，而且顯示Scum團隊的下一步工做。
• 確保開發團隊對產品待辦列表項有足夠的理解。

開發團隊：負責在每一個Sprint結束時交付潛在可發佈而且「完成」的產品增量。

• 他們是自組織的，沒有人（即便是Srcum Master都不能夠）告訴開發團隊如何把產品待辦事項列表變成潛在可發佈的功能增量。
• 開發團隊是跨職能的。團隊做爲一個總體，擁有開發產品增量所須要的所有技能。
• Scrum不承認開發團隊成員的頭銜，不管承擔哪一種工做他們都叫作開發人員。此規則無例外。
• Scrum不承認開發團隊中的所謂「子團隊」，不管是測試仍是業務分析的成員都不能劃分爲「子團隊」。此規則無例外。
• 開發團隊中的每一個成員能夠有特長和專一領域，可是責任屬於整個開發團隊。

Scrum Master：負責保證項目按照Scrum的方式進行。要確保Scrum團隊遵循Scrum的理論、實踐和規則。

（1）服務於產品負責人

• 找到有效管理產品待辦列表的技巧
• 幫助 Scrum團隊理解「清晰精煉的產品待辦列表項」的重要性
• 在經驗主義的環境中理解長期的產品規劃
• 確保產品負責人懂得如何安排產品待辦列表項來最大化價值
• 理解並實踐敏捷
• 按要求或須要引導 Scrum事件

（2）服務於開發團隊

• 在自組織和跨職能方面給予團隊指導
• 協助開發團隊開發高價值的產品
• 移除開發團隊工做中的障礙
• 按要求或須要引導 Scrum事件
• 在 Scrum還未被徹底採納和理解的組織環境中指導開發團隊

（3）服務於組織

• 帶領並指導組織採用 Scrum。
• 在組織範圍內計劃 Scrum的實施。
• 幫助員工及相關干係人理解並實施 Scrum和經驗型產品開發。
• 發起可以提高 Scrum團隊生產效率的改變。
• 與其餘 Scrum Master一塊兒工做，增長組織中 Scrum實施的有效性。

敏捷開發的3個工做

產品待辦列表

• 產品待辦列表是一個有序的列表，其中包含一切產品可能須要的東西，也是產品需求變更的惟一來源。產品負責人負責管理產品待辦列表的內容、可用性和排序。
• 演進。待辦列表是動態的，須要持續更新以反映出產品須要什麼來保持其合理、有競爭力以及有用。只要產品存在，產品待辦列表就存在。
• 產品待辦列表列出了將來發布的產品在特性、功能、需求、改進和修復上所要進行的全部改變。產品待辦列表項包含描述、次序、估算和價值。
• 隨着產品的使用，價值的獲取以及市場反饋的得到，產品待辦列表變成了更大、更詳盡的列表。由於需求永遠不會中止改變，因此產品待辦列表是個不斷更新的工件。業務需求、市場形勢和技術的變化都會引發產品待辦列表的改變。
• 「產品待辦列表細化」指的是爲列表項補充細節，估算和排序。這是一個持續不斷的過程，產品負責人和開發團隊協做討論產品待辦列表項的細節，並對列表項進行評審和修改。什麼時候如何進行細化的工做由 Scrum團隊決定。細化的工做一般佔用開發團隊不超過 10%的時間。然而，產品負責人能夠根據本身的判斷隨時更新產品待辦列表。
• 排序越高的產品待辦列表項一般比排序低的更清晰、更具體。根據更清晰的內容和更詳盡的信息就能作出更準確的估算；排序越低，細節信息越少。
• 開發團隊在接下來的 Sprint中將要進行開發的產品待辦列表項是細化過的，所以，任一列表項都可以在 Sprint的時限內「完成」。咱們把這些可以在 Sprint中「完成」的列表項稱爲「準備就緒的」（ Ready），它們將做爲 Sprint計劃會議中的待選列表項。
• 監控實現目標的進度，在任什麼時候間，達成目標的剩餘工做量是能夠累加的。產品負責人至少要在每次 Sprint評審會議的時候追蹤剩餘工做總量。產品負責人比較這個數量與以前 Sprint評審時的剩餘工做量，來評估在但願的時間點達成目標的進度。這個信息對全部的相關干係人都透明。

Sprint待辦列表

• 一組爲當前 Sprint選出的產品待辦列表項，外加交付產品增量和實現 Sprint目標的計劃。開發團隊在 Sprint待辦事項列表中預測哪些功能要包含在下一個增量中，以及交付這些功能到「完成」的增量中所需的工做。
• 當新工做出現時，開發團隊須要將其追加到 Sprint待辦列表中去。隨着任務的進行或者完成，團隊須要估算並更新剩餘的工做量。若是計劃中某個部分失去開發的意義，就能夠將其刪除。在 Sprint期間只有開發團隊能夠修改 Sprint待辦列表。 Sprint待辦列表是高度可見的，實時反映了團隊計劃在當前 Sprint內完成的工做，該列表由開發團隊全權負責。
• 監控 Sprint進度，在Sprint中的任意時間點均可以計算 Sprint待辦列表中全部剩餘工做的總和。開發團隊至少會在每日會站時跟蹤剩餘的工做量，預測達成 Sprint目標的可能性。團隊經過在 Sprint中不斷跟蹤剩餘的工做量來管理本身的進度。

產品增量

• 增量是一個 Sprint完成的全部產品待辦列表項，以及以前全部 Sprint所產生的增量價值的總和。
• 在 Sprint的結尾，新的增量必須是「完成」的。這意味着它必須可用而且達到了 Scrum團隊「完成」的定義的標準。
• 不管產品負責人是否決定真正發佈它，增量必須可用。

敏捷開發的5個事件

Spring計劃會議

目的是要爲這個Sprint的工做作計劃，這份計劃由整個Scum團隊共同肯定。爲期兩週的Sprint的計劃會議應該不能超過4個小時。Scrum Master確保會議順利舉行，而且每一個參與者都明白會議的目的，同時還要教導你們遵照時間盒的規則。
（1）接下來的 Sprint交付的增量中要包含什麼內容？

• 開發團隊預測這個 Sprint中要開發的功能。
• 產品負責人講解 Sprint的目標以及達成該目標所須要完成的產品待辦列表項。
• 整個 Scrum團隊爲了更好地瞭解 Sprint的工做進行討論。
• Sprint會議的輸入是：產品待辦列表、最新的產品增量、開發團隊在這個 Sprint中預計可接受的工做量和以往的表現。開發團隊本身決定選擇的待辦列表項的數量。只有開發團隊自己能夠評估接下來的 Sprint能夠完成什麼工做。
• 在開發團隊預測完這個 Sprint中可交付的產品待辦列表項後， Scrum團隊會制訂一個 Sprint目標。
• 經過實現 Sprint產品待辦列表能夠達成 Sprint目標。

（2）要如何完成交付增量所需的工做？

• 設定了 Sprint目標並挑選出這個 Sprint要完成的產品待辦列表項以後，開發團隊將決定如何在 Sprint中把這些功能構建成「完成」的產品增量。
• 這個 Sprint中所選出的產品待辦列表項以及它們的交付計劃統稱爲 Sprint待辦列表。
• 開發團隊一般先由系統設計開始，設計把產品待辦列表轉換成可工做的產品增量所須要的工做。工做的大小或預估的工做量可能會不一樣。
• 在 Sprint計劃會議中，開發團隊已經挑選了足夠的工做量，而且預計他們在即將到來的 Sprint中可以完成。
• 在會議結束前，開發團隊所計劃的 Sprint最初幾天的工做被分解爲工做量等於或少於一天的任務。開發團隊自組織地領取 Sprint待辦列表中的工做，領取工做在 Sprint計劃會議和 Sprint期間按實際狀況進行。
• 產品負責人對選定的產品待辦列表項做出澄清，並協助團隊權衡取捨。若是團隊認爲工做量過大或過小，就能夠和產品負責人從新協商選擇產品待辦列表項。
• 開發團隊也能夠邀請其餘人員參加會議，以得到技術或者領域知識方面的建議。
• Sprint計劃會議結束時，開發團隊應該可以向產品負責人和 Scrum Master解釋他們將如何以自組織團隊的形式完成 Sprint目標並開發指望的產品增量。

還須要在會上制定Sprint目標，Sprint目標能夠是爲惟一功能服務的產品待辦列表項的集合，也能夠是可以促使開發團隊向着同一目標而不是孤立的其餘工做。

每日站會

一個以15分鐘爲限的事件，期間開發團隊進行活動信息交流和計劃接下來24小時的工做。天天在同一時間，同一地點舉行。​Scrum Master確保開發團隊每日站會如期舉行，開發團隊本身則負責召開會議。 Scrum Master指導團隊把會議控制在 15分鐘內。Scrum Master強制執行每日站會的規則，即只有開發團隊的成員才能參加每日站會。
會議上，每一個開發團隊成員都須要說明：

• 昨天我爲開發團隊達成 Sprint目標作了什麼？
• 今天我準備如何幫助團隊達成 Sprint目標？
• 有什麼事情阻礙了我幫助團隊達成 Sprint目標？

Sprint

週期大於或等於1周，小於或者等於一個月，其產出是「完成的」、可用的、潛在可發佈的產品增量。Sprint的長度在整個開發過程當中保持一致。Sprint由Sprint計劃會議、每日Scrum站會、開發工做、Sprint評審會議和Sprint回顧會議構成。

• 不能作出有害於實現 Sprint目標實現的改變。
• 不能下降產品質量。
• 隨着對信息掌握的增長，產品負責人和開發團隊能夠澄清或者從新商討開發範圍。

Sprint評審會議

用意在於檢視增量，若是有須要的話還會調整產品待辦列表。非正式會議，爲期兩週的Sprint的計劃會議應該不能超過2個小時。Scrum Master確保會議順利舉行，而且每一個參與者都明白會議的目的，同時還要教導你們遵照時間盒的規則。
Sprint評審會議的目的：

• 在 Sprint評審會議中， Scrum團隊和相關干係人討論 Sprint中完成的工做。
• 根據完成狀況和 Sprint期間產品待辦列表的變化，與參會人員討論接下來可能要作的事情來優化價值。
• 演示增量的目的是爲了獲取反饋並促進合做。

Sprint評審會議包含如下內容：

• 產品負責人邀請 Scrum團隊以及主要相關干係人蔘加會議。
• 產品負責人說明哪些工做「完成」了，哪些工做沒有「完成」。
• 開發團隊討論在 Sprint中哪些工做進展順利，遇到了什麼問題，問題是如何解決的。
• 開發團隊演示完成的工做並解答關於所交付增量的問題。
• 產品負責人描述當前產品待辦列表的完成狀況，並根據進度推測可能的完成日期（若是有須要的話）。
• 參會的全部人就下一步的工做進行探討，這樣， Sprint評審會議就能爲接下來的 Sprint計劃會議提供有價值的信息。
• 評審市場或者潛在的產品使用方式如何形成接下來要作的最有價值的東西的改變。
• 爲下個產品版本的發佈評審時間表、預算、潛在功能和市場。

Sprint評審會議的結果：一份修訂的產品待辦列表

• 可能進入下個 Sprint的產品待辦列表項。
• 有可能爲了迎接新機遇而對產品待辦列表進行全局調整。

Sprint回顧會議

Srcum團隊檢視自身併爲在下個Sprint中制訂自我改進的執行計劃。Sprint回顧會議發生在 Sprint評審會議結束以後，下個 Sprint的計劃會議以前。對於長度爲一個月的 Sprint，會議限時爲 3小時。Scrum Master要確保會議順利舉行，而且每一個參與者都明白會議的目的，同時還要教導你們遵照時間盒的規則。 Scrum Master做爲 Scrum流程的監督者，也須要做爲團隊的一員參加該會議。
Sprint回顧會議的目的是

• 對前一個 Sprint週期中的人、關係、過程和工具進行檢視。
• 找出作得好的和潛在須要改進的主要方面，並進行排序。
• 制訂改進 Scrum團隊工做方式的計劃。
• Scrum Master鼓勵團隊在 Scrum的流程框架內改進開發流程和實踐，使得他們能在下個 Sprint中更高效，更愉快。
• 在每一個 Sprint回顧會議中， Scrum團隊經過適當調整「完成」的定義的方式來計劃提升產品質量。
• 在 Sprint回顧會議結束時， Scrum團隊應該明確接下來的 Sprint中須要實施的改進。
• 在下一個 Sprint中實施這些改進是基於 Scrum團隊對本身的檢視而作出的調整。
• 雖然改進能夠在任什麼時候間執行， Sprint回顧會議提供了一個專一於檢視和調整的正式機會。

取消Sprint

在 Sprint時間盒結束以前取消。取消Sprint不是必要的事件，但若是儘管評估，能夠對一個Sprint進行停止。只有產品負責人才有取消Sprint的權力，但他作這樣的決定也多是受到相關干係人、開發團隊或是Scrum Master的影響。

• 若是某個 Sprint的目標過期了（失去了價值和意義），那麼也許就須要取消該 Sprint。
• 當取消某個 Sprint時，任何作完和「完成」的產品待辦列表項都須要評審。假如其中有些是潛在可交付的，產品負責人就會採用它。全部未完成的列表項目要從新評估，並放回到產品待辦列表中。