2016-06-18

[工具篇] BoardThing - online brainstorming tool

目的
Retrospective Meeting

需求
要有線上白板功能
要讓Member 方便存取白板 (不要再另外註冊帳號)
最好有便利貼的感覺
方便分組
投票

緣由
由於我們Project Team的成員分隔三地 (台灣 , 大陸 , 美國) 所以我們沒辦法大家一起在白板前面做Brainstorming. 更何況是需要member們聚在一起的Retrospective Meeting了.
所以我就花了一點時間Survey了一下 目前有哪些online brainstorming的工具

參考來源 :
26 Tools for Online Brainstorming and Decision Making in Meetings
BoardThing

裡面試用了幾套 最後覺得這套 BoardThing最好用
只要主持人自己開了一個Board 將這個Board的link 分享出去
參加者就能參與討論 一起貼便利貼了

接下來就為大家介紹 怎麼使用這個Tool

How to Use BoardThing

Step1 主持人要先去BoardThing註冊 這部分就不特別提了
BoardThing 官方網站
http://boardthing.com/

新建一個Board


進入剛新建的Board 一片空白


來貼上第一張 便利貼 吧


便利貼可以用圖片

圖片還可以用網路上的Link

便利貼可以換顏色 不是只有黃色喔


可以用拖曳的方式 將類似的便利貼分組
不過很可惜 分組完會自動將第一張便利貼變成群組的名字

所以可以選擇先貼一張來當作群組名字
或是直接編輯這個群組

變成群組之後 可以設定投票

投票是針對裡面的便利貼 點一下圓圈就會 + 1
不過缺點是 按了就按了 不能取消
白板上還可以用畫筆 我們也可以用這個來分類

這個畫筆 也可以用橡皮擦功能擦掉
如果懶得打重複的字 可以Copy便利貼


可以Resize 便利貼的大小


最重要的一點 要將這個Board 分享給參與者

參與者只要在瀏覽器貼上這個Link 就能馬上加入這個Board的編輯


最後這個Board 是個Export出來的
只是我覺得效果不是很好




最後讓大家看看 我們POC 的 一個Board


目前還沒有讓團隊來試過
所以也還不確定多人同時上線的效果如何？
待我們試過之後 我再回頭報告測試的結果


2016-06-14

How to get started with .NET Core on Mac

最近剛入手Mac 唯一一個還不習慣的是
過去常常開Visual Studio來寫一些POC 驗證一些演算法 一些想法
但是在入手Mac之後就變得不方便了

剛好最近剛瞄到.NET Core 於是就來研究看看怎麼在Mac上開發.NET的程式
參考了很多資料之後 發現很多套件要安裝
這篇文章的目的 就是將這些步驟整理起來

Step 1 : Install Homebrew Requirements
為了要開發.NET Core 我們必須要先安裝OpenSSL套件
目前可以透過Homebrew來安裝 OpenSSL
但是安裝Homebrew之前 我們必須先安裝Xcode

(1) 透過Apple Store 安裝Xcode
(2) 將你的apple id加入到Xcode
(3) Get Command Line Tool
In Terminal >
xcode-select --install

(4) 確認是否正確安裝
In Terminal >                
 xcode-select -p
               


Step 2 : Install Homebrew
安裝 Homebrew
In Terminal >
/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"          

Step 3 : Install OpenSSL
In Terminal >
brew update
brew install openssl
brew link —force openssl
           
           
Step 4 : Install .NET Core
安裝完OpenSSL之後 就能開始安裝.NET Core SDK了
(1) 如果有裝過過去版本的.NET Core 請將他們移除
https://raw.githubusercontent.com/dotnet/cli/rel/1.0.0/scripts/obtain/uninstall/dotnet-uninstall-pkgs.sh

 (2) 下載官方的PKG Package
https://go.microsoft.com/fwlink/?LinkID=798400

(3) 安裝.NET Core SDK        
         
Step 5 : Install Visual Studio Code
正所謂工欲善其事 必先利其器
Visual Studio的好用就不多說了
但是Visual Studio Code 比較像是Editor (但是仍是相當強大的Editor)

(1) 到官網去下載 Visual Studio Code
      https://code.visualstudio.com/

(2) 安裝 C# Extensions
      打開 Visual Studio Code
      打開 Quick Open (⌘+P)
      輸入 ext install csharp

Step 6 : Install Yeoman
Yeoman Generator for ASP.NET Core 1.0能夠幫你很快地建立一個.NET Core的專案
要安裝Yeoman之前要先裝Node.js
請參考 https://www.npmjs.com/package/generator-aspnet
           
(1) 透過剛剛裝好的homebrew 安裝 Node.js
In Terminal >
brew install node

(2) 透過剛剛裝好的Node.js 安裝Yeoman
In Terminal >
npm install -g yo

(3) 安裝 bower
In Terminal >
npm install -g bower
           
(4) 安裝 Yeoman generator for ASP.NET Core 1.0
In Terminal >
npm install -g generator-aspnet

Step 7 : 建立新專案
你可以選擇你要建立哪一種專案
我們這邊先選擇建立一個Console Application
In Terminal >
yo aspnet
           
           
 
給專案一個名字吧
你會發現 Yeoman 有提示你接下來該怎麼做 照做就好了


到專案的目錄 輸入 dotnet restore 目的是重新整理這個專案的project.json file
接著你就能輸入 dotnet build 去build 這個專案 最後 dotnet run 執行這個程式



Step 8 : 來寫個程式吧
打開 Visual Studio Code
File -> Open (這邊請選擇整個專案Folder)
           

開始coding


Build


Run




Reference :
It is very easy to get started with .NET Core on your platform of choice.
如何在 Mac 建立 ASP.NET Core RC2 網站
Your First ASP.NET Core Application on a Mac Using Visual Studio Code
Visual Studio Code Getting Started
http://edentsai231.logdown.com/posts/151421-install-homebrew-in-mac-os-x
Tutorials

2016-05-31

新部門的首次Retrospective


轉到新部門也一個月了
這個月多多少少也聽到一些抱怨
也觀察到一些可以改善的空間
所以就讓同事們來體驗一下Retrospective Meeting
希望能找出大家的共識
以及討論出可以解決痛點的Action Item

今天使用的引導方法仍是O.R.I.D
  • O是 Objective , 代表客觀的事實
  • R是 Reflective, 代表心中的感受
  • I 是 Interpretive, 代表上述事實或是感受的解釋
  • D是 Decisional, 代表行動

由於同事們過去沒有參加過Retrospective的經驗
所以開場我先花幾分鐘解釋一下
Retrospective的目的及ORID的含義

首先

Retrospective不是幹譙大會喔！！！
Retrospective不是幹譙大會喔！！！
Retrospective不是幹譙大會喔！！！

 我們是希望透過大家的共識找出痛點
然後看看有什麼是團隊內部可以改進的？
哪些是團隊外面的問題 要怎麼處理？

今天進行的方式是ORID各個區塊分別討論10分鐘
3分鐘讓大家一起寫便利貼
7分鐘時間讓大家輪流上來說明
一次說2~3張
最後我們找出一個可以改善的Action Item

進行到一半的時候
我發現很多情緒是在抱怨一個團隊外部的問題
於是我就稍微引導一下
希望大家能再想一下 我們團隊內部 自己能做些什麼？
畢竟外面的問題 抱怨再多 也不是我們能控制的
所幸後來還是有討論出對內的Action Item
下個月就來試試看吧！！！

[今日Retrospective的Retrospective]
今天有幾點是下次可以再改進的
1. 從O->R的過程中 應該要有所連結的 不然光看情緒便利貼 會忘記這在抱怨什麼
        下次來試試 "水道"
2. 討論root cause 時 很容易把Action Item也一起講出來了
         e.g. 我覺得問題是xxxx 所以我們應該要oooo
3. 群組討論的感覺還是少了一點 大家是上台講自己的想法
    但是這次還是少了一些互動與討論
    下次試試 讓大家圍在白板前面討論
4. 雖然時間有限 但還是希望大家都能多提一些正面, 令人開心的事 算是正面的力量吧 可以鼓舞大家的士氣
5. 討論Decisional的時間仍舊不夠 今天應該要在Interpretive階段選出大家想要改善的問題
    然後鎖定這個問題在Decisional時討論Action Item

=================
[第二次的Retrospective]
本部門第二次的Retrospective Meeting 我嘗試加入了上次的一些回饋
1. 水道
2. 圍著白板討論
3. 先花5分鐘提開心的事

儘管今天的時間還是有超時
不過最後大家針對Decisional的討論 有進入狀況
也真的引導出大家的痛點

持續改善吧

2016-04-14

2016-03-03

Build Verification Test小小的改善方案

今天聽到一則令人開心的小故事

今天QA夥伴向我感謝
上次我建議的BVT (Build Verification Test)改善方案
讓這次的BVT非常順暢

這改善其實也沒什麼
只是讓QA提早開發BVT而已

過去我們Developer都是開發到一個程度之後
要放到我們所謂RAT環境測試 (算是DoD的一環 驗證自己開發的功能是work的)
而過去QA是在Developer放上去之後 才開始自己上去抓id 抓class去寫BVT
結果當然是要加班寫BVT 以及品質不夠穩定(因為只有兩天)

我就想說 那為何QA不在一開始就寫呢?
參加完Developer的Design之後
藉由討論 知道怎麼測? 要測什麼?
我們的Test Case就是這樣來的 那BVT應該也能比照辦理吧?
跟著Developer一起開發BVT 即時發現問題 即時獲得回饋
最後再藉著RAT這兩天來驗證自己寫的BVT是否work
正式測試時就有一個品質穩定的BVT啦~


[Jug讀新聞] Personal Kanban 介紹

最近在網路上看到一則影片
介紹Personal Kanban

資料來源 :　http://www.personalkanban.com/pk/#sthash.uDtxChXM.dpbs

內容其實很簡單
我們要做的事情很多 但是當這些task都擠滿你的腦袋時
你會錯過很多很多正確的抉擇
做事沒有效率

所以來試試Personal Kanban吧
它能夠幫助你管理你的工作

Personal Kanban只有兩個規則
1. Visualize your work
    將你的task視覺化 將他們排列出來 你才能開始去思考
    為什麼要做這個? 哪個是我想要做的?

2. Limit your work-in-progress (WIP)
    要做的事情很多 但是我們的時間有限
如果你把所有task都丟到Doing
那跟沒有安排是一樣的道理
請限制能工作的量

只要follow上述兩個規則
你就能一個一個完成每個task
You Finish this task, then you could Focus on next one.

我自己目前是使用Trello來當作我的Personal Kanban
很多Todo list 就丟到 Backlog欄位
每周挑選一些放到Week Backlog
每天再從Week Backlog挑選今天要做的項目放到Today欄位

每天有時會有Urgent Case. 通常我就直接加到Today欄位
然後再來就是 Doing 跟 Done

我也有設WIP point 都是憑感覺亂估的
現在還在抓

實行一段時間下來 感覺很不錯
每天都知道要做什麼 跟 不要做什麼

再搭配番茄工作法
真的感覺考試都拿100分了呢XD

2016-02-05

[Jug讀新聞] How NOT to Run Scrum Meetings

資料來源:
https://dzone.com/articles/how-not-to-run-scrum-meetings-for-software-develop?edition=138252&utm_source=Daily%20Digest&utm_medium=email&utm_content=DZone%20Daily%20Digest&utm_campaign=dd%202016-02-04&userid=821105

 How NOT to Run Scrum Meetings

 本文是用 "不要" 怎麼做的角度來談 Scrum Meetings

1. Don’t Address Too Much

不要 說太多

通常都只要求member講以下三件事

  • What has been done since the last scrum meeting?
  • What will be done before the next meeting?
  • What impediments are being faced which may block/slow down the work?
記得 Daily Scrum用來浮現問題 而非解決問題

2. Don’t Sit Down

不要 坐著開會

站著開會是種簡單的practice讓大家在短時間保持注意力 高效的作法 並能確保不會站超過15分鐘

3. Don’t Lose Focus

不要 失去注意力(離題)

有時可以直接對著task說明 這樣才不會離題

4. Don’t Neglect the Coach

不要 忽略Agile Coach


常常有種情況是明明就擁有明星球員的隊伍卻很難打出好成績 原因很可能就是因為爛教練
反之 一個好教練卻有可能帶著一支隊伍上天堂
要把團隊轉變?高效能的團隊是非常困難的
所以要盡量去向Agile Coach挖寶 他會給你很好的feedback

5. Don’t Do It All Alone

不要 自己單打獨鬥

利用Team work 不要老是自己單打獨鬥
藉助群眾智慧
這邊則是以pair programming 當例子

6. Don’t Forget Your Boots!

不要 忘了自己的武器

正所謂工欲善其事，必先利其器
這段則是在說developer的配備要好一點=.=

2016-01-27

[引導心得] 參加Agile Meetup 2015歲末分享



今晚參加AgileCommunity.tw 主辦的Agile Meetup 2015歲末分享
活動內容是

  • 由參與者發起的 
  • 由下而上的
  • 大家感興趣的 

討論項目

今天先由一個破冰遊戲開始

 破冰遊戲 I - 捏造的自我介紹
跟大家自我介紹三件事, 兩件是真的, 一件是假的
請大家猜哪一件事是假的

 藉由這個遊戲剛好找出桌長
由桌長擔任計時的腳色
因為之後的討論都必須設定Time Box

接著就進入今天的重頭戲
透過Lean Coffee產生今天討論的主題

規則如下:

1. 每人先寫下感興趣的主題 (Main Idea) 5分鐘

 2. 每個人用1~2句話簡介這個主題

 3. 每個人兩票 找出大家感興趣的話題 (依感興趣程度排序)

 4. 依排序從第一個主題開始討論 計時15分鐘

 5. 時間到, 大家投票這個討論是否要繼續 

 6. 若要繼續討論 則再計時8分鐘

 7. 同5

 8. 若選擇不繼續討論, 開始討論下一個主題(依排序)

 9. 如同4~8的迴圈 直到時間結束或是主題討論完畢

PS1 : 透過Kanban的方式 列出 ToDo, Doing, Done 的視覺化方式能幫助所有人明白現在正討論到哪裡

PS2 : 每個人的發言應該也要設一下Time Box 不然我今天就講太多了 讓其他人沒有說到話 很不好意思 , 不然就是第一輪強迫大家都得發表意見

最後幫 AgileCommunity.tw 再推廣一下
對Agile感興趣 有興趣 想嘗試的朋友 可以多多參加 Agile Meetup
聽聽別人的寶貴經驗 或是跟共同興趣的戰友們一同討論
一同奮鬥 在Agle路上你不會寂寞的

2016-01-26

透過O.R.I.D 方法進行Retrospective


O.R.I.D 焦點討論法是之前參加Agile Tour時從David那邊學到的
焦點討論法 (ORID)

當時就覺得這招很容易引導Member
引導出他們想說的話

  • O是 Objective , 代表客觀的事實
  • R是 Reflective, 代表心中的感受
  • I 是 Interpretive, 代表上述事實或是感受的解釋
  • D是 Decisional, 代表行動


這是套循序漸進的引導方式
從一開始大家都還沒有想法的時候
就先從最簡單的開始

1. O 事實

剛開始寫出看見的事實比感受還容易多了
然後再根據這批大量的事實
我們可以找出我們的

 2, R 感受

如果要收斂範圍的話
我個人覺得可以從感受開始收斂
如此大家討論的範圍就不會越來越發散導致收斂不了

有了大家都比較有感覺的感受之後
就可以根據這些感受討論

 3. I 解釋

為什麼會覺得不爽? , 為什麼覺得很爽?

再根據這些解釋
我們可能會找到Root Cause 或是 大家感受不錯的地方
最後 提出

4. D 行動

列出Action Item

今天試著照著ORID引導Member做Retrospective
感覺不錯喔 大家都有照著方向走
沒有越來越發散喔~

2016-01-19

[CI] [Jenkins] Jenkins的Nunit Plugin 無法讀取 Nunit3 的 format

Nunit 在2015/12/1時 release 了 Nunit 3.0.1

於是我就採用了最新版的Nunit來寫Unit Test

但是發現Jenkins的 Nunit Plugin仍未跟著升級到3.0.1的format


參考了Jenkins的Issue
https://issues.jenkins-ci.org/browse/JENKINS-27906

採用一個workaround
先將format 改成 nunit2吧
--result:TestResult.xml;format=nunit2

可以看見Report了


2015 Review - 個人成長篇

前面兩篇Review完了
2015 Review - 社區工作篇
2015 Review - 家庭生活篇

 接下來就來好好Review 今年的個人成長方面吧

 [工作份內的事]
工作份內的事就不多說了
大致上今年也沒有什麼固定的Feature
就是被老闆assign什麼就做什麼
累計下來也算蠻雜的

 幾個顯著或特別的成長大概就屬
1. T-SQL
2. Performance Tuning
3. Azure

 PS. 今年的目標是Full Stack Developer
       所以要學習front-end的技術

 [工作份外的事]
今年嘗試了許多工作外的任務 讓成長更多元

 1. Local CI
我覺得今年度對Team一個最大的貢獻就是寫了一套CI Checking 機制
過去我們Developer要很辛苦地凌晨看一下Build有沒有問題
如果Build Fail就要趕快修 或是 rollback 讓明天的Build沒有問題

 但是明天就算有Build了 QA拿去裝發現安裝失敗
又要花時間找問題點 然後重新submit一個build
而我們一個Build都需要3小時的時間

 這一來一往 就要浪費掉一天半的時間 !!!

 現在則是1小時內就會知道結果
知道前一個小時check in的code 會不會造成Build Fail , Installation Fail

 大大減少了浪費!!!

 講一個題外話 LocalCI的起源
其實也是來自於Retrospective的feedback
Build Fail是大家的痛 但是當時沒有什麼好的Solution

 而當時好巧不巧 參加了Continuous Delivery的Study Group
於是就當作自己的一個挑戰
而且也強迫用SCRUM的方式 每個星期有一定的產出
邀請一些member 透過Brain Storming 想出大致上的task
透過快速相對估算 對每個task估出effort
自己就是自己的PO 所以對每個task排出Priority
雖然成員只有我自己一人
然後就把初步的成果做出來了
11月 趁著新Project的開始 趕緊導入到Team中
讓Member都感受到LocalCI的好處

 PS. 今年則是計畫要將Unit Test 加到Local CI去 把Feature Checking加進去 

 Jenkins 初體驗

 2. 導入JIRA
過去我們總是把task寫在便利貼上 然後貼在我們的實體白板上
然後也常常忘記移動

 我就很好奇 貼在這裡的便利貼 真的有人會看嗎?

 於是我導入了JIRA到Team裡面 一開始也沒有取代實體白板
先讓大家熟悉一下JIRA的用法
下個Iteration才開始全面的導入
每天中午定期發個mail 提醒大家要去移動task
其實就算Member忘了移動 他的task會被顯示成紅色
久了大家都會記得去移動

 實體白板則是讓它顯示Summary的資訊
方便Manager閱讀
於是整個Project就變得非常透明

 後來的Retrospective 大家對於這個Practice都還蠻贊同的

 不過有點可惜的是 這個Practice在我們的新Project上 就不再用了

 PS.
Agile 一直是我迷信且崇尚的開發方法
不過導入讓我學習到了 要學著 "win-win" 
唯有"win-win" 讓Member感受到好處
他才會買單 相信你的Practice對他是有幫助的

 3. 講課
2015年也是我講課爆炸的一年
在公司內部就講了9場sharing吧

 也在公司成為了賈格老師
開了一堂課 Unit-testing programming
然後也教了實習生
也跑到成大去講課
在外面社群 - AgileCommunity.tw
在新竹也講了3堂
(1) 快速相對估算 - 動物洗澡 workshop

 (2) 在瀑布底下玩SCRUM

 (3) Unit-testing Coding Dojo

我也一直推廣快速相對估算
用兒子的動物牌卡 想了一套故事主軸叫做動物洗澡
利用這個詼諧 有趣的workshop讓大家體驗如何快速相對估算


儘管Team尚未採用
我個人則是從自己開始做起 真的用這套去估我們真實的task
效果很不錯
自己的工時自己估 - 應用相對估算的概念在WBS上

 4. 在公司內部投稿
    今年則是寫了兩篇去投稿
    其中一篇是有關於導入JIRA的
    後來年底SQA有找我sharing 不過可惜因為一些緣故而沒去講

 5. 拿下Product Hacking的冠軍 在1000人的場子演講
     這真的是一次永生難忘的經驗 沒想到在一次的20秒的勇氣中
     真的代表了Team去簡報我們Product Hacking的產品
     然後還真的拿下了冠軍 在1000人面前分享我們的Idea
     

    
    一切都要感謝我們背後專業的Hacking團隊阿
    

    
6. 成為了Certified Scrum Master
     上完Daniel的課之後 也抽空去考了Certified Scrum Master囉
     


 7. 擔任Trend Engineering Day工作人員
     因為總幹事是David 所以本著同鄉幫同鄉的因素
     就去幫忙啦 我負責的部分是Brain Hacking 中有關Product的部分
     因為高層中的高層想要寓教於樂 讓員工能夠更了解趨勢的產品
     於是我寫了一套故事 大膽地將我們部門的產品放到遊戲中
     也有Promote的效果
      


      講個有趣的小故事 其實我在謎題中最關鍵的部分偷偷置入性了我的名字
     於是有朋友就以為 解答是我的分機號碼XD

 8.擔任2015 Agile Tour 的工作人員
    年底的時候 也跑去擔任了Agile Tour 台北 跟 新竹的工作人員
    推廣Agile風氣 擔任工作人員有個好處 就是可以免費學習XD
    聽到也學到了很多別人的血淚經驗
    


 9. 學了幾堂很受用的課
      (1) 91學長的 TDD
      (2) Daniel 的CSM
      (3) 福哥的簡報技巧
      (4) Continuous Delivery的Study Group
      (5) 引導者工具箱的Study Group
      (6) 馬拉松式的Code Retreat
      (7) Agile Tour 學到很多別人的經驗
10. 擔任社區的文康委員 規劃了許多活動
       2015 Review - 社區工作篇

 2015真的是個很特別, 很精彩的一年~