發表文章

一個敏捷分子的獨白

圖片
 大家好,繼上次的 scrum master 的獨白以後,再來寫寫作為 agilist 的感想。 我在遇到問題的時候,常常會去尋找正確答案,這是學校教育教會我們的,甚至他也會教給我們怎麼樣去找出這樣的正確答案。 於是,好像有一種想法會慢慢地成形,那就是世界上有好人也有壞人,有對也有錯,有黑也有白。而我們必須在這兩個之間選一個。 我說不是這樣的, 在敏捷的世界裡,沒有絕對的好壞,沒有絕對的對錯,也沒有絕對的黑白。 在敏捷的世界裡,應該像是這樣的: 其實很多做法,很多安排,很多 你遇到的挫折,拉長時間來看,以整個團隊來看,甚至,是以整個公司來看,都沒有絕對的對錯,有的時候,We are on the right side of wrong, or wrong side of right. 很多我遇見的敏捷的朋友, 大部分都已經在一個敏捷的公司了, 少部分的朋友還在不那麼敏捷的公司,要馬就是苦苦的努力做一些事情想要改變現狀,要不然就是習慣了。 我可能命比較沒有那麼好, 從來沒有一開始就待在一間敏捷的公司過,所以有的時候我都會幫忙做一些想要變敏捷的事情。可是敏捷真的是對的嗎?是好的嗎?Not really. It depends. 很多的東西,我覺得在這次 2022 agile summit 的投影片都有了,投影片,我放在這裡了: https://www.slideshare.net/doyouknowsoftware/agilist-253555022 我的投影片就是字他媽的多,所以應該看得懂,我很多東西就不提了。以下重點摘錄: 1. Agile 啊,你可以說是心態,是生活態度,都對。但其實真的回去看看敏捷宣言吧~ 2. 你的敏捷跟我的敏捷跟他的敏捷真的不一樣!真的啦! 3. 關於組織(公司或 BU 或部門) 導入敏捷,是必須扯到規模化的議題的。 一個方向是:學會敏捷,摸透敏捷以後,然後試著把它規模化,套到公司或是 BU 的架構裡面,可以,合理。但過程中就是會格格不入,很卡。這個推動敏捷的人,要把自己練得很強,要搞定上上下下左左右右的所有人,這個過程很痛苦,通常會讓這個人受盡委屈而自動離職,也就沒有後續了。通常這個方向會形成 LeSS, Nexus, 大的看板方法這些路線。 另一個方向是: 先看清楚現實面,組織架構就是長這樣,主管就是那樣子做管理,等等,反過來從這樣的角

scrum master 的獨白

圖片
先說個故事,我當兵時,是古早的國防役,跟科技替代役不同,我們是真的要服役三個月,然後被派到某公司或研究單位工作四年的那種。 有一次我們被叫去拔草,五個人一排,總共三排往前拔,要從這邊拔到那邊。 我那時候年輕啊,天氣又熱,我恰好又是第一個,我就亂拔一通,拔得特別快,反正後面還有兩個人會拔麻,先是這樣: 後來就這樣了: 這時候,班長出現了: 班長就喊停,叫我們休息一下,這時候他特別叫我過去立正站好,不是要罵我,反而是跟我 1 on 1: 「120 啊,你有唸書啊,你是大專學歷,是不是?」 『報告班長,是。』 「我跟你說,你拔這個草啊,這樣拔也是拔啦,沒錯啦,可是,你是有唸書的人,如果你拔草的時候,能往上想三層,你這個草就會不一樣了。」 『...?』 「聽不懂齁~你看喔,你往上想一層,就是我,我這個班長會怎麼看你拔這個草,啊這個草要拔成怎樣?再往上一層,排長會怎麼看你拔這個草,要拔成怎樣?再往上一層,連長咧?他會怎麼看你拔這個草,要拔成怎樣?」 『。』 「如果你能用這個角度去看你拔的草,你拔的草就會不一樣了,我這個班長也就會很輕鬆了,我也不會定你,你日子也會比較好過。」 這個往上想三層的哲學,一直在我心中。 謝謝那個有點胖胖的、臉方方的、很愛改車的班長,但我忘記他的名字了。 XDDD 順便說一下,我們國防役,士官長好像很少出現... 我想在職場,任何角色也都是一樣,大家都是領人薪水,假如你能往上想三層,去看你的工作該怎麼做,做成怎樣,比如說,你這個 code 該怎麼寫?這個 UI 要怎麼設計,這個功能要怎麼測試等等,其實很多事情都會更清楚的。 老實說,我上面三層的連長,肯定看不到我每隻草是怎麼拔的,他只會看到最後這片連集合場有沒有雜草;同樣的,你上面三層的主管,可能不會打你的考績,但是他看到的是最後大家的東西是能夠整合出的來的,是可以拿去換錢的。而這過程中,有好多問題要解決。 如果你能把自己的視角(Perspective)提升到那個高度,你就會不一樣了 你上面三層的主管,現在遇到什麼問題,他用什麼方法解決?你,能不能跳出來幫他解決?你用的方法是 PMP? CMMI? 如果你恰好要用 scrum 來幫助他解決問題呢? 在這個情況下,Scrum 就是功夫了,他是真刀真槍的對決,在商業的世界裡的對決,是有人會死的,是攸關生死存亡的。你不能說,因為我的存在,讓我的團隊都變得更好了

牛仔很忙,主管忙不忙?

圖片
 主管啊,你領得多,做得事情當然要成正比,開的會議也要成正比,你當然應該忙啊。 是吧? 是嗎? 來用 主管很忙當關鍵字 google 一下:

真的需要自動化測試嗎你?

圖片
啊~久久寫一次,一次寫一大篇 XDD 以前我上課在講敏捷測試或是實際在帶敏捷團隊的時候,常常被問到說,Sprint 這麼短, 一個禮拜或兩個禮拜就結束了,測試跟不上啊!是的,如何用測試確保品質,是很多測試人員進入 scrum 後遇到的常見問題。 我都會用這個當例子,我的師父也是這樣教我的: 假設1. 開發人員每個 Sprint 開發 5 個 PBI。 那麼測試人員在第一個 Sprint 需要測試五個 PBI。 很直覺麻,要確保 DoD 有符合麻。還是有人覺得開發出來的東西不用測試? 那第二個 Sprint 呢? 開發人員仍然開發出了五個 PBI,測試人員要測幾個? 五個嗎?錯! 應該要測 10 個,因為測試人員需要知道第一個 Sprint 的五個 PBI 有沒有被改壞啊。所以第二個 Sprint,測試人員要測 10 個 PBI。 第三個 Sprint 呢? 理論上要測15個。 這兩個的關係我們可以做出以下的圖: 可是一個測試人員, 在一個 Sprint 內,肯定沒辦法這樣子測啊,總有個上限吧。於是,我們做了第二個假設: 假設2. 測試人員只有一個,他每個 Sprint 只吃得下 30 個 PBI 的測試。 在假設1, 跟假設2, 的情況下,現在我們的要解決的 問題是:在第七個 Sprint 之後, 測試人員會跟不上開發的腳步。 解法呢? 我這邊提出一些解法給各位參考: 解法一: 大聲宣佈這種迭代式的開發是不能保證品質的,然後回瀑布式開發。 大家回到瀑布式的開發,抓出測試的時程,其中包括 system integration test 以及 user acceptance test,在這兩個階段都要做回歸測試。這段測試時間的長度,取決於這一次 release 的大小或是產品的複雜程度,通常會建議是半個月到兩個月不等的時間。 這個解法的好處是真的可以確保品質,讓測試人員把關,而且管理者(比如說 PM、主管), 可以看得到測試時期的數字,比如說測試通過率等等。 壞處當然顯而易見的是,在測試時期會花掉一些時間,導致整個 schedule 往後,實務上的經驗是,通常在前面的計劃以及開發階段花去很多時間,擠壓到測試的時間,導致測試人員的時間壓力非常的大,甚至有可能造成開發部門跟測試部門之間的對立。 解法二: 使用自動化測試 讓測試人員撰寫自動化測試,讓每一個 Sprint 完成