1. 程式人生 > >高階軟體工程實踐總結作業

高階軟體工程實踐總結作業

一、請回望第一次作業,你對於高階軟體工程課程的想象

1)對比開篇部落格你對課程目標和期待,“希望通過實踐鍛鍊,增強計算機專業的能力和就業競爭力”,對比目前的所學所練所得,在哪些方面達到了你的期待和目標,哪些方面還存在哪些不足,為什麼?

開篇部落格對這門課的期待是:

希望能努力跟上隊友的腳步,努力增強自己的團隊合作能力,能理解到學到的新知識。

一共是三項期待,

  • 第一項:突然覺得以前的想法還是簡單了,天真的想著跟上隊友的腳步就是變得和他一樣強,但那時並未明白,其實每個人的強大並不一樣,在團隊合作中,每個人應該展現的,是自己相對較強的部分;在團隊面臨缺少角色的情況時,就算能力不足也應該努力撐住。所以我並不需要和隊友一樣強,強者已經扮演了強者的角色了,團隊角色飽和了。其實還有另一個thinking,想要追趕上強者,你完全不知道還要付出多少努力。

  • 第二項:在增強團隊合作能力方面,我覺得多少是有了些感悟和經驗的,但可以感覺到的是,合作的路是漫長的,可以漫長到一直伴著你的餘生。雖然是第一次參與如此深度的合作,但這次總體來說確實算是挺愉快的,但已經明顯感覺到了若是沒有持續不斷的繼續合作的經歷,是無法探索到更高階的團隊合作的藝術真相的。

  • 第三項:能理解學到的新的知識,這一點是三點中最欣慰的,這門課程教授的軟體模式還是很實用的,我也get到了不少,在實際專案開發中使用設計模式確實會比較可靠,可以說設計模式是前人總結的經驗,用設計模式寫程式會比不知道設計模式的人自己摸爬滾打效率高得多。

  • 第一項和第二項部分達到,尚有不足,第三項勉強達到。

2)總結這門課程的實踐總結和給你帶來的提升,包括以下內容:

1、統計一下,你在這門高階軟體工程實踐中,完成了多少行的程式碼;
1w行左右

2、高階軟工實踐的各次作業分別花了多少時間?(做一個列表)

作業 花費時間 作業 花費時間
軟體工程第一次作業-準備 7h 專案Alpha衝刺Day8 9h
軟體工程第一次作業 2h 專案Alpha衝刺Day9 8h
軟體工程第二次作業 4h 專案Alpha衝刺Day10 9h
設計模式第一次作業 5h 專案Alpha衝刺Day11 10h
設計模式第二次作業 7h 專案Alpha衝刺Day12 10h
設計模式第三次作業 7h 專案Alpha衝刺測試隨筆 3h
團隊展示 3h 專案Alpha衝刺總結隨筆 5h
選題報告 4h 專案Alpha衝刺集合隨筆 0.5h
選題報告ppt 4h 專案Alpha衝刺事後諸葛亮 3h
選題報告評審表 1h 專案Beta衝刺預備 3h
選題部落格隨筆 4h Beta衝刺第一天 8h
需求分析需求分析部落格隨筆 8h Beta衝刺第二天 7h
需求分析PPT和評審表 8h Beta衝刺第三天 5h
需求分析報告 8h Beta衝刺第四天 8h
專案Alpha衝刺Day1 10h Beta衝刺第五天 6h
專案Alpha衝刺Day2 8h Beta衝刺第六天 7h
專案Alpha衝刺Day3 10h Beta衝刺第七天 9h
專案Alpha衝刺Day4 9h Beta衝刺總結 5h
專案Alpha衝刺Day5 8h 使用者調查報告 6h
專案Alpha衝刺Day6 7h Beta衝刺集合 0.5h
專案Alpha衝刺Day7 8h 個人實踐總結 8h

3、哪一次作業讓你印象最深刻?為什麼?
是那次專案更改的時候吧,因為題目的更改,我們花了很多時間去做新的題目。為了那一份文件、一份PPT、一份部落格,具體內容已經模糊了,但兩個場景卻還在腦海中揮之不去。一是空曠的實驗室、三臺筆記本、三個對著螢幕敲鍵盤的人。第二個是,半層高窗戶,一張桌子,三個人,三個被扔下來被接住的書包。為什麼記住了這個場景,我想若只是一人的回憶,便是平常,若是和夥伴的共同回憶,那便是稀有的珍貴體驗了。

4、累計花了多少個小時在高階軟工實踐上?平均每週花多少個小時?
從選題到專案的beta版本結束一共花了222小時,完成系統一共進行了三週的衝刺,平均每週74小時。

5、學習和使用的新軟體;
MySQL workbench對mysql資料庫的操作。

6、學習和使用的新工具;
學會了github的一些操作,github是目前最流行的開源庫,也是一個優秀的程式碼管理平臺。

7、學習和掌握的新語言、新平臺;
對Java的進一步熟悉,對myeclipse開發平臺進一步的熟悉。

8、學習和掌握的新方法;
學習並初步掌握了工廠模式、策略模式、狀態模式等模式設計方法。

9、其他方面的提升。
對團隊合作進一步的認識,對自己能力的進一步認識,對自己性格更深入的瞭解,發現了自己在團隊協作中的許多不足。

二、寫下屬於自己的人月神話——個人或結對或團隊專案實踐中的經驗總結+例項/例證結合的分析

  • 1)巨集觀計劃和實際實施的矛盾
    由於缺乏專案經驗和對專案具體細節的預估。我們當前制定的非常合理的安排,到具體實施時可能會遇到很大的問題。比如有一次,在具體執行當日計劃時,我們有兩人的任務提前完成了,而剩餘一人的剩餘工作量仍然很艱鉅,這個是工作分配不均衡,是一個常見問題,也是很影響整體進度的一種情況,若是有經驗的團隊必然可以事先預見這種情況,準備了對應的策略,將工作量進行再分配等操作。而我們顯然沒有這樣的經驗和思想準備。

  • 2)衝突的解決
    解決衝突的重要性,團隊中發生衝突時,團隊的工作會停滯下來,所有人的進度都會被拖後,爭議不解決,影響越嚴重。所以對於小團隊來說,解決衝突的規則是非常重要的。我們小組在第一次衝突出現時就確立了一個衝突原則,“少數服從多數”,這一原則被認可度極高,並且事實證明,其對快速結束爭議,取得小組進度有著極好的效果。

  • 3)完不成的任務
    論度量的重要性。開發專案是一種藝術嗎?我認為每種工作都可以是一種藝術,開發專案也是這樣,你可以簡單的實現功能,完全不管程式碼是怎麼樣,實現了功能便是達到了目的。作為一項藝術,程式碼具有被打磨的性質,打磨變數的合理性,打磨程式碼的重用性,打磨程式碼的簡潔性,這幾點要求做到的話會比單單實現功能多花上很多時間,再高階一點的會加上註釋,再繼續打磨註釋的表達力,這就需要更強的功底了。所以開發軟體時,對軟體的功能一定要有所限制,對工作要具有一定的標準,不能想加什麼功能就加什麼功能,時間是有限的,你可能會完不成這任務了。

  • 4)合適的角色
    之前沒有過這麼緊密的組隊體驗,也許有過,但能做的僅僅是聽從安排罷了,但這次組隊人數較少,總有你能發揮作用的地方,你總該去找到一個適合的角色、一個適當的位置。我想團隊中最重要的莫過於你能清楚地知道你該扮演什麼樣的角色,發揮什麼樣的作用。

三、對下一屆實踐的建議,或者對於開學初的你,對於大一的你,對於開學初的我,你有什麼想建議和告知的呢?

對下一屆的學弟學妹們的建議,也就是2019屆學弟學妹吧,我想我會說,如果你們也有機會在實驗室一起奮鬥到深夜,一起爬窗逃離實驗室的話,記得那時,輕輕地撣去身上的塵,擡頭找一下夜空中的明月。月光下,你就不會去抱怨晚上的寒冷,而是學會了體會內心的溫度了。匆匆歲月過往,我們會忘記很多,有大事,有小事,那曾經讓你如臨大敵的許多問題,現在也都一笑而過,相忘於江湖了。你們努力去創造的,是自己最終能記住的事。

四、分析一下自己所處的團隊。軟體工程實踐是大學裡少有的認真的團隊協作經驗。《構建之法》上說團隊的發展有幾個階段,你的團隊都經歷過麼,最後到達了“創造”階段了麼?(參考《構建之法》第17章 人、績效和職業道德)

萌芽階段(Forming),在這一時期,團隊成員剛剛接觸到團隊的宗旨,同時很可能剛剛互相認識。團隊的目標沒有真正達成一致,而成員則非常依賴於團隊領導的指導。

磨合階段(Storming) 團隊中的一團和氣只能維持一小段時間,大家不得不認真地面對問題,開展討論。隨著討論的深入,有些人會沉不住氣,就會出現小的意見分歧和衝突。這些衝突不一定都是技術問題,也許是關於角色、職責、相互關係,甚至是各自性格、文化的衝突。

規範階段(Norming),成員們意識到光爭吵是沒有用的,大家還是要協同作戰。成員們就很多事情取得了一致。角色和職責定義得非常清楚。團隊還進行過有趣的團隊建設活動。這一時期的團隊有如下特點。

創造階段(Per-forming)。共同的遠景不再是空話,而是實實在在的階段性成果。這些成果鼓舞了士氣,整個團隊成為其他團隊羨慕的物件。高度自治,不再需要領導的時時教誨與介入。不同意見仍會出現,但是成員都以一種積極的心態和方式來解決。團隊成員相互支援,互相依賴並保持各自的靈活性。團隊成員之間都比較熟絡,同時也互相信任,個人可以放手獨立工作。角色和職責能夠根據專案的要求自然地轉換,沒有人為此擔心或發牢騷。

--引用自《《構建之法》閱讀筆記06

  • 萌芽階段:
    我們確實具有不斷探索適應這個團隊的新環境,小心的探知團隊成員的行事方式,儘量多的發表看法這些特徵,而此階段正確的做法是:

    領導要快刀斬亂麻地決定一些重要的問題,讓團隊在短時間內看到一些成果。
    --引用自《《構建之法》閱讀筆記06

我們隊一開始成型時就開展了小組第一次會議,會議上進行了簡單的交流,團隊任務的分析和一次共同完成任務的體驗。但幸運的是,小組中隱隱出現了一個leader角色,這個角色的出現意味著我們的小組有了可以短時間內完成一定成果的能力。我想這正與萌芽階段相契合。

  • 磨合階段:
    我們都來自不同地方,本科專業也各不相同,所以是各自性格、文化的差異,使我們在一些事情上的看法不同,發生衝突,此階段正確的做法是:

    團隊領導最好讓矛盾和分歧充分地暴露,將各種衝突公開化,並且學會傾聽、理解和調整。
    --引用自《《構建之法》閱讀筆記06

很幸運的又一點是,我們組長是一個非常有趣的人,在團隊成員的意見分歧之間往往會是那個 緩和化解矛盾的人。現有事實說明,他做的不錯。 但由於成員數量較少,所以暴露的衝突不夠豐富,我想這就是我們的磨合階段。

  • 規範階段:
    在團隊的後期,我們已經意識到了,針對當前團隊任務,我們要做什麼、不做什麼。小組成員之間開始意識到並學會尊重各人的個性。這個時期我們有一個時常催促進度的leader,一個調解斡旋矛盾的角色,我想第三階段我們已經探索到一部分了。至於團隊第三階段的其他未達成部分和團隊的第四階段,我想,我們的路,還遙遙可期。

五、怎樣證明你學會了軟體工程?

1)研發出符合使用者需求的軟體

我們的軟體確實是滿足了我們初期設想的各種需求的,所謂必須有的功能我們都有了,有必要的功能我們都加了。

2)通過一系列工具,流程,團隊合作,能夠在預計的時間內釋出 “足夠好” 的軟體

從一開始的選題報告,到後面的需求分析,到系統的具體開發、測試。alpha階段進行了各成員的詳細分工,專案燃盡圖從總工作量走到了0工作量。開發時間歷時兩週。經歷了alpha版本和beta版本的衝刺,在組員的相互督促下,除了實在沒可能完成的任務,每天的進度我們都會盡量完成,因此可以在一定程度上保證進度不被延後,保證一定時間內可以完成特定功能。

3)並且通過資料展現軟體是可以維護和繼續發展的。

我們的系統以選題報告為開端,相繼進行了需求分析、原型設計、Alpha階段的開發及測試、beta階段的開發及測試到最終完成都有相應的報告和記錄。
選題報告:
需求分析:
Alpha階段的開發及測試、beta階段的開發及測試:

六、個性發揮,包括圖文、照片和創意等

曾經,一個靈魂坐上一列火車,去向了未知的遠方,故事中沒有描述列車停下來的地方,也許是一片有兩幢風車的草原,也許是密佈蜿蜒小路的世外村莊,亦或是高樓大廈間的繁華都市…

人在面臨選擇之時,在猶豫彷徨之間,總會渴望能找到多一點的理由來佐證自己想要的選擇會更加合理,而在合理和你想要之間,你會走上那條路呢?