【Beta階段】展現博客

Beta階段展現博客

 

blog software buaa

 

 

一、團隊成員簡介

 

 

 

 

	Email：qianlxc@126.com Free time：8:00 7:00 a.m ~ 11:00 12:00p.m Introduction： 我是一個熱情的人。開朗的人。活潑的人。(小編以爲用逗號分開比較好 我喜歡交際，喜歡溝通。 我不是碼農，我是工程師。 Role：寫代碼，總體框架與結構的設計，負擔溝通接洽各個成員的責任。 Duty： Project Mannager(項目經理) Personal Homepage：http://www.cnblogs.com/SivilTaram/
Email：309143859@hotamil.com Free time：不上機的晚上 Introduction： 我以爲本身的專業能力在這個團隊當中是最差的，可是我會努力學的……其實以爲目前市場上的軟件功能已經逐漸覆蓋包圍，對於咱們這樣一個小團隊來講要開發新的功能確實不太容易，因此我我的的想法是着眼於身邊，在北航甚至是計算機學院的背景下作一些東西。 Role：任何職務（主要我以爲本身都不太會）組織要我幹什麼我就幹什麼 Duty： Reporter(文檔撰寫人員) Personal Homepage：http://www.cnblogs.com/lydiavitani/
	Email：1143974257@qq.com Free time：晚8點-晚12點 Introduction： c，java，安卓開發。此次團隊項目我更傾向於作安卓應用或開發安卓遊戲，主要是使用的是咱們更加熟悉的java語言。同時java也很是適合協做開發。 Role：運動教練，寫代碼，協調工做=。=（你還賣萌 Duty：Programmer(代碼開發人員) Personal Homepage：http://www.cnblogs.com/mnb10109/
Email：634208109@qq.com   Free time：早上4八點半到晚上八點半，並非空閒時間，12小時工做時間。 Introduction： web後端，滲透測試。 對團隊見解：咱們差個牛逼的前端畫網頁。。目測全系也沒有。。。。。。 軟件工程見解：軟工主要是學管人的，團隊合做，這倆我都不擅長，我只提些架構上的建議，一切聽領導安排。（確實差個好前端，快來我的跳槽呀！ Role：後端開發 Duty：Back-end(實力後端) Personal Homepage：http://www.cnblogs.com/hoerwing/
	Email：504037668@qq.com Free time：週一下午及晚上，週五下午，週末至少一天 Introduction： 忽然發現我能夠不把我的介紹搬上來呀哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈! Role：前端設計 吹比擔當 Duty：UI Designer(UI設計師) Personal Homepage：http://www.cnblogs.com/kibbon/
Email：songxh_scse@126.com Free time：8:00~11:30am（週四）   7:00~11:00pm（周1、三） 以及一些零散時間 Introduction：我的編程能力不強，目前仍然在學習之中，可是我願意學習，但願在之後的學習工做中與你們一塊兒進步。 Role：可寫代碼，也能夠測試，還能夠提供一些想法 Duty：Programmer(代碼開發人員) Personal Homepage：http://www.cnblogs.com/songxh-scse/

  

 

二、目標與實際數據

用戶數據永遠是咱們的項目最關心的，首先來講說相比於α階段，β階段的咱們有了哪些用戶量上的增長或改變。在β階段，咱們的目標有效註冊用戶是1000人，目標網站流量是25000次。

   

2.1 用戶註冊數

α階段團隊展現時，物理實驗網站的實際註冊用戶數是剛到300。截止至2016/1/9日12：00，物理實驗網站的有效註冊人數是800餘人左右，達到了指望的80%。

   

2.2 域名的啓用

在α階段展現時，咱們的域名備案尚未審批經過，從11.23日備案經過後，域名的做用逐漸發揮，如今受訪域名buaaphylab.com已經佔據受訪流量的1/4。

   

2.3 訪問流量數

α階段展現時，物理實驗網站的總瀏覽次數纔剛剛過3000。現在一月半過去了，咱們的網站也蓬勃發展了一個半月，雖然由於實驗在校歷第16週週二就已經中止了選課，從而致使總體流量的增長量在趨勢上呈下降態，可是流量總數是很是可觀的。從cnzz的數據統計獲得，截止至2016/1/9日12：00，咱們的網站流量總數已經超過了25000，達到了一個較爲可觀的數字。如下爲cnzz的數據統計結果：

   

2.4 活躍用戶數

在α階段展現時，咱們的物理實驗網站交流羣裏的人數剛達到160人次，在β階段結束後，已經達到了272人次。如下爲羣介紹與成員狀況

   

三、典型用戶與場景描述

   

3.1 典型用戶

名字	小紅
性別	女
職業	某校通常學院大三學生
物理知識層次與能力	通常般
動機	不一樣的物理實驗老師在數據處理上可能會有不一樣的要求，在處理特定的物理實驗數據時，和自動生成報告的數據組數不一致。
目的	但願可以有個小工具幫本身處理數據，並有必定的參考與指導意義。
困難	因爲數據組數不肯定，但願能夠動態增長數據或者減小數據組數。
用戶比例	約佔同屆學生20%
典型場景	小紅在作1011，這個實驗是須要使用逐差法作的。可是今天這個給小紅講課的實驗老師好像有點不同…哎？老師，爲何其餘同窗以前作這個實驗的時候只須要10組數據，而咱們此次就須要15組數據進行逐差處理啊？老師："我帶這個實驗帶5年了，上個人實驗就必須按我要求的方法來處理"。小紅內心一陣苦澀，任性的老師真多，若是有一個可以動態計算多組數據的逐差結果，而不是隻能經過固定組的數據生成報告就行了。想着想着，小紅進入了物理實驗網站，找到了小工具，逐差法計算器，輸入數據，按照需求還動態增長了須要的組數。小紅心想："這麼靈活的小工具，真是造福大衆啊"。

 

名字		小黑
性別		男
職業		某校學院大三學生
物理知識層次與能力	通常般，其實主要是電腦差，跟物理不要緊
動機		預定實驗放出的機會比較少，很難搶到。
目的		但願能有人搶到物理預定實驗後跟本身一塊兒去作。
困難		僧多粥少
用戶比例		約佔同屆學生90%
典型場景		"你昨天搶到預定實驗了嗎？""別提了，提起這事我就傷心，我那破電腦，搶個預定實驗簡直就是作夢啊。""那你沒試過在buaaphylab.com的論壇裏發帖請求別人帶你去一塊兒作預定實驗嗎？預定實驗還能夠一塊兒作，多好""你說的是真的嗎？那我如今就去發帖求人帶預定實驗了，這論壇真是好東西！"

 

名字	小明
性別	男
職業	某校學院大三學生
物理知識層次與能力	若是夠高，能不用考試嗎？
動機	烤漆到了，物理實驗的複習要撿起來了
目的	但願可以發帖詢問本身關於物理實驗考試題目的疑問並共同解決
困難	物理老師的答疑時間又過短，人太多，而且物理老師回答的老是那麼幾個問題，重複率過高。
用戶比例	約佔同屆學生70%
典型場景	烤漆到了，物理實驗的考試立刻就要來了，"啊，我物理實驗什麼都不會，考試該怎麼辦呢？這道題我沒看懂唉，但是物理老師的答疑時間又過短，態度很差不說，還給不出一個有理有據的答案。"小明心想：要是有個論壇可以用來交流提問各類基礎物理實驗有關的問題該多好啊，那樣你們回答過的問題也能保留下來，下一屆的同窗還能看到，真不錯。說着，小明點擊進入了連接，點擊社區進入了討論版，發出了第一個帖子：論物理實驗的複習。

   

3.2 場景描述

以上就是咱們β階段推出的功能所面對的三類特定用戶，能夠看出三類用戶都是學生。

α階段後，咱們反思了關於項目初始的定位，最終在反覆思量後取消了針對老師的服務，作成了專門針對學生的物理實驗網站服務平臺。作出這個決定的緣由是多方面的：一方面是由於在α階段後，我曾和物理實驗組的負責老師的接洽，老師表示不太願意接受這樣的平臺，實驗組的組長是一位年紀較大的老師，她負責出物理期末考試題，由於年紀緣由更加傾向於傳統意義上的答疑方式，不但願經過網上論壇的方式。另外一方面緣由是，若是要把物理老師接納進論壇的話要對物理老師進行實名制的認證，這將耗費比較大的精力，團隊在商量後決定全部feature的開發所有基於學生用戶。

在確立基本可能的需求後，咱們對用戶來了一次問卷調查，問卷調查的結果顯示：

• 關因而否須要論壇功能，有84.62%的人以爲須要，說明論壇功能有壓倒性需求。
• 有69.23%的人認爲有必要認證郵箱，30.77%的人認爲不須要。關於這一點，說明認爲須要認證的人仍是大多數，可是也有很多的人認爲並不須要認證這樣的功能。
• 對於本身預定了實驗是否願意在論壇上發帖求組隊這一點，92.31%的人願意跟不認識的人一塊兒作預定實驗，這是咱們團隊開始沒有想到的。
• 而論壇中是否須要考題討論區，絕大多數的人（92.31%）天然都認爲是須要的。
• 對因而否接受論壇須要經過賺取少許積分才能下載實驗報告，69.23%的人是不肯意接受的，可是這也在咱們的意料之中，畢竟之前是不須要積分的。這樣的機制是考慮到網站的長久發展而設想的功能。
• 積分制對論壇是否有促進做用，數據上並無特別明確的結果，23.08%的人會更願意水帖，30.77%的人以爲不肯意，46.15%的人以爲不知道。

調研的結果代表積分制可能會致使流失用戶，因此β階段將積分制的功能暫時擱置。而論壇的功能和小工具的feature符合咱們β階段的基本功能，說明β階段的計劃是可行的。

 

四、團隊管理與協做

4.1 分工協做

單核心

　　α階段中團隊管理中主要存在的問題是，做爲項目經理的我在整個流程中發揮的做用太大。一旦失去我這個中心，整個項目的各個部分都將處於一種停滯狀態。每一個隊員的直接交互人是我，直接交流的人也是我，不和其餘隊員產生信息交互與分享。又因爲第一階段要經過一些例子和參考來讓其餘隊員進行模仿學習，因此個人壓力和負擔很大。這種依賴關係以下所示

　　一旦失去我這個單核心，各個結點之間並不能產生關聯，沒有辦法造成小閉環進行正常的開發：適應與溝通都須要時間和人力成本。

   

多核心的試探

在β階段，爲了改變α階段出現的"沒有項目經理等於沒有一切"的狀況，將每一個人對整個團隊影響降到最低，在商討後，咱們對整個團隊的結構作出了調整，調整後的分工協做圖分兩條線並行

• 邢浩、魯聃是一條線，進行論壇的搭建與前端修改
• 佘彥廷、黃雨萌、何小松與劉乾是一條線，主要負責剩下的實驗數據處理、測試與實驗的上線

實驗處理部分的依賴關係以下圖，魚尾表明一個實驗的開頭，魚頭表明實驗上線，1~9表明對一個實驗的處理步驟。

　　而對每一個人來講，好比何小松，他的每日迭代開發應當是這樣度過的：

　　而對於一個總體來講，則是一個四級流水的結構，就像下面所展現的

　　同時項目經理做爲每日的監督控制人員，對每一個人只起督促做用，但再也不做爲主程序員控制最關鍵的一環。代碼開發的工做量減小，主要是負責協調進度與先後耦合溝通的部分。這樣即便我因某些因素請假沒有工做，只是會有一部分的工做停滯，不會產生大面積停滯的狀況。

　　而另外一支線則是我部分參與溝通的，主要由後端工程師邢浩與前端工程師魯聃直接交流與溝通的環狀結構。

   

　　兩路併發給咱們帶來各個部分比較高的自由度。第二階段在爲前端工程師定任務時我與以往也不一樣，聽從了自由制定，部分跟進的制度。前端可否作好有些時候靠設計和靈感。因此我爲前端工程師預留了足夠多的空間與自由安排的時間，因此可能你看到的Scrum meeting是這樣的：

　　受限於前端工程師自己的時間、精力與行業特殊性，因此我冒險讓其採用了上述自由安排進度的策略。最終中間過程不夠理想，可是結果也算是沒有辜負個人指望。

4.2 質量控制與評價

• 測試：　　　　    ★★★★☆
• 代碼規範：　       ★★★★☆
• 文檔：                 ★★★★☆
• 需求分析與反饋：★★★☆☆

 

因爲α階段測試不足，在β階段咱們惡補單元測試，嚴格要求測試與開發並行。本輪迭代涉及到了以下幾種測試： 

• 單元測試 
• 黑盒測試 
• 迴歸測試 
• 壓力測試

 

單元測試與自動構建是經過drone.io來完成的。它同樣能夠和Github緊密結合，每次push都能自動運行單元測試。可是與Travis-CI相比最大的優點在於登錄速度很快...Travis-CI的自動構建雖好，可是在國內比較難用。

本次黑盒測試共測試出了 10條bug，有1條還沒有修復

編輯欄狀態不穩定，圖標沒法完整顯示。Issue連接：https://github.com/buaase/Phylab-Web/issues/194

其他9條已經所有修復完成，如下爲bug清單：

• 只有主頁的導航欄裏有小工具的跳轉連接，其餘部分的導航欄裏沒有。
  • 　　Issue連接：https://github.com/buaase/Phylab-Web/issues/192
• 在論壇的編輯框內沒法上傳附件，最後發現是由於編碼問題。
  • 　　Issue連接：https://github.com/buaase/Phylab-Web/issues/189
• 我的資料頁裏在保存了網站和QQ後失效，沒法成功保存。
  • 　　Issue連接：https://github.com/buaase/Phylab-Web/issues/188
• 編輯欄的bug，在編輯東西時沒法完整顯示出編輯欄的各個狀態。
  • 　　Issue連接：https://github.com/buaase/Phylab-Web/issues/187
• 點擊社區不能跳到社區主頁，跳到我的資料頁，點擊phylab按鈕不能回到網站主頁。
  • 　　Issue連接：https://github.com/buaase/Phylab-Web/issues/184
• 圖片超過必定大小沒法上傳做爲頭像。
  • 　　Issue連接：https://github.com/buaase/Phylab-Web/issues/185
• 在資料保存成功後，提示的圖片的那個帶感嘆號的三角形很奇怪。
  • 　　Issue連接：https://github.com/buaase/Phylab-Web/issues/186
• 只有主頁的導航欄裏有小工具的跳轉連接，其餘部分的導航欄裏沒有。
  • 　　Issue連接：https://github.com/buaase/Phylab-Web/issues/192
• 上傳附件的按鈕消失，不一樣權限能看到的狀況不一樣。
  • 　　Issue連接：https://github.com/buaase/Phylab-Web/issues/195

本次還針對以前的主頁和其餘等進行了瀏覽器的兼容性迴歸測試，並使用siege進行了壓力測試，測試覆蓋較爲全面。

沒有給團隊的測試打五顆星，是由於還沒找到支持drone.io的代碼覆蓋率github插件，因此暫時無法給出代碼覆蓋率的測定結果。

本輪迭代作得比較差一點是用戶的需求分析和反饋。主要緣由是在論壇的使用上還沒到高峯期，論壇功能的出現時機處於一個比較尷尬的位置。而且團隊缺少宣傳推廣方面的新鮮創意，儘管最後使用了一些題目有關的帖子來引導用戶從羣聊模式轉向討論區模式，結果仍是不太奏效。

代碼規範方面，除了後端的php文件的代碼規範外，在寫數據處理前，專門定義了實驗處理的代碼規範與模版文件： 

   

 

五、團隊項目實際進展

   

5.1 燃盡圖

咱們在β階段的燃盡圖如上所示，能夠從燃盡圖的變化看出咱們團隊項目burndown圖的動態變化。天天都有完成一部份工做，可是完成的進度比較緩，沒有預想的那麼快。現狀也的確如此，在α階段項目經理new並close個70個issue，而在β階段，issue上漲到了123個，增長了僅53個而已，去掉bug所表明的issue，其實真正作的開發近乎于于α階段的一半而已。

咱們反思了這種狀況的出現，最後發現，β階段任務完成率不高主要是由於：團隊項目與隊員們其餘課業——主要是編譯課設的衝突。

   

5.2 衝突

與無憂無慮能夠每天作軟工的α階段不一樣，β階段，團隊面臨着兩個很難處理的難題：

• 編譯實驗帶來的心理壓力
• 包括課設、複習在內的課業帶來的團隊項目時間上的極度壓縮

這兩個難題一旦解決很差，團隊的挫敗與潰散是在所不免的。

前五次scrum meeting裏，項目經理的心情是沉悶的，每次開會時表情是這樣的：

 

• 隊員的頻繁請假　　                    ——"今天我想請個假...編譯調不完了"
• 本身面對編譯實驗的巨大壓力　　——"TuT，個人編譯怎麼辦...沒時間作了啊"
  
• 計組實驗有學生做弊帶來的壞情緒——"什麼？你確認他做弊了嗎？"

 

　　我甚至曾一度想放棄團隊項目。那段時間裏，天天回到宿舍就是愁天天的scrum meeting該如何寫。我不想造假，可是又擔憂開會時有些隊員又是一事無成。心理壓抑，矛盾，隊員的不理解，面對團隊項目，我天天都是想着如何可以撐過今天的scrum meeting，老是安慰本身：挺住，撐過今天就行了。

　　爲了能讓團隊項目依舊保持其活力，必須將團隊項目做爲最高優先級的我，捨棄了一些機會。做爲表率，個人行爲鼓舞了每個隊員，最終換得了項目天天緩慢可是持續的進展。第六次scrum meeting，會上麗叔說wecenter和laravel的對接初步成功的時候，團隊活力復甦，一直撐到了最後。

　　此次危機也讓我充分意識到兩點：一個是團隊須要有共同理想才能在面對艱難困苦的時候撐下來，不然一個團隊裏的成員很是容易在"大難臨頭"的時候各自飛。另外一個就是，項目經理的心理素質真的要足夠強大。

   

5.3 流水結構的弊端

在實際的開發裏，即便遵循多核心的分工協做，項目仍然遭遇了比較嚴峻的考驗。流水線開發的弊端在於，只要有一我的請假或停滯了開發，須要其產出做爲輸入的後續方將沒法很好地進行開發。而在編譯實驗和團隊項目β階段幾乎一直打架的狀況下，想努力維持每次scrum meeting都沒有人請假的狀況幾乎不可能。

就像是流水線裏阻塞了同樣，咱們團隊的開發也因大大小小的請假被迫延誤了至少兩天的完整工時，這一點是流水結構的弊端所在——影響均攤，結果總體風險加大了——由於每一個人都佔了必定的主導地位。

5.4 不可替換

在 β階段，我在分 配任務時遇到的比較大的問題就是隊員工做轉型的問題。由於第二階段前端須要開發的東西不算多，而咱們第一階段後將一名後端人員轉離團隊，因此團隊在商議 後，想把佘彥廷同窗調離前端的崗位，進行後端的處理。可是在操做時遇到了問題，無論是python仍是latex，想寫出有質量保證，可用的東西，學習耗 去的時間成本過高，最終爲了避免讓天天的scrum meeting都是學習和請假，仍是沒有讓佘彥廷同窗學習python，轉向後端的處理。

在 反覆思考後其實才能明白，學生階段與工做生產環境存在差別，可能會出現各我的學習能力與分配任務的不匹配。學習付出的時間成本是較大的，每一個人所作的工做幾乎都是不可替換的，好比只有邢浩一個後端，只有魯聃一個前端，只有我這樣一個能統籌規劃寫博客的項目經理等。每一個角色的代入感很強，可是一旦在某個職位上缺乏某我的，那麼一個團隊依舊可能會潰散。每一個人都是不可替換的一份子。

   

5.5 實際最終成果

實際上，第二階段你們在開發上所開發代碼沒有第一階段多，可是第二階段全員參與使用了github，狀況以下：

這一點是相對α階段作得很好的一點，全員參與github，你們都也熟悉了一些基本的git操做。

 

   

六、貢獻分配

姓名		具體貢獻		貢獻分
劉乾		412行python代碼 10篇scrum meeting 測試報告 發佈說明 源代碼管理博客 評審展現博客		60
何小松		1800行python代碼		61
魯聃		Wecenter更改配色與前端部分界面 小工具頁面		49
邢浩		800餘行php代碼 完成了laravel到wecenter對接思路設計與實現		55
黃雨萌		6個Latex無關文件 部分測試報告		40
佘彥廷		一次調研 調研報告 400行js生成模態框 12個正確測試數據 部分測試報告		35

 

七、特點功能展現

論壇功能

小工具頁面

 

八、技術難點與設計理念

8.1 遇到的技術難點

 

laravel主站服務和wecenter的對接

 

首先，兩個服務雖然使用了徹底不一樣的架構，咱們的需求就是，讓其能經過數據庫進行交互和對接，而且現階段的一個必要任務就是讓這兩個服務的用戶模型在數據庫中統一，而且登陸和註冊要共用一套接口。

 

在數據庫的合併這個問題上，爲了避免讓二者除users外的表發生衝突，咱們在安裝wecenter時給其設置數據表的前綴，這裏設爲wc_，以後咱們保留原來laravel數據庫中除users外的全部表，以後，咱們把laravel的users表中的password字段改名爲labreport_password，id改名爲uid，其餘字段不變，這樣咱們把這張表的結構和數據導入到wecenter的wc_users表中，這樣的話算是把二者的數據庫合併了，爲了避免改變laravel已有的代碼結構，咱們從wc_users表中導出一張名爲users的view，view中各列與原來laravel的users表徹底相同，這樣就完成了其在數據庫層面的對接。

 

以後，在統一登陸和註冊接口時，由於咱們已經有了四五百的註冊用戶，咱們沒法從其在數據庫中加密的密碼來得知其密碼明文，然而wecenter須要一個密碼字段，咱們又不能讓這五百註冊用戶挨個改密碼，這樣咱們想到了一個解決方案，咱們在後臺給wecenter設置一個全局的密碼，全部用戶的密碼都用這個加密後做爲密鑰。這樣的話，咱們的登陸接口使用laravel的登陸接口，以後主站就獲得了登陸憑證session，以後，咱們在登陸wecenter時，用這個session本地迴環訪問（即便用I/O）主站，從某個接口中得到用戶的登陸身份，以後使用這個身份驗證並登陸wecenter，得到wecenter的cookies。

 

在登陸wecenter時有一個登陸跳轉界面，這是由於wecenter登錄時有大量ajax請求，因此咱們保持了其原有登陸界面的結構進行登陸。

 

關於註冊接口，由於wecenter的用戶表中有大量與其邏輯有關的附加屬性，而且這些屬性很難被咱們徹底控制，也就是說很差直接編碼添加這些字段，因此咱們不能使用主站的註冊，而使用wecenter的註冊接口，而主站的用戶的字段咱們都是可控的，均可在註冊時添加進去。這裏有個比較坑的地方是，laravel的密碼加密方法與框架耦合很是緊，我沒有作到把其算法編碼實現，因此，在註冊填寫labreport_password字段時，咱們也是使用了本地迴環請求laravel的某個接口得到加密後的密碼，填寫入密碼字段。

 

按照上述這樣，咱們就完成了用戶註冊和登陸接口的統一。

8.2 設計理念

http://www.cnblogs.com/kibbon/p/5117674.html

 

九、總結

開發人員的一些感想：

佘大爺>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

M2期間其實出過許多的問題，由於畢竟不是隻有這一門課，你們都有許多其餘的事須要作，時間上不能分配的那麼理想，組裏的人也出過不少的矛盾還有意見分歧，PM每天晚上愁眉苦臉的，由於隨着其餘課程難度的加大，你們沒有那麼多的時間能夠分給軟工，沒法按時完成任務PM也很差寫scrum meeting，因而就很鬱悶。其實咱們徹底能夠像某些組那樣去杜撰scrum meeting，可是咱們並無選擇那麼作，我不知道其餘人是怎麼想的，可是PM和我都是把這當作一個正式的項目去作，而不是做爲一門課程的做業。組裏一些人把軟工放在了優先級稍微低一些的位置，而使得PM沒辦法儘快寫出工做進度，這樣的日子持續了快一週，看PM實在受不了了，感受團隊失去了活力，大概，我永遠就適合當那個壞人，把一切不能說那麼明白的事去跟人說出來。從那天開始，你們都開始把軟工放在優先的位置了，因此即便第二階段時間那麼緊，咱們依然按時完成了任務。固然，代價是有的。組裏不少同窗放棄了編譯的一部分分數，把時間都拿來作軟工了，不過這樣也體現出了相似於面對工做和其餘事的矛盾，咱們真的把這個項目當作本身的工做了。

第一階段的展現效果特別好，其實咱們有時候都以爲第一階段展現的東西太多了，畢竟咱們網站最主要的功能就是那些，第二階段主要就是讓實驗的覆蓋數量更大，然而這在展現效果上並很差，不過幸運的是，咱們還找到了其餘能夠開發的實用功能，使得咱們的網站功能更加完善，更加多元化。

咱們認爲，產品存在的價值就是，實用並且用起來舒服，要有連本身用起來都以爲很是舒服的用戶體驗，即便是小細節咱們的前端工程師也一絲不苟的完善着，這就是咱們強大的緣由。咱們是一個團隊。

鬆哥<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

不知不覺，一學期的軟工即將結束了。這學期咱們的任務很重，比之前任何一學期的任務都要重，可是比以往的任何一學期都要有意義。軟工則是這學期最有意思的一件事。

在軟工開始的時候，從我的項目開始，我真的是想好好作，可是對於一個暑假都沒有接觸代碼的我，完成實在是有點困難，並且那個時候本身的能力並不高。所以，軟工的我的項目就水水過了。結對項目的時候，漸漸地回覆了感受，直到M1階段，我開始意識到，必須作出改變，因而，逼了本身一次。

在M1階段的時候，學習了不少東西。從一開始的matplotlab，只是學了皮毛，雖然沒派上用場，可是本身學了；而後就是Python，學習了以後發現Python是一個很好用的語言，之前在上密碼學課程的時候就接觸了Python，這一次深刻的學習了一下Python，感受很不錯；再而後就是LaTeX，當時迫於團隊的進度和項目經理的任務量大，我開始學習LaTeX，分擔一些項目經理的工做，如今想來，學習LaTeX真是一個不錯的選擇。總之，學習和練習是M1階段的主要工做吧。如今想來，要是我能事先掌握這些工具，M1的時候就不用過得這麼累了。

在M2階段的時候，主要就是課程上的壓力。到學期末，不少課程都要面臨結束，有大做業，有考試，所以，這個階段主要就是時間上的安排。由於當時實驗室的工做停下來了，因此個人時間可能比他們都多一點吧，而後就盡力多作一點東西，讓咱們可愛的軟工項目可以活下來，並且活得更好。因此M2階段主要就是心智上的成長，咱們逼迫本身去完成一些之前看來不可能完成的任務，事實上也證實咱們能夠完成。

最後，我要感謝這個團隊。團隊中的每個人都是那麼可愛。每個人都在項目經理的安排下，努力地完成本身的任務，提出本身的合適的想法，讓咱們的項目變得更好。咱們都很累，可是咱們合做，讓每個人本來的累輕鬆一點（合做愉快！「軟件攻城獅」們！）。因此要感謝這個團隊，由於這個團隊，我成長了不少不少，謝謝！

萌萌>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

在整個軟工項目的過程當中，發現實踐的重要性。在課本上或者在論文中的知識其實都是對實踐中狀況的總結和昇華，可是單單從字面上仍是不能體會到文章中真正想 表達的意思。從大的主題上把握，個人體會就是，沒有萬能殺器，只有適合的道路纔是更好的。（P.S.從這句話看來整個體會是又紅又專的）

    交流溝通方面。在咱們的團隊中，主體是一個宿舍，其他的隊員也是一個班的同窗或者熟識的朋友，所以在交流溝通方面的成本不大，精力能夠更多地放在對項目本 身的安排上面，然而對於那些隊員之間比較生疏的團隊，我認爲仍是要在交流溝通方面下大工夫的。這一點在在一切運行順利時不能體現起重要性，可是在遇到問題 的時候格外重要，由於與交流溝通直接相關的就是任務分配和合做。一個團隊的配合和分工在項目中有多麼重要相信只要經歷過這個過程的人都回有體會。

     團隊中角色認知方面。舉個例子來講吧。我是在第一階段體會到項目經理的重要性的。在正式接觸一個軟件工程項目以前，我認爲的PM是一個相對而言的「閒 職」，不須要過多地碼代碼，只要把握整個項目的大方向便可，只一點直到看完書、參考資料也沒有太大的改變。如今再回到正題，實踐纔是檢驗真理的惟一標準。 在項目的第一個階段，我就發現了PM在整個項目中起到的是鏈接與動力的做用是多麼重要。仍是像以前說的，咱們團隊的項目經理堅持在天天早上或者前一天的晚 上將每一個人一天的任務放在羣裏進行公示與明確。並在天天晚上檢查今天任務完成狀況，以便及時調整項目進度。以我本身的切身體會，天天的任務和彙報機制逼迫 我天天不得不擠出時間來作團隊項目，從而保證了工做量。到了第二階段，因爲項目自己從磨合進入到規範階段，咱們的配合很大程度上已經取決於以前創建的不成 文的分配規定，PM的工做量就沒有那麼大了，但這也是在項目初期打下了的底子才能撐起來的。

    我的時間安排方面。書本上或者文章中的知識基本上是對於一個專業的軟件工程團隊提出的。而咱們的狀況是，在進行一個團隊項目的同時還要面對別的課程的壓 力，時間安排這一點上幾乎沒有可參考的內容。這時候發現前瞻性是多麼地重要！！！咱們的項目在alpha階段完成了大部分的工做，這一段時間編譯課設還沒 有開始，時間相對充裕。爲迎接以後編譯數據庫課設打好了能夠吃的家底。現在順利結束，回想一下，若是當時拖延，想着將任務放到後面作，想來在14-17周 的生活會至關至關難過。

     再次回到大主題吧，實踐出真知。我認爲六、7班的軟工課程是比前大班成功的，就是由於有了一個真正的項目來給咱們實踐、讓咱們思考和體會軟件工程文字的 知識是怎麼應用到現實的。然而實話說，在本學期作軟工的過程當中，我心裏曾經真的十分抗拒這門課。倒不是由於課程自己，而是時間安排的問題。當我知道咱們的 軟工課程考覈方式是如此不一樣的時候，心裏十分不平，認爲咱們付出了不一樣的時間精力卻拿一樣的分數，加之這個學期還有編譯和數據庫的壓力，看着室友優哉遊哉 生活過的滋潤本身卻在軟工的水深火熱之中心裏非常不平，相信不少同窗應該都有這個體會。可是我也說了，其實這樣設計很好，惟一的不足在於應該把這門課與有 壓力的課程分開安排。或者乾脆你們一視同仁，一塊兒辛苦，沒有了心理落差或許好不少。

乾<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

一個團隊只有在經受到巨大的壓力與挫敗的時候才能體現出它真正的凝聚力。咱們團隊的凝聚力不必定是最高的，行動證實一切。

最後，再熱情擁抱軟工這門實踐課，感謝這門課讓咱們團隊的人凝聚在一塊兒，也感謝這門課最終讓咱們收穫良多。

不只是編程能力上的，更多的是關於人、協調、團隊合做、團隊衝突等方面的經驗與感覺，相信每位隊員都收穫頗豐。那麼最後以一句話來做爲團隊項目的結尾：

再見，軟件工程！