【彩彩只能變身隊（第七組）】Beta版本

　　做業上交的困難和批閱的繁瑣是中科大各個規模較大的課程都存在的痛點。目前，老師或者使用郵箱，或者使用紙質做業上交，這些工具和平臺都存在着必定的問題。而咱們的線上課程做業管理系統正是基於這樣的需求背景下提出要開發的。是咱們主要的特點，目標就是作一個操做很簡單，很穩定的做業上交系統這個網站提供了一個方便老師和學生兩方使用的做業上交系統。學生可根據本身的時間自行上網查詢做業要求，提交做業文件，查詢做業上交狀況。老師也不用本身下載做業，經過在線預覽就能夠查閱做業，而老師不用面對擁擠的郵箱空間，也不用自行統計上交人數，提醒未上繳成員做業狀況，從而輕鬆的管理該門課程的做業。

五. 團隊管理,交流細節

　　軟件開發是一個須要協同做戰的工做，團隊是軟件開發工做的基本組織，所以造成一個有效的團隊是軟件組織成功的基礎。學期中，咱們主要經過每週一到兩次的小組會議與線上交流做爲主要的交流方式，七月份因爲沒法集中在一塊兒，更多的是經過線上交流。

六. 代碼管理

　　Github地址： https://github.com/Viarow/USTChomework

七. Beta階段衝刺：

0. Alpha階段遺留問題

　　先後端交互的遺留部分

　　文件操做

　　部署服務器

1. Beta階段衝刺狀況

　　7.9

　　改善路由框架，將教師端和學生端用兩個router分別輸出，後端根據前端的改變作相應調整。

　　7.10

　　引入pdf.js，能夠預覽本地的pdf文件。

　　7.12

　　因爲咱們的網站最重要的功能是做業的提交與批改，可是在設計路由的時候咱們在以班級爲單位仍是以一次做業爲單位的問題上討論了好久，最終肯定了總體的思路。

　　最後的思路是以班級的一次做業爲單位，班級成員就是某一次做業須要提交的學生全體，這樣比較清晰，也與咱們以前數據庫的設計相符合。

八. 團隊總結

　　咱們先入爲主的觀念經常是這樣的：團隊項目就是一羣人碼代碼。然而軟件的開發並不僅是單純地敲代碼，還要通過一整套嚴格的開發流程，包括對軟件的總體構建，風險評估，需求分析，UI設計，開發，測試以及後續的相關維護等。所以統籌規劃的能力至關重要。通過了一個學期共同的努力以後，咱們才慢慢體會到軟件工程不只僅關乎代碼關乎編程，而是一個引導咱們本身分析問題、解決問題的過程，而在這個過程中，時間管理、團隊管理、成員交流等都是不可或缺的重要組成部分。

　　咱們的項目是完成一個線上的做業提交與管理系統，在項目初期，咱們也聯繫了上一屆的學長，瞭解了一些基本的開發框架與工具。雖然咱們作的東西有相似的地方，可是咱們想要完成的與他們其實並無重疊之處，因此最後咱們放棄了增量式開發的想法。

　　一個項目的第一步首先就是需求分析，咱們開發出來的東西是給用戶使用的，因此咱們就要站在用戶的角度上合理全面分析他們的需求與痛點。並且在整個開發的過程中，還要考慮到用戶需求的變化，要依據用戶需求的變動及時作好調整。咱們的項目中一個很重要的用戶羣是老師，在需求分析這方面咱們沒有作得很好，在開發的過程當中沒有及時地去了解需求的變化，離用戶始終有一段距離。這也給咱們之後的項目提供了一個寶貴的經驗與教訓。

　　咱們團隊的成員當中沒有人曾經接觸過網站開發的相關知識，因此學習一些相關的基礎知識其實花費了咱們不少的時間。可是團隊項目的緊迫程度最終教會了咱們 Learning By Doing。這是一門課程，因此咱們不可能在學完了全部的知識之後再動手去作，只能邊作邊查邊學。這一點不只僅適用於這一門課程，對於以後咱們的學習與科研，道理也一樣如此。快速學習而且能夠把所學當即運用到實際當中的能力是軟工教給咱們的，也是咱們須要不斷去鍛鍊與提升的能力。

　　再來講一說敏捷開發。簡單的說敏捷開發就是把一個大的項目分紅多個相互聯繫，但能夠獨立運行的小項目，並分別完成，在此過程當中軟件一直處於可用狀態。敏捷開發就要求咱們要儘早交付能夠供用戶使用的軟件，才能獲得有價值的反饋，而後在用戶需求之上開發，這樣纔是有價值的開發。可是敏捷開發就須要咱們擁有強大的學習能力，在短期內適應高強度的開發模式。

　　一個績效良好的項目團隊要有有效團隊管理的能力。其中很重要的兩個方面，一是有效的交流與溝通。這不只體如今平常問題、工做的及時有效的討論與解決，也體如今代碼規範與標準之中。一個團隊完成一個項目，一份代碼就勢必要爲全部人而懂。所以代碼規範與代碼註釋就很是重要。另外一方面，是有效管理時間，團隊成員要明確每週的目標，要控制干擾，努力不被外界所影響。團隊中沒有自個人概念，也就沒有我的的勝敗，若是項目成功了，每一個人都是贏家。

九. 用戶使用狀況報告

　　Postmortem報告：

　　1. 每一個成員在beta階段的實踐和alpha階段有何改進？

　　在beta階段，團隊成員對技術自己掌握得更加熟練，對網站整體也有了更加清晰和全面的認識。固然，團隊成員之間的配合也更加默契。

　　2. 團隊在beta階段吸收了哪些alpha階段的經驗教訓？

　　alpha階段咱們依然缺少對項目框架的總體認識，對一些技術特別是先後端交互技術掌握得也不夠深刻與成熟。Beta階段咱們先對技術框架有了一個較爲全面的認識，由於只有對技術框架的全面而清晰的認識，才能夠減小無心義的重複性工做，提升效率。

　　beta階段咱們也對界面作了必定的美化，統一了網站的總體風格，努力使用戶體驗更好。

　　其次，在alpha和beta階段咱們充分認識到了時間合理分配的重要性。在從此作項目的時候，咱們必定要提早合理全面預估任務量，將功能模塊細分化。

　　3. 12條敏捷開發的原則中，團隊作的最好的和最很差的各兩點。

　　最好的兩點：

　　1）不論團隊內外，傳遞信息效果最好效率也最高的方式是面對面的交談。

　　The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

　　起初，由於全員須要學習技術框架所須要的各類知識團隊項目的進度常常處於擱置狀態，後來咱們發現採用成員之間互相交流互相學習、集體面對面開發的方法更有效率。其次，咱們發現，當把一些問題的討論發佈到QQ羣中的時候，並不能引發全部人的注意。而當咱們將問題拿出來面對面交流時，咱們之間每每可以碰撞出未曾有過的火花。

　　2）以簡潔爲本，它是極力減小沒必要要工做量的藝術。

　　Simplicity--the art of maximizing the amount of work not done--is essential.

　　爲了儘可能追求敏捷開發的原則，咱們以最迫切的用戶需求爲核心，追求以簡潔爲本。

　　最很差的兩點：

　　1）敏捷過程倡導可持續開發。責任人、開發人員和用戶要可以共同維持其步調穩定延續。

　　Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

　　因爲Beta階段團隊各成員都有其餘的事情須要處理，開發易受外界環境影響，沒能作到按照恆定速度開發。

　　2）咱們最重要的目標，是經過持續不斷地及早交付有價值的軟件使客戶滿意。

　　Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

　　因爲團隊成員都沒有網頁開發的基礎，因此花了大量時間學習相關技術。但在後期，咱們愈來愈體會到儘早交付能夠供用戶使用的網頁的重要性，從而作出相應的改善和調整。儘早交付軟件才能獲得有價值的反饋。軟件工程不只僅是寫代碼，其中還涉及不少爲人處事的道理須要咱們去領悟。

　　4. 對照The Cathedral and the Bazaar (大教堂和集市)，咱們的團隊開發模式是哪種，優點/劣勢在哪裏？

　　咱們初期的開發模式更加傾向大教堂模式，但在實際開發過程當中，咱們慢慢向市集模式轉變。尤爲是在Alpha答辯以後，咱們也獲得了來自老師、助教與同窗們的建議。