目錄3. 敏捷開發
姓名工作量
郝雷明8%
方梓涵15%
杜筱12%
鮑凌函11%
董翔雲11%
黃少丹9%
詹鑫冰7%
曾麗莉9%
曹蘭英9%
吳沅靜9%
2.1. 設想和目標
我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？
a: 解決的問題：為考研學子提供乙個交流經驗和提供題庫資源的平台；
定義：小程式功能定位清澈
有典型使用者和典型場景的描述：
使用者量, 使用者對重要功能的接受程度和我們事先的預想一致麼? 我們離目標更近了麼?
a: 由於小程式還沒通過審核，使用者量暫且未知，
之後會補充
有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?
a: 不要低估了任何乙個專案的開發難度和工作量
改進：每個成員之間溝通更加緊密；
2. 計畫
是否有充足的時間來做計畫?
a: 有足夠的時間準備，團隊分工還是較為明確的
團隊在計畫階段是如何解決同事們對於計畫的不同意見的？
a: 通過線下線上討論的方式，及時溝通，互相理解這個很重要！
你原計畫的工作是否最後都做完了? 如果有沒做完的，為什麼?
a: 團隊每乙個成員基本完成都完成了
有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
a:姓名
反思郝雷明
存在即有意義，縱然有些不合理，但不影響大局發展，也有學到一些不一樣的
方梓涵沒有，都是需要完成的任務
杜筱沒有，為完成那些功能實現，做的事都是必要的
鮑凌函有，走了一些彎路，最終選擇了最合適的雲開發完成功能實現
董翔雲沒有，做的事都有用，有的是現在，有的是以後
黃少丹沒有，踩的坑都能讓我懂得如何更好地避開未來的坑，總結經驗
詹鑫冰有，踩了很多坑
曾麗莉沒有，目前做的都很有必要
曹蘭英雖然現在有些事現在看起來沒必要，但是以後總有乙個時刻會覺得有用吧
吳沅靜有，測試初始文件設計太麻煩了
是否每一項任務都有清楚定義和衡量的交付件?
a: 是，分工將任務已經具體化，但在後端的時候，還是存在有人不清楚自己的任務的現象
是否專案的整個過程都按照計畫進行，專案出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?
a: 基本是按照計畫進行；
專案出現的意外：bug異常的多；
風險：時間分配還是比較緊張，
原因：沒有準備緩衝區，之後beta會安排緩衝區；
在計畫中有沒有留下緩衝區，緩衝區有作用麼?
a: 這個恐怕沒有，整個計畫沒有設留緩衝區
將來的計畫會做什麼修改？（例如：緩衝區的定義，加班）
a: 嗯，之後的時候會考慮增加緩衝區
我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
a: 有效的團隊合作會使專案事半功倍；
改進：無
3. 資源
我們有足夠的資源來完成各項任務麼?
a: 有，人力肯定不缺，因為做的是小程式，其他資源，像時間也不是特別緊張
各項任務所需的時間和其他資源是如何估計的，精度如何?
a: 沒有估計，分到任務後都是盡力完成，也有專門的負責人催促；
後期完善的時候，會估計修改**的時間等等一些資源配置
測試的時間，人力和軟體/硬體資源是否足夠? 對於那些不需要程式設計的資源 (美工設計/文案)是否低估難度?
a: 測試的時間，人力和軟體/硬體資源是否足夠
你有沒有感到你做的事情可以讓別人來做（更有效率）?
a: 應該沒有吧
有什麼經驗教訓? 如果歷史重來一遍, 我們會做什麼改進?
a: 有效的團隊合作會使專案事半功倍；
時間的分配合理促使專案更加順利進行；
改進：無
4. 變更管理
每個相關的員工都及時知道了變更的訊息?
a: 基本上是每個相關的員工都及時知道了變更的訊息。
（但存在：參加開會的成員不知道自己的任務，但是其他人都已經知道各自的任務，任務分配已經很明確了）
我們採用了什麼辦法決定「推遲」和「必須實現」的功能?
a: 根據剩餘的時間和原來的需求規格說明，來決定「推遲」和「必須實現」的功能，
現階段，小程式存在少量的bug和搜尋功能存在問題。
專案的出口條件（exit criteria – 什麼叫「做好了」）有清晰的定義麼?
a: 我們團隊一致認為:小程式功能基本實現作為出口條件
對於可能的變更是否能制定應急計畫?
a: 還沒有遇到特別緊急變化；
如果十萬火急，應該會立即開會並指定口頭上的急需計畫。
員工是否能夠有效地處理意料之外的工作請求？
a: 有員工能力較強，可以意料之外的工作請求；
但是也存在員工無法有效處理意料之外的工作請求（點讚取消功能）的現象
我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
a: 有效的團隊合作會使專案事半功倍；
改進：無
5. 設計/實現
設計工作有沒有碰到模稜兩可的情況，團隊是如何解決的？
a: 有，協商討論一同解決。
團隊是否運用單元測試（unit test），測試驅動的開發（tdd）、uml, 或者其他工具來幫助設計和實現？這些工具有效麼？
a: 有計畫使用單元測試，或者測試出小程式的效能
狀態還是有很大區別的；
原因是專案開始時的文件是基於我們的空想完成的，實際開發過程中不斷地在調整。當然需要更新（事實上我們也確實在做這件事）
a: 目前還沒有變化
什麼功能產生的bug最多，為什麼？在發布之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?
a: 社群功能，因為功能更加複雜；
小程式未發布，現在真機除錯，沒有什麼重要的bug
**複審（code review）是如何進行的，是否嚴格執行了**規範？
a: 目前複審的準則：功能是否可以正常使用，沒有特別嚴格執行**規範
我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
a: 有效的團隊合作會使專案事半功倍；
改進：適當的文字記錄會議內容。
6. 測試/發布
團隊是否有乙個測試計畫？為什麼沒有？
a: 有
是否進行了正式的驗收測試？
a: 正在完成，預估beta階段結束後，測試文件將定稿了
團隊是否有測試工具來幫助測試？
a: 有
在發布的過程中發現了哪些意外問題？
a: 還沒有發布（現在未知）
我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
a: 測試是乙個很難的事情，並沒有想象的簡單；
前期要盡可能考慮測試實施的可行性，測試計畫改了很多次
7. 團隊的角色，管理，合作
團隊的每個角色是如何確定的，是不是人盡其才？
a: 根據每個人的偏好和團隊需要進行分配；是人盡其才
團隊成員之間有互相幫助麼？
a: 有
當出現專案管理、合作方面的問題時，團隊成員如何解決問題？
a: 線下會議討論
8. 總結
你覺得團隊目前的狀態屬於 cmm/cmmi 中的哪個檔次?
a: 可重複級
你覺得團隊目前處於 萌芽/磨合/規範/創造 階段的哪乙個階段?
a: 規範階段
你覺得團隊在這個里程碑相比前乙個里程碑有什麼改進?
a: 分工更加明確
你覺得目前最需要改進的乙個方面是什麼?
a: 使小程式的功能更加完善，例如點讚和舉報功能實現
1-我們的最高目標是通過盡早和持續第交付有價值的軟體來滿足客戶；
舉例：這是我們團隊的共識，小程式是先將整個框架做好後，
通過不斷的除錯bug，達到產品基本可用之後，我們再進一步優化產品
2-歡迎對需求提出變更 - 即使在專案開發後期，要善於利用需求變更，幫助客戶獲得競爭優勢；
3-要不斷交付可用的軟體，週期從幾周到幾個月不等，越短越好
4-專案過程中，業務人員與開發人員必須在一起
舉例：團隊每乙個人既是開發者也是業務人員！
5-要善於激勵專案人員，給他們以所需要的環境和支援，並相信他們能夠完成任務
6-無論是團隊內還是團隊間，最有效的溝通方法是面對面的交談
舉例：在程式開發階段出現：
一名後端成員，在其他後端任務都快要完成各自的任務的前提下，還不知道自己要做什麼！
我們通過線下的會議，由專門的負責人一步步指導，以確保任務可以順利進行！
7-可用的軟體是衡量進度的主要指標
8-敏捷過程提倡可持續的開發，專案方，開發人員和使用者應該能夠保持恆久穩定的進展速度
舉例：整個專案都是連貫的，ui前端後端測試很少出現間隔或者耽誤進度的現象；
其中後端與前端的頁面上有一點點的疑問，但也很快就解決了！
9-對技術的精益求精以及對設計的不斷完善將提公升敏捷性
10-要做到簡潔，盡可能減少不必要的工作，這是一門藝術
11-最佳的架構，需求和設計出自於自組織的團隊
12-團隊要定期反省如何能夠做到更有效，並相應調整團隊的行為。
舉例：每次部落格編寫前都有組內都會舉行會議，討論每乙個人的接下來的任務內容。
特別是運動會期間，前後端的任務分配以及幾天前的測試與後端的對接上。
第06組 alpha衝刺 總結
目錄3.敏捷開發 姓名工作量 郝雷明8 方梓涵15 杜筱12 鮑凌函11 董翔雲11 黃少丹9 詹鑫冰7 曾麗莉9 曹蘭英9 吳沅靜9 2.1.設想和目標 我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？a 解決的問題 為考研學子提供乙個交流經驗和提供題庫資源的平...
第06組Alpha衝刺總結
目錄3.敏捷開發 姓名工作量 郝雷明8 方梓涵15 杜筱12 鮑凌函11 董翔雲11 黃少丹9 詹鑫冰7 曾麗莉9 曹蘭英9 吳沅靜9 2.1.設想和目標 我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？q 解決的問題 為考研學子提供乙個交流經驗和提供題庫資源的平...
第06組 Alpha衝刺 總結
目錄3.敏捷開發 姓名工作量 郝雷明8 方梓涵15 杜筱12 鮑凌函11 董翔雲11 黃少丹9 詹鑫冰7 曾麗莉9 曹蘭英9 吳沅靜9 2.1.設想和目標 我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？a 解決的問題 為考研學子提供乙個交流經驗和提供題庫資源的平...