l

2018年8月24日 星期五

我沒有被盜帳號之Scrum新詩

August 24 18:09~18:41

螢幕截圖 2018-08-24 18.40.47


好詩、好詩

前幾天在搞笑談軟工Facebook社團貼了一首詩:

我的目標

我想要愛你,而不控制你;
欣賞你,而非評斷你;
與你一起,而不侵犯你;
邀請你,而非強求你;
離開你,無須多言歉疚;
批評你,而非責備你;
並且,幫助你,但不看輕你。
如果,我也能從你那裡得到相同的,
那麼,我們的相會就是真誠的,
並且,會豐盈彼此。

朋友看到嚇了一跳,以為Teddy被盜帳號。這首詩的作者是已故家庭治療大師Virginia Satir(維琴尼亞 薩提爾),出版於《Making Contact》。上面的翻譯是取自於簡中版《與人聯結》,以下為繁中版的翻譯,與簡中版稍微有點差異:

我的目標

我想要愛你,而不抓住你
感激你,而不評斷;
參與你,而不侵犯
邀請你,而不要求;
離開你,而不歉疚
批評你,而不責備;
並且,幫助你,而不是侮辱。
如果我也能從你那裡得到相同的
那麼,我們就會真誠地相會
而且,豐潤了我們彼此。

***

與人接觸

讀到這首詩的第一個反應:「耶,這不是理想ScrumMaster的內心獨白!應該列為ScrumMaster必背新詩。」但後來想一想,不只是ScrumMaster,每個人都可以把薩提爾的「我的目標」當成自己的目標。

如同《薩提爾的家族治療模式》中所提到:生存的姿態,不需要討好、指責、超理智和打岔;只需要一致。

提高自己的價值感,保持一致性,你也可以達到薩提爾的目標。

***

友藏內心獨白:所有的問題都是人的問題XD。

好的理論就是最好的實踐

August 23 23:28~24:00;August 24 00:~00:28

螢幕截圖 2018-08-24 00.13.27

▲貼上封印的實務做法將使電腦無法洩露資料… (黑人問號???)


施展不開的苦惱

Teddy有一個很認真學習的朋友,有機會就到外面上課進修。最近這位朋友告訴Teddy他在學習上的一個困擾…

朋友:我上了很多課程,尤其是實戰班,我都有好好的練習。只要我回公司之後,在工作上遇到的問題跟上課時所教的問題一樣,我就能夠處理。但是,只要稍微有點不同,我就不知道要怎麼處理。

聽完朋友的敘述,Teddy的第一個反應就是—「你只是照著人家教你的特定招式練習,你根本沒有真的學會啊。」這種學習模式,只要情境稍微改變,原本罐頭式的解決方案很可能就派不上用場了,而你又不知該如何調整原本的罐頭,讓它在新的情境中派上用場。

***

理論和實務

理論和實務,經常被視為學習天平上的兩端。理論給人的感覺就是抽象、嘴砲、和社會脫節、無法實戰等。實務給人的感覺就是具體、立即可上手,就好像武俠小說中吃了天山雪蓮一樣,立刻增加一甲子的功力。

實務就好像例子(example or instance),非常具體、容易理解且容易照做。如果實務所描敘的情境(context),與問題(problem)和你工作上所遭遇的相同,便可立即套用。但通常越具體、越實戰的實務,其適用的情境也越特定(越窄)。所以,同一種「類型」的問題,可能衍生出數種甚至數十、數百種例子。如果沒有理論基礎的支援,沒有建立分析問題的框架或模型,需要靠自己慢慢地累積各種實戰經驗,然後再抽象化成為自己腦中的解題模型。這是一個冗長的過程,很多人還沒走完這個過程就放棄了,永遠都在「學例子」,而沒有學到例子背後的共通理論基礎。

***

建立收納知識框架

這幾天在某本書(這幾天看的書比較多,忘了哪一本。應該是溫柏格的某本書中引用另外一個人的話,要再找一下)讀到一句類似的話:

好的理論就是最好的實踐,因為它放諸四海皆準。

真是太有道理了。如果你的學習過程,發現自己都在忙碌的收集流行術語,以及參加各種經驗分享,搞到最後自己越學愈心慌。此時就應該停下來思考一下,你有看到人家背後的理論基礎、框架或模型嗎?

舉個Teddy自身的例子,Teddy博士論文的題目是「Java例外處理設計與重構」。一開始Teddy並不是研究這個題目,而是先研究pattern language,幾年後改研究design by contract裡面的contract specification。design by contract其實包含了contract specification與exception handling,但當時Teddy覺得exception handling太難,雖然有很多程式範例與所謂的best practices,但就是缺少一個理論框架,所以這一大堆例子與best practices在實際應用的時候經常互相衝突或不足夠完整解決問題。柿子挑軟的吃,所以Teddy一開始只研究contract specification。

後來陰錯陽差,花了許多時間研究exception handling,也建立了一個理論框架(很簡單的理論XD)來解釋例外處理設計的問題。有了這個框架,分析與設計應用系統的例外處理就變得很有系統化。

***

要怎麼從別人的教學中建立知識框架?最重要,也是最簡單的一點,就試看看教學者有沒有給你源頭參考資料。有些人強調自己的內容就是「原創」,但事實上這個世界真的「原創」的知識非常少,絕大部分都是建立在前人的知識體系上增加價值。好的實例,應該要建立在某些理論基礎之上。上課時可以不談這些理論基礎,但必須要提供參考資料,讓學習者課後有機會可以藉由進一步學習理論基礎來建立收納知識的框架以及培養自我解決問題的能力。

小心「斷水流式」的第二手 (第或N手)知識傳遞,無法追源溯流的知識只能在非常特定的情況下使用,跟「呼名大法」(請參考〈自我感覺良好神功(1):呼名大法〉)相去不遠矣。

***

友藏內心獨白:巨人知道你站在他的肩膀上嗎?

2018年8月21日 星期二

自我感覺良好神功(1):呼名大法

August 21 09:14~10:16

螢幕截圖 2018-08-21 09.18.24

▲前天在Facebook發了上面這則短文,有朋友跟Teddy反應,這文pH值太低,讓人看了「不蘇胡」,是不是又在暗中酸人?


呼名大法

▼前天讀了《溫伯格的軟體管理學:第一卷》,p.73這段話,才知道「呼名大法(name magic)」這種說法。當下有感而發,改寫書中的句子才在Facebook貼了那段文。

螢幕截圖 2018-08-21 09.23.24


呼名大法讓Teddy想起很多往事。其一,多年前有一陣子design thinking很流行,有一次Teddy跟一位朋友開會,會議中對方不斷 呼叫 提到design thinking,好像它是一種解決任何問題的萬靈丹。因為Teddy才疏學淺,完全不知道design thinking是什麼,於是弱弱問了一聲:「什麼是design thinking啊?」

沒想到對方突然停了三秒,然後笑笑地說:「其實我的專長也不是design thinking,而是service design」,就這樣結束這回合。

類似例子不勝枚舉,有一次在會議中聽取簡報,報告者不斷強調:「我跟XXX和YYY(兩個中央政府單位)的關係非常好,我已經跟他們都談過了,把產品推到全國幾百個ZZZ單位絕對沒問題」。

此時Teddy弱弱問了一聲:「請問你已經談好幾個單位了?」此時對方才說:「談過一個,但A、B還有C也都非常有興趣。」就這樣結束這回合。

其他舉凡像是:買書不看書,然後告訴別人「啊,這本書我也有」;開口閉口必稱某某大神是你的老師或朋友;自稱年薪幾百萬的矽谷工程師;Google/Apple/Microsoft的員工(或前員工),大概也都有點呼名大法的味道。

一言以蔽之,呼名大法就是A Name Without Quality(有名無實)。

***

人人都會呼名大法

雖然Teddy看似在批評呼名大法,但其實這個招式Teddy自己也常用(遮臉),相信大家也都用過。

呼名大法的用途其實很多,包括:

  • 讓學習者自己心安,形成短時間增加大量能力的表象
  • 抬高身價,意圖使人覺得自己好棒棒
  • 跟上潮流,潮到出水
  • 增加聊天話題
  • 因為弄假成真而促成一些事情發生(可能是好事,也可能是壞事)

成本低、效益大的好招式,不用嗎?

***

破解呼名大法

有一個很簡單的方式可以知道對方是真的懂,還是在施展呼名大法:請對方解釋「名字」的意義。大部分施展呼名大法的人這一關就過不了,但還是有些功力高強的人可以跟你扯上幾句。這時候只要再補上「為什麼」,就可以讓呼名大法現出原形。

***

結論

社會在走,「名詞」要有。技術日新月異,怎麼可能把所有的東西都學會?偶而施展呼名大法,可以讓對話順暢,而不糾結在一些非重點項目。但認真討論事情時,切記勿把別人的力量當成自己的力量,否則說得難聽一點,呼名大法就變成唬爛的一種形式。

***

友藏內心獨白:先嚇嚇他。

2018年8月20日 星期一

薩提爾變革模型

August 20 21:29~22:28

螢幕截圖 2018-08-20 21.14.43

▲薩提爾變革模型,節錄自《溫伯格的軟體管理學:第四卷》 p.67


薩提爾變革模型

這兩年台灣談敏捷(Agile)的人與組織越來越多,嘴砲派、實務派、反對派、隕石派、佛系派等紛紛崛起。從狹義的軟體開發,到廣義的食、衣、住、行、育、樂,似乎萬事皆可敏捷。

談敏捷,就不能不談改變。敏捷談的是靈活性,如何在不斷改變的環境中獲得成功。無論是個人還是組織,要增強對改變的適應性,就不得不回應改變,也就是自己也要持續改變。

改變所帶來的成長總是伴隨著痛苦,因此變革失敗的例子不勝枚舉。在《溫伯格的軟體管理學:第四卷》中,介紹「薩提爾變革模型」,可以運用這個模型來分析變革應採取的行動。

「薩提爾變革模型」指出發生變革的四個階段:

  • 近期現狀階段(舊有現狀):個人或組織的現況,通常表示某種穩定與平衡的成功狀態,大家都熟悉現有的做法。

組織會一直停留在這個階段,一直到「有人」攪亂一池春水,才會打破現有的平衡。這個「有人」,通常是外來事件或外部人員,並不在系統控制者的控制範圍內。例如,外部顧問的加入、重要成員離職、競爭對手發布比我們更好的產品。

  • 混亂階段:既使組織想要推遲改變,但最終因為無法逃避的外部因素,導致只好承認現況無法應付未來的挑戰。之後系統進入混亂階段,原本熟悉的工作模式與方法不再適用,但新的做法卻還未被確定。在此階段人們嘗試各種可能性,甚至走回頭路尋找更早期的成功模式。
  • 整合與實踐階段:經過一段兵荒馬亂的時期,有些新的構想與方法存活下來,似乎可以應付新的挑戰。但組織還不確定,需要更多的實踐與改造,才能讓組織有效適應新的方法,提高組織的績效。
  • 新現狀階段:整合與實踐階段成功便進入新現狀階段,組織重新獲得平衡,不熟悉的工作模式變得熟悉。

***

有什麼用

這個模型告訴我們幾件有趣的事:

  • 牛頓運動定律說:「靜者恆靜,動者恆動」。組織停留在近期現狀階段的力量往往非常強大,由組織內部自發性所引發的變革往往十分困難。因為組織與個人會不斷地否定問題,迴避改變的必要性,這也就是薩提爾所說的熟悉總是比舒適更有力量。畢竟,待在舒適圈的力量真的太強,只要舒適圈依然存在,又何必做出改變呢。所以,要讓組織脫離舊有現狀,經常需要藉由外部力量來推動。
  • 當外部力量介入,組織正在嘗試找出新的工作模式時,此時的混亂階段不宜帶入更進一步的改變,否則組織將會因為無法接受過多的改變,因而放棄走回原本的老路子。例如,組織想要導入Scrum,在團隊剛開始接觸Scrum的前3~6個月內,已經被敏捷精神與Scrum框架搞得一個頭兩個大,此時若持續導入新的工程技術,例如TDD,可能使得團隊無法負擔,最後決定還是用原本的開發方式比較「有效率」。
  • 在整合與實踐後期導入新的變革會比在新現狀才導入要來得好,因為到了新現狀之後,不久新現狀就會變成組織的舊有現狀,此時引入變革的阻力又多了起來。

***

結論

鄉民們可以試著幫自己學習新事物或組織引入新方法的過程對應到薩提爾變革模型,看看目前處在什麼階段。如果一直處在舊有現況,是不是需要帶來一些外部衝擊,就算目前組織現況是「一攤死水」,好歹也可以引起一些漣漪。

有些人很喜歡到處上課,有活動就參加,不吝惜投資自己。但會不會讓自己一直處在混亂階段,而沒有時間去沉澱與實踐所學的技能?

這些都是值得思考的議題。

***

友藏內心獨白:變革需要時間,就跟自己開發瀏覽器一樣。

2018年8月15日 星期三

為了快,你損失了什麼?

August 15 14:33~16:14

螢幕截圖 2018-08-15 16.15.02


問題

三不五時會聽到來自不同公司的朋友提起他們sprint planning meeting的進行方式…

在會議進行的時候,我們分別請UX/UI設計師與程式設計師分組估算他們各自擅長的工作,以便減少會議的時間。反正雙方人馬都不懂對方的工作性質與內容,一起討論實在是很沒效率。

這樣子做,好嗎?

***

緬懷大師

2018年8月7日,也就是一個禮拜前,軟體工程界大師Gerald M. Weinberg(傑拉爾德‧溫伯格)以85歲高齡過世。溫伯格一生寫了很多書,以生活化、輕鬆且風趣的筆法說明艱澀無趣的軟體工程觀念與方法。他的過世,著實是軟體工程界的一大損失。

在溫伯格與Donald C. Gause合寫的《Exploring Requirements: Quality Before Design》(中文版《從需求到設計:如何設計出客戶想要的產品》)書中提到:

發現什麼不重要,重要的是發現(探索)的過程…探索需求的工作事實上就是建立一個團隊。

沒錯,探索需求的工作事實上就是建立一個團隊。只為了「快」就將Scrum團隊依據「專長」畫分成小組,讓小組各自討論得出估算值。這種做法只比讓專案經理或團隊主管一人制定時程要來得好一點,但卻失去了Scrum建議組成跨職能團隊(cross-functional team)的目的,變成「跨職能團隊中的元件小組(component group)」。

***

大師開示

在溫伯格的書中接著提到,若以下任一條件不符合,專案就很可能失敗:

  1. 了解需求要件
  2. (大多數都)貫徹始終參與專案
  3. 知道如何使團隊有效運作

Exploring Requirements: Quality Before Design》這本書是1989年出版,距今29年前,相信那時候Scrum應該還沒有正式誕生。有跑過Scrum經驗的朋友請回顧一下,這三點是否也都包含在Scrum之中呢?

***


友藏內心獨白:不需要做的事情,就不需要把它做好。

2018年8月10日 星期五

【敏捷開發懶人包:Clean Architecture嘴砲班】九月平日班首發團招生中

August 10 14:00~15:20

螢幕截圖 2018-08-10 15.19.07


2018年最新課程

俗話說「水清無魚、嘴賤無敵」,誰說嘴砲不能當一位好工程師?!對於身為技術主管或有志成為技術主管的你,沒時間寫code卻不能不跟上最新軟體架構潮流。

你的需求Teddy看到了,經由Teddy濃縮再濃縮、提煉再提煉的【Clean Architecture嘴砲班】,最適合沒時間深入瞭解的你。由Teddy為你展示Clean Architecture的日月精華,再一起透過最後的精選Clean Architecture專案設計與程式碼評論練習,帶你邁向說得一口好程式的主管行列XD。

***

課程大綱。

  • 軟體架構的定義與目的。
  • 從範例學整潔架構。
  • 整潔架構三原則:
    • 首部曲:分層原則。
    • 二部曲:相依性原則。
    • 三部曲:跨層原則。
  • 邁向Clean Architecture。
  • 嘴砲實戰練習:
    • 精選數個網路上實作Clean Architecture之範例專案,讓學員實際練習評論這些專案的架構設計。
    • 實作細節討論。
  • 回顧。

***

課程效益

  • 一日之內掌握《Clean Architecture》(中文版《整潔的軟體設計與架構》)這本書的重點,讓別人誤以為你已經看完了整本書  為日後深入學習奠定基礎。
  • 了解架構審視(architecture review)所需關注的焦點。
  • 應用分層原則、相依性原則、跨層原則於自己的軟體開發專案中。
  • 透過多個clean architecture 專案的architecture review與code review實際演練,強化嘴砲 架構分析能力,

***

課程費用

  • 原價NT$11,000元。
  • 首發團早鳥優惠: NT$8,900(2018年8月22日前報名並完成繳費)
  • 首發團2人團報,每人只需:NT$7,900。

地點:台北市(近台北車站)。上課日2018年9月4日(週二) 09:30-16:30,共六小時 。

image

***

友藏內心獨白:意圖使人家覺得自己好棒棒。

***

相關文章閱讀