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:Biologic]
arthuroy





發文: 106
積分: 3
於 2003-10-08 16:58 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:
有個問題是: 對於小公司而言, 建立一個 forum 本身被使用的程度不高. 那到 public forum 這對公司的風險太高... 這個 forum strategy 豈不是沒有用?


的確是這樣,所以我提到說實務上建立的 forum 會比較傾向用於專案特定主題的討論做為跟外包廠商和客戶間的溝通機制

當然 strategy 會有一些前提,例如十萬元網站外包的案子為其建立一個 forum system 合不合用? 其實我們這樣想,forum strategy 是長期性的,不是為單一案子為成立的,單一案子在這個 forum system 中也許只是某一個討論區 (例如 JSPTW 要開發一個 open-source based extension 時,會另外開一個專門的討論區來進行 release or development discussion)。

public forum 主要是針對技術上問題的討論,要避開一些商業上的機密吧,我想。其實這就跟公司對 open-source solution 抱有一種不信任感是同樣的道理 (就說 JBoss 當做開發環境了,到時再上到 WebSphere/WebLogic 去做整合測試了呀,這樣也不行喲?)

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


的確 knowlegde sharing 可以達到,只是我們會希望能把範圍擴大,不是只有 pair programming 的這兩個人。除了 sharing 之外,也會希望能變成整個 team 的 know-how。

----
嗯 不知道 Jute 能不能把某些 posts 移出變成一個新主題,不然這樣下去 - 「一個既有的系統想要進行architecture的調整」怎麼進入下一個 phase 的討論呢 Disapproved


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:Biologic]
ming215





發文: 143
積分: 2
於 2003-10-08 17: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:
關於人力的流動, xp 的 knolwedge exchange, pair programmer strategy, 不知道有沒有幫助?


pair programmer .........
那都是理想值吧..當每個人都有自己的事情必須加班到三更半夜時..誰還有餘力搞這些東東...Sad 那是要事後再來討論這些 code 嗎?......又要再把需求說一遍..說到另一人了解..然後會變成..2 個沒進度的人...於是再努力加班追回進度..

正常情況下, 老闆當然會覺得..為什麼一件事要 2 個人..那是原作的人能力不行..所以需要另一個來幫忙? 還是另一個什麼都不會..所以要跟人家學習?
人力=金錢........cost..........

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

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


通常還會有小團體的出現..向心力不夠時....彼此互吐苦水..結論是一起閃..
亦或是一個帶一個(一串)走...然後留下欲哭無淚的pm...Black Eye

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

不錯的方法, 但要先建好醬子的機制... = ="..呃... 放眼望企..目前沒人力..
而且..有些technical support還是要經過討論的..不如直接用喊的..人就來討論了..只是會變無法追蹤進度(因為都忘光光)

arthuroy wrote:
. 版本控管 及 版本釋出計畫指引


.........這又是另一門學問了..........要有好用的工具..要有人願意配合.....要有時間........................最好是有專人控管...

----------------------------------------------------------
反正離題了~~開始胡言亂語 Big Smile

照片哦....看這張 Big Smile


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

換回來



發文: 416
積分: 6
於 2003-10-08 17:21 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:
(就說 JBoss 當做開發環境了,到時再上到 WebSphere/WebLogic 去做整合測試了呀,這樣也不行喲?)

我覺得不行耶。不同的application server會有一些細微的不一樣,早期發現早期治療。integration testing還有development environment應該跟production越相近越好。

回應括號裡面的話,會不會很奇怪?

arthuroy wrote:
的確 knowlegde sharing 可以達到,只是我們會希望能把範圍擴大,不是只有 pair programming 的這兩個人。除了 sharing 之外,也會希望能變成整個 team 的 know-how。

可是pair programming 是兩個人同時盯著螢幕在思考跟討論,放在forum上效果就沒這麼好了。我是覺得真的有用的東西,是需要花時間去討論的。規律性的討論跟review應該還是會是需要的。

arthuroy wrote:
嗯 不知道 Jute 能不能把某些 posts 移出變成一個新主題,不然這樣下去 - 「一個既有的系統想要進行architecture的調整」怎麼進入下一個 phase 的討論呢 Disapproved

不曉得,不過你們可以另外起一個主題來討論啊。Smile


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

我的網站:diggirl.net

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



版主

發文: 90
積分: 1
於 2003-10-08 17:37 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
ming215 wrote:
通常還會有小團體的出現..向心力不夠時....彼此互吐苦水..結論是一起閃..
亦或是一個帶一個(一串)走...然後留下欲哭無淚的pm...Black Eye


不不, XP 的信徒會告訴我們, 用了 Pair Programming 之後, 生產力大增,
那裡會有苦水好吐 :p

Pair Programming 雖然是搭檔進行. 不過對於搭檔的選擇也是有條件的,
比如說, 大家要輪流搭檔, 不能存在老是你一個人罷佔著某美女之類的事
發生.

也只有這種隨時都更換搭檔的方式, 才能將系統中的各種隱晦之處, 慢
慢擴散開來.


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

Speculator

版主

發文: 169
積分: 8
於 2003-10-08 17:38 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:
持續離題並且把這裡當成是灌水版的獨孤木......

塵歸塵、土歸土
讓灌水回到灌水板吧∼
歡迎大家來灌水板開新討論串

--
米花市長生意興隆
忍不住想來搶生意
恐龍妹(姐?)就不用哩,請您好好在DP板壓陣就行囉∼


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

換回來



發文: 416
積分: 6
於 2003-10-08 17:43 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:
pair programmer .........
那都是理想值吧..當每個人都有自己的事情必須加班到三更半夜時..誰還有餘力搞這些東東...Sad 那是要事後再來討論這些 code 嗎?......又要再把需求說一遍..說到另一人了解..然後會變成..2 個沒進度的人...於是再努力加班追回進度..

當然啦,還是要看專案跟team member特性啦。對於每個人都很熟悉的系統來說,可能分開工作會比較有效率。

不過一開始沒做對,後面再花很多時間test/debug/fix,跟一開始就想清楚,然後做對了,不要睡眼惺忪地加班,哪個比較好?雖然看起來加班加的很辛苦,老闆會覺得有在做事情。Tounge

ming215 wrote:
通常還會有小團體的出現..向心力不夠時....彼此互吐苦水..結論是一起閃..
亦或是一個帶一個(一串)走...然後留下欲哭無淚的pm...Black Eye

這可是個不好的循環啊。

ming215 wrote:
不錯的方法, 但要先建好醬子的機制... = ="..呃... 放眼望企..目前沒人力..

像是bugzilla這種東西是open source的,找人架起來應該還好吧?(沒架過,不知道。我們家有人會裝clear quest,只要出一張嘴就好了...有種幸福的感覺。)


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

我的網站:diggirl.net

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

Speculator

版主

發文: 169
積分: 8
於 2003-10-08 17:45 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
qing wrote:
Pair Programming 雖然是搭檔進行. 不過對於搭檔的選擇也是有條件的,
比如說, 大家要輪流搭檔, 不能存在老是你一個人罷佔著某美女之類的事
發生.

石榴裙下必有猛狼乎∼
結論:XP果然是講求人性呀∼

--
qing大大您好
看到大大就狗腿好像已經變成我的自然生理反應了 XD


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

換回來



發文: 416
積分: 6
於 2003-10-08 17:49 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
qing wrote:
不不, XP 的信徒會告訴我們, 用了 Pair Programming 之後, 生產力大增,
那裡會有苦水好吐 :p

生產力大增還是會有苦水可以吐啊。

功力變強了更受不了老闆的白爛,所以趕快徹夜逃跑。

要把灌水的thread從這裡搬到灌水版?這難度太高了,才用沒多久,不會用這麼高深的技巧。Smile

卯起來繼續灌。


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

我的網站:diggirl.net

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

塵世中一個迷途小書僮

版主

發文: 874
積分: 22
於 2003-10-08 18:09 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
qing wrote:
不不, XP 的信徒會告訴我們, 用了 Pair Programming 之後, 生產力大增,
那裡會有苦水好吐 :p

Pair Programming 雖然是搭檔進行. 不過對於搭檔的選擇也是有條件的,
比如說, 大家要輪流搭檔, 不能存在老是你一個人罷佔著某美女之類的事
發生.

也只有這種隨時都更換搭檔的方式, 才能將系統中的各種隱晦之處, 慢
慢擴散開來.


請問你是寫過"進去和出來"的那個qing嗎? (分析java io架構的文章)
如果沒錯的話, 久聞大名...小弟一直很景仰你 <(_)(_)>
那幾篇文章真是受益良多!


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





發文: 106
積分: 3
於 2003-10-08 18:30 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:
既然離題很遠,那乾脆就繼續下去好了。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.

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

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

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


Agree,所以我們會用 issue tracking 而不只是談到 bug (or defect) tracking。

ClearCase 與 ClearQuest 這兩項東西在價格上面我想一般的小公司也沒法取得使用;加上 ClearQuest 的畫面又不太美觀,實在是降低本身使用的意願,另一方面也怕客戶看了會覺得真是不夠專業。派人出去學也只能學到 system administration,在真正實際使用上 (諸如: release mechanism) 還是需要實際使用的人去操作... 功能的更新上我想一些 open-source solutions 說不定還比較快 - 這點用過 Rational Rose 的人可以了解到 - Rose 對一些 UML notations 的支援進行的很緩慢,比不上 Jude 或是 ArgoUML。

關於 bug tracking 跟 version control 的整合方面,也的確是我們在想辦法解決的問題。日前不小心掛網時看到 CVSTrac: A Web-Based Bug And Patch-Set Tracking System For CVS,在此提供有興趣的人參考一下吧。

Anyway,工具的使用需要經驗與管理上妥善的配套措施,就看各 PM 的決心 (或是要推卸責任給公司也行)。光有機制是不夠的,內容的規劃跟refine,以及持續的training,才能讓這件事情做好。 --- singlelog

啊...一時不察,把壓箱法寶上面蓋的布揭開了...我的潘朵拉盒危險了...

--------------------------------------------
嗯 到時整理結論,singlelog 兄您就知道這個離題問題大了....
所以專案開發不要做 RD 的工作 我好像慢慢能了解了 Tounge
就此打住目前的討論? 回歸原來 ming215 的提案?


arthuroy edited on 2003-10-08 18:39
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]
arthuroy





發文: 106
積分: 3
於 2003-10-08 19:03 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:
arthuroy wrote:
(就說 JBoss 當做開發環境了,到時再上到 WebSphere/WebLogic 去做整合測試了呀,這樣也不行喲?)

我覺得不行耶。不同的application server會有一些細微的不一樣,早期發現早期治療。integration testing還有development environment應該跟production越相近越好。

回應括號裡面的話,會不會很奇怪?


主要的原因是因為: 雖然在每個 developer 的桌上型電腦/Notebook上面架設 WebSphere/WebLogic + Oracle/DB2 也無妨 (license issue 如果不是問題的話),問題是這樣會演變成「必須在公司加班才有這種環境」(什麼? 架在家裡的電腦上? 嗯,可行性不高吧);就算架了也還是會有模組整合上的問題 (如果 PM 的 notebook 也架起來, demo/presales 時跑的動我也沒話說了)。

我們只希望讓 developer 能在在家想到要寫程式時能夠有一個環境 (這也是為什麼用 CVS 來做程式控管的一點因素,以前 VSS 不能跨 internet,不知道新版本解決了沒?) 能做基本的測試 - 如果在家不想做,我想來公司加班也不一定會乖乖地做,畢竟網際網路是迷人的。的確「早期發現早期治療」是要注意的事項,在這方面我們是盡量請 developer follow 工業標準再配合一些 tools (如 Ant, XDoclet, OR mapping engine) 來改善這些 vendor-specific issues;或許不能百分之百省力,但是至少我們是有在注意這點問題... 利用這種方式,以前在處理 Tomcat / Websphere 4.x 時就特別做出了處理 WAS 的一些 classes 與 deployment descriptors。

能做出來這樣也好,免得公司又想大小通吃時 (用 tomcat + JBoss + MySQL 的解決方案時),會由奢入簡難 Tongue

那我回應「回應括號裡面的話」,會不會更怪?

singlelog wrote:
可是pair programming 是兩個人同時盯著螢幕在思考跟討論,放在forum上效果就沒這麼好了。我是覺得真的有用的東西,是需要花時間去討論的。規律性的討論跟review應該還是會是需要的。

不曉得,不過你們可以另外起一個主題來討論啊。Smile


Agree,peer review/code review 還是需要的...只是真的很累人 - 名言: 「當頭頭的人本來就會比較累」 by singlelog。就像是在 forum 上發問,最後要做結論把解決方案分享出來一樣...累,但是是必須的。


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 19:30 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:
主要的原因是因為: 雖然在每個 developer 的桌上型電腦/Notebook上面架設 WebSphere/WebLogic + Oracle/DB2 也無妨 (license issue 如果不是問題的話),問題是這樣會演變成「必須在公司加班才有這種環境」(什麼? 架在家裡的電腦上? 嗯,可行性不高吧);就算架了也還是會有模組整合上的問題 (如果 PM 的 notebook 也架起來, demo/presales 時跑的動我也沒話說了)。

咦,我家的人都裝環境在notebook裡面說。programmer卯起來自己在家就可以改。公司不同果然差很多。Tounge

arthuroy wrote:
就像是在 forum 上發問,最後要做結論把解決方案分享出來一樣...累,但是是必須的。


咦,這個暗示很明顯喔。其實我剛剛在騎機車回家時,還在想說應該要整理一下目前討論的東西說。看來跑不掉了。Smile


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

我的網站:diggirl.net

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

Norman

版主

發文: 1073
積分: 5
於 2003-10-08 22:42 user profilesend a private message to usersend email to snpshureply 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:
咦,我家的人都裝環境在notebook裡面說。programmer卯起來自己在家就可以改。公司不同果然差很多。Tounge


老闆果然大手.. notebook要跑那些程式就是第一個困擾,版權就是最實際的囉!


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

換回來



發文: 416
積分: 6
於 2003-10-08 23:27 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
snpshu wrote:
老闆果然大手.. notebook要跑那些程式就是第一個困擾,版權就是最實際的囉!

你誤會了,我們公司想了不少方法來解決開發上license的問題啊。


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

我的網站:diggirl.net

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





發文: 277
積分: 4
於 2003-10-08 23:37 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
現在很多軟體開始賣 developer license...選擇性應該會越來越多吧~~~

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

老婆不准我用兒子照片



發文: 175
積分: 3
於 2003-10-09 00:14 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
ming215 wrote:
pair programmer .........
那都是理想值吧..當每個人都有自己的事情必須加班到三更半夜時..誰還有餘力搞這些東東...Sad 那是要事後再來討論這些 code 嗎?......又要再把需求說一遍..說到另一人了解..然後會變成..2 個沒進度的人...於是再努力加班追回進度..


當年大學乙組程式設計比賽的方式,是六個小時之內要做五題不算小的問題,只能帶入會場一台電腦。我記得大四那年的題目有一題是寫一個可以迴圈、可以print的簡單pl interpreter(最後要能讓評審輸入一段印出九九乘法表的程式)。其他的題目大概也都是同一個水準的。六小時哦!我們這一組四個人兩年都是滿分。

當我們開始使用這個模式練習的時候,很奇怪的事情發生了:首先,真的一台電腦是夠的,因為在紙上planning的時間突然就增多了。另外,coding的時候,常常是兩個人喃喃自語,把程式碼念了出來,如果兩個人念得不一樣,立刻就停下來討論是觀念的錯誤還是記錯了變數名稱之類的小問題。正式比賽的時候,都是上機coding->換另一組人上,我們印程式抓bug->改bug->完工。最多兩次抓bug就交卷(不然六小時哪寫得完?)而有時候練習我們也會回到從前單獨一人coding的方式,發現效果就是沒那麼好,整個流程總要跑個四五次,整體下來反而不如兩人一組用的時間少。

我們自己事後,都對這種方式寫程式的效率覺得不可思議。我自己個人是覺得,寫程式是一個蠻需要記憶力的工作,變數名稱、class的名稱、class的用法,這些東西即使每天在用,都不能保證每次都用對,兩個人分擔這種查核的工作應該是比一個人要好。而且,真的,碼的品質好非常非常多。


正常情況下, 老闆當然會覺得..為什麼一件事要 2 個人..那是原作的人能力不行..所以需要另一個來幫忙? 還是另一個什麼都不會..所以要跟人家學習?
人力=金錢........cost..........


我覺得是因為大家在從前的經驗裡,真的沒有用過這種方式配合寫程式。我記得大四那年,修台大資工研究所的專題,工作分配完了,就各自走人,下次meeting的時候,再交code,然後 leader 試著整合。相信這種場景大家一點都不陌生——湊到一起,才發現很多細節溝通錯誤。於是,常常兩三個星期都沒什麼進度。

由於我是和我比賽的一個partner一起修這個課,我還修了水泥數學,作業超多,所以,我們講好是每個星期找一個固定的時間上機(Vax850)把作業搞定。結果,每次都是我們在coding的時候把spec中的矛盾找出來,然後到樓上找助教(也就是project leader)。到後來,meeting的時候,只要問這次的工作進度有沒有什麼細節上的錯誤,所有人都知道要問的人是誰。所以,我和我的partner的專題是98分。

兩年前接觸到xp,才知道原來這叫做pair programming。我工作以後,做freelancer的時間比待在公司裡多,因此沒有機會再經歷這樣的開發方式,所以,細節面我也不敢說是不是真的比較好。而且我們當初那群partner,從高中社團的學長學弟一起混到大學,默契也真的是比一般人好。所以,這樣的經驗如何複製,老實說,我自己也沒有再經歷過,也沒試著要去重現。再加上現在的工作是業主(也就是驗收付錢的人),大概也不容易有這種經歷了吧!


通常還會有小團體的出現..向心力不夠時....彼此互吐苦水..結論是一起閃..
亦或是一個帶一個(一串)走...然後留下欲哭無淚的pm...Black Eye


站在management的角度上來說,每個人呆在他現在的工作上,都有許多歷史的理由:薪水還好、遇到不錯的project leader、小孩剛出來不敢動、甚至只是因為對面公司有個妹妹長得還不錯...。management的目的不是要把每個人凍結在這個公司裡,因為有太多的因素你沒有辦法manage。加重某種誘因(薪水、負擔、發展性、工作文化)也許在其他方面失去的更多,有些老闆會強調公平性,但卻讓組織變得有些沒效率;有些老闆強調效率,但因此發生的人員流動,其成本也許反而會讓整體表現不如一個強調公平的組織。而且,你還有自己的風格——就像我是個好心人,但卻永遠會在外人面前說錯話——這是沒辦法強求的,但好的組織,會隨著時間經過以後,達到一個平衡。沒有那個平衡點,一些外界的簡單刺激,就可能讓整個組織翻掉。

Management,其實就是:一、如何趕快讓這個組織到達一個平衡點,二、怎麼讓這個平衡點在你想要衡量的這些「領域分數」中向上提升。第二點的「領域分數」的選擇,就會形成公司的價值觀。你如果覺得向心力是你重要的「領域分數」,你就會注意影響這些事情的所有可能條件,然後採取一些行動;但你的所有行動都有副作用,因此有些人覺得不公平(比如要求其他人互相cover工作),所以,組織又開始流動,有些人離開,有些人加入,然後,組織到達一個新的平衡。你又開始下一階段的evaluation和改變...

當然,有些企管專家告訴我們:不要 manage,要 lead!我自己的心得是:我就這麼點材料,再囉唆我就繼續做freelancer!

說了這麼多,該辦的正事都沒做。網際網路真是害人不淺!繼續寫作業去了!


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

換回來



發文: 416
積分: 6
於 2003-10-09 01:21 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
問題:

你現在的工作是要把一套系統從Notes轉到J2EE下面,你是一個project manager,你在進行planning時,有什麼該特別注意的地方呢?

1.這種調整architecture的案子,跟一般全新的專案有什麼不一樣呢?
2.有什麼risk是要特別注意的呢?
3.假設如果要整個案子porting到J2EE下面,根據你的估計,整個做完要花兩年,三千萬。客戶說,我們今年只有一千萬,明年後年還各有一千萬。在這種預算有限的狀況下,你會建議客戶怎麼做?
如果要分期上線,你建議怎麼區分不同的release?依功能面,還是照其他的層面?對他們最大的效益是什麼?
分好幾個phase(大的iteration)來release的話,會有什麼要考慮的?

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

背景說明:

1你面對的系統,沒有up-to-date 的design document,只有一套正在running 的系統。

2.user除了想要把現有系統的功能轉過來以外,還想包一些enhancement在scope裡面。這些系統因為現在還在operate,所以得要考慮data migration,也要考慮怎麼做parallel run。

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

參考答案(截至目前為止的回應加上我自己的參考答案)

1.1 沒有現成的design,那麼在做頭一個release時,會需要做現有系統的reverse engineering。
關於reverse engineering應考慮下列問題:
•  reverse engineering會不會遇到什麼困難?
•  有沒有什麼tool?
•  要花多少effort?
•  有沒有適當的人選可以做這件事情?
•  如果沒有的話,有沒有什麼backup plan?
•  risk高不高?
•  這在第一個release是否是個must?

提到backup plan,resource不足時,除了找外界的人來輔導內部員工以外還可以考慮外包。關於外包應考慮下列問題:
•  你要找幾個外包?
•  你找得到這些外包商嗎?
•  怎麼把東西包出去給他們?彼此之間要怎麼切割?
•  如果包出去,可是有人結不了案怎麼辦?
•  包給5個外包商,中間良莠不齊,有幾個永遠沒辦法準時交件時,你的plan是什麼?
•  你又要怎麼樣去管理這些外包?有沒有什麼明確的management plan& mechanism?
•  risk會不會太高?

1.2 integration test時間與scope應該要足夠cover夠多的scenario。

1.3 除了integration test以外,還應該要規劃平行測試與平行運轉時間。這幾個item應該會在schedule上面有顯著的影響。

1.4 應該要特別注意data migration相關規劃。schedule應該要包含完整的分析資料/測試程式的時間。(離題一下,data migration的程式,應該先對轉出的資料格式進行嚴格的檢查。很多系統的資料都不乾淨。需要整理。)

project一開始,對於data migration的planning一定不清楚,應該要在data migration測試開始進行時,重新review data migration schedule以及launch schedule。那時應特別依據data 的volume推估migrate資料實際會耗費的時間。

如果每個phase都需要migrate data,migrate data的順序性,應該在initial planning時勾勒出方向,detail等到data migration相關utility開始implement時,需要重新檢討這個plan。

1.5 分多次release,開發經費會往上竄升。主要是因為project duration會因此而拖長,change request會進來的機率也會變高。而每次要給user做UAT,都會有相衍生的cost會發生。如果一次做要做三年的東西,分成三個phase去做,時間可能會拉長為4~5年。經費可能會升高為於原有的兩倍以上。

要考慮建立測試環境可能會衍生的成本。在第二年你的問題會變成是,1.要解頭一年上線系統的bug。2.要開發新系統。這可能需要兩組人。(這是另一個經費往上升的原因)。

你有新系統,也有舊系統,這是頭一個phase的狀況。到了phase 2,你有phase 1做好的系統,跟phase 1時改成可以跟新系統talk的舊系統,還有phase 2想要取代的新系統。在你在做測試的時候,已經在operate的東西如果出問題還要有地方測試。這時候可能會有很複雜的測試環境問題。

需要測試環境,就要準備相對應的軟硬體。會同時需要多個測試環境,有很多個測試環境,就要有人專門來負責管理這些環境。這通常也是另一個時間跟金錢會往上攀升的原因。所以建置測試環境所需要的時間/人力/成本,應該做通盤規劃。

1.6 如果team不大,可以考慮採用下列方法來plan resource。
對於小team來說,分工要分的很清楚確實比較困難。遇到這種狀況能做的,不是先預測有沒有人會走,有沒有沒有經驗的人會來,通常是會先去搶想要的人頭。接著開始plan sunny day scenario。

先假設已經被抓到,確定會進來的人都會待到結案,需要的人都會出現。算出來的schedule還有經費乘以一個倍率。(我建議考慮乘以2以上的數字)得到的數字,是你的底線。
各種event,遇到了再說。

1.7 最後這點最重要。每一個phase有沒有清楚明白地定義出跟其他phase無關的驗收標準。(最好是不要環環相扣喔,否則會影響cash flow喔。)

2.1 如果這是個non-stop mission critical的案子,光是這一點就是high risk。

2.2 沒辦法一個phase做完,所以一定會有新舊系統並存的時刻,這需要特別考慮兩套系統並行的問題。這會是一個很大的risk。

Design/review時,應特別著重在兩者介面是否規劃清楚。Integration test時間與scope應該要足夠cover夠多的scenario。此外,如果兩套系統的技術差異很大,例如從cobol轉成j2ee,那麼有沒有相關的人才就會有很大的影響。

2.3 data migration所需要migrate的data volume如果很高,schema又很複雜,risk就會跟著很高。

2.4 第一個phase因為要做reverse engineering,data migration,還有新架構的建置與部份程式的開發,所以resource usage與schedule都很有可能會是high risk。

2.5 如果這是個pilot project,technical上的未知也很多,那麼技術上也會是high risk。最好先做技術上的POC(proof of concept),確定想法確實可行。

3.1 先假設三年分三個phase launch。開發期間可能會有小的release,會有小的iteration。不過為了討論上的方便,這裡通通用waterfall的方式來討論。主要會從release給客戶的時間來推敲。

3.2 因為user頭一年只有一千萬的經費,要拿到這筆錢,通常就得要有一個可以驗收的東西。所以頭一年最少要有一個release可以上線。

3.3 integration test,parallel run加上unit test,對於這種轉換architecture的系統來說,可能要預留50%以上的時間進行測試。

3.4 一開始做planning/sa時,architect/designer應該要開始建立architecture baseline,並做出一些proof of concept。

3.5 通常第一個phase最難做,因為包含了reverse engineering跟data migration,這是一定會吃resource的。所以可以deliver的東西最少。可是user也最想要在第一個phase看到不一樣的東西。所以建議scope時的溝通是很重要的。

如果第一個release要給user覺得花錢是有回報的,可能是要把一些user覺得比較critical的enhancement放進去。不過這可能會影響第一個phase的schedule。這也是在第一個階段要討論,跟user達成共識的東西。

可是如果你保留了50%的時間進行測試,通常也表示只有50%的時間留給SA/SD/Coding。如果一開始做SA時,designer同時也在做POC,那麼SA+SD應該要佔30%+的時間,coding大概就只有20%-的時間。

user可能會希望enhancement先上,特別是這種經年累月的系統,通常會有很多可以改善的地方。

可是加入越多現在不存在的功能,在phase 2, phase 3提出新的change request的機率也會變高,並且在第一個phase的loading也會重很多。除了migrate data/reverse engineering/parallel run以外,還要跟user敲requirement,確定新的feature,並且經過漫長的測試期間。這樣overall的risk會變高。

在客戶滿意跟降低風險之間,通常得要有一個平衡點。我建議透過市場機制來解決這個兩難。也就是說,同樣的功能在不同的phase做,其實成本是不一樣的。

當你把問題的複雜程度攤開來以後,那時得要跟客戶討論經費跟schedule的部分。你要漲價,得要有一番道理。最少目前常見的定價策略都是成本(人月*薪水)加上固定成數的利潤 = 報價。而我的看法基本如下:

在phase 1做,可能你底層的架構還沒調整好,就要硬著頭皮去寫,這樣成本應該會比較高。在後面的phase來做,成本會變得比較低。最少你手上可能已經有一堆東西可以參考/reuse了。所以在不同的phase implement的話,收不同的價錢,看user要那個phase上。反正重賞之下必有勇夫。收多一點錢,就擔多一些風險,這是天經地義的事情。

3.6 既然都會有新舊系統共存的問題,所以不一定是phase 1=>新舊共存,phase 2=>全部更新,phase 3 =>enhancement。實務上可能會在phase 1,2都有一些enhancement,而且即使到phase 2 launch,舊系統依然存在。這樣可以舒緩phase 1, 2的壓力,並且降低risk。

通常可以考慮by功能面切phase。除此之外,還可以考慮從architecture的角度來思考。例如原本是vb寫成的client server program,可以改成front end依然是vb,可是底層改用ejb…的方式去做。只是如果是從architecture的角度思考,還要做poc就是了。

照功能面切割的話,優先考慮,當然是商業面的問題。Business requirement優先。接著才是從技術角度出發。可以依照現有系統與系統之間的coupling還有dependency來思考。跟別人越無關的東西,可以越晚上線。越接近源頭的東西,越有關的東西,要在越前面的phase上線。

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

大概整理出這樣的summary。手軟了,眼也花了。中間可能有不少遺珠之憾,有興趣的人自己去看上下文。我自己可是很喜歡小飛俠不來嗯這個新譯名喔。

還有人有其他意見嗎?我自己回答其實是掰不出來這麼多。(主要是因為我還蠻懶的。Tounge)


singlelog edited on 2003-10-09 01:52
reply to postreply to post
我的書:專案管理Happy書!

我的網站:diggirl.net

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



版主

發文: 90
積分: 1
於 2003-10-09 23:13 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
Yoshi wrote:
請問你是寫過"進去和出來"的那個qing嗎? (分析java io架構的文章)
如果沒錯的話, 久聞大名...小弟一直很景仰你 <(_)(_)>
那幾篇文章真是受益良多!


啊, 被捉到了, 不打聲招呼好像也不好Tounge 為了避免有灌水之嫌, 我也寫
一下看起來不及格的答案好了 Smile

1.這種調整architecture的案子,跟一般全新的專案有什麼不一樣呢?

答: 使用者對於需求比一般全新的專案清楚很多. 他們知道過去系統能做什麼
事情, 而且對於長期以來, 這套系統所缺乏, 而他們所期待要有的需求, 也有
相當的概念. 所以, 對於捕捉需求來說, 會比一般全新的專案來得容易.

2.有什麼risk是要特別注意的呢?

答: 新的架構是否實際可行. 通常會先做 POC. data migration 的工作常常會被
忽略. 例如, 只叫一個小毛頭來做之類的. 對 development team 來說, 在這個
專案裡, 是不是擺進來太多新的東西. 例如不只是新的軟體架構, 甚至包括新的
開發方法論. 當然, 對任何專案來說, 放進愈多新的元素, 風險就愈高, 這是必
然的 -- 除非這個專案的目的就是要試驗.

3a.假設如果要整個案子porting到J2EE下面,根據你的估計,整個做完要花兩年,三千萬。客戶說,我們今年只有一千萬,明年後年還各有一千萬。在這種預算有限的狀況下,你會建議客戶怎麼做?

答: 要看客戶的心態而定. 成本, 時程, 品質, 和範圍四根桿子. 如果成本, 時程
, 品質都被固定住了, 那麼顯然可以調整的就是範圍. 客戶想放什麼東西在範
圍裡, 很難說. 通常系統必備的功能, 一定要放進來. 轉換架構後的效應,
也應該被彰顯出來. 可能是可容納 volume 變大了, 可能是效率變好了, 可能是
Web-based 化了, 很難說, case by case, 端視轉換架構的目的為何.

3b.如果要分期上線,你建議怎麼區分不同的release?依功能面,還是照其他的層面?對他們最大的效益是什麼?

答: 如 3a 的答案所述, 要看客戶的心態而定. 如果轉換架構的目的是為了效率,
那麼能夠在第一階段彰顯出效率的提升, 就是會最大的努力目標.

3c.分好幾個phase(大的iteration)來release的話,會有什麼要考慮的?

答: 在參考答案中寫的很好, 錢要收的到. 此外, 似乎還需要更細的 context
才能回答.


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

換回來



發文: 416
積分: 6
於 2003-10-10 09:54 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
qing wrote:
1.這種調整architecture的案子,跟一般全新的專案有什麼不一樣呢?

答: 使用者對於需求比一般全新的專案清楚很多. 他們知道過去系統能做什麼
事情, 而且對於長期以來, 這套系統所缺乏, 而他們所期待要有的需求, 也有
相當的概念. 所以, 對於捕捉需求來說, 會比一般全新的專案來得容易.

理論上是這樣啦,不過requirement collection通常最大的變因是SA的功力,跟整個系統的goal。我們公司最近有個新的大廠轉包下來的案子,客戶想把系統從client server轉到J2EE。
最簡單的方法是requirement照舊,先porting就好了。他們選擇requirement重談,結果SA做得實在不怎麼樣,人又走了一批了,只好找外包廠商支援人力。我們去了以後,發現前一手的人根本就沒做好分析的工作,deadline在即,真不知道他們該怎麼辦。還好我們是賣人頭的。Smile

qing wrote:
2.有什麼risk是要特別注意的呢?

答: 新的架構是否實際可行. 通常會先做 POC. data migration 的工作常常會被
忽略. 例如, 只叫一個小毛頭來做之類的. 對 development team 來說, 在這個
專案裡, 是不是擺進來太多新的東西. 例如不只是新的軟體架構, 甚至包括新的
開發方法論. 當然, 對任何專案來說, 放進愈多新的元素, 風險就愈高, 這是必
然的 -- 除非這個專案的目的就是要試驗.

用小毛頭來做,確實是很常見的現象。還好上次我叫個高手來幫我解data migration的問題,不然一定會砸鍋。
對很多主管來說,data migration是一件很簡單的事情。呆伯特裡面好像是這樣說的:『是不是你不懂的事物你都覺得很簡單?答是的人就是主管。』
data migration最難的地方,在於很少人會為了migrate data去做analysis,design...,通常在project初期也沒有人花太多時間去分析資料。通常都是在project中期,或是末期,才會發現一個大黑洞。整個task沒有well planned。risk被underestimated。這就是最大的問題啦。

qing wrote:
3a.假設如果要整個案子porting到J2EE下面,根據你的估計,整個做完要花兩年,三千萬。客戶說,我們今年只有一千萬,明年後年還各有一千萬。在這種預算有限的狀況下,你會建議客戶怎麼做?

答: 要看客戶的心態而定. 成本, 時程, 品質, 和範圍四根桿子. 如果成本, 時程
, 品質都被固定住了, 那麼顯然可以調整的就是範圍. 客戶想放什麼東西在範
圍裡, 很難說. 通常系統必備的功能, 一定要放進來. 轉換架構後的效應,
也應該被彰顯出來. 可能是可容納 volume 變大了, 可能是效率變好了, 可能是
Web-based 化了, 很難說, case by case, 端視轉換架構的目的為何.

3b.如果要分期上線,你建議怎麼區分不同的release?依功能面,還是照其他的層面?對他們最大的效益是什麼?

答: 如 3a 的答案所述, 要看客戶的心態而定. 如果轉換架構的目的是為了效率,
那麼能夠在第一階段彰顯出效率的提升, 就是會最大的努力目標.

3c.分好幾個phase(大的iteration)來release的話,會有什麼要考慮的?

答: 在參考答案中寫的很好, 錢要收的到. 此外, 似乎還需要更細的 context
才能回答.

Agree.

現在是在討論general situation下面一些需要注意的guideline。每個案子還是有他自己的特性。

嗯,qing果然是非常有名的大大。我也好景仰你喔。A...年紀大了做這種事情可能有點噁心。請準備好嘔吐袋。

哇賽,一個很嚴謹的討論主題居然已經快破百了,裡面灌水還灌得蠻少的,看來快要寫下歷史上新的一頁...咦,大多數都是我自己灌的。BlushBlushBlush


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

我的網站:diggirl.net

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

換回來



發文: 416
積分: 6
於 2003-10-12 01:50 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:
我們自己事後,都對這種方式寫程式的效率覺得不可思議。我自己個人是覺得,寫程式是一個蠻需要記憶力的工作,變數名稱、class的名稱、class的用法,這些東西即使每天在用,都不能保證每次都用對,兩個人分擔這種查核的工作應該是比一個人要好。而且,真的,碼的品質好非常非常多。

我只有很少很少的pair programming經驗,還是跟qing這種強人在一起玩,所以可能不是很好的例子。不過在我跟他在一起pair programming的經驗裡面,除了變數名稱...以外,我覺得最重要的是觀念上的溝通。主要也是因為我不會java,所以變數名稱、class的名稱、class的用法...這些我都幫不上忙。唯一能幫忙的,就是幫忙看看SQL對不對。

當兩個人的討論集中在演算法時,其實補掉很多潛在的漏洞。像qing這種大師,其實寫程式就沒有bug。所有的defect都是導因於requirement/design的不清楚。兩個人可以互相進行想法上的溝通與驗證,其實是很棒的經驗。

當他在向我開示extreme programming時,我直覺覺得如果你在做pair programming時,遇到一個完全無法跟上你腳步跟思路的人,可能就會很痛苦吧。所以這可能只能當成是精英團體的特有process。

aladdin wrote:
站在management的角度上來說,每個人呆在他現在的工作上,都有許多歷史的理由:薪水還好、遇到不錯的project leader、小孩剛出來不敢動、甚至只是因為對面公司有個妹妹長得還不錯...。management的目的不是要把每個人凍結在這個公司裡,因為有太多的因素你沒有辦法manage。加重某種誘因(薪水、負擔、發展性、工作文化)也許在其他方面失去的更多,有些老闆會強調公平性,但卻讓組織變得有些沒效率;有些老闆強調效率,但因此發生的人員流動,其成本也許反而會讓整體表現不如一個強調公平的組織。而且,你還有自己的風格——就像我是個好心人,但卻永遠會在外人面前說錯話——這是沒辦法強求的,但好的組織,會隨著時間經過以後,達到一個平衡。沒有那個平衡點,一些外界的簡單刺激,就可能讓整個組織翻掉。

Management,其實就是:一、如何趕快讓這個組織到達一個平衡點,二、怎麼讓這個平衡點在你想要衡量的這些「領域分數」中向上提升。第二點的「領域分數」的選擇,就會形成公司的價值觀。你如果覺得向心力是你重要的「領域分數」,你就會注意影響這些事情的所有可能條件,然後採取一些行動;但你的所有行動都有副作用,因此有些人覺得不公平(比如要求其他人互相cover工作),所以,組織又開始流動,有些人離開,有些人加入,然後,組織到達一個新的平衡。你又開始下一階段的evaluation和改變...

當然,有些企管專家告訴我們:不要 manage,要 lead!我自己的心得是:我就這麼點材料,再囉唆我就繼續做freelancer!

所以好的公司在建立讓人願意留下來的努力上,是不遺餘力的。人員流動率,是有可能降低的。

只是大多數人,都沒待過好公司吧。Smile台灣的軟體公司,大多數看得都太短了,終日汲汲營營,就為了賺取人頭差價的這種蠅頭小利,每個賺到這種錢的公司,都還洋洋得意。給我spec,我就可以找到生產成本最低的生產方式,這好像就一直是臺灣人的想法。

臺灣從貿易業,製造業開始經濟起飛,做生意時,就一直在算怎麼樣可以用比較低廉的成本來買到/生產東西。我們的大企業,像是鴻海,多半是靠這樣子起來的。這不知道跟這整個民族的民族性有沒有關係?

咦,我什麼時候搖身一變,變成企管專家候選人了?嗯,應該要搖頭晃腦的說幾句『要lead,不要manage啊。』Smile


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

我的網站:diggirl.net

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

外線交給我

版主

發文: 2033
積分: 8
於 2003-10-12 02:47 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:
.....前略述刪

所以好的公司在建立讓人願意留下來的努力上,是不遺餘力的。人員流動率,是有可能降低的。

只是大多數人,都沒待過好公司吧。Smile台灣的軟體公司,大多數看得都太短了,終日汲汲營營,就為了賺取人頭差價的這種蠅頭小利,每個賺到這種錢的公司,都還洋洋得意。給我spec,我就可以找到生產成本最低的生產方式,這好像就一直是臺灣人的想法。

臺灣從貿易業,製造業開始經濟起飛,做生意時,就一直在算怎麼樣可以用比較低廉的成本來買到/生產東西。我們的大企業,像是鴻海,多半是靠這樣子起來的。這不知道跟這整個民族的民族性有沒有關係?

咦,我什麼時候搖身一變,變成企管專家候選人了?嗯,應該要搖頭晃腦的說幾句『要lead,不要manage啊。』Smile

我只能說,您說的真是對極了...Smile

~~~~~~~~~~~~~~~~~~~~
一個不知道好公司長啥樣子的人


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





發文: 143
積分: 2
於 2003-10-12 02:58 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
anthonychen wrote:
我只能說,您說的真是對極了...Smile

~~~~~~~~~~~~~~~~~~~~
一個不知道好公司長啥樣子的人

可能指望 "好主管" 會比較快吧..
好公司...牽涉到 "營利"事業單位..

遇到好的主管..也許公司不怎樣..你還會想待..
遇到爛的主管..公司再好..也不會久留..

but...也要看..爛公司留不留得住 好主管...


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

外線交給我

版主

發文: 2033
積分: 8
於 2003-10-12 03:03 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
ming215 wrote:
可能指望 "好主管" 會比較快吧..
好公司...牽涉到 "營利"事業單位..

遇到好的主管..也許公司不怎樣..你還會想待..
遇到爛的主管..公司再好..也不會久留..

but...也要看..爛公司留不留得住 好主管...

真...真神。
完全說中我目前的處境。
要不是知道你在IKon,我會以為你速我們公司的"死派"(SPY)咧...


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

換回來



發文: 416
積分: 6
於 2003-10-12 03: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
ming215 wrote:
可能指望 "好主管" 會比較快吧..
好公司...牽涉到 "營利"事業單位..

遇到好的主管..也許公司不怎樣..你還會想待..
遇到爛的主管..公司再好..也不會久留..

but...也要看..爛公司留不留得住 好主管...

好公司通常都是大公司。因為好,所以有機會變大。大公司到未必見得是好公司。

不過,好主管通常在爛公司都待不久。

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

咦,這麼晚不睡覺,有搶到100嗎?


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

外線交給我

版主

發文: 2033
積分: 8
於 2003-10-12 03:13 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:
好公司通常都是大公司。因為好,所以有機會變大。大公司到未必見得是好公司。

不過,好主管通常在爛公司都待不久。

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

咦,這麼晚不睡覺,有搶到100嗎?

被你搶到了。

不過我是99&101啦....自我安慰...


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