從 Clean Architecture 我們學到要把程式架構畫出來,把核心邏輯與其它細節分開來, 避免核心被汙染,達到最終目標:「最小化軟體生命周期的總成本+最大化程式設計師的生產力」。書本裡面給了一個四層的架構圖:Enterprise Business Rules, Application Business Rules, Interface Adapters, Frameworks & Drivers。簡單說前面兩個就是策略、業務規則、核心價值,後面兩個則是細節、資料庫、框架、通訊協定…等等。在這樣的分層規劃下,我們得以確認依賴關係是由外向內的。如果有需要,我們會利用依賴反轉(Dependency inversion principle,DIP)來維持核心的整潔,這樣的架構也允許我們延遲細節的決定。
事件風暴
第二堂課, Teddy帶我們體驗事件風暴(Event Storming),事件風暴是一種快速讓群體進入狀況, 跨部門達成共識的方法,不限於軟體,其實可以應用在各種業務領域,協助建構模型。事件風暴的介紹網路上可以查到很多,規則與範例就不在此贅述,因為事件風暴最重要的是溝通的過程,使用文字敘述很難體會,課程後我與YK(同事)為了讓更多同事也能了解這個溝通方法,因此辦了一個小workshop,邀請了三個不同部門的同事,其中包含測試部門、韌體研發、新技術開發部門一起共同討論「韌體自動化測試工具」這個主題。
共通語言
首先,大家想的真的都不一樣。我們先把12個人分成四個小組,讓大家各自列出這個系統中應該存在的Entity再來互通有無一下,結果發現:有一些東西大家都有共識(每一組都有塞一個專家),一定會有test case,也一定會有report,有一些東西則是我有你沒有,你有我沒有。但是即使是一樣的東西,各自表述之後就會發現,你的report跟我的report可能又不一樣,A組的包山包海,測試結果/細節步驟/結果統計圖,B組的只有成功與失敗,另外還有一個叫做debug log的會包含細節,沒有一個絕對的答案, 重要的是我們要找到共同的語言(ubiquitous language)。共通語言除了釐清彼此的想法以外,還有加速溝通的效果,建立共通語言後,可以提升溝通效率,不論是文件、程式或開會。例如當要做一個跟影像有關的專案的時候,我們可以在早期建模的溝通過程中,發現是不是所有成員都有3A的觀念,知道AE, AF, AWB是什麼,避免專案走到後期,才發現彼此有很大的誤解。
可視化流程
除了共通語言以外,事件風暴還提供了一個全面的可視化流程,我們同步大家的共同語言後,把四組合併成兩個組進行事件風暴,我們故意讓大家先用傳統方法從Entities開始發想,再補充上use cases,讓大家先跑一次流程。
事件風暴跟從核心出發不一樣,而是從領域事件開始展開(我們認為有點像是從use cases展開),兩組分別列出我們在乎的領域事件,看到大家不斷的貼上、移動、調整,對整個流程重新順一次,我想這就是事件風暴要的效果,最後產生一個看得到的用戶故事(User stories)。
我感覺event storming有點類似非coding版本的mob programing,用一種方法把群體的思維聚焦在同一個問題上,並且利用交流讓整體意識調整到相同頻率取得共識,共識後的產物是經過大家認可的業務邏輯與範圍,所以真正執行或實作的時候大家是朝同一個目標努力的。
|
在我們團隊快要一年了
一年的時間
寶寶可以長牙
台灣可以賣出 10 億杯飲料
營業額可以突破千億…
營業額可以突破千億…
| 經濟部統計處: 飲料店營業額在台灣逐年攀升 |
不說飲料
最近回顧了這一年的行事曆
我是有點吃驚的
我是有點吃驚的
OMG!
原來工作的方式,可以這樣影響生活
越工作越有活力
原來工作的方式,可以這樣影響生活
越工作越有活力
如何影響呢?
我先賣個關子,先來看幾個大部分的組織會遇到的現象。
第一個常見現象:開週會
Why are meetings so ineffective?
一個規模不大的四人團隊
一人報告一小時
一場 weekly meeting 就是四個小時
一人報告一小時
一場 weekly meeting 就是四個小時
如果你曾經有在電影院睡著的經驗
應該不難體會四個小時以上的會議有多累
應該不難體會四個小時以上的會議有多累
為什麼 weekly meeting 要開這麼久?
畢竟是一週的進度回報,如果每個人報告一個小時
相當於把他五個工作天,一天八小時的工作量
用 40 倍速的快進,講給你聽
奇怪的是,我們心理從來沒有出現這樣的聲音
“哇! 我聽到了 1/40 的超級濃縮精華/乾貨耶! ”
我們只希望他能再快個 40 倍
這不能怪同事,就像在電影院睡著其實也不能怪導演
這不能怪同事,就像在電影院睡著其實也不能怪導演
沒有哪個導演拍片是為了讓觀眾睡的
比較可能的是 —
那個議題和你沒有共鳴
Great movies tell stories that have deep emotional resonance
|
第二個常見現象:同事間的工作互換困難
Why is collective work difficult?
我們很常因為負責了某個案子,後續的東西都交給你來處理
因為這是短期看來最省時間的做法
因為這是短期看來最省時間的做法
當你在公司一陣子了,你會自然而然地有一個對照表:
“X module 的問題要找同事 A
Y module 的問題找同事 B”
“X module 的問題要找同事 A
Y module 的問題找同事 B”
你應該也對這種情況不陌生 —
同事 B: “A 請假耶,這問題要等他回來才能處理喔! ”
很少同事 B 會說: “A 請假,那你先把東西給我,我可以處理”
同事 B: “A 請假耶,這問題要等他回來才能處理喔! ”
很少同事 B 會說: “A 請假,那你先把東西給我,我可以處理”
但其實,這種工作互換、集體協作的例子,在生活中明明很常見
比如說便利商店的店員,A 忙著做咖啡、B 來幫忙結帳
從沒見過哪個店員跟你說:
“不好意思我不能幫您結帳,負責收銀的今天請假,我只會泡咖啡”
“不好意思我不能幫您結帳,負責收銀的今天請假,我只會泡咖啡”
上述這種情況在組織裡卻很常發生,原因是什麼呢?
可能是訓練文化
不知不覺把 ”人” 訓練成一台 “機器” (咖啡機/收銀機)
不知不覺把 ”人” 訓練成一台 “機器” (咖啡機/收銀機)
因此當我發現這裡的 team member 可以輕鬆的交換手頭上的工作
我是很驚訝的
我是很驚訝的
Machine learning or human learning?
|
第三個常見現象: 加班
Why work overtime?
你有玩過比手畫腳這類的傳話遊戲嗎? 通常結果都是各種歪樓
你可能會說,如果大家都能看到題目就不會有問題
No,還是不行
比如先前 U Think I Do 系列
就把朋友、家人、社會、學校、自己
看到一件事情的不同面向
放在一張圖裡,非常有趣
比如先前 U Think I Do 系列
就把朋友、家人、社會、學校、自己
看到一件事情的不同面向
放在一張圖裡,非常有趣
不同角度的生命科學系
|
撇除那種時程明顯不合理的情況
大多數的加班來自於
每個人對事物的理解不同:
大多數的加班來自於
每個人對事物的理解不同:
以為自己了解對方想要的功能
↓
發現不是對方想要的功能
↓
“盡量” 修改,改不完就加班
↓
發現不是對方想要的功能
↓
“盡量” 修改,改不完就加班
這個 “盡量” 可能妥協了很多事情
如果前面幾次靠著加班,都很幸運的在 deadline 前完工了
如果前面幾次靠著加班,都很幸運的在 deadline 前完工了
再遇到這種情況的時候,就會習慣性的把加班變成解決方法
而忘了去想該修正哪些流程
而忘了去想該修正哪些流程
又下班了?! 我還想工作
|
PM、RD、UX 都用自己的角度去理解、開發功能,在溝通不足、流程不透明的情況下,這個專案就會越來越像一個黑盒子
當老闆問這件事情什麼時候可以做完
是不會有人知道的
是不會有人知道的
高中物理就告訴我們,根據不確定性原理
專案的完成和沒完成,是同時存在的
只有打開黑盒子的一瞬間才會塌縮到一種可能性上
這種 “既完成又沒完成”
把人逼的 “既死又活” 的現象
把人逼的 “既死又活” 的現象
我們稱之為 —
薛丁格的專案
Schrödinger’s Cat 薛丁格的貓
|
本篇文章未完,你可以現在前往 Part2
也可以往下滑留下一些意見
The Year of Being Agile (Part 1)
我們再歸納一下,一般的組織常遇到三個現象:
1. 開冗長的週會
2. 同事間工作互換很困難
3. 加班
2. 同事間工作互換很困難
3. 加班
而我們 team 恰恰相反,有這三個很獨特的地方:
1. 不用開週會
2. 協作容易,你的同事就是你的分身
3. 不用加班
2. 協作容易,你的同事就是你的分身
3. 不用加班
這些特徵好像很難同時並存,你想,不開會怎麼知道同事在做什麼?
同事之間不了解,溝通成本就大
人越多就越複雜,花的時間也多
怎可能不用加班事情還能準時做完?
敏捷開發
Why OverCooked can teach you agile?
來講講 OverCooked 這個遊戲
一開始食物的訂單不多,每個人可以各司其職
專門切肉,專門煮菜,專門洗碗
而隨著訂單暴增和廚房地形改變
如果還是一個人只負責做一件事,時間肯定是不夠用的
一款具備敏捷精神的遊戲
|
Get back in sync
左上角可以看到現在的訂單有哪些
一回合的時間完成越多訂單得分越高
這是一款用嘴巴打仗的遊戲
你準備要拿料還是煮菜
需要什麼幫忙
哪邊需要修正
都要即時說出來
每個玩家都可以看到夥伴的狀況
這種快速 team sync 的方式就是 —
daily scrum meeting / standup meeting
Realtime review
這款遊戲一次最多四位玩家
如果有八個人玩呢?
一般情況就是多出來的四個會在旁邊
觀戰並且嘴砲給建議
等到下一回合再換這一組人拿搖桿
這種 driver & navigator 的方式 —
pair programming / mob programming
The programmer as navigator
|
介紹完遊戲,應該就不難回答我們一開始的問題
How to avoid boring meetings?
這個 team 不是不開會
而是不開沒有效率的會
daily meeting 有一些限制:
最多 15 分鐘,站著開
類似遊戲一回合的計時制
講求快速同步最新狀況
How to develop a cohesive team?
再來講協作:
關心不等於了解
想要了解一件事情
沒有什麼比實際參與還有效的
針對複雜的 task 安排 pair / mob
提倡 collective code ownership
簡單說就是共榮共享
但這樣講可能有點土
所以來看一下維基百科的定義:
合作或協作(英語:Collaboration)是指一種由兩個或兩個以上的個人或團體作為一個共同的目標而交集或在一起共同工作,舉例說明:一個知識分子可以透過合作的關係而去分享知識,再而經過學習和共識達到創作的目標
從上面描述看的出來
合作和凝聚力脫不了關係
那怎樣才能有好的凝聚力呢?
借用本公司的四大核心價值
誠信、 關懷、創新、當責
誠信、 關懷、創新、當責
肯定每個人的付出
讓每個人都看到自己的貢獻 —
一個人走得快一群人走得遠
Why collective intelligence matters?
電影環太平洋裡面
龐大的機器人無法由一人駕駛
需要兩位駕駛員連接彼此的腦神經
共享對方的情感、記憶、經歷
並且認同對方的處境之後
才能同步操控
Pacific Rim: Uprising (2018)
|
好的溝通和協作
就是用心和時間
灌溉的共同記憶
他會形成一個生命體
持續成長
或者說他就是一個生命
你們必須承擔起照顧這個生命的責任
也是這份承擔
讓你們之間的關聯
獨一無二
True collaboration yields better results
|
Iteration based method
Iteration 翻成中文『迭代』
在敏捷方法中是指
把一個大任務切成許多小週期可以完成的的任務
把一個大任務切成許多小週期可以完成的的任務
騰訊創始人馬化騰說:
小步快跑、快速迭代
小步快跑、快速迭代
這是他的產品思路
也成為互聯網創業法則
也成為互聯網創業法則
敏捷開發裡的迭代週期是一個 sprint
sprint 這字有短跑衝刺的意思
很符合迭代的概念
一個 sprint 一般為 2 ~ 4 週
sprint 這字有短跑衝刺的意思
很符合迭代的概念
一個 sprint 一般為 2 ~ 4 週
由團隊討論這個 sprint 能完成的功能
並在 sprint 結束時做個『試營運』
並在 sprint 結束時做個『試營運』
拿到客戶的 feedback
並且快速的衡量修正
並且快速的衡量修正
為了好懂,借個圖舉例
比較了傳統方法與敏捷開發法
如何在三個迭代週期完成蒙娜麗莎
如何在三個迭代週期完成蒙娜麗莎
Jeff Patton did an Iterative Mona Lisa.
|
先來看傳統的開發方法:
在第一階段可以看到蒙娜麗莎的頭
第二階段能看到蒙娜麗莎的左下半身
第三階段是完整的蒙娜麗莎
在第一階段可以看到蒙娜麗莎的頭
第二階段能看到蒙娜麗莎的左下半身
第三階段是完整的蒙娜麗莎
換成用敏捷開發會怎樣呢?
在第一階段是極簡主義派的蒙娜麗莎
第二階段是簡單上色派的蒙娜麗莎
第三階段是佛羅倫薩畫派的蒙娜麗莎
第二階段是簡單上色派的蒙娜麗莎
第三階段是佛羅倫薩畫派的蒙娜麗莎
不論哪個階段都是最小可行產品
很傳神地描述了敏捷的精神 —
很傳神地描述了敏捷的精神 —
接受反饋、迅速擴張
盡快給客戶有價值的產品
盡快給客戶有價值的產品
敏捷帶來的影響
How does agile affect my work and daily life?
所以回到一開始我賣的關子
那個讓我吃驚的行事曆
那個讓我吃驚的行事曆
我發現從以前到現在
晚上時間的利用有了很大的改變
從同事電腦辦公桌變家人散步吹吹風
以前晚下班總要負責關公司的門
有時候關得太順就會不小心鎖到別人
下圖的例外就是我補充的
關門 SOP
|
這一年有了固定的下班時間後
我開始能每天帶著媽媽去運動
我開始能每天帶著媽媽去運動
運動的地方是學校的操場
晚上學校警衛要關門的時候
看著警衛一邊關燈一邊趕人
看著警衛一邊關燈一邊趕人
這種熟悉又親切的感覺 —
等我退休了或許可以來當警衛吧 😝
前是把家當旅館現在是家事盡量管
The Year of Being Agile (Part 2)
平常 C++ 的開發工具是 Microsoft Visual Studio,然後現在的測試框架是使用 Google Test,以前都是一邊寫,一邊手動執行
test case 來驗證,沒有辦法跟 VS 內建的 Test Explorer 做整合,真的蠻原始的 =.=
最近因為 TDD 的關係,這樣子的開發環境真的太鳥了,所以認真研究了一下解決方案,發現了 Google Test Adapter 這個好東西:
https://github.com/csoltenborn/GoogleTestAdapter
很簡單,照著 github 上的說明安裝完後就可以使用。幾個要注意調整的地方:
public class E : VisualCommanderExt.IExtension
{
public void SetSite(EnvDTE80.DTE2 DTE_, Microsoft.VisualStudio.Shell.Package package)
{
DTE = DTE_;
events = DTE.Events;
documentEvents = events.DocumentEvents;
documentEvents.DocumentSaved += OnDocumentSaved;
}
public void Close()
{
documentEvents.DocumentSaved -= OnDocumentSaved;
}
private void OnDocumentSaved(EnvDTE.Document doc)
{
if(doc.Language == "C/C++")
{
DTE.ExecuteCommand("Build.BuildSolution");
DTE.ExecuteCommand("Test.RunAllTestsInSolution");
}
}
private EnvDTE80.DTE2 DTE;
private EnvDTE.Events events;
private EnvDTE.DocumentEvents documentEvents;
}
完工,現在只要存檔,就會自動 Build,並且在 Test Explorer 看到紅燈綠燈了
最近因為 TDD 的關係,這樣子的開發環境真的太鳥了,所以認真研究了一下解決方案,發現了 Google Test Adapter 這個好東西:
https://github.com/csoltenborn/GoogleTestAdapter
很簡單,照著 github 上的說明安裝完後就可以使用。幾個要注意調整的地方:
- 原本它會搜尋結尾為 test / tests 的執行檔來分析裡面的 test case,所以如果你的 Unit Test 程式不是 xxxTest.exe 的話,請記得到 [TOOLS] –> [Option] –> [Google Test Adapter] –> [General] ,裡面有一個 Regex for test discovery,我是使用 UT_[\w]*.exe
- 在同一頁中還有一個 Working directory & PATH extension,如果你的執行環境不是在預設的 output directory,也請記得修改。
- 修改 Unit Test Project 會自動跑 test case,但修改原本的 project 並不會被偵測到
- 希望可以每次存檔後,就自動 Build & Test ,這樣只要專注綠燈/紅燈就好了。
public class E : VisualCommanderExt.IExtension
{
public void SetSite(EnvDTE80.DTE2 DTE_, Microsoft.VisualStudio.Shell.Package package)
{
DTE = DTE_;
events = DTE.Events;
documentEvents = events.DocumentEvents;
documentEvents.DocumentSaved += OnDocumentSaved;
}
public void Close()
{
documentEvents.DocumentSaved -= OnDocumentSaved;
}
private void OnDocumentSaved(EnvDTE.Document doc)
{
if(doc.Language == "C/C++")
{
DTE.ExecuteCommand("Build.BuildSolution");
DTE.ExecuteCommand("Test.RunAllTestsInSolution");
}
}
private EnvDTE80.DTE2 DTE;
private EnvDTE.Events events;
private EnvDTE.DocumentEvents documentEvents;
}
完工,現在只要存檔,就會自動 Build,並且在 Test Explorer 看到紅燈綠燈了
Google Test Adapter
今天上 LeSS,沒想到這邊的 Large Scale Scrum 已經發展到這麼成熟了...果然是連車尾燈都看不到。今天的同學,大部份都有豐富的LeSS相關經驗,也有搞 SAFe 的,也有 Scrum coach,真的是令小弟無地自容..
這裡頭的故事,就讓我娓娓道來..
------------------------------------------------------
去年二月上完呂毅老師的 CSM 之後,對呂毅老師的授課方式及內容印象很好,然後公司內的 Scrum 團隊也開始在增加,因此當老師寄信來說要開 LeSS 的課程時,就毅然決然的報名了。
這次的課程在 Odd-e上海辦公室(隨著上海房價的飆漲,應該叫 Odd-億上海豪宅 才對) ,就在世紀公園正對面,我挑了最近的四星酒店[帝盛酒店],地鐵2號線[世紀公園站]出來就到,走路到豪宅上課也只要10分鐘,推薦給大家,下次去上課,訂這間就對了 XD
早上的課程一開始,先是同學們的自我介紹&你想學到什麼?,總共有11位學生,只有我一位是從台灣過來,剩的大部份都是從杭州過來。大部份同學的產品都是硬體產品,少數是純軟的,因為公司規模都很大,所以大部份都已經是 LeSS-like 的架構在運作,而且應該已經運作好幾年了..
自我介紹完,老師就開始講系統分析,這次 LeSS 的課程,重點不在講 LeSS 要遵循的那些規則,因為那就看書照著作就好了,老師反而是帶我們了解背後的原因(我覺得這是呂毅老師一貫的上課風格,就是投影片其實都很快就帶過,都在講投影片沒寫,更深層的一些想法)。
一個還是多個 product backlog ?
一個還是多個 PO?
一個還是多個 Scrum Master?
Feature Team or Component Team?
一個還是多個 PO?
一個還是多個 Scrum Master?
Feature Team or Component Team?
LeSS 在很多選擇中,做出了決定,而形成了 LeSS,為了了解這個決定背後的道理,老師先介紹了系統分析方法(CLD Causal-Loop Diagram):
Variable:變量
Link:連結
Loop R-loop & B-loop 增強迴路及平衡迴路,可見[第五項修練]&[系統之美]
而在二天的課程當中,我們總共實際演練了4次CLD,我覺得這點很重要,因為要做到[守破離],唯有洞悉背後的因素,才能到破,然後到離。LeSS(或著就稱大規模Scrum好了)在實際運作時,一定會碰到各式各樣的狀況,這時要如何調整團隊及運作方式,系統分析就很重要了。
Variable:變量
Link:連結
Loop R-loop & B-loop 增強迴路及平衡迴路,可見[第五項修練]&[系統之美]
而在二天的課程當中,我們總共實際演練了4次CLD,我覺得這點很重要,因為要做到[守破離],唯有洞悉背後的因素,才能到破,然後到離。LeSS(或著就稱大規模Scrum好了)在實際運作時,一定會碰到各式各樣的狀況,這時要如何調整團隊及運作方式,系統分析就很重要了。
講到這,提一下這次看到的:有些公司的 Scrum Team 沒有 Scrum Master(好,你也可以說這不能叫Scrum Team),有些也不一定都是Feature Team,有些會摻些 Component Team,有些自己添加了一些 roles 來處理溝通協調,有些公司處理bug是由專門團隊負責,也有一定是找回原作者的..,有些 team 竟然有所謂的"組長"..有些人有 release sprint,有些人有獨立的 testing team 來平行進行測試。
非常多的變體,所以這次課程中一個很大的收穫是,了解這些變體背後的原因,然後,我們這種才從[守]開始的,對於他們組織改變、心智模式改變已到[破、離]的速度,感到震撼,而且,他們都是很巨大的公司,也有很老的公司,還能這麼有魄力的改變,真的很厲害。最厲害的是,這些都是枱面上很成功的公司,一聽到就會 哇 的那種成功公司..
非常多的變體,所以這次課程中一個很大的收穫是,了解這些變體背後的原因,然後,我們這種才從[守]開始的,對於他們組織改變、心智模式改變已到[破、離]的速度,感到震撼,而且,他們都是很巨大的公司,也有很老的公司,還能這麼有魄力的改變,真的很厲害。最厲害的是,這些都是枱面上很成功的公司,一聽到就會 哇 的那種成功公司..
轉回CLD,為了讓我們熟悉CLD,老師用了[狼圖騰]裡頭的故事讓我們練習,簡單說:
Variable:狼,野物,草場,牛羊馬,設備
Link:狼會吃野物&牛羊馬,野物會破壞草場,草場可以養育牛羊馬,牛羊馬帶來錢,有錢可以買好設備,好設備可以讓草場更好
Loop:上面這些 Link 可以形成各種 R-loop & B-loop ,因此我們在這個 CLD 中,就可以想看看,如果希望牧場的利益最大化,應該要怎麼做最好?也可以看出來那些作法是"飲鴆止渴",那些作法是"長久之計"。
Variable:狼,野物,草場,牛羊馬,設備
Link:狼會吃野物&牛羊馬,野物會破壞草場,草場可以養育牛羊馬,牛羊馬帶來錢,有錢可以買好設備,好設備可以讓草場更好
Loop:上面這些 Link 可以形成各種 R-loop & B-loop ,因此我們在這個 CLD 中,就可以想看看,如果希望牧場的利益最大化,應該要怎麼做最好?也可以看出來那些作法是"飲鴆止渴",那些作法是"長久之計"。
這時再回來看,大型 Scrum 是要 1 Product Backlog 或著 多個 Product Backlog 就很有趣了
:)
就在這一堆CLD的討論中,結束了早上的課程。
中午老師帶我們到附近吃山西菜,山西菜份量多又紮實,吃完一餐就胖了一圈 XD 分享一下午餐故事,做為這一集的 ending
--
同學A:還多一塊羊排呀,誰把它夾掉吧
同學B:台灣的同學比較沒吃過這味道,給台灣的同學吧~
Diro:啊,我們台灣也是有羊的啊!!(但我還是吃了.......)
同學C:這個韭菜盒子也多一個啊~~
Diro:耶,我告訴你,我們台灣也有韭菜盒子,不要再叫我吃啦
--
[某大企業的HR打來]
HR:我們這裡缺 資深測試工程師 ,你有沒有興趣呀?
同學B:耶,你怎麼判斷我很會測試的呢?
HR:我看你的技能上有個 Test-driven Development 的經驗
同學C: 上次我們QA部門也很緊張的跑來找我
QA:聽說你們現在要弄什麼測試驅動開發,先跟我們交流交流吧
同學C: 這跟你們QA可能沒什麼關係..
QA:這上頭明明就寫著測試兩個字,你不要再騙我了..
--
同學A:你們 Scrum 跑多久了呀?
Diro:二年多,應該是2014吧~
同學A:2014?(驚),那真的還蠻慢的呀..
--
下午的課程,因為吃太飽,我就睡著都沒聽到了...
--
同學A:還多一塊羊排呀,誰把它夾掉吧
同學B:台灣的同學比較沒吃過這味道,給台灣的同學吧~
Diro:啊,我們台灣也是有羊的啊!!(但我還是吃了.......)
同學C:這個韭菜盒子也多一個啊~~
Diro:耶,我告訴你,我們台灣也有韭菜盒子,不要再叫我吃啦
--
[某大企業的HR打來]
HR:我們這裡缺 資深測試工程師 ,你有沒有興趣呀?
同學B:耶,你怎麼判斷我很會測試的呢?
HR:我看你的技能上有個 Test-driven Development 的經驗
同學C: 上次我們QA部門也很緊張的跑來找我
QA:聽說你們現在要弄什麼測試驅動開發,先跟我們交流交流吧
同學C: 這跟你們QA可能沒什麼關係..
QA:這上頭明明就寫著測試兩個字,你不要再騙我了..
--
同學A:你們 Scrum 跑多久了呀?
Diro:二年多,應該是2014吧~
同學A:2014?(驚),那真的還蠻慢的呀..
--
下午的課程,因為吃太飽,我就睡著都沒聽到了...
ODD-E LESS@上海 心得&攻略 PART 1
VIVOTEK Digest
這裡是 VIVOTEK 晶睿通訊 的技術部落格,我們在這裡分享與敏捷、Qt/QML及其它軟體相關技術
Trending
-
「不要試圖覆蓋所有使用案例。Spec.不是用來替代組合回歸測試的。」 - Spec by Example 中文版 p.151 但我們明明覺得現在用 Robot Framework 實現自動化 UAT 來替代組合回歸測試是很正確的做法,為什麼作者覺得這樣不對? 我認為...
-
平常 C++ 的開發工具是 Microsoft Visual Studio,然後現在的測試框架是使用 Google Test,以前都是一邊寫,一邊手動執行 test case 來驗證,沒有辦法跟 VS 內建的 Test Explorer 做整合,真的蠻原始的 =.= 最近因為...
-
針對常用的match role, 可利用QHash (or QMap) 多存一份, 來加快 search 效率 我們在設計model通常都會定義一個存unique string value的IdRole當作model item的索引, 且會很頻繁對這個role作ma...
Categories
Programming
19
Culture
11
Testing
6
scrum
6
Agile
5
performance tuning
4
Book
3
Code Quality
2
Qt
2
Event Storming
1
database
1
file system
1
virtual machine
1




