[實作筆記]在 Windows Subsystem for Linux 執行 docker

前情提要

最近開始學 Docker, 這個神器大概在 C 社時期就有聽過了,
不過一直沒有機會在實務上接觸,雖然有自已摸一點,但就只有皮毛而已,
在 A 社有機會由同事開課,並提供 EC2 作實驗,就趁這個機會作一點深入的學習。

一開始有一個很天真的想法,我想在 Windows 內建的 Linux 子系統 Ubantu 安裝 Docker, 沒想到最後是脫褲子放屁,不過過程蠻有趣的,稍微記錄一下。

操作步驟

  1. Windows 10 安裝 Ubantu

  2. 在 Ubantu 安裝 Docker

    更新 apt-get

    1
    sudo apt-get update

    允許 apt-get 透過 https

    1
    2
    3
    4
    5
    sudo apt-get install \
    apt-transport-https \
    ca-certificates \
    curl \
    software-properties-common

    加入 Docker 官方 GPG KEY

    1
    curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

    然後可以驗証一下

    1
    sudo apt-key fingerprint 0EBFCD88

    加入 Docker 的 apt-repository

    1
    2
    3
    4
    $ sudo add-apt-repository \
    "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
    $(lsb_release -cs) \
    stable"

    再次更新 apt-get

    1
    sudo apt-get update

    安裝 Docker CE

    1
    sudo apt-get install docker-ce
  3. Run Docker

1
sudo docker container run hello-world

我都會失敗如下

1
2
docker: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?.
See 'docker run --help'.

如何解決

  1. Windows 上要安裝 Docker for Windows

  2. 勾選 Docker for Windows → Setting → Expose deamon on tcp://localhost:2375 Without TLS
    Docker

  3. 回到 Ubantu , 執行以下命令

指定 Docker Host 在路徑

1
docker -H localhost:2375 images

如果不想每次指定的話…請參考以下命令

1
export DOCKER_HOST=localhost:2375

執行結果

學到的事

參考

(fin)

[實作筆記]用 Restclient GenCode

REST Client 是一套 Visual Studio Code 的套件。
可以讓你不離開編輯器(Visual Studio Code)的情況下,發送一些 Request。
使用方法可以參考最後的聯結,本文僅介紹 Code Gen 的功能。

作法

Step 1

取得 Request 連結資訊,這個部份可以直接從瀏覽器取得

大致上如下:

1
2
GET https://***.****.com.my/Invoice/DownloadMyInvoicePdf?shopId=44&tradesOrderGroupCode=MG180929L00002
Cookie: ai_user=zazJ/|2018-04-11T10:01:21.161Z; _ga=GA1.3.1260482009.1526374223; __zlcmid=p9hkxHsXzC5Ka5; _ym_uid=15450340861049673384; _ym_d=1545034086; _gid=GA1.3.233068902.1545616884; _fbp=fb.2.1545992230107.2040829768; .AspNet.ApplicationCookie=1ly--ntvPSpcJIIDvk2PBFfuyy744Wvwx4ezT0c0BEl1t4Vw3ahOOMwSczzBezkE0dIPWBwQt12KPN8IrFj8eV2ZgfO6HYKuiw7cUNgS37Gr1FOH28o-l5EZuOYGd4uuqRduaBBPbZrJop5nUso1oPS4fOs-mFO0I17QWHtfB_BI2Lzd6rQQRl6_IevI_EPbsh0EDahqvR4wvF2QFMH2ycECSzR4pgEmm3hcQRJ9COWoc-DtZjxxa11yfghghmReLbe1cYtx1G7ST9zakc_qGmnMV0IyZoRFqEmHrzEb1b8fDO35UkxsiP2_mzGY-Oy4e3fV12Q0N7eGVblEkJYZkrtXADP8h9iGToPwAUI5rbnX2o32Z0_4zbg7x_GSF_HWsW22SWlkRCAZEKhvhEB9Qk56JPSRSJwqmpGDzm8a807-6lRP-JPOo_F43eYLgztH6k6imlUseUyDyYBTwJeIgF5gdyLKMUSivKs-SOivyPofDiLMf0HItB9IgzRg-M94FjZROtOWeGXOYW4wqBMyABTelYgjfjgNtoW05SN7npnSYKG1JZeRwrT5KgaRXJy7KHkguyN8vhoYTjSX0cG4VaOrJqgGY-jsQov1lJvZTok_YAkiDRbOhDu3ebdJdi313sGSkUjjkW73Fn9ztmpexLN3OxfmhUlDu0MHhEqgLJMg8koLWBJjpmVC0YdNPCXNofGgNECkiWCZHTZw8u9jnLhtP686CG_JTQFE33YTdh3mJOp7KwFdFvQefEX5Jb2vUXmfFXMBP3MhD5civiPg4Q0WLU4; ai_session=XYYeY|1545989192862|1545993911682

Step 2

Ctrl+P,輸入 >,找到 Rest Client: Generate Code Snippet
選擇你的語言。

參考

(fin)

CSM 之後 Scrum 總結

  • 什麼是 Scrum ?
  • Scrum 的理想 ?
  • Scrum 怎麼導入 ?
  • 現實的殘酷
  • 仍然存在的疑惑 ?

什麼是 Scrum

「什麼是 Scrum?」,在這之前我們先問一下「為什麼要 Scrum ?」
「Scrum 之前我們怎麼進行專案的?」、「Scrum 之前我們怎麼管理團隊的?」
層層的組織架構、層層的管理人員、層層規劃設計開發…

本來都好好的,為什麼現在不 work 了?

時代正在改變,軟體、網路、行動裝置等…各種技術的成熟,使得整個社會,
不論工業、商業已經往下一個階段邁進,
這是一個VUCA(多變(Volatile)、不確定(Uncertain)、複雜(Complex) 與混沌不明(Ambiguous))的時代,
新的科技帶來新的生活習慣與消費行為,同時機會也再此產生,
不論是巨象還是螞蟻都必須想辦法求生存,而快速適應與改變的能力,成為這個時代必備的能力。

不論是 Agile 或是 Scrum 都是要讓你適應變化,並且活下去。

而 Scrum 是一個框架,三個大原則,透明(Transparency)、檢驗(Inspection)、調適性(Adaptation)
簡單易學,卻難以精通,這句話說得明白一點,就是很容易畫虎不成反類犬。
而 Scrum Guide 用了一句簡單帶過,
「Scrum’s roles, events, artifacts, and rules are immutable and although
implementing only parts of Scrum is possible, the result is not Scrum.
Scrum exists only in its entirety and functions well as a container
for other techniques, methodologies, and practices.」

常見的「Scrum 自助餐」其實不是 Scrum 。

透明(Transparency)

透明的目的是什麼?避免殼倉?曝露風險?取得共識?

CMS 課程帶給我一個很重要的學習,是個很簡單的老故事就說過的道理。
「盲人摸象」,大家應該都聽過這個故事吧,
有的人摸到了扇子(耳朵)、有人摸到牆壁(身體)、有人摸到柱子(腿)、有人摸到水管(鼻子)…
如果大象是你的產品、你的商業模式、你的生存武器,
那麼展現「雅量」就不是一件很好的事了,
當你的 DBA 說了扇子、RD 說了牆壁,PO 說了柱子而 QA 說了水管,
那麼這些的加總就是你的大象(產品)了嗎 ?

盲人的大象

「所有人說都是對,排列組合也是對的,但結果是錯的。」, 怎麼解決這個問題?

  1. 讓盲人看見
  2. 讓盲人摸得到別人的區塊

透明的目的是為了看見目標、取得共識, 還記得多少浪費生命的會議,有多少會前會?有多少會後討論嗎?
又或是大家都說好,作出來卻是半成品、廢品嗎 ?

取得共識 是困難的,Scurm 提供的機制,
讓回饋在不同的活動(會議)中由不同的角色中產生,
但是如果成員不願意講,這些會議就一點意義也沒有了。

要如何讓成員願意發言?
信任、信賴、安全感,但是這需要時間去打造這樣的文化與環境。
事實上不會喊完口號,成員就彼此互相信任,生產力大爆發。
如何打造一個這樣的環境?是管理職真正的責任所在。
但這種無法立竿見影的工作,喊口號的很多,作的人很少。

檢驗(Inspection)與調適性(Adaptation)

透明在檢驗與調適性之前,是有重要的意義的。
也只有透明,才能讓事實擺在眼前,
不是基於事實的檢驗與修正,只是自慰而已。

無奈的是這個世界是如此的複雜,你幾乎不可能真的看見大象(全貌),
曾經有個創業的朋友說了一個「敏捷無用論」,

沒錯,他說得對。
Agile 與 Scrum 從來不是銀子彈 ,如果要迷信「敏捷」不如迷信「沒有銀彈」吧。
你必需依賴你的情境(Context)來決定使用什麼方法,
在他的情境當中,他們要作得項目已經很明確了,而資金是不足的,所以每分每秒對他們都非常重要,
如果要照表操課這些會議,恐怕會佔據大部份的時間。
但是這些會議都有其背後的意義與目的,如果團隊能與商業目標緊密結合,
甚至是一體同心(比如說:你就是老闆又是開發人員),那麼梳理需求是不是能快速的在幾分鐘內完成 ?
如果你們每個人每時每刻都在一起工作,分享彼此的工作內容,那麼需不需要「每天」開個例會同步資訊呢 ?

反過來說,他說得也不對。
在每個會議與每個會議的產出物的背後都有一個目的與意義,
如果不能讓梳理需求、衝刺開發、展現結果與收取回饋時時發生,
那麼這些會議是最好的機會,更重要的事是 Scrum 給團隊自主權,決定進行的方式,
如果有進行這些活動,卻沒有帶來相對的效益,這背後是不是對 Scrum 沒有深刻理解所造成的呢 ?

這種都對都錯的「盲人摸象」時時發生,
重點是怎麼作「取捨」、怎麼作「選擇」。
也是「Adaptation」的意義,你要欠一些債,爭取提早上市的時間?
你要將一個團隊當作棄子,為了作出一個 POC?
這都是選擇,你是有意識的選擇,還是無意識的呢?

如果你是屬於身不由已的那方,被選擇得對象,那麼你要作出什麼選擇?
讓自已的生存機會提高呢?

Scrum 的理想

Scrum 本身僅僅是個框架,它給了整個團隊非常彈性的空間,
但是仍然有著一些限制。

角色的定位

Scrum Master 要作什麼 ?

Scrum Master 的這個角色,不存在一般的組織架構之中,
這個導致 Scrum Master 的養成非常不易,
偏偏「Master」這個名詞,使得人們對 Scrum Master 有不切實際的期待與依賴
「Scrum Master」本身是個教練型的角色,需要旁觀者的客觀心態,
需要觀察記錄個人、團隊乃至於整間公司文化,
(「記錄與側錄」是重要的,這能讓你從另一個旁觀者角度看事情,不要只有一個視角。)
同時又需要各種方法去教導、引導團隊,這包含「對 Scurm 的理解與實踐」與「工程實踐」
有太多 Scurm Master 常常會犯的錯如下:

  • 淪為安排會議的助理角色
  • 過度將焦點放在 Scurm Master 本身
  • 照表操課的帶四大會議,而不是觀注在團隊的成長與過程
  • 缺乏工程實踐的能力與經驗,導致在引入實踐時淪為空話
  • 身兼不同的角色,造成角色錯亂
  • 無法存活導致被炒,即使有冒出新芽的改變也隨之消失
  • 只顧著存活而無法帶來實踐改變,純粹變成招覽「人材」用的蜜糖(HR:我們有屎逛,很潮喔;進去後才發現是小瀑布,真的很潮)

PM 可以轉型 PO 嗎 ?

簡單的說,當然可以。
你想改變的是你的 Title 還是你的作事方法 ?
理想的 PO 應該更觀注在產品上面,我們希望你會產品有想法、有願景甚至有策略,
如果沒有策略,只是想作一些嚐試也是可以的。

第二點,排序,「我全都要」是不負責任的說法,是大頭症而且偏離事實的中二病
如果團隊也承諾「我全都給」,就要小心整個組織是不是落入「國王的新衣」,集體自我欺騙的困境了
Walking Skeleton 是一個非常好用的手法,在探索出你的商業策略之後,
要找出關鍵的支柱,儘可能快速的推出你的 MVP ,
實際上如果你要你的產品有 Value,你是很難在一個衝刺中完成一個可發佈的產品的
(Demo或概念介紹影片是有可能的,如果你也走記者會趨動開發的話…)。

我們理想上不要有半成品,或是讓半成品儘可能的少,存在時間儘可能的短,
我還蠻推崇 User Story Mapping 在排序上的作法,
「二分法」少了它就不行的功能、基礎建設就作,其它就不作。
讓 Walking Skeleton 儘早的串通,拿掉所有不必要的功能,儘可能的輕薄。
端看你的 DoD,要達成 End to End 的 Walking Skeleton。
但是有時候即使你拿掉所有非必要的東西,也需要多個衝刺才能完成 Walking Skeleton,
當你完成之後,你的每個開發就可以在這基礎上進行增量開發,而且每次都可以作端到端的完整測試,
持續的開發增量,直到滿足 PO 對 MVP 定義,才有 Release 的可能。
相同的手法在團隊拆解 Task 也是可行的。

MVP遠比你的想得大的多

歸納一下重點:

  • 想清楚產品現在最重要的策略
  • 由策略 Break Down 出 Product Backlog Items (User Story)
  • 只有作與不作的優先權
  • 只觀注要作 PBI 與 DoD
  • 找到 Walking Skeleton,在一開始儘可能的薄(這個手法適用 PBI 與 Task)
  • 事實上 MVP 仍然很大,大到你不一定能在一個衝刺中完成
  • 問兩個問題,什麼讓我們變慢?什麼能讓我們更快?
  • 增量不等於 Release
  • PO 要觀注產品的價值,與市場的變化
  • 不要 Management 不要 Dispatch,只要排序並約定最上面的最先完成
  • 進入衝刺後就不要異動排序
  • 保留插件泳道可以帶來一些彈性,但是也是有代價的,請確保放入泳道的 Task 比衝刺的 PBI 更有價值

導入

這幾年 Scurm 或是 Agile 在台灣各地相當盛行,
這是個好事,但同時也意味著各種妖魔鬼怪的出現,
認証單位的出現,品質低下的 WorkShop 出現,
同溫層自 high 喊口號的出現,這些都是一些壞味道,
敏捷是很科學的作法, Scurm 的經驗主義也是有其理論基礎。

在這之上如果變成直銷或是宗教化的宣傳,
我個人認是非常不好的,甚至會成為導入的反動力,
我常常在想,滿牆的便利貼與宗教崇拜這樣不是與彊屍道長沒有兩異嗎 ?

我的建議的導入方法

  • 先觀察找到瓶頸或 Key Man
  • 爭取組織關鍵人物的支持,如果有老闆的支持更好
  • 帶來變化與作法,更勝於帶來新名詞
  • 一直講一直講,通常講到對方不耐煩才只是開始

現實的殘酷 與 仍然存在的疑惑 ?

最後,記錄一些現在遇到不解的問題

團隊的不穩定

不論是個人的生涯規劃,或是內部的組織調動,
都會讓團隊的成員組成變得不穩定,而基於經驗主義的 Scurm,
如果每個衝刺的團隊組成都不一致,會不會帶來太多的變數 ?
甚至團隊成員是抱著打工的心態,而 Scrum Master 也當作這些成員是別人家的孩子,
而不關心其成長。這樣總體的團隊能成長嗎 ?

過多的變數

承上題,在實驗的過程中,我們會希望儘可能的控制變因,
但是實務上,包含人員、工作內容(可能過度偏向某個 Skill Set)、假期、Deadline與項目的複雜度/範圍等…
都會帶來很大的變因,這樣的估點是否仍然有意義 ?

規模化

理想的 Scrum 想達到有效溝通,建議人數要在 5~9 人,實際上整個組織一定會遠超這個人數,
雖然現在有 Less 等 solution,但是我仍沒有理解與體會到其帶來的價值,
因此仍然有所疑惑。

跨職能與自組織

本身產品的覆蓋範圍就很大,團隊人數限制在 5~9 之時,
要完成 End to End 變得有些不切實際與困難。
一方面現有的產品欠了相當大的技術債,而團隊欠了相當大的學習債, 團隊成員在開發上已經有點捉襟見肘,還要跨領域的學習,又要深入鑽研某項技能。

如何讓團隊認知到清還債務能讓我們變快,並且在工程實踐上達到要求也是需要時間,
而成員確在職涯規劃上,2~3年就換個工作,而花了時間培養的戰力瞬間飛滅。

更甚是組織內部寧可用便宜的人材,換掉好不容易養成的人才。
對此我深感無力,跨職能與自組織最後也是淪為口號。

全貌

以上,我仍在觀察、記錄…
並且尋找機會,「Change Your Company」。
做正確的事,然後等著被炒

(fin)

CSM Day2-3 Scrum Master

Scrum Master

哪些人適合作 Scrum Master ?
常見組織轉型時會直覺的找現有的角色作 Scrum Master ,
但是 Scrum Master 是一個 Couching 的角色,
傳統公司裡面並沒有 Couching 的角色,通常都行不通的。

從 Manager Driven 變成 Custom Driven

傳統公司裡面的 Manager ,要麼是 R&D 的 Manager ,要麼是 PMO 的 Manager。通常會有幾個問題

  1. R&D 通常由資深RD升上來,但是不善於管理(彼得效應)
  2. PMO 會有自已與部門的考績考量,而這不一定能瞄準市場目標
  3. 通常工作都會由 Manager 分派,而不是由成員主動爭取
  4. 失敗的時候,總要有人背鍋,那個人就是 Manager (但是實務上常常看到 Manager 丟鍋給成員)
    5. 不太關注成員的成長。(好啦,也許有的有)
  5. Manager 要作太多的決策

Scrum Master 不是 Decision maker

情境:當 Team Member 無法決定求助 Scrum Master 時。
解法:也要看情境,干預或不干預是要付出成本的。
你要關心「風險」與「成長」,在沒有風險的情境下 Scrum Master 應該引導團隊自行作決定。
問問題是一個好的引導方式,過多的干預會讓團隊無法成長。

以小孩作比喻

情境 作法
小孩爬桌子(低風險) 讓團隊試試看,讓團隊學習、成長。
小孩爬馬路(高風險) 作出Decision,避免失敗(失敗就沒有下一次)
別人家的孩子爬桌子(不穩定的團隊) 防東防西,風險至上(他成不成長干我啥事?)

如果把時間拉長一點,可以觀察出自已的取捨是否太偏向某一方(風險 or 成長), 比如說幾個月,如果團隊仍無法自行決定,可能是你( Scrum Master )干預太多了,
Scrum Master 每一個決定都會影響到團隊。
Scrum Master 應該給自已訂一些目標,來判斷自已的取捨是否合理。

Ex:

  • 團隊是否會自行分工
  • 團隊是否會自行作決定
  • 團隊是否會蜂擁處理最高優先權的東西
  • more…

更多情況 Scrum Master 不見得能作 Decision。

Scrum Master 的責任

  • Coach PO

    • 消除客戶與開發之間的障礙
    • 教導 PO 如何透過 Scrum 最有效率達到目標(How to maximize ROI and meet their objectives through Scrum )

    以下圖來說,Y 軸代表價值,X 軸代表時間。上圖的策略表示產品初期就發佈高價值的增量,
    隨著時間過去,單位時間能帶來的價值太少時,也許我們就不作了(虛線之後),因為不符成本。
    而實務上,可能會更接近下圖,在初期有些基礎建設,這些建設不一定能帶來較高的(客戶)價值,
    但是可以降低風險,有時候更可能是初期必要的相依項目。這兩種策略沒有好壞,關鍵點仍是要能結合你的產品,
    與 PO 共同討論出取捨的方向。 User Story Mapping 是一個工具,怎麼樣找到 Walking Skeleton ,
    怎麼在這個基礎上豐富你的產品,這都是 Scrum Master 的職責。

兩種不同的迭代策略

  • Coach Team

    • Improving the lives of the development team by facilitating creativity and empowerment 

    • 以任何可能的方式提高開發團隊的生產力

      團隊常見的兩個問題,作太少或是作不完。可以嚐試一些工程實踐,但是別忘了工程實踐的目的是讓 Sprint Done。
      比如說:

> mini-waterfall的流程可能會導致 Item 作不完,原因是 Testing 的角色在最後面才會進來,會有 Items 作不完,  
> 提早發現其實是件好事,不論是**全都作不完**、**高優先權的作不完**或是**低優先權的全都作完**都是很好的干預點,  
> 只要在 Retrospective 將作不完的東西攤開\(透明\),分析問題就可以有機會改善

> 引入不同的流程、開發方式都會有一個學習與生存的焦慮在裡面。可以透過 Coaching 降低學習焦慮,  
> 你要尋找適合的人選與資源,這是 Scrum Master 的職責。  
> 有的團隊的抗拒會比較強,Scrum Master 要找好時機進行,例如:Sprint 失敗時。  
  • Improving the engineering practices and tools so each increment of functionality is potentially shippiable。
> 實例化需求\(SBE\)、驗收趨動開發\(ATDD\)  
> 實踐上怎麼作呢 ?  
> 在 Sprint 中的 Item 應該都有驗收標準\( Acceptance Criteria\),  
> 這都應該在 Planning 或 Refinement 的階段被列出來,更進一步應該變成 test case。  
> Example :  
> Sprint裡有 Item1、Item2、Item3、Item4  
>
> Item1 應該會有 test case 1.1,test case 1.2...,Item2 應該會有 test case 1.1,test case 1.2...,  
> 正常一個 Item 應該在兩三天完成這個功能。  
> 這時候就可以測試  test case,假設 test case 4.3 作不完就不作了,這樣就不會留半成品。
>
> 再透過持續整合\(CI\)的實踐,避免後面的改動,影響到前面。
>
> 實務上,一種是團隊很喜歡作這類的實踐與改變,另一種更多  
> 「團隊作不到 Done,在 Retrospective 階段來趨動改善的過程」,為了解決問題。
1
2
3
4
5
Question:
1. Item1、Item2、Item3 會改到同一個模塊,所以 RD 會習慣同時開發(F2E反應)
2. 沒有持續集成(CI),或是 CI 不包含自動化測試怎麼辦?
- 如何快速寫出一個自動化測試試?
**

問一個問題,「什麼讓我們慢下來?,什麼讓我們不能更快?」

通常第一線的人員(Developer)不覺得慢是一個問題,甚至不會在 Retrospective 提出。Scrum Master 的職責是找到這個問題。

小結:

  • Scrum Master 要讓團隊與 PO 深入理解 Scrum
  • Scrum Master 就像是牧羊犬要保護羊群(團隊),因為會有狼(插件or something…,或是羊群裡有狼)
  • Scrum Master 不作決策,更多是關心決策的過程甚於決策本身
  • 具有生產力的團隊就是 Scrum Master 的產出
  • Scrum Master 要發揮影響力(知易行難,怎麼作?)

情境題

避免爆雷,不描述課堂上的情境,但是將一些原則列下:

  1. 很多人第一時間會找 Scrum Master 問問題。
    • 這是好事 Scrum Master 要發揮影響力
    • Scrum Master 可以籍些說明 Scrum 在作什麼,團隊是怎麼運作的。
    • Scrum Master 不作決策更關注過程。
    • 不要急著解決問題。
  2. Product Owner 要基於 Product Value 作排序
    • 如果要最大化價值,一個產品就一個 Product Backlog,不管是多少個 Team。
    • 一個插件有幾種可能
      • 放進下面幾個 Sprint Backlog。
      • 放進 Product Backlog。
      • 很異常的情況,才會終止 Sprint。
    • Scrum Master 要關注 Root Cause
  3. 保持團隊與 Product Owner 的連結
    • 有時候 Product Owner 也身不由已。
    • 如果 Product Owner 不在決策圈或未被授權,要了解背後的原因。
    • 如果 Product Owner 太忙,想辦法減輕他的壓力。
    • 如果 Product Owner 有別的角色(Sales、Boss…),找個適合的人作 Product Owner。
    • 改變文化 改變組織 改變作法。
  4. 讓 Product Backlog 作為團隊工作項目唯一的入口
  5. 在不被 fire 的情況下,對組織帶來改變與價值!要有勇氣。
  6. 不要讓團隊與 Product Owner 成為甲方乙方。
  7. 讓團隊自已挑選工作,而不是分派工作。
  8. 觀注事實。
    • 團隊的 Velocity
    • 上個 Sprint 完成的點數
    • 誠實面對失敗( _柯語錄:面對挫折打擊不是最困難的;最困難的是面對各種挫折打擊,卻沒有失去對人世的熱情_)。
    • 思考著如何讓 Product 的 Impact 發生
      • 昧著事實去滿足時程與範圍,可能會為此喪失品質與生產力(欠債…)。
      • 找到正道,但是也許會更花時間。
      • Change Your Company。
    • 觀注 Product 的成功勝於作了多少工作。
    • 盲人摸象的故事,每個人都對,也都不對。

Part-time or Full-time

Scrum Master 觀注改進,同時兼任多個角色時,容易陷入可量化產出的角色之中。
要想辦法讓 Scrum Master 的工作可視化,不然容易淪為開會召集人或訂訂便當與飲料的角色。
實踐:

  • 使用 Scrum Master Check List http://scrummasterchecklist.org/
  • 建立 Scrum Master 的改善 Impact Backlog,並且設定優先級。
  • 按優先級逐步的改善。
  • 尋找一組 Scrum Master 彼此討論與評量,讓這個流程形成一個循環。
  • Less 的解決方式是 Full-time Scrum Master 兼任多個 Team。

相同的作法,對不同的 Team 不一定有用, Scrum Master 如果能接觸不同的團隊是好的。或是從其它 Scrum Master 汲取經驗。

呂毅老師的實務分享

常見一個問題,Product Owner 常常單向對 Team 輸入訊息,導致最後的結果與 Product Owner 的想法有落差。

一些壞味道

  • Planning 的時候大家「帶電腦」作自已的事或是在「滑手機」。
  • 開會人數太多,部份人在討論時,其它人放空。

Solution:

  • 讓成員不要帶電腦,收走手機
  • Product Owner 講完換 Team 講
  • 測試
  • 拆散小組至2-3人
    • 有點類似 Lean Coffee 的作法,讓團隊拆成小組討論 。
    • PO 輪流在小組之間被問問題。
    • 如果等不到 PO 可以先寫在便利貼貼到白板上。
    • 設定 Time Box ,時間到請 PO 回答問題。

Ending

不要反射性的去解決問題,讓子彈飛一會兒…。

  • 讓問題變透明,讓團隊看見問題
  • 不急著干預,試著讓團隊自行解決問題
  • 讓 Team 與 PO 直接交流,不要成為 PO 與 Team 的傳話筒。
  • 要保持「意識」,不要條件反射去干預,要克服這個心魔。

Real Team

  • 所有人的目標是一致的,而不是臨時組成的一群人。
  • 俱備 End to End 的完整。
  • 有限的人數,Scrum 建議 5~9 人。
  • Mutual accountability
  • Agreed way of working

Scrum Team 是自組織的團隊

一個好的 Scrum Master 的產品是 Well-Working Team, 這需要時間(以年計算…)。 如何打造一個 Team ,這比 Scrum Maser 有更多的討論,但是實務上在成為 Scrum Master 時,大多數人打造 Team 的基本功是缺乏的(彼得原理?),這需要更多的學習…

參考:
心得小結:
  1. 還好上課有記錄,課程很有料,過了一個月想法仍源源不絕的出來。
  2. 你可以繼續 Scurm 自助餐,但是那個不是 Scurm 不是守破離。
  3. 一邊觀察 N 社團隊的運作一邊寫筆記,Change My Company。
  4. Gitbook 也很方便的筆記工具,寫完後同步到 Github 就能拿到九成完美的 markdown 。
  5. Scurm 給團隊更多職責,所以團隊要更強才行。
  6. Corss Learning 不僅僅是溝通層面而已,而是為了真正的 End to End。你的 End 到底到哪裡 ?如何 DoD?
  7. 所有聲音都是真的,不要急著說服別人,記住盲人摸象沒有一個瞎子說謊。
  8. 第二步我在哪裡?第一步看見全貌、先要透明,透明的意思是有共識,再此之上是溝通與信任…不要把人僅僅當作 Resource。
  9. 團隊裡面不要有小團隊/人數控制在5~9/保持團隊穩定/Real Team,好難…實務上怎麼作 ?
  10. Walking Skeleton 可以貫通在 PBI/User Story/Task 之間,要盡可能的薄但暢通,再此之上才有增量。
  11. 可交付的增量不是Release,也不是MVP。MVP比你想像的還大。
  12. Sprint 的觀念在蕃茄鐘或GTD也有反覆出現過,在 Timebox 中反覆實驗,尋求改善。

(fin)

[實作筆記] Git 批次刪除分支

要知道的事

  • OS : Windows 10

易學難精的 Git 與 Flow

在使用 Git 時,分支的策略往往比 Git 本身更複雜。
Git 在建立分支是成本非常低的一件事情,
也因此很容易開出一堆分支,
這與團隊規模和PR的流程有關,可以參考文末的分支策略聯結。
因為 Git 開分支實在太便宜了,
我的 Remote Repo 不知不覺中竟然有了破千的分支。
大量的分支意味著大量的需求,其實是好事,
但是大部份的分支都已經功成身該退了,
當我使用一些 GUI 工具,為了顯示這些分支時,
這樣的數量反而成了阻礙。

解法

大量刪除遠端分支的方法

Step1. 可以透過正規表示式查詢大量分支。

1
git branch -r | awk -Forigin/ '/\/feature\/BTS14/{print $2}'

Step2. 同上的語法,但是後面 pipeline 串接 xargs push 到指定的遠端(這個例子是 origin)

1
git branch -r | awk -Forigin/ '/\/feature\/BTS14/{print $2}'| xargs -I {} git push origin :{}

特別看一下 {} git push origin :{} ,我們實際上是透過 push 語法刪除分支的。

補充

2019/05/09

大量刪除本地分支的方法

Step1. 可以透過正規表示式查詢大量分支。

1
git branch | grep "pattern"

Step2. 同上的語法,但是後面 pipeline 串接 xargs push 到指定的遠端(這個例子是 origin)

1
git branch | grep "pattern" | xargs git branch -D

參考

[N社筆記]敏捷路上跌倒站起來 2018/11 月

2018/11/30

Planning 有沒有優先討論重點項目?

  1. 最先討論上個 Sprint 的 UnDone
  2. 順序等於優先權嗎?
  3. 工作是事先 Assign 好,而不是
  4. 兩個 Team 的 Backlog 放在一起,結果順序是
    • A Team (B Team 發呆)
    • B Team (A Team 發呆)

PO 只作明顯短期可見效果但低價的項目(沒有 Focos 價值),如何引導 ?

Scrum Master 消失 ,Planning 沒有 Couch PO

  • Scrum Master 兼任主管
  • Scrum Master 兼任開發人員

KA 後台要中文 / 前台要英文

  • 要問 Why:KA 面對的客戶也以中文為大宗,為什麼要英文?

2018/11/28

Demo 會議是由「 PO 介紹給 stackholder ?」
還是「 Team 介紹給 PO ,有 stackholder 最好。」
如果可以看錄影就當作 Demo 過了,那還需要 Demo 嗎 ?

三個 Team 各自有各自優先級最高的項目,這樣會不會陷入局部優化,過早進入細節 ?

  • 無法集中火力處理優先度最高的需求

最大的 PO 沒進來

會後主管和小 PO 們再討論,有好有壞?
Scrum 怎麼說?

  • 主管應該不要進來
  • PO 最好能夠進來
  • 不要在團隊裡形成小圈圈

2018/11/26

無限站立會議之卷

10:10 SRG 站立
10:20 A Team 站立
10:30 B Team 站立
11:30 RD1 周會

2018/11/23

  • 你需要一個旁觀者,不然只是自 high

    • 觀查群眾的反應
    • 客觀點出講者的優缺點
    • 再好的內容沒有人聽也是枉然
  • 成為 SM 之前要小心,不要急著成為 SM (特別是你是兼職的 SM 時)

    小心過早聚焦到細節,例如:安排會議/主持/作簡報
    不然你會變成「借會議室的人」、「照表操課的 Scrum Master」

  • 用誇張口吻重複他說的理想,你就會知道他是在說理想還是說幹話

2018/11/22

情境:
團隊開發會與其它團隊開發相依或衝突,導致 Release 的品質有所缺陷。

  • 用更多的會議/文件/Check List作控管,有沒有辦法從 root cause 解決問題 ?

  • 主管為什麼會想看「沒意義」又「不真實」的東西 ?

    2018/11/21

  • 口頭敘述

2018/11/19

  • Scrum 不要拿 A 會議的時間作 B 會議的事
    • 觀注目的
    • 作該作的事

有關進步

運動員是否真的變得更快、更好、更強 ?

(fin)

如何讓 windows 也有美美命令提示視窗

目的

就是要美美命令提示視窗
常常在一些社群看到,大神都超會下 command,
開始學習使用各種 command 之後,才發現那個美美的 terminal 不只是華麗而已,
實際上也可以加速閱讀,而且潮指數也是怒加一波(畫錯重點),
當然要研究一下如何讓自已擁有一個賞心悅目的 commander 囉

作法

使用 Cmder , 這是一個 Windows 的開發人員常用的 terminal 介面,
他可以執行一般的 CMD、Bash 與 PowerShell ,別想得太複雜,就是一個命令提示視窗。

安裝字型 on Windows 10

  1. 下載 powerline,選擇 Clone or download > Download ZIP
  2. 解壓縮後,選擇使用 AnonymousPro 字型(主要是要那些git icon的圖案,如果別的字型有 也可以使用)
  3. 控制台>字型 把 ttf 拖進去安裝

設定 Cmder

  1. Win + Alt + P 開啟設定畫面
  2. Cmder > Settings > General > Fonts > 下拉選單選 Anonymice PowerlineCmder

使用 lua Config

  1. 下載cmder-powerline-prompt,選擇 Clone or download > Download ZIP
  2. 開啟 Cmder 安裝檔所在位置,找到 Config 資料夾
  3. 將下載的所有 *.lua 檔放入 Config 資料夾

最後重啟 Cmder 就可以有一個美美的命令提示視窗了。
lua 也是一個程式語言,你大可開啟文字編輯器,看一下裡面作了什麼。

2018/12/02 補充

追加讓 PowerShell 在 cmder 裡面也美美的方法

步驟

  1. 下載cmder-powershell-powerlin-prompt,選擇 Clone or download > Download ZIP
  2. 解壓縮 ZIP 檔
  3. 開啟 Cmder 所在的資料夾,如下圖 > 開啟 config 資料夾
  4. 將壓縮檔內的 user_profile.ps1,取代 config 內的 user_profile.ps1
  5. 將壓縮檔內的 profile.d 資料內的所有檔案,全數貼到 config 內的 profile.d 資料夾內,如果不存在就建立一個。
  6. 開啟 config\profile.d 資料夾,重新命名 goToFolder.config.example 為 goToFolder.config
    • 這個檔案內會設定一些目錄與 alias 。
    • 使用方法,在使用 cmder 開啟 powershell 的情況下,輸入 g + alias
    • 比如說在 goToFolder.config 中,設定一組 m, C:\User\Marsen
    • 在 cmder 輸入 g m 就會自動切到 C:\User\Marsen 的路徑底下
  7. 還有很多 Alias 請自行研究。
  8. 重啟 cmder 後就會載入新的設定,變成美美的 powershell 了

參考

(fin)

[實作筆記]用 Command Line 取得資料夾內包含特定檔案的子資料夾

情境

  • OS : Windows 10

在一個巨型的 Git Repo 當中,底下依專案分了許多專案資料夾,
參考下圖。
擁有多個專案的Repo

而今天發生了一件事情,我需要更新某幾個子專案的 POCO 的 .tt 檔,
這裡不說明 POCO 是什麼;簡單的說,有的專案會有 .tt 檔,
有的專案會沒有,而每個專案的資料夾結構又不一定相同,
所以要找出這些 .tt 是有點麻煩的,另外我的目標並不是 .tt 檔,
而是所在的專案,再用 IDE 開啟進行修改,
為此我需要列出專案資料夾

目標

用 Command Line 取得Repo資料夾內包含.tt檔案的專案資料夾名稱

作法

1
2
D:\Repo\Taiwan\******.******.Repofolder
λ Get-ChildItem -Path .\ -Filter *.tt -Recurse -File -Name | ForEach-Object { $_.Split('\')[0] } | Group {$_} | select name
1
2
3
4
5
6
7
8
9
Name  
----
FacebookShop
LineOrderFinish
LineOrderNotify
Mail
NMQMonitor
OrderMonitor
SyncImageToOthers

小結

總覺得寫得有點又臭又長,希望有更好的作法可以提供給我,
不限於 powershell 就算是 Linux 的語法也可以讓我參考一下。

(fin)

[踩雷筆記] BDD 跑3個失敗就停止

原文描述

Visual Studio 的 Test Explorer 在跑測試,
如果遇到失敗,會直接中斷,
比如說有 2000 個測試案例 跑到第 1300 個時測試失敗就會中斷
剩下的 700 個案例會不執行直接略過。

情境

實際狀況

並不是一跑到錯誤就會中斷測試,而是跑了 3 個失敗後中斷測試,
另外執行的測試專案,是使用 SpecRun.Runner 撰寫 Cucumber 語法跑 BDD 測試。

原因

當使用測試專案使用 SpecRun.Runner,預設 stopAfterFailures 是 3,
所以3個失敗就會略過。

更多

正常的測試都是會全跑完的。因為 Test Framework 標示 Test Method 的部份,
都是幫你內建 Try/Catch 攔下所有 Exception 的。

MsTest 的 [TestMethod] 或是 NUnit 的[Test](XUnit 是 [Fact]),其實就是層 Wrapper
你在方法裡面寫的內容,只要有引發 Exception 的例外,
都會被這層 Wrapper 攔下來,轉成測試結果的內容。

解決方案

測試專案根目錄應該有一份 Default.srprofile 檔,如下
stopAfterFailures 調整至適當的值(ex:500),將會顯示所有失敗測試。
本案例開啟後,實際失敗的測試有 37 個

<Execution stopAfterFailures="3" testThreadCount="1" testSchedulingMode="Sequential" />

參考資料

特別感謝 91、Green、余小章的協助

(fin)