PPT下載連結：http://pan.baidu.com/s/1bncprTd

敏捷開發分享講義-修改版

第1頁：個人資訊

就不做自我介紹了，我的基本資訊就在PPT第一頁。7月26日，也就是上週六，我和會成參加了一天的培訓，關於敏捷開發的。參加這次培訓我們倆主動申請的，因為這次培訓適合的聽眾除了中高層領導、專案經理、產品經理之外，還適合有軟體經驗希望往專案管理方向發展的人士。“不想當專案經理或者專案主管的IT屌絲是真屌絲”，不想成為真屌絲，所以參加了培訓。但這次跟大家分享是被婷姐逼的（開個玩笑！嘿嘿！）。雖然時間不長，但是還是有些有價值的理念和工作方法，所以耽誤大家一點時間，今天由我跟大家做其中一部分內容的分享！下週由會成做另一部分的分享。

第2頁：分享背景

22d—>7.0h—>1.0h

敏捷開發設計的內容比較多，按照那個講師的計劃講完所有的課程是22天（其中專業人才培養課程是9天，包括：優秀需求分析師、優秀軟體設計師和優秀系統分析師的培訓各3天。專案經理培養的課程也是9天，包括：專案管理、專案質量和專案評估各3天，中層管理領導培訓課程4天，包括：中層領導能力的訓練和績效考核各2天）。22天的課程，這哥們只講了一天（7小時，本來規劃師6小時講完的，因為內容多又拖延了一個小時）。不少內容都沒有講到，講到的內容也不是很詳細。短時間內無法消化，現在跟大家分享的時間很有限，不會超過1個小時。所以只能講其中部分內容：如何打造敏捷團隊。

第3頁：分享標題

如何打造敏捷團隊

第4頁：內容大綱

這四點是我們培訓那天的學習目標。我今天主要和大家分享第二部分：如何構建敏捷土壤，就是如何打造敏捷團隊。敏捷本質和專案管理方面我會提一下，還有關於“學會敏捷需求分析實用技巧”，主要是會成在下週的某一天和大家做一個分享。我們首先了解下敏捷的本質。敏捷這個詞很火熱，我們經常聽到它，而且敏捷確實被很多公司一直運用著，不僅在軟體專案研發方面，也運用到了軍隊、零售行業、學校管理等等。到底什麼樣的團隊才算是敏捷團隊，敏捷到底是什麼？下面我們從兩個方面來了解下敏捷的本質。

第5頁：敏捷的本質

1. 敏捷的核心基礎

2. 敏捷的特點

第一個是敏捷的核心基礎，第二個是敏捷的特點。

第6頁：核心基礎

我們在同一條船上

就像地基是建房子的基礎一樣，那麼敏捷的“基地”到底是什麼呢？網上各種版本都有，用一句通俗的話來講就是“我們在同一條船上”。這句話有兩層意思：一是專案團隊所有的成員都在同一條船上，二是所有員工和公司在同一條船上。這個聽起來好像很簡單，就兩句話，但是沒有公司能完全做到，尤其是第二條。因為要做到這兩點需要建立在強大的物質基礎之上，否則很難的。所以我們常常看到一個專案中，最著急的永遠是專案主管，因為整個專案團隊中就他的利益最大，一旦專案出事了，老闆肯定會找專案主管，不會找團隊中其他的人。所以專案負責人還是要幫助那些跟你在同一條船上的人，和你一起著急的同事。這個“基地”打得越結實，樓房才能建得更高，這個專案團隊才能站得更高，看得更遠。這樣的直接結果就是：團隊每個人都在進步。現在我們自己思考：我們在同一條船上嗎？這裡不作討論，只供大家思考。接下來我們瞭解下敏捷的特點：

第7頁：敏捷的特點

1. 所有人對專案成功負責。

2. 所有人直接需求驅動地工作。

3. 所有人都需要跨領域地工作。

4. 持續交付、迭代前進。

5. 小步前進，持續改進。

6. 有效、簡單。

這裡我們簡單瞭解下就行。1.所有人都對專案的成功負責，並不是只有專案經理一個人著急，忙個不停。2. 所有人直接需求驅動地工作，而並不是技術驅動地工作。因為需求一旦確定，就不應該修改了。所以需求的確認是很重要的，需要和直接研發產品的人溝通好。3. 所有人需要跨領域地工作。設計和研發、美工和設計，測試和研發都是可以跨領域工作的。4. 持續交付、迭代前進。5. 小步前進、持續改進。6. 有效和簡單是敏捷開發最直接的特點。敏捷的目的就是為了“簡單和高效”，最後是盈利。

第8頁：

如何打造敏捷團隊？

第9頁：團隊概念

設計、美工、研發、測試、實施等等

既然是分享，想跟大家小互動一下。我問下老劉吧，一個簡單的問題：隨便挑一個你正在做的專案，說出現在有幾個人？（你肯定會說一個人或者說事兩個人，還有詠爺。）這是不對的，除了研發人員，首先得包括專案負責人吧，還有設計、美工、測試、實施等等，只有和專案有關的人，都算專案團隊成員。這是我們很多人常犯的一個概念上的錯誤，問研發人員你們這個專案團隊有幾個人，他只會說研發人員的人數，不會把測試人員算在裡面。你問測試人員，你們專案組有幾個人，測試人員也會只會把研發人員算在裡面，把自己都拋棄了。好，下面我們通過介紹兩個經典的團隊架構，匯出優秀的團隊應該具備怎樣的特點。

第10頁：經典團隊架構

SCRUM團隊架構

MSF團隊架構

第一個是SCRUM團隊架構，大家有誰聽說過嗎？好，沒有就好！（好，知道的人不多就好！）現在很多人把SCRUM和敏捷劃等號。第二個是MSF團隊架構，這個團隊架構，上週五濤哥給大家講過，MicroSoft Solution Framework，微軟解決方案框架，後面我也會給大家簡單介紹一下。我們首先來聊聊SCRUM團隊框架。

第11頁：SCRUM團隊架構—創始人

這麼經典的團隊模式，我們至少得知道他的創始人是誰。SCRUM是由兩個美國佬提出的：JS和KS。這兩個都挺傳奇的。JS再哥們今年快60了，起初是飛行員，參加過美國越南戰爭，飛行超過100次任務。11年軍旅生涯結束之後，獲得科羅拉多醫學院的博士。先後擔任過11家軟體公司的CEO、CTO。KS也很牛，這哥們比JS正好大十歲，45年出生。剛開始是做商船經理，說白了就是管海上運貨商船的。後從事軟體開發40多年，曾給IBM大型機開發系統軟體，自己也創過業。兩人在一個IBM專案合作時候提出的SCRUM。下面我瞭解下這個團隊主要有哪些角色構成。

第12、13頁：SCRUM團隊架構—角色

角色主要分為三個：1. 是產品負責人PO，即ProductOwner。2. 是Scrum主管SM，即Scrum Master，此SM非彼“SM”。3. 是開發團隊Team。PO主要的職責是為產品提供願景，確定範圍和優先順序。這個提供願景很重要，大部分時候只有專案經理和主管才知道專案願景，這個專案做成了，有多好多好，可團隊其他成員根本不知道。這也是導致有時候只有專案經理一個人為專案著急的原因之一。像這張圖一樣，只有站著的那一個人看到前面美麗的景色，坐著的人根本看不見，即使喇叭聲音再大也沒有，最多是應付一下！要是拿喇叭的人說：“大家使勁劃啊！前方的沙灘都是比基尼大妞啊！”大家想想這種效果會怎樣。哈哈！

第14頁：SCRUM團隊小結

每位成員都對專案成功發揮獨一無二、不可替代的作用。

各成員可能經驗、能力等不盡相同，但都有條件有機會成為一等一的高手。

可讓各成員為專案成功各展所長。

可讓各成員有充分的成長空間。

此架構應是陽光開明、激勵進步、讓人身心愉快的。

第15頁：MSF團隊架構

MSF團隊上週五濤哥講過，這裡我就簡單介紹就OK了。MSF團隊是已溝通為中心，團隊成員之間的關係是：相互依賴，相互協作，平等。大家都對專案或產品的成功發揮自己所長，缺一不可。

第16頁：MSF團隊的核心思想

專案團隊中每個人都是同等重要的，

專案團隊由各專業人士組成的，

每位成員在自己的專業領域發揮領導作用，

每位成員對專案的最終成功負責。

第17頁：優秀團隊應該具備的特點

所有成員同等重要，每位成員都是主人翁，

能力高的人更有責任推動專案組人員提高水平，

學習、總結、進步。

前面兩點，我們前面都提到過，這裡不再過多解說。第三點：學習和總結是過程，進步是結果。怎樣學習？怎樣總結？給人的感覺總是很朦朧。我這裡拋磚引玉，給大家分享下自己的一點經歷。

第18頁：拋磚引玉之學習總結

1）每週五研發部的技術分享或者說經驗分享

2）Android小組階段性的程式碼走查

3）堅持寫技術部落格

前面兩點是我在上家公司的經歷，也是我參加工作第一家公司的經歷。第三點是我從參加工作以來一直在堅持做的一件事情。引用上週五濤哥講的“緊急和重要”的關係，學習和總結屬於“重要但不緊急”這一類的。學習重要嗎？當然重要，緊急嗎？當然不緊急。隨著時間的推移，會轉變為“即緊急又重要”的事情。所以我們常常感嘆：書到用時方恨少！當然大家也有自己的學習方法。

第19頁：如何看待“犯錯”？

軟體研發是創造性和發明性的工作，不犯錯是不可能的。大家贊同吧？其實其他部門也是一樣的。孔子都說：“人非聖賢，孰能無過？”

第20頁：如何看待“犯錯”？

但是我們得知道犯錯的原因，犯錯分為兩種：高階錯誤和低階錯誤。你是因為低難度的或者是反覆做過的工作犯錯，還是因為高難度的工作犯錯？那如果是前者，那就是犯低階錯誤，領導應該少批評並多幫助其改進；如果是後者，我們應該鼓勵“犯錯”，在高難度工作中犯錯進步是最快的，鼓勵“犯錯”其實就是鼓勵進步。

第21頁：“犯錯”有感！

失敗不是成功他媽，總結才是成功之母！

敏捷的本質和打造敏捷團隊就分享到此。接下來咱們聊聊專案估算、計劃和跟蹤。

第22頁：

專案估算、計劃、跟蹤

專案整個流程應該是：估算-->計劃-->跟蹤-->交付

第23頁：專案估算

我們先看下粗糙的估算：（展示圖片）幾個人討論，取個平均值，差不多就OK了。這樣還算好的，有時候領導直接衝過來把功能大概跟你講一下，需求也不完全清晰，就讓你給專案估算個時間。你估算的時間短了，領導說：“這是你說的啊，到時候得準時完成啊”，完不成你就死定了，就算加班勉強完成了，到時候出問題你也死定了；你估算的時間長了，領導又會說：“這麼點功能要開發這麼長時間呀！”，又讓領導誤以為我們沒有信心或者能力不行。那怎麼估算才合適呢？

第24頁：專案估算

我們在看看比較細的專案估算。至少應該分別從這四個方面對專案進行估算：需求細化（確定），軟體設計，程式碼實現及修復缺陷，測試。這樣做出來的估算相對而言比較有依據可言。應該是比較好的一種估算方法。

第25頁：專案計劃

按功能模組做專案計劃，以時間為節點，並指定相應功能模組的負責人。

第26頁：專案跟蹤

專案跟蹤應該有這麼一個表格：todo將要做的，doing正在做的，done已經做完的，filished通過測試的。

第27頁：內容回顧

將內容給大家回顧回顧即可。

第28頁：6min短視訊分享

直接放視訊即可，效果應該不錯。

第29頁：Thank You！

祝大家週末愉快！