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為例,您進入系統後,可以嘗試點選右上角的更新鈕:

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