最近，其實過得不是很好。可能有點憂鬱，有點躁鬱。對很多事情，都很沒耐心。有種總人皆醉我獨醒的感覺。
我想忍聲吞氣的，不過已經睡不好很多天了。每晚回家後都在想怎麼應付明天而輾轉難眠。無法控制情緒已經讓我更加不安了。我決定做自己的抒發。
做人嘛，催眠自己，讓自己過得好，應該是常情。不過，以推卸責任，然後催眠自己做得好，你腦子才有病吧？！怎麼變成是我病了？這就是“合群”效應。當大部份人都催眠自己，這個錯誤是他人的，因此，那個“他人”要改善。
我從事電腦、雲端相關的工作。去年年底，我兼做了用著的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吧！
下次說關於渣男的故事。他說證明我還有魅力是件好事，不過，被騷擾可不是件好事。我也不需要被證明或認可什麼的。
