最近 Rails 新的研討會 Rails World 的演講慢慢都上傳了，其中有一場是由 Shape up 作者 Ryan Singer 講的：Applying Shape Up in the Real World
短短不到半小時的內容，全部都講中我對 Shape up 的誤解，因此我想好好的記錄。
以下內容並沒有按他講的順序，是我自己排的。
短短不到半小時的內容，全部都講中我對 Shape up 的誤解，因此我想好好的記錄。
以下內容並沒有按他講的順序，是我自己排的。
一、SHAPING ASYNC?
「非同步討論」：這個釋疑被我擺在第一個，因為它描述到了我心中很多的困擾（並沒有解決，但把困擾的原因解釋的很好），而且我想會一直對我未來的職涯有幫助：
我舉兩個我們目前工作流程中遇到的例子：
a. 透過 GitHub PR 非同步 review；
b. 透過 To-do comments 非同步討論專案方向（注意是「方向」，也就是還很不確定的事情）、非同步討論設計專案。
首先，Ryan \不是在抱怨「非同步」讓我們每次都要等對方回覆等好～～～久/，所以叫我們不要非同步。
他在解釋的是每個人在 \回留言之前，並沒有足夠的時間進入狀況/，只是看到新留言就回覆。
因此整串 thread 中，\所有人能在極度專注的心態中互相討論/ 的時間是很少的。
那你可能想說：「有阿我都有認真回欸」
Ryan 是這樣描述這感覺的：
我舉兩個我們目前工作流程中遇到的例子：
a. 透過 GitHub PR 非同步 review；
b. 透過 To-do comments 非同步討論專案方向（注意是「方向」，也就是還很不確定的事情）、非同步討論設計專案。
首先，Ryan \不是在抱怨「非同步」讓我們每次都要等對方回覆等好～～～久/，所以叫我們不要非同步。
他在解釋的是每個人在 \回留言之前，並沒有足夠的時間進入狀況/，只是看到新留言就回覆。
因此整串 thread 中，\所有人能在極度專注的心態中互相討論/ 的時間是很少的。
那你可能想說：「有阿我都有認真回欸」
Ryan 是這樣描述這感覺的：
Everyone gives their comment and then we all walk away thinking I was right.
- Ryan Singer, Rails World 2023
二、真實世界的 Shaping 是什麼？
這很好理解，就是買房的取捨：
屋齡、格局、地點
這些都要根據你的預算去取捨
屋齡、格局、地點
這些都要根據你的預算去取捨
三、Shape up 講求完全自主，那成員都要夠資深吧？
投影片上兩條流程：
流程 1 指的是：成員先夠資深，才能讓他自主
流程 2 指的是：輸入好資訊，然後讓他自主，他就會學習如何自主（怎麼突然覺得聽起來像訓練 AI，看來人類真的是超級機器人）
流程 1 指的是：成員先夠資深，才能讓他自主
流程 2 指的是：輸入好資訊，然後讓他自主，他就會學習如何自主（怎麼突然覺得聽起來像訓練 AI，看來人類真的是超級機器人）
四、Shaping 需要技術人員
承接三，我應該要接著解釋怎麼提升輸入品質，但在那之前，先看一下技術人員在這當中的角色
Ryan 一樣舉了真實世界例子：
你想「在客廳牆上裝一盞燈」，因此你考慮的可能是燈多少錢、燈要買多大、燈要擺多高，甚至請室內設計師來設計了一番。
但如果沒有水電師傅來評估：
「你要裝的地方到底有沒有電？」
「如果沒有，拉電會很貴嗎？」
「已經有電，那使用上有沒有什麼限制？」（也許你要裝的不只是燈）
他也舉了程式開發的例子：
PM 想要跳過「一個步驟」，但看了程式之後發現那「一個步驟」其實是很多流程的交叉口，因此關係到很多流程。
Ryan 一樣舉了真實世界例子：
你想「在客廳牆上裝一盞燈」，因此你考慮的可能是燈多少錢、燈要買多大、燈要擺多高，甚至請室內設計師來設計了一番。
但如果沒有水電師傅來評估：
「你要裝的地方到底有沒有電？」
「如果沒有，拉電會很貴嗎？」
「已經有電，那使用上有沒有什麼限制？」（也許你要裝的不只是燈）
他也舉了程式開發的例子：
PM 想要跳過「一個步驟」，但看了程式之後發現那「一個步驟」其實是很多流程的交叉口，因此關係到很多流程。
五、提升輸入品質：Shaped work is BUILDABLE
在 Shape up 中提到可以把 shaped work 寫成一份 Pitch，我自己實際執行起來，雖然沒有到 All "why" and no "how" 那麼慘，但只是「一次把我想做的事情都寫下來」，太多太雜不夠精準（沒有聚焦在大家現在想解決的問題）。
Ryan 也有從 Pitch 去描述那些誤解：
寫好 pitch 我認為是最難的，因為這不只關係到前期的「要解決什麼問題」（"Framing" in his language），也關係到 shaped 後，是否有足夠能量去寫成 buildable。
Ryan 同時改良了一下原本 shape up 當中的 language：
Framing、Shaping、Package
（本來只有 Shaping、Pitch）
----------
總結
Ryan 這場演講的開頭是這樣的：
我們使用的 Rails，比起其他開發方式來說，更能 "看到" 每個需求的樣子。
其他開發方式也許需要跟隨 Scrum 建議去切分很多細的 tickets（即使本來的 pitch 已經很完善），因為不切分的話，程式端實在太難做。
我們應該更多去發揮 One person framework 的優勢。