大概說明一下簡報的內容：
也就是說，我配合很多工讀生執行這些工作。工讀生素質不一程度有差異，且都是學生，人員組成有太高的風險存在。學校並不會教寫程式的時候要版本控管因為能寫出來就偷笑了，通常平時能夠使用 WAMP 懶人包架設網站已經是萬分幸運了。比較糟糕的是拿 WAMP 直接上線當網站。要求到使用 LAMP 方式開發並且遵循版本控管及軟體專案管理的流程，並請使用某種特性流程的開發方式，如果沒有經過一番的訓練是有難度的。
開發的環境程式為 PHP ＋ HTML + Jacascripts 的程式，後端是 MySQL、PostgreSQL及 Oracle 等資料庫，通常系統端只有我自己維護且再程式部份有範例程式碼提供撰寫的範例。
需求通常來自於我的上級長官，再經由我確認後交派給工讀生開發或是自行開發，但是長官的高深莫測需求漂移不定是最大的困擾。即使本人多方進行需求分析了解也有時會有方向錯誤的狀況發生......
通常交派工作後會遇到的情境狀況1，使用者聽到需求後馬上使用他的 WAMP 懶人包開發程式，工具使用 Dreamweaver or Notepad++ 工具，配合 filezilla 等 FTP 上下傳程式。然後直接觀看網站的結果與輸出，執行測試。測試正確 Testing == Release ，馬上即時成為釋出的版本。
這問題很大，通常這個過程沒有明確的將需求紀錄由可能造成傳遞上的錯誤，並且沒將需求分段設定里程碑來驗證，開發人員寫完後，也沒有管道可以不同部的回報。如果遇到需求變動，這就更麻煩了....
情境狀況2，再內部我架設了一個 bug tracker (PHP、全中文 and GPL)傳遞管控開發工作的訊息，可以控管每件事情包含平時的工作、軟體開發的工作、網路維護工作，用來追蹤工作是否有完成。這軟體很好用，我第一次遇到和它一樣的類似的是 http://www.fogcreek.com/fogbugz/ forbugz 這套，這作者就是有名的作家「 Joel on Software 周思博趣談軟體」作者自行創業的公司開發的軟體，可惜它要錢否則是很棒的軟體。
如果遇到多個開發者，開發者可以觀看 bug tracker 知道目前的進度。但是仍有 FTP 版本覆蓋的問題，沒版法徹底解決.....
所以問題就是開發者沒有版本控管不知道協同開發者改了什麼東西，以前的開發者幹了什麼事。原始的需求不斷變動沒有紀錄，版本即使有差異也很難比較差異。版本控管早期就是用 copy and paste 問題會越來越多檔案，不知名的檔案。
人員如果流動，一個專案又重新開始說明。延遲的專案加入一個人之後會更加延遲..(人月神話) 。管理者更慘，根本不知道程式寫到哪了，程式碼寫的有沒有問題。 code style 有沒有遵循也不知道。
所以我打算用版本控管程式碼， WIKI 控管文件，bug tracker 控管追蹤專案。並調整規範開發的流程及方式，要求所有開發者確實遵循開發規範。
所以上面的圖加上了 SVN 機制，及 RedMine 軟體專案管理平台。
再人員的角色上，專案經理也就是我本人。採用人月神話中的外科手術醫生團隊開發模式，由我主導負責整個專案的進行，分工後採用專案控管的方式追蹤稽核。
開發人員則是由比較有經驗的資深工讀生，經過訓練後讓它可以自己 commit、測試 及 Deploy 程式碼到 Release 的平台。
報告人員大多為生手或是搞不清楚狀況的使用者，讓它只做報告人員報告問題即可。不用做太多以免發生風險。
所以根據上面流程圖及角色，列出了開發需要執行的流程方式。但是這個流程其實在某些例子下，是可以稍微簡化的。例如：同時間只有一人開發的時候(也就是我摸著鼻子默默的把程式寫完的時候)
因為工讀生的工作時間長短不一定，品質不一定。長官的需求也常常不一定。所以採用類似螺旋模型的方式，讓每次開發都是小循環，每次都經歷全部的開發流程，降低風險。
至於專案平台選擇的考量，有打算採用 TRAC or RedMine 之類的整合型平台。雲端上也有 github or googlecode 等平台，但是它門 public code 才可以免費用，所以摸摸鼻子自己維護了。
這兩套是用了一陣子發現 Redmine 的界面、中文、控管都很方便，對於管理專案者的門檻比較低，我可以把工作分派出去所以我暫時選了它。(為何說暫時勒？因為我不喜歡 Ruby On Rails ，所以暫時接受它....)
REDMINE 是一個 Ruby on Rail 開發的專案管理平台，且包含了可以讀取 svn or git 版本控管系統的界面，wiki 文件及 issue tracker 的整合性平台。功能完成，外掛套件也很多。且針對每各專案都有獨立的 wiki , SCM , 文件,日曆等界面，可以專一的控管專案。
這是他的活動，最近有那些變化都會列出再這裡。
這個是他的 bug tracker ，issue 可以父子問題相依，填功能時用點小技巧就可以達成里程碑的功能控管專案的進度。
上面的 issue tracker 可以直接和日曆、甘特圖結合，非常的方便可以控管專案。
WIKI 就跟維基百科一樣，可以檢視修改的文件變化。維護也很簡單。
程式碼儲存庫，可以支援 svn or git 等，且可以再 web 上比對程式碼的不一樣，也可以看 code style 隨時可以稽核。
版本控管最後選擇了 Subversion 的版本控管系統，因為員工程度落差過大，集中式的控管方式最能保障不會出大問題。也可以知道目前的進度。
這段我應該作個 SVN 的 step by step 教學文的，不過限於篇幅晚點再說....
當開發環境只有一個人的時候，可以用這個比較簡單的方式作程式碼的控管。只要先 svn commit 倒 Testing 的平台，測試正確後就可以 Release 的產品網站了。
另外這是修改 bug 的原則方式，及開發一個功能的時候因為會大幅動到程式碼，所以建議先 branches 再 merge 合併到 trubk 主幹之中。
我希望我的員工可作息正常，身體健康。熬夜開發程式是不健康的行為，寫程式要在白天寫，集中精神大概 3HR 就讓它一個循環，可以提高效率降低工時。且遵循下班前不要隨便將 Testing 轉換到 Release 的網站，因為通常那有可能讓我加班修理 bug.....
並且程式碼希望寫的淺顯異動，否則其他人看不懂那就沒辦法了........
最後就是推行了，通常開發人員看不到整個開發流程的全貌。所以透過這份報告，告訴它門開發軟體的全貌。我想這種勇氣、正直、善良和不爆肝的軟體開發流程大家應該可以接受才對。
軟體工程是一個有趣的課題，整個學期讀完一本軟體功能的議題，並且經過作者本人再課堂上面的講解，有實務經驗的超資深業界學長帶領完成整個軟體工程課程。
軟體工程 - 導論
軟體工程-課程大綱
上課錄影檔：(李智 http://richchihlee.wordpress.com/ )
為何要軟體工程，軟體專案為何會失敗? 如何避免失敗
軟體工程 - 出發前的準備
軟體工程- Requirement Analysis
軟體工程理論與實務 - 軟體估算
軟體工程-雛型法
SOA 服務架構導向
軟體工程-coding規範風格&測試軟體方法
典型資訊系統架構-利用Archi工具塑模
沒有留言:
張貼留言