看見全貌

.

專案開始之初，首重看見全貌。

一旦；當你把眼光投注在哪一個要項的時候，實際上你就只看到那一部分，你的思緒將被那一部分的內容所牽動，很難再看見其他的事…

所以我們要退後一步，

不! 有時要退後很多步，才能比較清晰地看見全貌。

(好有趣喔! 退遠了卻反而看得更清晰)

所以要調整範圍，試圖把我們在意的事放進視線可及之處，

淡淡的審視它，不帶一點情緒，就是這樣，我們看見了全貌。

.

※ 開發團隊被抱怨開發速度太慢的案例層出不窮…

軟體影響開發速度的因素

其實當你努力的去改善開發環境還有程式，祈求開發速度能夠跟上需求時，其實；還不如從提升需求的「業務價值」來著手改進會快上很多，請參考"需求分析的設計模式“一文。

.

一旦你看見全貌之後，要怎麼做呢? 

演講內容:  DevOps 教战守策：三步工作法 ，內容 PPT 的全貌( XPS展示)

首先；把它畫下來。畫下來不論對自己或閱讀的人都是一種極具價值的事。（上面81張slides的內容如下圖）

.

將演講內容整理成 圖示 (演講: DevOps 教战守策：三步工作法 )

畫出來；可以具像化(產生 Avatar)的整理出資料的脈絡，告訴學員運用圖示來回憶上課的內容，當遇到有疑惑的地方時再去細看 PPT的內容會效果會更好。

.

整理出來的心得

.

請思考你的「退後一步」是什麼?

.

運用工具來協助你看見全貌

系統思維（麻省理工Jay Wright Forrester先生的 System Thinking)能夠協助你以CLD圖式較抽像的方式看見全貌。坊間流行的影響地圖（impact mapping, by: Gojko Adzic ）是用來尋找影響路徑，還有著名的是用戶故事地圖（user story mapping， by: Jeff Pattorn 用來記錄陳列需求)則都是用來記錄分析需求的有用工具，但基本上還是屬基於以客戶為導向的開發工具, 這二者還是離不開描述個別客戶的情境示意圖，對看見全貌而言反到狹窄了視野，它記錄的是專案運行下的各個需求分類，已經自我設限而失去了真正的全貌，反倒能夠協助收斂思維便利施工作業，而非全貌探索。

.

註:

• 拉遠原則 (Pulling principle) 

就是在更大的範圍內觀察事物。我們可以試著將一個產品放置在更大的背景環境中去考慮，這樣可以避免見樹不見林的現象。(例如: 坊間一些書籍的試讀軟體，就有這種效果。) 雖然我們這麼去觀察，但還是只看到它的外觀，好的作品，設計者的品味(taste) 卻還是能隱然呈現，尤其是那些優秀的產品。至於內涵的部分，就需要細細的去品味了。

.

精實原則: 著眼整體 See the Whole

一個系統的好壞不是由單一組件來決定的，也不是各部分的總和，還要加上各部分相互的協作能力。

 Mary & Tom Poppendieck

這一段話把它拿來描述由人所組成的開發團隊也十分適用，一個產能好的開發團隊需要的不是幾個出色的工程師而已，團隊的協作能力也是效能的一大因素。

局部優化易造成捨本逐末

開發團隊需要著重全局, 要避免局部優化.這裡所謂的「局部優化」所指的是單位與單位之間或公司與公司之間協作開發時，會刻意誇大自己在合作事件上的重要性，這種做法會讓自己做的那一部分增加被重視的比例，而失去擬聚整個系統的重要性。 當然；這種想法也適用在開發團隊上，大家都去強調自己開發的這部分的重要性，也一樣會造成局部性能的受重視，而失去兼顧全體的性能。運用在個人身上: 如果人們在開發一個系統的時候，處處都優先考慮自己的專業興趣，而忽略了整體性的考量，則產品就會出現局部優化，而共同利益就會受到損害。在開發上過度注意細節、在考績或合約的執行上也都可能會局部優化，茲描述如下:

※ 因為過度注意細節就容易產生局部優化

運用連續目標來修正短視可能是最有效的方式。為團隊制定一系列的目標，可以讓團隊不會過度注重於細節，能夠自動克服這種容易讓人不能自拔的陷阱。舉例說明: 行動裝置UI 顯示的重要性是不容忽視的，當大家對顯示畫面都有意見的時候(人的審美觀是很難一致的)，團隊就很容易落入一改再改的現象而耽誤了時程，如果能緊守目標，讓網頁真正要表達的意圖，能夠明確的傳達給使用者，目地就可以算達成了，也就不會因為局部因素耽擱時程了。在敏捷迭代的開發採取的方式是，讓細節被短的循環所約束。每一個迭代之間以達成既定目標為前提，就不怕過於注重細節而產生局部優化的現象了。運用目標來驅動實做可以避免過於關心細節而造成局部優化的問題。

※ 因為考績的因素就容易產生局部優化

2014 年日本Sony 企業的巨大虧損，該公司宣稱是因為不正確的考績方式所造成的。而這已經不是第一起因為考績的方式而引導企業失去競爭力的公司了(外傳微軟總裁 鮑默爾也是因為不正確的考績方式導致微軟戰力下滑)。管理學上著名的霍桑效應(Hawthorne Effect)，它是指由於受到額外的關注而引起努力或績效上升的情況。正好可以說明員工因為考績的評估方式，造成員工為了求得好的考績，而刻意去做有利於考績卻無助於生產力的工作。

※ 因為合約的因素就容易產生局部優化

簽約的目的是保證一方能夠相信另一方會履行合約的內容。簽約的方式可能是固定價格的合約、可能是多階段的合約或是目標成本的合約，但考量只有一個就是要交付完整的產品。其實客戶需要的不是軟體，他們要的是解決他們的問題。但合約的內容將牽引著雙方走向合約上可以確認的項目去做開發作業。在專案的時程結束的時候，客戶會得到合約上驗收項目的組合，而不是一個完整的，用來解決他們問題的系統軟體。這就是跟著合約走的問題，到最後你只會依據驗收的項目去兜起來完成你的專案。完成的部分就只有驗收項目的部分，合約會帶領著你局部去優化軟體。那敏捷又能如何處理合約呢?

敏捷合約；當客戶嘗試過第一次與敏捷開發團隊的合同之後，在下一次簽約時，對簽約的內容就變得不是那麼在意了。真正重要的是如何把需求描述的完整。為什麼?

因為我們把開發作業切分成一個個的小周期，而每一個周期的產出客戶都看的見，而且還可以就展示的結果回饋意見，讓產品適當的加入真正需要的功能或者是變更設計。而用來配合一個一個迭代開發的是將需求(Product Backlog)給予優先級別。讓需求有優先級別?

※ 讓需求有優先級別，徹底瓦解局部優化

很多正在學習SCRUM的人士，都容易忽略了讓需求有優先級別的重要性。因為將這些需求累積起來一個一個做下去，每每做完一些需求客戶就可以看到做完的結果，滿意就繼續做下去，不滿意就變更需求。這樣做下去的結果你應該已經預期到了，那就是；在你還沒來得及把需求全部做完，客戶大概已經急著要求先上線了。因為你已經解決了他的問題了!