第 2 件事：application deployable from day 1
在進入開發階段後，我會做的第一件事： ** make application deployable**
也就是：專案開始第一天，就必須要有個 production 直接可運行（可以鎖密碼，當作測試 server）才行。（我在 Rails 101 這本書最後一章，加入 capistano 與裝機為必練技能，就是這個緣故。）
為什麼專案需要 deployable？
提前控制風險：開發環境與線上環境的不同
在一般的經驗中，往往在在專案進行到尾聲快上線之時，才會注意到一個可能使專案時程大爆炸的事情：** 開發端與線上端的環境通通不一樣 **。
在開發過程中，所有人只專注在自己的機器上能不能動，這是常態。專注在實現功能，東西有缺就先在 local 上塞假資料。在最短時間內將 feature 盡可能寫完絕對是第一要務。
但很可惜的，寫完並 不等於 放到正式環境上可以動。
網站上其實非常多功能需要實際被「真人」測試，才會知道到底有沒有問題。有一些設定，甚至開發環境與上線完完全全不一樣。（以 Rails 來說，其實就差很多。比如說程式 class 會不會被 cache，asset 有沒有 optimize，上傳路徑以及與第三方接軌的設定等等...）
如果拖到最後一個月才作 deploy 的這件事，因為「到底有多少東西不一樣」，變成了一個完全的未知數。原本夠用的一個月測試期，被這樣一壓縮可能完完全全就不夠用了。而且因為專案截止日已進，隨之而來的壓力更加大了犯錯的可能性。
一個透明的已知進度
Day1 就有一個可以直接實際測試的站台，還有一個很大的好處，能夠確保專案中所有人都知道現在進度，與規格書上的東西到底差多少。如果有重大瑕疵，或者是絕對不可行的功能，就可以早早會提出修改，下架等等。節省大家寶貴的開發精力。
如果專案截止日最後十五天，大家才知道很多東西原來根本是作不出來的，或者是跟原本想像差太多的，這時候鐵定陷入交相指責，一遍慌亂的狀況。
絕對注意：捍衛進度
不過這一招的使用，專案經理或者是 RD 主管要特別注意。因為 Day 1 就有一個直接可以看的站台，不少完全不懂「技術」的專案參與者（通常是企劃或老闆），會對網站的「裸站」狀態感到極度的恐慌，他們會挑剔 UI，會不滿 implement 細節，進而想要實際插手進度修改內容。請務必堅持住，堅持到進入最後一個階段：測試修飾期才可以讓他們修改（通常進入準完工階段，裸站狀態其實也消失了，當初挑剔的東西幾乎在這個階段不復存在，故也沒有修改的必要。）
P.S. 可以架設一個 issue tracking system，把他們提出的修改事項先通通記起來，但通通不實作。等到接近測試期，再來看看這些當初的「建議」到底還有哪些實際需要被執行。
只有「完全不合實際應用」的東西，或者是「變更會讓實作方式更合理」的東西可以在整個開發期，被丟入排程中。
否則，他們的驚慌，會害這個專案完全結不了案。
＝＝＝＝
系列文章：