談某項目中的問題與解決方案.doc

此文檔收集于網絡 如有侵權 請聯(lián)系網站刪除 此文檔僅供學習與交流 淺談某項目中的問題與解決方案淺談某項目中的問題與解決方案 袁志軍 2007 07 24 摘要 當前 在整個軟件行業(yè)的激烈競爭下 項目的成敗將關系到軟件企業(yè)的生存與發(fā)展 項目需要 建立在自我不斷創(chuàng)新和高質量滿足客戶要求的基礎上 建立這種基礎的前提就是要具備很強的對 需求 問題或機會 的識別能力以及提出相應解決方案的能力 因此如何隨時識別項目中各項風 險和問題 對整個項目的實施過程中的風險進行預測 進而對各種風險進行跟蹤預防 規(guī)避 轉為 問題后妥善的解決這些問題 成為項目成敗的關鍵 選擇適當?shù)能浖_發(fā)模型能清晰 直觀地表達軟件開發(fā)全過程 明確規(guī)定要完成的主要活動和 任務 用來作為軟件項目工作的基礎 我們公司很多的項目都選用瀑布模型 瀑布模型屬于整體開 發(fā)模型 它規(guī)定在開始下一個階段的工作之前 必須完成前一階段的所有細節(jié) 其特點是每個階段 有明確的開始和結束點 一個階段的輸出為下一階段的輸入條件 它很難適應需求可變 模糊不定的 軟件系統(tǒng)的開發(fā) 而且在開發(fā)過程中用戶很難參與進去 只有到開發(fā)結束才能看到整個軟件系統(tǒng) 這種理想的 線性的開發(fā)過程缺乏靈活性 不適應實際的開發(fā)過程 我們所使用的實際上是漸增模 型 漸增模型是在瀑布模型基礎上加以改進而來的增量模型 它是以瀑布模型為基礎 按功能增量 方式進行增量開發(fā) 項目背景 某項目是個 WEB 系項目的典型 工期緊 開發(fā)人員能力弱的項目 項目生命周期為漸增 模型 項目過程階段為項目啟動階段 式樣理解 編碼 Coding Debug UT 畫面集成 系統(tǒng)驗收 及維護 項目結束 項目要求 2006 年 12 月 24 日上線 為保證上線前 ITF 公司的結合測試和系統(tǒng)測 試 我們必須于 12 月 10 日完成 UT 和初步的結合測試交貨 由于時間倉促 式樣設計沒有完整的基 本設計 詳細設計預計于 10 月 30 日給我們未經 Review 的初版 11 月 10 日給出經過 Review 的版 本 項目規(guī)模 25 人月 項目的各個階段都有一些不同的問題存在 對其進行分析并提出解決方案 希望能為以后的 項目提供幫助 此文檔收集于網絡 如有侵權 請聯(lián)系網站刪除 此文檔僅供學習與交流 一 項目前期 它包括建立項目組織 對項目進行估算 制訂相關的計劃 系統(tǒng)可行性調查分析 營業(yè)上的溝 通 技術上的學習培訓等準備工作 典型的工作產品 項目任務書 項目工程計劃報告書 也就是 用分階段的生命周期計劃嚴格管理 這一條是吸取前人的教訓而提出來的 統(tǒng)計表明 50 以上的失 敗項目是由于計劃不周而造成的 在軟件開發(fā)與維護的漫長生命周期中 需要完成許多性質各異的 工作 這條原理意味著 應該把軟件生命周期分成若干階段 并相應制定出切實可行的計劃 然后 嚴格按照計劃對軟件的開發(fā)和維護進行管理 為了更好的控制好項目 某項目導入 CMMI 它很好的 規(guī)范和定義好了軟件開發(fā)和管理的過程 為項目的成功提供了 在作計劃是往往會碰到 1 沒有完整的基本設計或詳細設計 2 人力不足 3 人員能力弱 等問題 由于這些問題的存在 想要完全按照瀑布模型來實施就會很困難 在某項目中式樣設計由于時間倉促 沒有完整的基本設計 詳細設計預計于 10 月 30 日給我 們未經 Review 的初版 到 11 月 10 日給出經過 Review 的版本 沒有完整的基本設計式樣理解就不完全 式樣理解階段就沒結束 而瀑布模型規(guī)定在開始下 一個階段的工作之前 必須完成前一階段的所有細節(jié) 所以編碼開發(fā)就不能完全進行 如果等到式 樣理解完全結束在進入開發(fā)的話 就會增加開發(fā) 測試的風險 時間不夠 因此采取了漸增的方式 開發(fā)從 11 1 日開始 11 1 日 11 10 日安排對新人的培訓 根據(jù)一期的經驗和能確定的穩(wěn)定的式樣 先進性部分畫面的開發(fā) 開發(fā)完畢后進入測試階段 11 月 10 日拿到經過 Review 的式樣版本 11 10 進行式樣理解 11 13 日開始未開發(fā)的畫面 開發(fā)完畢后進行測試 設計開發(fā)式樣理解測試 設計開發(fā)式樣理解測試 時間 進度 符合使用漸增模型的開發(fā)模式 這樣既能完成一部分頁面的開發(fā)測試 同時新人在 10 天的培訓中能 此文檔收集于網絡 如有侵權 請聯(lián)系網站刪除 此文檔僅供學習與交流 力得到了提升 為后面頁面的開發(fā)提供了保障 1 1 式樣不足 先找穩(wěn)定的部分進行或和客戶商討找出相對穩(wěn)定的模塊先著手 把計劃排在前 面 不穩(wěn)定的排在后面 先推動項目 去發(fā)現(xiàn)存在的問題 并且進行理解和討論 不產生 Rework 的 工作都可以安排先做起來 比如培訓預算等 和客戶確定接受物的日程 清楚什么時候能夠拿到達 成公式的穩(wěn)定的資料 設定假定的條件 在假設的基礎上的進行評估 如果假設變了 在重新評估 通過各種方法 盡可能促成假定條件得到滿足 1 2 人力不足 開發(fā)只有參與過 10 月版的開發(fā)人員 7 名 含一名 PJL 測試 2 名 另外一名 PM 根據(jù) 10 月版開發(fā)的經驗 當時的人力缺少開發(fā) 5 名 其中需要一名技術支持 測試 2 名 測 試經理一名 先把這個問題列入風險管理票中 寫入可能的預防措施和補救措施并進行跟蹤 預防措施 提升現(xiàn)有成員的作業(yè)能力 和事業(yè)部長或公司的領導進行溝通 是否有調整資源的可能 性 爭取能得到自己想要的人力資源 并告知如果人力不足可能導致的問題 某項目中經過公司內部調整 增加 4 名開發(fā)人員 但都缺乏實際項目開發(fā)經驗需要進行相關的 培訓 測試人員 Pending 調入技術部張曉洲進入項目 項目得以按時啟動 1 3 人員能力弱 這是項目中不可避免的問題 公司最近引進了很多新人 必須讓他們加入項 目 在項目中鍛煉他們 提升他們各方面的能力 能力弱的人員可能難以完成交付給他們的工作 甚至其工作效率可能比你想象還要低 要認識正視這個項目組人員問題 否則 隨著能力弱的人員 的工作的失敗 整個項目很可能延誤 措施 前期的培訓一定要有 特別是項目的規(guī)范和所要使用的技術 某項目中 11 1 日 11 10 日就安排對新人的培訓 讓他們熟悉編碼規(guī)約 Webpump 的使用等 把能力弱的人員指定 SE 或 SubLeader 來帶 然他們來負責控制這些人員的質量和進度 此文檔收集于網絡 如有侵權 請聯(lián)系網站刪除 此文檔僅供學習與交流 二 項目中期 2 1 式樣理解 如何才能做好式樣理解呢 在式樣理解階段 下面成員應該遵照式樣理解計劃和制定式樣理解指南進行 如與計劃和不符 的應該及時與 leader 進行溝通 作為項目的管理者 也需要了解式樣理解的狀況以便及時調整 在 式樣理解階段開始前最好就建立好 QAMS 的帳戶或問題回答票 以會議的形式嚴格要求 避免問題的 遺忘 盡量的站在客戶的角度去理解式樣 對式樣理解進行 review 并對重要的畫面進行重點理解 評審 保證式樣理解的質量 盡早的發(fā)現(xiàn)問題 在某項目中式樣理解開始時東京 QAMS 遲遲沒見好 式樣理解中發(fā)現(xiàn)的問題沒有及時記錄 共享 性也不足 在 11 2 日的周會上發(fā)現(xiàn)了該問題 決定用 excel 暫時管理問題 統(tǒng)一發(fā)給東京 共通性 的問題以 mail 的形式通知全員 但也許因為這個原因 一開始對 QA 要求的不嚴格 導致開發(fā)人員 過于依賴式樣 開發(fā)階段提出的式樣問題不多 大部分問題在進入測試階段后才發(fā)現(xiàn) 2 2 編碼 如何提高開發(fā)質量 任何軟件開發(fā)項目中 質量不僅僅擁有發(fā)言權 而且對項目的成敗擁有表決權甚至最終的否決 權 質量不僅僅會對軟件開發(fā)項目本身的成敗產生影響 而且會對我們軟件企業(yè)的形象 商譽的褒 貶帶來沖擊和震蕩 質量是指項目滿足明確或隱含需求的程度 定標 首先定義作業(yè)范圍的交付物標準來明確定義作業(yè)成果物的質量 包括質量的各種特性 及這些特性需要滿足的要求 還可能對項目的過程質量做出明確規(guī)定 包括軟件開發(fā)所規(guī)定的流程 開發(fā)的規(guī)范和 BUG 率的標準 以及有效執(zhí)行這些過程的證據(jù) 還可能對項目的顧客應對質量作出規(guī) 定 包括應對顧客的態(tài)度 速度以及方法 以會議的形式讓你的項目成員了解要達到的質量目標所 需要努力 通過項目努力 完成的工作產品以及其過程滿足客戶要求的程度 把目標量化 某項目在綜合管理計劃中明確指出了目標值 對重要畫面 20 進行重點的理解評審 開發(fā)人員在畫面編碼結束時 要自己按 CD CheckPoint 對代碼進行自檢 通過利用 Night Build 檢 查代碼的規(guī)范性 畫面編譯通過 開發(fā)人員自己構建基本 case 并且保留紀錄 按照基本 case 進 行調試 調試通過算完成 leader 對 debugcase 和執(zhí)行情況進行抽樣檢查 各開發(fā) Leader 對 Member 的代碼 review 率 50 對 UT Case 的 review 率 50 Bug 檢出標準 標準值 8 個 最低值 6 個 最大值 15 個 目標明確 給提高質量打下了基礎 選擇 指定項目成員中質量意識 開發(fā)質量高 技術能力高的成員去帶動相對低的成員 在 此文檔收集于網絡 如有侵權 請聯(lián)系網站刪除 此文檔僅供學習與交流 實際工作中去影響他們 言傳身教的提升相對較弱的成員 管理 采取一些的方法來確保質量 檢查 監(jiān)督 驗證 就是要用數(shù)據(jù)證明開發(fā)人員是不是在正確的制造產品 注意這里強調的是過程的正確 行 確認 就是要用數(shù)據(jù)證明開發(fā)人員是不是制造了正確的產品 注意這里強調的是結果的正 確性 review 最好是 subLeader 以上的成員來擔當 某項目中要求開發(fā)人員自己構建基本 case 并且保留紀錄 按照基本 case 進行調試 調試通 過才算完成該畫面 一開始的計劃是 PJL 主要 review 新人 有過一期開發(fā)經驗的人相互 review 從進展的結果來看 程序員之間相互 review 幾乎沒有效果 因為他們總是著重于自己的畫面 review 流于形式 只是單純的為了完成計劃而已 質量得不到保證 交流和溝通 設計 式樣 管理組內人員的交流和溝通 項目成員間的交流和溝通 與客戶的 交流和溝通都是必不可少的 要求你的項目成員在任何交流或溝通的場合里都能敞開心扉 完整地 表達自己的觀點 通過交流溝通會發(fā)現(xiàn)項目隱藏的問題和風險 某項目中通過相互的交流和溝通發(fā)現(xiàn)由于設計人員在細節(jié)方面考慮的不夠 有部分的共通類存 在問題 會對項目的開發(fā)造成很大的影響 于是要求東京設計擔當人員于 11 月 13 日至 11 月 17 日 到南京進行式樣講解和式樣答疑 就在這一周時間內 式樣變更頻繁 消除了設計上和式樣上的缺 陷 為項目的成功打下了基礎 端正態(tài)度 樹立正確的編碼觀念 提高項目成員的質量意識 讓他們從思想上認識開發(fā)質量 的重要性 很一些開發(fā)人員認為只要頁面出來編碼完就行了 甚至單一的認為自己已經按照式樣書 開發(fā)完了 測試是測試人員的事情 事實證明不是 編碼只是開發(fā)的第一步 還有很重要的一步那 就是 DEBUG BEBUG 可以發(fā)現(xiàn)代碼中的缺陷 如果做的不好 BUG 率就會偏高 有統(tǒng)計結果顯示 大 部分錯誤是在編碼階段造成的 錯誤發(fā)現(xiàn)的越晚 改正它要付出的代價就越大 要差 2 到 3 個數(shù)量 級 給項目增加了成本 并且如果還有開發(fā)計劃的話 要完成 SCHEDULE 又要對應 BUG 的話 加 班就很可能難免了 另外 過高的 BUG 率會讓 LEADER 降低對此成員的信任 同時此成員的自信心也 會受到影響 進而可能會對項目的成功造成阻礙 對此 也可以采取一些方法 例如 可以讓開發(fā) 的成員把所要開發(fā)的畫面和式樣書打印出來 然后要求其對照式樣一一 DUBUG DEBUG 完一項就打勾 直到完成 然后交由 LEADER 確認 慢慢的讓成員養(yǎng)成 DUBUG 習慣 把大量的編碼問題扼殺在開發(fā)階 段 某項目中要求就明確要求出 DEBUG 報告書 C0 Managerment 01 EngineeringMng 06 CD Debug 報告書 持續(xù)提高開發(fā)人員各方面的技能 開發(fā)人員的技術能力提高了開發(fā)出來的代碼的質量也會得到提 高 公司的實力才會得到提升 軟件開發(fā)技術日新月異 客戶的需求變動不居 所以所有成員都應 持續(xù)的學習和提高 這一點相信大家都有共識 本公司的技術推進組也根據(jù)公司的營運目標制定技 術培訓課程 根據(jù)計劃對相關人員進行培訓 事業(yè)部的日語培訓 并根據(jù)相應的情況制定了相應的 獎懲措施 這就進一步保證了公司的整體實力在邁向一個新的臺階 此文檔收集于網絡 如有侵權 請聯(lián)系網站刪除 此文檔僅供學習與交流 2 3 BUG 對應 如何對應好測試出的問題 首先開發(fā)人員要擺正對測試人員的態(tài)度 要理解雖然開發(fā)和測試在某種程度上是對立的 但是 從項目的角度來說是統(tǒng)一的 都是為了保證項目的成功 為公司盈利 測試人員是在幫助開發(fā)人員 發(fā)現(xiàn)編碼中的缺陷 完善開發(fā)的程序 其次 BUG 的對應應該也要注重方法 BUG 再現(xiàn) 有時可能是由于版本環(huán)境等問題造成的 一 看到 BUG 不加再現(xiàn)的就去修改的話 很可能會造成時間的浪費 而且可能會改出新的問題 BUG 修正 再現(xiàn)了 BUG 后 針對問題點進行修改 修改是要切忌改出新的問題 BUG 驗證 只是對所 修正問題的品質保證 必不可少 BUG 修正的 SOURCE 上傳 CVS 填寫回復 QA 票 做到以上五步 就大大的減少了 BUG 回歸的可能 2 4 如何提高項目成員的戰(zhàn)斗力 在項目作業(yè)過程中宣揚團隊精神 消除個人表演主義 集合眾智 趨向成功 當我們以團隊的形式工作時 要比以孤軍奮戰(zhàn)的形式來得更加富有成效 團隊的協(xié)同工作比個人競 爭更能激勵項目成員 軟件開發(fā)過程中必須消除單打獨斗的個人主義 催生團隊精神 為了實現(xiàn)共 同的目標 為了發(fā)揮團隊的集合力量 而相互合作 相互支援的精神狀態(tài) 團隊精神應該包括下述 要點 自我激勵 基于一種成功 成就 成長的意愿而自我激勵 自我督促 自我提升 在工作中不僅 僅執(zhí)行上級的命令 更重要的是積極地參與 起到決策與輔助決策的作用 換位思考 站在其他項目組成員和項目管理者的立場上思考問題 避免產生誤解 創(chuàng)造和諧互動 的作業(yè)氛圍 熟悉團隊內其他成員的工作 保證工作協(xié)調順利進行 避免因為自己的作業(yè)質量或者 作業(yè)進度影響到團隊的質量和作業(yè)效率 合作推斷 決定團隊作業(yè)效率的關鍵因素可能不是團隊成員的能力 而是精誠合作的態(tài)度 假設 別人會積極主動地進行合作為前提來決定自己應該采取的行動 即以合作和開放的心態(tài)來回應別人 的行為 以此形成一個 善的循環(huán) 某項目中手紙畫面承接著很多其他畫面的借口 擔當者主動召 開關聯(lián)者會議 互相討論來決定參數(shù)命名和參數(shù)在畫面間的流動 力量整合 團隊的存在意義在于團隊的整合力量遠遠大于每個成員單獨力量的總和 能得到一種 相乘效果 即超越個人力量之和 項目組成員的角色就在于 從團隊整合力量的角度出發(fā)來整合眾 人的力量 責任驅動 項目開發(fā)流程的終斷 項目進度的遲緩 項目問題的浮現(xiàn) 項目質量的脆弱等并非與 團隊某位成員毫不相干 因為團隊意味著共同承擔最終責任 共同享受最后榮光 在項目責任面前 每人肩上都有份量 因此必須徹底消除 與我無關 的態(tài)度 伙伴關系 軟件開發(fā)團隊成員之間需要基于共同成功的目標而相互支持和幫助 具體而言 每位 此文檔收集于網絡 如有侵權 請聯(lián)系網站刪除 此文檔僅供學習與交流 成員在工作中要積極地參與項目的各種活動 團隊成員比較熟悉團隊內其他人員的工作 以保證工 作協(xié)調進行 在其他成員需要的時候 主動提供支持 團隊精神 在某項目中一直貫穿項目的始終 例如 項目中由于設計將畫面和業(yè)務層分開 畫 面設計與類設計中間缺少接口設計書 開發(fā)的時候也將開發(fā)業(yè)務類和畫面系分開 造成畫面系的人 不了解畫面的業(yè)務邏輯 開發(fā)類的人不知道具體方法是由哪些畫面調用 為此項目成員之間自發(fā)召 開與自己畫面相關的人員進行相互溝通 相互通力合作解決擔當任務之間的磨合問題 某些開發(fā)人 員能力偏弱 獨立解決問題比較困難 PJL 和 subleader 經常會去幫助開發(fā)人員解決問題 讓畫面 按計劃提交測試 保證測試的順利進行 項目的管理者姚茜也多次在項目會議上要求項目的成員發(fā) 揚團隊精神 這為項目的成功奠定了堅實的基礎 2 5 如何來預防項目成員的流失 古人云 凡事預則立 不預則廢 從團隊培養(yǎng)的角度來說 只有具有持續(xù)吸引力的團隊 才是最穩(wěn)固的團隊 凝聚技術性人才的真正動力 在超越了收入這一層次的時候 技術素養(yǎng)的培養(yǎng) 更具有吸引力 這就必然要求技術部門的管理者要能夠有一個相對長遠的技術規(guī)劃 一方面能夠讓 企業(yè)在技術手段上能夠立于不敗 另一方面能夠使團隊的每一個成員感受到吸引力和進步感 這樣 既能夠穩(wěn)定技術結構 又能夠穩(wěn)定人員結構 我想 這也是技術部門是否能夠留住一流技術人才 軟件企業(yè)是否能夠持續(xù)發(fā)展壯大的一個根本原因之一 此文檔收集于網絡 如有侵權 請聯(lián)系網站刪除 此文檔僅供學習與交流 三 項目后期 項目后期的要點 開發(fā)和測試要密切的配合開完成畫面集成和測試 確保系統(tǒng)驗收的成功 對各功能模塊的功能 單元進行語句覆蓋 分枝覆蓋或其