狠狠色丁香婷婷综合尤物/久久精品综合一区二区三区/中国有色金属学报/国产日韩欧美在线观看 - 国产一区二区三区四区五区tv

大致描述一下我的項目團隊（算上美工5人）在這方面的情況：

 

首先，介紹角色：

１.項目組長：相當于項目經理吧，主要職責我就不多說了。
 2.界面工程師：是用戶界面交互方面的專家，決定與用戶交互的方式，當然很大程度也影響著界面
 3.美工：設計和美化界面
 4.高級程序員：設計總體程序結構，制定技術上的規范，并為小組解決各種難題，幫助項目組長分解每日程序員任務
 5.程序員：編寫代碼，實現功能
 6.需求人員：與本話題無關，我就不介紹了
 7.公關人員：雖然與本話題無關，但我就想在這里突出其對項目組的重要性，所以順便提一下。至于要攻什么關大家一定都能猜得出來。
 8.其他，如測試人員、文檔管理人員等(想象能有plmm角色)：都很重要，但也與本話題無關。

 

工作流程：

 

 1.公關人員和需求人員獲得用戶需求，并制定需求文檔。
   需求的正確與否是項目成功的首要關鍵環節，這個我就不多說了，和本主題相關的就是他們需要獲取到用戶的各種習慣層次上，主要分為兩種思路來整理，一種是之前用過軟件系統的考慮如何延續他們的習慣，另一種是之前沒有用過軟件系統的考慮如何適應他們原有手工的工作流程，并作出合理化的改進。
 
 2.項目組長和需求人員以及高級程序員共同根據需求制定大體的設計方案，包括總體模塊和各個可行性功能。
  在這里，項目組長會根據需求人員和高級程序員的意見來合理安排出一個基本雛形，然后去寫Project2003（我覺得這個蠻不錯）...后面還有反復交復雛形給用戶確認等等我就不介紹了。有一點值得注意的是，項目組長除了需要具備一定的人員管理方法以外，最好還是要懂得技術，這樣能夠制定出更合理、更準確的項目進度，也能帶動團隊工作的士氣。個人認為項目經理的技術水準應該在高級程序員之上，不然在這個環節中就只能聽取高級程序員的意見了，相信大家如果遇到個不懂技術的項目經理，而他又指責你技術水準有問題時，一定都會自然而然地產生想K他一把的沖動，這樣的團隊還能保持好的士氣么？技術人畢竟還是需要以能耐服人來得好。
 
3.開工，項目組長在高級程序員配合下根據預先計劃開始推動項目進展。
  這里是關于本主題的主要環節，首先由項目組長和高級程序員在上一環節設計的雛形的基礎上按照計劃規劃架設各模塊的基本結構。然后以模塊為單位，我這邊團隊喜歡采用我們稱之為狼群戰術的方法來逐步蠶食各個模塊，每個模塊的流程分為如下幾個步驟
   a.高級程序員詳細化拆分該模塊的各個界面和功能，包括前臺和后臺等。需要需求人員給出參考
   b.在高級程序員的分配下，界面工程師對當前子模塊制定界面用戶交互的基本方案，也需要需求人員給參考，美工人員則給出美學方面的建議，并達成一致。在這里，界面工程師會將決定界面的大致框架，并將界面相應的功能描述成文以用于給程序員，一個子模塊界面的雛形在這里已經誕生，生成的程序文件有aspx和(vb或cs)，建議界面結構最好用表格來設計。
   c.美工去做界面，對界面工程師所搭建的界面框架aspx或ascx文件進行處理，如背景、需要配合的圖片圖標及flash等。在這里環節上，美工已和界面工程師已經在明確需求人員的指導下達成對界面統一風格的一致。因為界面工程師在之前已經在頁面中制定好標記，所以美工可以忽略有腳本標記的地方。而且，總的來說這一環節上美工主要是預先為界面定義好各種素材。
  d.與美工并發執行的是高級程序員與程序員對功能的實現。程序員們在界面工程師的指導下將功能實現，其間包括滿足交互功能所需的控件、業務規則層、數據訪問層，等等的實現，所涉及編寫的文件則為界面文件(ascx等)和程序文件(vb或cs)。這里需要說明的是在實現功能時程序員只要把滿足功能的控件拖到大致位置就可以，然后就關注功能的實現。而此時美工也在設計該界面，但因為只是設計素材，所以根本不與程序員沖突，在后面的環節中始終以程序員完成的程序文檔為準。
  e.程序員完成功能后，轉交測試人員進行功能測試。。。
  f.基本測試通過后，又回到界面工程師手里，在不改動程序文件(vb或cs)文件的前提下，界面工程師只對界面文件中的各種控件、結構等進行調整。達到滿意的效果為止。
  g.界面基本已經誕生，只是全裸不太文雅，所以這時回到美工手上，給其穿上美工設計的靚裝，加上各種圖片背景等就ok了
  h.補充一下項目組長，貫穿整個過程，負責團隊人員之間的協調，監督項目進度，合理分配任務，看誰不干活就。。。

 4.所有模塊都完工后，就是整體的銜接和測試，然后反復交復用戶征求意見，這里參與的是團隊所有的人馬，一直忙到最后期限為止，然后再延期，直到用戶滿意。

  以上是我所在團隊的大致工作流程，大家看了后一定會提出如此分角色人手資源一定不夠的問題。確實，通常來說小公司的開發團隊就幾個人，所以通常很容易做著做著就陷入作坊式做法，大家角色不明確，各自包辦各自的模塊，導致之后程序維護非常困難。我上面所述的工作流程中每個環節都明確指出了每個角色的出現場合，所以我是很強調以角色來分工。但如我前面所提到的，我這邊的團隊也不過5個人，所以，雖然角色眾多，但我們還是可以根據各自的團隊實際情況來分擔這些角色，只要記住一個原則，找合適的人去做合適的角色，即擔當某一角色的人是對該角色領域感興趣的人。比如在我的團隊中，美工是對藝術美感感興趣，我團隊的美工是plmm，可惜只是兼職，沒太多機會，建議大家有條件就找plmm來擔任。需求人員是對整體業務有興趣的人，我這里的需求人員是辦公室頭，所以向上和外界的公關都是由他搞定。還有兩個是程序員角色，一個偏向于底層數據庫的實現，另一個偏向于邏輯層的實現，而最后我則是很痛苦地擔當了項目組長、界面工程師、高級程序員的角色。之所以這樣，也是無奈，因為團隊組建才半年不到，兩個程序員尚不能勝任更高級的角色，期望其中一個人能盡快勝任界面工程師角色，那樣就能做到更合理化的角色分配，是理想的團隊結構。

該文章在 2011/4/7 22:53:28 編輯過