# 打開DevOps的后門：成為卓越的管理者 - 李智樺（Ruddy）
###### tags: `DevOpsDays Taipei 2019`

{%hackmd B44mr9JvRMSCm5gVjQMNXA %}

devops 本來是很簡單的東西，但是我們現在一直在加東西進去，讓 devops 變成 end-to-end ，讓整個 devops 變的越來越複雜

應該要回歸，從最簡單的開始

一定要把 dev 的看板與 ops 的看板結合在一起成為一個看板，才是 devops

無序的，混沌的，你什麼都不要動，他自己會壞掉

在有序的時候 制定SOP是有用的

在敏捷的世界裡，也是要求要進化。

突如其來的事件或Bug先用短解，但一定要進行長期解決方案

先看到問題在使用design pattern 而不是先學design pattern再硬去解決問題

都對 也都不對 有一些有用就好

([source](https://www.gp-training.net/training/communication_skills/consultation/equipoise/complexity/stacey.htm))

開始的時候 從混亂到非常複雜 才會逐漸變成簡單

心態是個人的作業系統 DevOps 重點是在心態 決定行為

專案開始時最重要的事情，是看見全貌，弄清楚問題，實際上要看情境來調整方式(不要瘋狂的用Scrum、DevOps、開發)，用對的合適的方式來進行專案

>團隊 devops 效能 = 能力 + 經驗 - 干擾 （干擾是最大的問題）

挑最糟糕的團隊做最難的專案 (因為是示範的專案，所以不會受到干擾，干擾是最大的因素，沒有干擾什麼事都做得好)

> 團隊只有不受干擾才是最佳的
>
10/17讓團隊不受干饒但主管受到很多干擾，該怎麼辦？

> 管理者只有在反思的時候才學習

"==察覺=="是有才能的人與一般人的差別?

工程師什麼時候，才會主動加班，是有“==熱誠==”的時候

熱情是會消退的, 所以會需要責任感來支撐.

主管要==always== 出現在工程師的面前. 解決問題.

> （熱情＋信念＋專注） ＝＝＝ 績效

怎樣的心態 才能解決重複犯錯 (反省 反思)



工程師應該時常的尋求回饋，要能有察覺 awareness

Code Review在程式行數較少時執行效率更佳,建議不要在最後整個程式完成後再執行

心態是敏捷性的重點

信任責任模型([source](https://ruddyblog.wordpress.com/2019/02/10/%E4%BF%A1%E4%BB%BB%E8%88%87%E8%B2%AC%E4%BB%BB%E6%A8%A1%E5%9E%8B/)）

敏捷教練離開後會不會讓團隊敏捷度倒退，取決於主管。主管的敏捷性是key point

情境領導:
(https://www.bnext.com.tw/article/24619/BN-ARTICLE-24619)

面對不同屬性的員工, 要懂得採用相對應的管理方式

推薦書籍：
管理3.0培養和提升敏捷領導力: Martie 模型、敏捷管理
* 主管要hold的住團隊
* 當團隊表現非常優秀，主管要分清楚是加班還是激發了更多的潛能造成的

第五項修練：心智模式的誤區

專業引導技巧 : 主管心態

怎樣讓團隊沒有干擾，才是真正產生績效的地方
# 打開DevOps的后門：成為卓越的管理者 - 李智樺（Ruddy）
###### tags: `DevOpsDays Taipei 2019`

{%hackmd B44mr9JvRMSCm5gVjQMNXA %}

devops 本來是很簡單的東西，但是我們現在一直在加東西進去，讓 devops 變成 end-to-end ，讓整個 devops 變的越來越複雜

應該要回歸，從最簡單的開始

一定要把 dev 的看板與 ops 的看板結合在一起成為一個看板，才是 devops

無序的，混沌的，你什麼都不要動，他自己會壞掉

在有序的時候 制定SOP是有用的

在敏捷的世界裡，也是要求要進化。

突如其來的事件或Bug先用短解，但一定要進行長期解決方案

先看到問題在使用design pattern 而不是先學design pattern再硬去解決問題

都對 也都不對 有一些有用就好

([source](https://www.gp-training.net/training/communication_skills/consultation/equipoise/complexity/stacey.htm))

開始的時候 從混亂到非常複雜 才會逐漸變成簡單

心態是個人的作業系統 DevOps 重點是在心態 決定行為

專案開始時最重要的事情，是看見全貌，弄清楚問題，實際上要看情境來調整方式(不要瘋狂的用Scrum、DevOps、開發)，用對的合適的方式來進行專案

>團隊 devops 效能 = 能力 + 經驗 - 干擾 （干擾是最大的問題）

挑最糟糕的團隊做最難的專案 (因為是示範的專案，所以不會受到干擾，干擾是最大的因素，沒有干擾什麼事都做得好)

> 團隊只有不受干擾才是最佳的
>

> 管理者只有在反思的時候才學習

察覺是有才能的人與一般人的差別?

工程師什麼時候，才會主動加班，是有“==熱誠==”的時候

熱情是會消退的, 所以會需要責任感來支撐.

主管要==always== 出現在工程師的面前. 解決問題.

> （熱情＋信念＋專注） ＝＝＝ 績效

怎樣的心態 才能解決重複犯錯 (反省 反思)



工程師應該時常的尋求回饋，要能有察覺 awareness

Code Review在程式行數較少時執行效率更佳,建議不要在最後整個程式完成後再執行

心態是敏捷性的重點

信任責任模型([source](https://ruddyblog.wordpress.com/2019/02/10/%E4%BF%A1%E4%BB%BB%E8%88%87%E8%B2%AC%E4%BB%BB%E6%A8%A1%E5%9E%8B/)）

敏捷教練離開後會不會讓團隊敏捷度倒退，取決於主管。主管的敏捷性是key point

情境領導:
(https://www.bnext.com.tw/article/24619/BN-ARTICLE-24619)

面對不同屬性的員工, 要懂得採用相對應的管理方式

推薦書籍：
管理3.0培養和提升敏捷領導力: Martie 模型、敏捷管理
* 主管要hold的住團隊
* 當團隊表現非常優秀，主管要分清楚是加班還是激發了更多的潛能造成的

第五項修練：心智模式的誤區

專業引導技巧 : 主管心態

怎樣讓團隊沒有干擾，才是真正產生績效的地方

(專家面對面) 有時候要讓團隊經歷失敗 挫折，才會增加向心力。