【設想和目標】

• Q1：我們的軟件要解決什麽問題？是否定義得很清楚？是否對典型用戶和典型場景有清晰的描述？
• “小葵日記”是為了解決18-30歲年輕用戶在記錄生活時希望得到一美體驗友好、功能全而不雜並提供分享平臺的日記app的問題而開發的。
• Q2：我們達到目標了麽（原計劃的功能做到了幾個？ 按照原計劃交付時間交付了麽？原計劃達到的用戶數量達到了麽?)?
• alpha階段原計劃完成的三個模塊完成了兩個，但順帶完成了兩個計劃外的功能。
• 已按照原計劃提交審核。
• 無用戶量。
• Q3:用戶量, 用戶對重要功能的接受程度和我們事先的預想一致麽? 我們離目標更近了麽?
• 無用戶量，先占個坑，beta之後再來qwq。
• Q4:有什麽經驗教訓?如果歷史重來一遍,我們會做什麽改進?
• 經驗教訓就是每個階段的目標一定按照每個階段的含義以及時間來規劃，在保證最小可用的原則時，盡量達到最大的可展示性。
• 會做的最大改進是要先確定最低標準，再進行開發，防止在非重點的功能上耗費太多時間。

【計劃】

• Q1：是否有充足的時間來做計劃?
• alpha的計劃時間有點倉促。
• Q2：團隊在計劃階段是如何解決同事們對於計劃的不同意見的？
• 一起分析不同意見產生的原因，以及兩種方式各自產生的結果，最後選擇對團隊最有利的那種。總結來講就是一定要認真傾聽、及時交流。（真實情況是我們團隊的隊員基本對所安排的計劃沒有意見。隊員有意見這種事情的發生，我認為最大原因是出於隊長，對於整體的情況考慮得不夠到位，需要自我反思。）
• Q3：你原計劃的工作是否最後都做完了?如果有沒做完的，為什麽?
• 原計劃工作未全部完成，大致完成80%。
• 原因主要有兩點：1.沖刺時間不符預期；2.沖刺目標不夠準確（已反思）。
• Q4：有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
• 有的。其主要原因還是上面提到的目標不夠準確。
• Q5：是否每一項任務都有清楚定義和衡量的交付件?
• 無硬性要求。通常情況是完成一個主要功能後進行團隊內部的簡單測試，無bug，並且使用相對友好即算是完成交付。
• Q6：是否項目的整個過程都按照計劃進行，項目出了什麽意外？有什麽風險是當時沒有估計到的，為什麽沒有估計到?
• 並不是都按照計劃進行。
• 前期進度超乎意料的緩慢。
• 團隊成員們對新技能的學習時間比預料之中要長。
• 前期計劃過於理想，沒有考慮到其他學科作業、考試、電氣實習等除軟工項目之外的時間殺手。
• Q7：在計劃中有沒有留下緩沖區，緩沖區有作用麽?
• 有的。
• 預留了睡眠時間^ _ ^，隨時準備為項目奉獻睡眠。
• 還是挺有用的，Alpha版本交付的前幾天和隊友一起使用了熬夜大法，補上前期落下的進程。
• Q8：將來的計劃會做什麽修改？（例如：緩沖區的定義，加班）
• 緩沖區並不打算修改。
• Q9：我們學到了什麽?如果歷史重來一遍,我們會做什麽改進?
• 要做的改進應該就是在計劃之前問清楚團隊成員的具體學習進度吧（:D細分到每個知識點)，而不是問個大概就完了，這樣計劃表才能更符合實際。

【資源】

• Q1：我們有足夠的資源來完成各項任務麽?
• 人力資源算夠用了。
• 時間資源匱乏。
• 其他資源好像沒什麽了，暫時沒發現哪些欠缺的。
• Q2：各項任務所需的時間和其他資源是如何估計的，精度如何?
• 各項任務所需時間都是通過與任務的負責人溝通後，(經過一系列友好辯論後)取他們能夠完成的最快時限。
• 這麽做的主要原因是我（隊長）是負責前端的，對於後端的了解並不如我的後端隊友們深，相比門外漢的硬性要求，還是應該選擇尊重並信任隊友們的自我判斷。
• 精度不算高，只精確到天數，我們團隊的任務匯報形式都是“x天完成x個任務，分別是xxx,xxx...”。
• Q3：測試的時間，人力和軟件/硬件資源是否足夠? 對於那些不需要編程的資源(美工設計/文案)是否低估難度?
• 同Q1，時間資源不足，人力資源勉強夠用，軟件/硬件資源暫時沒有看出問題，算夠用吧:D
• Q4：你有沒有感到你做的事情可以讓別人來做（更有效率）?
• 沒有，每個隊友的任務都挺滿的，並且任務量都不會差很多，再幫別人分攤任務不管從哪個角度來講效率都不會比現在高。
• Q5：有什麽經驗教訓?如果歷史重來一遍,我們會做什麽改進?
• 雖然現在人手勉強夠用，但每個人的工作量還是挺多的，如果歷史重來一遍，大概會去挖幾個墻角吧:D

【變更管理】

• Q1：每個相關的員工都及時知道了變更的消息?
• 可以說是的。一般都什麽重要的消息都會第一時間發布在群裏，並且當天開會時再強調一遍，確保每個相關隊員都能知道。
• Q2：我們采用了什麽辦法決定“推遲”和“必須實現”的功能?
• 按照之前討論過的優先級以及項目實際進展來決定，先實現優先級高的，優先級靠後的在時間不足的情況下推遲實現。
• Q3：項目的出口條件（ExitCriteria–什麽叫“做好了”）有清晰的定義麽?
• 定義：界面優美、使用友好、無明顯bug。

• 以及一個終極評判標準：該項目可否成為團隊成員的自留產品。

• Q4：對於可能的變更是否能制定應急計劃?
• 可以的。
• Q5：員工是否能夠有效地處理意料之外的工作請求？
• 可以的，他們都很聰明:D

• Q6：我們學到了什麽? 如果歷史重來一遍, 我們會做什麽改進?
  -個人覺得在管理這一塊我們團隊做的還算可以，暫時沒有發現有什麽太大的問題。

【設計/實現】

• Q1：設計工作在什麽時候，由誰來完成的？是合適的時間，合適的人麽？
• 原型設計是由煒坤同學在項目開發前完成的；UI設計是由語懇同學根據前端進度和需要完成的；接口設計是由後端小分隊在項目開發前完成的（參考了前端小分隊的看法）。
• Q2：設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？
• 發現就及時解決，不存在一拖再拖，拿不準主意找其他隊友協商。對於一邊動工一邊修改設計（特別是原型和接口）的行為表示不支持不贊成。
• Q3：團隊是否運用單元測試（unittest），測試驅動的開發（TDD）、UML,或者其他工具來幫助設計和實現？這些工具有效麽？比較項目開始的UML文檔和現在的狀態有什麽區別？這些區別如何產生的？是否要更新 UML 文檔？
• 有用過其他工具來幫助設計，例如mockplus和staruml等。
• 有效，簡單易上手。
• 相比之前，現在的文檔更豐富。
• 主要是思考的角度更深層，對於項目的理解更為細致。當然，各種設計稿也讓文檔顯得豐富了不少。
• Q4：什麽功能產生的Bug最多，為什麽？在發布之後發現了什麽重要的bug?
• 現完成的功能基礎圖文編輯功能產生的bug最多，還記得前端隊友改bug改了很久。
• 主要原因是想支持圖文混插編輯，難度會比普通文字編輯大，並且對於這方面之前了解的可以說是少了，所以容易產生bug。
• 暫未發布，就驗收的成果來說，發現手寫塗鴉方面還存在的小bug，會在beta版本中進行改進。
• Q5:為什麽我們在設計/開發的時候沒有想到這些情況?代碼復審（CodeReview）是如何進行的，是否嚴格執行了代碼規範？
• 不動手怎麽知道有多難啊(+_+)?。
• 現階段並沒有執行代碼復審，前後端使用的語言不同，所以沒有統一制定代碼規範，都是每個小分隊各自制定各自的。
• Q6:我們學到了什麽?如果歷史重來一遍,我們會做什麽改進?
• 簡化功能，不要畫太大的餅?_?。

【測試/發布】

• Q1：團隊是否有一個測試計劃？為什麽沒有？
• 有制定詳細的驗收驗證標準，但還未進行正式測試。
• 認為並不是現階段的重點工作。（功能都還沒完成，沒什麽好測的。。。）
• Q2：是否進行了正式的驗收測試？
• 沒有。原因如上。
• Q3：團隊是否有測試工具來幫助測試？
• 沒有。原因如上。
• Q4：團隊是如何測量並跟蹤軟件的效能的？從軟件實際運行的結果來看，這些測試工作有用麽？應該有哪些改進？
• Alpha階段對於軟件的效能方面的要求較低，所以跟蹤測量什麽的，不存在的。
• 會在beta階段進行效能測量和改進。
• Q5：在發布的過程中發現了哪些意外問題？
• 最大的意外大概就是還沒有發布吧:D。
• Q6：我們學到了什麽?如果歷史重來一遍,我們會做什麽改進?
• 對於測試，我們還是秉持著原本的觀點，Alpha階段以實現功能為主，不過多考慮效能測試方面的事，畢竟要先會跑才能談飛啊。

【團隊的角色，管理，合作】

• Q1:團隊的每個角色是如何確定的，是不是人盡其才？
• 角色確定流程如下：隊長簡單介紹每個角色，並給出人數限制——隊員們自我思考幾分鐘——待隊員們都準備好後采取先到先得的方式進行“搶”角色——根據隊員真實情況進行微調。
• 目前看來隊員們對於各自的角色完成的都不錯，但也不能說是人盡其才，完成的不錯說明他們優秀，就算換到其他角色應該同樣也能做的不錯。
• Q2:團隊成員之間有互相幫助麽？
• 有的，各小分隊經常私下組織去自習，並且宿舍離得都很近，交流問題很方便。
• Q3:當出現項目管理、合作方面的問題時，團隊成員如何解決問題？
• 及時進行友好的溝通交流。問題不大在線上解決，問題較嚴重時開個臨時會議，面對面交流。

• Q4:每個成員明確公開地表示對成員幫助的感謝 （並且寫在各自的博客裏）：

• Q5:我們學到了什麽? 如果歷史重來一遍, 我們會做什麽改進?
• 因為自己是做前端的，所以時刻都想從後端拉個人過來幫忙:D。

• 如果歷史重來，大概會在前後端的人數分配上再多做考慮，可以將後端人員調成2個試試，增加一個前端人員。（但估計會被拒絕:D）

【總結】:

• Q1：你覺得團隊目前的狀態屬於CMM/CMMI中的哪個檔次?
• CMMI二級（管理級）
• 之前沒接觸過CMM/CMMI之類的定義，查了度娘，覺得二級會更符合一些:D。
• Q2：你覺得團隊目前處於 萌芽/磨合/規範/創造
• 規範和創造的過渡階段。
• Q3：階段的哪一個階段?
• 簡單來講是屬於每個人都知道自己現在該做什麽，以及接下來該做什麽的階段，不需要隊長每天督促和安排任務（隊長表示很省心:D）。
• Q4：你覺得團隊在這個裏程碑相比前一個裏程碑有什麽改進?
• 大概就是對於項目了解的更深入、對各自的角色掌握得更好，很少有多臉懵逼的場面了:D。
• Q5：你覺得目前最需要改進的一個方面是什麽?
• 測試方面可以考慮開始制定計劃了。
• Q6：對照敏捷開發的原則,你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。
• 1. 第6條原則：在團隊內部，最具有效果並且富有效率的傳遞信息的方法，就是面對面的交談。
• 原因：上面也提到過，我們小組經常各分隊私下約自習，並且宿舍離得比較近，因為討論一個bug串門到深夜也是常態。
• 1. 第12條原則：每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，然後相應地對自己的行為進行調整
• 原因：每個階段都進行反省是一直都有的習慣:D。非要舉具體例子的話，大概就是某次被批評之後，團隊成員們在操場看了4個小時的星星吧（從晚上10點半到淩晨2點半）。

【團隊合照（小黃衫照）】:

• 1. 這張照片14號就拍完了，就想著寫總結的時候一起放比較有意義（其實主要是懶得再拍了:D），所以拖了好久才發。
• 1. 本來想拍太陽的，奈何14號前幾天一直在陰天下雨(￣ε(#￣)
• 1. 想體現出一種唯我獨尊的感覺，不知道為什麽拍成追悼會了(+_+)?
• 獲得小黃衫的感想：意外，震驚，開心。對應的表情應該是這樣子的：(⊙o⊙)？ —— Σ(っ °Д °;)っ —— (ノω<。)ノ))☆.。
• 附圖：
  

【學習進度條】

alpha沖刺（事後諸葛亮）