Ruddy Lee 分享空間

Emergent Design 演化設計

Archive for 十二月 2014

Agile But: 我愛敏捷式開發,因為我可以任意更改需求

leave a comment »

(這是典型的Agile But的錯誤觀念。遺憾的是;好幾個我帶過的團隊也遇到這種事件,卻採取了錯誤的解決方式,也就是回歸合約的限制來處理這件事,難過之餘才決定在這裡描述一下敏捷的用意。這裡引用專案鐵三角來做說明)

.

»  工程師: 你可能會覺得如果放任「客戶」任意的漫天更改需求工作會做不完對不對?

.

一個錯誤的觀念: 客戶知道你在RUN敏捷開發因此就認為可以隨便定義需求,因為反正隨時都可以再去更改它。其實敏捷開發在迭代的開發循環中是不會去變更需求的。

SCRUM 比傳統的Waterfall方式更重視需求,SCRUM的團隊採用專家模式的方式讓全員一起來聆聽客戶描述它的需求(這個成本很高)。甚至在團隊內製造一個站在客戶端代表客戶立場的代理PO角色(至於估算工時的方式也是採取全員一起估算的方式),這是為了那些不能加入我們團隊的客戶所設立的角色,他代理客戶負責闡述需求的責任。

Scrum 採取迭代式短時間的循環模式,我們堅持在一個循環內不去變更需求,需求的變更是客戶看了我們所做的展示後,進一步的厘清了產品的需要後,所提出有必要的變動。一旦做了《需求變更》大家都知道,我們是在浪費資源,先前所作的可能都白做了,但它的更改對客戶而言比起我們所浪費的工作,還是值得的。(算是學習的成本)。

.

專案鐵三角

時間 Time + 金錢 Cost + 範圍 Scope = 品質。這個模型依然適用在敏捷式的開發方法。傳統的法則是由Scope去驅動Time跟Cost。而Agile的精神則是由Time跟Cost去驅動Scope。

.

由何時要? 預備花多少經費? 來決定你能做出來的成果。

(換句話說;就是資源是固定的)

.

這一點跟裝潢業十分類似。也就是資源是固定的模式。當客戶開始變更需求時,它就是開始在浪費資源的時候,因為time與 cost在不做變動的情形下,客戶所提出錯誤的需求會造成開發團隊必須做出相對應的變更(返復)工作,當然會開始浪費資源了。

概述一下專案鐵三角:
專案三角也稱為「鐵三角」,更實際的說法則為「三重限制」。無論怎麼稱呼,說的都是同一件事:您無法變更專案的預算、排程或範圍,而不影響另外一個或兩個部分。

其運作方式的部分範例如下:
• 若要配合完成日期 (時間),您可能得耗費更多資源 (金錢) 以便更快完成工作,或刪減功能 (範圍) 以減少新期限之前的工作量。
• 若要在預算 (成本) 內完成專案,您可能無法加班,而且得延後完成專案 (時間) 或是刪減功能 (範圍)。
• 若要新增產品功能 (範圍),您可能得延長截止期限以便為新工作爭取時間 (時間) 或增加人力以便更快完成工作 (成本)。您也可以同時執行這兩項策略!

鐵三角

品質是專案三角的第四個部分。它坐落於中心,而且變更任何一邊都會影響品質。
(參考自 Office Online)

.

»  客戶: 所有的需求項目都必需完成,也就是合約上所註明的項目都必需完成,才算結案。

.

一個錯誤的觀念:必須完全依照合約上所設立的範圍來工作(大家還記得應用程式的大部分功能,就有百分之四十左右根本沒有人在使用)。但專案開發真正的目標應該是做出一個好的產品、好的解決方案才是。

.

何謂「敏捷合約」?
長話短說;它的意思是在每一次展示進度給客戶觀賞的Demo會議上,客戶看到已經足以使用的展示時(即使它對全部功能數而言只達到八成左右的比例),便會要求開發團隊何時可以拿來正式上線了。理由是;它已經堪用了! 客戶在越早獲得產品對市場越有利的前提下,希望提前取得軟體程式。而這種提前交付的情景打破了合約的限制模式。(但前提是;我們必須用功的開列需求,並對需求做正確的重要性排序)

.

如果你還認為我講得太不食人間煙火了,請去試一下你的敏捷指數《 Agile But 的測試網頁

.

另一個錯誤的觀念: 客戶常會說既然這些報表不用做了,我們就把它拿來換取另外這些功能,如何?! 這個問題我們下回再談。

廣告

Written by ruddyllee

2014 年 12 月 27 日 at 17:27:05

張貼於未分類

Tagged with , ,

個人看板:滑手機的綠色思維

leave a comment »

如何做好個人的時間管理呢!,要勤於滑手機;並在滑手機的時後進行「個人看板」的更新行為。

subway

台北捷運候車時的低頭滑手機盛況

在採用個人看板做時間管理時,你經常會出現一個問題,就是不知道更新個人看板的時機。我個人的習慣是早、晚更新,有時是空閒的時候不經意的更新。這要看你的環境及個人配備和採用甚麼App。

.

睡前的沉思時刻

這是我最喜歡更新個人看板的時機,也是我幾乎不會忘記的時刻,做久了你會覺得這是一種享受。 一整天的收穫讓我帶著他們入夢吧!這是事事順心的時候,免不了會有不順利的時候,(擔心的時候)這個時候我會更用心地看他;還是來仔細的審視一下那裡還有機會出紕漏。哈哈!久而久之,不看是不能入眠的(記得要調整好床頭看書的角度)。

有空就進行的審視行為 — 滑手機

看板是一種即時性的系統JIT: Just In Time,完全符合隨時隨地性的更新行為。老實說:「它是滑手機的最佳時機」。在看板上面有空缺欄位出現的時候才能進行新的做業,這是拉動系統的一種特色。不會讓工作變得凌亂無序,適合那種缺少管理的理性思維的人來採用它。而且它的效益無限,個人看板能讓你做些什麼? 為什麼它值得你用滑手機的時間來做它呢? 細說如下: 透過個人看板的運作,你能看到:

  • 你想要的是什麼? (What you want).

  • 你做了些什麼? (What you do).

  • 你是怎麼做到的? (How you do it).

  • 你跟誰一起做的. (Who you do it with). 

  • 這段時間,你完成了些什麼. (What you complete).

  •  那些是你尚未完成的? (What you leave unfinished).

  • 你做事情的速度如何? (How quickly you do things).

  •  是什麼原因造成你的瓶頸? (What causes your bottlenecks).

  • 是什麼時候?為了什麼造成拖延. (When and why you procrastinate).

  • 是什麼事情會造成你著急? (When and why certain activities make you anxious).

  • 你能承諾些什麼? (What you can promise).

  • 什麼情形之下,你可以說不! (What you can say No to).

看起來相當令人驚訝,個人看板竟然有這麼大的能耐可以讓我們看清這麼多事情。原創者是這麼說的:

Personal Kanban:

Mapping our work allows us to navigate our life
將工作視覺化在看板上,能使我們主導我們的生活。
 ( Jim Banson. )

Written by ruddyllee

2014 年 12 月 07 日 at 11:37:29

工程師如何估算工時?

leave a comment »

當上級過來詢問『這個工作要作多久?』你要怎麼回答呢?

範圍呢? 它可能是:

* ㄧ個功能的小修改。
* 新增一個完整的功能。
* 一個人的專案開發。
* 一個3到5個人的開發團隊要接手一個新專案。
* 一個古老系統的重新開發,人力、時程…,都要一起估算。
* …
* 哈,可能只是一個構想,但總要估個時間來作參考啊。

而你可能是一個工程師或是這個專案的負責人,請問要如何估算開發的時程呢?

.

(基本上;不管你怎麼估算,都不會太準確的《這是軟體開發的特性,不是個人的問題,別太在意》。不如花一點時間,多收集一些資料,然後運用參考、比較的方式來進行估算,這樣會準確許多。但! 這還是在猜測。 不如針對整個開發團隊訂下簡單的規範,讓大家一起來遵循,會有意義的多。以下是我建議的做法: 「信心點估算法」)

.

長久以來,我們都用直覺或是猜測的方式來回答這個問題,即便是曾經作過,有經驗可供參考。但基本上;還是很難像補輪胎的師傅一樣的回答: 大約 10 分鐘!

.

※ 對個人而言

工程師由第一天開始寫程式開始,就會被不斷的問到這個問題,怎麼回答呢? 老實說,只要你是用猜的,他就不會準! 但;如果不用猜的話那要怎麼辦。正式的回答是:

「給我一點時間,讓我進一步了解一下! 」

— 接著; 用科學的方法: 盡快的依靠觀察、組織、搜尋,用切割成小的區塊再整合起來的方式去架構出來你需要的估算,最基本的作法就是切割成小組件來估算,在一塊兒的加總起來(Divide and Conquer)。

.

老闆當然不會給你太多時間去進一步了解一下的! 很快的,工程師就必須給出一個預估的時間(把我這篇文章給老闆過目一下,老闆在閱讀的時候還可以換取一些時間),接著呢! 這時候;就應該趕緊去理解這個問題,要明白當你越快弄清楚了,成功的機率就越大!(軟體開發的過程,就是一種學習的過程,學得越好,程式才會越正確)

 

估工時2

圖一. 運用信心點的估算方式

請注意!

第一次的估算純粹是猜測,不是承諾。要我真正的承諾,等我的信心點出現。

第二次的估算,是有信心後的估算,它是承諾。

上面這一張圖是我上課的時候常常建議給學員們的方式,在第一時間點(專案還沒開始時,時間=0),不要甚麼都不做就去猜,至少要透過「進一步了解一下」的方式,才給出「預估」的時間。

然後在專案進行到產生「信心點」時,再來給上級「承諾」。此時的承諾可能要比當初的預估時間要準確許多了。這是我經常要求工程師的動作,隨著我們對專案問題的了解越來越深入,自然會越有把握何時會做完(這個時候務必讓主管也知道一下,這一點非常重要,它叫做專案的透明度)。

上面的「信心點」就是我們對自己工作的把握程度。我一般把它訂在專案開始後 1/5 到 1/3的時間範圍內(這裡的比例是根據不確定性錐的曲線所得來的(Cone of Uncertainty),1/5到1/3的時候剛好是不確定椎急速收斂的區間,這個時候是我們對專案的相關智識快速增加的區間,也就是我們開始大量熟悉它的時候,因此我習慣在這個時候要求工程師給予承諾。工程師經常在還不到1/5時就跑過來拍胸脯了。好啊! 有信心是好事!)。通常在時間到了(到達1/3的開發時間)的時候,我會再要求工程師給一次估算,然後慎重其事地說,這一次可是「承諾」了。雖然這個承諾基本上還是猜測,但他至少是一個較值得我們一起去努力達成的,一個比較有意義的奮鬥目標(其實他的意義已經遠勝於承諾的價值了)。

Cone01

不確定性錐Cone of Uncertainty

這樣子的做法是對工程師的一種尊重。但是工程師應該要主動做這件事,不需要主管再來確認。(請參考: Steve McConnell 的不確定性錐)

.

制定簡單的規則

一、當我們被要求要做估算時,不要在第一時間就做出回答。應該要花一點時間,多收集一些資料,運用參考、比較的方式,來做第一次的估算。(請參考2002年諾貝爾獎得主Daniel Kahneman所著的: 快思慢想 ,他說沒有經過較多時間思考就做的回答,往往錯誤率會偏高且容易被問題所誤導)

二、在提出估算之後,要持續去追求對專案問題的瞭解,盡快找到「信心點」,在產生了信心之後,主動向主管做出承諾。承諾是第二次的估算。然後團隊就可以以此為共同的目標,努力的去實踐它了。

.

工程師如何估算工時? 讓他依照團隊所制定的簡單規範來做預估,千萬不要讓工程師各自為政沒有一定的準則在做估算,上面的二個簡單規則,歡迎參考,我稱它為「信心點估算」,信心點越提前,我們就能越快獲得工程師的承諾。而提前的因素很多,多做測試就是一個,請這方面的專家來演講也是一個。

.

為什麼要給工程師二次估算的機會呢?  因為這樣做是值得的。

.

(還記得實施Scrum的時候,會要求團隊自我管理時要制定簡單的規範嗎? 這就是了! 但我還是囉嗦一下,執行簡單規則要成功必須有一個要素,那就是「共識」! 一定要有共識;讓團隊、老闆看一下這篇文章,討論一下,制定你們自己的規則。造成共識是成功的第一步…)

.

※ 至於對團隊的專案預估。如果你還在採用一個人一天工作八小時來作估算! (我的天啊!這個時代還有人這麼做嗎? )請問你上班時不開會或接電話或上網嗎? 這個議題待下回再聊了!

.

值得參考的一本書: [軟件估算:“黑匣子”揭秘], by: Steve McConnell

Written by ruddyllee

2014 年 12 月 03 日 at 13:04:33