各位的系統開發歷程,都依循著軟體工程的方法論嗎?? |
|
G01
高階會員 發表:249 回覆:379 積分:215 註冊:2002-05-21 發送簡訊給我 |
這陣子忙翻天,除了捍衛自己的興趣;還要忙公司的Case;前不久做的Sample ER-Model工具;就拿來分析了一下舊的系統;這才發現...暈啊.....天啊!!....驚呼聲此起彼落....想到以後要接這些前人的"債"...突然覺得一陣暈眩..... 忽然想請大家聊聊...同時也想想幾個問題
1.哪個方法論在實際工作上較易落實呢??
2.若依循某一個方法論來實踐,又如何把虛擬的成果表達到能讓Boss可以預見呢?
3.專案管理方式與方法論需要有特定的組合嗎??
4.曾經遇到過專案管理與實際施工狀況'脫節'的情形...這是常態嗎?? 歡迎大家各書己見...說說您的"遭遇"與您的看法....
|
change.jian
版主 發表:29 回覆:620 積分:439 註冊:2003-06-02 發送簡訊給我 |
其實,小弟做過的專案,沒有1000也有800了.但,你的問題,我也在尋找答案中. 以我的感覺來說,案子的執行,其實沒有什麼特定的理論可以確保案子順利進行.原因有很多,諸如技術上的問題,客戶要求的完成日期與分配的人力是否在合理值之內,案子的大小、範圍等. 以前總認為經過事前詳細的sa,sd,coding,測試,是一個完整且確保可以完成的工作方法,但實際上,往往時間不允許你做這樣的流程.分工過細,代表的是溝通會越來越多,會議會越開越頻繁.同樣的,到了,sd,coding時,投入的人力更多,溝通與管理就越不容易. 而現在,雖然有所謂的uml做為分析的方式.但說真的,沒幾個人懂.且最重要的,是客戶不懂.這是重點,如果客戶懂就不會找你做了.老實說,光本人就碰過有人把案子做砸了,然後繞跑,而那個人還在市面上寫關於uml這類的系統分析的書咧. 真要說有沒有什麼方法可以知道案子會不會順利,我覺得客戶端負責系統的人的水準很重要.專案負責人能夠與客戶的負責人有良好的互動,訊息能夠正確的傳達,意見能充分交換,系統才可能做對.像之前在中科院做過一個專案,負責人對於整個系統要做成什麼樣子,會有那些功能已經有一個很清楚的view,所以系統做起來不會有打不到靶的情形.也有碰過不敢負責任,然後自己天馬行空的亂想系統的功能,溝通起來不但費力費時,加上沒有什麼水準,解釋master-detail的限制老半天,就是認為你不願意做. 至於案子的控管.其實我覺得倒還容易.把所有的功能清單列一列,看看會有幾隻程式,難易度大概抓一下,就可以換算成概略要執行的天數.然後,每個禮拜檢討進度,其實也都還OK.我覺得.
|
G01
高階會員 發表:249 回覆:379 積分:215 註冊:2002-05-21 發送簡訊給我 |
|
G01
高階會員 發表:249 回覆:379 積分:215 註冊:2002-05-21 發送簡訊給我 |
|
暗黑破壞神
版主 發表:9 回覆:2301 積分:1627 註冊:2004-10-04 發送簡訊給我 |
|
G01
高階會員 發表:249 回覆:379 積分:215 註冊:2002-05-21 發送簡訊給我 |
呵呵呵....感謝暗黑破壞神的回覆.....
其實,光是把整各系統的概況描述的很完整;就是一件異常艱辛的工作
更別提是針對一般User了.
記得看過一篇文章是在說明專案進行的管理,到後來卻話鋒一轉;說到其實是變數很多,根本無法完全管控;只能做"風險管理"......^-^....!! 另外,提出這個討論主題也是希望能有個能讓User可以理解目前系統的方法,降低天馬行空的需求被提出的機率;不然真的是...做到死...又不知何時才能結束!!
還有就是有些分析工具離實際作業實在太遙遠...感受不到去做那些分析到底能不能落實到實際作業上....如果可以的話....那還真是我輩一大福音呢!!
|
KENI_LIN
中階會員 發表:86 回覆:267 積分:90 註冊:2004-05-31 發送簡訊給我 |
其實每個專案(Project)成立前,都要有一位領導(Leader)和PM管理,一定會做所謂的"專案成立通知書",內容包含了市場評估,成本計算和生產利潤,以及是否有既定客戶需求(每月固定訂單)等等的前置作業討論;一般老闆最關心的就是客戶需求了,當然是有訂單的先處理,接下來就是苦了S/W和H/W的工程師,要趕出預計的進度來完成它. 所以新/舊產品都會需要做"專案成立通知書"的評估報告,因為老闆和業務的專業技術不見得會比工程師強,所以才會需要Leader和PM做出"統計分析"將結果數值化出來;雖然感覺像"紙上談兵",但是本人覺得這樣做可以把很多問題明朗化. 寒窗苦讀十年書;只待今朝狀元時!~~
︵ / / ︵
( ∩ ∩ )
○ ︶ ○
------
Keni Lin |
暗黑破壞神
版主 發表:9 回覆:2301 積分:1627 註冊:2004-10-04 發送簡訊給我 |
|
㊣
版主 發表:261 回覆:2302 積分:1667 註冊:2005-01-04 發送簡訊給我 |
引言: 我記得當年年輕時去上過課。 老師說過一句話。我到現在還一直實行中。 ”在幾月幾日以前提出的需求。我們有權判斷是否受理。 在那之後所提出的需求。請另案處理” 否則。專案會結不了案。 因為使用者有些是根本不知道電腦能幫你做到什麼。 等你給他看到它的方便時。就會再。。。那能不能在這邊再加個XXX。 這類的話出來。那你依他。就會有做不完的事情了。 所以。務必堅持那一道防線。^_^沒錯!!個人曾身受其害... 只能說當時熱心,忘了人心險惡... 學生時接案,遇到廠商一直要求加功能..真的差點結不了案... 那就算了,結案後,有很多案外問題他也拿來問你..甚至別的案子...
------
------------------------------------------------------------------------- 走是為了到另一境界,停是為了欣賞人生;未走過千山萬水,怎知生命的虛實與輕重!? |
change.jian
版主 發表:29 回覆:620 積分:439 註冊:2003-06-02 發送簡訊給我 |
專案最好玩的地方是沒有一定的解法,沒有標準答案.這中間,不只考驗技術上的功力,更考驗專案負責人的VIEW有多大?往往USER要的系統,其實出發點只有一個功能,然後系統在USER的想像力之下就會越想越大.重點是這個出發點能否被專案負責人發現並掌握. 至於我目前的做法,是以case tool做系統table的管理,然後產生程式碼.建議你,要有一套上手的case tool,否則,近200個table如何管理.不要天真的認為用人工去修改word檔裡的欄位規劃只是累一點而已,想想看.修改一個欄位,你要改資料庫,改程式,然後去改檔案說明書.沒有那個功夫啦!!就跟寫程式一樣,同樣的功能就是寫在一個物件裡,用到這個功能才去呼叫這個物件.同樣的,系統的table有那些,欄位怎麼定,就都記錄在case tool裡.然後由case tool去產生文件,產生程式碼.不要用人工去維護這些資料,很沒有效率!! "昨天在畫ER-Model時,的確被視為異類;巴不得我趕快Codeing"<----這就表示你的user不懂專案流程!!你有兩個選擇:1.想辦法說服user,教育user何謂專案流程,為什麼要先做系統分析,解釋你為什麼畫ER-Model. 2.想辦法改變自己的專案做法,訪談後就可以開table ,coding. 我是走第二種,為什麼不走第一種?試問,當一個人會把腳踏車騎上高速公路,你有沒有辦法去說服他為什麼不行!! 發表人 - change.jian 於 2005/04/14 13:26:29
|
hahalin
版主 發表:295 回覆:1698 積分:823 註冊:2002-04-14 發送簡訊給我 |
我有一個朋友,他公司因為人員離職,被安排去接手維護系統
那個系統本身已經有客戶在使用,但是問題很多 他接手之後,想要整理文件,想要把規格弄清楚,才能把bug修復
他的老闆跟他說了這麼一段話 "現在沒有時間了,你不用把來源的各個table搞懂,就是把bug修好,
因為客戶不能等了" 他在跟我提的時候,我覺得真好玩,不把相關的table弄懂,
可以把bug修好? 有時候,有太多外行領導內行,土法煉鋼,打帶跑的情況不斷上演,
跟時間賽跑,然後是不斷的修補,每次都是,把這個弄好再整頓,
隨著人員的異動,熟悉度不斷下降,然後製造了更多的問題,或是
解決了一個bug,製造了十個新的bug. 台灣中小企業的精神,就是搶時機錢,打帶跑,能說什麼呢?
就因為有這種出錢請你來我是老大的土財主心態,
更有可能是大環境下的妥協不得不如此,
未來會如何?
Who knows? 我這位朋友的老闆還說過一句名言 "生命會自己找到出路" 阿彌佗佛,善哉,善哉!
|
G01
高階會員 發表:249 回覆:379 積分:215 註冊:2002-05-21 發送簡訊給我 |
本站聲明 |
1. 本論壇為無營利行為之開放平台,所有文章都是由網友自行張貼,如牽涉到法律糾紛一切與本站無關。 2. 假如網友發表之內容涉及侵權,而損及您的利益,請立即通知版主刪除。 3. 請勿批評中華民國元首及政府或批評各政黨,是藍是綠本站無權干涉,但這裡不是政治性論壇! |