對比開篇博客你對課程目標和期待,「但願經過實踐鍛鍊,加強計算機專業的能力和就業競爭力」,對比目前的所學所練所得,在哪些方面達到了你的期待和目標,哪些方面還存在哪些不足,爲何?
本身在項目管理上有了一點進步以及跟隊友溝通和交流,任務的安排上,以及對整個項目的理解有了進步,可是編程方向始終仍是個人弱項,編程能力不太行,本身對編程的興趣不太濃厚,也比較少編程。
總結這門課程的實踐總結和給你帶來的提高,包括如下內容:
1)統計一下,你在這門課程中,完成了多少行的代碼;
差很少三四百行吧。
2)軟工的各次做業分別花了多少時間?(作一個列表)php
做業 | 時間 |
---|---|
軟工網絡15我的閱讀做業1 | 1.5 |
軟工網絡15結對編程練習 | 6 |
軟工網絡15我的閱讀做業2——提問題 | 3 |
軟工網絡15團隊做業1——團隊組隊&展現 | 1.5 |
軟工網絡15我的做業3——案例分析 | 4 |
團隊做業3——需求分析與設計 | 3 |
團隊做業2——團隊計劃 | 2 |
軟工網絡15Alpha階段敏捷衝刺 | 3 |
團隊做業6——展現博客 | 2 |
團隊做業5——測試與發佈 | 5 |
alpha階段項目複審 | 1 |
團隊做業7——alpha階段之過後諸葛亮分析 | 1 |
我的做業4——alpha階段我的總結 | 1 |
beta版驗收互評 | 1 |
我的做業5——軟工我的總結 | 1.5 |
3)哪一次做業讓你印象最深入?爲何?
提問題的環節吧,作得很難受,有時候會有問題,可是並不能強求提問的數量而不在於質量。
4)累計花了多少個小時在軟工上?平均每週花多少個小時?
累計花了多長時間?我只知道每週都要花費挺長的時間的,天天都要好幾個小時,好比開會,安排任務,有時候忙點本身的事情都沒什麼時間。每週十幾個個小時吧,尤爲是衝刺階段,特別忙。
5)學習和使用的新軟件;
碼雲,leango
6)學習和使用的新工具;
墨刀,微信web開發工具
7)學習和掌握的新語言、新平臺;
微信小程序開發平臺,js,Android、php,博客園、問卷星
8)學習和掌握的新方法;
學會了分配任務,溝通交流以及團隊協做。
9)其餘方面的提高。
團隊協做能力、溝通能力、編程能力、學習能力。web
首先,須要有一個好的想法,同時也須要一個好的領隊,能夠是編程大佬,其次,遇到問題先思考再需求幫助,若是有個團隊牛逼人物幫忙解決的話,那就會事半功倍。還有就是須要對時間任務安排好,有想法就去作,可是想法必須符合實際要求,而不是爲所欲爲,天馬行空的,要懂得量力而行。最後,在溝通上以及管理協調上也應該多注意一下,這在之後的工做上也是頗有用的。最近,本身去投遞了一家公司的產品經理,大概瞭解了一下,產品經理須要讓用戶的需求用在軟件上實現得以知足用戶需求。同時須要具備一些溝通能力和創新能力,也要安排好任務的分配,統籌。
編程能力很重要,別落下功課了,有一些課程不是及格就夠了,若是你想變得優秀,那麼你就須要多花費一點時間。據說過一句話,若是你不肯意吃學習的苦,那麼你之後就要吃生活的苦,若是你多吃學習的苦,那麼你之後就會少吃點生活的苦。 建議:別隻是爲了任務而進行換人,應該要有點想法和分析,符合這個項目的實現。
我本身實在換人階段被調走的,本身之前的團隊作得蠻成功的,由於算是有大佬的幫忙,因此一切都進展得蠻好的,經歷了萌芽階段,磨合階段,規範階段和創造階段,最後達到了創造階段。後面這個團隊仍是須要增強,團隊幾我的編程能力都相對比較薄弱,因此編程方面很吃力,經歷了萌芽階段,磨合階段,規範階段和創造階段,創造階段相比較理想的仍是有挺大的差別的。
經過最近的學習,團隊的努力,研發出符合用戶需求的軟件。這個微信小程序也已經公佈了,有必定的用戶和實際用戶,最近都忙着期末考,就沒有再進行繼續努力了。
研發出符合用戶需求的軟件
必須公開發布,有實際的用戶,必定的用戶量和持續使用量 (3 天后能保持10 - 100個用戶);而不是: 作沒有用戶使用的軟件
經過一系列工具,流程,團隊合做,可以在預計的時間內發佈 「足夠好」 的軟件
有項目規劃/需求/設計/實現/發佈/維護,有定時的進度發佈 ; 而不是: 經過臨時熬夜,胡亂拼湊,大牛一人代勞,延遲交付等方式糊弄
而且經過數據展示軟件是能夠維護和繼續發展的。
而不是 找不到源代碼,代碼無文檔,代碼不能編譯,沒有task/bug 等項目的發展資料
請在隨筆中用數據證實上述內容或側重選擇之一。編程
參考論文文獻:
[1] Stamelos I, Angelis L, Oikonomou A, et al. Code quality analysis in open source software development[J]. Information Systems Journal, 2002, 12(1): 43-60.
[2] Boehm B W, Brown J R, Lipow M. Quantitative evaluation of software quality[C]//Proceedings of the 2nd international conference on Software engineering. IEEE Computer Society Press, 1976: 592-605
[3] Samoladas I, Stamelos I, Angelis L, et al. Open source software development should strive for even greater code maintainability[J]. Communications of the ACM, 2004, 47(10): 83-87小程序