2014年12月27日 星期六

如何培養你的『溝通力』

這是一篇欠了很久的文章。不寫,是因為我覺得這主題要寫的好著實不容易,但偏偏『溝通』這件事情,是專案管理當中非常重要的一環,也是工程師想要蛻變或升級的一個必學功課。(因此這一篇讀起來要有點耐心)

在溝通這件事情上,身為開發人員或PM的你,理論上應該要非常有經驗。從專案一開始(甚至說還沒開始)『溝通』就持續在發生。在presale介紹產品時,在SA洽談規格時,在UAT面對客戶的挑剔時,在專案延遲面對客戶的責難時...

你肯定會發現,需要『溝通力』的場合真是無所不在。

既然需要溝通的場合天天發生,那表示,大部分的PM或工程師,都能夠順利的做好『溝通』這件事嗎? 完全沒有,甚至可以說,大部分的專案都是敗在溝通上面的。特別是工程背景的技術人員,在面對溝通上,總是常常犯著有形無形的錯,卻始終不自知。然而,這是個性和訓練背景的不同使然,可能真的是非戰之罪。

但只要有機會,工程師必須調整自己,才能夠往另一個層次的方向邁進。

備註:上面所說的,正好就是資深技術人員不一定能夠成為好的PM的原因,雖然我自己找的PM,都堅持必須要有技術背景,但我也非常清楚,對於有技術背景的專業人員,由於受的訓練與思考模式的不同,其實相當不容易跳過這個gap。


接著,我們就來談談溝通這件事情。

首先,你第一個你必須注意的事情是,溝通是一件需要花時間的工作。大多數的工程師喜歡思考、也喜歡動手、甚至喜歡談技術,但不喜歡說話,特別是不喜歡耐心的聽別人說話。

『不喜歡耐心的聽別人說話』,是溝通的第一個致命傷。(你認為自己算是很有耐心? 或覺得這應該是個容易克服的問題? 請先往下看再說...)

你必須知道一件事情(這是一個心態的調整),所謂的溝通,並非是想盡辦法(透過技術或是專業)說服對方,而是給對方一個說服自己的機會。意思是,當你想要和對方溝通,如果你的潛在目的是只想讓對方照你的意思做,那不叫溝通,基本上那就是談判(或是說服)。

溝通是,你必須抽離自己的角色和立場,從一個第三者的角度來看,你自己所在意的,和對方所在意的,兩者之間有多大的距離,為了讓雙方都滿意,該如何找出具有創造性的第三選擇,而非只執著在自己要的結果或對方想要的結果上面。(想深入了解這個概念,可以參考柯維的『第三選擇』一書)

柯維在第三選擇中說:「溝通中的傾聽是你讓對方充分表達並且了解對方的感受,到足以為對方辯護的程度,否則你其實並沒有聽進去任何東西。」

注意,溝通的目標絕對不是妥協,不是企圖守住自己底線的妥協、或是試圖讓對方妥協,而是找出兩者均感到滿意的新的另一種可能性。要完成這樣的工作,不耐心傾聽別人說話,是不可能達成的。

因此,溝通的第一件事情,是真心的想要並且真正的理解對方到底在意的是什麼。

而要真正理解對方在意的是什麼,第一個要素就是『傾聽』。不幸的是,工程師都很聰明,而愈是聰明的人愈沒有耐性傾聽。

你可能過去在很多書上看到過介紹傾聽的許多技巧,甚至包含身體該擺什麼姿勢,該怎樣運用手勢或是表情....然而我要說的是,這些技巧,如果只是停留在『技巧』的階段,則你並非是真心的想了解對方。著重技巧的傾聽,充其量只是一種行為上的敷衍(像是在告訴對方,我現在花了時間聽你說話囉,等一下就換我說了,你準備好好聽著吧!)。人的相處很微妙,如果你不是真心的想要了解對方的想法,相信我,時間一長,對方肯定會知道。

因此針對傾聽,我只推薦一個做法,是我在教會和第三選擇一書上多次學到的,就是『複述』。當你在傾聽對方的想法時,必須要練習絕不打斷對方發言,直到每一個對方主動停下來的段落,你要複述你所聽到的(複述他所說的),直到對方(注意,不是你自己)確定你理解他的想法為止。

例如...用以下這樣的方式詢問,讓對方協助你確認你自己是真的知道他的想法...
『所以,你的意思是.....』
『因此,你認為最重要的是...』
『我感受到你在意的是...』

這很花時間,且違反人性。要求你不辯解、不反駁、只複述對方所說的,直到對方都講完並且認為你聽懂了為止。你甚至可能擔心這樣是否會給對一種懦弱的感覺,但相信我,這麼做絕對值得。

你或許也會質疑,有時候事情就是只有『對』或『錯』、『要』或『不要』、『是』與『不是』,就算知道對方的想法之後,又有什麼用呢?

如果你常常用這個角度來思考,我得要衷心的提醒你,你被這個世代(特別是台灣當代)非黑即白、非藍即綠的二分法思想荼毒太深,必須立刻回頭,否則可能找不到岸。(工程師特別容易陷入這樣的true/false陷阱)

在這個世界上,太多事情落在 0 與 1 之間。但有趣的是 0 與 1 之間所能找到的解答絕不只是妥協,而是第三種對雙方都更好的可能性。但,這是什麼意思呢?

我們在專案或人生中可能碰到很多衝突。業主要金額低,但同時要品質高、專案人力不足,但時程又很急、這個月底要驗收,但客戶又要增加功能...有太多太多太多『看起來』是衝突的問題,這時候高德拉特TOC理論中學習到的衝突圖,總是可以提供我很大的幫助。

以一個簡化的例子來看,請先看下圖右方綠色的部分...

 
看上圖這個例子,在專案中PM覺得需要更多的人力,而老闆則堅持專案不該再增加人力。兩者之間顯然發生了衝突。一般人碰到這種衝突或意見不合,都會反射性的啟動『防衛模式』,開始聚焦在自己的立場和角度,並且找出各種論點去支持自己的看法,導致兩方的態度漸行漸遠,最終完全沒有交集。最後,事情只能透過妥協或折衷(雙方都不滿意,但勉強可以接受)的方式來解決。

但高德拉特和柯維建議我們不要這麼做,而是透過溝通、傾聽,去了解對方心裡想的是什麼? 到底他在乎的是什麼? 透過繪出衝突圖,你會發現PM在乎的是『讓手中的專案能夠順利完成』,而老闆則碰到『其他專案也有迫切人力需求』的情況。

理解了雙方背後所在意的因素之後,接著要找出兩者共同的目標(價值觀),因為我們只能在價值觀一致的情況下溝通(不要不信邪,價值觀不同,是沒法溝通的)。PM和老闆透過溝通,最後發現其實雙方在意的都是『如何將人力資源進行更有效的規劃與使用』。有了這個基礎,兩方之間就可以找到一致的價值觀,開始尋求對雙方都更好且彼此都滿意的作法。

能夠瞭解這之間的差異嗎? 如果不透過溝通,雙方解決問題時,最終只會透過談判或協調的方式,產生的結論幾乎都不是最佳解,而是0與1之間的妥協值。然而,透過溝通,則是找出雙方所堅持的問題背後的原因與動機,且尋求出一個兩者一致的價值觀,並且找出兩全其美、皆大歡喜的第三選擇。(這不是妥協,而是找到一個更好的新方法)

上面這個例子,是一個最小Scope的演練,在你的專案中、每天的生活中,會有非常多這樣的例子,由於這真的是一個違反人性的習慣,你必須一直練習、一直練習,直到你反射性的會傾聽,下意識的想去了解跟你不同的意見的人的看法,直到這時候,你才會逐漸感受到這個技巧的用處與價值。

備註:在台灣,我們非常幸運,幾乎每周都有一個議題,讓我們可以練習。例如公車專用道要不要拆、服貿該不該簽訂、鐵路要不要穿過水庫、證所稅該不該課徵...每天,台灣社會總是被二元化的思維所制約,正反雙方只堅持立場,不肯去尋求或理解對方的思維。

前面說過,這是一個違反人性的練習,所以想要培養出你的溝通力,你必須從你自己開始,你無法要求對方這麼做。也就是說,你不能拿著這篇文章,或是柯維的『第三選擇』、高德拉特的『限制理論』,丟到對方面前,要求對方傾聽你說話,你只能自己先這麼做,並且透過上面提過的技巧,引導對方和你一起找到彼此共同的價值觀,並尋求對彼此更好的解決方案。

沒有人說溝通是一件不費力或是很簡單的事情,也絕非只是說說話、開個電話會議、或是發一封mail就能解決的(我曾說過,email不是拿來溝通用的,email是用來記錄的)。然而,當技術人員能夠徹底的掌握到溝通的原則後(注意,是原則,不是技巧),所能夠發揮的力量,絕對是你難以想像的。

後記: 我真的很建議工程師先看完高德拉特的『目標』一書,接著你可以從他的續集『 絕不是靠運氣』中,學習到衝突圖的使用技巧,四本高德拉特讀完之後,接著看柯維的『第三選擇』,柯維和高德拉特這兩位作者的十幾本書,都是我長年放在書架上(大概重複看了二十年),並且常常在研討會送學員和team member的經典著作。

本篇收錄自 - 『敏捷開發專案管理與架構設計實務

2014年12月25日 星期四

保持模糊的共識?

最近在新聞上,又有政治人物談起一個有些古老的議題,也就是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就談定了。至於工作範圍,人力預估…等文件內容,就算不是『天書』,也是PM透過經驗和直覺所產出的猜測數據

接著,專案開始,如果這時候開始細談規格,發現距離賠錢不遠,還有踩煞車的可能,然而,事情卻不會那麼簡單。

好不容易案子接進來了,團隊成立。人員安排好了,做了一個月你想停掉這個案子? 這責任要誰扛啊? 而且沒有下去做,你怎麼知道一定會delay呢? 怎麼知道會做不完? 加加班ㄍㄧㄣ一下,或許…應該可以的啦。

內外壓力夾殺之下,乙方PM慢慢接受專案現況,把案子撐下去。這時候關鍵來了,你猜日後甲乙雙方會更努力認真的釐清規格,算出到底有多少差距? 還是索性把頭埋在土裡,能不碰乾脆不碰?

是了,事已至此,清楚的釐清規格,只會造成雙方痛苦,甲方會發現專案一定Delay,乙方得接受案子一定賠錢,再繼續釐清下去,甲乙雙方都非加班不可,既然如此,乾脆保持模糊,大家眼不見為淨。

但,保持模糊有何好處?

首先,面對驗收時,可以用談判的方式來解決,有經驗的PM都知道,驗收不一定是照功能清單Check box勾勾勾,也可以用交換的,到時候拿這個功能換這個功能,拿那個功能換另一個功能,或許可行,因此,乙方PM想著的是…客戶頭都洗一半了,諒他也不敢打掉重練吧?

甲方PM心裡想的是:『規格沒搞清楚是你的責任,想要我付錢當然就是要照我說的來驗收啊,反正我到時候不簽驗收看你是能怎樣?』然而問題在於,同一個規格的文字描述,甲方想的是ABC,乙方想的是甲乙丙,兩者看是相似卻有差別,最後誰說了算呢?

既然規格不清有那麼多風險,那談到很清楚再簽約不是比較好嗎? 問題來了,那前面談規格的那一段成本算誰的? 規格要談的很清楚,就必須花時間,要花時間,就等於要花錢。這錢要誰出? (甲乙雙方都會覺得這是對方該負擔的) 更重要的是,那這樣還要不要成案? 如果談了三個月中途生變,豈不是賠了夫人又折兵?

所以,這種『創造性的規格模糊』,就在矛盾和妥協當中出現了。

在我經歷過的專案當中,需求和規格在很清楚的狀況下才開始進行開發的案子極少,有相當高的比例是在簽約時,規格都還沒有釐清。那規格不清晰怎麼會有預估金額呢? 不要問我,我也覺得很不可思議,但台灣大部分的軟體專案就這麼幹了。

規格模糊並非只有壞處,有時候可能就是得要這樣,才能夠面對瞬息萬變的用戶需求(Really???)。時程較長的大型專案,想要釐清規格恐怕也很難。有時候開發到1/3的階段,用戶需求已經大幅改變,搞不好連當時談規格的用戶都已經離職,一開始談的再詳細也是沒用。(對,規格書很清楚,但end-user會跟你說,這系統他不能用啊,他知道規格書這樣寫,但他不能用你要他簽驗收,他還是簽不下去啊…)

也因此,問題不在規格的模糊,而是在怎麼控制變更。

PM把規格和需求的變更視為常態(從心態上一開始就當作理所當然,這就是會發生的事情),你就不會擔心(憂慮)規格模糊的問題(而應該在各方面做好面對變更的準備,包含合約)。然而,模糊的規格當然還是必須在日後開發前確認與釐清,這也是我們在Scrum當中,會有Planning Meeting與Sprint安排的原因之一。

規格的模糊並非罪惡,然而在何時,怎樣用適當的方式把規格釐清,讓開發團隊可以即時的進入開發,並且讓客戶滿意,則是專案管理上的一個溝通藝術。

過去在waterfall時代,規格的模糊也常常發生,但往往卻導致UAT驗收的那一刻,你才發現這不是客戶要的(客戶也才發現你根本沒聽懂他說什麼),如今在agile時代,規格的模糊依舊會發生,但我們卻不害怕變動,透過頻繁的溝通讓變動與規格的釐清在你的掌握中,透過每一個Sprint的Demo/Review讓你的成果被客戶所認同,隨時與客戶保持互動,讓客戶知道你正在為他努力,你也在乎他的需要,這才是PO/PM該達成的使命。

因此,身為PM/PO,不需要害怕規格模糊。但是,千萬別忘記,刻意保持的模糊,是為了達成某個共識(例如成案),然而終有一天,模糊的事情必須被釐清,隱藏的問題必定被揭露,屆時,就看彼此準備的有多充分了,專案上如此,政治上其實也是。

本篇收錄自 - 『敏捷開發專案管理與架構設計實務

2014年12月20日 星期六

[經驗分享]如何用VS Online及Scrum帶領兩岸三地團隊進行專案開發與管理 - (十) 累計流量圖 與 燃盡圖

再上一篇我們談過了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可以很清楚的知道整個專案的健康狀況,也能夠反映出專案能夠準時完成的可能性。在管理上是相當好用的報表。

本篇收錄自 - 『敏捷開發專案管理與架構設計實務

2014年12月18日 星期四

[經驗分享]如何用VS Online及Scrum帶領兩岸三地團隊進行專案開發與管理 - (九) 從Backlog展開Tasks

Task的建立與撰寫

Taskbacklog的子階,一般來說,我讓PO來建立Backlog,由Team MemberScrum Master來展開Backlog建立Task

Backlog代表著是要待完成的功能(任務),而Task則是具體展出來的開發工作。Backlog多半沒有技術的用詞,最好的寫法是以非技術的term來撰寫(stakeholders也能看懂),而Task則是該功能(任務)的拆解開來的具體工作了,所以有一些技術的term並無不可。

PO所撰寫好的Backlogs展開(或拆解)tasks,是在ScrumPlanning Meeting中發生的,所以一開始專案Kick-off前後,可能根本只有Backlogs而沒有tasks
 
還記得嗎? Backlogs中有一個effort欄位,寫的是預估時間。

在台灣,專案成案前,往往必須告訴客戶預估金額和時間,但Tasks都還沒有展開,能算出100%準確的預估時間嗎? 我不認為可能。依照Backlogs所估出的時程也僅僅為估算而已。專案團隊最好不要讓POSales以為這是時程上的『承諾』。

而真正到了專案開始進行,把Backlogs展成Tasks之後,POteam才會慢慢了解(認清)專案的真相,一些被隱藏的工時才會慢慢出現,特別是3-5Sprint之後,就可以清楚的知道自己的預估是否準確,從而進行修正。

也因此,落實到合約的簽訂,如果可以,最好在總時程和總金額尚保留一點空間。(我承認在台灣很難)

在操作的實務上,Sale依舊可以依照過去的報價方式(把預估膨脹個幾倍)來報價,但對於POScrum MasterTeam(甚至客戶)來說,在運行Scrum之後,專案的透明度無疑地提高了。

(關於專案報價與成案問題,可以參考飛機上的27A - 談敏捷開發的成案問題)

如何建立Task


Work分類項目下,你可以看到Backlog Items,請留意當滑鼠移動到下圖Backlog Items的藍色長條圖示右方後,會看到其實右方有一個比較淡色的灰色長條,你可以點選它:




點選之後,會發現該長條變成黃色了,如此一來可以展開Task




 
如果你的Backlog尚未建立任何Task,可能會跟上圖一樣,只看到階層狀(如果有階層的話)Backlogs但你可以按下左方的『+ 』符號,則可以在該Backlogs底下建立一個新的Task


建立Task的畫面與建立Backlogs差不多,除了都可以Assign給特定的Team Member之外,也可以描述Description,一般來說,我讓team members在這裡寫下該工作的規格與進行的狀況(也可以寫在右邊的History),便於開發也便於事後追蹤。
 
由於剩餘工時的欄位內容(數值)會在該task被check in為done時清空為0,因此,如果你想保留每一個Task所花費的工時(實際花費工時),則必須要特別將該數值(實際工時)寫在另一個欄位中(我們是寫在Task的Backlog Priority欄位中,因為該欄位具體用途不大,在Backlog中已經有Priority了)。
 

剩餘時數 與 燃盡圖

 
而effort欄位在Task這邊變成了remaining work(剩餘工時),這個欄位是讓開發人員隨時(一般來說是每天)更新該工作預估還要多少時間才能全部做完。基本上這部分是用來產生燃盡圖(Burndown Chart):
 

從燃盡圖上,PO/PM可以看的出來工作目前進行的狀況(完成度),圖中的黑線是平均理想線(也就是假設在Sprint結束前,工作都會被如期完成),如果圖形顯示出來,顏色區塊是低於黑色直線(像是上圖中的2/8, 2/9),表示工作進行得很順利,甚至可能提早完成,反之,如果顏色區塊都高於黑色直線(像是上圖中的2/14),表示順利如期完成的機會恐怕不高。

當然,燃盡圖要有意義,前提是team member必須天天更新remaining work時數,且數值必須真實。不過需要強調一下,實務上,我們看燃盡圖也只是為了得知專案真實的狀況,並非要壓迫(壓榨)哪一個developer,逼著team在期限內完成工作。

指派工作負責人員


你可以在建立Task的時候就指派該Task的負責人員,但這比較不符合Scrum的精神(後面我們會提原因)。在指派人員的介面操作上,也有兩種不同的方式,例如在底下新增畫面中,選擇Assigned To欄位中的team member:



但用這樣的方式來設定,如果你沒有在一開始建立task的時候就指派負責人,那日後指派時得要把每一個task都Double Click點開,非常辛苦&麻煩,也不方便調整或一次指派多個task。

 因此,有另外一個更好的方式。

 你可以在Sprint當中作tasks的指派,請參考下圖:


當某一個Backlog被分派到某個Sprint當中之後,你可以在左方點選該Sprint的黃色Bar,接著會出現上圖右方的畫面,請注意其中有一個Capacity選項:

你點選之後,可以設置團隊每一位成員的每天可用工時。別忘記設定完成之後要按下 鈕。
接著,請切回Backlog,並且將Work Details要設為On,接著你就可以透過拖曳的方式,將某一個task指派給特定的Member了:




從上圖右下方的圖表中你也可以看的出來,每一位team member的工作量是否爆表,或是還有餘裕可以接收更多的task,工作量爆表的Member會以紅色顯示,而綠色則表示尚有餘裕: 



 
本篇收錄自 - 『敏捷開發專案管理與架構設計實務

2014年12月8日 星期一

這些問題都不在Scrum

前幾天,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卻覺得面對面溝通沒有效率,所以希望用文件來取代面對面溝通。(這是真的,因為很多developer溝通起來像鬼打牆,繞來繞去兩小時後還在討論一樣的問題)

但其實,用文件溝通是『經過研究指出最無效的溝通方式之一』,我始終不相信透過文件溝通會比面對面溝通來的有效且明確。

文字,其實是一種抽象的表達,有時候用錄影的影片,效果都比文字來的好上一大截。

我強烈的不建議團隊用文件來取代溝通,特別是描述性質的文件,描述功能、描述bug、描述規格...等。我希望PM/PO打從心裡質疑文件,而把文件當作一種紀錄工具而非溝通工具

我常常讓PM/PO跟客戶談規格的時候,一邊打開VS Online的backlog/features,並且同時當著客戶的面把功能敲入系統,但請注意,這不是拿來跟客戶或developer『溝通』用的文件,而只是一種備忘,避免漏掉了某一個客戶提到的需求。

有各種技巧和方法來描述user story,你在坊間可以看到各種優雅或是前衛的方式,甚至搭配影音或是ppt slide,有太多太多方式聲稱可以清晰地描述規格,但我建議你,不要太過於全盤相信。只透過文件的溝通,永遠不能取代面對面的交談。

我衷心地建議PM和開發人員:我們可以竭盡所能地要求文件清晰,但不要以為文件就是溝通的工具。溝通,除了理解對方想表達的內容,還包含接收對方的感受。

有些Developer會說,我之所以選擇寫code,就是不希望碰到用戶,難道不能只看規格書來寫程式嗎? 我只能說,Developer,請多加訓練自己溝通的技巧,面對客戶、面對用戶,去了解對方真正的需求,去感受到對方的情緒,少說話,多聽,複述對方的需求,直到對方認為你了解他心裡所想的,那才是溝通。

截至目前為止,我從未讀過可以讓我"感受到用戶情緒"的文件,文件是死的,但人是活的。所以,千萬不要只看文件去理解規格,不管是features/bugs都是。

請不要誤會我覺得文件不重要,文件是重要的,但文件不是拿來溝通的。人,才具有溝通的能力,隔了一層文件,只能有最基礎的認知和理解,而不容易掌握到全局。developer千萬別放棄自己溝通的能力...傳統認為SA/PM才需要具備溝通技巧的時代慢慢要過去了...

如果有機會,我們改天再來談談溝通的問題

2014年11月22日 星期六

為什麼我要規範所有團隊用同樣的架構開發專案?

前陣子在上架構與框架設計的課程時候,提到幾件事情。我說...
  • 要設計出好的架構不難,但真正能夠實施(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 處理,分別是:
  1. Server Components 開發
     
    Server Components 以.NET Assembly(.dll)的形式開發,開發人員可以建立標準 的.NET 4.5.x Class Library,透過引入 Framework Server Component Nuget Package 來建立 Visual Studio Project。開發後的.dll會被佈署到上圖中最底下藍色的那層Backend Application Service Layer中。
            
  2. Client 端 UI 開發
     
    Client 端 UI 有各種不同的形式,如果是網站可能是 HTML Pages,如果是 Windows Desktop application,則可採用 WPF 或 Windows Form 開發技術。如果是 Mobile Device,則可能是 Windows Store App, Windows Phone App, 或是 iOS/Android Apps…etc.。
     
    不論是何種形式的前端Project,均可透過引入相對應的 Nuget Package,取得 BackendServiceClient 這個共用 Component 來進行 Server Component 的調用,以及開發 Client 端所需要的各種 Helpers/Utilities。

透過這樣的開發方式,你會發現,這和你以前習慣的開發方式 -- 『開發人員直接打開Visual Studio 2013,用微軟內建的範本來寫程式…』會有著很大的不同。

首先,我們只讓開發人員寫兩個部分的Code,分別是:
  1. ServerComponent(.dll)
  2. Presentation(UI)
我們稱之為ServerComponent的部分,本質上就是Class Library,也就是.net的assembly(.dll),其中的具體內容就是一個一個的Method(我稱為ServerMethod)。

除此之外,其他的程式碼我們都已經透過framework所封裝,包含身分驗證、日誌(Log)的儲存、例外處理(exception Handling)、權限與安全性…等。都由Framework中的AOP機制來達成。

所以我們的開發人員在進行ServerComponent的撰寫時,毋須擔心或過度的處理cross-cutting concern部分的機制。撰寫程式碼時,只要繼承自我們提供的BaseClass,並專注在business logic的撰寫即可。cross-cutting concern部分的機制,有我們開發好的一整組Attributes可以用。(例如,只消在ServerMethod掛上WriteLog attribute,該Method即可具有log的功能,掛上Exception Handling attribute即可自動處理例外發生時的紀錄、retry、或alert...)

而前端UI(Presentation Layer)調用服務器端ServerComponent的部分,也是透過我們所建立的Services Layer與前端API。且不管前端用哪一種開發方式,是Web/Desktop/Mobile甚至是iOS或Android,都以同樣的一個Helper(BackendServiceClient)來調用服務器端ServerComnponent中的Server Method(via ExecuteCommand),也就是說,不論是開發哪一種前端,前端對於後端Business Logic調用的寫法幾乎完全相同。

前端開發人員需要發揮的就是UI的處理與特性,後端開發人員需要撰寫與掌握的就是Business Logic。

簡單總結一下,透過這樣的架構:
  1. 後端開發人員需要會的技能是 C#, OOP, ORM(EF), 以及domain know-how
  2. Web前端開發人員需要會的技能是 HTML/JavaScript(or some js framework)
  3. Windows desktop開發人員需要會的技能是 XAML/C#
總的來說,我們盡可能地壓低開發人員所需要的skill set,這樣的目的是確保開發成本降低,並且讓交接與維護更為容易。

我要坦白說一句,這對於開發人員來說不一定100%是好事(但放心,我們並沒有苦待開發人員,我們有架構設計與RD單位,讓具有RD個性、特質、與能力的開發人員,反而更能夠有另一條更有挑戰也更有趣的升遷管道),但這對於專案管理來說,卻是一個很大的利基。當每一個案子都用這樣的方式和架構來開發時,你會發現每一個專案的程式碼寫法與架構都完全相同,在交接或維護時,立刻可以看到優點,管理效率提升到PM會偷笑的程度。

如果依照過去的作法,每一個案子(或產品)都由該案子的Architect來從頭設計架構,你會發現長期下來這根本是一個災難。

首先,先不管坊間framework的變化程度(你想想從ASP.NET WebForm到ASP.NET MVC才幾年? 再想想AngularJS從1.x到2.0的改變...),也不管架構師本身的素養和能力。當每一個案子的特性不同,架構師往往會很『盡責』的去設計出貼近這個案子的開發架構,並且『順手』就把最近學到的新技術給硬生生地塞進去。

你會發現很有趣的事情,在過度自由的開發環境中,同一個架構師(或同一個團隊),所經手的三個案子,可能會有五種不同的設計。每一次都有新的『改進』,而每一次『改進』,就意味著某些過去的作法被推翻與拋棄,然後架構師又會持續在新的案子中加入了新的元素(或技術、或pattern),企圖讓校能更好,讓開發更方便,或是讓XX更OO、讓ZZ更YY....總之架構師或SD會告訴你...加入這個...加入那個...各種好處不在話下。

如果案子不用維護,那當然沒有任何問題。但你有碰過不用維護的案子嗎? 是了,少到幾乎沒有,所以開發完成之後,往往才是災難的開始。

特定的開發技術,特定的前端框架,這對於開發來說都是機會,但也都是風險,對於維護來說則都是成本。即便用了某些框架,可以很快的完成某些功能,但,以後呢? 如果開發過程中碰到規格變更呢? 這些隱含的成本往往PM和開發團隊都不太關心,但這卻是日後無法結案或無法維護的主因。

也因此,最近這幾年,我們力求統一開發架構,讓每一個專案(甚至產品)的開發,都用完全一樣的Framework(我們自己開發的Framework),當有新的技術或是更好的作法,我們會邀請前線的開發人員,反饋給架構設計單位,並且每季定期釋出框架(framework)更新。由於開發工具的進步,現在我們將框架透過nuget package來導入,更新時開發人員只需要update package即可自動更新。

正如同我前面所說的,架構和框架設計是一種取捨,這樣做讓開發團隊自由發揮的空間減少,卻讓後續維護與交接的成本有效的降低。然而取捨,是一種需要智慧的決定。

有機會,我會再談談在企業和團隊中導入開發框架時,所會碰到的阻礙和因應方案。

本篇將收錄到 - 『敏捷開發專案管理與架構設計實務

2014年11月15日 星期六

[經驗分享]如何用VS Online及Scrum帶領兩岸三地團隊進行專案開發與管理 - (八) 重新對應Backlogs與Feature之間的關係,以及專案時程的推估

先前我們在這一篇當中,曾經介紹過如何從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,那可就誤會大了。

本篇收錄自 - 『敏捷開發專案管理與架構設計實務

[研討會] 透過雲端彈性且快速地延伸軟體的開發及測試

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


2014年11月11日 星期二

[經驗分享]如何用VS Online及Scrum帶領兩岸三地團隊進行專案開發與管理 - (七) Backlogs的異動、歷史紀錄、與Notification機制

每一個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:
 
對於開發團隊來說,是相當好用的機制。

 
本篇收錄自 - 『敏捷開發專案管理與架構設計實務

2014年11月8日 星期六

[經驗分享]如何用VS Online及Scrum帶領兩岸三地團隊進行專案開發與管理 - (六) 從Features展開Backlogs

在實務上,專案可以不寫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敲到系統裡面,最好不僅僅是標題,還包含初次訪談的手札或筆記甚至錄音,直接以附件的方式加入Backlogs或是填入Backlogs的Description中都可以。
        還記得嗎?我們提過,對於敏捷開發來說,產出客戶可用的軟體是我們的首要目標,也因此,非必要的文件能少就少。如果真需要一些文件(特別是給客戶的),我都盡可能讓Product Owner或是Scrum Master來撰寫,而Developer就是focus在軟體的開發上。

=====================================

敲入Backlogs的方式無須多說,跟Features差不多。基本上就是在Backlogs畫面中title的部分,直接輸入後按下Add即可:

 
在輸入的時候,你一定會發現,一次輸入完大部份能夠想到或列出的Backlogs後,再視實際需要逐一double-click進入輸入description或acceptance critiria,會比你輸入一個backlog就點進去輸入該backlogs的description會來的順暢的多。
 
當你在某一個Backlog上Double-click,會開啟如下圖的畫面,您可以針對每一個欄位,輸入相關的資料:
 
  你會發現上圖中的視窗上半部有一些欄位,我們針對比較重要的欄位說明如下:
  • [Iteration] 也就是這個Backlog被放到哪一個Sprint,一開始建立不用太在意,我們後面會用拖曳的方式來調整它。
  • [Assigned To] 這個Backlog的負責人。
  • [State] 該Backlog的狀態,有New, Approved , Committed, Done, Removed這幾種。在我們這邊是這樣用的,剛建立的Backlog狀態當然都是New,一旦該Backlog規格確認無誤(這是PO和SM的職責),確定可以開始進行開發,則會被移入Approved,這時候多半也代表著該Backlogs已經(或快要)放入Sprint中了。團隊中的開發人員,永遠只focus在當前Sprint所要進行的Backlogs上,一旦開發完成(也通過Unit Test)之後,則Scrum Master可把該Backlog狀態調整為Committed,待PO(或客戶)測試無誤後,則該Backlogs移入done。
  • [Effort]這個backlog的預估工作量。這個數值不一定是天數,嚴格來說這個數值應該是backlog彼此之間預估工作量的差異,它可以用來判斷backlogs大概會被放到哪一個Sprint。不過礙於輸入與參考、計算的便利性,我們大多都是輸入預估天數或預估時數 。
  • 在 [Business Value] 中可輸入數字,表示項目的相對商業價值。(也就是出錢的人有多重視啦,這跟Backlog Priority可能不同喔)
  • [Area]前面在建立iteration的時候曾經提到過,我們可以將一個較大的專案,依照開發團隊或是模組切割成不同的Area/Team,一般來說我們是用開發團隊來切割。當一個Project有多個Area/Team的時候,這個欄位就可以用來識別該Backlog屬於哪一個Area。

 
本篇收錄自 - 『敏捷開發專案管理與架構設計實務



2014年11月6日 星期四

專案中一個幾乎遙不可及的夢 - 專人專用

這是一篇我很早就想寫的文章。

我常常把標題列著,放在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就不好控制,因此很多控制的手段就出現了,包含daily report, daily meeting, worklog tracking...etc)

回頭想想...
專人專用,真的有那麼困難嗎?
專人專用,真的有那麼重要嗎?

我得說,這麼多年下來,特別是run scrum之後,我發現,專人專用絕對是案子成敗與否的重要關鍵。事實上是,只有在專案團隊成員是100%的投入時,才有所謂的『品質』可言,也才有『合理的績效』可以要求。

我不需要(也不想)花太多時間去解釋開發人員身兼多個案子,在兩三個案子之間switch時的轉換成本。因為你只消做過一兩年developer就知道,在關鍵的時刻,一點點的interrupt對開發來說都可能是一種罪惡。更何況腦袋要常常在兩個案子中轉來轉去,常常需要開不同的專案會議,常常需要參與不同的daily meeting,寫不同的專案報告、改不同的程式碼...對於一個擁有正常腦袋的開發人員來說,這不僅僅是一種試煉,這根本可以說是一種折磨。

我甚至可以很武斷的說,你想搞砸一個案子? 只需要讓團隊中大部分人都身兼多職就可以了。

我得嚴肅地說,成員身兼多職的團隊並不是一個真正的團隊(如果你了解我對團隊的定義的話 - 詳見筆者拙著)。你能想像一個職業籃球隊裡面的成員有一半晚上都在兼職踢足球嗎? 我得說,所謂的一心多用,根本是個業餘的做法。很多廠商所謂的品質,都只是掛在嘴邊說的,因為嚴格說起來,一心多用是不會有品質可言的。

也就是說,當專案的老闆和PM,開始允許團隊成員身兼其他案子的成員的那一刻起,就表示他心裡已經默許這個專案的品質是可以降低的了。

從這個角度來說,台灣很多的開發團隊,其實從來沒有從頭到尾好好做過一個案子。許多Developer從一踏入專案領域開始,每天就是在身兼許多案子的狀況下過日子,久而久之,甚至習以為常了。

有一天當他變成PM甚至老闆之後,他會認為本來就可以(應該是)這樣(因為他以前就是這樣的),卻不知道,其實身兼多案才是專案失敗的重要原因之一。

即便專案成員或PM有點sense,但軟體公司老闆卻往往不接受在專案中的專人專用,而總是讓開發人員或PM身兼很多案子,除了人手不足迫於無奈的因素之外,很多老闆甚至打從心底認為,人是可以一心多用的,因為他自己就是這樣。

許多業務或是非技術出身的老闆(或PM),把開發人員當成resource,把team當作生產程式碼的機器,但卻忘記了,所謂的『開發』本質上並不只是一種『生產』,而是一種『創作』!你會要求畫家或是作曲家同時間畫兩張畫,或是同時彈奏兩首曲子嗎? 你會常常要求演員同時演兩場舞台劇? 或是同時間軋很多角色? 你不該會這樣的。

如果可以,我們都會盡量讓畫家、作曲家、演員...做完一件事情後,再去做另一件,因為知道這樣才能真正有『效率』,因為知道這樣才能開始談『品質』,一心多用中間的轉換成本很高很高。人腦要一心多用,在創作上是很困難的。

但老闆們(或PM)們卻常常不以為意,因為從他們的經驗上來說,人是可以一心多用的。不是很多主管同時帶兩三個部門嗎? 不是很多老闆同時間負責很多決策嗎? 不是很多經理同時間看很多案子嗎?

我要說,實際上很可能是,因為他一直沒有真正的投入過,才會以為人可以一心多用。

不要拿管理部門來說,拿養家活口來說吧,正常來說,一個負責任的男人要養一個家庭,再帶2個小孩, 如果真要認真投入,幾乎得要花上自己的全心全力。你能想像一下,如果你要同時養兩個家庭,同時照顧四個(兩組)小孩,同時有兩個老婆要養,同時有兩個結婚紀念日要過,同時有兩個年夜飯要吃...那...會是一種怎樣的人生呢? (相信我,這該不會是一種幸福的)

有另一件事情說起來也很弔詭,幾乎每一家公司,都不希望員工晚上兼差, 幾乎每一家公司,也都不希望員工下班後額外接自己的案子,理由不外乎是,兼差會讓員工分心,無法專注在公司的工作云云...

有趣的是,若老闆真的這麼相信,那為何在公司自己的案子上,卻又總是讓員工『兼差』呢?

的確,或許能否一心多用可能跟這個人本身的能力有關,歷史上也不乏可以身兼多職的能人異士,但,這畢竟是少數,且不管能力再強,每個人都有上限。經驗上告訴我,越能夠『快速專注』的人,越有機會可能可以同時間參與很多專案,但這很難,也很少見,並不多人擁有超人的專注力。(更何況是薪資領得比較少的junior developers)

因此,對專案最好的狀況是:讓團隊成員就只負責一個案子,並且讓團隊的成員盡可能的專注,always focus在自己的專案上。

我在帶專案時,非常討厭聽到成員跟我說...因為在處理另一個案子的OOXX,或是另一個案子必須開什麼會議、趕什麼文件,所以導致這個案子發生了什麼問題。也因此,如果可以,我幾乎讓專案成員同時間只專注在一個案子,專注在一個目標上,真的非得一人多用,也必須以Sprint為單位,不能在同一段時間,讓團隊成員同時在兩個案子的Sprint中出現。

你還必須知道,除非專人專用,否則時程預估和成本預估所得出來的數值,幾乎會接近沒有意義。

我們在專案中太多的預估,都是假設在專案成員不被其他專案所打擾的狀況下所建立的。因此,只要專案成員開始被其他案子打擾(開始必須要在2,3個案子上switch),那所有的預估值很可能立即開始失效。(這也是專案拿時程預估值轉換成成本來報價時,大多數sale都會乘上2-3倍的原因) 我幾乎可以說,在軟體開發專案裡面,沒有專人專用的化,那麼用多麼豪華的Excel表格或Project做出的時程預估,根本上就是個謊言(或是不切實際的猜測)。

往往你對task的預估,在這個人身上是5,在另一個人身上會變成10,換了人,開發時間膨脹一倍這種事情根本屢見不鮮。如果再加上團隊人員又兼了其他案子,你很快就會知道下場有多悲慘了...

說了那麼多,你就知道我對專人專用有多麼在意了。

但無奈的是,專案身涯至今,只有極少數的partner能夠在不on site的狀況下給我專人專用的承諾(而這樣的partner,也才是我理想的合作夥伴),更好笑的是,我時常看到有些團隊即便on site了,卻還無法實現專人專用。團隊成員人明明被綁在客戶C公司的辦公室,卻依然在處理另一個B客戶先前還沒收尾的案子,然後C客戶的PM打開門進來,整個team把螢幕關掉這樣的狀況...

這不是很可悲嗎?

『沒有專注,就沒有效率。 』這在哪裡都會是個定理。

本篇收錄自 - 『敏捷開發專案管理與架構設計實務

2014年11月3日 星期一

再談薛西弗斯的石頭

『薛西弗斯是希臘神話中的一個人物,他因為卓爾不凡的智慧惹惱了眾神。作為懲罰,他雙目失明並被判永久的將一塊大石頭推上山頂,但最終都不可避免地要承受著大石頭滾進山谷的結局。』-- wiki

第一眼看到這篇,吸引我注意的,當然是照片中推著石頭的薛西弗斯。從某種角度來說,薛西弗斯絕對是一個悲劇人物,而這篇出現在『猴子靈藥Blog』上的文章,也真的道盡了創業者所要面對的辛酸,以及不為人知的心路歷程。

文中有一段,引了『梁宁』寫下的…

『在创业的真空里,没有人告诉你,该做什么,停止什么,该往那里去。你再也不能通过迎合某人的要求而换得晋级。』
上面這段話,我感觸尤其強烈。

因為種種的因緣巧合,我在約莫10多年前,離開了穩定的園區工程師生涯,後來從事寫作、顧問、教育訓練…等工作,一直到後來參與成立自己的公司,雖然這些確實都是我的興趣(何其有幸),但這也確實並不是一開始我人生規劃中曾經考慮的路徑。

不少朋友以為,這樣的『講師』生活肯定多麼愜意。事實上是,離開了所謂上班族的生活之後,要不了多久,你確實就會開始感受到生活的的確確、明顯的和上班時有所不同。

首先,準時早起上班開始變成工作中的非必要條件,但換來的則是忽高忽低的不穩定的收入,以及強烈的不安全感。

我曾經多次跟身邊的朋友說,當你開始變成所謂的SOHO,只消幾個月的時間,你就會發現你無可避免的,會幫自己接下超過你原本上班時所能接受的工作量還來的多很多的工作(所以比起上班時更不自由、時間更少)。為什麼? 很簡單,因為你再也不會有固定的薪資在每個月固定的那一天匯到你的帳戶(我得說,回頭想,每個月能夠固定領到錢,就是一種幸福)。你開始必須自己估計每一筆款項可能進來的時間,並且,預先為客戶可能發生的延遲匯款自己事先做好準備。

在你上班時,你理所當然的認為從來不需要擔心的問題,在你變成SOHO之後,開始變的得要自己小心管理。不過這還算OK,只要謹慎一點、量入為出,積極一點、拼命工作,再加上你的產品(也就是你自己)還賣得出去,那大致上不會出什麼大問題。

只不過,你再也沒有上班時的那種…生了病可以請假、下了班可以暫時把工作丟在一邊、國定假日可以自在地休息…的日子了。當自己要為自己的收入負上100%的責任時,你的人生觀會立刻開始有所不同。

因為你清楚地知道,你得為自己的工作績效與成敗負上完全的責任。如果你有家人孩子要養,如果你有房租或房貸要繳,對面金錢,你就會出奇的謹慎,面對客戶,你會出奇的尊重,嚴重程度到你上班時無法理解、匪夷所思的地步。

如果開始創業呢? 請把上面這樣的狀況乘上個三五倍。如果你不僅只是創業,你開的公司還要付一群人的薪水,那請再把上面這樣的狀況乘上個10倍。(後來我就慢慢地能夠體會上班族口中的豬頭老闆和邪惡老闆的心情)

在成為獨立作者與講師的初期,不只一次(到底多少次根本記不得)的有長輩建議我,要不要找個『收入穩定』的工作做可能會好一點。

沒有辦公室的時候,伯朗咖啡和Starbucks的店員都很熟悉我喜歡點的咖啡和輕食,我不需要說他們就知道我要點什麼,我甚至可以很有經驗地跟朋友(或客戶)介紹咖啡店裡每一種餐點的特色。但,我卻常常不知道該怎麼介紹我自己。

那時的我有很多種身分和工作,我是講師、也是作者、還是顧問,聽(講)起來都可以很炫,但我卻說不出自己屬於哪一家公司,我沒有年終獎金,當然也沒有員工旅遊。很多出版社和教育訓練中心會在逢年過節的時候自動送禮盒給我(這我一直很感激,真的),但我卻始終不知道該在填寫信用卡申請表格的公司欄裡,能夠填上哪一家公司的名字。

我和很多知名企業有合作,好像也認識很多人,但卻完全沒有工作上的歸屬感。當朋友聚會時總會有人問你在哪邊上班? 逢年過節親友聚餐吃年夜飯,大家抱怨年終獎金少的時候…(這些年我從來沒領過年終)這種孤寂的感覺格外格外地強烈。

同時間,工作上的能走方向開始變得既多元卻又模糊,彷彿每一條路你都可以走,但卻又不知道實際走下去之後,會通往何處。真的就如同一開始所說的,『在创业的真空里,没有人告诉你,该做什么,停止什么,该往那里去。你再也不能通过迎合某人的要求而换得晋级。』對錯一切都得自己承擔,勝敗當然也得自己扛下來。

掉了案子或是搞砸一場研討會、你知道完全不需要為自己的失敗找任何藉口和理由,因為不只你想說的時候身邊沒有人聽,即便有,也沒有任何意義。

你所能做的,只是檢討後改進,為下一個可能來臨的機會,自己先做好準備,因為你知道你可以輸個一次兩次,但失敗的次數多了,你本錢不夠因此輸不起。銀行的貸款和必要的支出,不會憐憫你的情緒、不會顧念你的心情…成敗,就是自己(和依靠你的家人跟你一起)承擔而已。

但,如果你還年輕,我真的鼓勵你,試著當當SOHO,或是自己創業一次。Developer是幸運的,我們手上所擁有的技術能力,加上這個時代的科技和工具,讓我們可以只消有台NB,在任何地方都可以發揮你的創意和生產力。

如果你還年輕,不妨給自己一個機會,給自己幾年的時間,體會一下我說的那種心情。日後,不管你是不是重新回到職場,這段經驗肯定會讓你對人生和工作,開始有不同的體會,你將會更清楚的知道,自己人生的目標,和『工作』對你的意義。

-- 摘錄自 『敏捷開發專案管理 與 架構設計實務』 電子書

如何更新PubU平台上的電子書

如果你有購買PubU平台上的電子書,像是『敏捷開發專案管理 與 架構設計實務』。

我們不時會更新電子書,更新時會在我們的FB專頁上通知,當您看到通知,即可試著更新您的電子書。底下以ipad為例,您進入系統後,可以嘗試點選右上角的更新鈕:

接著你會看底下的更新畫面:
完成後您即可閱讀新版的電子書囉。

2014年10月10日 星期五

preparation is the key...

還記得我去年寫了一篇文章,關於『練習』,看看時間,剛好快一整年。

當時寫『練習』這篇文章時,是因為同時間看到了一些讓我挺有感觸的東西。一個是當時跟大家提過的日劇Dinner,一個是Robert C. Martin的The Clean Coder。而剛好那時候又碰到TechDays結束,忍不住把一些心情整理下來,這也是後來在MVP Open day當中,會和朋友們談到我自己的一些學習過程的緣起...

後來,曾經有學員(也是朋友)私下問過我,如果凡事都需要那麼多練習,那豈不是沒有生活的時間了嗎?真的每一個所謂成功的人,都那麼精實的訂定自己的『目標』,都那麼積極的過每一天的生活???

當時我沒有回答,因為我不知道該怎麼回答。

我不知道的是,是不是只有我看到(學到)的是這樣?我無法肯定是不是一個通往夢想或實現目標的正確方程式就一定是如此;同時我也不能那麼肯定,這就是唯一正確的道路。

一年之後,我看到了一場兩年前的演講,讓我可以更肯定地跟朋友們分享:或許我在上課時提到的那些(目標、努力、練習...etc),不一定是通往夢想的標準答案,但顯然不只我一個人這樣做(或這麼想)。

或許通往成功的方向有很多條路,但更多的準備,絕對是讓你在這條路上可以走的比別人更快的方法

可能是因為幸運,我求學階段沒有太多參加補習班的經驗,我也沒有去過台北知名的補習街上過太多的課,所以對於補教界的老師也只是耳聞(雖然某種程度上來我,我自己搞不好也 算是補教界的一份子...),再加上前幾年風風雨雨的補教人生,可能讓很多人從新聞媒體上看到的印象是很負面的。

不過如果暫且撇開這些不談,主講者在工作上的努力,和對於目標的專注與積極的準備,是讓人相當欽佩的。顯然在極度競爭的市場中,要擁有一席之地,倚靠的絕不會是僥倖。

本來只是假日想讓讓自己休息所以找個演講用聽的,點開youtube時不很期待,但沒想到她的演講講的很好,比我預期的要好~非常多...

整場內容時間不短(但卻一點不會沉悶),講到目標、講到夢想、講到教學、講到熱情、講到練習、講到努力、講到核心價值...etc.這些主題都是我熟悉的(甚至是我自己講過的),但能講得這樣吸引人真的很不容易,講者在演講和授課技巧上算相當不錯...推薦給當講師的朋友 或 想當講師的朋友(part 2還談到了教學技巧和怎麼準備好梗)...是場少見的演講

其中一句話讓我印象深刻,呼應了去年寫的那篇文章的主題...『preparation is the key』。

假日,不妨敞開心,聽一場演講吧。
part 1-4
https://www.youtube.com/watch?v=WvN6IQzlFWo&list=PLmqK1wR8I6PefHfEvmLcaXmPBITOwljeP

2014年10月4日 星期六

飛機上的27A - 談敏捷開發的成案問題

 
最近看一本書,書名就是這篇文章的標題『飛機上的27A』,剛好工作上發生一些事情,頗有一些感觸。

這是一本小書,也是一本小說,我是看電子書,但看完之後我又買了紙本書(送給身邊的朋友)。書中一位成功的企業家對於選擇合作對象的想法,讓我重新省思一些幾乎快被我忘記了的原則。

書中主角是一個成功的年輕人,算是在當今這個營營汲汲的資本主義社會中的佼佼者,然而有一天,他在飛機上碰到了這位很不一樣的企業家,在企圖爭取這個企業家成為他的客戶的過程中,他所學習到的一些故事。

看完這本書後,讓我回頭思考的問題是,這個世界不知道從什麼時候開始,充斥著各種商業與管理技巧,各種tips類型的準則,讓我們目不暇給,眼花撩亂。時間管理? 談判法? 如何成交? 銷售的心法? 甚至連生活都有小技巧...然而被這些tips轟炸的同時,我們都忘記了很多最基本的原則。

其中之一,就是『誠信』。

為什麼對這個特別有感觸?

書中的企業家選擇合作的廠商,首先看重的不是獲利能力、不是資本額、不是折扣的高低、或是交易的利益。而是這家公司的誠信、道德操守、以及員工、經理人的人格特質,和公司文化。

我發現上面這一行最後幾個字,幾乎是我們現在在報章媒體上已經很少看到甚至很少被用的文字了。

最近一兩年,我們的開發團隊整個改為agile與scrum,然而碰到最大的挑戰,並非制度與工具、也不是人員或方法。坦白說,最大的問題是外部的客戶、採購與銷售。

Scrum在意團隊,也在意客戶,agile從軟體開發最原始的角度出發,我們希望建構一個客戶能用、好用的軟件。說真的,這可能是每一個軟體開發人員最原始的初衷,沒有人希望自己寫的code只能看不能用(或是不能看也不能用)。

然而,從這個角度出發,實際上會碰到最嚴重的問題,其實往往是『信任』。

依照Scrum,最合理的合約與付款方式是time material,也就是合約金額不固定。原因很簡單,因為我們隨時接受需求變更,如果隨時接受需求變更,那總工時當然也會跟著變更,沒有道理總工時調整了,合約金額卻不變吧? 這種合作模式,time material當然是最理想的付款選擇。

然而,這在台灣幾乎被視為不可能。

客戶總是希望固定付款金額,固定工時(遲了還要罰錢),但需求內容則在成案後還是會變更(好一點的客戶會註記變更幅度不超過15%之類的),麻煩的是,許多案子在成案前也無法把規格或scope確定(或許從客戶的角度來說是確定了,他有提供三張A4描述了SOW啊?但對我來說靠這三張A4要精確地算出專案成本,根用猜的差不多吧? 更何況還要落在合約上?)。但如果選擇先談好規格再簽約,則往往案子不成,SA成本卻又已經付出了。

當然,我們知道客戶的老闆想知道完成這案子大概要花多少錢,這我們能夠理解,但合約上能不能不要寫死那個金額還加上罰則呢?不行 >_< (很多客戶會質疑,你們又不是on site做案子,我怎麼知道你會不會浮報工時?我心裡想:難道我們on site就沒法浮報工時嗎? 你就能肯定我們寫的code一定和你的案子有關?)

因此軟體廠商為了自保,只好在時程預估上保留很大的buffer,膨脹工時或是人天數,以避免案子賠錢。久而久之,買方採購就習慣拿到報價先砍個2-3成,接著的拉鋸就是看買賣雙方的談判技巧了。

這樣的報價模式,廠商留有buffer,買方採購也可以交差,剩下就聽天由命了。如此一來,痛苦常常發生在專案開發團隊(一直碰到需求變更而無法結案)與軟體終端用戶(最終拿到可以驗收卻無法用的軟體)身上。

從整個交易過程和行為模式上來看,你很容易發現,這種deal其實是一個假雙贏的零和遊戲。本質上買賣雙方幾乎沒有進行第二次交易的打算,似乎都想幹完這一票走人的感覺。

有時候買方會說,Eric你放心,我們後面還有很多這樣的案子。有經驗的Eric心裡會想:你少唬爛我,我這筆先賺到再說,大不了不拿尾款(當然,表面上肯定不會這樣說)。

這種交易裡面少了什麼? 對,就是我想說的:『誠信』。

在累積了幾年的接案經驗之後,我大概得出一個結論:只要客戶企圖用最低的價格讓你做這個案子,那表示該客戶後面肯定幾乎沒有其他案子會給你。

久而久之,我開始把報價越拉越高,主動放棄需要用價格來競爭的案子,因為我不想要(我需要、但不想要)這樣的客戶。我希望跟客戶的合作建立在誠信上面,我希望培養的是長時間的默契與往來,我希望真的透過我們團隊的技術與經驗(這才是真正值錢的部分,我的客戶你必須認同),協助客戶解決難題。

因為這樣,我們必須放棄很多的案子,因為客戶和我的理念與公司文化不合

坦白說,這很辛苦。我甚至也不知道值不值得。

但回頭想想,難到不該這樣嗎?

看看身邊,最近台灣很多食安的問題,不也是因為誠信? 賣你黑心商品的上游廠商,心裡想的也是賺一票走人的邏輯、考慮的不是永續經營,而中間廠商只願意用最低的成本採購原料,用最有競爭力的價格賣給消費者,這彷彿已經是商業既定的唯一真理。(但競爭力怎麼來的呢?壓榨了誰呢? 犧牲了什麼呢? 卻沒人在意了)

記得有天我感慨的在臉書上寫到:『在這個時代,大多數人都遺忘了一件事情,就是商業行為一開始是建立在信任和誠信上的。如果大家還有印象,就會發現以前(近百年前)的廠商,對信用這兩個字很在意的,人無信不立,說到的就一定要做到,撒謊和欺騙是一件很嚴重的事情。但這個時代變了...所以其實重點是在,重新建立一個和消費者之間的信任的過程...

(想一想其實很好玩,30多年前我記得沒有超商的時候,巷口的雜貨店老闆我是認識的,他住在那,從小我就看著他長大,老闆的兒子是我同學,我100%信任他賣給我的東西不會有問題,但時代變了,7-11可以讓我買到遠在海外不知名的地點生產的加工食品,但我卻再也沒辦法信任這些賣我東西的廠商...)


科技是進步了,但我們在商業行為中慢慢失去了最原始的信任。

台灣在中小型的軟體專案當中,報價空間是非常大的,差價大多來自專案團隊的經驗、以及許許多多看不見的東西(專案管理技巧、需求分析能力、控管能力、對品質的要求、問題追蹤能力...etc)如果客戶像是選擇香豬油一樣用最低的價格來選擇一個軟體開發廠商,所能得到的軟體能吃嗎? 喔,當然可以,就像香豬油一樣,只不過就是有點不衛生罷了...

2014年10月1日 星期三

廣告:敏捷開發專案管理 與 架構設計實務(電子書搶鮮版)

本手冊是光岩資訊董大偉老師在『敏捷開發專案管理與架構設計實務』課程中的內部訓練教材。董老師以十多年軟體專案與產品開發經驗為基礎,採用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生存之道,是一本與資訊技術密切相關,卻又適合技術人員在茶餘飯後細細品味的書籍。

言盡於此,其餘的,就由讀者自行體會了。

此版本為搶鮮預覽版,後續會持續更新(如何更新),但也可能調高價格!(越早買越便宜) 更新後,先前購買的讀者依舊可以免費持續下載最新版本。需要的讀者可以到這邊搶購。物超所值啊!!!

===============================================
序言
讀者須知
目錄
第1章 先讓我們來聊聊Scrum
 1-1 對於Scrum的看法
 1-2 Scrum中的角色與做法
第2章 專案工作項目的管理
 2-1 從Kick-off開始(建立第一個專案)
 2-2 從蒐集Features開始
  2-2-1 蒐集Features
  2-2-2 建立Features
 2-3 從Features展開Backlogs
  2-3-1 Backlogs的細節
  2-3-2 設定Backlogs的階層關係
  2-3-3 Backlogs的狀態與歷史紀錄
  2-3-4 Backlog的異動Alert(Notification)機制
 2-4 Task的建立與撰寫
  2-4-1 建立Task
  2-4-2 剩餘時數 與 燃盡圖
  2-4-3 指派工作負責人員
 2-5 工作完成狀態 與 相關的圖表
  2-5-1 累計流量圖(Cumulative Flow Diagram)
  2-5-2 燃盡圖(BurnDown Chart)
  2-6 控管每一個bugs
第3章 Scrum專案週期性工作與會議
 3-1 Scrum中Sprint的周期性工作
 3-2 Planning Meeting
  3-2-1 確定目標Sprint Goal
  3-2-2 決定Sprint Backlogs
  3-2-3 決定該如何完成?
  3-2-4 架構設計的衝突
 3-3 Daily Scrum與Team Room
  3-3-1 關於團隊
  3-3-2 關於溝通
  3-3-3 每天溝通
  3-3-4 線上溝通
 3-4 Demo Meeting (Sprint Review)
 3-5 透過Request Feedback取得Stakeholders的反饋
 3-6 Retrospective Meeting
第4章 程式碼版控(尚未完成)
第5章 建置與測試(尚未完成)
第6章 關於CI(Continuous Integration) (尚未完成)
第7章 雲端壓力測試(尚未完成)
第8章 開發人員的密技(尚未完成)
第9章 透過框架設計提升Scrum(尚未完成)
第10章 開發人員私房話(尚未完成)
第11章 專案管理私房話(尚未完成)
第12章 咖啡館呢喃 (尚未完成)

2014年9月11日 星期四

[研討會] TechDays 2014 Taiwan

每年到了九月,總是會把這一段時間保留下來,並且特別準備好醞釀了好一陣子的內容,和學員們度過這幾十分鐘。

http://www.microsoft.com/taiwan/techdays2014/default.aspx

今年比較特別,比起往年總是分享特定的開發技術,今年則是首度和學員們分享軟體專案管理、ALM(Application LifeCycle Management)以及Scrum/Agile的導入心得,對於陪著我一起學習成長的學員來說,應該會有著不同的感觸吧...

相關的Slides可以從這邊找到:
http://www.microsoftvirtualacademy.com/training-courses/techdays-taiwan-2014-breakout-sessions-dev

課程編號是DEV307...

不過我得說,現場參與跟會後的錄影,氣氛真是差太多了 :)

2014年8月26日 星期二

[影片] WP8 1 Navigation Model 簡介 - WP8.1/Win8.1 App


底下這段影片,是2014八月底在微軟7AB跟學員們介紹WP8.1的開發以及Universal App的部分Demo片段(重錄),如果對同時開發WP8.1與Win8.1 App(也就是Windows Store App)有興趣,想知道 WP8 1 Navigation Model ,可以參考底下這段影片...
 

[影片] Common Xaml UI Framework, 簡介 - WP8.1/Win8.1 App 如何共用XAML UI與Code

底下這段影片,是2014八月底在微軟7AB跟學員們介紹WP8.1的開發以及Universal App的部分Demo片段(重錄),如果對同時開發WP8.1與Win8.1 App(也就是Windows Store App)有興趣,想知道如何手機和平板如何共用XAML UI/Code的開發人員,可以參考底下這段影片...

2014年8月21日 星期四

[研討會] 初探 Windows 市集 APP 開發 (Windows 8.1 / Windows Phone 8.1)

 
 
很高興能夠再一次跟大家介紹嶄新的Windows Phone  8.1相關開發技術,這個場次相關的內容,包含投影片、範例、以及影片和書籍,將會在近期公布,請持續關注本網站或加入 FB 專頁:  https://www.facebook.com/DotNetWalker