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

1、1 淺談某項目中的問題與解決方案淺談某項目中的問題與解決方案 袁志軍 2007/07/24 摘要 當(dāng)前，在整個軟件行業(yè)的激烈競爭下，項目的成敗將關(guān)系到軟件企業(yè)的生存與發(fā)展，項目需要 建立在自我不斷創(chuàng)新和高質(zhì)量滿足客戶要求的基礎(chǔ)上。建立這種基礎(chǔ)的前提就是要具備很強的對 “需求、問題或機會”的識別能力以及提出相應(yīng)解決方案的能力。因此如何隨時識別項目中各項風(fēng) 險和問題，對整個項目的實施過程中的風(fēng)險進(jìn)行預(yù)測，進(jìn)而對各種風(fēng)險進(jìn)行跟蹤預(yù)防、規(guī)避，轉(zhuǎn)為 問題后妥善的解決這些問題，成為項目成敗的關(guān)鍵。 選擇適當(dāng)?shù)能浖_發(fā)模型能清晰、直觀地表達(dá)軟件開發(fā)全過程，明確規(guī)定要完成的主要活動和 任務(wù)，用來作為軟件項目工

2、作的基礎(chǔ)。我們公司很多的項目都選用瀑布模型，瀑布模型屬于整體開 發(fā)模型，它規(guī)定在開始下一個階段的工作之前，必須完成前一階段的所有細(xì)節(jié)，其特點是每個階段 有明確的開始和結(jié)束點,一個階段的輸出為下一階段的輸入條件。它很難適應(yīng)需求可變、模糊不定的 軟件系統(tǒng)的開發(fā)，而且在開發(fā)過程中用戶很難參與進(jìn)去，只有到開發(fā)結(jié)束才能看到整個軟件系統(tǒng)。 這種理想的、線性的開發(fā)過程缺乏靈活性，不適應(yīng)實際的開發(fā)過程。我們所使用的實際上是漸增模 型。漸增模型是在瀑布模型基礎(chǔ)上加以改進(jìn)而來的增量模型。它是以瀑布模型為基礎(chǔ)，按功能增量 方式進(jìn)行增量開發(fā) 。 項目背景某項目是個 web 系項目的典型：工期緊，開發(fā)人員能力弱的項目。

3、項目生命周期為漸增 模型。項目過程階段為項目啟動階段、式樣理解、編碼 coding、debug） 、ut、畫面集成、系統(tǒng)驗收 及維護(hù)、項目結(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 人月。 項目的各個階段都有一些不同的問題存在，對其進(jìn)行分析并提出解決方案，希望能為以后的 項目提供幫助。 2 一項

4、目前期： 它包括建立項目組織、對項目進(jìn)行估算、制訂相關(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ā)與維護(hù)的漫長生命周期中，需要完成許多性質(zhì)各異的 工作。這條原理意味著，應(yīng)該把軟件生命周期分成若干階段，并相應(yīng)制定出切實可行的計劃，然后 嚴(yán)格按照計劃對軟件的開發(fā)和維護(hù)進(jìn)行管理。為了更好的控制好項目，某項目導(dǎo)入 cmmi,它很好的 規(guī)范和定義好了軟件開發(fā)和管理的過程，為項目的成功提供了

5、在作計劃是往往會碰到：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ā)就不能完全進(jìn)行。如果等到式 樣理解完全結(jié)束在進(jìn)入開發(fā)的話，就會增加開發(fā)、測試的風(fēng)險時間不夠；因此采取了漸增的方式： 開發(fā)從 1

6、1/1 日開始，11/1 日11/10 日安排對新人的培訓(xùn)，根據(jù)一期的經(jīng)驗和能確定的穩(wěn)定的式樣 先進(jìn)性部分畫面的開發(fā)，開發(fā)完畢后進(jìn)入測試階段；11 月 10 日拿到經(jīng)過 review 的式樣版本， 11/10 進(jìn)行式樣理解，11/13 日開始未開發(fā)的畫面，開發(fā)完畢后進(jìn)行測試； 設(shè)計開發(fā)式樣理解測試 設(shè)計開發(fā)式樣理解測試 時間 進(jìn)度 符合使用漸增模型的開發(fā)模式。這樣既能完成一部分頁面的開發(fā)測試，同時新人在 10 天的培訓(xùn)中能 3 力得到了提升，為后面頁面的開發(fā)提供了保障。 1.1 式樣不足：先找穩(wěn)定的部分進(jìn)行或和客戶商討找出相對穩(wěn)定的模塊先著手，把計劃排在前 面，不穩(wěn)定的排在后面；先推動項目，去

7、發(fā)現(xiàn)存在的問題，并且進(jìn)行理解和討論，不產(chǎn)生 rework 的 工作都可以安排先做起來，比如培訓(xùn)預(yù)算等；和客戶確定接受物的日程，清楚什么時候能夠拿到達(dá) 成公式的穩(wěn)定的資料；設(shè)定假定的條件，在假設(shè)的基礎(chǔ)上的進(jìn)行評估，如果假設(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ù)防措施和補救措施并進(jìn)行跟蹤： 預(yù)防措施：提升現(xiàn)

8、有成員的作業(yè)能力；和事業(yè)部長或公司的領(lǐng)導(dǎo)進(jìn)行溝通，是否有調(diào)整資源的可能 性，爭取能得到自己想要的人力資源，并告知如果人力不足可能導(dǎo)致的問題； 某項目中經(jīng)過公司內(nèi)部調(diào)整，增加 4 名開發(fā)人員，但都缺乏實際項目開發(fā)經(jīng)驗需要進(jìn)行相關(guān)的 培訓(xùn)，測試人員 pending，調(diào)入技術(shù)部張曉洲進(jìn)入項目，項目得以按時啟動。 1.3 人員能力弱：這是項目中不可避免的問題，公司最近引進(jìn)了很多新人，必須讓他們加入項 目，在項目中鍛煉他們，提升他們各方面的能力。能力弱的人員可能難以完成交付給他們的工作， 甚至其工作效率可能比你想象還要低。要認(rèn)識正視這個項目組人員問題。否則，隨著能力弱的人員 的工作的失敗，整個項目很可能

9、延誤。 措施：前期的培訓(xùn)一定要有，特別是項目的規(guī)范和所要使用的技術(shù)，某項目中 11/1 日11/10 日就安排對新人的培訓(xùn)，讓他們熟悉編碼規(guī)約，webpump 的使用等；把能力弱的人員指定 se 或 subleader 來帶，然他們來負(fù)責(zé)控制這些人員的質(zhì)量和進(jìn)度。 4 二.項目中期 2.1 式樣理解 如何才能做好式樣理解呢？ 在式樣理解階段，下面成員應(yīng)該遵照式樣理解計劃和制定式樣理解指南進(jìn)行，如與計劃和不符 的應(yīng)該及時與 leader 進(jìn)行溝通，作為項目的管理者，也需要了解式樣理解的狀況以便及時調(diào)整；在 式樣理解階段開始前最好就建立好 qams 的帳戶或問題回答票，以會議的形式嚴(yán)格要求，避免問

10、題的 遺忘；盡量的站在客戶的角度去理解式樣；對式樣理解進(jìn)行 review，并對重要的畫面進(jìn)行重點理解 評審，保證式樣理解的質(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ā)階段提出的式樣問題不多，大部分問題在進(jìn)入測試階段后才發(fā)現(xiàn)。 2.2編碼 如何提高開發(fā)質(zhì)量？ 任何軟件開發(fā)項目中，質(zhì)量不僅僅擁有發(fā)言權(quán)，而且對

11、項目的成敗擁有表決權(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)度、速度以及方法。以會議的形式讓你的項目成員了解要達(dá)到的質(zhì)量目標(biāo)所 需要努力，通過項目努力，完成的工作產(chǎn)品以及其過程滿足客戶要求的程

12、度，把目標(biāo)量化。 某項目在綜合管理計劃中明確指出了目標(biāo)值：對重要畫面（20%）進(jìn)行重點的理解評審； 開發(fā)人員在畫面編碼結(jié)束時，要自己按 cd checkpoint 對代碼進(jìn)行自檢；通過利用 night build 檢 查代碼的規(guī)范性；畫面編譯通過，開發(fā)人員自己構(gòu)建基本 case，并且保留紀(jì)錄，按照基本 case 進(jìn) 行調(diào)試，調(diào)試通過算完成，leader 對 debugcase 和執(zhí)行情況進(jìn)行抽樣檢查；各開發(fā) leader 對 member 的代碼 review 率50%；對 ut case 的 review 率50%；bug 檢出標(biāo)準(zhǔn):標(biāo)準(zhǔn)值：8 個，最低值： 6 個，最大值：15 個；目標(biāo)明

13、確，給提高質(zhì)量打下了基礎(chǔ)。 選擇：指定項目成員中質(zhì)量意識，開發(fā)質(zhì)量高，技術(shù)能力高的成員去帶動相對低的成員，在 5 實際工作中去影響他們，言傳身教的提升相對較弱的成員。 管理：采取一些的方法來確保質(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 進(jìn)行調(diào)試，調(diào)試通 過才算完成該畫面；一開始的計劃是 pjl 主要 revi

14、ew 新人，有過一期開發(fā)經(jīng)驗的人相互 review， 從進(jìn)展的結(jié)果來看，程序員之間相互 review 幾乎沒有效果，因為他們總是著重于自己的畫面， review 流于形式，只是單純的為了完成計劃而已，質(zhì)量得不到保證。 交流和溝通。設(shè)計(式樣)管理組內(nèi)人員的交流和溝通；項目成員間的交流和溝通；與客戶的 交流和溝通都是必不可少的。要求你的項目成員在任何交流或溝通的場合里都能敞開心扉，完整地 表達(dá)自己的觀點。通過交流溝通會發(fā)現(xiàn)項目隱藏的問題和風(fēng)險。 某項目中通過相互的交流和溝通發(fā)現(xiàn)由于設(shè)計人員在細(xì)節(jié)方面考慮的不夠，有部分的共通類存 在問題，會對項目的開發(fā)造成很大的影響，于是要求東京設(shè)計擔(dān)當(dāng)人員于 1

15、1 月 13 日至 11 月 17 日 到南京進(jìn)行式樣講解和式樣答疑，就在這一周時間內(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)的越晚，改正它要付出的代價就越大，要差

16、2 到 3 個數(shù)量 級，給項目增加了成本。并且如果還有開發(fā)計劃的話，要完成 schedule 又要對應(yīng) bug 的話，加 班就很可能難免了。另外，過高的 bug 率會讓 leader 降低對此成員的信任，同時此成員的自信心也 會受到影響，進(jìn)而可能會對項目的成功造成阻礙。對此，也可以采取一些方法，例如：可以讓開發(fā) 的成員把所要開發(fā)的畫面和式樣書打印出來，然后要求其對照式樣一一 dubug，debug 完一項就打勾， 直到完成，然后交由 leader 確認(rèn)。慢慢的讓成員養(yǎng)成 dubug 習(xí)慣，把大量的編碼問題扼殺在開發(fā)階 段。某項目中要求就明確要求出 debug 報告書（c0 managermen

17、t01 engineeringmng06 cddebug 報告書） 。 持續(xù)提高開發(fā)人員各方面的技能。開發(fā)人員的技術(shù)能力提高了開發(fā)出來的代碼的質(zhì)量也會得到提 高，公司的實力才會得到提升。軟件開發(fā)技術(shù)日新月異，客戶的需求變動不居，所以所有成員都應(yīng) 持續(xù)的學(xué)習(xí)和提高，這一點相信大家都有共識。本公司的技術(shù)推進(jìn)組也根據(jù)公司的營運目標(biāo)制定技 術(shù)培訓(xùn)課程、根據(jù)計劃對相關(guān)人員進(jìn)行培訓(xùn)；事業(yè)部的日語培訓(xùn)，并根據(jù)相應(yīng)的情況制定了相應(yīng)的 獎懲措施。這就進(jìn)一步保證了公司的整體實力在邁向一個新的臺階。 6 2.3.bug 對應(yīng):如何對應(yīng)好測試出的問題？ 首先開發(fā)人員要擺正對測試人員的態(tài)度。要理解雖然開發(fā)和測試在某種程

18、度上是對立的，但是 從項目的角度來說是統(tǒng)一的，都是為了保證項目的成功，為公司盈利。測試人員是在幫助開發(fā)人員 發(fā)現(xiàn)編碼中的缺陷，完善開發(fā)的程序。 其次 bug 的對應(yīng)應(yīng)該也要注重方法：bug 再現(xiàn)。有時可能是由于版本環(huán)境等問題造成的，一 看到 bug 不加再現(xiàn)的就去修改的話，很可能會造成時間的浪費，而且可能會改出新的問題；bug 修正。再現(xiàn)了 bug 后，針對問題點進(jìn)行修改，修改是要切忌改出新的問題；bug 驗證。只是對所 修正問題的品質(zhì)保證，必不可少；bug 修正的 source 上傳 cvs.填寫回復(fù) qa 票。 做到以上五步， 就大大的減少了 bug 回歸的可能。 2.4如何提高項目成員的

19、戰(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è)氛

20、圍。熟悉團隊內(nèi)其他成員的工作，保證工作協(xié)調(diào)順利進(jìn)行，避免因為自己的作業(yè)質(zhì)量或者 作業(yè)進(jìn)度影響到團隊的質(zhì)量和作業(yè)效率。 合作推斷。決定團隊作業(yè)效率的關(guān)鍵因素可能不是團隊成員的能力，而是精誠合作的態(tài)度。假設(shè) 別人會積極主動地進(jìn)行合作為前提來決定自己應(yīng)該采取的行動，即以合作和開放的心態(tài)來回應(yīng)別人 的行為，以此形成一個“善的循環(huán)” 。某項目中手紙畫面承接著很多其他畫面的借口，擔(dān)當(dāng)者主動召 開關(guān)聯(lián)者會議，互相討論來決定參數(shù)命名和參數(shù)在畫面間的流動。 力量整合。團隊的存在意義在于團隊的整合力量遠(yuǎn)遠(yuǎn)大于每個成員單獨力量的總和，能得到一種 相乘效果，即超越個人力量之和。項目組成員的角色就在于，從團隊整合力量的

21、角度出發(fā)來整合眾 人的力量。 責(zé)任驅(qū)動。項目開發(fā)流程的終斷、項目進(jìn)度的遲緩、項目問題的浮現(xiàn)、項目質(zhì)量的脆弱等并非與 團隊某位成員毫不相干，因為團隊意味著共同承擔(dān)最終責(zé)任，共同享受最后榮光。在項目責(zé)任面前， 每人肩上都有份量，因此必須徹底消除“與我無關(guān)”的態(tài)度。 伙伴關(guān)系。軟件開發(fā)團隊成員之間需要基于共同成功的目標(biāo)而相互支持和幫助。具體而言，每位 7 成員在工作中要積極地參與項目的各種活動；團隊成員比較熟悉團隊內(nèi)其他人員的工作，以保證工 作協(xié)調(diào)進(jìn)行；在其他成員需要的時候，主動提供支持。 團隊精神，在某項目中一直貫穿項目的始終。例如：項目中由于設(shè)計將畫面和業(yè)務(wù)層分開，畫 面設(shè)計與類設(shè)計中間缺少接口

22、設(shè)計書，開發(fā)的時候也將開發(fā)業(yè)務(wù)類和畫面系分開，造成畫面系的人 不了解畫面的業(yè)務(wù)邏輯，開發(fā)類的人不知道具體方法是由哪些畫面調(diào)用；為此項目成員之間自發(fā)召 開與自己畫面相關(guān)的人員進(jìn)行相互溝通，相互通力合作解決擔(dān)當(dāng)任務(wù)之間的磨合問題。某些開發(fā)人 員能力偏弱，獨立解決問題比較困難。pjl 和 subleader 經(jīng)常會去幫助開發(fā)人員解決問題，讓畫面 按計劃提交測試，保證測試的順利進(jìn)行。項目的管理者姚茜也多次在項目會議上要求項目的成員發(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ù)手段上能夠立于不敗，另一方面能夠使團隊的每一個成員感受到吸引力和進(jìn)步感，這樣， 既能夠穩(wěn)定技術(shù)結(jié)構(gòu)，又能夠穩(wěn)定人員結(jié)構(gòu)。我想，這也是技術(shù)部門是否能夠留住一流技術(shù)人才、 軟件企業(yè)是否能夠持續(xù)發(fā)展壯大的一個根本原因之一。 8 三項目后期：項目后期的要點？ 開發(fā)和測試要密切的配合開完成畫面集成和測試，確保系統(tǒng)驗收的成功；對各功能模塊的功能 單元進(jìn)行語句覆蓋、分枝覆蓋或其他等級的跟蹤執(zhí)行以驗證程序?qū)崿F(xiàn)的正確性?；蛘呔?/p>