關於 waterfall agile比較 ，我們在網路上蒐集到這些相關的討論、資訊與評價

Scrum 少了哪一味?

Agile 一開始的時候, 是希望兼顧 商業價值 和 軟體品質的
它希望能快速反應外界的變化, 了解 PM 或客戶的考量為何
並且也讓開發者本身對於工程技藝能夠重視, 並且有效的落實.
至少這是 Kent Beck 一開始的想法.

後來 Ken Schwaber 說我們要來搞個 Scrum 認證
沒錯, 認證這件事情確實讓 Agile 發揚光大
不在只是一小撮人自己在爽

但是, 是誰來參加 Scrum 認證呢?
大多是 manager, 是管理階層或非技術人員
開發人員反而沒有那麼多.
當初想要兼顧 商業價值 和 軟體品質的夢
似乎沒有實踐

所以 Scrum 少了什麼?
沒有了品質, Scrum 是無法加速的
沒有技術品質, Scrum 只會越跑越慢
你無法在有技術債的狀況下, 還能跑得很快
並且在越多技術債的狀況下, 你只會越跑越慢
這是一個加速的負循環, 讓你的專案越來越慘

對於軟體開發團隊
你不能導入 Scrum, 卻沒有任何工程實踐
你必須重視工程實踐, 才能確保你高速前進
這可能也是後來會有 持續交付 或者 DevOps 興起 的原因之一

另外, 對於非軟體開發團隊
你的領域中的工程實踐是什麼呢?
你不可能只有敏捷思維, 或者 Scrum 的迭代, 就會比較快
你沒有找出你領域中的工程實踐
那你領域中的技術債就會拖垮你

所以提倡 Agile HR, Agile Marketing, Agile Enterprise 的朋友們
你有找到你領域中的工程實踐了嗎?
還是你認為只要有 agile mindset 就可以比較快了?

至於純管理領域的朋友們
不要認為只有 Scrum 就可以
不要忽略了技術債所帶來的影響
否則可能你的結論就是會 waterfall 比較好
反而讓你們更堅定了 瀑布式 的決心了

參考來源: https://www.youtube.com/watch?v=hG4LH6P8Syk

《小吃貨的英國日常》軟體工程師到底在做什麼？

很多人常會想像軟體工程師就是，在電腦前做一些什麼，然後進階一點可能會覺得就是在寫程式，偶爾聽到他們說什麼Debug, 這也是我在成為工程師前，對工程師工作日常的想像。

實際上，其實軟體工程師也分很多種，例如Web類還有分前端後端全端，手機類，還有像桌上型程式，其他也有像測試工程師，遊戲工程師，網路安全工程師，架構工程師，每一種工程師都不見得知道其他種的日常，甚至不同公司，不同產業使用不同的開發模式，像waterfall, agile, 有沒有CI/CD,DevOps,雲端，版控都差很多……

至於我到底在幹嘛……目前邁入工作的第二年，相較於第一年的菜鳥訓練生生活真的差很多，大概就是漸漸步入軌道，越來越接近一般工程師的生活。由於我們team是走DevOps, CI/CD,Agile, 基本上每天早上都要開會scrum，每個星期一有weekly planning, 要plan task。那開會在幹嘛呢？就是要報告自己昨天做了什麼？任何瓶頸?今天要做什麼? 這樣有問題可以馬上和team討論，team member 也才會知道你在幹嘛。每個禮拜一除了會run一次scrum 還會把一些任何做plan, 就是討論這個任務在做啥，怎樣task break down, 這個很重要，因為task 的size也很重要，要分幾個sub task, 要做什麼，誰要做，有任何問題? 需要再跟設計師討論? 當然因為DevOps, 我們所有meeting 設計師跟測試還有PM都會在，更方便討論。其他時候我們就自己認領task去做，做完丟給team leader review, code review 完才去測試工程師那， 然後才deploy, 所有流程都在Jira Kanban 版上，所有做了多少時間都要log work, 供PM看Team Leader 掌握進度。我目前是fullstack 全端，所以前後端都要學， 而學習主要還是自學。和其他工作很不一樣的是，工程師大多要自學，自己找資源，看影片，看文件，所以比較痛苦的大概是英文閱讀，另外是溝通，因為要一直開會，一直討論，還有要跟設計師，測試討論，這大概是因為DevOps, 所以更會這樣。這一年來我英文閱讀跟口說進步神速，而真正coding 反而沒那麼多，更多是在做AWS, 寫script, 雖然寫script 人家也會說寫程式，可是現在更像是了解computer science, 要知道很多系統，很多規格，很多Design Pattern 的東西，而前端框架也是，更多是怎樣設計，演算法別人都包好了，後端也是框架都包好了，一來不容易出錯，二來容易測試，反而跟以前所想像的工程師工作或在學校學的差很多。在工作上更重要的是Software Engineering, 怎樣寫出clean， high availability, testable， readable 的code比你想出很聰明的方法更重要。有時很efficient 的function, 可能很難測試，可能有漏洞，可能很難相容。

不知道大家會不會覺得工程師的日常好像很無聊呢～哈哈！至於工作環境，英國和台灣一樣，女生工程師很少，所以大部份的同事男生，大家可能會幻想那，英國的男生對女生都很紳士什麼的。在我公司一點也不會，反而會覺得男生工程師都講話更Aggresive,當他們覺得就是這樣，就很難改變他們意見，有時候他們講話也沒在客氣，質疑你的想法，批判你的想法都很直接。但也因為這樣，有時候一群男性工程師更容易做出太果斷的決定，通常他們就只有Yes 或No居多，所以工作環境的diversity 也很重要。當然另外，普遍男工程師也比女工程師更有自信（網路上有研究數據），可能是環境的關係，所以就更容易做出偏頗的決定，而且因為團隊中可能只有一個工程師是女生，有時也很難真的有diversity 的效果……而且當團隊80%都持意見A時，往往就不會考慮到剩下的20%，即使那可能是軟體開發很重要的一環。可能也是因為我英文不夠好又是外國人，又是團隊中唯一的女工程師，就也常常不知道何時可以發表意見或害怕講話，怕講錯話，而且英文也很難完整表達，這大概也是未來需要努力的部份吧～另外就是看文件的速度還有思考邏輯。每次我如果描述一個問題，我主管都會說，這不是工程師用語，你要用工程師的用語，像defect, tech debt, 或者不能說I don't know, 當你不知道的時候就要馬上找到原因，而不是問人，你即使問人也要說你覺得可能的問題或原因。

#覺得當工程師好難
#一有空檔就到廚房偷懶

上完課有個恐怖的傳說....

如果非得替這個傳說加上一個 timebox, 我會說是....六個月。

---
守破離、以終為始、定義好自己的TA、切細切細切細，可以降低風險、加速調整、增加生存機會。

週一到週三參加了三天的CSPO(Certificated Scrum Product Owner)課程，到現在總算可以沈澱一下來記錄一下感想。

雖然說三天的課程很像很長，必且灌入了很多的知識，但是脈絡清晰。課程概觀是這樣，產品發展分為探索(discovery)跟交付(delivery)，而這門課主要重點都在教怎麼探索。

探索的過程就是從
1. 做夢。找出你想做的..
2. 商業目標的迭代，可能從早期的試錯學習，到中期的從中獲取利益，到晚期的守成或是停止等等。
3. 每個迭代找到每個目標的關鍵角色
4. 這些關鍵角色可以為他解決什麼問題? 而對這個問題有哪些假設，並且試著證偽。如果假設沒有辦法推翻，證明是個問題，那就試著去解決它，這就接到後面的交付的部份，後面會補充。

而有了商品要怎麼行銷它?
1. 先期使用者跟他貼身肉搏
2. 中期使用者的營銷策略
3. 晚期使用者透過社會壓力而不得不用你的產品 (我都被迫安裝Line跟微信der)

至於交付的部份，就是我們常認知的Scrum PO要做的那些部分。例如如何做User Story Mapping，如何切近光燈遠光燈，好的Backlog應該有哪些味道等等的。不過也有些從Daniel的觀點看到對Scrum PO有一些不一樣的闡述。例如PO不用寫Acceptance Criteria而由dev team寫，過期的Backlog item其實可以扔了。這些請大家爭酌使用 XDDD

所以上述的課程三大塊要怎麼看
"探索"所描述的做產品部份是1，行銷是0。做對產品有了1後，才可以用其他的行銷補上0。這樣才會是1000000...，不然就只是000000，那還是0啊。那什麼樣的產品才是好產品，那就是要Remarkable，或說是個"紫牛"。因為工業時代的產品是大眾商品，追求的是大量標準化便宜品質好的產品。所以做這條路的產品永遠只會有人比你更好。而現在是連結經濟(connected economy)，我們可以輕易地透過互聯網找到你的終端客戶並且跟他貼身肉搏，所以你應該做出一個像是"紫牛"這種讓人關注的產品，在一個niche的地方找到空間。你做不了京東，但是你可以專門賣鋼賣銀的京東。找出一個狹窄的空間把它做到最好，這是目前比較可行的機會。而如果說產品跟行銷是戰略的話，那交付就更像是戰術。找到方向後，但要做到產出最小化(小到只剩內褲)，結果最大化($$或是學習)，以及影響最大化。有點像是我們所說的MVP。

這些大概就是課程的內容，來講講自己的體悟。

我喜歡做事的人，而且是從行動的經驗來表達理念是我最佩服的，而這堂課的講師Daniel就是這樣的講師。這次三天的CSPO課程最吸引我的不是那些方法論，而是方法背後的理論實踐。例如講到Odd-e在每年辦的AHA大匯用的那些出不著痕跡但出神入化的行銷技法，講到Odd-e的團隊如何共同運作來開發新事業，講到如何用訓練課程來建立connection，以及如何在平日生活中做到探索與試錯。如果說理論信條的闡述顯得虛無縹緲，而實際的實踐則可以深深讓下信服。從他的理念 Show don't tell，用行動來傳遞理念比那些說了一堆方法或爭論那些教條更有感染力。

而我第一天有個疑惑。第一天Daniel說了一堆反agile，反scrum的說詞，他是不是覺得敏捷不對了? 帶著滿滿的疑問第二天跟Daniel討論後，他說了Scrum不是最後，但是是不錯的開始。我還有一點搞不太懂，好像懂了，但是還是有點錯亂。但是最後比較想通了，那就是"守破離"。Scrum是一個Best practice，對於初次接觸照著做不會錯太多。但是best practice是一個很可怕的字，因為總是有不適合所有團隊的process，如果只固守那些教條，那跟嘲笑waterfall的人有什麼不一樣? 你又怎麼知道你的團隊適合scrum? agile的核心精神就是不停的迭代，fail fast，並且自省。所以不停的迭代一定可以找到團隊最適合的運作流程。但是你還是需要一個起點"守"，在不斷迭代的"破"，等到有了更高的啟發後，此時就是無招勝有招，那就是"離"了。而Daniel就是那個"離人"，而我還是那個"小白"。

另外第一天的有一個觀點讓我印象深刻，公司最外層是process/tool，中間一點是組織/架構，核心的是文化。說文化太虛幻，而組織如果是傳統組織的話，要走敏捷轉型通常都很難轉得動。我們的組織都是在一個工廠模式的組織，也就是階層式的管理架構，基本上"管理者"就是一個工廠思維的產物。當然一定有好的管理者，但是這種從上到下的組織，就是扼殺創意的結果，個人都可能因為social loafing而讓產值大幅下降。而敏捷組織更是扁平，甚至可能沒有管理者，每個都像是阿米巴原蟲一樣可以自理，迭代，端對端。Odd-e他們公司就是這樣搞的，沒有support部門，每個人都是可以搞定所有一切。所以我一開始接觸到Scrum第一個問題就是那Manager在哪? 這就是一個從傳統組織思維過來的問題。有這個體悟我就下了一個結論，敏捷組織無法徹底地從傳統轉型的，有太多既得利益者或是僵化性。但是另一個體悟是，個人，團隊，公司本來就是各自迭代。如果你想要改變，要發於自我，不要埋怨資源少，不要覺得自己沒有權力做。show don't tell，做出成績了人家管你敏不敏捷，成績就是王道。當然同樣的，公司的目的就是$$$，所以真的公司好好的，不要想不開去搞敏捷轉型，敏捷只是一個方法，不要把它當作是目的。

在課程最後每個人發表自己的感想。我的感想是"原本是打算來開腦的，但是感覺是被砍腦的。想太多說太多無意，重點是要用身體學習，不斷的迭代試錯，然後多丟丟骰子，多發現新事物，也許有不錯的豔遇" 也分享給各位。

也感謝 Richard Hsiao的推坑及 TenMax AD Tech Lab 的補助，當然還有感謝 Daniel Teng 真的超多啟發的，真心感謝。

Pop

#成年人
#抱大腿
#不要臉
#SmallIsTheNewBig
#ShowDontTell