目錄
- 設想和目标
- 計劃
- 資源
- 變更管理
- 設計/實作
- 測試/釋出
- 團隊的角色，管理，合作
- 總結:
- 貢獻分
- 全組讨論的照片
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% |
| 青元 | |
| 宇恒 | 7% |
| 恺琳 | |
| 政演 | 6.5% |
| 一好 | |
| 丹丹 | |
| 鴻傑 | 11% |
| 家偉 | |
| 家燦 | 9% |
| 卉卉 |