alpha衝刺過後諸葛亮（團隊）

alpha衝刺過後諸葛亮（團隊）

課程名稱：軟件工程1916|W（福州大學)
團隊名稱: 雲打印
做業要求: 項目Alpha衝刺（團隊）
做業目標:完成Alpha衝刺的過後諸葛亮

團隊隊員

隊員學號	隊員姓名	我的博客地址	備註
221600412	陳宇	http://www.cnblogs.com/chenyuu/	隊長
221600411	陳迎仁	https://www.cnblogs.com/yinen/
221600409	蔡森林	https://www.cnblogs.com/csl8013/
221600401	陳詩嫺	https://www.cnblogs.com/orangepoem/
221600408	蔡鴻鍵	https://www.cnblogs.com/jichiwoyaochi/	轉出
221600307	李姣	https://www.cnblogs.com/CloudLong/	轉入

---

設想和目標

1.咱們的軟件要解決什麼問題？是否認義得很清楚？是否對典型用戶和典型場景有清晰的描述？

咱們軟件主要解決傳統線下打印的一些弊端，好比線下打印店人多擁擠、排隊時間長，U盤中毒、丟失，對打印機不熟悉錯印多印，商家須要時刻關注各臺打印機的打印情況等傳統弊端。對軟件功能的定位是很清晰的。主要針對目前大學生的打印場景以及目前大學生的羣體進行了清晰的調查，經過問卷和實地考察，進行清晰的描述。

2.咱們達到目標了麼（原計劃的功能作到了幾個？ 按照原計劃交付時間交付了麼？ 原計劃達到的用戶數量達到了麼?)

微信小程序端原計劃主要實現5個大功能模塊：文件打印、圖片打印、聯繫客服、聯繫商家、掃一掃；每一個大功能模塊下還劃分了許多子功能，好比文件上傳、微信支付、訂單列表、訂單填寫；按照原計劃a階段實現了主功能文件上傳以及微信支付即文件打印功能。原計劃達到的用戶數尚未達到。

3.和上一個階段相比，團隊軟件工程的質量提升了麼？ 在什麼地方有提升，具體提升了多少，如何衡量的？

團隊軟件工程的質量提升了，對於整個軟件的開發以及管理和計劃的把握上有了必定的提升，從沒有計劃的建瓦房達到了有圖紙有規劃的建平樓，經過開發的軟件項目質量以及開發過程當中對問題的處理以及初始的計劃安排狀況來衡量

4.用戶量, 用戶對重要功能的接受程度和咱們事先的預想一致麼? 咱們離目標更近了麼?

用戶量離預期還有較大的距離，用戶對文件打印功能的接受程度與事先的預想相差很少，但在一些細節上還不夠完善，還須要進一步改進。

5.有什麼經驗教訓? 若是歷史重來一遍, 咱們會作什麼改進?

經驗教訓：初期只是規劃在10天內完成的一系列功能，粗糙地 安排天天的工做量，可是在後面的執行欠缺更加嚴格的監督，致使其中一兩天耽擱，沒有按照預期的進度去作，還好後面幾天加班完成預期功能。經過這個教訓，感覺到應該嚴格監督天天的進度。若是從新來一遍，咱們會更加合理的安排人員以及時間，清晰劃分每一個任務的deadline，嚴格監督天天進度。

---

計劃

1.是否有充足的時間來作計劃?

作計劃上的時間仍是挺充足的，作好計劃，有助於工程的順利進行。

2.團隊在計劃階段是如何解決同事們對於計劃的不一樣意見的？

當遇到不一樣意見時，咱們主要採用投票表決，決策出最優方案。

3.你原計劃的工做是否最後都作完了? 若是有沒作完的，爲何?

大部分任務如期完成，未作完的部分由於突發緣由或技術問題影響工程的進度。

4.有沒有發現你作了一些過後看來不必或沒多大價值的事?

這個卻是沒有遇到。

5.是否每一項任務都有清楚定義和衡量的交付件?

每一項任務基本都有明確的目標。

6.是否項目的整個過程都按照計劃進行，項目出了什麼意外？有什麼風險是當時沒有估計到的，爲何沒有估計到?

項目未徹底按照計劃進行，中間由於某些技術上的問題，致使進度有些落後。對於風險的問題，這個卻是沒考慮到。

7.在計劃中有沒有留下緩衝區，緩衝區有做用麼?

咱們計劃中留有必定的緩存區，某種程度上較好地彌補落下的工做。

8.未來的計劃會作什麼修改？（例如：緩衝區的定義，加班）

根據技術上的難度適當調整天天的工做量。

9.咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?

在這個過程當中，咱們學到了微信小程序開發的相關技術，先後端交互的問題解決能力以及開發過程當中遇到的種種問題的解決經驗等

---

資源

1.咱們有足夠的資源來完成各項任務麼?

技術資源不夠，須要邊學習邊開發，工做量大，壓力大。

2.各項任務所需的時間和其餘資源是如何估計的，精度如何?

主要按照工程中功能實現的難易程度進行估計，精度上還須要進一步改進。

3.測試的時間，人力和軟件/硬件資源是否足夠? 對於那些不須要編程的資源 (美工設計/文案)是否低估難度?

測試時間不夠，人力和軟硬件資源湊湊有餘，對於美工、文案設計確實低估了工程難度，在界面設計中遇到了許多問題。

4.你有沒有感到你作的事情可讓別人來作（更有效率）?

這個卻是沒有，本身正在作的事情本身比較熟悉，忽然交付給別人來作，須要花費時間跟他交流討論，才能真正交接，這樣效率反而不高。

5.有什麼經驗教訓? 若是歷史重來一遍, 咱們會作什麼改進?

代碼複用性不是很好，後期修改的工做量大，若是能夠再來一次的話，咱們打算對代碼進行重構，提升代碼複用性和整潔性。

變動管理

1.每一個相關的員工都及時知道了變動的消息?

收到變動通知後，咱們及時和組員進行了溝通和交流，保證了消息的時效性，讓組員第一時間收到通知。

2.咱們採用了什麼辦法決定「推遲」和「必須實現」的功能?

根據這個功能對軟件的必要性和開會討論。

3.項目的出口條件（Exit Criteria – 什麼叫「作好了」）有清晰的定義麼?

在前面的需求分析報告，和系統分析報告中有比較清晰的定義。

4.對於可能的變動是否能制定應急計劃?

沒有，全靠熬夜加班。

5.員工是否可以有效地處理意料以外的工做請求？

在alpha衝刺中沒有遇到意料以外的工做請求。

6.咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?

保證消息的時效性，制定好應急計劃。

設計/實現

1.設計工做在何時，由誰來完成的？是合適的時間，合適的人麼？

設計是在初期原型設計的時候由團隊多名隊員一塊兒完成的，是合適的時間，合適的人。

2.設計工做有沒有碰到模棱兩可的狀況，團隊是如何解決的？

有，會團隊一塊兒討論把模棱兩可的地方肯定。

3.團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其餘工具來幫助設計和實現？這些工具備效麼？ 比較項目開始的 UML 文檔和如今的狀態有什麼區別？這些區別如何產生的？是否要更新 UML 文檔？

• 有運用單元測試和UML等工具來幫助設計和實現。
• 這些工具是有效的，單元測試保證了每一個部分的正確性，uml幫助咱們觀察類、對象等之間的關係。
• UML文檔類圖的對象和方法都有不同，區別產生於老師和助教的建議後，咱們更新了UML文檔。

4.什麼功能產生的Bug最多，爲何？在發佈以後發現了什麼重要的bug? 爲何咱們在設計/開發的時候沒有想到這些狀況?

• 小程序微信支付功能產生的bug最多，由於你們不太熟悉它的工做原理。
• 發佈後沒有發現重要bug。

5.代碼複審（Code Review）是如何進行的，是否嚴格執行了代碼規範？

• 代碼複審由組長審查代碼的格式、風格、命名是否符合規範。

6.咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?

• 咱們學到了微信小程序的開發，還有不少測試工具的使用。
• 若是歷史重來一遍，咱們會更嚴格按照代碼規範編程。

測試/發佈

1.團隊是否有一個測試計劃？爲何沒有？

有。

2.是否進行了正式的驗收測試？

進行了。

3.團隊是否有測試工具來幫助測試？

有，如Junit等。

4.團隊是如何測量並跟蹤軟件的效能的？從軟件實際運行的結果來看，這些測試工做有用麼？應該有哪些改進？

有用Jprofile對軟件的功能進行測試。有用，確保了軟件功能的正確性。

5.在發佈的過程當中發現了哪些意外問題？

• 沒有遇到意外問題。
• 咱們學到了測試的重要性。
• 若是重來一遍咱們會提前學習測試工具的使用，不用臨時學習

6.咱們學到了什麼? 若是重來一遍, 咱們會作什麼改進?

• 沒有遇到意外問題。
• 咱們學到了測試的重要性。
• 若是重來一遍咱們會提前學習測試工具的使用，不用臨時學習。

團隊的角色，管理，合做

1.團隊的每一個角色是如何肯定的，是否是人盡其才？

每一個成員負責本身擅長的部分，充分發揮團員的優勢。

2.團隊成員之間有互相幫助麼？

有

3.當出現項目管理、合做方面的問題時，團隊成員如何解決問題？

團隊一塊兒溝通討論

每一個成員明確公開地表示對成員幫助的感謝 （而且寫在各自的博客裏）：

• 陳宇
  感謝chj在完成先後端的任務中給與個人幫助，即便離開了團隊也繼續完成了前端的任務。

• 陳迎仁
  我感謝cy同窗對個人幫助， 由於在出現的一些bug的時候都是他和我一塊兒克服，還指導我學習java後端。

• 蔡鴻鍵
  我感謝cy對個人幫助,由於某個具體的事情: 幫我一步一步改BUG。

• 蔡森林
  我感謝cyr對個人幫助，由於某個具體的事情: 他讓我開始接觸和開發微信小程序。

• 陳詩嫺
  我感謝cy同窗對個人幫助，由於某個具體的事情：衝刺階段寫代碼遇到bug幫我找緣由和修改方法。

總結

1.你以爲團隊目前的狀態屬於 CMM/CMMI 中的哪一個檔次?

可重複級(Repeatable)檔次。

2.你以爲團隊目前處於 萌芽/磨合/規範/創造 階段的哪個階段?

從磨合到規範的階段。

3.你以爲團隊在這個里程碑相比前一個里程碑有什麼改進?

代碼規範度更高，配合也更默契。

4.你以爲目前最須要改進的一個方面是什麼?

增長團隊成員的配合度。

5.其它軟件工具的應用，應該如何提升？

參考網絡上的教程自學，或請求掌握該工具使用的同窗的指導。

6.項目文檔的質量如何提升？

參考網絡中優秀的項目文檔是怎麼寫的。

交換組員的工做交接和培訓方案

工做交接：
1，傳給新成員原成員寫的源碼，由於原成員是web端，因此咱們把全部的HTML+CSS+JS的網頁代碼交給他。
2，由於新成員學習過基本的WEB知識，就不用另行學習。
3，由原成員帶新成員學習web使用的框架。
4，因爲新成員是作UI的，會幫派一些UI圖標優化。

培養計劃
1，溫習基礎HTML+CSS+JS知識
2，由原成員帶新成員瀏覽代碼，學習框架，並運用
3，使新成員瞭解接下來的項目需求，提出本身的看法，使加快融入小組
4，由先後端同窗交流接口，使之理解數據交付，熟悉AJAX和DOM原理等
5，自我界面美感優化

討論的照片