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