最近陸陸續續的花了一些時間導入專案軟體開發工具跟流程進到現在的公司中，我想就藉由這次的機會來描述我想像中一個軟體專案應該要有的體制。當然，這些都是基於我過去在其他公司參與遊戲開發專案所得出的結論，或許很多並不是最佳解，但我想裡面應該有一些可以參考的觀點。
基本上，我所認為一個好的軟體專案開發體制需要能解決以下這三個主要的問題：
一、工作要能夠連續，不要輕易的被打斷：尤其是當一個人才剛進入工作的狀態卻被其他的臨時事項或溝通所打斷時，要再重新進入原本的任務內容所耗費的時間與心神勞力在無形之中都是個浪費。
二、任務內容要能夠有效傳達：由於軟體開發在本質上複雜與不可見的特性，很多時候口頭上所討論的內容每個人所理解的都不盡相同。又尤其開發過程中肯定會有不少任務內容展開，而開發人員肯定是一件一件的對於這些任務進行消化。而在這期間，軟體需求的各種修改與追加其實會是一種常態，特別是對於新創公司而言，要如何讓這些任務內容有效的傳達到所有相關的參與者身上，而不是藉由開會來佔用人員寶貴的開發時間，則是一件軟體專案管理上必須要思考的議題。
三、軟體設計過程要能夠追蹤：軟體開發不同於其他產業，它很難用任何量化的指標去評估。公司的價值基本上就是圍繞在裡面成員的技能與組成，因此，要如何將開發經驗傳承下去則是每個軟體公司都會面臨到的挑戰。這點在程式人員中通常都是使用版本控制軟體(如Git)，但只有這個是遠遠不夠的。程式碼無法體現想要達成的使用者經驗以及其他各種功能面上的決策與情境，因此如何為這些東西提供一個互相參照的機制，則會直接影響到公司的體質。體質好的公司，這些開發經驗是要能有系統的累積下來的。人員若能夠藉由這個機制而能簡單且快速的存取到跟手邊任務相關的資訊，則能夠大大的提升軟體開發與維護的效率。
其實，上面這些問題在本質上都是怎麼「溝通」。要怎麼讓這件事更有效率的被執行，其實在軟體界中有一門叫「軟體工程」的理論專門在探討相關專案管理的開發議題，從各種從上千人參與的軟體開發專案到十人以下的小團隊都有提出一些方法論來解決各種軟體開發上所會面臨到的情境。其中一套被稱作agile的方法論普遍被世界上各個開發團隊所採用，其核心思想便是藉由每天不斷的溝通、頻繁的交付版本來快速的適應需求的變化。
然而，溝通是有成本的，因為溝通需求而被中斷的開發時間意味著時間的浪費。因此在agile中的 「scrum」框架下才會有每天的站立會議的出現。藉由每天在進入工作之前跟成員間互相分享彼此在任務上的狀況與需要協助的地方，以解決當面互相溝通的需求。
當然，就如同人月神話一書中所提到：「沒有銀彈」──軟體開發並沒有一套完美的方法論可以完美的套用。各個軟體專案管理必須要根據人員的組成與專案的特質進行不同的管理流程，一切都要以如何進行有效與簡潔的溝通為基礎來進行發展。
基於上面的需求，市面上其實也已經有幾套專案軟體系統可以用來協助我們減輕成員間溝通的負擔。
其中最有名的是jira( https://www.atlassian.com/software/jira )，它是目前公認做的最好的專案軟體管理工具，只是如果要完整的使用該公司的方案的話，在價格上會有些昂貴。
再來就是redmine( http://www.redmine.org/ )，由於這套解決方案是免費的，因此在市場上佔有不小的份量。只不過我個人用過的感覺是缺乏了不少關鍵性的整合能力，而且server必須要自己架設，適合有專門資訊人員在管理的團隊。
接下來便是微軟的vsts( https://www.visualstudio.com/team-services/ )，由於其完整度還蠻高的，各種整合跟服務都很不錯，而且5人以下免費，git跟git lfs的空間無上限，因此作為startup使用的專案軟體管理工具是蠻適合的。
另外也有不少小團隊採用Trello( https://trello.com/ )，只是我覺得這套系統作為個人使用的任務管理工具雖然還蠻完美的，但當團隊成員擴張到5個人以上的時候就會開始顯得有些零亂，到10個人以上時基本上就會呈現一種無法管理的狀態。
當然，除了使用專案管理系統之外，還是會有即時溝通的需求。基本上，市面上的專案管理系統會在每天匯整當天的任務資訊並寄到你的email，但若我們在專案管理上的任何更動或任務的指派都能夠即時通知到相關人員的話，那麼團隊就能夠更敏捷的去處理各種突發狀況。
通常大部份的人想到的都會是建立一個line或Skype群組並手動的通知對方相關的任務變更，但「手動」這件事其實是一件勞心勞力的事，若能夠自動化的話該有多好？而且建立line或skype群組意味著公司需要再去尋問員工私下個人的帳號資訊，這對於一些重要資訊的控管與流程的制度化其實是不好的。
這就是為何市面上會有slack、hipchat或microsoft teams……這些群組聊天軟體出現，它們不僅僅跟專案軟體系統有一些自動化機制上的整合，更重要的是如果這們軟體是直接跟公司的email帳號綁在一起，就能夠讓員工們做到公私分離，在公事上分享相關機密資訊時就不會有太多的疑慮。
最後，根據agile的精神，我們必須要頻繁的交付版本以達到快速適合需求變更。但交付版本這件事其實是一件勞心勞力的事，若是每幾天都要繳交一個版本的話，那麼就會必須要配置一個工程師整天都在做這件事。這其實也是一種浪費，若是這件事也能夠自動化的話該有多好？
其實所謂的持續集成(Continuous Integration)就是在處理這件事。基本上要做的事情就是一套自動化建置與佈署的流程，撰寫自動化的測試程式以確保基本的軟體質量，並在每天晚上自動執行這些自動化出版的腳本。其中這套持續集成系統最有名的是jenkins( https://jenkins.io/ )。這套流程雖然一開始的建置需要花費一些時間，但是當整個機制完成之後，團隊成員每天能夠拿到一個最新的版本以檢視其前一天的工作成果，而且最大的好處是能夠讓各種潛在的議題在軟體實作的初期就浮現出來。一個好的CI流程能夠體現軟體專案的心跳聲，若是我們能夠越早傾聽出專案中各種潛在的病症，那麼便能讓我們後期專案的開發與維護成本降至最低。
Leave a Reply