小蟹的Rails心得筆記

上班一年多了，最近一次的大型專案開發在 6/1 上線，來利用這篇文章反省加檢討我參與過的專案管理與開發時程問題。

先講很失敗的第一次，因為對當時的實力掌握太差，所以最後大受打擊無疾而終。

處理的專案是廣告系統的後台，需要改寫並新增功能，但我想完 model ，寫完 CRUD 之後就停滯了。

• 原因1：當時的我，對於基本網站架構還不夠熟悉，在規劃 CMS 上也不夠清楚，因此上稿的部份寫完，與前台接軌就卡住了。
• 原因2：寫完那些 CRUD 之後，因為我同時還要顧及美妝的專案，每個月固定都要寫 event ，雙管齊下當時的我無法吃下來。
• 原因3：時間管理太差，我當時沒有把整個負責部分切開成一張張小票的能力，整個混在一起沒頭沒腦地做，難以掌控進度，也無法知道什麼時候要完成哪些區塊。

最後因為開始寫美妝的 event ，負責的部份就也撥給同事處理，那時候也沒有再拆票過來請我幫忙，從此這個專案就成了我心中的痛，處理的一團糟。

回頭檢視，我真是太傻太天真，做一塊還不夠熟悉的東西（web），也不曉得章法（製作流程），重點是也不知道怎麼開口請教別人給予一些基本指導。

再來講最近的一次美妝改版，情況比剛剛說的廣告後台專案好，但有很多值得檢討記錄的地方，這也是寫本篇的目的。

改版的方式走瀑布式開發，雖然我一直很想嘗試敏捷開發，但是我對網站的經驗還是太少，無法充分的決斷與規劃。

在初期，我先挑了一個最麻煩的新品快遞服務來處理，開始將 database 先 porting 成新版的結構，同時做出對應呈現的前台。這次我學乖了，開始試著把這個服務切成一張張小票處理，但是我沒有處理好時程，對於處理事項的權重也有問題。票開好了應該要先排序、找核心票避免解票時發生卡票、相依性太高的票要盡量切小/切開，這些問題我都踩到了，因此開發時雖然一直在做事，但卻像多頭馬車什麼都有做卻什麼都沒有完成，所以在時程上顯示一直 delay。

同時，雖然這段時間美妝的 event 改用其他方式製作，不會花到我的時間，但我決定趁這次機會，將陳舊的 Rails 2.3.4 直接改用 Rails 3.0 改寫，導致初期花了不少時間，將原本的程式搬過來後調整成新版的寫法。另外，由於有做 SSO ，原本的使用者認證 gem 就變得太過肥大，當時我決定將原本的 user authentication library 改寫一份給專案使用的精簡版本，這種種繁雜的問題，使得初期進度極為緩慢。

初期的問題在於，我對 Rails 3 還不熟，所以在估算改寫的時間時，必須要將解決 Rails 3 的寫法這塊也考慮進去。雖然我習慣性地的預留一些開發時間，但是留的太少了。再來，當已經拆出小票之後，優先權最高的應該是 dependency 最高的票，因為這種票不做完會 block 到其他票的進度；其次是要把只有自己特別熟悉的票先做完，因為這種票如果要請其他 RD 協助，是快不起來的。這幾點之中，我只有最後一項處理的比較好，前兩項準則沒抓到，所以做起票來東卡卡西卡卡，成效不彰。

中期的時候，雖然花了不少時間，但我有把初期新品快遞的服務功能寫完 90% ，因此當美術把版都切完送過來時，我開始處理第二塊 porting 流行日誌，這時也正式進入五週的技術開發時程。由於先前寫 Rails 3 把部分的地雷都排除過，因此技術上卡住的情形降低很多，不過我在這個階段做錯兩件事，迫使我時程大 delay 。

第一，新品快遞的服務功能完成 90% ，這個數字事實上有 pending 一個在後台接軌痞客邦相簿的功能，決定 pending 的原因很簡單，因為已完成的功能是可以正常上稿，也可以使用痞客邦相簿，只是會多幾道手續，但是如果要完成接軌的功能我得再花 2~3 天實作，以時程來說最高優先毫無疑問是上線，因此我應該先去完成其他的服務，最後有時間再來解這張功能票，但我陷在裡面好幾天，後來主管提醒之下才醒悟。

第二，優先權錯誤，在初期和中期開發上，我都把 database migration 放在最高優先，因此花了很大的力氣去做對應的 convert ，這個決定錯在我應該先生頁面，讓頁面功能正常，再來做 database migration 把舊資料轉移過來才對，畢竟上線會先看的是功能正常，其次才是看資料內容。

由於這兩個原因，讓我做了兩週之後，雖然大部分資料庫已轉好，但頁面依舊有許多是未套版或功能未完成。第一週結束時我還很天真的認為，進度雖然有延誤，但是週末加班趕工可以追上進度，第二週結束後才發現我錯了，檢視之下發現，原因是我切出的票具有太高的 dependency ，可是我花在做 database migration 的時間卻不少，因此頁面功能的進度 delay ，導致時程被越拉越遠...

在第一週發現時程延誤時，我有先告知主管希望把我不擅長的票拆出去，請其他 RD 幫忙，但只有一小部分；而到第二週結束時，我不得不再次告知主管，我很抱歉拖到時程只剩三週才講，可是必須要再請一位 RD 一起寫，否則真的會來不及。幸運地是，雖然我當初花了太多的力氣去做 database migration ，但這部份也是我較為熟悉的部份，因此一起合作 coding 的 RD 在跳進來後沒有被這塊 block 。

後期開發上，首要決斷是我完全放棄管理專案，改請主管接手，我不再開會而是專心寫程式，而且很明顯我的排票、時程估算和決策等等都還有待磨練。主管接手之後，他很迅速地根據時程決定 pending 一些有替代方案、以及影響較小的功能，讓所有目標都專注在完成整個網站並上線，同時 RD 的壓力也跟著降低；此外，主管根據我已經切出的票再延伸，讓團隊開發上能夠更加地容易。以往我開票的方法不夠有條理，也沒有切到很乾淨，在做票時也不曉得要設定狀態讓其他 RD 知道，這次讓我都學到了。另一位 RD 加入之後，由於 api 接軌和 javascript 的部分他很熟，功能做起來也相當迅速，而我就可以專心做我熟悉的部份，進度因此明顯提昇，最後得以在 6/1 順利上線。

總結來說，

• 我對於時程估算非常有待加強，主要是得看出實作上會花時間的地方，有時候魔鬼藏在細節裡，沒做過真的不會知道小地方其實需要花很多時間實作。基本 CRUD 最少要半小時，如果有特殊功能繼續往上加； database migration 非常花時間，一定要儘早處理；遇到有加密的部份，因為涉及到 system library ，最少要撥三天處理（像是 SSO ）；自己不擅長的技術，要估算兩倍或三倍的時間；有替代方案的功能，可以往後壓晚點做。
• 我的切票技巧有比以前好，但是切的還不夠乾淨，最終目標應該是切出的票要有正交性。
• 做票的優先權， CRUD 很枯燥，但是要乖乖地做；所有的 link 都應該先做，不然會缺東少西；拆不開，具有高 dependency 的核心功能要先做，不然會 block 後面的票；只有自己能做的票要先做，以免影響到其他 RD 。
• 排定時程時，從容易的功能開始，排在時程末端，接著依序將越難的功能排到越前面的時程。訂好的時程，要每天或是每兩天檢查，延誤一週就要趕快求救。

以上這些，是我親身的專案經驗檢討，雖然兩次專案都沒有處理好，但記錄下失敗的經驗，避免以後重蹈覆轍。這次趁著記憶猶新，將這兩個月的苦日子回想了一遍，盡量客觀地把自己的問題找出來。沒有人喜歡失敗，我也不例外。