Hiiir 百人團隊導入敏捷實踐經驗
•
56 recomendaciones•4,719 vistas
如何將敏捷實踐帶進大規模的產品開發團隊之中，其中會遇到的困境，以及解決的方式。 真正導敏捷的關鍵是思維，具體落實是組織，善用工具能為催化劑，以上不改變，就當成練兵的養份即可，總有一天會開花。
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (17)
Similar a Hiiir 百人團隊導入敏捷實踐經驗
Similar a Hiiir 百人團隊導入敏捷實踐經驗 (20)
Más de ChiaHsien Lee
Hiiir 百人團隊導入敏捷實踐經驗
- 1. Hiiir 百人團隊導入敏捷實踐經驗 Modern Web 2017 Hiiir 共同創辦人 Neil Lee 時間軸科技股份有限公司
- 2. 現職： • Hiiir 時間軸共同創辦人暨技術總監 • 淡江大學資訊管理學系企業導師 • 台灣大學工業工程學研究所研究生 經歷： • 淡江大學資訊管理系課程委員會委員 • 創辦兩間公司，待過兩間 Start-up • 2015,2016 AWS Summit Taipei Speaker • 2013,2016 COSCUP Speaker • 2012 MOCON Speaker • 淡江資管渡船頭之戀BBS站站長 證照： • CSM / CSPO 李佳憲 Neil Lee
- 3. 新創團隊到永續創新企業 • 從新創到創新過程 • 敏捷不要只是口號 • 失敗是必然但積累未來成功 • 持續改變的過程 • 總結
- 4. 單一產品： 貼曆 1500 萬 PVs 380 萬 User 規模：30 人 Hiiir 成長階段 三網一實品牌專 案：可口可樂、 全家、爭鮮 （百項大小專案） 規模：60 人 全力發展線上 到線下行動應 用服務 規模：300 人 衝撞市場 （追求亮點） 生存擴張 （追求效率） 建立生態圈 （追求傳承） 2008-2010 （燒錢） 2010-2012 （接案） 2013-2017 （併購） 2017- （合併） 集團電商整併， 期待產生綜效 結合集團資源 規模：400 人 建立運營規範 （追求效率） 遠時科技
- 5. 時間軸科技 服務藍圖 O2O手機票券購物平台 電子支付系統 實體通路M化解決方案 巷弄 場域： 台北 台南 台中 高雄 實體通路O2O 解決方案 時間市集 內容共創、導購分潤平台 為策展原生創作而生 就算是一卷衛生紙也有它的特色 Yahoo!奇摩行動遊戲入 口 台灣最具規模卡牌網站 卡牌搜尋、組隊系統、遊 戲攻略 Y!Play 導購/自媒體 解決方案 成效媒體投遞 品牌全媒策劃 媒體廣告代理 AA pixel 廣告監控系統 AA Miner 廣告採購 解決方案 品牌電商客製開店 客製電商平台開發 主機系統維護 廣告採購 影音直播 策展議題 網紅導購 爆品打造 加購變價式購物 場域出發 付費會員制 忙碌上班族的好夥伴 線上購物 解決方案 策展 影音電商 創新 全館變價 品牌 旗艦開店 Traffic ModelSales Model
- 6. • 新創團隊期 – 有默契目標契合的夥伴 • 低潮期 – 發展不如預期時 • 急速擴張期 – 找到浪頭逐浪而起 • 團隊崩解期 – 快速擴張導致的文化不一致性 • 核心團隊建立– 集合願意相信改變的夥伴 • 重新開始 – 透過核心團隊開始建立文化 團隊是成長重要的關鍵 個人會成就團隊，團隊也會榮耀個人 （有神快拜） （廟要倒了神都走了） （管他是什麼先來再說） （有耶穌有佛祖到底那一趴） （相信能反擊的搜查隊呀） （開始遠征吧） 團隊成長循環
- 7. 扁平化組織 專案型組織 衛星型組織 新創團隊期 低潮期 急速擴張期 團隊崩解期 核心團隊建立 重新開始 2008 2009 2010 2011 2012 2013 20人 產品研發團隊組織演進史 8人 40人 2016 邦聯型組織 俱有共識 的聚落 100人 議會
- 8. Welcome to VUCA World Complexity （複雜） Volatility （易變性） Uncertanily （不確定） Ambiguity （模糊） Avaliabile data Predictionaboutfutureimpact + + 每年全球產生的資 訊量超過摩爾定律 ，每兩年超過兩倍 口語傳播 紙 電台 網路
- 18. Gap ? VUCA World
- 19. Vargo and Lusch （2004）服務主導邏輯
- 20. Value in Exchange（Produce) V.S Value in Use（Co-Create、Co-Production） 商品主導邏輯 V.S 服務主導邏輯
- 21. 主動變革、敏捷、洞察、預見
- 22. 敏捷不是口號 • 大家不是都上過課了。 • 開發速度會加倍嗎。 • 需求隨時都可以變更。 • 我們每天都有站立會議呀。 • 還是有 DeadLine，而且規格都不能少。 • 我20年前就在搞敏捷了！
- 23. 形式上的敏捷比瀑布更惱人
- 25. 敏捷 ! = 快 敏捷 == 快速應變
- 26. 失敗是必然但積累未來成功 大規模導入（2016-2017） • 組織改造 • 強力推動落實所有流程 • 需求單位適應期 • 持續調整（找到對得人） • 逐步擴展 • 全面導入 2012-2016 小規模培養核心團隊 • 產生成果進行分享推廣 • 增加人數打散分組 建立開發者文化、導入敏捷思維 失敗重來 自組織 Tools：CI / CD / Automation Testing / Ticket / Communication
- 27. 失敗原因 • PO 的工作和 PM 一樣。 • 績效指標未能連動。 • 資訊通透層度太低。 • 少了成就感的節奏。
- 29. 文化 方法 工具
- 31. 請找個 Scrum Master Expert 加入公司！
- 32. 文化 組織 方法
- 33. 組織的藝術 部門 Ａ單位 Leader Leader 客服 訂單 Ｂ單位 APP APP C單位 QA QA QA QA TEAM A TEAM B TEAM C PO 需求單位 A 需求單位 B 需求單位 C
- 36. 組織的藝術 部門 Ａ單位 帳務 子系統 訂單 訂單 Ｂ單位 APP APP C單位 QA QA QA QA TEAM A TEAM B TEAM C PO 需求單位 A 需求單位 B 需求單位 C 技術會議 TEAM Ｄ
- 40. Daily Stand up Meeting
- 41. Retrospective
- 42. 人
- 43. 機器人 or 智慧工作者？
- 44. 這是機器人未來的樣貌
- 45. 工廠 VS 創意
- 48. 公司文化 部門文化 個人習慣 教 練 引 導 創 造 動 能 領導的雙向 文化 方法 工具 • 給予團隊犯錯的空間 • 尋找資源給團隊
- 49. 角色
- 50. 重新定義 R&R 和 建立有效 KPI： • 事業單位是眼睛（行銷、業務、企劃、營運） • PO 是溝通分析者（PM、企劃） • 大腦由團隊形成共識決（Cross function Team） • 手腳執行（Design、RD）
- 52. PO = Problem Owner = Police Officer • 找出產品的問題。 • 勾勒產品/功能願景。 • 說出功能故事。 • 了解如合行銷推廣。 • 將功能價值說明給團隊知道。 • 掌握產品數據表現。 • 了解市場動態。 • 回答團隊對於功能目標的問題。 • 估算 PBI 價值。
- 54. 專案管理迷思 TIME Scope Cost 如期、如質、如預算 ＰＭＰ 時間固定（Time Box） MVP Performance
- 56. 士氣 具體成果調整節奏
- 57. 溝通 不同文化 不同年紀 不同部門 不同層級 文化 方法 工具
- 60. 類型 參與人次 預期成效 創造內外部交流的機會 文化 方法 工具 • 約莫 30 場的內外部交流
- 62. 建立隨時溝通的文化
- 63. 老闆要扮演的角色 • 做個成年人。 • 不要臉。 • Stanout。 • Show,東tell。 • 取得團隊支持，保護也領導團隊。
- 66. Team Velocity Sprint 1: 90 pts Nov 1~ Nov 22 / 3w Sprint 2: 80 pts Nov 23 ~ Dec 6 / 2w Sprint 3: 112 pts Dec 6 ~ Dec 20 / 2w Sprint 4: 276 pts Dec 21 – Jan 3 / 2w （加入 maiatain 估點尚不精準） avg: 139.5
- 68. 插件狀況分析與改善（任務透明度增加後的優點） 插件包括： 1. 真的插件、hotfix 2. iOS https 的驗證 3. Ramp up 4. 福委會會議與討論 很反映現實狀況，很好！
- 69. 插件狀況改善比較 Sprint 2 有多於三分之一的時間在處 理插件 Sprint 3 只剩下 14.7 %
- 70. 團隊做的怎樣？ 經過了 4 個 sprint，已經變成數學題了～ sum_salary = 團隊薪資 / 2 value_delievered = sprint 的產出物的價值（PO 與 Stakeholder 決定） if value_delievered >= sum_salary 團隊表現好 else 團隊表現不好
- 71. 工具
- 72. 訊息透明度解決溝通問題 • 工作任務的透明度 • 溝通內容的透明度 • 成果狀態的透明度 善用開源軟體 提升資訊透明度 自動化機制解決效率問題 • 測試的自動化 • 部署的自動化 • 監控的自動化 目標清楚 工作有效率 文化 方法 工具
- 73. 持續整合 Continuous Integration, CI (1/2) • 說明 – 每次異動進行檢查、測試，進而達到程式碼一完成有把握上版 – 測試項目 • RD: 單元測試(Unit Test)、功能測試(Functional Test)… • QE: 功能自動化測試 – 延伸：持續部署 Continuous Delivery, CD • 目前 Hiiir CI 檢查項目 – 測試覆蓋率(Coverage Rate): 單元或功能測試覆蓋率 – 程式碼風格(Code Style)：統一的撰寫風格 – 重複程式碼(Duplicated Code)：非用複製貼上的程式 – PMD：檢測潛在缺陷、不安全或未優化程式碼。例：記憶體未使用 、程式函式定義太大
- 74. 持續整合 Continuous Integration, CI (2/2) • Hiiir Jenkins Server
- 75. 部署時會透過 Jenkins 進行 Auto Testing 驗證
- 76. CI 狀況: coverage rate duplicated code coding style PMD Member 57% -> 57.7% (0.7%) 0 -> 0 10 -> 0 69 -> 62 Product 54.7% -> 55.1% (0.4%) 0 -> 0 7 -> 7 134 -> 137 (+3) Order 34.2% -> 35.5% (1.3%) 12 -> 12 1344 -> 836 430 -> 431 (+1) Supplier 0% -> 11% (11%) 6 -> 4 639 -> 11 108 -> 86 Core 6% -> 18% (12%) 4 -> 4 287 -> 425 (+138) 102 -> 105 (+3) Resource 8.4% X X X Support 6.5% X X X Mall 0% X X X Promotion 92.4% 0 0 0 Cart 91.9% 0 0 0 Search 90.9% 9 6 0 優先權與目標 1. Coverage Rate: 建議 > 75% 2. Duplicated Code: 0 3. PMD: 0 4. Code Style: 0
- 77. 程式碼品質追蹤彙整平台 • 問題：團隊需每月手動追蹤目標達成狀況，僅能看到是否達成目標，無法看 到持續的進步 • 行動方案：透明團隊成果提昇改善動力 Before After • 傳統 Excel • 透過彙整到 Tableau 分析 • 每日異動趨勢、即時計算是否達成該月目標
- 78. 文化 方法 工具 DevOps flow All in RocketChat 主機警示訊號 程式部署提示 部署後狀態 程式碼品質 任務狀態
- 79. 部署任務於 Redmine 派送透過 Slack 進行通知
- 80. Redmine 詳盡紀錄部署資訊
- 81. GitLab 紀錄 Code Diff 及 CodeReview / Merge Log
- 82. 每次 commit code 會由 Jenkins 排程自動驗站 Quality
- 83. 部署時會透過 Jenkins 進行 Auto Testing 驗證
- 84. DevOps 部署後透過 ＲocketChat 更新狀態給各主管
- 85. 結論： • 敏捷是一種思維而不是一成不變的規則。 • 領導需要信任，信任不是靠強迫。 • 每次失敗都會有所積累成為下一次的養分。 • 從組織改變才可能影響到文化。 • 推動敏捷文化需要管理層與團隊同步扮演好角色才可能推動。 • 推動者要隨時做好被殺頭的心理準備。
- 86. Ｑ＆Ａ • 這功能什麼時候會好？給我一個DealLine。 • Ａ單位與B單位都各自提出很急很趕的功能該該如何處理？ • 有人就是不願意參加團隊的會議和分享？
- 88. 願大家在敏捷路上持續學習
Notas del editor
- 三個維度的成長階段
- 一個人若每天24小時不停觀看現今世上超過2,000億部的HD電影(片長為2小時)，需花上4,700萬年才能看完。
- 我們最優先的任務，是透過及早並持續地交付有價值的軟體來滿足客戶需求。 竭誠歡迎改變需求，甚至已處開發後期亦然。敏捷流程掌控變更，以維護客戶的競爭優勢。 經常交付可用的軟體，頻率可以從數週到數個月，以較短時間間隔為佳。 業務人員與開發者必須在專案全程中天天一起工作。 以積極的個人來建構專案，給予他們所需的環境與支援，並信任他們可以完成工作。 面對面的溝通是傳遞資訊給開發團隊及團隊成員之間效率最高且效果最佳的方法。 可用的軟體是最主要的進度量測方法。 敏捷程序提倡可持續的開發。贊助者、開發者及使用者應當能不斷地維持穩定的步調。 持續追求優越的技術與優良的設計，以強化敏捷性。 精簡──或最大化未完成工作量之技藝──是不可或缺的。 最佳的架構、需求與設計皆來自於能自我組織的團隊。 團隊定期自省如何更有效率，並據之適當地調整與修正自己的行為。
- 人腦 18 歲就發育完成足夠活在世界上
- 由主管自發，公司贊助。
- 有內部各團隊在玩的技術分享，Agile 內訓，和團隊默契訓練，
- Sniffer = Codeing Style C/P Status Mess Dectector Current Rulesets List of rulesets and rules contained in each ruleset. Clean Code Rules: The Clean Code ruleset contains rules that enforce a clean code base. This includes rules from SOLID and object calisthenics. Code Size Rules: The Code Size Ruleset contains a collection of rules that find code size related problems. Controversial Rules: This ruleset contains a collection of controversial rules. Design Rules: The Code Size Ruleset contains a collection of rules that find software design related problems. Naming Rules: The Naming Ruleset contains a collection of rules about names - too long, too short, and so forth. Unused Code Rules: The Unused Code Ruleset contains a collection of rules that find unused code.