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

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

組長博客連接

本次做業博客連接

項目Postmortem 模板

設想和目標

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

• 針對日常沒有不少時間看手機，微信、QQ羣消息反而偏多、可是想了解羣裏面關鍵話題的人羣，若是有這麼一款軟件能夠直接幫助這部分人羣提取出羣消息裏面的關鍵話題，這樣既節省了時間，也方便這部分人羣直接處理相關的消息。定義很是清楚，對典型用戶和典型場景有清晰的描述。咱們的軟件主要解決用戶在平常生活中對於QQ和微信消息難以在短期內快速獲取重點與關鍵信息的問題。咱們軟件解決的問題是定義得較爲清楚的。咱們的軟件針對諸如日常沒有不少時間看手機、難以在大量的羣聊中get到重點、須要快速獲取羣聊的重點信息並在第一時間獲得通知的典型用戶。咱們的軟件主要應用於諸如用戶爲了融入羣聊環境但願快速瞭解本身各個羣聊熱點話題、用戶須要第一時間迴應上司或者部門羣體at通知、用戶但願獲取本身交際圈最近的話題導向這樣的典型場景。

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

• 咱們不只達到了目標，還比原目標超出了許多。原計劃的功能要作到羣消息的保存、數據庫的搭建、界面的初始框架，登陸和註冊的界面，在Alpha版本咱們所有作到了，並且還額外的完成了管道方式的多進程通訊模塊、無感式單向好友檢測模塊、基於NLP的熱詞分析模塊。原計劃是打算在在Alpha衝刺階段完成，可是咱們的具體功能在開發的期間已經作完了，還剩下幾天就是不斷的整合在一塊兒。原計劃是不打算有用戶的，就是本組內部成員在試用。咱們達到了部分的目標。原計劃的功能咱們實際上在後端已經完成了三個，整合進入前端界面的有兩個。同原計劃有必定的差距，可是核心功能都已經獲得了完成。目前階段用戶基本侷限於組內人員以及少數同班同窗，同原計劃的用戶數量有必定差距，這與目前的功能開發進度有關，相信在beta版本發佈以後會有所改善。

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

• 目前咱們暫時就是本組成員在試用。根據Alpha版本答辯的現場情況來看，咱們的主要功能仍是比較吸人眼球的。

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

• 這基本上對於咱們來說就是第一次開發一個項目，經驗教訓太多了，下面列幾點比較深入地：
  （1）對pyqt、wxpy等語言的難易程度沒有掂量清楚，一開始就輕易的定下項目開發使用的語言工具
  （2）若是遇到一個比較難解決的問題（wxpy形成主程序的假死），咱們會在這個問題上卡許久
  （3）軟件開發過程當中的不像暢暢組那麼規範專業，沒有相應的文檔和記錄較少
  若是歷史重來一遍，咱們會在開發最開始定語言工具的時候更加仔細衡量用什麼語言會比較方便，會在軟件開發的過程當中更加註重規範化，會在軟件開發的過程當中更加註重相關語言的學習。

計劃

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

• 學期初即公佈了本學期項目的安排，所以咱們團隊有充足的時間對Alpha衝刺任務作出了計劃和安排。

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

• 咱們團隊的民主氛圍比較濃厚，咱們團隊會一塊兒討論你們提出的不一樣意見。

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

• 因爲進度安排較爲合理，咱們團隊完成了全部原計劃中的任務。
  有沒有發現你作了一些過後看來不必或沒多大價值的事?

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

• 在真正開始項目以前，咱們對項目進行過程當中將會遇到的各項任務不可以作到徹底的估計和衡量，隨着項目的推動，咱們對於各項任務的認識愈發得清晰了起來，基本上對每一項的任務都作出了清楚的定義並制定了衡量的交付件。

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

• 項目的總體進展大體按照着計劃進行，咱們對前端開發工具PyQt的低估是咱們項目進行過程當中出現的最大意外。PyQt的學習難度，好比設計難度高、學習資料少是咱們沒有估計到的風險，沒有估計到的一部分緣由在於學習時間短，實踐經驗少；另外一部分緣由在於真正進行項目的開發以前沒有對它進行充分的瞭解。

在計劃中有沒有留下緩衝區，緩衝區有做用麼？

• 咱們在計劃上預留下了兩至三天的時間緩衝區，這個預留的緩衝區對咱們項目的最終完成起了很大的做用。

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

• 未來的計劃中將會留下更多的緩衝區用以解決發生在乎料以外的狀況，以及更好地完善產品；進一步改善任務的分工安排，優化團隊間的合做， 提升團隊的工做效率，避免沒必要要的「加班」。

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

• 在本次團隊衝刺中， 咱們團隊合力完成了Alpha版本的發佈，在這一過程當中咱們初次經歷了團隊的共同開發，認識到了計劃對整個項目方向和進度的重要性。若是歷史重來一遍，咱們會事先作好更加完善的計劃，並在項目進行中根據實際狀況及時對計劃作出修正。

資源

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

在經歷了初期的需求報告調研以及項目展現後，咱們組通過總結認爲有如下幾大塊的任務：

• 發現問題（需求或痛點）並將其表述清楚，並轉化爲規範的文檔
• 經過討論溝通等模式來對發現的問題進行解構、分析
• 基於分析給出可行的方案和思路，並聚合成各個功能
• 將各個功能細化，造成包括但不限於原型、UML等形式的文檔供開發使用
• 對項目的開發分爲界面、美工、數據庫、後端、算法等分支進行協同開發
• 撰寫記錄項目開展進度的文檔、以及進行展現的文檔
• 經過PPT、視頻、海報、圖片、文案對項目進行全方位的展現和推廣
• 對開發的代碼進行復查、測試
• 經過高效的工具和模式來保證團隊成員間的高效合做
• 團隊內須要有威望的成員（如PM）和人性化的制度進行項目管理，模塊合併來保證項目的順利完工

而這些任務目前來講，雖然和理想的、完美主義的目標相比仍然有差別，但就實現的角度來講完成得不錯。就資源和緣由來看：

• 組內的成員都對軟件工程這門課十分上心，毫不會敷衍了事
• 成員們都具備高效的學習能力，可以在短暫的時間上手新的技能和技術
• 團隊的交流和合做氛圍十分良好友善，成員都是儒雅隨和的TYPE
• 分工十分明確，項目的管理和協做並無出什麼大的紕漏
• 組內成員都很是有想法創意，並有相應地能力去實現這些創意
• 全員強迫」讓成員們對本身工做質量要求都很高，各項任務完成度很高，質量也處於較高的水準
• 組長具備良好的技術和豐富的經驗，對本身不妥協不放棄，能及時幫組員填坑
• 由於某些緣由，團隊有十分穩定的場地以供協做

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

• 目前做爲一個開發經驗不夠豐富的團隊來講，各項任務所需的時間在某種程度上只能根據討論和臆測來進行估計。
• 在資源的估計上相對來講科學的多。
• 對於大的任務模塊本組以半天做爲單位來進行估量
• 在小的任務模塊上本組以小時爲單位進行評估
• 精度方面大多數任務的估計與實際工做量不會誤差過多，在界面方面有必定的誤差

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

• 功能測試上時間的餘量相對來講比較寬鬆
• 軟件資源方面，產品的一項功能（單項好友檢測）因爲騰訊WXPY庫及API方面的政策，致使短暫的封號，使帳號資源較爲緊張
• 美工/文案方面因爲本組有半專職的美工從事相應的工做，同時在PS、AI、PPT等技能上較爲熟練，所以人手和資源較爲充裕。
• 但因爲PyQT的特性，致使設計稿和界面有必定差距

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

• 團隊若是能更加高效地使用好GitHub，能在代碼的管理上更加高效
  對項目任務的分塊工做量估計不夠精準，致使一部分的人力資源浪費

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

• 慎用網絡上文檔資料較少的技術棧
• 在計劃設計階段要對項目功能的可行性、技術政策風險進行評估、對技術棧的使用也要有多方面的考量
• 團隊應當更加高效地使用好git工具
• 對於代碼的一些規範要進行好約束
• 更加細化分工
• 變動管理

變動

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

• 由於團隊每次都是在開會期間決定功能模塊的變動，而每一個成員幾乎都不會缺席，所以團隊內的每一個成員能及時知道變動消息。
• 團隊的計劃和任務分配都會同步到團隊的協做管理平臺--Leangoo，即便偶爾有成員缺席會議，也能經過Leangoo即便知道團隊的任務變動。

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

• 咱們團隊綜合衡量了現階段所能投放在項目上的時間以及成員的能力，分析了現有的開源項目所能提供的技術支持，結合產品開發前期咱們作的大量的用戶需求分析，最終決定必須實現基本的軟件運行環境和核心功能「熱詞分析」、「單項好友檢測」，將「關鍵詞提醒」和「羣發祝福」推遲到Beta版本實現。

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

• 目前咱們是有較明確的出口條件的：
• 四大功能在後端算法實現上基本完成，能保證每次都正常運行
• 產品界面美觀、前端和後端交互邏輯正常，用戶體驗良好
• 作好數據庫等的安全防禦措施，保證用戶數據的安全性，並制定完善的用戶隱私政策

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

• 臨近deadline，組織團隊成員集中面對面編程
• 每日彙報各人任務進度

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

• 鑑於團隊成員都是在校生，平時課業較爲繁重，因此若是要臨時增長需求或功能，可能沒法在Deadline以前實現。
• 若是是現有功能出現的異常，好比哪一個功能忽然出現了未知bug，團隊仍是可以及時處理並解決的。

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

• 使用GitHub進行代碼管理，而不是把GitHub當成百度雲盤
• 編寫完善的設計文檔，作好註釋工做

設計/實現

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

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

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

• 咱們暫時沒有進行單元測試，咱們會在beta階段加入對每一個模塊的測試！咱們使用了UML進行輔助設計。

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

• 主要的變化是在數據庫上的變動，數據庫的結構有發生變化。

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

• 團隊以前碰到的BUG主要是在對wxpy進行整合的過程當中，主窗口假死的BUG；以後咱們使用了多進程通訊的方式，在使用多進程通訊方式的過程當中，又出現瞭如窗口關閉後wxpy進程沒法跟着關閉等BUG。固然，界面開發過程當中也出現了不少BUG。

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

• 咱們沒有很好地進行代碼複審（慚愧），代碼規範咱們儘可能的遵循PEP8的編程規範。

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

• 學到了多進程通訊、PyQt的使用（很麻煩，須要手寫各類類間的繼承）、wxpy的使用、sqllite數據庫的使用等

測試/發佈

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

• 暫無
• 團隊經驗不夠足
• Alpha版本時間緊、工做量大

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

• 暫無

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

• 暫無

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

• 暫無

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

• 咱們使用pyinstaller打包軟件時，發現和本地運行結果的不同（沒法調用wxpy），暫未解決

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

• 學到了多進程通訊、PyQt的使用（很麻煩，須要手寫各類類間的繼承）、wxpy的使用、sqllite數據庫的使用等

團隊的角色，管理，合做

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

   根據本身的興趣以及掌握的技術來分配，相對來講能達到人盡其才的程度

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

   有，事實上不少困難時是團隊一塊兒攻克的

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

   擺出事實，而後闡述問題出如今哪，而後一塊兒尋找解決方案

公開感謝（我的）

我感謝 __ _對個人幫助， 由於某個具體的事情: 。

總結

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

初始級。工做無序，項目進行過程當中常放棄當初的計劃。管理無章法，缺少健全的管理制度。開發項目成效不穩定，項目成功主要依靠項目負責人的經驗和能力，他一但離去，工做秩序面目全非。
整組有部分人員沒有分配合理的工做，或者未能交出合理、可用的工程任務。主要的工做都集中在個別成員中。當我的的工做完成後，不能及時的分配接下來進行的任務，只能組員自行安排可行的任務。

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

• 磨合階段。團隊成員開始逐漸熟悉和適應團隊的工做方式，面對問題和衝突，可以進行有效的溝通，解決問題。可是問題仍然存在。

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

• 從進程通訊和界面編寫的坑中爬了出來

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

• 任務量分配不合理，一個任務完成以後下一個任務沒有及時安排

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

討論照片

現場得分及QA總結

	第一組	第二組	第三組	第四組	第五組	第六組	本組	第八組	第九組
本組對其評分	81	77	68	75	66	81.5	85	81	53
對本組的評分	79	79	77	60	80	74	85	77	75

去除最高總分，最低總分，求平均分後，獲得：

本組的現場答辯得分：(79+79+77+80+74+77+75)/7=77.28

第一組提出的問題：

問：答辯中提到pyqt的教程數量不多,是否pyqt自己就存在開發的侷限才使得它的教程數量少呢?

• 其實我的認爲得益於qt框架的健壯性，pyqt的框架也不會不好！目前pyqt教程少一方面是由於社區還不夠大，另外一方面應該是不多有人拿pyqt去找工做吧！至因而否是pyqt架構自己存在問題，咱們只能說咱們水平還沒到能評價架構上是否存在侷限的地步。

問：答辯中提到,pyqt對部分組員太難了,是否考慮分配組員完成其餘任務？

• PM向沒法駕馭pyqt的隊員分配了數據處理、數據庫接口、文檔撰寫等任務

問：用戶使用大家的軟件是否須要配置相應的運行環境?

• 目前是須要的，由於python存在依賴庫，項目開發後期發佈release版本後應該就不須要依賴壞境了

第二組提出的問題：

問：既然是掃描微信登錄，爲何還要弄申請帳號呢？

• 申請帳號爲本軟件後續的經營提供了收支渠道。

問：關鍵詞提醒功能是在電腦端提醒仍是手機微信提醒呢？

• 關鍵詞提醒功能能夠根據用戶自定義，來設置經過郵件提醒或者經過手機短信提醒。

問：可否對QQ信息來執行相關的功能呢？

• 在Alpha階段咱們其實是有作QQ消息的保存的，只是由於精力有限沒有將QQ端的功能整合進來。

第三組提出的問題：

問：關於封號的問題，是否有一個具體明確的解決方案，仍是到時候選擇棄用網頁端呢？

• 咱們的解決方案是設置安全的延時時間，模擬用戶的真是操做

問：對於界面是否有想過優化

• 有的，本組的Beta版本任務就包含了美化界面這一塊。

問：是否考慮與用戶簽定隱私協議

• 能夠考慮一下

第四組提出的問題：

注：該組在規定時間內未對我組提出任何問題，故不作回答。

第五組提出的問題：

問：關於界面的問題，是否有考慮在後期從新換一種語言寫界面？若是不換，如何考慮組員的分工問題

• 考慮過，可是不打算換了，由於目前不少功能都用pyqt實現了，另外換語言的成本也很大（代碼重寫、TCP連接也不是很容易創建）

問：電腦睡眠狀態時，軟件可否正常運行？

• 只要網絡保持鏈接、不殺死進程是能夠的。若網絡鏈接斷開，會形成沒法保存的狀況。

問：如何解決聊天記錄可能泄露的問題？

• 本組不會嘗試獲取用戶隱私。並且從技術層面上咱們確實獲取不到用戶的隱私，主要緣由是登陸時是在模擬用戶在web端登陸微信，登陸過程騰訊是有作加密的，咱們獲取不到相關信息。

第六組提出的問題：

問：在alpha版本僅實現了部分功能，是否存在分工不合理現象？

• 事實上，alpha版本已實現了咱們的核心功能【熱詞分析】，而且，本組對alpha版本的任務規劃已所有完成，所以進度是在預期內的。

問：是否有考慮在後續版本中增長帳號密碼登陸微信的方式？

• 本組開發的軟件登陸時是經過WXPY提供的接口模擬用戶在web端登陸微信，而WXPY提供的登陸方式暫時只有用戶掃碼登陸這一方式。

問：在beta階段是否會考慮對已實現功能的優化？

• 這是確定會的。

第七組提出的問題（本組）

第八組提出的問題：

問：大家說網上的資料不多不少須要本身手寫，那麼對於後期如何有效提高團隊的總體效率呢？

• 這二者...有關係嗎？

問：後期對於組內的分工方面是否還要更細緻一點？

• 是的，本組接下來會繼續細化組內的分工，作到合理分配任務。

問：對於ui界面準備如何美化？

• 首先，本組會參考目前較爲熱門的ui設計配色方案，並以此爲依據進行美化；而且，會在能力範圍內作一些調研，爭取讓ui界面更加合理，對用戶更友好。

第九組提出的問題

問：當前實現的功能較少，是否存在團隊分配不合理的狀況？

• 事實上，alpha版本已實現了軟件的核心功能【熱詞分析】，而且，本組對alpha版本的任務規劃已所有完成，所以進度是在預期內的。

問：掃描登錄微信功能是否安全，是否能夠安全？

• 用戶登陸時是在模擬用戶在web端登陸微信，登陸過程騰訊是有作加密的，所以是安全的。

問：所說的PyQt和wxpy的坑，打算如何越過，有沒有具體的計劃？

• 目前算是爬出來一半了，以後主要是由已經踩過坑的同窗來帶領團隊開發

各小組對我組提出的建議及我組改進總結

第一組：

建議：美化界面，提高用戶操做體驗。

• 改進：好的，本組會在接下來的開發過程當中進行改進。

第二組：

建議：網頁端微信封號的問題可否改善。

• 改進：咱們儘量的不形成封號（設置必定的發送延時）

建議：UI 配色應統一美觀。

• 改進：好的，本組會在Beta版本進行改進。

建議：排除掉一些常常用的而且不是用戶須要獲取的詞。

• 改進：能夠考慮設計合理的詞庫，僅統計詞庫中有的詞

第三組：

建議：封號問題以前已經有人提過解決方案了，隱私問題原來小組有說過能夠之後尋求專業人士幫助，我以爲還能夠跟用戶簽定協議，以避免沒必要要麻煩。

• 改進：咱們並無查到什麼針對封號問題的解決方案！

第四組：

建議：推出更多功能，增長用戶體驗。

• 改進：好的，謝謝大家的建議。

第五組：

建議：能夠多去參考一下一些熱門展品的UI以及配⾊

• 改進：好的，謝謝大家的建議。

建議：但願後面能支持對QQ的熱詞分析。

• 改進：咱們會考慮在Beta階段加入

第六組：

建議：先初步實現各項功能再進行後續的迭代和優化

• 改進：好的，謝謝大家的建議。

建議：優化交互界面的細節

• 改進：好的，本組會在Beta版本進行改進。

建議：實現經過帳號密碼來登陸微信以及增長對 qq 的支持根據用戶實際需求改進功能

• 改進：好的！

第八組：

建議：但願後續可以分工分配的更加合理

• 改進：好的！

第九組：

建議：無建議。

我的貢獻分

我的部分

我的PSP

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

我的學習進度條

第N周	新增代碼（行）	累計代碼（行）	本週學習耗時(小時)	累計學習耗時（小時）	重要成長
2	413	413	21	21	學用git；接觸vs性能分析、單元測試功能；
3	0	413	16.5	37.5	閱讀《構建之法》；結對配合；學習NABCD模型；接觸原型開發工具
四、5	1061	1474	23.5	61	結對配合經驗up；瞭解接觸爬蟲
6-9	500	1974	100	161	團隊合做經驗up；文檔編輯能力up；學習Python；學習PyQt
10	265	2239	25	186	繼續學習PyQt，開始動手實踐
11	97	2336	7	193	繼續學習PyQt；進行團隊項目；對本身的認識up
12	54	2784	20	213	進行團隊項目
13	136	2866	6.5	219.5	進行團隊項目
…