Ruddy Lee 分享空間

Emergent Design 演化設計

需求分析的設計模式

leave a comment »

.

需求不只是需求.

– Kent J. Mcdonald

特性分析法(Feature Injection)是需求分析的一種方法。它的關鍵是理解專案期望的交付價值,並以交付能夠提供價值的特性為目標,同時運用實例來進行溝通與特性有關的信息. 作法:

  • 識別價值

  • 注入特性

  • 提供實例

.

首先、識別價值

0002.png

.

注入特性

Feature Injection

.

》提供實例;是讓模型的整體認識更加清晰的最佳方法。實例可為模型產生測試。

 

.

  1. Chris Matts :  Given-When-Then 的發明人之一( 另一位是Dan North)。
  2. 參考自"超越需求“第五章、交付價值.
  3. 特性分析法;當我們從系統中拉取業務價值時,我們注入產生價值的特性。它與看板的拉動有著相同的原理,但相反的價值流動方向。

.

廣告

Written by ruddyllee

2017 年 11 月 09 日 at 14:19:55

三步工作法思維導圖

leave a comment »

.

0002_8.png

三步工作法思維導圖

.

 

.

Written by ruddyllee

2017 年 10 月 28 日 at 11:04:58

張貼於未分類

Tagged with ,

看見全貌

leave a comment »

.

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

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

所以我們要退後一步,

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

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

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

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

.

0054.png

軟體影響開發速度的因素

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

.

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

一種全貌.png

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

首先;把它畫下來。

.

0002_8

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

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

.

see the whole

整理出來的心得

.

註:

  • 拉遠原則 (Pulling principle) 

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

.

Written by ruddyllee

2017 年 10 月 27 日 at 09:53:55

張貼於未分類

Tagged with ,

工程師多任務單工的作業方式

leave a comment »

.

「解決多工作業的多任務單工作業 Multi-mission but Single Task

– Multitasking is evil

.

Coding! 基本上進行的方式就一定是一個人一個鍵盤的形式,當然或許你同時使用多個畫面,但基本上在做邏輯思考時,一定是一次思考一件事情,程式寫這麼多年來還沒有看過能夠用二隻手同時間寫二支以上程式的人。這是寫程式的天性,一次寫一支程式的進行方式。因此單工作業是不可避免的,跟我們平常一邊走路一邊嚼著口香糖是絕然不同的事。如果你同時間進行多個程式撰寫的工作的話,可以預期的是,工時一定會更長,Bug也會變得更多(請參考下面圖示)。這種弊多於利的作業方式;你還要繼續嘗試嗎?

 

有趣的是,老闆們就是一直把工作丟下來,這一點;造成了幾乎所的工程師都兼具多個任務在身上,很少有工程師能夠一次只作一件工作的(那是一種福氣!)。因此多工作業便成了常態性的現象。而許多工程師會在上一個工作尚未完成時就放下來跑去作別的工作。當然;有時是在工作上遇到障礙或落入苦思無解的情境,就藉著轉換工作的形式來讓思維能多出一些空間來,試著讓自己進入解題的狀況。因此就多工了,這種多工 Multi-tasking的現象,實質上正是殘害邏輯完整性跟程式品質不佳的元凶。下面這一張圖,顯示同時做三件事,跟順序的完成這三件事的時間差異。

.

多工_task3

醒醒吧! 多工只會多增加switching task所花的時間

.

用看板來可視化多工

多工的行為牽扯到的不只是工時上的問題,還有團隊工作分配是否合理的問題,除了能讓團隊更勞累之外同時也會帶動員工的情緒起伏。多工;不管從哪一方面來看對公司或團隊都是一種傷害,但事情一直來,就是那麼多工作要完成,而且它們總是會挑相同的時間一起來,那工程師該如何處理這種情形呢? 這裡運用「多任務單工看板」來處理它,請參考。

.

多工多任務單工作業看板

.

多任務單工作業看板

Multi-mission but Single Task

這是一種以人員為主的看板,上圖中第二個欄位【負責人】就是以工作負責人的姓名為主的欄位,在他左邊陳列的是它所背負的任務,分別依它們的重要性由右至左來排列在【TO Do】欄位裡。接下來是第三個欄位【分析】;這裡可能有工作的細分或進一步的拆解、估算。然後是【執行】、【測試】及【完成】欄位。看板的下方則是緊急渠道。目前正在負責完成工作的人是 Allan。他之前正在做A3的工作,但遇到緊急事件,就先暫停下來,做好了紅色倒三角的標誌之後就下來解決急件了。

它完全符合看板的基本原則,也就是單工的拉動系統作業。工程師在同一時間內只能做一件事。而【TO Do】欄位裡排列的是他所被要求要完成的任務。

.

看板是敏捷迭代開發的縮影

        看板方法沒有任何固定的會議或是角色的定義,它針對的就是流動在欄位之間的工作項目。至於這個工作;可能是一個任務或是一個較大的使用者故事所描述的需求,或單純就是一個工作項目(Task),當然也可能是一個缺陷(Bug)。這一點要看你的工作性質來做定義。上圖中的【TO Do】欄位就像是敏捷開發中按重要性所排列的需求 Queue.而全部的 【TO Do】欄位內的總合就像是敏捷開發在迭代循環中所必須完成的全部工作項目(Sprint backlog item)。它就是整個迭代開發流程的縮影,這正是讓看板十分適合拿來取代Scrum工作板的主要原因。而看板的單工作業原則,就更適合工程團隊拿來解決一般工程師被要求多工作業的問題,拿來設計成看板就成了「多任務單工的作業」的看板了。讓可視化的現象,提供主管看見每位工程師的負荷,讓進度據實的呈現出來,讓相關人員可以容易進行協調工作。它也正常展現了精實開發的基本精神 – 單工作業。

.

工程師千萬別要因爲你被同時指派多個工作就忙著進行多工的開發作業,請務必繼續單工開發的作業模式,但必須讓你的工作透明化,如此其他人才好配合。

.

.

Written by ruddyllee

2017 年 10 月 26 日 at 15:46:14

近代的软件开发

leave a comment »

.

DevOps 隨想…

大家都想要速度,追求開發到布署在速度上的極致,

試想你可以發布得多快,比子彈還快嗎?!

然後呢?

作對的產品!對的「方向」才是王道。

.

近代的軟體開發.png

這是ㄧ個動態的網頁是拿來作演講用的,在這裡只放了靜態的首頁,期待下次的巧遇…

Written by ruddyllee

2017 年 10 月 14 日 at 18:40:48

張貼於未分類

Tagged with

看板的系統思維

leave a comment »

.

DevOpsDays 2017 Taipei 演講資料

.

看板的危機

當看板貫穿在各個理論之間時,不禁讓我們擔心容易被誤導的全貌。

.

系統思維 就是把認識對象作為系統,從系統和要素、要素和要素、系統和環境的相互聯繫、相互作用中綜合地考察認識對象的一種思維方法。系統思維以系統論為思維基本模式的思維形態,它不同於創造思維或形象思維等本能思維形態。系統思維能極大地簡化人們對事物的認知,給我們帶來整體觀。

–        Wiki

當你看不見全貌時,就容易;講不明白、說不清楚,然後學習的時候快不起來。

 

看板為什需要有系統思維?

實踐看板可以讓你看得見流程,讓你看見了自己原來在工作上有這麼多浪費,但其實它是排除了許多細節資訊,讓你的目光能專注在大的工作事項上。這是一種消除浪費的方式,也就是所謂的看見浪費,就能消除浪費。但其實讓你能看見限制才是它真正的目的(要在透過分析前置時間來捕抓最大產能)。但這麼做是有風險的,因為看板太容易讓人落入線性的思維方式了

 

舉個例子; 當我們看到專案在時程上有來不及的現象時,你很容易就會想那就多放幾個工程師進去,就能多吃幾張工作單(Tasks)到開發的欄位裡去了,這樣開發的速度不就能相對的變快了嗎? 這便是一種單純的線性思維方式,一種「基於一分耕耘,一分收獲的思維」方式,那二分耕耘是不是就應該有二分收獲了呢?如果你這麼想;你就會認為解答就是多投入幾個人力來消化工作單不就成了嗎。但這是一種錯誤的做法!

 

請務必變換個思維方式,因為在真實的世界裡,產能是不能用等值累加的方式來計算的。事實是;當你增加人手時;產能反而會因為增加人手的初期先行下降(因為新加入的人員需要透過時間來學習才能像其他人有所產能,在這段新人需要熟悉環境、學習新技能的時間裡 (所謂的;前置時間) 你反而必須浪費最熟這個系統的人來擔任老師,負責教會新手,因此初期產能反而會不升反降),產能要經過一段時間後產可能上升。

 

 .

 

專案來不及時,不要急著增加人手,先弄清楚真正的問題點在哪?

–        人月神話

 

因果回饋圖 + 提問

問對問題可以提供我們正確的思維路線,也能夠觸發自己反思的機會。無疑的;它會讓我們看得、想得更清楚。但;我們要如何來避免落入線性思維呢? 系統動力學之父 Jay Forrest 為此發明了因果回饋圖(CLD: Casual feedback Loop Diagram)來解決這個問題。

 

運用正向因果回饋圖來判定系統的滾雪球效應。用負向或稱之為平衡回饋圖來判定造成系統平衡的因果元素。再加上時間延遲的考量因素,讓我們得以分析並思考問題的解決模式。這便是採用因果回饋圖模式來進行系統思維的分析工作。

.

解題前應該作的系統思維

我作顧問的時候,經常會駐足在團隊後方,遠遠的看著他們進行站立會議。一旁也偶而會有主管來詢問,這麼作的目的。不走近的原因是表達對 Scrum Master 的信任,而採用遠觀的目的則是想更客觀的來思考一些問題。因為看板很容易讓人落入線性思維,因此想再退一步來查看全貌。通常我在想的是…

》是否別被表象所迷惑了

   跟自己說,看到的只是冰山的一角,宛如薩提爾女士的冰山理論所言,人們被觀察到的外部行為,只是冰山浮出水面的一小部份,隱含在水面下的才是內在的應對、情緒、觀點、期待、渴望及真正的自我。而系統思維最有意思的一部分便是他會隨著時間變化而有所改變,他可能成長、停滯、衰退、震盪甚至隨機的改變進化。因此時時的收集資訊,鑑古知今,便成了探索系統結構的基本動作,現在的人都稱這種行為為大數據分析。

》在非線性的世界裡,不要用線性的思維模式

   這是我們依據看板來做決策時最容易陷入的麻煩之一,就是用一種線性的思考模式來研判問題,例如:在土壤裡施100磅肥料,收成可增加10斗;如果施加200磅肥料,收成是不是可以增加20斗呢? 那,300磅肥料,收成便可增加為 30斗呢? 結論當然不是這麼回事。真的這麼做了,甚至可能會徹底破壞土壤的有機質,以至於什麼再也長不出來了! 在真實世界裡,事情往往是多方牽連的,也就是非線性關係的,也就是說我們必須用因果關係來推論反饋的原因和現象。此時;好的提問以及採用因果回饋圖可能是避開線性思維的最佳方法。

》恰當的劃定邊界

   有所取捨,確實最複雜的地方經常都會出現在邊界上,但這些個邊界其實都是人為的定義,是我們將系統硬做區分的,這是簡化的來源也是基礎,看板便是這樣的一個系統,我們簡化了許多資訊,讓實體看板可以剛剛好顯示足夠的訊息,這樣做可以讓我們看得更清楚,但也預作了假設,因此必須恰當的劃定邊界。

 

》看清各種限制因素

   我們通常以單一的原因會引發單一的事件來進行思考。現在這個問題,可能就是先前我們那樣做所引發的後果。這是我們眼界的淺短性所致,但是現實的生活裡,往往是多個原因一同引發多個結果的複雜現象,因此挑選相關因子並做好衡量的工作,就成了決策成敗的一大依據了。這一點在近代的AI人工智能上也可能會有重大突破。但前題依然是我們要掌握正確的因素,才足以問對問題,否則再好的人工智能也很難給出好的回答。

》無所不在的時間延遲

    在系統中每個存量都是一個延遲,這是我在凝視看板時最害怕的一件事了,那便是「時間延遲」,在真實世界裡處處都是時間延遲,延遲時間的長短可以徹底的改變整個系統的表現。但我們在看板上因為它無法受控制,所以通常只是輕易的給上「紅、黃、綠燈」來做依據判斷便是了,因為它可能帶來風險,所以Mark 它是一個風險,實在是一種神話級的處理方式。進行「衡量」可能是較好的一種處理方式(因為這樣便有了機率的依據了)。但究竟該或不該花時間去做衡量可能才是關鍵的困難點。

 

》有限理性

   我們都想做出理性的好決策,但先期的決策,不說你也知道它隱含著大量的不確定性,因此通常可以稱它為猜測。因此盡量的收集資訊,做到自以為合理的決策便成了努力要達成的目標。敏捷Agile在處裡這個問題的方法是迭代持續改善,若能越改越好自然可以逐漸趨近目標,反之;則應該討論是否是認知太貧乏了,便需要一種跳脫的思維模式來支撐了。

 

結論

系統思維的目的是在透過對系統進行分析之後,依靠尋找到的槓桿點來進行事半功倍的解題

.

槓桿點.png

.

作為一位專業的顧問,經常是在開發團隊出狀況的情況下才被請來解決難題的。人們總以為顧問是請來解決問題的,但實質上;身為一位資深顧問,必須跟你們說:「顧問只是請來讓問題比較容易被解決的」。也就是說;真正解題的人還是要靠你們自己,顧問只是用較客觀的角度,用經驗來協助大家解題罷了。而我們經常的解題方式,便是去尋找問題系統的「槓桿點。一種讓我們能夠正確的施力,並換來巨大成效的做法罷了! 其實任何組織平常就應該培養這種解題的能力。上圖是我的建議,最重要的三點是: 1)制定簡單的規範,讓團隊經常做到自我管理,2)形成一個自組織的團隊,3)並善用交互及外來的回饋。讓訊息能夠快速地在組織內流動,它便能經常可以化大問題成為小問題,讓小問題成為生活的插曲罷了。

 

 

.

Written by ruddyllee

2017 年 09 月 03 日 at 18:12:17

2017 Scrum Process Chart

with one comment

.0025.png

.

新增

  • 引導 Facilitation
  • 二代精實 Lean  (Second Generation Lean Product Development)  by: Donald G. Reinertsen
  • 系統思維 System Thinking

.

Written by ruddyllee

2017 年 08 月 09 日 at 16:41:06