目錄設想和目標計劃資源變更管理設計/實現測試/發布團隊的角色，管理，合作總結:貢獻分全組討論的照片

設想和目標

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%

全組討論的照片

總結

以上是生活随笔為你收集整理的诸葛亮的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。