為什麼專案總是失敗

2021-08-27 10:21:38 字數 3112 閱讀 2893

做了很長時間的開發,也帶過一些專案,有過很多成功和失敗的經歷。

一些失敗的專案不斷促使自己思考如何才能把專案做成功,也看了一些關於專案管理和敏捷開發方面的書籍。

自己總結下來,發現專案失敗的原因大概是兩方面:

1. 缺少方法, 不知道如何應當使用那些方法來保障專案的成功。

這個方面可以通過請教、多看書、不斷實踐來提高。

2. 還有乙個重要原因是人性的弱點,"超越規則"的僥倖心理。

近期報道的中國式的過馬路,凸顯了國人不遵守規則的心理。因為人總會認為自己是個特例,明知道規則的情況下,總是認為自己能夠超越規則而能夠成功或者避免懲罰。

這也是軟體專案中同樣的失敗案例不斷重現的原因,即使我們有前人總結過的經驗教訓。

比如:你明知道這個專案不可能在3個月內完成,但是迫於老闆的壓力,你會覺得自己能夠超越當前開發效率滿足這個不切實際的幻想。

下面是我總結的一些團隊開發的規範,只是初稿,非常歡迎園友有其它的建議或者補充。

"你我是朋友,各拿乙個蘋果彼此交換,交換後仍然是各有乙個蘋果;倘若你有乙個思想,我也有一種思想,而朋友間交流思想,那我們每個人就有兩種思想了。"

1. 專案開始前組織培訓

使用的工具和技術, 如git, log4net, resharper, redmine, nant等

專案編碼規範

專案使用的框架和設計培訓

2. 每日構建

每日構建要能夠自動化執行。

覆蓋以下內容來保證專案質量:

單元測試的**覆蓋率達到90%,每日構建能夠成功通過

所有**執行過程, log4net可跟蹤

通過自動化的驗收測試

每天使用nant做每日構建,執行單元測試,**質量檢查,**重複檢查,安裝包製作和發布

3. 關於測試資料

在專案開始時,著手準備建立和維護一套資料庫結構和測試資料,測試資料要達到以下要求:

測試資料應當全員用一套,可以方便的匯入和恢復到初始狀態

測試的資料庫結構和資料要有版本管理

測試資料應當用相對有意義的資料,比如user name 不能用asdfasdfas這種, 而用peter, jim等。

當bug發生時,如果可以通過補充特例的測試資料達到覆蓋bug的效果,應當補全這部分測試資料

4. 每日的站會和分享

組織專案成員站會,關注專案block issue

成為站會的組織者而不是領導者,發揮集體成員的主動性來解決問題和分享經驗。

分享的內容與重要,大小無關。可能只是發現了乙個更好的api的使用,乙個變數命名不好的錯誤等。

讓團隊成為乙個自主的,自我提高和修正錯誤的團隊。

5. 關於知識分享工具

團隊中不斷建立的規範、知識、使用者需求等,需要有種方式記錄和傳播。以避免進入新的成員時,只能依靠經驗和記憶等不可靠手段來傳遞的方式。

推薦使用wiki

6. 關於專案中使用的第三方api或控制項

使用第三方api或控制項時, 任何對商業使用收費,或者免費但不開源的,都需要得到客戶的認可和同意付費

團隊需要考慮第三方api或控制項的穩定性,和可維護性,避免開源專案暫停或者停止維護等問題

如果是和客戶的技術團隊合作,即使使用開源和免費的,也需要得到對方的同意。

新增注釋

1. 類注釋

類的注釋,需要描述類的功能、依賴和如何使用

2. **注釋

複雜的邏輯應當新增注釋

3.使用region

使用關鍵字region注釋使**更加整潔

4.全域性變數注釋

每個全域性變數需要寫注釋

5. 程式流程變化注釋

switch, if, while 等條件判斷地方必須寫注釋

6. public方法注釋

public的方法體中的**,需要寫好詳盡的注釋

編碼規範

1. 單行**寬度不能超過150, 單個.cs檔案長度不能超過600行. if, while, for, switch等的巢狀必須<=3

2. 少定義委託,多使用event, func, action 和 predicate

3. 對於public的函式, 不要太長,可以分拆成多個private方法減少**長度.

4. 變數命名

4.1 控制項的名稱,不允許是button1, textbox1這種無意義的名字

4.2.使用能讀懂的命名(盡量使用全名)

4.3 event等delegate的命名

event的命名要體現出事件, 如...changed, 體現發生了什麼,而不是告訴要做什麼

bad: publiceventhandler extendorderdetails;這裡直接告訴別人做什麼

good: public actionordertracktypechangedtoother; 這裡只是告訴別人發生了什麼

單元測試

1.盡量在專案中覆蓋單元測試,依據專案不同,團隊可以制定自己的標準(如**覆蓋率等)

2.修復bug前,先寫單元測試覆蓋bug, 然後再fix bug

1.單一職責

業務邏輯類中不要包含介面相關**

切實保證這個類中的**,和類的名字(定義)一致。

只告知外界本類內部發生的事情,不要直接發指令讓外界做什麼。例子: 類中的delegate, event, 是用來告訴類內部發生了什麼,不要指導外界做什麼。

盡量隱藏類內部的實現細節。比如ms的file類,包含操作檔案的方法實現,但是外界不需要知道具體如何實現的。

2.類應當盡量依賴其它小的類,依賴的其它的類應該盡量放到建構函式中

假如有乙個擰螺絲的功能類,只需要乙個扳手就能解決問題,那麼不要讓這個類依賴於乙個工具箱

3.減少依賴於類, 應當更多的依賴於介面

把上面的扳手類抽象成乙個介面,讓擰螺絲的功能類依賴於介面

4.盡量少的使用全域性變數

全域性變數需要寫好注釋,解釋全域性變數的作用

全域性變數不要在類中的私有方法中使用

為什麼你的專案總是延期?

公司有個專案需要你來完成,老闆讓你給出個完成時間。當給出了專案完成的時間線後,你的老闆會可能會將其分解為若干步驟,就像你之前所做的那樣,然後分析每一步的完成時間,最後將這些時間加起來作為整個專案的時間線。不過,這樣做就能確保專案按時交付麼?sketchdeck團隊對此給出了自己的答案。雖然這是估算多...

為什麼你的專案總是延期

隨著專案管理在企業中的廣泛應用,它對於企業內部效率以及經濟效益的提公升扮演著越來越重要的角色。有調查分析顯示,使用軟體輔助管理專案的企業中,專案可以順利驗收的比率是92.5 而不使用軟體管理的,專案成功率只有72.7 保質保量按時完成專案是每個專案管理者最基本的目標,但在實際專案開展工作中,類似以下...

為什麼總是加班

為什麼總是加班?看到其他人可以做的很好,而我為什麼總是加班也完成的不好呢 我總結了好幾點,現在說說我自身的問題吧 1 以前養成的壞習慣,不能當日的事情當日解決。2 上班的時候不能合理高效利用工作時間 3 最近狀態不好 4 老是要求完美 不知這樣說對的起自己不,哈哈 所以進展就很慢 以上四點佔我自身因...