碼農的敏捷開發經驗

近幾年軟體業界對於敏捷開發 (Agile) 是蠻推崇的，因此大概從碼農我的第二份工作開始，幾乎都是走這樣的方式。

不過即使都叫做 Agile，各公司執行的方式似乎也都不太一樣。在 D 公司的時候，公司的一個開發週期是一個月，但在 R 公司的時候，一個週期則是兩週。不過基本上在我經歷的敏捷開發文化裡面，都還是有以下的幾個特徵。

開發流程 Development Process

需求 Requirement

這是最重要的一環，如果需求不清楚的話，也真的不知道要做什麼產品。因此，最好在這時候要有所謂的目標客戶，讓他們確定產品的方向跟用途，這樣才不會讓開發出來的東西不符合他們的期待。

不過也不用期待他們一次把所有的產品方向制定完成，因為這就又回到以往瀑布式開發的舊觀念思維。反而是讓他們把他們想要解決的問題拋出來，讓我們站在他們的立場，從他們想要解決的問題著手，開始跟他們一起討論，一起參與產品的制定。這樣是更有效的。

另外，通常在這階段，設計師(Designer)與系統分析師(System Analyst)也會間接參與，一起把使用者故事(User Story)撰寫出來，好估計整個專案的時程。

設計 Design

當客戶一起參與了你的產品，這時候就會開始衍生出各種設計的問題。界面的設計、用途的設計、使用體驗的設計，技術面的設計。粗略會分成以下兩種設計。

使用界面 / 使用體驗設計 UI/UX Design

產品要做出來，在需求大致確定之後，就會開始著手外觀的設計、使用體驗的設計。這時候設計師會更多跟客戶溝通，討論明確的需求。系統分析師也會開始看著界面的設計，構想大概有哪些技術面的需求，把這些需求轉化成後面技術設計的要點。

技術設計 Technical Design

在界面逐漸確定的同時，技術方面的分析也要進場，開始把一個一個的功能需求丟出來。這時候，系統架構師(System Architect)也要參與技術設計的討論，確保將來實做這些功能的時候，不會打壞原本的系統架構。把所有將來程式要實做的內容，撰寫成一份份的規格(Design Spec)，讓接下來的開發時程，可以直接照著文件開發即可。

開發 Implementation

開發的時間就是寫程式的時間了。如果時間安排得宜的話，在上一個設計的階段，有經驗的工程師可能就會先做前期的驗證。對於沒有做過的東西、沒有用過的語言，會先預留一些時間做研究，好讓開發的這段期間可以更順利。

好的工程師對設計模式也是信手拈來，所以在設計上會做得很有結構。就好像看一個文筆流暢的人寫作，看到很棒的程式碼的時候，也會讓人讚嘆連連。

通常單元測試也會安排在這時間，讓整個程式更有保障，在前期提早發現問題，可以加快之後測試驗證往返的時間。撰寫功能、熟用設計模式、單元測試，這些都會是開發這階段要做的工作。

測試 Test

測試是為了確保產品的品質，因此好的產品絕對少不了測試，好的公司也會重視測試。

在軟體工作上，有手動的測試與自動的測試。手動有手動的價值，自動有自動的優勢。手動包括需要用肉眼判斷的檢查與測試，有些外觀的美醜、用色的好看與否，都需要手動、人工的檢查。

自動則是能加快測試的步驟與流程。測試工程師事先撰寫好測試的程式碼，在軟體工程師寫完程式送出的那一剎那，就可以觸發測試的程式碼，讓開發與測試能夠緊密結合，加快開發的流程。

因此，手動測試與自動測試兩者要能取得平衡，幫助產品能保有良好的品質。

佈署 Deployment

當你的程式都開發完畢、測試也都過關，表示你的產品已經有一定的水準，也夠穩定了。那麼，是時候可以發布你的產品了。這時候就是佈署。發布產品需要哪些檔案，要有哪些步驟要執行，這些就是佈署時候要做的事情。

如果是單機產品，就是各地下載，比較會遇到版本管理的問題。如果是伺服器端的服務，那麼只要你的主機更新了，大家連上你的服務時就會是更新的版本。

而如果你產品的服務夠大，需要發布到多台主機上的話，佈署也會是個重要的課題。如何在短暫的時間內大量批次佈署到多台機器上，這是最近很夯的話題，也造就了這個很夯的職缺 DevOps，這角色需要熟悉開發(Development)與維運(Operation)。

自動化 Automation

除了前期的設計與開發，後面的測試、佈署，都有自動化的可能。於是乎，自動化的課題就因應而生。因此，近年來這兩個名詞逐漸在業界慢慢熱門了起來。

持續整合 Continuous Integration

為了加快開發的流程，在開發的階段，如果使用持續整合，就可以達到接近平行的開發速度。只要誰有進程式碼，機器可以立刻編譯，其他人就可以馬上看到結果，並且繼續他手上的工作。這樣的開發流程，比起寫完還要上傳 FTP 或是郵寄程式碼給同事，會快上很多很多。

測試人員的程式碼也可以排入這整合之中，只要進程式碼，就可以立刻編譯，然後透過測試的程式碼檢查程式好壞，若是程式有問題，開發人員可以收到通知，更快修正程式的錯誤。因此，如果能導入持續整合的自動化，公司的產能可以大大提升。

持續佈署 Continuous Delivery

佈署有時涉及各個面向，除了程式的更新，有時候資料面也需要更新，因此如果一切都是人工手動的話，還是有出錯的可能，並且速度也會比較慢。因此如果能寫成 Scripts，導入持續佈署的話，會更有效率，並且可以在事前先驗證，檢查錯誤並解決。

特別對於多台機器的佈署，自動化的持續佈署是非常有幫助的，如果你的服務規模夠大，導入佈署的自動化，這是非常有幫助的。

小結

總結來說，我覺得敏捷開發不僅僅是一個流程，更是一種文化。因為要讓團隊中所有人都參與這樣的制度，首要的應該是大家都參與並認同這樣的文化，不然最終只會被團隊所拋棄。因此，在施行之前，一定要有充分的溝通與討論，找到一個適合團隊的方式，而不是硬要兜什麼方法，為了施行而施行，有時候是更勞民傷財、折損士氣的。

那麼，希望大家都能在自己的團隊中找到最合適的運作方式嚕！

​