近況

最近,其實過得不是很好。可能有點憂鬱,有點躁鬱。對很多事情,都很沒耐心。有種總人皆醉我獨醒的感覺。

我想忍聲吞氣的,不過已經睡不好很多天了。每晚回家後都在想怎麼應付明天而輾轉難眠。無法控制情緒已經讓我更加不安了。我決定做自己的抒發。

做人嘛,催眠自己,讓自己過得好,應該是常情。不過,以推卸責任,然後催眠自己做得好,你腦子才有病吧?!怎麼變成是我病了?這就是“合群”效應。當大部份人都催眠自己,這個錯誤是他人的,因此,那個“他人”要改善。

我從事電腦、雲端相關的工作。去年年底,我兼做了用著的platform的functional owner,他們給了一個超好聽的名字,叫做business consultant。主要工作內容是寫requirement,讓程序員可以更了解他們要做出的product。不過,我又不是product owner,因此,我的工作比較屬於輔助性的。每每他們做出令人傻眼的作品出來,都是怪在requirement寫得不清楚。那個頭領每次都投訴我寫得太詳細,沒有給他們可以做出調整的空間。甚至試過一個project,直接把我摒除在外。當sprint要開始的時候,突然間說,沒有functional document,他們無法開工,然後把矛頭拋向我。X的。我也不是省油的燈。我直接說,我從來沒有參與任何討論,不曉得那是什麼project,該交由那些參與討論的人負責寫。那是幾個月前的事了。從此以後,就沒有發生任何project我被摒除在外的事情。

這次的sprint都是簡單的幾個小feature。其中一個,是要求一個小button來reset status。需要這個button,因為這個platform也太⋯⋯當deploying project的時候,那個project的status可能會死在Installing state。嗯,是status,而backend該做的事情,可能hang了,可能完成。不過接下來backend的step是無法繼續了。因此,我們得patch database,通過這樣的workaround來做undeployment for clean up,再然後重新deploy。Patch database呢,是因為直接改database,需要經過change management,得等荷蘭那邊開始工作了,assess了change request,再等infra team去做DB patch,我們才得以繼續我們的工作。有時候,往往是time critical的。我們會打電話去荷蘭那裡,做escalation。因此,這個request是要一粒button來reset那個status而已。結果~等到demo的時候,給了我一個drop down,和現有的一個form一起做update。變成,user要改成什麼status,隨由user。你知道這麼做多危險嗎?如果剛好要改其他field的value,然後剛好那個implementation的state改變了,而你按那個save button會把implementation的state弄錯?!Retrospective的時候,你說,這是因為requirement不clear。至少我要的是一粒button,有說到button,沒說到drop down,很明顯吧?!不clear不會問啊?!全部人睜著眼睛說鬼話。這只是其一。這個sprint只有幾個小feature,結果有三個feature是不符合要求的。不要去搜我在哪間公司工作,然後覺得我們公司不可靠。這些不穩定的東東,都交由我們去把該做好的做好,像我team lead常用的字眼,die die have to do it。親愛的客戶,為了滿足您的需求,您知道我們有多stress嗎?完美的包裝底下,我們花了多少心血嗎?親愛的D-level,C-level的上層,您知道您的dev team在做啥嗎?

第二個,原以為是不符合要求,因為demo說,那粒button只有在很特定的情況瞎才會出現。結果,那個放假回來的dev說是因為bug,那粒button應該都會出現的。QA瞎了嗎?(抱歉,不想人身攻擊,不過,這是simple testing吧?該show button的時候,沒show button。Dev也沒檢查自己的作品嗎?)第三個,是改善error message,developer自己做決定,自己去改每個error message的字眼,包括一些屬於比較technical的資料,不應該出現給end user的。問起QA怎麼一回事,他說,他不知道這些error會被end user看到,因此沒在意。

拜託,可以認真工作嗎?!

現在更離譜的是,這個sprint沒有fail。為啥呢?因為沒有寫acceptance criteria。既然沒有acceptance criteria,就不能說fail。把那三項變成了下一個sprint裡的task。然後得寫acceptance criteria。然後那個AC得寫得很詳細,這樣就不會有問題了。

對我來說,那已經是在寫test scripts,或他們說的test steps了。還說什麼behaviour driven development wor...

Acceptance criteria
A description of each specific scenario of the narrative with the following structure:
Given: the initial context at the beginning of the scenario, in one or more clauses;
when: the event that triggers the scenario;
then: the expected outcome, in one or more clauses.

然後,就寫成這樣。
AC1 : Given I am delivery engineer, when I go to XX1 implementation deployed with YY1 version page, then go to ZZ1 page, then I will see the button.
AC2 : Given I am delivery engineer, when I go to XX2 implementation deployed with YY2 version page, then go to ZZ1 page, then I will not see the button.
AC3 : Given I am delivery engineer, when I go to XX1 implementation deployed with YY1 version page, then go to ZZ2 page, then I will see the button.
AC4 : Given I am delivery engineer, when I go to XX2 implementation deployed with YY2 version page, then go to ZZ2 page, then I will not see the button.
AC5 : Given I am delivery engineer, when I go to XX1 implementation deployed with YY1 version page, then go to ZZ3 page, then I will not see the button.
AC6 : Given I am delivery engineer, when I go to XX2 implementation deployed with YY2 version page, then go to ZZ3 page, then I will not see the button.

那個⋯⋯這還沒有說到click那粒button後會怎樣呢!

我simple的requirement你都懶得讀,看不到,你還認為這個錯誤是因為寫得不夠詳細?然後,做出這樣的要求?你是機器嗎?這根本原因是你們不認真工作、不看requirement、斷章取義、不做溝通!根本的問題不解決,卻把它推在別人的身上。你好意思!

超級不爽!這是agile嗎?這是所謂的減少花時間在做documentation的政策裡嗎?嗯,是的,只要minimal dev work就對了。我工作差不多十多二十年,第一次碰到給developer的工作得有這個minimal dev work的前提。

算了,推給PO,我只是給requirement,你們要咋地就咋地,要go die就go die吧!

下次說關於渣男的故事。他說證明我還有魅力是件好事,不過,被騷擾可不是件好事。我也不需要被證明或認可什麼的。

留言