在項目中成長

　　1　背景介紹
　　
　　2009年2月25日至4月17日，禮平老師提出將學院大三的“軟件項目管理”和“軟件項目開發實踐”兩項課程相結合，讓學生完成一個網上書城系統。項目歷時52天，在兩位老師的悉心指導下，整個學院的同學組成20多個團隊，開始了開發歷程，在這個過程中，著重培養了學生獲取知識、共享知識、應用知識、總結知識和傳播知識的能力。
　　作為其中一個團隊的小組長，我深為自己所在的團隊“喜羊羊與灰太狼”感到自豪，它對于我以及我們組員的影響都是“前所未有”，并且是長遠的。說其前所未有，緣于這次開發就如大學前幾年的一次總結，幫助我們匯總學習方法，融會貫通所學知識；說其影響深遠，緣于其對我們后期課程乃至下一屆或下幾屆學弟學妹們的幫助。
　　
　　
　　“喜羊羊與灰太狼”是一個由5個女生、2個男生組成的團隊。這是一個奇怪而又強大的組合，這7個人沒有任何相關領域的開發經驗，沒有任何組隊共同開發的合作經驗。在團隊中，有的活潑可愛，有的深沉內斂，有的認真細致，有的想法獨特，當組合在一起之后，我們有過爭執，有過失望，但是最終我們卻提交了一份令人滿意的成果，包括7個完整版本的源代碼和32萬字的文檔，還有每一位成員在未來學習中取之不盡的開發經驗。
　　
　　2　實際開發結果
　　
　　2.1　產品
　　產品功能如圖1所示。
　　
　　2.2工作量
　　編碼工作完成情況：
　　·C#代碼：9712行：
　　·數據庫代碼：299行；
　　·CSS代碼： 633行；
　　·存儲過程：1711行。
　　預計的生產效率：70行／人／日
　　程序的平均生產效率為：12355／7／14=126行／人／日
　　實際效率大于預計效率原因：
　　(1)開發團隊中有技術很好的成員，當遇到問題后，可以通過請教相互溝通，能夠很快地解決問題，不落下進度。
　　(2)開發人員自學能力好，通過第一、第二階段的開發，積累了一定的經驗，在后期三四階段的開發中將效率提高。
　　(3)所有成員都十分努力，同時團隊的管理機制很好，項目開發嚴格按照計劃進行，按時完成任務甚至超前完成，工作效率很高。
　　
　　2.3　對生產效率的評價
　　經過統計，整個網站系統的代碼數量為：C#代碼9712行，數據庫代碼299行，CSS代碼633行，存儲過程1711行，此部分都是開發人員手動開發的代碼，總共為12355行。前期的開發時間為14天。那么程序的平均生產效率為12355／7／14=126行，人／日，這已經大大超出我們所預計的生產效率70行／A／日。雖然量增多了，但是質量依舊控制在計劃之內。
　　經過統計，所產生文檔字數大約為：75870字。所統計的文檔包括需求、概要設計、詳細設計、數據庫設計、開發計劃、測試計劃等項目所需文檔。那么文件的平均生產效率為：75870／1000／7／7／=1.5千字數／人／日，這明顯不足于我們所預期的2.5千字數／人／日。這是因為我們還有其他很多文檔并沒有統計進去，例如小組的溝通，小組每周的會議記錄，小組每周的總結，個人總結等。因此，如果包括所有的文檔，估計能有3千字數／人／日左右。
　　因此我們的生產效率是能達到我們預期的要求的。
　　
　　3　開發歷程
　　
　　從以上的開發成果看，這已經是一個完整的開發項目。這不同于課程的開發作業，也不同于科技創新項目，課程初期，禮平老師接受同學們的建議，結合同一學期著重技術講解“軟件開發實踐”課程，提出共同完成同一個項目的觀點，兩門課程從不同的角度，即技術講解和項目管理指導兩個方面指導項目開發。這樣大大減少了課程內容的重復和沖突，集中了同學的時間和精力，讓我們更加具體細致地完成一個項目。
　　
　　3.1　相關課程的結合，集中學生經歷
　　隨著學校對于學生動手能力的要求提高，每一門專業課程基本都要求學生開發一個小型項目以增加對于專業知識的了解。然而過多的課程導致了較大的項目壓力，最后學院的同學們都不堪重負。實際上，學生一直在忙于完成各種不同的項目，并沒有達到實際的學習效果。
　　因此，當我們對禮平老師的教育理念還沒有理解時，我們只是覺得能夠將有關的課程相結合，是多么令人開心的事情。
　　“軟件項目開發實踐”課程老師由淺入深地對我們所遇到的技術問題進行指導：“軟件項目管理”課程隨著軟件生命周期的進行講述不同階段應該要采用的軟件工程項目管理方法。
　　然而，這不只是兩門課程的結合。在后期的軟件測試課程中，我們再次將自己完成的系統作為測試對象，對其中重要的功能點采用一套完整的測試方案，對其進行測試評估。因為被測系統是由自己開發，在測試過程中，我們可以很順利地對缺陷進行修復。
　　
　　3.2　軟件產品的開發生命周期同課程的結合
　　以軟件開發周期作為課程的大環境，兩位老師由淺入深，從需求分析開始，到設計、實現、測試和維護，一步一步帶領我們進行開發。
　　這像是對所有課程的總結，其中包括編程的基礎課程、Web開發的相關技術、軟件工程的相關課程、項目管理。在這樣一個短暫的不到兩個月的時間內，我們實現了基礎課程中的理論知識，我們重現各類開發和設計模型。在需求分析中，我們采用“面向對象”課程中的需求分析方法，力求通過標準的需求建模方法，明確系統功能和性能要求：在設計和開發過程中，我們采用迭代的開發方法，運用所學的Web開發課程和C#編程的內容；在測試階段，我們采用軟件測試課程中學到的測試策略，對每一個階段的測試，運用有關的測試工具開展測試過程。
　　現在課程結束已經快一年了，但在后期的像“軟件開發實習”這樣的課程中，我們卻總是不自覺地會將這次開發的經驗作為我們開發的依據。通過這樣一次完整的項目開發過程，我們了解了整個產品的開發周期，明確每個階段應該完成的任務，熟悉各個階段所可能遇到的問題以及應該采用的方法，甚至對于風險的估計都更加準確了。
　　
　　3.3　老師的指導，我們前行的指明燈
　　摒棄了傳統的教授方式，在禮平老師的教育理念指導下，我們開始走上講臺講述自己所遇到的問題、采用的解決方法，老師讓我們開展討論，讓我們團隊內部或者不同團隊之間共同交流來尋求解決方案。另一位“軟件工程實踐”課程教師，他采用問題驅動的教學方式，對我們不同開發階段遇到的技術問題進行匯總統一，提供出可選的技術解決方案，不同的團隊可以依據自己項目的特點采用合適的解決方案，并通過自學的方式了解該解決方案的技術細節，從而順利解決問題。同時我們也了解到了相關其他解決方案適用的情景，讓我們在今后的開發中“有法可依”。
　　在這場互動式的教學中，老師并沒有因為學生的主動而減輕了工作壓力，他們需要及時調整我們到合適的方向上，這得益于老師自身豐富的開發經驗。禮平老師會在我們停滯不前的時候，建議我們應該先完成一個靜態Demo來幫助了解需求：在我們對項目計劃感覺茫然的時候，他會拿出自己多年的開發經驗告訴我們，應該如何在計劃和開發上平衡時間；當我們對自身網站的特色定位不清楚的時候，他會讓我們注重細節的完善而不是新穎的功能，讓我們最終以一個穩定而完整的系統獲勝。當初的我們甚至以為一個項目開發就是一次集體編寫代碼，然而老師卻教會我們需要確定需求，將設計工作做得完整，實際的開發時間只需要兩個星期，事實確實是如此，在嚴格的項目進度控制中，組員在兩周之內竟然基本完成了系統功能。
　　就是這樣，起初懵懂的我們對“項目”的過程完全不知所措，而現在，任何項目到我們手中，無論其采用的技術如何，無論其要求時間是多久，我們總能得心應手地為其制定開發計劃并開展工作來實現它。這些知識在別人看來就像是與生俱來的，然而只有我們知道，正是通過了這樣一次完整的開發過程，讓軟件工程領域的知識成為我們自己的“天賦”，隨手拿來，即人們常說的“經驗”。
　　在這個成長的過程中，老師并沒有說，如果遇到了這樣的問題，有多少偉大的人發明了多少模型我們可以采用，這種模型的構建過程是這樣，那種模型的適用情況又是如何。若老師僅是這樣用生硬的文字告訴我們，用我們做20年學生的經驗來看，不出一個月這些知識就會模糊，不出半年這些知識又會變成新的知識。而在這一次的開發過程中，老師卻像路標，告訴我們正確的方向，或者可能的路線，而其中探索的過程卻是由我們來實現，前進的道路由我們自己來選擇。我們變得習慣于獨立思考，我們變得善于表達，我們開始熟悉這條成功之道。
　　
　　3.4　綜合性學習經驗，我們最終的目標
　　獲取知識(自學)、共享知識(團隊工作)、應用知識(解決問題)、總結知識(創新)和傳播知識(溝通)的能力，這是CDIO要求學生在基于項目的學習過程中需要得到的綜合能力。
　　我們從不糾結于某一個技術問題，從不局限使用某一種開發模型，項目的內容也不限定，通過一次完整的項目開發過程，著眼于學生綜合能力的提高，培養學生成為能夠與國際接軌的高等工程師。
　　禮平老師強調我們要不斷總結，并把這個過程運用到其他地方，不僅是軟件產品的開發，從確定需求、制定計劃、設計和實現的過程來看，我們可以將各種模型甚至運用到制定個人規劃，還有那些需要考研的同學的考研計劃中。在項目完成后，老師欣喜地翻閱每一位同學的心得體會。作為小組長我也看過組內每一位成員的總結，每個人的教訓和經驗都不盡相同，也許這就是我們學習的目的，每個人都能有所收獲，從不同的角度，不同的領域培養不同的能力，收獲不同的知識。
　　
　　3.5課程考核，不僅僅是分數
　　與往常的課程考試不同，我們采用的考核方式是多樣的，包括平時的討論、組內的互評，答辯的結果和最終的產品質量。
　　平時討論作為考核的內容之一，增加了平時課堂討論的參與度，使得同學們更加積極地投入到課堂交流，為每一次的成果匯報作好充分的準備，積極主動地思考解決方案。
　　組內互評是我們的一大特色，我們采用禮平老師號稱的“雷達圖”來評定每一位成員在開發過程中的表現。這種評定方法通過不同方面評定每個人的能力，讓每位成員能夠更加清楚地認識自己，并依據其在組內的貢獻作為評分依據，計算出組內互評的最終得分，“雷達圖”示意圖如圖2所示。
　　答辯是最后的考驗，我們為此做足了準備，甚至排練了多次。經過之前多次的中期檢查，我們慢慢學著如何更好地展示和表達我們的成就，讓老師和其他項目組在答辯的短暫十分鐘之內看到我們的努力和優秀的產品。終期答辯推動著我們不斷完善系統，因為考慮到老師要進行任何操作，提出各種疑問，所以我們從用戶的角度考慮一切有可能出現的操作，盡可能地保證系統的實用性、便捷性和穩定性，這樣大大提高了產品的質量。在后期的總結中，我們發現這樣的方式運用到實際的產品開發中也是如此的有效，因為時刻從客戶的角度考慮，是保證產品質量的重要因素。
　　正是這樣的考核方式，不僅讓我們學會如何有效表達、了解自己，更在一定程度上學會考慮如何成就一個成功的項目。
　　
　　3.6　團隊合作，我們最寶貴的經驗
　　人際交往技能即團隊協作和交流，是CDIO工程教育模式所提倡的應該培養學生的技能。對我們來說，團隊培養的協作關系是我們寶貴的財富，團隊合作也成為我們最寶貴的經驗。
　　為了能夠順利完成每個階段的計劃，我們的小組成員常在一起整合到凌晨，為問題開會討論好幾個小時，我們會將設計制定的細致再細致，只為其他隊員能夠減少理解時間。當然，因為我們性格各異，所以也會對他人的行事風格不理解，也會出現推脫責任的時候，也有不能達成一致意見而發生爭執的時候。可是因為大家有共同的目標，抱著對項目負責的態度，我們逐漸建立起默契，漸漸開始為對方考慮。每個小組成員都很細致地對待自己負責開發的模塊，盡量減少出現缺陷，避免其他功能的開發遭到停滯或者增加整合人員的工作量。
　　很多人都知道，團隊合作會保證項目的順利進行，減少項目風險，構建一種良好的團隊氛圍，而對于我們來說，團隊合作更讓我們關注自己的工作，在很大程度上保證了產品開發的質量。通過團隊開發的方式，讓我們在開發過程發現協作的意義，更讓我們收獲了友誼。
　　
　　4　CDIO之我見
　　
　　禮平老師的課堂帶給我們收獲和成果，作為軟件學院的學生，作為CDIO工程教育理念的受益者，我們有自己的理解和感受。
　　在有限的大學4年教育中，我們希望自己能夠承受一定的壓力并收獲有用的知識，能讓我們在未來的職業領域有所發展。同時我們了解，作為工科學生，工程實踐經驗尤為重要，而從小學到中學，理論為主的教學模式讓我們深感自己經驗不足，動手能力不強，對于實際的公司項目更是束手無策。成為社會肯定的具有良好綜合素質的畢業生，這是我們對自身的要求，也是我們對于學校教育的期望。
　　CDIO這一教育理念很好地把我們從繁重又重復的課業項目中解脫出來，且更好地發揮了我們的自主能動性，讓我們富有熱情地投入項目，在這個辛苦的過程中享受成長。就如這次的開發，作為“軟件項目實踐”、“軟件項目管理”、“軟件測試”三門相關課程的共同項目，前后統一并相互關聯，老師扮演領航者的角色，用他們自己的工程項目經驗指導我們，讓我們花精力和時間去了解真正的項目流程，在項目開發中了解工程項目的全部生命周期，鞏固工程基本知識，發展個人技能，提高綜合能力，增加開發經驗，更讓我們在團隊開發過程中學會如何與團隊成員溝通交流，更好地進行團隊開發。
　　至今，“喜羊羊與灰太狼”團隊的7名成員都因為我們的“網上書城”而感到驕傲，我們的努力凝聚于那32萬的文檔和最終的系統中。項目開發的知識已經成為我們自己的財富，所有文檔不僅成為了我們后期開發項目的參考模板，更被下幾屆的學弟學妹用來作為學習案例。我們為此感到自豪，也希望同樣的教育模式可以幫助更多的