關于敏捷：

是一個框架，在此框架中，人們可以解決復雜的自適應難題，同時也能高效并創造性地交付最高價值的產品，它是輕量級的，易于理解的，難以精通的

敏捷的精髓在于小團隊，個體團隊具有高度靈活性和適應性，當單個、幾個、多個和團隊在開發、發布、運營和維護成千上萬人的工作和工作產品時，這些優勢得以持續運作并發揮價值。

從現在的趨勢來看，不管是國外的谷歌、IBM、Facebook，還是國內的阿里、騰訊、華為，越來越多的是以小團隊作戰，這些公司慢慢成為了一個個平臺，平臺提供所有基礎的服務和軟硬件資源，優秀的人互補地、順其自然的形成小型敏捷團隊 5-9人，完成某一個或某幾個特定目標的項目、產品、任務、活動 ，從而體現價值，創造財富，未來的世界是自由人的世界，這符合科學社會主義的發展趨勢，而我們正走在這樣的道路上。

敏捷采納一種迭代、增量式的方法來優化對未來的預測和控制風險，我們可以檢視下當前互聯網企業，產品的發展基本也都遵循這樣的發展軌跡，小到1天1次或幾次，大到1周或1個月一次，不斷進行版本的迭代升級，不管是APP、小程序或是PC端，亦或是一些非軟硬件的營銷活動，亦如此。

三大措施：

透明、檢視、適應?是支撐每一個經驗過程實施的支柱

透明：

就像從【重新定義公司】提到的谷歌的開會模式，過程中的關鍵環節對于那些產出負責的人必須是顯而易見的，所有人都可以看到、聽到、感受到這些內容，去引發思考和想象，所有的過程不是某一個人或領導們在參與或主導，而是每個人都在參與，都在未最終結果負責。

檢視：

檢視則是對過程或階段性目標或結果的驗收和把控，我們不再是安排一個任務，在最終交付的時候做檢視，而是把一個大任務或活動切分成了很多細粒度的小因子，相應的目標進度，可以一目了然，這也就要求我們具備一項很重要的技能，對任務或工作的拆分，當前不管是敏捷，還是精益、亦或是PMP、P2，這些優秀的實踐，均開始強調這些，既然我們都不是萬能的，也都不是十項全能，那么在需要別人協助的時候，把問題拆分，便是解決問題的最好方式。

適應：

適應是我們強調要靈活變通，不要死板，調整工作必須盡快執行如此才能最小化進一步的偏離，甚至于在我們制定計劃，執行策略或方案時，對方法論的裁剪，去適應我們具體的場景，也是很關鍵的，敏捷、精益、P2理論均如是。

四個事件：

包含Sprint 計劃會議、每日Scrum 站會、Sprint 評審會議、Sprint?回顧會議

Sprint：

Sprint?是?Scrum的核心，其持續時間一般為一個月或更短的時間，每一個Sprint內構件一個“完成”、可用的潛在可發布的產品增量。Sprint由Sprint?計劃會議、每日?Scrum?站會、開發工作、Sprint?評審會議?和?Sprint?回顧會議構成。

每個Sprint都可以被視為一個項目，為期不超過一個月。

Sprint?計劃會議

Sprint?中要做的工作在Sprint?計劃會議中做計劃，這份工作計劃是由整個Scrum團隊共同協作完成的。Sprint?計劃會議是限時的，以一個月的Sprint來說最多8小時為上限，Scrum?Master?要確保會議順利舉行，并且每個參會者都理解會議目的，Scrum?Master要教導Scrum團隊遵守時間盒的規則。

每日Scrum 站會

每日 Scrum 站會是開發團隊的一個以 15 分鐘為限的事件。每日 Scrum 站會在 Sprint的每一天都舉行。在每日 Scrum 站會上，開發團隊為接下來的 24 小時的工作制定計劃。通過檢視上次每日 Scrum 站會以來的工作和預測即將到來的 Sprint 工作來優化團隊協作和性能。每日 Scrum 站會在同一時間同一地點舉行，以便降低復雜性。

我在做CTO和產品總監時，會要求每個產品研發團隊，每天晚上在當天工作結束前的10分鐘開始，團隊成員在站會前把當日工作進度更新完畢，站會時檢視進度，并主要聚焦于問題和經驗分享，以及資源協作和次日的工作調整與安排。

Sprint?評審會議

Sprint?評審會議在Sprint快結束時舉行，用以檢視所交付的產品增量，并按需調整產品待辦列表，在Spint?評審會議中，Scrum團隊和利益攸關者協同討論在這次Sprint中所完成的工作，根據完成情況和Sprint?期間產品待辦列表的變化，所有參會人員協同討論接下來可能要做的事情來優化處理。

Sprint回顧會議是Scrum?團隊檢視自身并創建下一個Sprint改進計劃的機會，該會議的目的在于：

（1）檢視前一個Sprint?中關于人、關系、過程和工具的情況如何

（2）找出并加以排序做得好的和潛在需要改進的主要方面

（3）制定改進Scrum團隊工作方式的計劃

我們可以理解為復盤，階段性的復盤，可以幫我們查漏補缺，同時進行團隊協作和工作方式的優化、改進，以此方式不斷以階梯式或螺旋式上升的方式推動產品迭代和團隊提升

五大價值觀：

承諾、勇氣、專注、開放、尊重

團隊的構成：

一名產品負責人、開發團隊、一名Scrum?Master組成。正如現在敏捷、精益大行其道，所有模式的發展正遵循著以項目為中心——以產品為中心——以用戶為中心的發展路線，向前推進，有一個產品負責人和Scrum?Master來領導的開發團隊，會更專注于用戶增長和商業價值，開發團隊未來的頭腦中也應該會多一些用戶、商業的理念或認知，不再僅僅只有技術，或編程、代碼。

設置我們可以進一步想象，除開發團隊外，我們還會有運營團隊、售后團隊，那么是不是跟增長黑客的理念吻合了呢，所以說大道至簡、世界大同，很多新的理念都不是那么高深莫測的，從以前的部門職能團隊，到現在的自組織跨職能團隊，我們所要達成的是怎么更好的服務客戶，怎么更有效的創造商業價值。

產品負責人

未來的工作中，我們會看到更多的職能崗位發展成為負責人，就像產品負責人一樣，我們應該擔負起一定的職責，而不僅僅是執行完成工作，這么簡單

產品負責人是負責管理產品待辦列表的唯一負責人，產品待辦列表的管理包括：

（1）清晰地表述產品待辦列表項

（2）對產品待辦列表項進行排序，使其最好地實現目標和使命，即我們所說的迭代次序、優先級

（3）優化開發團隊所執行工作的價值

（4）確保產品待辦列表對所有人是可見、透明和清晰的，同時顯示Scrum團隊下一步要做的工作

（5）確保開發團隊對產品待辦列表項目有足夠深的了解

但從現在國內的中小型企業來看，一些公司中高級領導者對產品主導型跨職能團隊的理解和認知，還未到一定程度，仍停留在項目管理層級，仍然以項目經理、技術總監來主導產品研發，產品經理只是負責原型設計、需求規格制定的整個產品生命周期的某一個環節工作，但我們可以看到的是華為、阿里、騰訊這些科技巨頭，已經開始實踐，不管是Scrum，還是DevOps，相信在這些公司的引領下，我們很快能看到一個快速進步的局面。

Scrum?Master

在此實踐中，我們還看到了一個職位Scrum?Master，這個人對于團隊來說，是一個服務型領導，主要來促進和支持Scrum，通過他來幫助每個人理解Scrum理論、實踐、規則、價值。

從其職責定位上來看，Scrum?Master以各種方式服務于產品負責人，包括：

（1）盡可能確保Scrum團隊中的每個人都能理解目標、范圍和產品域

（2）找到有效管理產品待辦列表的技巧

（3）幫助Scrum團隊理解為何需要清晰且簡明的產品待辦列表項

（4）理解在經驗主義的環境中的產品規劃

（5）確保產品負責人懂得如何安排產品待辦列表使其達到最大化價值

（6）按要求或需要引導Scrum事件

當然Scrum?Master也要服務于團隊、組織，具體的職責可以查看附件中的描述，怎么類比理解兩者的關系呢，就好像團長、政委、參謀長三者之間的關系，產品負責人就相當于團長，負責產品的整個生命周期，對目標和具體工作決策和領導，負全部責任，Scrum?Master就相當于政委、參謀長，進行理論的宣導和策略的講解，同時制定具體的作戰方針，輔助產品在整個生命周期中各個環境高效、順利運行。?這樣的搭檔模式，才能讓團隊發揮最大效能，產品生命周期更順暢、高效，獨裁或是多人決策，都不是一個好的選擇。

推薦工具：

在帶團隊的時候，對比多TeamBition、WorkTile、騰訊TAPD，覺得都沒有跟自身已有BUG?Tracker系統、TIM討論組這種方式結合起來方便好用，也或許是習慣問題，當把內部流程打通之后，最適合自己的反倒是對已有資源的整合，這種成本也最小

最近在接觸DevOps，覺得對于開發或產品團隊來講，這是一個很好的工具或理念，非常完美的把整體流程串聯了起來，把一些復雜的流程自動化pull了起來，而不是push，不管是Gitee、阿里云效、騰訊TAPD還是華為的DevCloud，我都試用了下，如果從我的角度來看的話，我更喜歡華為的DevCloud，比較靈活，而且是一體成型的，使用操作流程、功能齊全、頁面功能清晰可得，項目構建、發布、代碼管理、檢測等都一應俱全，而且5人內免費使用，對于團隊或個人，都適用。

總結

以上是生活随笔為你收集整理的敏捷指南阅后的几点体会的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。