中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

敏捷轉型涉及到流程建設、人員培訓、平臺建設、軟件架構優化等，一家公司要想成功地完成敏捷轉型并非易事。

一件事情，干了36個月，想想還真是蠻長的。作為一家傳統公司（消費類電子）在進行智能硬件產品研發時進行敏捷轉型，當前的結果還是比較令人滿意。

公司沒有專門的人做這個事情，都是業務部門的人兼職做，所以不要給自己設定邊界，認為是一件對的事情，就持續堅持吧！

一、敏捷轉型的目標與關鍵成果

目標

敏捷開發達到業界優秀水平，更快速的響應市場需求。

關鍵成果

1. 可以任意指定用戶群進行特性發布。
2. 每周都可以對外進行特性發布。
3. 各軟件專業發布互不依賴，獨立規劃、獨立發布。
4. 版本規劃、需求、資源、阻塞問題可以高度透明，及時同步。

二、敏捷轉型的困難

敏捷轉型是一項系統性工程，涉及到流程建設、人員培訓、平臺建設、軟件架構優化，所以一家公司要成功的完成敏捷轉型，往往比較困難，極其容易在轉型初期形成敏捷無法有效提升研發效率的錯覺，變得消極，難以突破。而且大家在談論敏捷時，往往更多的談及敏捷在流程上的改造，卻容易忽略其他方面的重要性。

流程建設

流程建設在初期必然會和已有的流程產生一些沖突，如果一上來就全面替換現有的所有流程，必然引起強烈的不適。

更何況，在敏捷轉型初期，我們對敏捷的理解往往還不到位，制定出來的流程往往存在不少缺陷，即使全面替換，也不能保障效率的提升，甚至還會導致效率的下降，打擊大家轉型的積極性。而且流程制定一定要結合企業的特點，不能完全照搬標準定義，這也考驗著我們對敏捷和業務理解的深度。

當我們設定了一個合理的流程后，順利的落地執行依舊是一項挑戰。

忽略人員培訓的重要性

由于在公司轉型初期本身理解敏捷這套方法論的人就不多，往往缺乏培訓人員，或者缺乏明確的培訓責任劃分，導致難以有效培訓。

敏捷里面有一個scrum master的角色，這個角色的工作業績缺少太難以量化，我想很少有公司會設立專職的scrum master，即使我們在這條路上走了三年，依舊沒有這個角色。

另外，要打破我們固有的思維模式和工作習慣是一件比較難和需要持久進行的事情，在轉型期如果沒有明顯的提升，質疑的聲音就會迎面撲來，大家會表達出想用以前的工作方法愿望。

忽略平臺建設

這個道理很簡單，給你一輛拖拉機你永遠都開不到法拉利的速度，不管你把其他方面做得多么極致。但是，當我們進行轉型時，要順利的完成相關的平臺建設，可不是一件容易的事情。

從我們轉型過程來看，我們在第三年才投入相關資源建設相關平臺，雖然我們一直在吐槽平臺難用，效率低。這里主要涉及到以下幾個問題：

1. 業務發展還不夠明朗，不舍得投入資源進行平臺建設。
2. 業務發展過于迅猛，研發資源都投入到了業務開發上。
3. 公司組織架構問題，多部門目標不一致。
4. 缺乏對這件事情明確負責的人，三不管地帶。

所以，如果平臺建設不在業務線范圍內明確其重要性，這件事情基本無法搞定。

軟件架構優化

軟件研發本身就是一件系統性工作，如果軟件架構不合理，開發周期長、bug多、依賴重，同樣很難快起來。

當前的智能硬件產品，往往都涉及非常多的軟件專業，包括服務器、H5、Android、iOS等等，如果系統足夠復雜，前面的幾大專業還會細分出更多的專業。如果每個專業的發布需要依賴其他專業，那么很難快起來。

就像大家都在高速公路上跑，路上出了事故，大家都得慢下來，等出來完事故后，大家又得重新慢慢加速。

在春運期間我們很容易遇到，你發現把堵車的路段開完了也沒有看到事故，可以為什么還是堵車呢，事故處處理完后堵車路段為什么不能迅速疏通呢？

另外一方面，你用H5開發一個功能和用原生應用開發一個功能，發布速度肯定有天壤之別。H5一天發幾十個版本都有可能做到，你用Android原生開發可能做到嗎？

三、流程建設

我們的產品涉及面廣，我們針對產品特點，分出來了多個特性小組，每個特性小組由產品經理主導，作為特性交付的第一負責人，目前已成功運行的機制如下：

1. 特性團隊
2. 產品提案評審
3. 隊列填充會議
4. 晨會機制
5. 交互評審
6. 產品驗收
7. 版本火車發布
8. 灰度與全量發布
9. 大數據分析
10. ……

3.1.確保需求有價值

問題越早發現，帶來的收益就越高。

使用OKR梳理部門年度目標，基于部門年度目標，各專業梳理出自己的年度目標和季度目標，個人基于專業領域的年度和季度目標，梳理自己的季度目標。通過使用OKR這個工具，大家目標上下左右對齊，識別出正確的事情，避免不必要的資源和時間浪費。

產品團隊針對新的特性需求建立提案評審機制，保障新需求的質量，雖然我們無法完成預見需求最終的市場表現，但是至少要做到邏輯上這個需求是靠譜的。特殊情況，一些需求大家很難達成一致，這個時候我們更趨向于允許這個需求進入研發，進行市場驗證。

每周五最后一小時召開固定的隊列填充會議，各領域負責人與產品經理共同確認拉入的需求。避免產品經理的單一視角，導致拉入一些不合理或者沒想清楚的需求。

3.2 確保需求優先級達成一致

資源永遠是不夠的，所有優先級在迭代過程中是必須要保障的事情，否則有可能導致一些重要的事情得不到足夠的資源，或者各領域之間互相扯皮，增加溝通成本。

特性小組要有自主性和獨立性，但是不能完全的獨立和自主，這樣他們很容易站在自己所負責的特性的狹隘視角安排迭代。另外我們要充分認識到不同產品經理的能力是有所不同的，不能完全放權到產品經理，否則很有可能因為產品經理能力的不足，導致一個特性團隊處于混亂中。

建立需求準入審查機制，該機制可以在隊列填充會議上運行，產品經理拉入研發的需求都需要讓各領域知曉，如果發現不合理的需求，可以在該會議上有效控制。

進入研發的需求需要通過交互評審，如果存在文檔，需要附上相關文檔內容。該規定，也可以在隊列填充會議上有效控制。

3.3 確保進入研發的需求有相應的研發資源

停止啟動，聚焦完成，我們迭代過程中一定要控制同時研發的需求量。否則你會發現每件事都在做，然而每件事情都需要很久才能做完。

控制研發看板上的需求數量，就需要控制流進和流出。所以大的原則是沒有需求做完前，不允許拉入需求。當然，如果研發看板本上的需求本來就比較少，或者說增加了研發人員，這里可以靈活控制。

隊列填充會議上給到多個特性小組互相協調資源的契機，也給到各專業負責人了解資源情況的一個契機。通過大家協調和調整資源，確保需求有對應的資源進行研發。

3.4 確保研發過程足夠透明

信息透明是自組織的基礎，足夠的信息透明，才能讓討論和問題處理有完全的參考，才能高效協作和解決問題。

對于大型團隊一定是需要一個電子化工具支持研發信息的透明的，完全靠人是不合適的，這個市面上有相關產品，當然我們是自研的。為什么我們要自研呢？主要是為了保障產品敏感資料的安全性以及更好的適應我們企業的流程。

晨會作為敏捷的一個標志性會議，是一定需要開的。我們能通過這個會議讓特性團隊的凝聚感更強，同時及時同步研發信息和問題，提升研發效率?？梢砸_好晨會也不容易，例如：

1. 存在團隊成員跨團隊的情況，導致你的晨會他不一定能參加。

2. 晨會人員過多，導致場面混亂。

3. 看板泳道設計不合理，導致信息可視性和可流動性差。

版本規劃要明確，我們要有一個電子平臺在里面公示版本信息，包括版本涉及領域、各個客戶端版本號、包含哪些需求、集成時間、發布時間等等。

四、人員培訓

以人為本，不斷多好的流程、多好的工具，參與和使用它的人沒有掌握，都無法有效達成目標。

需要對全員培訓敏捷的相關理論，并為他們答疑解惑，長期輔導。

可以針對《敏捷軟件開發實戰-估算與計劃》《看板方法》這兩本書里面的理論梳理培訓大綱，同時也可以分享這兩本書給到團隊成員閱讀。

當敏捷適配到企業流程后，建立出適合企業的敏捷流程，在這個適配過程中，也需要不斷的給相關團隊成員培訓流程建設的目的和意義。

五、平臺建設

持續集成平臺

軟件的構建當下越來越復雜，類似于Jenkins、GitLab、各種靜態檢測、依賴管理、自動化測試都得做起來，使用以前的原始手段處理當下的軟件系統，效率是非常低的。

發布平臺

智能硬件的軟件發布可以分為多個層級，包括：OTA升級、應用發布與升級、應用內功能開放與關閉、H5發布。為此，我們需要針對這些發布方式，構建相關的后端發布平臺，支持相關業務人員可以簡單、高效、靈活的操作。

研發管理平臺

研發管理包括：版本管理、需求管理、任務管理、bug管理、發布管理等等，缺少這些平臺的支持，都會嚴重影響研發效率。

運營平臺

一個好的功能，還需要讓用戶知道。我們需要通過推送、彈窗等各種手段將運營信息傳達到用戶眼里。因此，也需要提供簡單、高效、靈活的運營平臺。

六、軟件架構優化

這是一個技術話題，大家可以關注當前比較火熱的大前端，各家公司都在想辦法如果通過軟件架構優化提升迭代效率。這里可以大致列舉一下業界的各種技術：

1. 小程序（微信、支付寶）
2. 快應用（各大手機廠商）
3. ReactNative（Facebook）
4. Flutter（Google）
5. 組件化（微信）
6. 插件化（攜程）
7. Weex（淘寶）
8. ……

另外補充一下，上面談及的技術均是客戶端技術，針對服務器的快速發布和部署，業界技術也是層出不窮，例如：微服務、各種運維技術等。

當然，軟件架構優化也不一定要通過上新的框架這么大的動作來改善。這里重點想表達軟件架構優化對敏捷轉型也至關重要。例如僅僅做簡單的代碼重構，降低業務耦合度也是有意義的。

本文由@墨一 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議