福大軟工 · 第十一次做業 - Alpha 過後諸葛亮（團隊）

  

Information：

 

組長連接

 

做業連接

 

Thinking：

- 設想和目標

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

解決微信端上的輕便辦公，方便微信端上的辦公羣體，例如共享編輯針對須要反覆審閱修改的辦公情形，以及其餘環境下面向組內的通知、投票等一系列辦公需求。

1. 咱們達到目標了麼（原計劃的功能作到了幾個？

原計劃的功能中基本完成投票功能、對象分組，接近完成共享編輯功能，半完成通知、想法功能，未完成簽到功能。

1. 按照原計劃交付時間交付了麼？ 原計劃達到的用戶數量達到了麼?)?
   用戶量, 用戶對重要功能的接受程度和咱們事先的預想一致麼?咱們離目標更近了麼?

距離目標咱們還有必定的差距，此次的alpha未可以達到咱們原定的計劃，如上述所表述的，進度並非使人滿意，目前所完成的效果也與前期設定的原型不管是風格上仍是功能上相左，須要完善的地方有許多。

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

柯奇豪：前踩工做須要作好，瞭解總體項目所須要的技術、軟硬件支持，才能是後續的項目進度有條不紊。

- 計劃

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

由於種種緣由(考試、黨課、我的等等)，每次計劃的都不是很完美，也沒有很及時的時間去補正，後續會注意。

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

經過了激烈的討論，獲得一個可行的方案並往這方面走。

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

楊禮亮：美工工做完成，輔助翔宇的工做還未完成，由於效率不高，能力不夠

丁水源：通知後端的工做完成，可是完成的速度比較慢

柯奇豪：共享編輯後期遇到許多以前沒有估計到的修改，例如存儲形式、功能增長等，因此致使沒有及時的作好，只完成了簡單的列表顯示功能。

黃毓明：投票、分組功能完成。

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

柯奇豪：有，花了大把的時間在ssm框架上，結果不太會用，轉用springboot+mybatis，但慶幸是能用了。

丁水源：過程當中學到的東西都挺有價值的，時間花的挺值得

楊禮亮：學了不少可是都遺忘了

黃毓明：一開始寫的投票沒能融入框架，只能使用裏面的部分函數，大部分未使用

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

全部人：很遺憾，沒有，許多東西都是在後續工做中不斷髮現須要修修補補的地方，許多地方沒考慮到。

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

全部人：沒有固定的計劃，過程當中遇到同伴的退出，沒有有效的資源共享，致使每一個人進度不一，許多人很無措。

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

全部人：有過留取一段時間進行先後交互，可是每一個人並無在這段時間前很好的將本身的任務及時完成，致使後續進展不順，因此後來的緩衝區做用不大。

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

柯奇豪：留出一段時間出來進行一個項目的整合，目前在過渡期內，我計劃分紅兩部分人羣分別負責部分功能的先後端一塊兒完善，最後在緩衝區的時間段內總體的一個彙總，每兩天找個固定的時間段來一塊兒編程。

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

柯奇豪：學到的就是須要在項目開展以前即蒐集足夠多的資料來對總體的項目各部分有一個明確的方向，這樣在後續的進度中就不會由於卡殼而不停的調整，初步瞭解各部分細分下來所須要的技術支持。

- 資源

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

時間資源不足，基礎能力儲備不足。

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

原先是按照每次博客的提交時間爲週期進行編程，後續可能會更加細化，由於還有許多工做須要完善。

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

柯奇豪：測試階段基本上部署服務器，暫時還在前期籌措階段，待後續反饋。

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

在項目的規劃上以及對任務的佈置上本身仍是有缺失的，我的不怎麼善於言辭，因此在過程當中表述上經常沒辦法解釋清楚，致使組員出現一頭霧水的狀況，在語言溝通上可能存在障礙。

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

技術資源共享不夠，若是重來或許能夠借鑑其餘組的思路，編程過程裏也整理問題及解決辦法，整合一份技術指南來便於小組開發。

- 變動管理

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

會有消息延遲的狀況，部分時候會耽誤進度，後續可能採用固定時間段來集體完成並彙總提交。

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

按照博客提交的進度進行，可是發現不能很好的既定目標相符，須要調整一個合理的辦法，可能會增長組內的進度deadline。

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

暫時沒有考慮到這個問題，後續以真機測試爲準。

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

目前沒有

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

基於每一個人的水平，部分紅員沒辦法作到

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

deadline與驗收標準的肯定須要完善，缺乏壓力的團隊每每就會致使項目的短時間擱淺，本身也須要學會對隊員有更高的要求與督促。

- 設計/實現

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

在項目的初期由組內共同討論完成，是的。

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

原先在部分的功能上有歧義，基本經過各自表述本身的見解而後你們共同決定經過。

1. 團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其餘工具來幫助設計和實現？這些工具備效麼？

主要使用processon、leangoo來對項目細則有必定的說明。

1. 比較項目開始的 UML 文檔和如今的狀態有什麼區別？這些區別如何產生的？是否要更新 UML 文檔？

存在比較大的差別，是原先組內沒考慮到的，主要緣由在於項目開發經驗不足，沒有細化到許多具體的地方，後續有時間會對以前的UML文檔進行修正。

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

框架的使用上遇到較多的bug，由於原先並無考慮到會用框架，也是第一次嘗試使用。

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

暫時沒有代碼的複審，後續作完會對代碼的命名規範、註釋、項目具體的佈局作必定的修改。

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

規劃上雖然沒辦法一開始就作到盡善盡美，但在後續的進程中，仍是須要安排適當足夠的時間去作好這塊內容

- 測試/發佈

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

暫時沒有，由於基礎性的開發並無及時完成，可是在後續會有一個測試版本階段。

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

目前尚未

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

沒有具體的規劃，後續會去請教一下其餘組給出方案。

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

暫未進行，設定的目標是想在周圍人羣中進行一次推廣調查，而後收集意見酌情修改完善。

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

產品暫未發佈，還未遇到問題。

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

柯奇豪：有一個合理夠用的測試能夠簡化項目後續的工做，減小bug的出現，儘量考慮狀況解決缺漏

- 團隊的角色，管理，合做

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

按本身的意願進行職能的分配，基本上算是人盡其才，但仍是存在部分紅員存在空窗期的狀況，例如在原型設計階段部分先後端不知所措，以及後續先後開發過程當中美工人員的不知所措等。

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

柯奇豪：團隊成員在瞭解框架、具體編程等的過程當中，基本上都是採起互幫互助的形式進行學習，相互指教的。

1. 當出現項目管理、合做方面的問題時，團隊成員如何解決問題？
   每一個成員明確公開地表示對成員幫助的感謝 （而且寫在各自的博客裏）：

柯奇豪：我感謝 ++毓明++ 對個人幫助， 由於某個具體的事情: ++本身自己不太善於言辭，僅僅只是本身會使用、編程，但常常給其餘人解釋不清，毓明則能很好的幫我與其他的人溝通，指導他們框架搭建，這是我未能作到的++。

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

柯奇豪：一個團隊最不能缺乏的，就是團結一致爲共同目標而共同奉獻自個人決心，少一點藉口，多作一點實事纔是。帶領隊員一同進步的工做並無想象中的簡單，須要負責的地方有太多太多，對pm的責任多了一份敬重。還有就是努力改善本身的表述方式吧。

- 總結:

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

柯奇豪：我以爲目前團隊還處於可重複級階段。

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

柯奇豪：我以爲團隊暫時處於磨合階段，信息與進度的不一樣步是目前遇到的最大問題。

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

柯奇豪：更加的瞭解了軟解開發流程，逐漸提升了編程能力，學習的語言與技能都有很大程度的提高，整個團隊的合做觀念漸長。

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

柯奇豪：目前最須要改進的方面就是組內的責任意識，也但願後續你們可以共同努力，齊心合力共同開發出能讓咱們本身滿意的小程序來。

1. 對照敏捷開發的原則, 你以爲大家小組作得最好的是哪幾個原則? 請列出具體的事例。

柯奇豪：面對面交談原則：其中的站立會議以及leangoo進度的監督做用仍是很顯而易見的。

• 博客要附上全組討論的照片
  

Summary ：

姓名	得分（百分制比例%）
柯奇豪	22
蔣雄	11
黃志銘	11
黃毓明	24
林翔宇	9
丁水源	10
楊禮亮	13

評審表格設計

Final Score：

小組	評分
第一組	53
第二組	75
第三組	73
第四組	45
第五組	70
第六組	77
第七組	68
第八組	76
第九組	62
最低分	77（第六組）
最高分	45（第四組）
有效分數	53，75，73，70，68，76，62
最終平均得分	68

Q&A：

• 第一組的問題

Q1:是否考慮在beta和alpha這段期間繼續完成alpha未完成的任務?

A1: 固然會接着完成未完成的任務，咱們在beta階段來臨以前盡力完成alpha階段落下的工做量。

Q2:組內先後端的任務分配彷佛存在問題,有考慮相應的解決對策嗎?

A2: 先後端在人手分配上確實是存在着問題，致使如今前端須要的工做量太大，如今咱們調整了策略，每一個前端負責各自部分工做外再完成各類部分前端的代碼。

Q3:是否考慮太高併發場景下的服務器表現？

A3: 這個問題目前沒有考慮過，由於有些功能尚未完成，不過考慮到各個小組內部的數據量並不會過大，並且服務器的表現如何還和價格成正比，這方面目前不會去深究。

• 第二組的問題

Q1:簽到功能是否會被虛擬定位而進行不正確位置的簽到？

A1: 由於簽到功能的人手缺失，暫時延後開發，該問題其實以前有回答過，就是輔助加上ip地址的限制

Q2:PPT中的指定wifi簽到是什麼意思？

A2: 即經過連入wifi所分配的ip地址限制簽到

Q3:若是成員沒有打開小程序，是否會提醒發佈的通知或者被邀請進的投票？

A3:能夠作到的話會加入提醒的彈窗，配合已有的通知功能

• 第四組的問題

Q1:未提問

A1:

Q2:未提問

A2:

Q3: 未提問

A3:

• 第五組的問題

Q1:有沒有考慮美化一下界面，或則說換一個界面風格？

A1:

Q2:隊友退出沒留下任何代碼，能夠理解爲該隊員沒有寫過代碼嗎

A2: 。

Q3:共享編輯是大家的主要功能，爲何在前端方面須要三十多個頁面呢？

A3:

• 第六組的問題

Q1:在隊友退出的狀況下，大家組是怎樣調整分工的？

A1: 隊友退出，對應負責的功能目前咱們是採用你們一塊兒作，先作完對應功能的同窗來負責

Q2:在後續的做業中有沒有想要採起哪一種方法來避免代碼丟失的狀況？

A2: 對於代碼丟失這個問題，咱們目前代碼是進行一更新一github的方法，及時對代碼進行更新，以免丟失

Q3:前端在頁面較多的狀況下，有考慮什麼方法來使頁面更加方便本身製做來減輕壓力？

A3: 咱們目前調整了工做方式，由對應功能的前端和後端一塊兒負責該功能，一方面減少前端壓力，另外一方面提升項目總體可行性。

• 第七組的問題

Q1:投票功能裏小組選擇，小組是指微信羣聊嗎？若是是的話，即便該羣聊不在通信錄裏面，也能檢測到嗎？

A1: 小組是事先建好的工做小組，組別id是存在後端的，不是微信小組。發起人可建立小組，後來的人憑連接加入。

Q2:共享編輯，別人編輯的時候，是整篇編輯，仍是隻能一次編輯一段？若是是整篇編輯，合併的時候只想合併某幾段，不想所有替換，要怎麼作？

A2: 對已發佈文章按段處理，會顯示更改日誌，不用改全篇。

Q3:現階段開發進度未涉及到核心，爲何不優先開發核心功能。

A3: 核心功能其實也已經實現的差很少了，只是先後端未對接，算法已經OK了。

• 第八組的問題

Q1:團隊分工有沒有值得總結的地方？能夠分享下

A1:

Q2:對alpha版本的完成度如何自我評價？吸引

A2:

Q3:beta版本對分工和進度跟進有什麼改進的想法？

A3:

• 第九組的問題

Q1:大家以爲大家最重要的特點功能是什麼？大家打算怎麼實現？

A1: 共享編輯，使得文本內容共享可修改，相似於github的團隊提交模式，在此基礎上附帶上版本的回退功能。

Q2:大家對本身的進度有具體的把握嗎？分工和合做上是否是存在問題？

A2: 會根據具體的完成狀況調整進度安排，可是總的來講危機感，緊迫感不夠，後續要增強。分工合做後續也會調整。

Q3:大家打算如何對代碼進行管理不會丟失

A3: 代碼有進展及時籤進github。

 

PSP Table：

PSP2.1	Personal Software Process Stages	預估耗時（分鐘）	實際耗時（分鐘）
Planning	計劃	20	20
· Estimate	· 估計這個任務須要多少時間	20	20
Development	開發	460	500
· Analysis	· 需求分析 (包括學習新技術)	40	50
· Design Spec	· 生成設計文檔	0	0
· Design Review	· 設計複審	0	20
· Coding Standard	· 代碼規範 (爲目前的開發制定合適的規範)	0	20
· Design	· 具體設計	20	30
· Coding	· 具體編碼	400	280
· Code Review	· 代碼複審	0	0
· Test	· 測試（自我測試，修改代碼，提交修改）	0	100
Reporting	報告	40	50
· Test Repor	· 測試報告	20	10
· Size Measurement	· 計算工做量	0	0
· Postmortem & Process Improvement Plan	· 過後總結, 並提出過程改進計劃	20	40
	合計	520	570

 

Schedule：

 

第N周	新增代碼（行）	累計代碼（行）	本週學習耗時(小時)	累計學習耗時（小時）	重要成長
1	500	500	15	15	學習VS2017，GitHub使用，複習C++相關知識
2	500	1000	20	35	閱讀《構建之法》，從零開始學Java語言
3	1000	2000	15	50	閱讀《構建之法》，學習Java，學習墨刀等工具使用
4	700	2700	35	85	複習C++知識，學習STL的使用。
5	300	3000	20	105	學習STL相關知識，以及使用VS，Process On 等工具
6	0	3000	35	140	學會如何設計軟件的相關細節。
6	0	3000	30	170	學會如何寫一份完整的「需求分析報告」。
6	0	3000	20	190	入門java，學會分析任務
7	0	3000	15	205	熟悉了本軟件的框架，爲接下來的代碼作好準備。
8	50	3050	12	217	熟悉了ssm框架、Java語言
8	250	3300	3	220	熟悉了軟件開發過程、java語言
9	200	3500	7	227	學會如何用Java實現軟件的某些框架和功能模塊。
10	250	3750	5	232	入門springroot
11	300	4050	20	252	熟悉springboot，學會搭建框架，Java更加熟練，對框架更加熟悉
11	400	4450	20	272	熟悉java和Spring boot框架，對軟件項目的搭建流程更加熟悉。
12	300	4750	15	287	熟悉任務框架，java語言，框架。
12	100	4850	10	297	熟悉springboot，學會搭建框架，熟悉JavaScript。
13	200	5050	5	302	熟悉Springboot框架，明白框架的含義架構。