開發流程

「請問你們的開發流程？部門是如何互相溝通？」

這件事就是在問敏捷開發與跨部門的協作，這個就可以問出「超級多」東西。

首先是關於 PM 部分：
是用什麼工具去管理專案？
PM 會交代要做的工作。（都不需要 Task board ?????）
現在那麼多專案管理軟體，jira, trello, clickup等等，不要再像原始人一樣用嘴巴派任務。

使用什麼工具來了解API 規格？
最雷的大概是「打了就知道」，那種憑感覺開發真的很糟糕⋯⋯最差最差也要有 swagger, postman json，但也沒有很理想就是了。
以我來說最理想要有文件，文件必須登載以下：URL, Method, Parameter, Response DTO Scheme, Error Type。最討厭看到貼了一個 Json example 跟我說這是他的 response ，連type, enum, 什麼都沒交代。

最後是QA：
用什麼去管理 Issues?
最少要有使用專案管理功能，最差用個 GitHub or Gitlab 的Issue board。通常 issue 卡片要交代 Bug ，通常要內容、圖片、復現步驟。絕對不是給你一份 Excel 跟你說這個是 Bug 清單。

一般溝通：
通常這一行主流還是依賴使用 slack 這類的團隊管理工具，對於各個平台的擴充性好，能串接 CI/CD, CLI 各類型問題的工具為首選。有的公司也會開發內部溝通軟體。但最糟糕的是用 Line 之類的，那種使用跟你生活綁在一起的軟體，只會讓你生活混亂。
其實從溝通工具就可以了解到團隊很多基本的狀況，如果連工具挑選都很隨便，代表專業度不足，很容易開發到變成隕石。

通常交付前我都要自己去跟前端對接，確認要用什麼方式做，他需要什麼樣的檔案，動效要mp4還是svg還是我直接寫成js給他
因為外行PM就是直接把檔案丟給RD說明一下就叫交付，交付他個圈圈叉叉腦子被夾

事的問題（hard skill）
« 該做什麼
« 何時完成
« 花費預算
« 其它如品質、風險、採購

人的問題（soft skill）
« 溝通
« 人力資源（團隊、領導與衝突管理）

遇到發布一個溪改規格 後來又說不要

As a user, I want a feature to select the ready-to-buy item so that I can see the selected item in my cart and speed up the purchase operation

這時 TL 或工程師可能就會開始問：

// 選擇行為是單選還是多選？
// 如果是多選，那要不要有全選功能？
// 使用者會不會需要有過濾選項再進行的需求？
// 使用者選完後商品但沒有進入下一頁時，行為要被記錄嗎？

理想上 PM 在進行產品規劃時，就會把使用邏輯盡可能事前補上，減少和工程師來回確認的時間，但這先經驗真的需要時間累積。

當作是 Acceptance Criteria 的依據

估點有三個向度的指標進行衡量：未知程度、費工程度、複雜程度，最後每個人要出一個值（費氏數列 1, 2, 3, 5, 8…），然後從差異最大的成員們提出為何點數估高、估低的原因，討論最後需要收斂到大家共識的點數，討論過程的目的有兩個：

讓任務明確，盡可能降低不確定性
讓所有人對技術的開發方向有共識

當然，估點是主觀的，又或者每個人心中的尺可能不同，所以針對未知程度、費工程度、複雜程度，可以請團隊成員一起出一份簡單的指示，例如 1 點代表：「沒有新邏輯、只需要加五行內的程式碼」。

下一步則是問，點數是相對的，要幹嘛用？一開始一個團隊在跑 sprint 時，根本不知道能消耗多少點數，但是跑過兩三個 sprint 後，大概會得到團隊能消耗的點數總量，這時候這個值就是團隊的生產速度 (velocity)，進一步用這個生產速度，回推一個產品可能開發所需的時間。舉例來說，某個團隊跑了三次的 sprint 得到的生產速度如下，大概可以估計一個 sprint 能完成的點數約莫 50 點：

感受不到到底大家到底做了多少事情, 感覺可以在 sprint 尾聲明確化這件事情
Retro

做得多的人大家其實也看不出來做得多
也難以評估團隊每個 sprint 可以消化多少點數來評估校個 sprint 的安排

專案的規劃與估時 那規劃專案本身這件事情是怎麼決定要討論多久的阿??
匹方說 PO 向 TTL 要求評估工時 TTL 有多少時間去思考時間、人力
完整模糊的需求 => 具體化、包含人力需求工時要達到的完整度之類的 中間可以有多少時間去做這件事情呢?

關於第一點新官上任，到目前為止的經驗是很簡單，但也需要練習，原則就是：真誠、承諾、尊重。因此，我第一件做的事，就是讓資訊透明，上層如果有什麼新的資訊，我盡可能不更改原意的分享，但有些可能不方便直接說明，就要適度的修改說法，避免不必要的衝突與對立。如果真誠坦白，久而久之大家都會對你感到信賴。至於承諾也很重要，當成員反映某些事情需要你的協助，只要有任何的答應，「好我幫你確認一下。」講出來就真的要做到，最好是連回覆時間都告知，讓大家知道你有心在處理大家的問題。最後是尊重，已所不欲勿施於人，有時候自己都怕的麻煩，就盡可能不要麻煩別人，如果真的要麻煩別人，也必須設法站在對方的立場，想盡辦法解決對方的麻煩，通常如果有一件很麻煩的事情是大家都不想做的話，一開始我會自己先做一些，或是跟大家討論「如果我執行 xxx ，其他人可以協助 yyy 嗎？」，”Get your hands dirty” 往往大家就會有行動力。

許多實踐敏捷開發的團隊經常落入「形式化」的陷阱。舉例來說，很多使用各類敏捷方法的團隊，經常有很多大大小小的會議。然而，敏捷背後的原則是要「經常交付可用的軟體」，如果長時間花在開會上，壓縮了能經常交付可用軟體的時間，就會變得與敏捷背後的原則牴觸。

又或者許多公司在導入流程與工具時，會很死地要求團隊必須要照著做，即使某些流程在落地後幾乎變得沒有意義，但仍是為了做而做。但敏捷宣言提到「個人與互動重於流程與工具 」。

但敏捷的核心是追求「滿足客戶需求」，是追求更頻繁的回饋迴圈 (feedback loop)，這能避免做出對使用無價值的成果。

使用者很多時候，其實沒辦法說清楚自己真正想要什麼。所以單純的前期使用者訪談，雖然能做為方向的指引，但很多時候不會是馬上就能精準抓對方向。因此更有效的方法，是根據需求做出原型，接著給使用者用用看，同時蒐集回饋來迭代。

系統架構：了解該公司的前端、後端、資料庫的運作方式，雖然不同公司大同小異，但初期可以先了解「哪種情境要找前端、哪種情境是後端資料問題」等基礎情境，方便未來遇到 bug 或要釐清時，可以更快找到問題源。
開發流程：了解工程團隊的上版 / 上線規律，像是固定哪天 Release、或 Code Review 流程、或上線流程，方便之後要提供專案時程時，可以依照團隊流程對外喊出真實且正確的時程。
功能限制：了解現有功能的限制和開發過程，像是現有的功能支援與不支援的情境，並理解過往開發遇到的效能、擴充性、邏輯卡控等技術考量，確保未來規劃新功能或舊功能迭代時，能更貼近功能現況。

扮演「需求過濾器」的角色。

使用者對原本操作流程哪邊不滿意？其他競品的類型情境怎麼處理？
使用者最終想獲得什麼結果 / 看到什麼畫面？
為什麼要現在做 / 不做會怎麼樣？
做此功能的效益是？影響多大？

驗收標準

明確標示各項需求的優先程度，以及它們之間的相互依賴關係，確保在時間有限的前提下，必要的功能能被先執行。

PO 的困境 並不適他們不想瞭解這些用詞或專業度不夠, 是因為當他們想確認時會被說你想跨越職責是不是? 然後繼續被新的需求追著跑…

讓人輪流當 Retro host

==> 至少要有一個人覺得這件事很重要 讓他帶動 比較不會流於形式

PO

釐清與傳達價值 幫助找到工作的意義

”不講人話“習慣提高了大家的學習門檻