Diro's Journey

Programming Cooking Music Photography

https://agileneihu.kktix.cc/events/trickinretrospective

這次的講者 Sam 讓大家試著用國家元首的角度,回顧這一個月國內外發生的新聞事件,然後進行討論、擬定行動方針。整個流程包括了:開始 -> 回顧 -> 探索 -> 進化  -> 結束



在回顧、探索及進化三個階段,講師示範的方式是在壁報紙上,畫上了時間軸及各種面向來引導團隊開始貼便利貼,這是我以前沒有用過的方法,所以有一些啟發:


時間軸(月初~月底)
這個月發生了什麼新聞?結果大家只記得世大運跟這幾天的新聞,前半月的早就忘光了 ><"
有了時間軸輔助,才驚覺自己記憶力有多差,可以想想回顧回議是不是常常都只討論"最近"發生的事情?
啟發:
1. 回顧會議不能一個月一次(一個 sprint 如果長度為 4 weeks 的不知怎麼開?)
2. 也許可以平常就紀錄每天發生的點滴 (good, better) 來解決失憶症的問題,哈

多面向(國內新聞、國外新聞)
如果讓大家直接想,我猜大家只會寫國內新聞 XD ,但因為有在壁報紙上先劃了國內新聞及國外新聞二區,就會驅使團隊也想想國外新聞,我覺得這點還不錯。
啟發:
1.讓團隊自由發想、貼便利貼時,有時提出來的東西會漏掉一些面向,例如團隊可能都是在想一些工程實踐上要改善的東西,但漏了跟 PO 溝通互動這一塊,但如果先在壁報紙上做幾個面向的分類及提示,可以解決這個問題,例如:[工程實踐] [團隊合作] [對外溝通]

其它筆記:
愈靠近的人(實體位置及心靈距離),講的話聽的愈清楚。所以讓近的人一起開回顧會議是最有效果的,而且如果是發自內心自己想要的,就更棒了。這是講者喜歡引導的原因 :-)



今天上 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?

LeSS 在很多選擇中,做出了決定,而形成了 LeSS,為了了解這個決定背後的道理,老師先介紹了系統分析方法(CLD Causal-Loop Diagram):
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 中,就可以想看看,如果希望牧場的利益最大化,應該要怎麼做最好?也可以看出來那些作法是"飲鴆止渴",那些作法是"長久之計"。
這時再回來看,大型 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?(驚),那真的還蠻慢的呀..
--
下午的課程,因為吃太飽,我就睡著都沒聽到了...

http://www.taaze.tw/sing.html?pid=11100723738

本書獲得《Dr. Dobb’s Journal》肯定,榮獲第21屆Jolt獎。

打造優良的軟體開發團隊,除了要大家有敏捷的觀念外,基礎建設也是非常重要的。前一陣子唸完了 Continuous Delivery 之後, 便開始計畫要把不足的部份補完(如果不知道 Continuous Delivery 有什麼好處,可以先上網查查,或著看看書 XD),在幾位同學的努力之下,花了一個多月把缺的部份補上,包含架設CI Server、夠好用的build script、Robot Framework for QML、Unit Test integration。

  1. CI
    1. 我們選定的 CI 是用 TeamCity,其實 Jenkins 也不錯,但是比較起來商業化的軟體在易用性及介面上,還是略勝一籌,加上之前也都是在用 TeamCity,我覺得用 TeamCity 可以更快上手。
  2. Unit Test
    1. Unit Test 使用 Google Test,為何捨棄原本的 Boost Testing Framework?一個原因是它在 mock/stub 這一部份還不及 Google Test 完整,因此我們選用了 Google Test。
  3. UAT (User-Accaptance-Testing)
    1. UAT 的部份則是使用 Robot Framework,沒有特別原因,只是因為有其它同事正在用,就一起用吧 XD
  4. Qt/QML Testing Framework,
    1. GUI Application 的測試,有一點很重要的是要以 HANDLE、object ID 來操作,而避免使用”圖形”的方式來操作,因為你的 GUI 有非常大的機率會調整,只要一改,你的 test case 就要全部重來了。但是 QML Application 裡頭是沒有所謂的 window handle 的,跟傳統的 Windows Application 不大一樣,而目前市面上只有 Squish 有辦法去對 QML Application 做到使用 object ID 來操作。(Ubuntu 的 testing tool 似乎也有,但沒有深入研究)
    2. 但我們並沒有使用 Squish,而是讓我們的程式原本就具備這樣的”可測性”,也就是說我們自己做了一個 python library,可以讓開發人員透過這個 python library 來操作我們的 QML Application。而 Robot Framework 就是透過這個 python library 來完成 keyword-driven testing。不知道什麼是 keyword-driven testing 的話,可以參考 http://kb.froglogic.com/display/KB/Article+-+Keyword-driven+testing+with+Squish+and+Robot+Framework
就這樣,透過上面四個元件的合作,我們完成了 Continuous Delivery 的目標。這個系統會自動完成下面的工作:
  1. 有團隊成員 commit code 之後,開始進行 build,然後執行全部的 unit test
  2. 通過 unit test 之後,自動打包成準備釋出的 installer.exe
  3. 接下來自動依序發佈到不同平台的 VM 上去進行測試。
  4. 系統呼叫 sikuli,自動在各個 VM 裡頭執行 installer.exe,並完成軟體的安裝。
  5. 安裝完畢,會呼叫 Robot Framework 開始進行 UAT (User-Acceptance-Testing)。
  6. 完畢,產生報告。
有了 Continuous Delivery,現在 RD/UX/PO 都隨時可以下載最新版的”已測試過"軟體來使用,再也不用等人手動去 build 出來了。

更多技術細節,就等其它人分享了 :) 


Older Posts Home

ABOUT AUTHOR

Follow us

POPULAR POSTS

  • QML + Arduino / Web + Arduino
  • QML + LeapMotion & Arduino
  • [SOFT] TeamCity - 好用的 Continuous Integration 持續整合工具
  • How to Integrate Robot Framework with TestRail
  • [DECO] Eva Solo 花盆

Categories

  • 2016 5
  • agile 3
  • Bike 4
  • Book 4
  • Cooking 1
  • DECO3 4
  • House 8
  • Interior Design 4
  • IoT 1
  • IT 7
  • Life 13
  • Photography 1
  • Programming 22
  • QML 8
  • Qt 9
  • Scrum 3
  • Software 19
  • Travel 9
  • UAT 1
  • Uncategoried 3
  • 喇叭 1
  • 裝潢 6

FOLLOW US @ INSTAGRAM

About Me

Popular Posts

  • Odd-e LeSS@上海 後記 Part 4
    在 LeSS 最後一天,聽到別的公司在導入敏捷時,也成立了很多很多的實踐社群 CoP (Community of Practice),其中一個是 心靈成長 CoP,讓我印象非常深刻,這邊來聊聊為什麼 :) 在第五項修練中,彼得聖吉一直在強調"整體": 「遠古的人類並...
  • 單車路線#5 - 大坑缺溪-秀才窩自行車道-梅崗
    沿大坑 缺 溪騎到鎮南橋後,直走接往中庸路,經過一小段爬坡即接往福羚路,再往接瑞溪路即可抵達楊梅愛買後方,接著往裕成路(五楊高架下方)是我騎到楊梅最喜歡的路線。裕成路到底後,便到達楊梅校前路,是熱門的自行車路線,校前路前行便會抵達這條路線的重點-秀才窩自行車道,這個路線會穿過小茶...

Advertisement

Copyright © 2016 Diro's Journey. Created by OddThemes