JWorld@TW the best professional Java site in Taiwan
      註冊 | 登入 | 全文檢索 | 排行榜  

» JWorld@TW » Software Engineering  

按列印兼容模式列印這個話題 列印話題    把這個話題寄給朋友 寄給朋友    訂閱主題
reply to topicthreaded modego to previous topicgo to next topic
話題被移動
該話題已被移動 - popcorny , 2003-10-15 10:51
如果您尚不清楚該話題被移動的原因,請參考論壇規則以及本版公告或者聯系本版版主。
本主題所含的標籤
無標籤
作者 Re:一個既有的系統想要進行architecture的調整,你們認為該怎麼做比較好呢? [Re:popcorny]
Biologic

生物學下的產物



發文: 524
積分: 4
於 2003-10-07 17:38 user profilesend a private message to usersend email to Biologicreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
popcorny wrote:
Bio講的的確是一種做法...
但是若我是客戶...以獨哥哥形容的case
最主要的是本既有系統移植到J2EE platform上
這是他們這個project的重點....
而新功能是附屬的...
若第一個phase就先把新功能做出來...
也許根本不是客戶想要的...

再者...
通常我們會希望越早建立Architecture Baseline...
也就是能夠在這個architeture的骨幹下..
可以有方法實作出客戶的大部分需求...
若只想要做新功能...
往往會忽略客戶的需求本質...
在第二第三年的話...
又要把就系統轉過來新系統
又要保證你的新功能可以正常運作
這會比較簡單嘛?? 可想而知...

所以我還是堅持我的說法..
把舊系統轉到新系統是首要時做出來的
也是風險最大的
第一步只要踩的穩
接下來的三四年也是囊中物了阿...XD


我的做法並非沒有先做 architect. 正確來說是在 new feature 上使用 new architect.
但是不同點是 我不先把 舊系統替換成新系統, 然後才開發新 features.
我是反向, 先 new features, 然後 old system.

事實上 new feature 跟 old system 有些一定會衝突. 到時需要同步修改. 但是不衝突的為優先處理.


reply to postreply to post
作者 Re:一個既有的系統想要進行architecture的調整,你們認為該怎麼做比較好呢? [Re:popcorny]
Biologic

生物學下的產物



發文: 524
積分: 4
於 2003-10-07 23:41 user profilesend a private message to usersend email to Biologicreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
popcorny wrote:
Bio講的的確是一種做法...
但是若我是客戶...以獨哥哥形容的case
最主要的是本既有系統移植到J2EE platform上
這是他們這個project的重點....
而新功能是附屬的...
若第一個phase就先把新功能做出來...
也許根本不是客戶想要的...

再者...
通常我們會希望越早建立Architecture Baseline...
也就是能夠在這個architeture的骨幹下..
可以有方法實作出客戶的大部分需求...
若只想要做新功能...
往往會忽略客戶的需求本質...
在第二第三年的話...
又要把就系統轉過來新系統
又要保證你的新功能可以正常運作
這會比較簡單嘛?? 可想而知...

所以我還是堅持我的說法..
把舊系統轉到新系統是首要時做出來的
也是風險最大的
第一步只要踩的穩
接下來的三四年也是囊中物了阿...XD


再補一下好了

在你的答案中是強調從困難的先做. 但我會先從簡單的 sub-system/elements/components 先做. 然後每個 sub-system 我(或許)會從困難(or key elements)的先做.


reply to postreply to post
作者 Re:一個既有的系統想要進行architecture的調整,你們認為該怎麼做比較好呢? [Re:Biologic]
singlelog

換回來



發文: 416
積分: 6
於 2003-10-08 00:15 user profilesend a private message to usersend email to singlelogreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
Biologic wrote:
再補一下好了

在你的答案中是強調從困難的先做. 但我會先從簡單的 sub-system/elements/components 先做. 然後每個 sub-system 我(或許)會從困難(or key elements)的先做.

user可能會希望enhancement先上,特別是這種經年累月的系統,通常會有很多可以改善的地方。
可是加入越多現在不存在的功能,在phase 2, phase 3提出新的change request的機率也會變高,並且在第一個phase的loading也會重很多。除了migrate data/reverse engineering/parallel run以外,還要跟user敲requirement,確定新的feature,並且經過漫長的測試期間。這樣overall的risk會變高。
在客戶滿意跟降低風險之間,通常得要有一個平衡點。我建議透過市場機制來解決這個兩難。也就是說,同樣的功能在不同的phase做,其實成本是不一樣的。
在phase 1做,可能你底層的架構還沒調整好,就要硬著頭皮去寫,這樣成本應該會比較高。在後面的phase來做,成本會變得比較低。最少你手上可能已經有一堆東西可以參考/reuse了。所以在不同的phase implement的話,收不同的價錢,看user要那個phase上。反正重賞之下必有勇夫。收多一點錢,就擔多一些風險,這是天經地義的事情。
不知道有沒有人有更好的建議?


reply to postreply to post
我的書:專案管理Happy書!

我的網站:diggirl.net

my blog http://tinyurl.com/36gcye
作者 Re:一個既有的系統想要進行architecture的調整,你們認為該怎麼做比較好呢? [Re:Biologic]
ming215





發文: 143
積分: 2
於 2003-10-08 01:20 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
Biologic wrote:
我聽過有公司賣 SA/PM 的人力. 這個不知道可不可以算 SA/PM 可以賺錢?


租人力的方式肯定有賺, 但要注意的是..租到最後..變成他們的人..

在專案評估上, 當然就是人力.成本.系統功能範圍.時程的定義等等,
花多少cost在硬體? 花多少錢在軟體? 大約估算會有多少個功能模組(程式支數粗估)? 開發成本(依開發人員熟悉的架構或不熟悉的架構..成本會差粉多)

硬體規劃..需不需要做 cluster? 用 ap 還是 hardware 做? 要不要 load balance?
要不要 backup ? even 做 異地備援? 允許多少個人同時作業? 系統回應時間? 系統 crush後的復原承受時間? 這些都會影響到硬體方面的成本.

軟體呢? 主機的作業系統? run time environment ? db? 是否需有 media server? 是否要有 ldap server? application server 用哪套? 是否有特殊需求? web base? internet/ intranet / client.server?
這些都是規劃時所要考慮的..

ok, 撇開這些不說. 若以純 ap 考量呢?

公司有多少個部門要使用系統? 部門間的 data 交換? 對舊系統所不滿的地方?
舊系統好用的地方? 什麼功能是核心, 一定要用的? (如以會計而言, 傳票則為最基本, 但傳票又分 支出/收入/轉帳/現金轉帳 等亂七八糟的各式傳票? 但其實只需轉帳傳票一種就足以沖轉所有科目)

如分期施工..假設為三年好了,

第一個月..軟硬體架構規劃 (機器設備環境 servey)
第二個月..排定各部門需求會議(了解新舊系統功能差異,界定急迫性/非急迫性需求功能, )
第三個月..整合各部門需求(了解各部門資料是否有共用資料, 是否有流程性相關? 如二次簽核公文等等)
第四個月..提出整體規劃(sa文件)

考量重點, 各部門需求的急迫性..資料共通性..

如 會計部門已轉換系統, 則連帶財務必需一併轉換
那麼 倉庫 是否先不去動它? 那進貨呢? 應收/應付款項如何勾稽?
那..若以進/銷/存部份先進行..會計帳最後再動呢?

若各部門轉換時程不同, 則需再訂出過渡時期的資料交換方式
以獨立運作的部份先go, 其它的必需想好轉換的順序, 才不會各部門哀號遍野

............後續的...呃..懶得寫了..好累...
總之, 細項的工作項目都訂出來後, 大約就可以推算出各階段的時程了

回到原主題上, 以我為例, 接的是公家機關的案子居多
風險評估? 基本上..我覺得我們專做不可能的任務..

舉例說明: 10月標到案子, 同年12月要結案, 案子maybe算100萬好了
人給你 2 個新手, 時間到請你交出東西...

政府專案..有預算執行壓力, 時間到, 東西就是要交..要驗收.教育訓練.上線
接不接這個案子? 呃..好像由不得你不接..
當有利益關係的客戶找上公司幫忙做案子時, 由得你不接嗎?
好吧..就接吧?! 如何在時程內完成這個案子..就是考驗一個pm&團隊了..


reply to postreply to post
作者 Re:一個既有的系統想要進行architecture的調整,你們認為該怎麼做比較好呢? [Re:singlelog]
Biologic

生物學下的產物



發文: 524
積分: 4
於 2003-10-08 09:28 user profilesend a private message to usersend email to Biologicreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
singlelog wrote:
user可能會希望enhancement先上,特別是這種經年累月的系統,通常會有很多可以改善的地方。
可是加入越多現在不存在的功能,在phase 2, phase 3提出新的change request的機率也會變高,並且在第一個phase的loading也會重很多。除了migrate data/reverse engineering/parallel run以外,還要跟user敲requirement,確定新的feature,並且經過漫長的測試期間。這樣overall的risk會變高。
在客戶滿意跟降低風險之間,通常得要有一個平衡點。我建議透過市場機制來解決這個兩難。也就是說,同樣的功能在不同的phase做,其實成本是不一樣的。
在phase 1做,可能你底層的架構還沒調整好,就要硬著頭皮去寫,這樣成本應該會比較高。在後面的phase來做,成本會變得比較低。最少你手上可能已經有一堆東西可以參考/reuse了。所以在不同的phase implement的話,收不同的價錢,看user要那個phase上。反正重賞之下必有勇夫。收多一點錢,就擔多一些風險,這是天經地義的事情。
不知道有沒有人有更好的建議?


這個我有一個比較好奇的問題. 原則上系統已經存在了, 為什麼還要考慮使用者想要的先上? 相反的在沒有一定的系統了解下, 冒然的去動某些很 risky 的 sub-system 這個除了成本可能提高外. delay/failure 的機率也非常高.

除了 new features 以外, 我不覺得先把使用者想要的舊系統改成新的比較主要. 因為通常使用者要求的都非常具有 risk.

通常舊系統一定有限有的 system structure. 不過我原則上是希望企劃案開始的時候就先做完整的 sa. 然後制定一套系統架構. 排定進度.

不過 ming 講的很對, 很多東西是需要考量的. 這個企劃案還有點問題不明瞭, 那就是 user 的工作環境. 很多系統是設計的很完美, 但都是以專業的角度上. 並非使用者的角度. 畢竟用的人不是我們. 這樣下企劃就算做好了, 一樣都會被宣告失敗.


reply to postreply to post
作者 Re:一個既有的系統想要進行architecture的調整,你們認為該怎麼做比較好呢? [Re:ming215]
Biologic

生物學下的產物



發文: 524
積分: 4
於 2003-10-08 09:30 user profilesend a private message to usersend email to Biologicreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
ming215 wrote:
租人力的方式肯定有賺, 但要注意的是..租到最後..變成他們的人..

在專案評估上, 當然就是人力.成本.系統功能範圍.時程的定義等等,
花多少cost在硬體? 花多少錢在軟體? 大約估算會有多少個功能模組(程式支數粗估)? 開發成本(依開發人員熟悉的架構或不熟悉的架構..成本會差粉多)

硬體規劃..需不需要做 cluster? 用 ap 還是 hardware 做? 要不要 load balance?
要不要 backup ? even 做 異地備援? 允許多少個人同時作業? 系統回應時間? 系統 crush後的復原承受時間? 這些都會影響到硬體方面的成本.

軟體呢? 主機的作業系統? run time environment ? db? 是否需有 media server? 是否要有 ldap server? application server 用哪套? 是否有特殊需求? web base? internet/ intranet / client.server?
這些都是規劃時所要考慮的..

ok, 撇開這些不說. 若以純 ap 考量呢?

公司有多少個部門要使用系統? 部門間的 data 交換? 對舊系統所不滿的地方?
舊系統好用的地方? 什麼功能是核心, 一定要用的? (如以會計而言, 傳票則為最基本, 但傳票又分 支出/收入/轉帳/現金轉帳 等亂七八糟的各式傳票? 但其實只需轉帳傳票一種就足以沖轉所有科目)

如分期施工..假設為三年好了,

第一個月..軟硬體架構規劃 (機器設備環境 servey)
第二個月..排定各部門需求會議(了解新舊系統功能差異,界定急迫性/非急迫性需求功能, )
第三個月..整合各部門需求(了解各部門資料是否有共用資料, 是否有流程性相關? 如二次簽核公文等等)
第四個月..提出整體規劃(sa文件)

考量重點, 各部門需求的急迫性..資料共通性..

如 會計部門已轉換系統, 則連帶財務必需一併轉換
那麼 倉庫 是否先不去動它? 那進貨呢? 應收/應付款項如何勾稽?
那..若以進/銷/存部份先進行..會計帳最後再動呢?

若各部門轉換時程不同, 則需再訂出過渡時期的資料交換方式
以獨立運作的部份先go, 其它的必需想好轉換的順序, 才不會各部門哀號遍野

............後續的...呃..懶得寫了..好累...
總之, 細項的工作項目都訂出來後, 大約就可以推算出各階段的時程了

回到原主題上, 以我為例, 接的是公家機關的案子居多
風險評估? 基本上..我覺得我們專做不可能的任務..

舉例說明: 10月標到案子, 同年12月要結案, 案子maybe算100萬好了
人給你 2 個新手, 時間到請你交出東西...

政府專案..有預算執行壓力, 時間到, 東西就是要交..要驗收.教育訓練.上線
接不接這個案子? 呃..好像由不得你不接..
當有利益關係的客戶找上公司幫忙做案子時, 由得你不接嗎?
好吧..就接吧?! 如何在時程內完成這個案子..就是考驗一個pm&團隊了..


你談的好像都是技術性問題... singlelog 好像想要談的是 管理性問題.
對了 你有沒有照片?


reply to postreply to post
作者 Re:一個既有的系統想要進行architecture的調整,你們認為該怎麼做比較好呢? [Re:Biologic]
Biologic

生物學下的產物



發文: 524
積分: 4
於 2003-10-08 09:31 user profilesend a private message to usersend email to Biologicreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
Biologic wrote:
你談的好像都是技術性問題... singlelog 好像想要談的是 管理性問題.
對了 你有沒有照片?


... 也不太對... 大家討論的都很技術性問題...


reply to postreply to post
作者 Re:一個既有的系統想要進行architecture的調整,你們認為該怎麼做比較好呢? [Re:Biologic]
ming215





發文: 143
積分: 2
於 2003-10-08 10:56 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
Biologic wrote:
你談的好像都是技術性問題... singlelog 好像想要談的是 管理性問題.
對了 你有沒有照片?


照片?..Oh My God? 啥碗糕?

嗯嗯~~ 偶素以寫 proposal 的角度去看, 規劃一個系統時優先考慮到這些東東,然後才有辦法往下 go, 若連這些都不確定..要怎麼開始?

人力.時程的控管..真的是沒有一定呀..完全要看系統範圍
硬體建置的人力.時程..甚至進主機的時間..
開發環境建置..這些也要時間..

所謂的時程壓力..這些是都算在內的~所以還要先看整個系統含不含硬體建置

就算不含硬體建置..至少也有 測試環境建置 & 正式環境建置的時程問題


reply to postreply to post
作者 Re:一個既有的系統想要進行architecture的調整,你們認為該怎麼做比較好呢? [Re:ming215]
im1000



版主

發文: 149
積分: 7
於 2003-10-08 11:42 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
當一個案子超過一個評估的臨界點

人力的評估很容易發生錯誤
1. 人力是流動的
2. 人不可能一直在寫程式
3. 人的實力也是不一樣的
............... 有很多

時程的掌控很容易發生錯誤
1. 需求的變更
2. 隱含的 BUG
3. 技術上的瓶頸
............... 有更多

我想獨孤大大想要討論的
就是這麼多不確定因素之下
該如何抓出異動的風險評估方法
進而想辦法分割時程及專案目標


reply to postreply to post
作者 Re:一個既有的系統想要進行architecture的調整,你們認為該怎麼做比較好呢? [Re:Biologic]
singlelog

換回來



發文: 416
積分: 6
於 2003-10-08 12:07 user profilesend a private message to usersend email to singlelogreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
Biologic wrote:
這個我有一個比較好奇的問題. 原則上系統已經存在了, 為什麼還要考慮使用者想要的先上? 相反的在沒有一定的系統了解下, 冒然的去動某些很 risky 的 sub-system 這個除了成本可能提高外. delay/failure 的機率也非常高.

我也認為這樣risk很高。不過單純就end user來說,他們通常不會因為架構不好而想要換系統,通常是原有的系統已經不敷使用了,才會想要換。(有些大公司的系統經過經年累月的patch下去,後面的人改出來的side effect遠大於正面的效益。)

換architecture這種事情,IT人員當然都很興奮,有機會換成J2EE,好耶,Oh yeah。Oh yeah。Oh yeah。可是對於user來說,這些東西比較虛無縹緲。所以通常user的demand會是希望在第一個phase就有一些新的需求可以被realize。

要拿到user的support,通常會在業務的考量下,同意這個決定。雖然做的人通常都不怎麼喜歡這麼高的risk。Smile


reply to postreply to post
我的書:專案管理Happy書!

我的網站:diggirl.net

my blog http://tinyurl.com/36gcye
作者 Re:一個既有的系統想要進行architecture的調整,你們認為該怎麼做比較好呢? [Re:im1000]
ming215





發文: 143
積分: 2
於 2003-10-08 12:19 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
im1000 wrote:
當一個案子超過一個評估的臨界點

人力的評估很容易發生錯誤
1. 人力是流動的
2. 人不可能一直在寫程式
3. 人的實力也是不一樣的
............... 有很多

時程的掌控很容易發生錯誤
1. 需求的變更
2. 隱含的 BUG
3. 技術上的瓶頸
............... 有更多

我想獨孤大大想要討論的
就是這麼多不確定因素之下
該如何抓出異動的風險評估方法
進而想辦法分割時程及專案目標


那就更複雜了, 必需 by project 去看

基本上..project 有分 初期..中期..末期....
我前面所提到的..算是 before (初期)
一旦案子開始 go 了, 人力..時間..個人能力 都是考量重點
把適合的人擺在適當的位子上..才能發揮到最大值

分割時程..專案目標..這樣說太籠統

sa..sd..db建置..coding..debug..test..trainning...document write.
有辦法把人員分割的很清楚嗎?
分工太細..每個人所能學到的..一定不滿足
分工不細..每個人什麼都兼..學到了..也累屬了..

我們的人力..始終是在 3-5人 一個專案..從頭包到尾..所有事情都包..
你跟公司喊人力不足..老闆說..好呀..要人就給你人..
問題是..末期才加進來的人..未必見得就是助力呀...
加進來的人, 有沒有 sense..能不能 control ? 是有益還是有害?結果很難說

而要如何防止人員流動? 這些要去預測...真的是很困難呀~

再說到 sa 的掌控, 一旦分析錯誤..幾百支的 code 就等於白寫了..
也許重新再來一次 survey? 時程呢? 人力呢?
工程師早被玩屬了~~譙聲不斷..要不要再繼續go下去? 還是早點 quit ?

pm 決定了案子的成敗....帶頭的倒了就玩完了..以目前的業界來說..
所看到的情況是醬子吧~


reply to postreply to post
作者 Re:一個既有的系統想要進行architecture的調整,你們認為該怎麼做比較好呢? [Re:ming215]
singlelog

換回來



發文: 416
積分: 6
於 2003-10-08 12:26 user profilesend a private message to usersend email to singlelogreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
ming215 wrote:
租人力的方式肯定有賺, 但要注意的是..租到最後..變成他們的人..

沒錯。我們公司有切身之痛。人還不是用租的,是on site久了,被客戶挖角。有些公司會跟客戶簽禁止挖角條約。不過公司太小,有時候,客戶根本懶得理你。卻偏偏小公司的人少,人被挖走是最痛的。

基本上做人力派遣業的話,最大的困擾就是流動率高的問題。所以找人時,能力還不是優先考量,穩定度才是最大的重點。
ming215 wrote:
在專案評估上, 當然就是人力.成本.系統功能範圍.時程的定義等等,
花多少cost在硬體? 花多少錢在軟體? 大約估算會有多少個功能模組(程式支數粗估)? 開發成本(依開發人員熟悉的架構或不熟悉的架構..成本會差粉多)

硬體規劃..需不需要做 cluster? 用 ap 還是 hardware 做? 要不要 load balance?
要不要 backup ? even 做 異地備援? 允許多少個人同時作業? 系統回應時間? 系統 crush後的復原承受時間? 這些都會影響到硬體方面的成本.

軟體呢? 主機的作業系統? run time environment ? db? 是否需有 media server? 是否要有 ldap server? application server 用哪套? 是否有特殊需求? web base? internet/ intranet / client.server?
這些都是規劃時所要考慮的..

ok, 撇開這些不說. 若以純 ap 考量呢?

公司有多少個部門要使用系統? 部門間的 data 交換? 對舊系統所不滿的地方?
舊系統好用的地方? 什麼功能是核心, 一定要用的? (如以會計而言, 傳票則為最基本, 但傳票又分 支出/收入/轉帳/現金轉帳 等亂七八糟的各式傳票? 但其實只需轉帳傳票一種就足以沖轉所有科目)

如分期施工..假設為三年好了,

第一個月..軟硬體架構規劃 (機器設備環境 servey)
第二個月..排定各部門需求會議(了解新舊系統功能差異,界定急迫性/非急迫性需求功能, )
第三個月..整合各部門需求(了解各部門資料是否有共用資料, 是否有流程性相關? 如二次簽核公文等等)
第四個月..提出整體規劃(sa文件)

考量重點, 各部門需求的急迫性..資料共通性..

如 會計部門已轉換系統, 則連帶財務必需一併轉換
那麼 倉庫 是否先不去動它? 那進貨呢? 應收/應付款項如何勾稽?
那..若以進/銷/存部份先進行..會計帳最後再動呢?

若各部門轉換時程不同, 則需再訂出過渡時期的資料交換方式
以獨立運作的部份先go, 其它的必需想好轉換的順序, 才不會各部門哀號遍野

............後續的...呃..懶得寫了..好累...
總之, 細項的工作項目都訂出來後, 大約就可以推算出各階段的時程了

辛苦了。Thumbs up
ming幾乎把寫proposal所有的章節都寫出來了。看來是個做ERP的行家。

怎麼寫proposal可能是另一個有趣的題目,因為我每次寫這種東西都在偷懶,刻意省略很多detail。Tounge不過現在發現亂出考題,是很累的事情。還是先龜起來好了。

中間的這一段,其實很符合我原先設定的主題。如果我們要切phase時,可以參考這個idea。
ming215 wrote:
若各部門轉換時程不同, 則需再訂出過渡時期的資料交換方式
以獨立運作的部份先go, 其它的必需想好轉換的順序, 才不會各部門哀號遍野


ming215 wrote:
回到原主題上, 以我為例, 接的是公家機關的案子居多
風險評估? 基本上..我覺得我們專做不可能的任務..

舉例說明: 10月標到案子, 同年12月要結案, 案子maybe算100萬好了
人給你 2 個新手, 時間到請你交出東西...

政府專案..有預算執行壓力, 時間到, 東西就是要交..要驗收.教育訓練.上線
接不接這個案子? 呃..好像由不得你不接..
當有利益關係的客戶找上公司幫忙做案子時, 由得你不接嗎?
好吧..就接吧?! 如何在時程內完成這個案子..就是考驗一個pm&團隊了..

是啦,我們常常會接到不得不做的案子。預計schedule用聽的也覺得蠻唬爛的。可是對於pm&團隊的考驗有多大是一回事,要做之前,心裡面也要有個譜。預先做好準備。
對外可以宣稱12月結案,目標也可以訂成12月結案,不過你不能幫那兩個菜鳥排明年1~3月的工作,這也是顯而易見的事情。
以前做了很多『明年3月我們一定會上線』『今年7月我們一定會上線』的宣示,訂過很多不可能的schedule。每次跳票,team member就越來越無奈。講話也越來越小聲。現在則是越來越不喜歡做這種事情了。Smile

一個難如登天的專案做完了,team member也走光了。這種形單影隻的感受可是不好受啊。


reply to postreply to post
我的書:專案管理Happy書!

我的網站:diggirl.net

my blog http://tinyurl.com/36gcye
作者 Re:一個既有的系統想要進行architecture的調整,你們認為該怎麼做比較好呢? [Re:ming215]
singlelog

換回來



發文: 416
積分: 6
於 2003-10-08 12:44 user profilesend a private message to usersend email to singlelogreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
ming215 wrote:
照片?..Oh My God? 啥碗糕?

插花一下,上面這個問題應該跟工作版要找jsp的人那一篇有關。看來ming除了政府的案子以外,還要開發eLearning產品,真是辛苦。
ming215 wrote:
嗯嗯~~ 偶素以寫 proposal 的角度去看, 規劃一個系統時優先考慮到這些東東,然後才有辦法往下 go, 若連這些都不確定..要怎麼開始?

你說的沒錯,不過我本來是想討論proposal寫得差不多時,怎麼做風險評估,以及那種已經有舊系統存在的系統,規劃時有什麼比較特別之處。

ming215 wrote:
人力.時程的控管..真的是沒有一定呀..完全要看系統範圍
硬體建置的人力.時程..甚至進主機的時間..
開發環境建置..這些也要時間..

所謂的時程壓力..這些是都算在內的~所以還要先看整個系統含不含硬體建置

就算不含硬體建置..至少也有 測試環境建置 & 正式環境建置的時程問題

I can't agree more。所以我們昨天提過的除了要考慮,測試環境的經費問題以外,還有建立測試環境可能對於schedule的impact。特別是很多很貴的server,光是硬體廠商要出貨,都要等很久的作業時間。還不要提人為的問題。

像我們家的客戶,要建置測試環境時,要先預約DBA的時間。要開很多會前會,會中會,哇勒會後會,還要發很多email。其實可能要他們做的,不就是create table,drop table...這類的事情。沒遇過的人可能會很訝異,我頭一次遇到時也是很訝異。Smile 靠,你連test environment的create table的privilege都不給我?Angry這個時候,客戶的官僚程度就可以看得很明顯了。


reply to postreply to post
我的書:專案管理Happy書!

我的網站:diggirl.net

my blog http://tinyurl.com/36gcye
作者 Re:一個既有的系統想要進行architecture的調整,你們認為該怎麼做比較好呢? [Re:ming215]
singlelog

換回來



發文: 416
積分: 6
於 2003-10-08 13:01 user profilesend a private message to usersend email to singlelogreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
ming215 wrote:
把適合的人擺在適當的位子上..才能發揮到最大值

Agree!

ming215 wrote:
分割時程..專案目標..這樣說太籠統

sa..sd..db建置..coding..debug..test..trainning...document write.
有辦法把人員分割的很清楚嗎?
分工太細..每個人所能學到的..一定不滿足
分工不細..每個人什麼都兼..學到了..也累屬了..

我們的人力..始終是在 3-5人 一個專案..從頭包到尾..所有事情都包..
你跟公司喊人力不足..老闆說..好呀..要人就給你人..
問題是..末期才加進來的人..未必見得就是助力呀...
加進來的人, 有沒有 sense..能不能 control ? 是有益還是有害?結果很難說

而要如何防止人員流動? 這些要去預測...真的是很困難呀~

對於小team來說,分工要分的很清楚確實比較困難。
遇到這種狀況能做的,不是先預測有沒有人會走,有沒有沒有經驗的人會來,通常是會先去搶想要的人頭。先嗆聲說,我要歐尼爾,我要馬龍,我還要『不來嗯』(因應性侵害官司,小飛俠中文譯名正式更動以掌握時事脈動,符合時代潮流。主要是引言自當日時況轉播『嗯,不要不要,人家不來了。』)。好吧有個培頓我也要。(咦,是我太久沒看體育板嗎?今天看到的新名詞SKII G)

接著開始plan sunny day scenario。就是進來的人都會待到結案,需要的人都會出現。算出來的schedule還有經費乘以一個倍率。(我建議考慮乘以2以上的數字)得到的數字,是你的底線。
各種event,遇到了再說。

ming215 wrote:
再說到 sa 的掌控, 一旦分析錯誤..幾百支的 code 就等於白寫了..
也許重新再來一次 survey? 時程呢? 人力呢?
工程師早被玩屬了~~譙聲不斷..要不要再繼續go下去? 還是早點 quit ?

pm 決定了案子的成敗....帶頭的倒了就玩完了..以目前的業界來說..
所看到的情況是醬子吧~

通常遇到這樣的狀況,流動率就會變高。管理階層太短視,代價就很高。

可以考慮做做SA/SD/Code review。Good luck.


reply to postreply to post
我的書:專案管理Happy書!

我的網站:diggirl.net

my blog http://tinyurl.com/36gcye
作者 Re:一個既有的系統想要進行architecture的調整,你們認為該怎麼做比較好呢? [Re:ming215]
Biologic

生物學下的產物



發文: 524
積分: 4
於 2003-10-08 13:06 user profilesend a private message to usersend email to Biologicreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
ming215 wrote:
那就更複雜了, 必需 by project 去看

基本上..project 有分 初期..中期..末期....
我前面所提到的..算是 before (初期)
一旦案子開始 go 了, 人力..時間..個人能力 都是考量重點
把適合的人擺在適當的位子上..才能發揮到最大值

分割時程..專案目標..這樣說太籠統

sa..sd..db建置..coding..debug..test..trainning...document write.
有辦法把人員分割的很清楚嗎?
分工太細..每個人所能學到的..一定不滿足
分工不細..每個人什麼都兼..學到了..也累屬了..

我們的人力..始終是在 3-5人 一個專案..從頭包到尾..所有事情都包..
你跟公司喊人力不足..老闆說..好呀..要人就給你人..
問題是..末期才加進來的人..未必見得就是助力呀...
加進來的人, 有沒有 sense..能不能 control ? 是有益還是有害?結果很難說

而要如何防止人員流動? 這些要去預測...真的是很困難呀~

再說到 sa 的掌控, 一旦分析錯誤..幾百支的 code 就等於白寫了..
也許重新再來一次 survey? 時程呢? 人力呢?
工程師早被玩屬了~~譙聲不斷..要不要再繼續go下去? 還是早點 quit ?

pm 決定了案子的成敗....帶頭的倒了就玩完了..以目前的業界來說..
所看到的情況是醬子吧~


關於人力的流動, xp 的 knolwedge exchange, pair programmer strategy, 不知道有沒有幫助?


Biologic edited on 2003-10-08 13:09
reply to postreply to post
作者 Re:一個既有的系統想要進行architecture的調整,你們認為該怎麼做比較好呢? [Re:Biologic]
iampoya

Speculator

版主

發文: 169
積分: 8
於 2003-10-08 14:27 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
Biologic wrote:
關於人力的流動, xp 的 knolwedge exchange, pair programmer strategy, 不知道有沒有幫助?

養出了一隻狼加一隻狽
要跑就跑一雙 XD

--
ming215的照片要到沒?
身為團長,我還是要照顧一下狼族弟兄…


iampoya edited on 2003-10-08 14:30
reply to postreply to post
Japan Adult Video Album
作者 Re:一個既有的系統想要進行architecture的調整,你們認為該怎麼做比較好呢? [Re:Biologic]
singlelog

換回來



發文: 416
積分: 6
於 2003-10-08 14:28 user profilesend a private message to usersend email to singlelogreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
Biologic wrote:
關於人力的流動, xp 的 knolwedge exchange, pair programmer strategy, 不知道有沒有幫助?

沒用過,不過我覺得應該有。以前跟一個programming高手一起開發系統時,就是我先講一次,他一邊寫 code,然後順便看程式順便討論。可以找出很多思考上不周全的地方,也可以發現雖然我們在溝通時,可能有聽到一句話,文件上可能也有寫,可是somehow在寫code時,一不留神,還是會miss掉。

可是我很懷疑有多少公司會這樣做。因為pair programming對不懂的人來說,就是兩個人在做一個人份的工作。在旁邊那個不是在偷懶是在做什麼?Smile

而大老闆們是門外漢的情況居多啊。


singlelog edited on 2003-10-08 14:32
reply to postreply to post
我的書:專案管理Happy書!

我的網站:diggirl.net

my blog http://tinyurl.com/36gcye
作者 Re:一個既有的系統想要進行architecture的調整,你們認為該怎麼做比較好呢? [Re:singlelog]
arthuroy





發文: 106
積分: 3
於 2003-10-08 15:19 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
singlelog wrote:

Biologic wrote:
關於人力的流動, xp 的 knolwedge exchange, pair programmer strategy, 不知道有沒有幫助?


沒用過,不過我覺得應該有。以前跟一個programming高手一起開發系統時,就是我先講一次,他一邊寫 code,然後順便看程式順便討論。可以找出很多思考上不周全的地方,也可以發現雖然我們在溝通時,可能有聽到一句話,文件上可能也有寫,可是somehow在寫code時,一不留神,還是會miss掉。

可是我很懷疑有多少公司會這樣做。因為pair programming對不懂的人來說,就是兩個人在做一個人份的工作。在旁邊那個不是在偷懶是在做什麼?Smile

而大老闆們是門外漢的情況居多啊。


這點我們倒有切身之痛,pair programming 的結果常常變成上面會質疑: 你是不是有 cover 對方的工作 (嗯 難不成所謂的 teamwork 是喊假的嗎? 原來特種部隊間是不能互相 cover 的,電影上喊「covering fire」或是「cover me」是好萊塢憑空想出來的... bah!)。 現在台灣的環境不適用 pair programming,要做也只能私底下做不能講出來;現在業界要的人是能單打獨鬥的那種 teamwork,也就是專業不能重疊。

換句話說若是一男一女 pair programming 變男女朋友,到時公司就會想盡辦法將這兩個拆開;二個男的或是二個女的也是會要求某一個去處理另外的事務 - 反正就是「不能兩個人做一件事」就對了....what can I say?


reply to postreply to post
Self-Pity

I never saw a wild thing sorry for itself.
A small bird will drop frozen dead from a bough
without ever having felt sorry for itself.
作者 Re:一個既有的系統想要進行architecture的調整,你們認為該怎麼做比較好呢? [Re:singlelog]
aladdin

老婆不准我用兒子照片



發文: 175
積分: 3
於 2003-10-08 15:35 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
我們公司剛好在做獨孤兄所提到的案例, 我們是要把sybase+powerbuilder轉到新版的sybase+j2ee. 我不是mis的人, 但因為和這些人的交情不錯, 常常聽到許多耳語. 有機會, 可以拿我公司來做題目, 大家比較有真實感. 不過得先過了這一陣子再說.

另外, pair programming最大的好處就是速度. 小時候參加教育部的程式設計比賽, 四個人一組, 只能帶一部機器. 前兩年成績都不怎麼樣, 第三年, 我們從前一年的冠軍隊伍身上看到兩人一組的威力, 我們也依樣畫葫蘆, 接下來拿了兩年冠軍.

Pair programming的另外一個好處就是專心, 現在電腦一打開, 誘惑太多, 隨隨便便上網(哦!該回去工作了!), 就可以掛個半天. Pair的時候, 就像是兩個人開會腦力激盪, 注意力不易被拉走, 速度當然會快很多. 更不要說彼此的互相交流所帶來的成長了.

如果我有機會做老闆, 我絕對投pair programming一票.


reply to postreply to post
作者 Re:一個既有的系統想要進行architecture的調整,你們認為該怎麼做比較好呢? [Re:arthuroy]
singlelog

換回來



發文: 416
積分: 6
於 2003-10-08 15:40 user profilesend a private message to usersend email to singlelogreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
arthuroy wrote:
這點我們倒有切身之痛,pair programming 的結果常常變成上面會質疑: 你是不是有 cover 對方的工作 (嗯 難不成所謂的 teamwork 是喊假的嗎? 原來特種部隊間是不能互相 cover 的,電影上喊「covering fire」或是「cover me」是好萊塢憑空想出來的... bah!)。 現在台灣的環境不適用 pair programming,要做也只能私底下做不能講出來;現在業界要的人是能單打獨鬥的那種 teamwork,也就是專業不能重疊。

換句話說若是一男一女 pair programming 變男女朋友,到時公司就會想盡辦法將這兩個拆開;二個男的或是二個女的也是會要求某一個去處理另外的事務 - 反正就是「不能兩個人做一件事」就對了....what can I say?

這種情況可能會改善,可是可能要等到各位還在唸書的朋友們已經開始工作了,還是小工程師的人變成主管了,才會有所改變吧。Sad

在那之前,只好先把cover me當成是拿條棉被幫我蓋起來,我們來玩蓋棉被純聊天的遊戲。所以只能私底下做不能講出來,嗯,難怪會變男女朋友。

咦,不是啦。在時空環境轉變之前,可以先小規模地在工作上試驗。不過要可以不吵到別人的話,可能比較難。因為可能有蠻多公司都是開放式隔間,而開發軟體其實需要安靜地思考。可以考慮做做peer review,小組成員之間相互幫忙review。或是follow標準的review流程。

不過如果真的要review的話,所有參與review的人都應該事先看過要被review的東西,並且寫下大致上的觀點。再集中起來討論,不然就應該延後review的時間,或是讓review的參與人變少。像是code review如果沒辦法做peer review的話,就讓program manager,或是developer lead來review別人的code就好了。當頭頭的人本來就會比較累,只是這樣子做,知識還是只會keep在特定成員上。


singlelog edited on 2003-10-08 15:46
reply to postreply to post
我的書:專案管理Happy書!

我的網站:diggirl.net

my blog http://tinyurl.com/36gcye
作者 Re:一個既有的系統想要進行architecture的調整,你們認為該怎麼做比較好呢? [Re:Biologic]
arthuroy





發文: 106
積分: 3
於 2003-10-08 15:50 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
Biologic wrote:
關於人力的流動, xp 的 knolwedge exchange, pair programmer strategy, 不知道有沒有幫助?


至於 knowledge exchange,就是 software engineering 中會提到的 group memory,基本上 source repository 要先建立起來 (CVS 才是王道呀 Big Smile ),之後 forum 這類的機制也需要。

這裡指的 forum 比較傾向用於專案特定主題的討論,比較不建議像是 JSPTW 這樣專業分類的 forum。怎麼說呢? 專業性的論壇若是只給一個部門 (5-10 人在同一地點工作) 結果還是會變成用語言溝通 (用說的);此外,要討論研究技術,還不如來 JSPTW 會更有效果點。

專案特定的 forum 主要是適用於跟 外包廠商 和 客戶 間的溝通,當然這還是要推廣的,不是架設了就有人會用,是需要有管理的 (至於管理模式請參見 JSPTW 的模式)。使用 forum 可以免除 email 難以管理的缺點 (要選多個 addresses,forward 來、reply 去的,總是會掉芝麻...)。

而 forum 上的討論到某個階段還是需要加以整理彙總變成專案的知識或是日後相關情況的參考資料 - 精華區是一種方式;我個人是建議使用 Wiki 這類的工具做整理。當然別忘了整理過後的文件還是要放一份到專案的 folder 裡進入版本控管的機制 (不管是 CVS 還是印出來放在一個真實的檔案夾中做未來歸檔用 - 嗯高層主管還是習慣看印出來的資料的,別忘了這點)。

一些需要持續追蹤的 issues 則是建議用 Mantis (Open-Source、PHP、良好的權限控管)、Rational ClearQuest (嗯畫面很難看,會造成心理上不想用而且又是 ASP+Applet+Crystal Report...bah!) 等等的 web-based issue tracking system。就我們的經驗,目前來說,使用者很高興我們能提供 Mantis 來做為 issue-tracking 和 release management 的工具。

然而,有了這些機制不代表就萬事 OK 了,沒有人花時間做系統管理/trouble shooting 的話也只是枉然 (談到這不由得要向各版主致敬了 - 這種管理論壇的工作通常在公司裡是不被承認有 performance 的,唉~)。

OK,總結一下: 針對「一個既有的系統進行architecture的調整」這類的專案,以下的機制仍然需要建立:

. 版本控管 及 版本釋出計畫指引
. 專案特定議題討論及結論整理
. 議題追蹤及回報機制

對於人力的流動也許毫無幫助 (team 的成功不代表公司跟該 team 能夠有共識),但對於 建立乃至提昇開發團隊的向心力 及 專案的管理 絕對有用。

以上也是在初期的階段應該進行的事宜...

----
離題真的太遠了 GOD....


reply to postreply to post
Self-Pity

I never saw a wild thing sorry for itself.
A small bird will drop frozen dead from a bough
without ever having felt sorry for itself.
作者 Re:一個既有的系統想要進行architecture的調整,你們認為該怎麼做比較好呢? [Re:aladdin]
singlelog

換回來



發文: 416
積分: 6
於 2003-10-08 15:53 user profilesend a private message to usersend email to singlelogreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
aladdin wrote:
Pair programming的另外一個好處就是專心, 現在電腦一打開, 誘惑太多, 隨隨便便上網(哦!該回去工作了!), 就可以掛個半天. Pair的時候, 就像是兩個人開會腦力激盪, 注意力不易被拉走, 速度當然會快很多. 更不要說彼此的互相交流所帶來的成長了.

如果我有機會做老闆, 我絕對投pair programming一票.

還好沒人說來個pair management,接著來跟我看同一台電腦,不然我就不方便到這裡來了。Big Smile嗯,只有開會時看會議記錄才會做這種事情。ccc

在大多數的企業裡面,組織觀念的改變,都不會是一夕之間。做在高位的人,會受到以前的工作經驗跟見識的限制啊。所以可能真的要等到阿拉丁當老闆囉。阿拉丁,努力一點吧。

咦,最近的討論又都離題了,反倒是一直在講冷笑話,鐵獅玉玲瓏已經退流行了說。嗯,看來我岔題的功力也是一流的。


reply to postreply to post
我的書:專案管理Happy書!

我的網站:diggirl.net

my blog http://tinyurl.com/36gcye
作者 Re:一個既有的系統想要進行architecture的調整,你們認為該怎麼做比較好呢? [Re:iampoya]
arthuroy





發文: 106
積分: 3
於 2003-10-08 15:55 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
iampoya wrote:
養出了一隻狼加一隻狽
要跑就跑一雙 XD


留不住人也不能怪他人擇良木而棲呀... 總不能一直叫大家過苦日子吧。每個專案 team 也是有背負著 quota,不僅是要養活 team 還要攤提公司的一些固定成本+股東權益不是嗎 Dead


reply to postreply to post
Self-Pity

I never saw a wild thing sorry for itself.
A small bird will drop frozen dead from a bough
without ever having felt sorry for itself.
作者 Re:一個既有的系統想要進行architecture的調整,你們認為該怎麼做比較好呢? [Re:arthuroy]
singlelog

換回來



發文: 416
積分: 6
於 2003-10-08 16:10 user profilesend a private message to usersend email to singlelogreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
arthuroy wrote:
專案特定的 forum 主要是適用於跟 外包廠商 和 客戶 間的溝通,當然這還是要推廣的,不是架設了就有人會用,是需要有管理的 (至於管理模式請參見 JSPTW 的模式)。使用 forum 可以免除 email 難以管理的缺點 (要選多個 addresses,forward 來、reply 去的,總是會掉芝麻...)。

而 forum 上的討論到某個階段還是需要加以整理彙總變成專案的知識或是日後相關情況的參考資料 - 精華區是一種方式;我個人是建議使用 Wiki 這類的工具做整理。當然別忘了整理過後的文件還是要放一份到專案的 folder 裡進入版本控管的機制 (不管是 CVS 還是印出來放在一個真實的檔案夾中做未來歸檔用 - 嗯高層主管還是習慣看印出來的資料的,別忘了這點)。

一些需要持續追蹤的 issues 則是建議用 Mantis (Open-Source、PHP、良好的權限控管)、Rational ClearQuest (嗯畫面很難看,會造成心理上不想用而且又是 ASP+Applet+Crystal Report...bah!) 等等的 web-based issue tracking system。就我們的經驗,目前來說,使用者很高興我們能提供 Mantis 來做為 issue-tracking 和 release management 的工具。

然而,有了這些機制不代表就萬事 OK 了,沒有人花時間做系統管理/trouble shooting 的話也只是枉然 (談到這不由得要向各版主致敬了 - 這種管理論壇的工作通常在公司裡是不被承認有 performance 的,唉~)。

OK,總結一下: 針對「一個既有的系統進行architecture的調整」這類的專案,以下的機制仍然需要建立:

. 版本控管 及 版本釋出計畫指引
. 專案特定議題討論及結論整理
. 議題追蹤及回報機制

對於人力的流動也許毫無幫助 (team 的成功不代表公司跟該 team 能夠有共識),但對於 建立乃至提昇開發團隊的向心力 及 專案的管理 絕對有用。

以上也是在初期的階段應該進行的事宜...

----
離題真的太遠了 GOD....

既然離題很遠,那乾脆就繼續下去好了。Big Smile

我們公司花錢買了clear quest && clear case。不過沒把這兩個東西整合起來,所以效用大失。理論上來說,bug tracing system應該跟version control system integrate起來,這樣要上patch,或是要產生新的release時,才不會挂一漏萬的。聽說這兩個東西是串的起來的,只是我們公司的人一直沒有花錢努力去上課,所以一直沒有學會。Sad所以 clear quest他們說應該叫做configuration management的tool。如果串得起來,倒也沒錯啦。

用forum的方式來處理,是可以分享資訊,可是如果有事情要follow的話,其實不太容易追蹤進度。我自己是很喜歡把bug tracing system拿來記錄所有要叫人家做的事情,或是想要追蹤status的東西。而不只是defect。

例如我們家有sales想要申請technical support,就當做這個人發一個defect,需要engineer去support,接著leader再assign一個人去做,做完了就把defect close掉。所有的information都在裡面,管理起來就容易多了。有時候,想要叫誰做一件什麼事情,就發一個defect然後assign給他。做完了以後,也很好查status。到了客戶端,叫出web based interface,dynamic下一個query,一定會贏來一陣讚嘆。

知識的分享,這真是比較難的事情。我總覺得,光有機制是不夠的,內容的規劃跟refine,以及持續的training,才能讓這件事情做好。我總覺得跟IT有關的東西有很多是需要大量的example。有了example,或是第一個version,才能有討論的base。當討論有了結過,這時候就要定出 common的template跟golden samples.

咦,好可怕啊,再這樣下去,我一些壓箱的法寶都會被套出來,這樣下去怎麼維生呢?

--------------------------------------------

持續離題並且把這裡當成是灌水版的獨孤木......


singlelog edited on 2003-10-08 16:17
reply to postreply to post
作者 Re:一個既有的系統想要進行architecture的調整,你們認為該怎麼做比較好呢? [Re:arthuroy]
Biologic

生物學下的產物



發文: 524
積分: 4
於 2003-10-08 16:42 user profilesend a private message to usersend email to Biologicreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
arthuroy wrote:
至於 knowledge exchange,就是 software engineering 中會提到的 group memory,基本上 source repository 要先建立起來 (CVS 才是王道呀 Big Smile ),之後 forum 這類的機制也需要。

這裡指的 forum 比較傾向用於專案特定主題的討論,比較不建議像是 JSPTW 這樣專業分類的 forum。怎麼說呢? 專業性的論壇若是只給一個部門 (5-10 人在同一地點工作) 結果還是會變成用語言溝通 (用說的);此外,要討論研究技術,還不如來 JSPTW 會更有效果點。

專案特定的 forum 主要是適用於跟 外包廠商 和 客戶 間的溝通,當然這還是要推廣的,不是架設了就有人會用,是需要有管理的 (至於管理模式請參見 JSPTW 的模式)。使用 forum 可以免除 email 難以管理的缺點 (要選多個 addresses,forward 來、reply 去的,總是會掉芝麻...)。

而 forum 上的討論到某個階段還是需要加以整理彙總變成專案的知識或是日後相關情況的參考資料 - 精華區是一種方式;我個人是建議使用 Wiki 這類的工具做整理。當然別忘了整理過後的文件還是要放一份到專案的 folder 裡進入版本控管的機制 (不管是 CVS 還是印出來放在一個真實的檔案夾中做未來歸檔用 - 嗯高層主管還是習慣看印出來的資料的,別忘了這點)。

一些需要持續追蹤的 issues 則是建議用 Mantis (Open-Source、PHP、良好的權限控管)、Rational ClearQuest (嗯畫面很難看,會造成心理上不想用而且又是 ASP+Applet+Crystal Report...bah!) 等等的 web-based issue tracking system。就我們的經驗,目前來說,使用者很高興我們能提供 Mantis 來做為 issue-tracking 和 release management 的工具。

然而,有了這些機制不代表就萬事 OK 了,沒有人花時間做系統管理/trouble shooting 的話也只是枉然 (談到這不由得要向各版主致敬了 - 這種管理論壇的工作通常在公司裡是不被承認有 performance 的,唉~)。

OK,總結一下: 針對「一個既有的系統進行architecture的調整」這類的專案,以下的機制仍然需要建立:

. 版本控管 及 版本釋出計畫指引
. 專案特定議題討論及結論整理
. 議題追蹤及回報機制

對於人力的流動也許毫無幫助 (team 的成功不代表公司跟該 team 能夠有共識),但對於 建立乃至提昇開發團隊的向心力 及 專案的管理 絕對有用。

以上也是在初期的階段應該進行的事宜...

----
離題真的太遠了 GOD....


有個問題是: 對於小公司而言, 建立一個 forum 本身被使用的程度不高. 那到 public forum 這對公司的風險太高... 這個 forum strategy 豈不是沒有用?

我在想說, pair programming 在 small group 中也可以扮演著這種角色. 也可以利用相互交叉的方法達到最高的 knowledge sharing.


reply to postreply to post
go to first page go to previous page  1   2   3   4   5  go to next page go to last page
» JWorld@TW »  Software Engineering

reply to topicthreaded modego to previous topicgo to next topic
  已讀文章
  新的文章
  被刪除的文章
Jump to the top of page

JWorld@TW 本站商標資訊

Powered by Powerful JuteForum® Version Jute 1.5.8