In 91

前言

在我常接觸到的團隊開發上，通常分工比較細。
會有SA幫忙開功能Spec，而PG拿到Spec後，根據Spec來撰寫程式，完成所需功能，達到User RFP上的目的。

而在SA與PG之間的working model，怎麼樣可以有效的降低其中的成本，
這邊以個人小小的一點經驗，整理了一些issue，供未來新鮮人參考。

 

Guideline

1. 拿到規格前，應該要做的事
   1. 必須瞭解眼前這支規格，在整個系統中，扮演的角色，有什麼樣的功能，目的是要解決使用者什麼樣的需求。
      • 有whole picture才不會見樹不見林
   2. 瞭解「共用規格」或「系統開發手冊相關」說明
      • 可能是word, excel, 或是wiki等形式的文件
      • 避免重複發明輪子，降低重複開發的成本。避免一式多份，降低維護上的困難。
   3. 每天開工前，記得上SVN update，檢查一下規格是否有異動
      • 確保規格是最新的，才不會重工。衝得越快，方向錯了，成本越高。
2. 拿到規格時，應該要做的事
   1. 先把規格整體全看過一次，先抓骨頭再看肉，把有問題的部分都先紀錄下來
      • 紀錄完，再review一次規格與問題紀錄的描述是否通順，有沒語意模糊、前後文矛盾或交代不清的情況
      • 如果同案子有Senior developer，詢問一下他的意見
      • 建議先以email將相關的問題與紀錄，mail給SA，請教他們何時有空可以討論上述的問題
   2. 從功能規格、程式規格、測試腳本去瞭解這支程式的目的、前後關連程式、有哪些傳接值參數
      • 用抽象角度去看這支規格實際在做什麼事
   3. 是否有參考其他共用程式或其他規格(如用到哪一些UserControl、Service、共用function)
      • 檢查參考到的部分是否已經完成
      • 是否知道該如何使用這些共用的東西
   4. 檢查DB相關table是否存在，欄位名稱是否有不一致的情況，且應擁有(初始)資料
      • 測試值是否具有規則，請SA/User提供範例資料與規則
      • 瞭解table之間的關係
   5. 檢查EA(或其他UML modeling tool)上相關的Diagram與Data model
      • 抽象的去瞭解此功能的目的、參與人員，使用的物件彼此之間的關係，以及互動的情況
   6. 瞭解UI動線，用使用者角度去看，操作是否合理、順暢
      • UI的敘述與文字的說明是否match
      • 顯示與否、唯讀與否
      • 初始值與動作後要改變的值
      • 驗證相關、是否需提示訊息、相關訊息是否存在於資源檔中
      • 考量「Performance」、「頻寬」、「相容性」、「未來修改彈性」、「UI實作困難度」、「即使做出效果來是否好維護」等等tradeoff的因素，衡量是否有更好的UI設計
   7. 程式命名與路徑的確定
   8. 底層架構、公用控制項、Skin與CSS的確定
3. 拿到規格後，應該要做的事
   1. 說給SA聽你看到的規格是要做什麼(What to do)
      • 以自己理解的方式，與SA或Senior developer再進行一次確認(Validation)，確保開發出來的軟體符合客戶(系統)的需求
      • 軟體開發品質V&V的落實
        • Validation(確認)：確認工作產品符合客戶的需求(do the right thing)
          • Review
        • Verification(驗證)：使工作產品符合設計上的品質(do the thing right)
          • Testing
      • 作對的事比把事情作對更重要
        • do the right thing rather than do the things right
           

結論

以上僅是個人經驗所整理出來的一些建議，僅供參考。

也希望可以得到更多的feedback，來改善這樣的過程。

希望對junior develoepr或比較少接觸到團隊開發模式的programmer有所幫助。

---

blog 與課程更新內容，請前往新站位置：http://tdd.best/