此作業要求：
組名：扛把子
組長：遲俊文
組員：宋曉麗 梁夢瑤 韓昊 劉信鵬
答：有充足的時間，我們的小組成員在選題前進行前對專案進行了評估和研究，並且對小組成員所掌握的技術手段有一定的認知。在確定選題後，我們進行了典型使用者和典型場景的定義，並且在整個專案製作過程中，我們各自發揮了各自優勢，並且各自都分配了相對擅長的任務，大大提高了效率，節省了時間。
答：首先，在每週作業發布後的首次例會中，我們會對上一周的工作進行總結，並且對新一周的任務進行細化分工（截止時間精確到小時）。在做討論決定時小組成員各抒己見，保證每乙個成員的民主平等，提出建議後組長組織組員進行分析並投票（投票的形勢遵循少數服從多數的原則）以保證好的建議能夠被得以實行。
4.使用者量、使用者對重要功能的接受程度和我們事先的設想一致嗎？我們離目標更近了嗎？有什麼經驗教訓？如果歷史重來一遍，我們會做什麼改進？
答：我們本次專案的alpha階段實現了psp記錄時間並生成**功能，這也是我們產品的重要功能之一。我們的產品在alpha階段預計的15使用者（不含專案涉及人員）目標達成，使用者在使用專案後為我們提出了許多寶貴的意見例如psp介面美觀度以及初試介面的引導功能不足等，通過與使用者的交流我們了解到了使用者的需求同時也得到的大多數使用者的肯定，所以使用者對於主要功能的接受程度和我們事先設想基本一致。
我們離目標確實更近了，目前該專案已經實現了預期的主要功能，結合使用者的建議後期我們會對專案繼續優化。
經驗教訓是團隊開發中在實現特定功能時要學會變通，不能鑽牛角尖。在設計過程中，我們常會遇到讓大家耗費大量時間但難以解決的問題，這個時候不能故步自封，要學會請教他人以及查詢是否有其他方法可以解決此類問題。
答：原計畫的工作已經完成，並且我們正在進行beta階段的任務。
答：存在。在對部分功能的實現上，我們太過苛刻的用原定方式解決，而忽略了更高效的方式。
答： 是的，我們通過對於專案功能以及作業完成的切割，合理的分配給特定的組員。在任務截止前，組員有權利義務在可能無法完成任務時進行組內求助，其他成員同時也有權利和義務對出現的問題進行討論並提出解決的辦法，整個過程中我們始終按照原有計畫執行，並執行的相對良好。
答：我們的專案預留了緩衝區。因為我們小組是按模組劃分任務的，所以會給任務設定乙個較早的deadline，以方便組內成員檢查修改。緩衝區的作用是為不能按時完成計畫留有緩衝，給我們有條不紊的完成計畫任務提供保障。
答：我們學會了要悉心聽取他人意見，並合理對人任務進行劃分。如果再來一遍，我們會將任務分配更加合理，並且在組內人員無法攻克的問題上，會及時請教他人，並權衡他人提出的建議。
答：在任務的分配時，成員首先要熟悉任務，任務的分配會根據成員自身的實際情況進行。所以組內會有乙個時間訴求，該訴求會經過組內分析確保成員能在自身條件滿足並不影響整體專案進行的情況下進行，精度會根據每天課餘時間的多少有所不同，一般精確到天。
答：足夠。
答：經驗教訓是在遇到問題時要盡早提出來，依靠團隊的力量解決問題會事半功倍的結局問題。在遇到難題時不該把解決問題侷限在某個人上，而是該分享給組內甚至組外的人。
如果重來一遍的話在分配任務的同時會關注每乙個任務的進度，並在過程中及時溝通，及時查詢方法乃至請教他人。
答：是的。
答：我們根據功能的重要程度和難易程度，如果是關係到後續發布的核心功能那麼必須做到按時實現。對於工作量大以及暫時不具備能力完成的功能模組，經組長和組內人員協商可以進行推遲。
答：我們認為實現了預期，本專案的預期就是先期實現記錄時間以及psp**。
答：我們學到了在團隊開發的過程中一定要做到將心比心，在確保自己任務完成的同時要關注整體專案的進行，融洽的氣氛和廣泛的交流是乙個團隊成長的關鍵。
如果歷史重來一遍，我們會提公升對於專案的責任感，在過程中多多交流，增進團隊成員之間的友誼。
答：在設計方面，由具備一定經驗和程式設計能力的同學負責，由團隊整體進行協作。在現實的工作中證明，是合適的時間和人。
答：有。根據問題的性質和類別，有組內成員進行討論和分析，並權衡分析結果的優勢和劣勢後進行組內投票，遵照少數服從多數的原則決定最後結果。
答：在實現時間記錄的問題上我們出現了在暫停後二次計時，而開始時間定格為更改為第二次計時時間的情況。原因是在**設計時出現的判斷錯誤已經前期的測試不夠全面。
答：由於開發周期短，**規範還沒有擬定。**複審主要是alpha階段專案整合之後，產品上線之前，通過**互查、組內個人**分享的形式進行了複審。
答：在產品的設計前要做好市場調研，去了解使用者的 需求，以及使用者所處在的環境。已經在每個功能的實現如何對使用者去進行引導和幫助。
如果重來一遍，我們會讓自己的產品更加親民，充分了解使用者的感受，與此同時要增加嚴格的**規範。
答：有測試計畫，但是因為時間不夠充分，所以測試不細緻。
答：沒有。由於時間有限，我們還沒來得及做這項工作。
答：沒有。
答：alpha階段沒有涉及效能分析。
答：在psp2.0發布的過程中我們遇到了專案**審核無法通過的問題。官方給出的原因是專案有「違法，涉黃」嫌疑，並附上了帶有相關關鍵字的。這是我們意料之外的，2.0版本中我們對圖示介面等進行了大量公升級，但由於該特殊原因在為期兩天的過程裡無法進行發布。但我們的技術人員巧妙地在**中加入了官方的安全介面，最後通過漫長的審核，最後發布成功。
答：經驗是要做好完整的計畫，把專案的 細節盡可能的做到最好，保證專案發布的同時更加要保證專案的質量。
如果重來的話，我們會制定周密的計畫，做好測試，並跟蹤軟體的效能。
事後諸葛亮會議
作業資訊 專案內容 所屬課程 18web方向軟體工程 作業簡介 按照專案回顧模板開展事後諸葛亮會議並撰寫回顧報告 作業要求 團隊專案 任務四 第二次衝刺 作業目的 通過回顧軟體設計 開發 測試 構建 發布的整個過程以及團隊合作狀態總結經驗教訓 參考資料 學生姓名 張家林 撰寫人 於金池 趙政綱 王建...
事後諸葛亮會議
此作業要求參見 組名 板磚 組長 李惠璨 組員 張傳玉 朱航序 趙新萍 樊培毅 魏琛 設想和目標 1.我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？2.我們達到目標了麼 原計畫的功能做到了幾個？按照原計畫交付時間交付了麼？原計畫達到的使用者數量達到了麼?原計畫的...
事後諸葛亮會議總結
問 我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？答 問題和需求明確，但是典型使用者，典型場景好像只是只是口頭說說了。問 是否有充足的時間來做計畫 答 我們覺得需求和計畫是這次實踐中最重要的問題，當然有。問 團隊在計畫階段是如何解決同事們對於計畫的不同意見的？問...