首先介紹我所體悟到的敏捷，以及我認為敏捷有點像是一些精神後所延伸創造出的一些產物跟方法，我認為它是用來克服一些問題而想出的思維，也藉由這個思維創造出一些敏捷的開發方式，建立出一些流程給想嘗試敏捷的人做參考。
何謂敏捷
敏捷這兩個字，會讓人很容易聯想到快速，想到快速就會有一種感覺好像整體花的時間就會比較短?，但所花的時間比較短，或許是因為你敏捷的反應而帶出的效果，而不是採用敏捷就一定花的時間就一定會馬上變短!
敏捷我認為他要給的概念是快速反應，希望讓使用這個流程的每個參與者能更快的去發現問題並去採取相對應的Action，因此會看到一些敏捷的週期不會拉的太長，其目的就是希望能在比較短的週期中就能快速地得到成員的回饋，或者是Key stakeholder的回饋，並快速地進行Action的調整
而這個精神的目的，就是不希望大家離最終目標有太多的偏差，透過短一點的週期進行確認，同步修正，讓你的團隊不會頭洗了好一大半，才發現距離目標似乎偏移的太多了，導致要花很多的時間做修正，敏捷讓你更頻繁的sync與回饋，不斷的修正Action甚至是目標，走向團隊一起認知的方向不要害怕失敗，失敗代表你距離成功更近了
這個精神是我延伸所學到的，他是個老掉牙的道理了，但事實上他搭配了敏捷你會發現，你更能讓失敗成為你成功的墊腳石，如果失敗是短期就發現的，那你很快地就可以調整，下次如果又失敗，那就在調整，但如果你的這個失敗，是很難被發現的，要走到快結束才發現，那這個失敗才是可怕的
另外有時候我們會因為，為了要成功，害怕失敗，而限制了自己的action，因為害怕失敗會導致很多方案不敢嘗試，想要一開始就選一個會成功的，但事實上有些事情不可能一開始就能全面評估出來，若真的一開始都完美的評估出作法，那敏捷的精神也不需要了，因為你可以一開始就想好全部，那就照著做就好，假設你一開始的想法就能成功的話
能夠在每次的失敗中有所學習，讓你跟你的團隊都有學習，學習怎麼克服這些難關，讓下次能夠成功，抱持這個學習的精神，就不必太害怕失敗
DevOps將開發串聯，但其實有很多的部分再串連的是人
一開始加入時，我認為我在做的是將整個開發串聯讓他自動化，這麼說其實沒錯，確實工作的項目有一些部份是在處理這些技術上的問題，但到中期我慢慢的發現，原來很重要的一部份是在串聯人，串聯這些團隊運作的方式，工具只是輔助，重要的是協助這個團隊讓團隊更順暢，更敏捷的運行，技術的發展其實就是在協助解決問題，這件事情我在加入了DevOps有更深刻的體悟
指出房間裡的大象
有些大象不見得是一個人能解決，但連指都不肯指出來，怎麼會期望這個問題會被解決?
有時候有些大象大家都會看見，但有的會視而不見，有的裝沒看見，有的是真的沒看見，當然看見未必能處理，但如果有些機制是能讓你在團隊中指出來的，那就鼓起勇氣把他指出來
指出大象的好處
1.可能有辦法被解決
有些問題是你指出後，maybe你的團隊能跟你一起解決，maybe你的老闆可以解決，或者你老闆會帶著問題往上找人解決
2.可能獲得了新的觀點
有些時候是因為看的方向不同，所以你認為這是個大象，但或許你蒐集到了其他成員或老闆的input後，你會對這件事情有更深層、更全面的看見，你的觀點是會改變的，也或者你們會一起想到新的action
3.指出的過程練習開誠布公的勇氣與不咎責或客觀的描述方式
有時候要能開誠布公去指出大象是需要勇氣的，透過這樣的行動，會增加你的勇氣，以及在描述時，練習客觀且不咎責的去講述現在的狀況，這些方法其實是需要一些練習的，且用這樣的方式去描述問題，也比較能讓大家抱著解決問題的態度來去討論問題，而不是在抓戰犯或者在責怪某人。
反省!=責怪，可以讓大家反省一件事情，但它是可以在過程中將責怪排除的，團隊其實需要的是學習下次如何應對，因為過去的它發生了責怪並不會改變，想出新的方式去面對問題才會改變。
沒辦法其實是心態問題
有些時候會覺得，有些問題我職等不夠好像沒辦法，不是我能解決的。
但後來發現，重點還是你想不想有辦法而已，其實如果抱著我職等高一點可能有辦法，事實上這件事也不會存在，因為當你成為公司的CEO時，你還是可以說沒辦法，因為是心態上覺得沒辦法。舉例來說當你成為CEO，業績不好你還是可以說就算我是CEO我也沒辦法，因為經濟環境不好所以我沒辦法。
有些事情確實，是在一個人的關注圈而不在影響圈，所以你可能無法直接改變，這其實沒錯，但你然仍可以指朝著這個目標，去進行你影響圈能做的事情，當然有可能因為影響圈太小，問題並不會馬上被解決，但至少它不是完全沒辦法，至少你做了在你的影響圈能做的事情，而如果你抱著沒辦法的心態，則是連影響圈的行動都完全不做，那才真的會造成好像什麼都沒辦法的現象。
充分溝通，讓認知一致
有些團隊可能大家都很有想法，因此大家可能習慣的發表自己的想法，而給出不同的建議，但有時候會發現怎麼建議或者回復，跟原本的問題好像有點歪樓，因此協助團隊成員確認大家的認知是相同的事件重要的事情。
如果認知不同會出現的壞處其實蠻多的，舉例來說:
1.答非所問
2.有人提出了好像跟原本問題不相關的solution
3.有人糾結在某個點上，而且還糾結在跟原本問題完全不同的事情上
4.大家對最後成功的景象的想像，產生很大差異
以上幾個點大概是有可能在一些會議或一些實際案例可能會發生的狀況，這些都跟大家對同一件事情，但有認知落差而產生的影響，因此協助團隊讓彼此認知在同個水平事件重要的事情，大家的討論才能針對問題做處理。
引用«教練»一書的說法:"即便你覺得你充分表達清楚，也要重複多講幾次，才能讓人真正的明白，重複並不會破壞溝通效果，就像你禱告時會一再講同樣的話一樣"，我認為書中的這個重點，也是在描述讓團隊認知相同的重要性!
以上是我近期加入DevOps所體悟到的一些心得，分享給大家，近期還有看了一些書，以及從身邊的伙伴，主管獲取了一些不同的職場心得，未來有機會在分享給大家，另外也推薦大家可以一些跟教練有關的書籍，或是自我覺察的一些書籍，會發現書中有些方法，是可以運用在工作中與生活中。
艾克森跟你說，這次是以分享的方式就不評分啦，感謝你的閱讀。
