課程簡介
通過接觸很多宣稱使用敏捷模式的團隊，發(fā)現(xiàn)真正在效果上體現(xiàn)出敏捷的團隊其實并不多。在實施敏捷的過程中滋生出很多的混亂，效率不高，而“敏捷”又成了很多混亂和計劃性差的保護傘。于是“偽敏捷”又成為近年來越來越多的討論聲音，這個現(xiàn)象值得仔細探究。本次課程筆者將真誠分享自己所帶的幾個團隊應用敏捷的實踐、改造敏捷的過程、落地的成功經驗、以及中間趟過的坑。在課程結束時，希望大家都能不僅獲得敏捷的落地實施能力、更能夠獲得隨時根據團隊和市場情況改造敏捷方法本身的能力。這才是敏捷真正的精髓！
目標收益
? 對于正在進行敏捷轉型的團隊或新團隊：可以獲得完整的敏捷方法知識體系，快速開展落地，同時規(guī)避敏捷開始階段容易調入的誤區(qū)，少走彎路
? 對于正在進行敏捷實踐的團隊：
o 大中型團隊：獲得組織級敏捷化的大廠模式
o 中小型團隊：獲得戰(zhàn)術級敏捷的調整能力
? 對于實施敏捷但效果不理想、感到困惑的團隊：可以有更多的交流和答疑，對癥下藥，看看到底是方法論本身的問題還是執(zhí)行的問題，以及如何改進
培訓對象
? 研發(fā)人員
? 研發(fā)管理人員
? 敏捷教練
? 產品經理
? 測試管理人員
課程大綱
|
【第一章】 敏捷落地的頂層設計 |
敏捷其實是一個說起來容易做起來難的方法，它的靈活性是廣受歡迎的原因；但敏捷的難以駕馭也是因為它太靈活。這一模塊分享筆者真實項目中出現(xiàn)的挑戰(zhàn)，這些也是目前業(yè)界敏捷落地的過程中的普遍問題。整個課程由這些問題開始逐個擊破，本章講解敏捷落地的頂層設計層面，并分享筆者在實際工作中制作的“Photoshop敏捷寶典” （1） 怪象一：一個項目反反復復、改來改去，大家看似都很忙，有效輸出卻不多，卻說這叫敏捷 （2） 怪象二：產品經理總覺得需求已經很清楚了，開發(fā)總覺得需求不清 （3） 怪象三：進度滯后有如家常便飯，卻說這叫敏捷 （4） 以上是筆者帶隊過程中的親身經歷，讓我們開始真正的敏捷——敏捷的頂層設計 （5） 重新定義和明確敏捷團隊的角色、職責、邊界、和人員配比 （6） 真實實例分享：“Photoshop敏捷寶典” |
|
【第二章】 敏捷模式下的產品—開發(fā)配合 |
產品方向和演進圖譜是敏捷實施的重要基礎，敏捷是整個團隊一直朝著一個目標探索、嘗試、盡量用最短路徑達到目標。而沒有方向的反復搖擺和消耗嘗試何談敏捷。本章分享如何將產品和開發(fā)作為一個整體提升敏捷度，以及對產品和開發(fā)有哪些新能力要求和輸出要求，同時分享產品開發(fā)配合、確認、迭代的實施細節(jié)和實際案例 （1） 產品細節(jié)可以靈活調整，產品方向則要相對穩(wěn)定（+產品規(guī)劃原則） （2） 產品需求可以不重文檔，但不能描述不清（+方法實戰(zhàn)分享） （3） 產品需求可以變更，但不能沒有變更管理（+變更控制方法） （4） 產品需求可以思考調研，但不能沒有時間控制（+進度控制實踐） （5） 產品輸出的關鍵點和標準 （6） 開發(fā)啟動的關鍵點和標準 （7） 敏捷模式下對架構的要求 （8） 實例分享：Photoshop的產品與開發(fā)之間是如何配合的 |
|
【第三章】 敏捷教練——整個項目的助推器 |
敏捷教練是團隊中非常關鍵的角色，做的好可以極大提升項目的效率；反之，也會拖住整個團隊。這就對敏捷教練的大局觀和對敏捷的理解提出了更高要求。本章重點講解敏捷教練的實戰(zhàn)落地點及方法，通過本章學習敏捷教練將對項目進展的把控力得以全面提升。同時，分享筆者在實際工作中定義和實現(xiàn)的項目狀態(tài)儀表盤，這些是非常實用的參考內容 （1） 敏捷教練的必備工具 （2） 敏捷教練的分配資源能力強化方法 （3） 敏捷教練的計劃能力提升方法實踐 （4） 敏捷教練的項目執(zhí)行力強化訓練 （5） 制定迭代周期的原則和實戰(zhàn)要點 （6） 任務追蹤及通過精細化管理 （7） 定義可視化項目儀表盤 （8） 實例分享：Photoshop的項目狀態(tài)儀表盤 |
|
【第四章】 敏捷模式下的協(xié)同開發(fā) |
敏捷模式之下的協(xié)同開發(fā)對于開發(fā)之間的溝通提出了更高、更頻繁的要求，技術之間的依賴和影響日益增多。但程序員隊伍并不是一個喜歡花大把時間進行大量語言交流的群體。程序員不怕多做工作，但討厭做無意義的工作，技術開發(fā)步調不一致時開發(fā)會大為光火。本章介紹如何建立和落地一套機制，可以達到盡量提升協(xié)同開發(fā)效率同時降低對溝通的依賴的目的 （1） 需求確認的原則和標準 （2） 如何避免并行開發(fā)間的相互干擾 （3） 提高代碼復用度的三層結構 （4） 從代碼中加注釋到注釋中加代碼 （5） 如何制定、明確、和保障開發(fā)任務完成的退出標準 （6） 協(xié)同開發(fā)時代碼提交的流程和沖突處理 （7） 確認機制和廣播機制 （8） 案例分享：讓我們的開發(fā)人員每天下班時都清清楚楚完成今日進度目標 |
|
【第五章】 敏捷測試及敏捷發(fā)布 |
做的快還得做的好才是真敏捷，測試和發(fā)布環(huán)節(jié)跟不上照樣敏捷不起來。本章分享以測試驅動開發(fā)和缺陷預防為核心的敏捷測試實踐，并分享Photoshop的結對編程模式 （1） TDD：測試驅動開發(fā)的原則和實踐分享 （2） 自動化測試——敏捷測試的重要基石 （3） 代碼注射及代碼覆蓋率的測量和分析 （4） 缺陷預防及測試結果的快速反饋：將測試活動和測試結果提前到開發(fā)代碼提交之前 （5） 構建管理：通過構建級別的定義及使用支撐快速發(fā)布 （6） 案例分享：Photoshop的結對編程 |
|
【第六章】 敏捷方法的自我進化能力 |
敏捷重意不重形，切記思維僵化，如果照搬硬套敏捷宣言中的XX原則、XX事項本身就已經偏離了敏捷的思想精華。我通過在不同規(guī)模、不同基礎、不同行業(yè)的團隊應用敏捷，深深體會到對敏捷方法自身的不斷思索、持續(xù)演進才是真正的敏捷落地 （1） 敏捷不可拘泥于套路，頭腦要活、思路要靈 （2） 案例分享：我在大廠的敏捷落地都做了哪些調整 （3） 案例分享：我在中小型團隊的敏捷落地都做了哪些變化 （4） 案例分享：精英化程度較高的團隊敏捷怎么玩 （5） 案例分享：基礎較為薄弱的團隊敏捷怎么開展 （6） 反思：那些所謂的“絕對” （7） 每日站會改巡會 （8） 如果不能敏捷的輸出有效結果，任何理論都毫無意義 （9） 量體裁衣：獲得制定出適合你團隊的量身訂造敏捷模式的超級能力！ |
|
【第一章】 敏捷落地的頂層設計 敏捷其實是一個說起來容易做起來難的方法，它的靈活性是廣受歡迎的原因；但敏捷的難以駕馭也是因為它太靈活。這一模塊分享筆者真實項目中出現(xiàn)的挑戰(zhàn)，這些也是目前業(yè)界敏捷落地的過程中的普遍問題。整個課程由這些問題開始逐個擊破，本章講解敏捷落地的頂層設計層面，并分享筆者在實際工作中制作的“Photoshop敏捷寶典” （1） 怪象一：一個項目反反復復、改來改去，大家看似都很忙，有效輸出卻不多，卻說這叫敏捷 （2） 怪象二：產品經理總覺得需求已經很清楚了，開發(fā)總覺得需求不清 （3） 怪象三：進度滯后有如家常便飯，卻說這叫敏捷 （4） 以上是筆者帶隊過程中的親身經歷，讓我們開始真正的敏捷——敏捷的頂層設計 （5） 重新定義和明確敏捷團隊的角色、職責、邊界、和人員配比 （6） 真實實例分享：“Photoshop敏捷寶典” |
|
【第二章】 敏捷模式下的產品—開發(fā)配合 產品方向和演進圖譜是敏捷實施的重要基礎，敏捷是整個團隊一直朝著一個目標探索、嘗試、盡量用最短路徑達到目標。而沒有方向的反復搖擺和消耗嘗試何談敏捷。本章分享如何將產品和開發(fā)作為一個整體提升敏捷度，以及對產品和開發(fā)有哪些新能力要求和輸出要求，同時分享產品開發(fā)配合、確認、迭代的實施細節(jié)和實際案例 （1） 產品細節(jié)可以靈活調整，產品方向則要相對穩(wěn)定（+產品規(guī)劃原則） （2） 產品需求可以不重文檔，但不能描述不清（+方法實戰(zhàn)分享） （3） 產品需求可以變更，但不能沒有變更管理（+變更控制方法） （4） 產品需求可以思考調研，但不能沒有時間控制（+進度控制實踐） （5） 產品輸出的關鍵點和標準 （6） 開發(fā)啟動的關鍵點和標準 （7） 敏捷模式下對架構的要求 （8） 實例分享：Photoshop的產品與開發(fā)之間是如何配合的 |
|
【第三章】 敏捷教練——整個項目的助推器 敏捷教練是團隊中非常關鍵的角色，做的好可以極大提升項目的效率；反之，也會拖住整個團隊。這就對敏捷教練的大局觀和對敏捷的理解提出了更高要求。本章重點講解敏捷教練的實戰(zhàn)落地點及方法，通過本章學習敏捷教練將對項目進展的把控力得以全面提升。同時，分享筆者在實際工作中定義和實現(xiàn)的項目狀態(tài)儀表盤，這些是非常實用的參考內容 （1） 敏捷教練的必備工具 （2） 敏捷教練的分配資源能力強化方法 （3） 敏捷教練的計劃能力提升方法實踐 （4） 敏捷教練的項目執(zhí)行力強化訓練 （5） 制定迭代周期的原則和實戰(zhàn)要點 （6） 任務追蹤及通過精細化管理 （7） 定義可視化項目儀表盤 （8） 實例分享：Photoshop的項目狀態(tài)儀表盤 |
|
【第四章】 敏捷模式下的協(xié)同開發(fā) 敏捷模式之下的協(xié)同開發(fā)對于開發(fā)之間的溝通提出了更高、更頻繁的要求，技術之間的依賴和影響日益增多。但程序員隊伍并不是一個喜歡花大把時間進行大量語言交流的群體。程序員不怕多做工作，但討厭做無意義的工作，技術開發(fā)步調不一致時開發(fā)會大為光火。本章介紹如何建立和落地一套機制，可以達到盡量提升協(xié)同開發(fā)效率同時降低對溝通的依賴的目的 （1） 需求確認的原則和標準 （2） 如何避免并行開發(fā)間的相互干擾 （3） 提高代碼復用度的三層結構 （4） 從代碼中加注釋到注釋中加代碼 （5） 如何制定、明確、和保障開發(fā)任務完成的退出標準 （6） 協(xié)同開發(fā)時代碼提交的流程和沖突處理 （7） 確認機制和廣播機制 （8） 案例分享：讓我們的開發(fā)人員每天下班時都清清楚楚完成今日進度目標 |
|
【第五章】 敏捷測試及敏捷發(fā)布 做的快還得做的好才是真敏捷，測試和發(fā)布環(huán)節(jié)跟不上照樣敏捷不起來。本章分享以測試驅動開發(fā)和缺陷預防為核心的敏捷測試實踐，并分享Photoshop的結對編程模式 （1） TDD：測試驅動開發(fā)的原則和實踐分享 （2） 自動化測試——敏捷測試的重要基石 （3） 代碼注射及代碼覆蓋率的測量和分析 （4） 缺陷預防及測試結果的快速反饋：將測試活動和測試結果提前到開發(fā)代碼提交之前 （5） 構建管理：通過構建級別的定義及使用支撐快速發(fā)布 （6） 案例分享：Photoshop的結對編程 |
|
【第六章】 敏捷方法的自我進化能力 敏捷重意不重形，切記思維僵化，如果照搬硬套敏捷宣言中的XX原則、XX事項本身就已經偏離了敏捷的思想精華。我通過在不同規(guī)模、不同基礎、不同行業(yè)的團隊應用敏捷，深深體會到對敏捷方法自身的不斷思索、持續(xù)演進才是真正的敏捷落地 （1） 敏捷不可拘泥于套路，頭腦要活、思路要靈 （2） 案例分享：我在大廠的敏捷落地都做了哪些調整 （3） 案例分享：我在中小型團隊的敏捷落地都做了哪些變化 （4） 案例分享：精英化程度較高的團隊敏捷怎么玩 （5） 案例分享：基礎較為薄弱的團隊敏捷怎么開展 （6） 反思：那些所謂的“絕對” （7） 每日站會改巡會 （8） 如果不能敏捷的輸出有效結果，任何理論都毫無意義 （9） 量體裁衣：獲得制定出適合你團隊的量身訂造敏捷模式的超級能力！ |
近期公開課推薦
