Please enable JavaScript.
Coggle requires JavaScript to display documents.
CPM (現況 (對策 - 每個人都能自由修改 (流程改善 - 如何確保改善方案可以融入平日的開發/測試流程之中 (Kown issue…
CPM (
現況 (
對策 - 每個人都能自由修改 ,
RD不曉得劇本,
Kown issue 可以檢視，看看哪些可以適時優化，不然kown issue累積下來會很多,
文档应该可测试化,
文件過多/操作不易,
Jenkins維護經常性遭忽略 (沒作用 不如就停止使用 or 轉到RTC)+1因為build失敗原因需要花時間需要查找，但是優先級沒有那麼高,
人力資源不足,
Unit Test無法落實+3 代碼可測，可維護會加強,
Scrum運作不順暢,
CPM做為讓solution快速開發的平台(ex: IBM IoT)，還欠缺部份功能，先有雛型再追求優化,
QA經常問什麼是預期結果，或測試場景定義,
外部人員對CPM沒信心，打擊開發人員自信(批評是阻力 or 動力，在大家一念之間)，CPM差，比CPM好的東西又有多少？,
現在CPM應沒有架構問題，但有優化問題,
Config 過多、複雜: 啟動service(EP, DM), Handler,
同時進行的戰線過多,
GUI人力缺乏 + 2 #,
Demo的Feedback沒有達到預期的效果，沒有把設計盲點Highline出來,
分成兩個Group，Demo後還需要整合,
有為了Demo而Demo的現象),
客戶 - 了解客戶「真正」的需求，這通常不是他們口頭上所說的+1,
有活力的團隊-一個能完成/解決PM提出的需求/問題的團隊特質,
績效管理 (
Team之間的競合,
個人的表現,
DRC的進度要求,
BUBG對CPM的需求越來越多(哪組有需求?SIDB, ESBD,... 問June, 目前有人在用2.0.x?，若非政治因素，有人想用?)),
產品 - 如何設定產品及，同時滿足客戶/開發團隊/測試團隊「真正」的需求,
採用模型 (
物理學：量變產生質變 - 臨界點,
第五項修煉：系統思考, 系統動力學，正回授/負回授),
確定採用的對策 - 經過討論過後的決定,
透過系統思考，我們可以做哪些改變，讓我們團隊成為「有活力的團隊」？,
這張圖解析度太低了，看不到
圖片分辨率過低，貼link上來，文章第二節中的圖片)