學(xué) 生以團(tuán)隊(duì)進(jìn)行開(kāi)發(fā)常常遇到的一個(gè)問(wèn)題便是不知道如何組織一個(gè)團(tuán)隊(duì)進(jìn)行工作，不知道如何分工合作，以及如何開(kāi)始一個(gè)項(xiàng)目。而傳統(tǒng)的瀑布型的開(kāi)發(fā)方法過(guò)于重 型，需要產(chǎn)生及維護(hù)太多文檔。前期工作過(guò)長(zhǎng)，在開(kāi)始編碼之前已經(jīng)將大家的熱情消耗了很多。目前國(guó)內(nèi)外用于中小型項(xiàng)目的方法多采用敏捷的開(kāi)發(fā)方法，而其中用 得較多的是XP（eXtreme Programming） 方法。這種方法的特點(diǎn)是對(duì)系統(tǒng)進(jìn)行功能劃分，并以此為基礎(chǔ)進(jìn)行迭代開(kāi)發(fā)和增量集成。其優(yōu)點(diǎn)是，可以讓開(kāi)發(fā)人員在剛開(kāi)始迭代的時(shí)候，只在局部上把握系統(tǒng)的分 析及設(shè)計(jì)。而隨著迭代的進(jìn)行才慢慢從總體上把握系統(tǒng)的設(shè)計(jì)。從而避免了在一開(kāi)始即面臨著分析及設(shè)計(jì)整個(gè)系統(tǒng)的壓力，因此也不知如何下手。XP方法的編碼過(guò)程也十分有利于知識(shí)的傳播，讓開(kāi)發(fā)人員在開(kāi)發(fā)過(guò)程同時(shí)也學(xué)到其他人更多的知識(shí)。
由于XP方法的這種特點(diǎn)，適合于學(xué)生使用作為小團(tuán)隊(duì)開(kāi)發(fā)中小型軟件的方法。而我結(jié)合我們學(xué)生的特點(diǎn)，在XP（eXtreme Programming）方法的基礎(chǔ)上對(duì)其做了某些改變，使其更適合于學(xué)生使用。該方法以及其中某些建模方法在我們的團(tuán)隊(duì)經(jīng)過(guò)實(shí)踐證明是可行的而且能夠給我們的團(tuán)隊(duì)開(kāi)發(fā)帶來(lái)較好的效率。
由于XP方法強(qiáng)調(diào)用戶參與與反饋，并根據(jù)反饋的信息來(lái)確定下一步的開(kāi)發(fā)計(jì)劃與軟件下一步的設(shè)計(jì)方案。因此，可經(jīng)常對(duì)軟件進(jìn)行演示并評(píng)估來(lái)獲得更多的反饋信息，包括客戶以及開(kāi)發(fā)人員的反饋。
XP開(kāi)發(fā)方法可以以系統(tǒng)用戶目標(biāo)級(jí)用例為功能單位，以迭代以及增量集成為原則，逐步將一個(gè)個(gè)的用例所描述的功能集成到系統(tǒng)代碼中，從而最終完成系統(tǒng)的開(kāi)發(fā)。
該方法的具體實(shí)施步驟如下：
一． 系統(tǒng)規(guī)劃階段
首先，應(yīng)用面向?qū)ο蟮挠美治龇椒ǎ瑢?duì)系統(tǒng)進(jìn)行分析。得到系統(tǒng)的用戶目標(biāo)級(jí)用例的用例圖以及用例描述，描述用例時(shí)盡量用通俗的語(yǔ)言描述用例的執(zhí)行次序。然后可將每一個(gè)用例作為一個(gè)子任務(wù)用于安排迭代。關(guān)于用例分析方法可以參考《道法自然》一書(shū)。
盡 量做到一個(gè)用例只描述系統(tǒng)某一子部分的功能。切不要試圖使一個(gè)用例中包含對(duì)系統(tǒng)很多功能的描述。所有這些用例不需要詳盡的包含系統(tǒng)的所有功能，可以在開(kāi)發(fā) 的迭代周期間對(duì)用例進(jìn)行增加，刪除和更改。如果是優(yōu)先級(jí)特別高的增加，刪除或者更改也可以在迭代周期內(nèi)進(jìn)行。但是剛開(kāi)始所有這些用例是我們開(kāi)始的基礎(chǔ)，它 們至少應(yīng)該包含系統(tǒng)首次迭代所需實(shí)現(xiàn)的所有功能，而且最好所有這些用例能夠表達(dá)出系統(tǒng)總體上的一個(gè)概貌。而且用例描述的功能也可以作為以后驗(yàn)收測(cè)試的基 準(zhǔn)，并可以以用例為單位設(shè)計(jì)功能性測(cè)試。
然后確定每個(gè)用例的開(kāi)發(fā)優(yōu)先級(jí)以及開(kāi)發(fā)次序。并對(duì)每個(gè)用例所花的時(shí)間進(jìn)行粗略估算。從而確定每次迭代大概要完成的用例數(shù)目以及迭代時(shí)間。
二． 迭代設(shè)計(jì)階段
按照用例的優(yōu)先級(jí)以及開(kāi)發(fā)次序在還沒(méi)有實(shí)現(xiàn)的用例中，選出用例，為本次迭代安排迭代任務(wù)。安排的用例數(shù)目由每次迭代確定的時(shí)間和所需完成的用例數(shù)目決定。
不要提前安排下一次迭代的任務(wù)，而應(yīng)該在每一個(gè)迭代過(guò)程開(kāi)始之前的迭代會(huì)議上討論并安排本次迭代過(guò)程應(yīng)該做些什么。盡量不要急著去做那些沒(méi)有被安排進(jìn)入本次迭代過(guò)程的用例。有些用例要安排在下一次迭代任務(wù)中完成。因?yàn)閄P的原則是交流，簡(jiǎn)單和反饋。經(jīng)過(guò)這次迭代得到反饋信息之后。我們可能需要對(duì)用例的優(yōu)先級(jí)或其他信息進(jìn)行更改，或者刪除一些用例，下一次迭代的任務(wù)，在下一次迭代之前才知道。
確 定了本次迭代需要完成的用例之后，接下來(lái)是進(jìn)行本次迭代的分析和設(shè)計(jì)。設(shè)計(jì)盡量保持簡(jiǎn)單明了。如果設(shè)計(jì)過(guò)于復(fù)雜就想辦法用某種簡(jiǎn)單的東西替代。切記，保持 設(shè)計(jì)的簡(jiǎn)單易行，不要隨意添加功能。不要太早地加入所有的功能，以保持系統(tǒng)的整潔，額外的想法可以在以后加入。而且由于每次我們所需把握的都是表現(xiàn)系統(tǒng)局 部的幾個(gè)用例，所以進(jìn)行分析和設(shè)計(jì)的難度相對(duì)較低，而且也可以較容易的得到系統(tǒng)簡(jiǎn)單的設(shè)計(jì)。
目前，一般都使用UML建模技術(shù)作為面向?qū)ο蠓治黾霸O(shè)計(jì)的技術(shù)，對(duì)軟件進(jìn)行分析及建模。建立的模型不必過(guò)于詳細(xì)以及面面俱到，所建立的軟件模型記錄了目前系統(tǒng)的總體設(shè)計(jì)原理、類(lèi)的整體架構(gòu)、各個(gè)子系統(tǒng)間的類(lèi)架構(gòu)、調(diào)用、產(chǎn)生關(guān)系以及關(guān)鍵功能的“順序圖”。如何使用UML進(jìn)行建?？蓞⒖肌禪ML與模式應(yīng)用》，《敏捷軟件開(kāi)發(fā)》，《設(shè)計(jì)模式》等書(shū)。
如 果目前已完成的系統(tǒng)設(shè)計(jì)適合于添加本次所需實(shí)現(xiàn)的功能，并且容易做到。即采用目前的設(shè)計(jì)，在這個(gè)設(shè)計(jì)的基礎(chǔ)上添加新功能的設(shè)計(jì)，否則對(duì)目前的設(shè)計(jì)進(jìn)行重構(gòu) 并將新功能添加在其中。一般情況下，后者在前一至兩次迭代時(shí)可能會(huì)發(fā)生。因?yàn)閯傞_(kāi)始時(shí)對(duì)系統(tǒng)的了解不夠深入，隨著迭代的進(jìn)行，對(duì)系統(tǒng)的了解會(huì)慢慢深入。所 以，將會(huì)產(chǎn)生更適合于系統(tǒng)的設(shè)計(jì)，使系統(tǒng)更能適應(yīng)變化，添加新的功能。這個(gè)時(shí)候不要害怕對(duì)系統(tǒng)的設(shè)計(jì)進(jìn)行改變會(huì)帶來(lái)很大影響。因?yàn)?，每次迭代所需要完成?用例并不多，這樣使系統(tǒng)很能夠適合于變化。并且剛開(kāi)始時(shí)系統(tǒng)并不大，很容易對(duì)設(shè)計(jì)以及目前代碼進(jìn)行重構(gòu)。如何進(jìn)行重構(gòu)，可參考《重構(gòu)》一書(shū)。
完成初始設(shè)計(jì)之后，根據(jù)所產(chǎn)生的子系統(tǒng)以及各個(gè)可獨(dú)立編碼及測(cè)試的單元進(jìn)行分工合作。分成若干個(gè)小任務(wù)。這些小任務(wù)之間有先后順序，將小任務(wù)分配給每個(gè)人。確定編碼標(biāo)準(zhǔn)，編碼標(biāo)準(zhǔn)詳細(xì)到每個(gè)編碼細(xì)節(jié)的規(guī)定。
三． 迭代編碼階段
考慮到學(xué)生的特殊性，我們可能不能按照XP傳 統(tǒng)的結(jié)對(duì)編程方式進(jìn)行編程。但是，為了讓小組的每個(gè)成員均能夠熟悉系統(tǒng)整體的代碼并均勻分配工作量。并讓知識(shí)在開(kāi)發(fā)人員之間傳播，我們可以將采用一種稱(chēng)為 “接力棒”式的編程方式。即按照排好順序的任務(wù)進(jìn)行編碼。所以第一個(gè)開(kāi)始的編碼任務(wù)就是第一個(gè)小任務(wù)，也即是由認(rèn)領(lǐng)該任務(wù)的人接過(guò)第一棒，開(kāi)始編碼。在編 碼之前，每個(gè)人均應(yīng)根據(jù)自己任務(wù)的需求先寫(xiě)出測(cè)試用例，（該測(cè)試用例用于驗(yàn)收你的代碼是否完成了該任務(wù)以及是否有出錯(cuò)以及異常）再進(jìn)行編碼。
編碼過(guò)程中，每個(gè)人在代碼中一定要寫(xiě)足夠的注釋?zhuān)寗e人從代碼中就可以看出代碼中類(lèi)的架構(gòu)及聯(lián)系，還有編碼的思想。最后讓代碼有自解釋能力。
一個(gè)單元的代碼編寫(xiě)完成后用編碼前編寫(xiě)的測(cè)試用例進(jìn)行單元測(cè)試，如果測(cè)試有出錯(cuò)，在改錯(cuò)之后應(yīng)該增加新的測(cè)試用例再次測(cè)試，直到確保你的任務(wù)沒(méi)有錯(cuò)誤以及異常。然后將代碼和測(cè)試用例一起存入代碼庫(kù)，兩者同時(shí)成為系統(tǒng)的一部分。
執(zhí)行任務(wù)的人要在規(guī)定的時(shí)間內(nèi)完成自己的任務(wù)，一般小任務(wù)完成時(shí)間是一到兩天。小任務(wù)完成后，將完成的功能集成到系統(tǒng)里面并將“接力棒”傳給下一個(gè)任務(wù)的那個(gè)人。并向下一個(gè)人或者整個(gè)團(tuán)隊(duì)做開(kāi)發(fā)報(bào)告。報(bào)告內(nèi)容可以包括：
1. 本次你執(zhí)行小任務(wù)過(guò)程中所遇到的問(wèn)題以及解決方法。
2. 對(duì)你的任務(wù)的代碼做說(shuō)明以及對(duì)關(guān)鍵地方進(jìn)行解釋?zhuān)遣槐剡^(guò)于詳細(xì)，因?yàn)槲覀円呀?jīng)有類(lèi)間的架構(gòu)以及關(guān)系圖，同時(shí)你又在你的代碼中做了足夠的注釋。
3. 所采用的技術(shù)說(shuō)明。
這個(gè)過(guò)程同時(shí)也是促進(jìn)知識(shí)傳播以及大家互相學(xué)習(xí)的一種方法。
下一個(gè)人接過(guò)上一個(gè)人的“接力棒”，也即接過(guò)了整個(gè)系統(tǒng)的所有代碼。接著開(kāi)始編碼，用相同的過(guò)程方式執(zhí)行自己的任務(wù)，直到自己的任務(wù)完成，做完開(kāi)發(fā)報(bào)告并交給下一人。然后下一個(gè)又用相同的過(guò)程方式執(zhí)行自己的任務(wù)，這個(gè)過(guò)程一直持續(xù)到本次迭代過(guò)程的所有任務(wù)都已完成。
對(duì)整個(gè)迭代結(jié)果完成的系統(tǒng)進(jìn)行整合測(cè)試及優(yōu)化，看看是否完成了預(yù)定的功能以及是否有錯(cuò)誤及異常，當(dāng)有錯(cuò)誤時(shí)，改進(jìn)之后要引入新的測(cè)試用例，再次測(cè)試。本次迭代完成后要對(duì)目前已有代碼進(jìn)行重構(gòu)，關(guān)于重構(gòu)的原則，請(qǐng)看《重構(gòu)》一書(shū)。以相同的過(guò)程，進(jìn)行下一次迭代。迭代一直進(jìn)行直到小組成員一致確認(rèn)完成系統(tǒng)，然后對(duì)整個(gè)系統(tǒng)進(jìn)行整體測(cè)試以及整體代碼重構(gòu)。
四． 系統(tǒng)整體測(cè)試階段
對(duì)整個(gè)系統(tǒng)進(jìn)行整體的集成測(cè)試及最后的代碼重構(gòu)。關(guān)于系統(tǒng)整體測(cè)試的方法，參考有關(guān)的軟件工程書(shū)籍。而重構(gòu)方法以及原則請(qǐng)參考《重構(gòu)》一書(shū)。
參考資料：
《程序員》2003合訂本
Erich Gamma 、Richard Helm 、Ralph Johnson 、John Vlissides.
設(shè)計(jì)模式－可復(fù)用面向?qū)ο筌浖幕A(chǔ). 機(jī)械工業(yè)出版社
Robert C. Martin. 鄧輝 譯. 敏捷軟件開(kāi)發(fā). 清華大學(xué)出版社
Martin Fowler. 候捷、熊節(jié) 譯. 重構(gòu). 中國(guó)電力出版社
王泳剛、王泳武. 道法自然－面向?qū)ο髮?shí)踐指南. 電子工業(yè)出版社
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=411224
