.NET Walker

這是一篇欠了很久的文章。不寫，是因為我覺得這主題要寫的好著實不容易，但偏偏『溝通』這件事情，是專案管理當中非常重要的一環，也是工程師想要蛻變或升級的一個必學功課。(因此這一篇讀起來要有點耐心) 在溝通這件事情上，身為開發人員或PM的你，理論上應該要非常有經驗。從專案一開始(甚至說還沒開始)『溝通』就持續在發生。在presale介紹產品時，在SA洽談規格時，在UAT面對客戶的挑剔時，在專案延遲面對客戶的責難時... 你肯定會發現，需要『溝通力』的場合真是無所不在。 既然需要溝通的場合天天發生，那表示，大部分的PM或工程師，都能夠順利的做好『溝通』這件事嗎? 完全沒有，甚至可以說，大部分的專案都是敗在溝通上面的。特別是工程背景的技術人員，在面對溝通上，總是常常犯著有形無形的錯，卻始終不自知。然而，這是個性和訓練背景的不同使然，可能真的是非戰之罪。 但只要有機會，工程師必須調整自己，才能夠往另一個層次的方向邁進。 備註：上面所說的，正好就是資深技術人員不一定能夠成為好的PM的原因，雖然我自己找的PM，都堅持必須要有技術背景，但我也非常清楚，對於有技術背景的專業人員，由於受的訓練與思考模式的不同，其實相當不容易跳過這個gap。 接著，我們就來談談溝通這件事情。 首先，你第一個你必須注意的事情是， 溝通是一件需要花時間的工作 。大多數的工程師喜歡思考、也喜歡動手、甚至喜歡談技術，但不喜歡說話，特別是不喜歡耐心的聽別人說話。 『不喜歡耐心的聽別人說話』，是溝通的第一個致命傷。(你認為自己算是很有耐心? 或覺得這應該是個容易克服的問題? 請先往下看再說...) 你必須知道一件事情(這是一個心態的調整)，所謂的溝通，並非是想盡辦法(透過技術或是專業)說服對方，而是給對方一個說服自己的機會。意思是，當你想要和對方溝通，如果你的潛在目的是只想讓對方照你的意思做，那不叫溝通，基本上那就是談判(或是說服)。 溝通是，你必須抽離自己的角色和立場，從一個第三者的角度來看，你自己所在意的，和對方所在意的，兩者之間有多大的距離，為了讓雙方都滿意，該如何找出具有創造性的第三選擇，而非只執著在自己要的結果或對方想要的結果上面。(想深入了解這個概念，可以參考柯維的『第三選擇』一書) 柯維在 『 第三選擇 』 中說：「溝通中的傾聽是你讓對方充分表達並且了解

最近在新聞上，又有政治人物談起一個有些古老的議題，也就是OO共識。不過一直以來，這個名詞總給人一種虛無飄渺的感覺。有人說OO共識根本不存在，有人說確有這個共識，但實質內容為何? 也不一定人人都可以說的上來… 這種國家大事，可能不是身為市井小民的我們，能夠深入剖析和探討的，但有一個極為類似的問題，則是我們在進行專案管理中，時常發生的狀況。也就是『規格的刻意模糊化』。 很多專案團隊，在驗收時碰到爭議，很大比例的原因，是因為規格不清，或是規格的認知有所差距。我們最常聽到的例子，就是客戶指著規格書中的某一條說：『OO功能 當然 是包含在這條規格裡面的，現在怎麼沒有呢?』或是：『這個機制怎麼可能沒有XX功能? 這 想當然 應該要有的啊，不然怎麼用呢?』從客戶的角度來說，這些OO和XX，本來就是系統該出現的內容， 但對於專案團隊來說，這則是規格書中所沒有的『規格外』的『需求變更』 ，為何兩者之間會有那麼大的落差? 其中一個最主要的原因是，當時談規格的時候『沒談清楚』。但，為什麼會沒談清楚呢? 可能是時間不夠，可能是系統分析師素養不足，也可能是甲乙雙方溝通或表達能力不好，但這些不是我想談的問題(因為以上原因都可以透過訓練來改善)，我想談的是另一個看似不該存在，但卻十分常見的原因，就是…甲乙雙方刻意讓規格保持模糊。 這種情況你或許以為不該發生，但實際上卻是最常發生的狀況。 雙方PM為何要刻意讓規格模糊? 理由很簡單，因為雙方都想成案。而模糊化的規格書，最有助於成案(是了，因為可以各自解讀)。有時候靠著一兩張A4的SOW工作範圍說明書，PM和Sale就想把價格和時程談下來，甲方PM可能經歷了漫長的選商和詢價，早已面對(答應上頭老闆)的時程壓力，而乙方Sale正好業績缺的緊，雙方一看對眼，你情我願之下，交易立刻談定，PO馬上開出，接下來的後面一個月皆大歡喜。 甲方PM開始熱鬧的安排Kick-off，乙方Sale本季績效達成，乙方PM接到燙手山芋其實也不太擔心，反正kick-off之後還有半年時間，年底才要驗收。有時候乙方Sale甚至會給PM(人情)壓力，PM也知道規格不清楚會有風險，但不接案難道喝西北風嗎? 先前已經推掉兩三個案子了，總不能Sale拉進來的每個案子都被自己擋掉吧? 如此這般，在沒有詳細規格之前，Deal就談定了。至於工作範圍，人力預估…等

再上一篇我們談過了Task的建立之後，接著，我們來看看延伸出的圖表。 在VS Online當中，有兩個比較關鍵的圖表，是與工作進度有關的。一個是先前提過的燃盡圖(BurnDown Chart)，另一個則是累計流量圖(Cumulative Flow Diagram)。 由於我們先前看過了燃盡圖，因此我們先來看一下累計流量圖。 累計流量圖(Cumulative Flow Diagram) 累計流量圖主要呈現出專案中每一個Backlog在時間軸上狀態的變化，外觀大致讓如下： 你會看到圖表右邊的四種狀態分別是New、Approved、Committed、與Done。如果你還記得，這四個狀態是Backlog的狀態，可以從Backlog的維護畫面中設定： 但更多的時候，其實我們比較喜歡在Backlog的看板(Board)當中用拖曳的方式來設置(改變)狀態： 一般來說，我讓PO/Scrum Master建立Backlog(剛建立的Backlog狀態為New)，但我只讓PO把Backlog從New改為Approved ，一但開發完成，Tester/QA測試無誤，則讓Scrum Master將該Backlog從Approved狀態改為Committed ，PO(或客戶)驗證無誤後，則由PO將Backlog從Committed改為done。 而你看到的累計流量圖，則是這個狀態在時間軸上的變化狀況。也就是說，從圖上看起來，如果綠色的done面積佔有的比例越來越大，則表示這個專案逐漸完成，反之如果灰色的New佔有的範圍越來越大，則表示這個專案的新需求持續增加。 從累計流量圖當中，很容易可以看出整個專案的健康程度，以及完成的比例。 燃盡圖(BurnDown Chart) 燃盡圖我們在前面討論『剩餘時數 與 燃盡圖』討論過，從燃盡圖上我們可以看到在Sprint中所有工作項目(Tasks)的完成度。 某種程度上來說，燃盡圖用以表現出特定Sprint的剩餘工作量(藉此預估是否能夠如期完成)，而累計流量圖則可以看出整個專案的整體工作進度(也包含了新需求的成長速度)。 透過這兩張圖表，PO或Scrum Master、Stakeholders可以很清楚的知道整個專案的健康狀況，也能夠反映出專案能夠準時完成的可能性。在管理上是相當好用的

Task的建立與撰寫 Task 是 backlog 的子階，一般來說，我讓 PO 來建立 Backlog ，由 Team Member 或 Scrum Master 來展開 Backlog 建立 Task 。 Backlog 代表著是要待完成的功能 ( 任務 ) ，而 Task 則是具體展出來的開發工作。 Backlog 多半沒有技術的用詞，最好的寫法是以非技術的 term 來撰寫 ( 讓 stakeholders 也能看懂 ) ，而 Task 則是該功能 ( 任務 ) 的拆解開來的具體工作了，所以有一些技術的 term 並無不可。 將 PO 所撰寫好的 Backlogs 展開 ( 或拆解 ) 成 tasks ，是在 Scrum 的 Planning Meeting 中發生的， 所以一開始專案 Kick-off 前後，可能根本只有 Backlogs 而沒有 tasks 。   還記得嗎 ? Backlogs 中有一個 effort 欄位，寫的是預估時間。 在台灣，專案成案前，往往必須告訴客戶預估金額和時間，但 Tasks 都還沒有展開，能算出 100% 準確的預估時間嗎 ? 我不認為可能。依照 Backlogs 所估出的時程也僅僅為估算而已。專案團隊最好不要讓 PO 或 Sales 以為這是時程上的『承諾』。 而真正到了專案開始進行，把 Backlogs 展成 Tasks 之後， PO 和 team 才會慢慢了解 ( 認清 ) 專案的真相，一些被隱藏的工時才會慢慢出現，特別是 3-5 個 Sprint 之後，就可以清楚的知道自己的預估是否準確，從而進行修正。 也因此，落實到合約的簽訂，如果可以，最好在總時程和總金額尚保留一點空間。 ( 我承認在台灣很難 ) 在操作的實務上， Sale 依舊可以依照過去的報價方式 ( 把預估膨脹個幾倍 ) 來報價，但對於 PO 、 Scrum Master 、 Team( 甚至客戶 ) 來說，在運行 Scrum 之後，專案的透明度無疑地提高了。 ( 關於專案報價與成案問題，可以參考 飛機上的 27A - 談敏捷開發的成案問題 ) 如何 建立Task 在 Work 分類項目下，你可以看到 Backlog Items ，請留意當滑鼠移動到下圖 Bac

前幾天，China RD Team有一個PM說，想找我問個Scrum相關問題。 內容大概是這樣的，PM問我有沒有什麼好的方法來管理Bug? 沒頭沒尾，我當然反問他：『Visual Studio Online不夠好嗎?』他只說：『覺得太浪費時間了?』我只好問：『怎麼說呢?』 大概的狀況如下: Tester測試後把bug列上了TFS，變成work item，接著就擱在那裏了。首先，這個bug沒有owner，這問題好解，如果很嚴重只需要在team room或是日常溝通或deily scrum時，讓PM/PO/SM把bug指派給特定developer即可，如果不急，最遲最遲Planning Meeting或retrospective meeting做都行。這沒問題，接著，變成developer解完bug後，這個bug就擱在那裏了，tester不會(也不想)去再次驗證，或是tester常常覺得developer改的不是他說的bug，不然就是developer不理解tester所謂的bug是什麼意思??? 劇情到這裡就很玄了，我開始有點聽不懂。 我只好問：『developer和tester都是自己人吧? 在同一間辦公室嗎? 』 PM回答：『他們坐在附近。』 我問：『那，他們都不溝通的嗎?』 PM說：『溝通太浪費時間了!』 我追問：『那它們怎麼確認bug的細節呢?』 PM：『就是寫在TFS上啊』 我：『寫bug description? 包含重現的步驟? 包含測試時採用的帳號? 還有操作的順序? 還有... 』 PM：『沒有，就寫一行，幾個字這樣...』 我：『...』 我只能說，這是素養的問題，這跟Scrum無關。 首先，並不代表你run了Scrum，原本專案中的問題就會消失，頂多大家職責開始變得清楚了，是誰的責任，會比以前更清晰。再說，Scrum讓團隊變得敏捷，但團隊成員中，程度好、程度差並不會因為這樣就有所改變。你還是得去面對以前碰到的問題。包含管理問題。 前面提到的狀況，是軟體開發中很典型的常見狀況。developer和tester之間的溝通障礙，本來，scrum就不鼓勵用文件來溝通，文件頂多是用來記錄，而溝通這種事情，最好是面對面進行的。而PM/PO卻覺得面對面溝通沒有效率，所以希望用文件來取代面對面溝通。(這是真的，

前陣子在上架構與框架設計的課程時候，提到幾件事情。我說... 要設計出好的架構不難，但真正能夠實施(implement)在團隊中的卻很不容易。 架構設計是一種取捨，沒有絕對完美的做法，有得，就有失，架構師除了要有足夠的技術能力，更重要的是，要有足夠的溝通能力。 架構設計只有一件事情最重要，就是能夠實施(implement)，無法實施的架構，再美也是枉然。(不能實施的因素有很多，除了設計的好壞，更多的時候是架構師是否能夠同理開發人員技術程度，以及能否在導入時突顯這個設計的優點) 架構與框架的設計與導入，不僅僅是建構開發團隊的基礎，更是一種引導或限制，讓開發人員被框在某一個規範中，在有限制的狀況下自由發揮(我甚至補充，在軟體開發和專案管理的世界中，過度的自由是一種罪惡) 。 我無法在有限的課程時間中，解釋某些事情。因此，趁著有空且記憶猶新，我想來談談我們過去一兩年做的架構設計，以及為何我要求台灣和China幾個團隊中，所有的成員(PO/PM, SD/SM, Developers)都必須採用這樣的架構。 =================================== 先講講背景... 最近這幾年，我們在Web開發上揚棄了從服務器端產生HTML的方式，而改採接近SPA(Single Page Application)的model來進行專案開發，也因此，整個ASP.NET MVC，嚴格說起來，我們只有用WebAPI，其他的部分都是透過我們自己開發的框架(Framework)來搭配與運行。 簡單的架構圖如下：   在這個架構底下，Framework 本身負責 Services Layer(中間橘色的那塊)、Client 端對服務器端 Server Components 的調用(呼叫)、以及 Cross-Cutting Components(左方豎著的那塊)。 採用此Framework 架構的開發人員，只focus 在底下2個部份的開發，而將其他部分交由這個Framework 處理，分別是： Server Components 開發   Server Components 以.NET Assembly(.dll)的形式開發，開發人員可以建立標準 的.NET 4.5.x Class Library，透過引入 Frame

先前我們在 這一篇 當中，曾經介紹過如何從Features展開Backlogs，但也有非常多的狀況是直接產生(建立)Backlogs，這時候我們就有可能需要重新連結(對應)Backlogs與Feature之間的關係。在這一篇當中，我們來看看這個部分。   前面說過，你可以從Features展出Backlogs，這部分實際上操作時很簡單，你只需要在Features畫面中，依照底下的方式，就可以透過『+』從Features以展開的方式來撰寫Backlogs了。   但如果你的Backlogs是獨立寫好的，或是先寫了Backlogs，後來想要讓它歸屬於某一個Features，或是調整Backlogs的Features，可以怎麼做呢?請參考下圖： 你可以先把Backlogs與Features的Mapping打開，即可拖曳特定Backlog到特定的Feature身上，以建立(或修改)兩者之間的關係。 此外，如果你觀察Product Backlogs的輸入畫面，會看到畫面右上部分，有一個forcase，可將其設為On，接著，會出現一個Forecasting Velocity讓你輸入調整（每個Sprint的工作量），設定後，即可看到如下圖的預估： 你會發現，系統已經參考了我們輸入的參考工作量，依照Backlogs的順序，計算出會大致落在哪一個Sprint ，這個功能非常的好用，能夠讓客戶一目了然的知道特定的Backlogs大約會何時開始開發。 但請留意一下這張圖，坦白說這張圖乍看之下不是很容易理解，所以我特別用藍底白字的箭頭，標註了一下Sprint。你會發現，編號1,2,3這三個Backlogs，是屬於Sprint 6進行開發的，而編號6,7,8,9則是屬於Sprint 8進行開發的。特別標註是因為，如果你把藍底白字的箭頭拿掉，你可能會以為編號3,4兩個backlog items是屬於Sprint 6，而編號5,6,7,8的backlog items是屬於Sprint 7，那可就誤會大了。 本篇收錄自 - 『 敏捷開發專案管理與架構設計實務 』

http://www.microsoft.com/taiwan/events/azure-enterprise/   在這個場次的研討會中，再一次地跟大家分享，透過VSOnline與Scrum如何讓團隊在專案管理與ALM上有個好的開始。由於時間比較長，因此這回比較完整的介紹了從kick-off開始之後，我們的專案團隊如何透過VS Online處理專案(或產品)開發的每一個Sprint，錯過的朋友，明年應該還有機會喔。   

每一個Backlog都有可能因著PO或Team Member的調整，而改變了狀態或內容，這個改變可能來自於團隊成員，也可能是擁有權限的任何人。但你不需要擔心，work item的每一個調整，哪怕只是上傳了一個檔案，或是在description中增加或減少了一個字，你都可以透過History看的一清二楚，因此不僅不用擔心被異動，也不會有資料經過修改後遺失了的問題。 要看到Backlog的History，可以開啟Backlog，接著點選 History：       進入到History之後，你可以更清楚的看到，該Backlog狀態的改變、以及Backlog的所有異動： Backlog和專案中的每一個工作項目(不管是Task/Features/Bugs…etc)都是開發團隊相當關注的部分。也因此，每當這些Work Items有異動的時候，老闆們(或是PO)可能都會想要知道。 因此，VS Online除了讓你可以從Backlogs/Task的History中看到變更之外，還可以透過訂閱的方式，來隨時掌握這些Work Items的異動。 你可以進入Project的首頁，在右上方有個『工具』的圖示： 點選該圖示後，會進入到管理畫面(請留意，必須具有管理權限才可以進入)。進入後請按下Alerts頁標籤，接著會看到底下畫面: 你可以從左方的選單處看到該專案所有的Alert，而右半部則可讓你建立或修改Alert。 當你點選New來新增Alert之後，會看到底下視窗：   你可以選擇Alert的範圍和類型，按下OK後即可新增。在底下的新增畫面中你可以看的出來，是依照剛才選擇的Alert範圍和類型所建立的。當然您也可以自行客製化調整，增加判斷條件，或是這個通知的發送對象。   按下OK鈕之後，這個Alert就建立好了，也同時間生效。此後，一旦Work Item有所變更，訂閱者將會收到類似底下這樣的email:   對於開發團隊來說，是相當好用的機制。   本篇收錄自 - 『 敏捷開發專案管理與架構設計實務 』

在實務上，專案可以不寫Features，但不可能跳過Backlogs。 由於蒐集好Features之後，基本上Features只是客戶的Wish List，談不上是什麼規格，基本上只是針對系統需求的期待而已。因此，我們會讓PO稍微排一下優先順序(當然是參考客戶的意見)，接著，開始把Features展開成為Backlogs。實務上，你也可以把Features視為Backlogs的大項分類。如果系統不是很大，那只寫Backlogs不寫Features(或是用後面會提到的階層式Backlogs取代Features)也並無不可。 如果參考微軟MSDN網站上的翻譯，微軟把Backlogs稱為『待處理項目 』，類型上還分為三種。 不過我倒是覺得，我們可以從比較扼要的角度來看Backlogs(簡化可以降低工具和開發方法導入的困難度)。 在這邊，我們先簡單定義一下。我們將一開始建立好尚未放入Sprint中)的Backlogs，統稱之為Product Backlogs，至於進入Sprint之後，被放入特定Sprint中的Backlogs，我們稱之為Sprint Backlogs。因此，剛寫好的Backlogs，全都是Product Backlogs。 至於何時要將Product Backlogs放入特定Sprint(成為Sprint Backlogs)? 則是Planning Meeting要決定的事情了。(會在後面Planning Meeting中介紹) 此外，剛才前面有提到過，多個backlogs之間，也是可以有階層關係的，例如:   這個階層也可以視為Backlogs的分類，有點像是Features的意味。   Backlogs 的來源其實有很多種可能性，原則上大多是從 Features( 或是上一層的 Backlog) 展開，或是直接從系統分析後的規格書謄過來。   ===================================== 備註：         這邊要做一些說明，一般來說，我並不會希望團隊在run scrum的過程中，額外多一個撰寫系統分析說明書這一段。因此，我們一般是直接針對end-user做系統需求訪談，訪談時直接開著VS Online，立即把Features或Backlogs敲到系統裡面，最好不

這是一篇我很早就想寫的文章。 我常常把標題列著，放在Blog的文章清單裡，但放著放著，半年就過去了，可能只是因為我一直找不到好的例子，把我想解釋的想法或概念，有條理地跟大家分享。這一篇，就是最典型的狀況。 我一放，就放了半年。直到今天和Team Member剛好討論起相關的議題，才讓我重新把這篇整理出來。 想說的很多，但題目卻很簡單，就是『專人專用』。 自己做專案很多年，不僅接觸過很多公司，也接觸很多接案的外包的單位。我可以說，幾乎沒有任何一個開發團隊，團隊中負責Coding的開發人員，是100%的專人專用。幾乎每一個所謂的『團隊』，開發成員身上都是兼著2-3個案子。也就是說，絕大部分的開發團隊成員，身上都不只一個案子。如果是PM，那就更慘，大多數的PM肯定都身兼多個案子。這還不包含不需要談規格和需求的維護案。 其實對我來說，這是一件很弔詭的事情。但，在這業界似乎卻是常態。 年輕時，不只一次，我曾在專案裡要求我的team member是100%投入，不得兼任其他案子的任何角色，然而，過去幾乎每一家公司的老闆，都曾跟我說過：不可能。 不管我擔任甲方或乙方，這種結果幾乎如宿命般的相同：就是開發人員『總是』身兼多職，同時也身兼多案。在比較具有規模的接案團隊中，『搶資源』有時候還變成某些PM的強項咧。 但有趣的是，任何腦袋清楚的Developer，都會告訴你，只要身兼兩三個案子後，自己的工作效率就會開始變糟、程式碼的bug數也開始變多。事實上最理想的狀況，其實是讓Developer同一個時間，只參與一個案子。但任何老闆都會跟你說：我知道，我也希望這樣，但這是理想狀況，現在實際上....(後面的就不用多說了) (我甚至聽過有公司應徵developer的時候，其中的問題是...你的『抗壓性』如何? 你可不可以身兼多案? 能不能在專案中快速的轉換? 碰到這種公司，我勸Developer好自為之。) 因此，只消幾年業界經驗之後，Developer就知道，這是一個不用抗爭的事情，幾乎在任何公司、任何老闆、都會讓你身兼多案，屢試不爽，毫無討論的空間。 但有趣的是，任何客戶都不希望這樣，如果是賣人力的time material合約，大部分的買方，即便沒有要求on site，也會要求人力不能兼任其他客戶的案子。當然，沒有on site就不好控制，

『薛西弗斯是希臘神話中的一個人物，他因為卓爾不凡的智慧惹惱了眾神。作為懲罰，他雙目失明並被判永久的將一塊大石頭推上山頂，但最終都不可避免地要承受著大石頭滾進山谷的結局。』-- wiki 第一眼看到 這篇 ，吸引我注意的，當然是照片中推著石頭的薛西弗斯。從某種角度來說，薛西弗斯絕對是一個悲劇人物，而這篇出現在『 猴子靈藥Blog 』上的 文章 ，也真的道盡了創業者所要面對的辛酸，以及不為人知的心路歷程。 文中有一段，引了『梁宁』寫下的… 『在创业的真空里，没有人告诉你，该做什么，停止什么，该往那里去。你再也不能通过迎合某人的要求而换得晋级。』 上面這段話，我感觸尤其強烈。 因為種種的因緣巧合，我在約莫10多年前，離開了穩定的園區工程師生涯，後來從事寫作、顧問、教育訓練…等工作，一直到後來參與成立自己的公司，雖然這些確實都是我的興趣(何其有幸)，但這也確實並不是一開始我人生規劃中曾經考慮的路徑。 不少朋友以為，這樣的『講師』生活肯定多麼愜意。事實上是，離開了所謂上班族的生活之後，要不了多久，你確實就會開始感受到生活的的確確、明顯的和上班時有所不同。 首先，準時早起上班開始變成工作中的非必要條件，但換來的則是忽高忽低的不穩定的收入，以及強烈的不安全感。 我曾經多次跟身邊的朋友說，當你開始變成所謂的SOHO，只消幾個月的時間，你就會發現你無可避免的，會幫自己接下超過你原本上班時所能接受的工作量還來的多很多的工作(所以比起上班時更不自由、時間更少)。為什麼? 很簡單，因為你再也不會有固定的薪資在每個月固定的那一天匯到你的帳戶(我得說，回頭想，每個月能夠固定領到錢，就是一種幸福)。你開始必須自己估計每一筆款項可能進來的時間，並且，預先為客戶可能發生的延遲匯款自己事先做好準備。 在你上班時，你理所當然的認為從來不需要擔心的問題，在你變成SOHO之後，開始變的得要自己小心管理。不過這還算OK，只要謹慎一點、量入為出，積極一點、拼命工作，再加上你的產品(也就是你自己)還賣得出去，那大致上不會出什麼大問題。 只不過，你再也沒有上班時的那種…生了病可以請假、下了班可以暫時把工作丟在一邊、國定假日可以自在地休息…的日子了。當自己要為自己的收入負上100%的責任時，你的人生觀會立刻開始有所不同。 因為你清楚地知道，你得為自己的工作績效與成敗負上完

如果你有購買PubU平台上的電子書，像是『 敏捷開發專案管理 與 架構設計實務 』。 我們不時會更新電子書，更新時會在我們的FB專頁上通知，當您看到通知，即可試著更新您的電子書。底下以ipad為例，您進入系統後，可以嘗試點選右上角的更新鈕： 接著你會看底下的更新畫面： 完成後您即可閱讀新版的電子書囉。

還記得我去年寫了一篇文章，關於『 練習 』，看看時間，剛好快一整年。 當時寫『 練習 』這篇文章時，是因為同時間看到了一些讓我挺有感觸的東西。一個是當時跟大家提過的日劇Dinner，一個是Robert C. Martin的The Clean Coder。而剛好那時候又碰到TechDays結束，忍不住把一些心情整理下來，這也是後來在 MVP Open day 當中，會和朋友們談到我自己的一些學習過程的緣起... 後來，曾經有學員（也是朋友）私下問過我，如果凡事都需要那麼多練習，那豈不是沒有生活的時間了嗎？真的每一個所謂成功的人，都那麼精實的訂定自己的『目標』，都那麼積極的過每一天的生活？？？ 當時我沒有回答，因為我不知道該怎麼回答。 我不知道的是，是不是只有我看到(學到）的是這樣？我無法肯定是不是一個通往夢想或實現目標的正確方程式就一定是如此；同時我也不能那麼肯定，這就是唯一正確的道路。 一年之後，我看到了一場兩年前的演講，讓我可以更肯定地跟朋友們分享：或許我在上課時提到的那些(目標、努力、練習...etc)，不一定是通往夢想的標準答案，但顯然不只我一個人這樣做(或這麼想)。 或許通往成功的方向有很多條路，但更多的準備，絕對是讓你在這條路上可以走的比別人更快的方法 。 可能是因為幸運，我求學階段沒有太多參加補習班的經驗，我也沒有去過台北知名的補習街上過太多的課，所以對於補教界的老師也只是耳聞（雖然某種程度上來我，我自己搞不好也　算是補教界的一份子...)，再加上前幾年風風雨雨的補教人生，可能讓很多人從新聞媒體上看到的印象是很負面的。 不過如果暫且撇開這些不談，主講者在工作上的努力，和對於目標的專注與積極的準備，是讓人相當欽佩的。 顯然在極度競爭的市場中，要擁有一席之地，倚靠的絕不會是僥倖。 本來只是假日想讓讓自己休息所以找個演講用聽的，點開youtube時不很期待，但沒想到她的演講講的很好，比我預期的要好~非常多... 整場內容時間不短（但卻一點不會沉悶），講到目標、講到夢想、講到教學、講到熱情、講到練習、講到努力、講到核心價值...etc.這些主題都是我熟悉的(甚至是我自己講過的)，但能講得這樣吸引人真的很不容易，講者在演講和授課技巧上算相當不錯...推薦給當講師的朋友 或 想當講師的朋友(part 2還談到了教學技巧和怎麼準

  最近看一本書，書名就是這篇文章的標題『飛機上的27A』，剛好工作上發生一些事情，頗有一些感觸。 這是一本小書，也是一本小說，我是看電子書，但看完之後我又買了紙本書(送給身邊的朋友)。書中一位成功的企業家對於選擇合作對象的想法，讓我重新省思一些幾乎快被我忘記了的原則。 書中主角是一個成功的年輕人，算是在當今這個營營汲汲的資本主義社會中的佼佼者，然而有一天，他在飛機上碰到了這位很不一樣的企業家，在企圖爭取這個企業家成為他的客戶的過程中，他所學習到的一些故事。 看完這本書後，讓我回頭思考的問題是，這個世界不知道從什麼時候開始，充斥著各種商業與管理技巧，各種tips類型的準則，讓我們目不暇給，眼花撩亂。時間管理? 談判法? 如何成交? 銷售的心法? 甚至連生活都有小技巧...然而被這些tips轟炸的同時，我們都忘記了很多最基本的原則。 其中之一，就是『誠信』。 為什麼對這個特別有感觸? 書中的企業家選擇合作的廠商，首先看重的不是獲利能力、不是資本額、不是折扣的高低、或是交易的利益。而是這家公司的誠信、道德操守、以及員工、經理人的人格特質，和公司文化。 我發現上面這一行最後幾個字，幾乎是我們現在在報章媒體上已經很少看到甚至很少被用的文字了。 最近一兩年，我們的開發團隊整個改為agile與scrum，然而碰到最大的挑戰，並非制度與工具、也不是人員或方法。坦白說，最大的問題是外部的客戶、採購與銷售。 Scrum在意團隊，也在意客戶，agile從軟體開發最原始的角度出發，我們希望建構一個客戶能用、好用的軟件。說真的，這可能是每一個軟體開發人員最原始的初衷，沒有人希望自己寫的code只能看不能用(或是不能看也不能用)。 然而，從這個角度出發，實際上會碰到最嚴重的問題，其實往往是『信任』。 依照Scrum，最合理的合約與付款方式是 time material ，也就是合約金額不固定。原因很簡單，因為我們隨時接受需求變更，如果隨時接受需求變更，那總工時當然也會跟著變更，沒有道理總工時調整了，合約金額卻不變吧? 這種合作模式，time material當然是最理想的付款選擇。 然而，這在台灣幾乎被視為不可能。 客戶總是希望固定付款金額，固定工時(遲了還要罰錢)，但需求內容則在成案後還是會變更(好一點的客戶會註記變更幅度不超過15%

這 本手冊是光岩資訊董大偉老師在『敏捷開發專案管理與架構設計實務』課程中的內部訓練教材。董老師以十多年軟體專案與產品開發經驗為基礎，採用Scrum與Visual Studio Online作為專案管理框架的實戰經驗分享，內容相當難得。與坊間的PMP專案管理、CMMI、瀑布式(waterfall)開發有所不同，本書內容為第一手的敏捷開發實戰經驗，不僅如此，這本書也並非傳統照本宣科的Agile/Scrum教材，而是結合了華人特有的專案運作模式與管理制度和文化，所凝結而成的經驗分享。         內容以Scrum為骨架，搭配Visual Studio Online為實作工具，從專案的kick-off開始，一路談到專案開發的整個Life-Cycle，內容包含工作項目的管理、Features, Backlogs, Tasks, Bugs的建立、管理、追蹤與維護，包含測試與stakeholders的反饋蒐集，也包括Scrum的周期性工作說明與經驗分享。         在本書中，董老師透過實際專案運用Scrum的經驗，以第一人稱的角度，將運用Scrum和VS Online的第一手經驗真實的呈現給學員，同時也和學員一起探討，面對在華人(特別是台灣)特殊的軟體專案氛圍下，各樣實施Scrum所發生的衝突和解決之道。更豐富的是，書中不僅僅介紹如何採用VS Online進行Scrum團隊開發，更進一步的討論到了如何透過架構與開發框架(Framework)設計，來解決專案經驗不足的團隊，採用Scrum時可能有的水土不服、品質低落的問題。透過開發框架(Framework)設計，簡化開發方法與程序，配合ALM工具和敏捷開發精神，讓您未來面對專案或產品開發更有信心。         不僅如此，這本書也集結了董老師這幾年來，在不同場合分享的Developers生存之道，是一本與資訊技術密切相關，卻又適合技術人員在茶餘飯後細細品味的書籍。 言盡於此，其餘的，就由讀者自行體會了。 此版本為搶鮮預覽版，後續會持續更新( 如何更新 )，但也可能調高價格!(越早買越便宜) 更新後，先前購買的讀者依舊可以免費持續下載最新版本。需要的讀者可以到 這邊 搶購。物超所值啊!!! =============================================== 序言