敏捷開發vs瀑布開發->都幾勒？

凡是能夠讓團隊成員順利開發，知道任務的先後順序以及並行數量，就是一個很好的開發方式，我個人並不特別推崇敏捷開發，但是瀑布開發在這個瞬息萬變的市場並不是一個樂觀的選擇，除非它精確瞄準的市場是有一塊沒人敢/想碰的。

瀑布式開發

是比較常見的開發方式，先有「完整」的企劃，才去實行，這幾乎是所有產業在開發商品的流程，「市場測試」是放在最後面，同時也是消費者比較容易買單的模式，因為已經有了成品，然後看得到所有人的評價。

敏捷式開發

在軟體開發這一塊，是許多領導層口口聲聲想要執行，卻老是被吐槽「隕石開發」，原因是什麼呢？因為領導層其實自己並不清楚自己要開發什麼，不了解工程師可以並行開始的任務有哪些，所以才會嚷嚷著一定要有ＸＸＸ，才能做ＸＸＸ，可是對於部分任務而言，他的前後順序並沒有這麼強的連結。

舉例，網站是最容易執行敏捷開發的。

當一個網站的雛形架構出來之後，前端工程師就可以開始架構草圖，當UI/X設計搞出來後，開始與設計師討論修改，後端工程師可以根據這個網站的雛形去設計資料庫、演算法等等。

網站的雛形架構和 UI/X 設計師的確是最應該先跑的，所以在新創團隊上，前端和後端要做的就是設置建構環境、精進自己的技術。

因為是敏捷設計，所以當網站的基本功能出來後，就應該要盡快丟到市場試水溫，後續的功能慢慢完成，可以依據使用者回饋去調整或是增減功能。

放在遊戲裡，大概就是手機遊戲能這樣做，因此這一篇放在 React 網站開發之中。

在ＳＣＲＵＭ敏捷實戰手冊明確指出了：

實際運作的軟體 比 包山包海的說明文件 重要

個人與互動 比 流程與工具 重要

意即在開發的過程中，尊重必且獲取每一個成員的建議是很重要的，敏捷開發的成員不應該過多，也不應該低於3人，一個專案負責人＋一個美術設計＋一個工程師＝一個軟體商品，如果今天美術設計或是工程師兼任專案負責人，那麼商品就必須小，並且評估開發時間並且掌握。

在軟體商品來看，不是只有開發，所有跟美術和coding 無關緊要的事情都應該由專案負責人酌情接手，例如：文件、客戶、行銷，身為一個初創團隊，如果隊友是合夥，那麼就需要與成員溝通並取得共識，如果隊友是發包來的，那就尊重他的知識、情報與技術，並且時時檢測他的作品是否和預期相同。

在敏捷開發的規劃前期，或者說整段開發過程可能都一直在調整企劃，有一個是需要專案負責人時時刻刻提醒自己：

越小的目標，越能夠更快實現，越能夠更快完成，就能夠越快丟到市場裡面。

換句話說，如果要實現某個較大的功能，就需要更多時間，因此借助工程師的能力去判斷到底該在前期實現還是後期實現，那就是團隊要考量的事情，尤其現今寫程式的門檻越來越低，我們將會迎來人人都能寫程式的時代，至少在你我的有生之年，是有機會看到的。

對於一個網頁，或是一款手機程式，我並不認為所有功能都要齊全才能上線（瀑布式開發），核心功能已完善時，就可以丟出來了。

難道 Threads 不就是這樣嗎？應該沒有人會覺得它現在的功能就長現在這樣吧？

Threads 的核心功能是擁有跟 Twitter/微博 相似的短文貼文，這是臉書和ＩＧ沒有的，他如果要吃下 Twitter 的市場，就必須截長補短，推出一個很相似但是又有不同機制的社群媒體。

沒錯，你沒聽錯， Twitter 活了這麼久，依然是歐美是不死的存在，即使臉書普及率這麼高，Twitter 的使用率依然不減，彷彿就是洗碗精和洗衣精，各自有自己的市場互不干擾。

參考資料：