第十一次作業 - Alpha 事後諸葛亮（團隊）
目錄
設想和目標
1.我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？
我們軟體解決的問題是：人們日常並行事項越來越多，而人的記憶是有限的，我們的記憶罐頭這款
備忘錄可以有效的提醒和安排日常事務，並且提供眾多便捷、智慧、實用的功能。已經定義的十分清楚。（詳情可參見需求分析報告）
典型使用者為：學生黨和工作黨。（在需求分析課堂展示中已有描述。）
典型場景：佩佩和小柯的故事。
（在需求分析課堂展示中已有描述。）
2.我們達到目標了麼（原計劃的功能做到了幾個？ 按照原計劃交付時間交付了麼？
已達到目標，原計劃功能已完成6個：備忘錄的基礎使用、天氣分析、智慧提醒、App使用分析、語音輸入、智慧識別簡訊。剩下1個需在Beta版本完成：形成語音輸入小浮標。
在Alpha版本規定時間完成交付。並進行Alpha版本課堂展示。
3.原計劃達到的使用者數量達到了麼?
- 原定計劃中未對使用者數量做出明確定義。使用者量還需要在Beta版本完成之後進行推廣獲取。
4.使用者量, 使用者對重要功能的接受程度和我們事先的預想一致麼? 我們離目標更近了麼?
- 暫時還未進行推廣，因此還沒有使用者量。離目標更近一步。
5.有什麼經驗教訓? 如果歷史重來一遍,我們會做什麼改進?
- 團隊共享。
計劃
你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?
-在alpha版本的原計劃的資料庫初始化和介面的實現任務最後都完成了，剩下的是beta版本的使用者登入和雲端備份的實現；原計劃的前端功能都已經實現，現在缺少的是頁面的精修，在美觀上還需要改進。
有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
-在android stdio的下載上花費了很長時間，至少有兩天，出現各種問題。以及在程式碼整合的過程中，出現有些人程式碼可以執行，但是有些不能執行的情況。在軟體的問題上出現很多錯，但是有很費時。專案初始計劃是做伺服器上的資料庫和介面，但是這樣會導致手機在沒有網路的情況之下，載入不出資料，整個軟體會處於不能使用的狀態，這和我們這樣一個備忘錄app的使用者使用場景出入很大。發現問題之後決定將資料庫部署在本地。還有就是介面設計的時候，其實有些功能前端可以直接實現的，不需要對應的介面，常常設計出前端不需要的介面；
是否每一項任務都有清楚定義和衡量的交付件?
-在後端部分，資料庫和介面的設計我們是有在需求文件中做了詳細的規劃，根據軟體的原型和需求，規範地設計資料庫和細緻地設計介面的，資料庫表結構和介面需求明確之後才進行的程式碼實現，所以在於整個專案的開發中，任務和進度是很精確的，也提供測試樣例作為參考。
是否專案的整個過程都按照計劃進行，專案出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?
-後端部分，是先根據原型和需求，資料庫表結構和介面需求明確之後才進行的程式碼實現的，按照文件一步步實現的，期間由於對java和AndroidStudio開發的不熟悉，有時在資料庫初始化和sql語句上出現問題；風險的話因為做的功能是相對簡單和基礎的部分，可能在安全係數和資料庫版本升級的部分沒有做的詳盡；對於將來伺服器安全部分會考慮加強安全性的途徑；
在計劃中有沒有留下緩衝區，緩衝區有作用麼?
將來的計劃會做什麼修改？（例如：緩衝區的定義，加班）
-計劃的實施都是在大家都有空的時候，一起進行的。各自在平時有空的時候自行學習和code，也會互相分享經驗，任務完成的也相對高效緊湊，沒怎麼需要加班；一起code的時候，一般都是任務完成到預期進度才各回各家；將來的計劃，我覺得這種狀態挺不錯的（畢竟大家有不同的課業需要兼顧），可能會多一項在固定時間互相交流學習內容和實現思路，這樣對接下來計劃的實現思路會更加明確；不過在每天的任務中難免存在難度無法做完的情況，我們會選擇熬夜完成專案。
我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
-對於後端能實現來說，由於第一次做，對於任務量的不熟悉，在分配任務的之後，會導致有的成員天天埋頭苦幹，有的則無所事事，還有就是不同成員在學習重複的知識，這樣使任務的完成度參差不齊，也降低效率；如果歷史重來一遍，會對任務進行詳盡的分析，明確技術難點和工作量，然後進行任務分派，在提高效率上應該會有所成效；同時，我們可能會選擇多增加程式碼規範性的瞭解，在頁面的設計上也會稍加改進。
資源
我們有足夠的資源來完成各項任務麼?
- 有足夠的資源來完成各項任務。團隊人才濟濟。
各項任務所需的時間和其他資源是如何估計的，精度如何?
- 各項任務所需時間及其他資源是詢問前輩的經驗以及在開發過程中不斷更新考量估計的，精度不太準確，出現超時完成任務的情況。
測試的時間，人力和軟體/硬體資源是否足夠?對於那些不需要程式設計的資源 (美工設計/文案)是否低估難度?
- 並未低估文案和美工設計的難度，在最開始的時候便分配了專員負責這兩個模組。測試時間安排不太合理，暫未分配測試時間。
你有沒有感到你做的事情可以讓別人來做（更有效率）?
-我覺得我做的事情，讓一個心思縝密的組員都能做的不錯。
有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?
-分配任務的時候會對任務進行詳盡的分析，明確技術難點和工作量，然後進行任務分派，能夠讓大家都輕鬆高效的完成專案
變更管理
每個相關的員工都及時知道了變更的訊息?
- 如果有變更的訊息的話，員工們都能從員工群裡面獲取實時的變更訊息，此外在相關員工的小組群裡面也會有變更訊息的提醒，這樣保證了每個相關的員工都能夠及時知道變更的訊息。
我們採用了什麼辦法決定“推遲”和“必須實現”的功能?
- 在專案初期，員工們對於自己負責部分的功能有粗淺瞭解之後，員工們根據功能的實現難度判斷功能屬於“推遲”或“必須實現”的功能，然後在開會期間提出該議題（若無提出，預設“必須實現”），經過討論（參照功能是否為必須實現的主要功能、關鍵功能）後，採取集體投票的方式最終決定該功能屬於“推遲”或“必須實現”的功能！
專案的出口條件（Exit Criteria – 什麼叫“做好了”）有清晰的定義麼?
- 對於我們的專案，我們首先規定了一些基本功能，在最後完工時，這些基本功能就是我們的專案的出口條件。
對於可能的變更是否能制定應急計劃?
- 是的！俗話說計劃趕不上變化，我要以不變應萬變，根據自己所學的和所看的書結合實際情況，做出判斷。接著進行羅列出可行的計劃，然後進行選擇，選出比較好的幾個應急計劃，再對各個計劃、各種方案的優缺點以及成本進行篩選。
員工是否能夠有效地處理意料之外的工作請求？
- 我們的員工在收到意料之外的工作請求時，會先確認其來源的需求，在確認無誤並沒有異議的情況下，能夠合理協調自己的安排以滿足目前的總體需求。
我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
- 首先，每個員工在技術知識方面都或多或少有所收穫，或是前端頁面方面、或是後端介面編寫方面等，此外我們的每個員工都對一個app的開發流程有了一定的瞭解，而不是負責某一部分就只瞭解該部分的內容；其次，我們積累了一些開發經驗，在某些問題的解決上有了解決方法；此外，我們還認識到了軟體開發團隊中員工之間的團結協作和交流溝通是十分重要的，如果一個團隊能夠團結協作並積極地交流溝通，那麼這個團隊的狀態是健康積極的，軟體的開發便能順利愉悅地進行，相反地，如果一個團隊有大大小小的各種矛盾，那麼這個團隊的狀態是不健康的，甚至很可能影響到軟體開發的進度。如果歷史重來一遍，我們會請教有過專案開發經驗的學長或學姐更具體的開發流程細節，更好更快地完成我們專案的分工部分，為開發過程中的“bug”留下更充足的時間；其次，我們會更加註重開發的“規範化”，比如每兩天寫學習總結，將開發過程中遇到的問題的可行解決方法寫成技術文件等；此外，我們會在團隊成員之間的團結協作和積極交流方面做得更好！
設計/實現
設計工作在什麼時候，由誰來完成的？是合適的時間，合適的人麼？
原型的設計工作是卉卉做的，之後迭代是丹丹完成的。原型的設計工作在團隊選題報告之後重新設計的，一方面讓新隊員卉卉熟悉了我們的專案，我們認為讓她來做是比較合適的。（卉：介面醜其實是我的鍋orz）
資料庫和介面的設計是由後端部分的家燦和卉卉在選題報告之後一起討論完成的。
設計工作有沒有碰到模稜兩可的情況，團隊是如何解決的？
負責的原型設計的同學在群裡釋出了很多版本，其他組員也提了許多意見，最終確定了最終版本。
後端的設計工作在後面的程式碼實施階段遇到了一些分歧，也是通過後端組內討論解決的。
團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效麼？
-後端是在Androidstudio裡進行的單元測試，後端同學表示Androidstudio自帶的測試環境比較方便也挺好用的。
比較專案開始的 UML 文件和現在的狀態有什麼區別？這些區別如何產生的？是否要更新 UML 文件？
-差距還是比較大的，區別是在開發過程中發現UML文件的東西不適應專案的開發，需要改變。需要更新UML文件以適應。
什麼功能產生的Bug最多，為什麼？在釋出之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?
-基礎功能中的備忘錄展示，因為對android開發不熟悉，自定義控制元件的使用不熟悉，導致書寫的過程出現很多問題。釋出之後，語音插入之後完成時間是已過期，刪除功能不完善。開發的時候因為alpha版本時間有點趕，未進行完整的測試。
程式碼複審（Code Review）是如何進行的，是否嚴格執行了程式碼規範？
-無，並未嚴格執行程式碼規範。
我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
-學到了如何開發一個專案的全部流程，以及如何有效的分工。同時，每個組員對前後端的交接有了完整的理解。如果歷史能重來，我們會在一開始就進行程式碼規範，以及程式碼複審，這才是軟工實踐的最大意義。以及合併時採用GitHub，讓合併更加高效。
測試/釋出
團隊是否有一個測試計劃？為什麼沒有？
- 測試計劃分為四個方面：
- 測試桌布是否可以自動生成
可自助選擇桌布格式，字號大小，字號顏色，自動生成桌面桌布 - 測試快遞，車票資訊是否可以自動生成
接受車票，快遞資訊，生成備忘資訊 - 測試是否可以新建備忘資訊
- 測試語音轉文字功能
- 測試刪除選中功能
- 測試反饋功能
- 測試桌面控制元件功能
在測試過程中，及時消除bug和解決軟體閃退問題。
是否進行了正式的驗收測試？
- app在桌面可安全開啟，並完成測試計劃提到所有功能，有視訊展示。
團隊是否有測試工具來幫助測試？
- 測試計劃分為前端，後端兩個部分。
前端測試利用Android studio進行build，build成功後按三角執行按鈕，電腦與安卓機利用資料線相連，授予USB訪問許可權，執行成功後，創作介面會在安卓機自動顯現。
後端利用Android studio裡的junit進行測試，測試失敗會顯示錯誤。
團隊是如何測量並跟蹤軟體的效能的？從軟體實際執行的結果來看，這些測試工作有用麼？應該有哪些改進？
- 我們的後端已經寫了一份單元測試來進行測量並跟蹤軟體的效能。從實際執行結果來看，這些測試工作是非常有用的。我們應該適當地豐富測試檔案的內容。
在釋出的過程中發現了哪些意外問題？
- 由於我們在打包APK的過程中，想要將所有的部分調整到最好，導致沒有將APK打包好。
我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
- 我們對前端，後端的部分從一無所知或者只知道大概，到對整個開發流程和APP有了很詳細的瞭解。並且明白瞭如何融入一個團隊中，將團隊變得更好。
我們會對隊員分工進行更詳細得調整，將所有人都加入到開發工作的熱情中。
團隊的角色，管理，合作
團隊的每個角色是如何確定的，是不是人盡其才？
團隊成員之間有互相幫助麼？
當出現專案管理、合作方面的問題時，團隊成員如何解決問題？
每個成員明確公開地表示對成員幫助的感謝：
我感謝 _______<姓名>______對我的幫助， 因為某個具體的事情: _____________________。
我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
總結:
你覺得團隊目前的狀態屬於 CMM/CMMI 中的哪個檔次?
你覺得團隊目前處於 萌芽/磨合/規範/創造 階段的哪一個階段?
你覺得團隊在這個里程碑相比前一個里程碑有什麼改進?
你覺得目前最需要改進的一個方面是什麼?
對照敏捷開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。
貢獻分
| 成員 | 比例 |
|---|---|
| 緒佩 | 13% |
| 青元 | 13% |
| 宇恆 | 7% |
| 愷琳 | 7% |
| 政演 | 6.5% |
| 一好 | 6.5% |
| 丹丹 | 7% |
| 鴻傑 | 11% |
| 家偉 | 11% |
| 家燦 | 9% |
| 卉卉 | 9% |