Alpha 事後諸葛亮（團隊）

軟工 · 第十一次作業 - Alpha 事後諸葛亮（團隊）

組長本次作業連結

現代軟體工程 項目Postmortem

• 設想和目标

  • 1.我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？
    • A：我們的軟體要解決的是結對人的互相提醒的問題，對這個對這個問題定義的很清晰。主要是針對團隊，研友，情侶或者親子，要結對人都關閉鬧鐘，軟體才會停止工作，以達到互相提醒的作用。例如互相約好去學習，設定鬧鐘，醒來的人可以根據軟體的提示知道另一個人是否已經醒來，如果未醒，則可以根據軟體設定的提醒方式來提醒對方。
  • 2.我們達到目标了麼（原計劃的功能做到了幾個？ 按照原計劃傳遞時間傳遞了麼？原計劃達到的使用者數量達到了麼?)?
    • A：我們還未完全達成目标，原定的功能隻實作了兩個，未能按照原定計劃傳遞。由于未完成整體軟體，是以目前還沒有任何使用者。
  • 3.使用者量, 使用者對重要功能的接受程度和我們事先的預想一緻麼? 我們離目标更近了麼?
    • A：由于未對軟體進行釋出，是以使用者量和使用者對功能的接受程度無法估計，是以我們并沒有離目标更近。
  • 4.有什麼經驗教訓? 如果曆史重來一遍, 我們會做什麼改進?
    • A：在傳遞軟體之前，所有人都要有緊迫感，要有壓力，有适當的壓力才會有動力，才能更好的完成軟體。如果曆史重來，我們将制定嚴格的計劃程序，将任務落實，給予所有人适當的壓力，在deadline前完成軟體。

• 計劃

  • 1.是否有充足的時間來做計劃?
    • A：在Alpha沖刺開始之前，大家的大緻分工任務便已配置設定下去，是以開始各自學習開發所要用到的技術、工具等。Alpha沖刺開始之後，會議讨論上大家一緻達成在Alpha沖刺結束前實作基礎功能的計劃，轉而進入了Learning by doing的狀态。而後由于各自的任務不同，主要是各自制定個人的規劃。
  • 2.團隊在計劃階段是如何解決同僚們對于計劃的不同意見的？
    • A：少數服從多數。
  • 3.你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?

    • A：

      有的完成了，有的暫未完成。

      時間上，在Alpha沖刺中後期有期末考試，一定程度上被剝削了一些時間，導緻計劃沒有實作；

      技術上，團隊成員之前并沒有使用過相應的開發工具，開發語言也基本沒有接觸，心有餘而力不足，技術不夠導緻一些問題難以解決，原定計劃沒有實作；

      經驗上，缺少開發經驗，不知先做什麼再做什麼，效率降低。

  • 4.有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
    • A：首先是Alpha沖刺初期，算法很多是靠自己設計，代碼全程靠自己手寫，又由于技術受限經常卡住導緻浪費了很多時間，後來懂得借鑒前人的優秀作品，站在巨人的肩膀上，效率得到了提高；再者是缺少經驗，提前學習了某些技術但在實際開發中并沒有用到，對此次開發而言浪費了時間。
  • 5.是否每一項任務都有清楚定義和衡量的傳遞件?
    • A：一開始并沒有仔細考慮這個問題，導緻最後各部分整合的時候出了些問題。
  • 6.是否項目的整個過程都按照計劃進行，項目出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?

    • A：并沒有都按照計劃，有的部分由于技術等原因暫未實作。

      沒有估計到的風險是軟體工程比想象中的困難，不管是時間上需要更長還是技術上需要更多。原因一是計劃沒有制定好，導緻後期做的事情比前期多，先甜後苦；二是缺少開發經驗，不能很好估計難度。

  • 7.在計劃中有沒有留下緩沖區，緩沖區有作用麼?
    • A：沒有留下，隻是計劃在Alpha沖刺結束前實作基礎功能。
  • 8.将來的計劃會做什麼修改？（例如：緩沖區的定義，加班）

    • A：會計劃提前一天或兩天完成，以留下伸縮的餘地，解決一些突發事件等。

      以及會更多考慮短期計劃的制定，減少拖延症的發生。

  • 9.我們學到了什麼? 如果曆史重來一遍, 我們會做什麼改進?
    • 制定計劃不要剛剛好，應該要有緩沖的餘地，否則遇到問題将會很頭疼；同時也要考慮制定短期計劃，否則容易拖延導緻最終計劃不能實作。如果曆史重來一遍，我們會決定在Alpha沖刺結束前一天實作我們的計劃，同時會細分計劃，做短期計劃制定，循序漸進。

• 資源

  • 1.我們有足夠的資源來完成各項任務麼?
    • A：網上的安卓資源充足，我們有足夠的資源來完成各項任務。
  • 2.各項任務所需的時間和其他資源是如何估計的，精度如何?
    • A：各項任務所需的時間和資源是根據大家公認的難度來進行估計的，精度一般。
  • 3.測試的時間，人力和軟體/硬體資源是否足夠? 對于那些不需要程式設計的資源 (美工設計/文案)是否低估難度?
    • A：測試時間，人力和軟體/硬體的資源不夠充分，對于不需要程式設計的資源并沒有低估難度。
  • 4.你有沒有感到你做的事情可以讓别人來做（更有效率）?
    • A：因為組内大家都是萌新，所有東西都要新學，是以大家的效率應該都是差不多的。
  • 5.有什麼經驗教訓? 如果曆史重來一遍, 我們會做什麼改進?
    • A：資源要充分的利用，要站在巨人的肩膀上來看世界。如果曆史重來，我們要充分學習利用網上已有的項目資源應用到我們自己的項目上，這樣會更具有效率，能更好的完成項目。

• 變更管理

  • 1.每個相關的員工都及時知道了變更的消息?
    • A：我們會在群内進行通知，并確定每個人都能知道并正确了解
  • 2.我們采用了什麼辦法決定“推遲”和“必須實作”的功能?
    • A：我們針對産品的核心定義進行篩選，厘清核心功能和附帶功能
  • 3.項目的出口條件（Exit Criteria – 什麼叫“做好了”）有清晰的定義麼?
    • A：我們産品的出口條件是：具備能夠正常運作的核心功能
  • 4.對于可能的變更是否能制定應急計劃?
    • A：若出現突發變更，我們會根據項目目前的狀況和剩餘時間制定應急計劃
  • 5.員工是否能夠有效地處理意料之外的工作請求？
    • A：若出現意料之外的工作請求，我們會制定應急計劃，讓員工盡可能有效地處理
  • 6.我們學到了什麼? 如果曆史重來一遍, 我們會做什麼改進?
    • A：這次alpha沖刺體驗，具有重要意義，也收獲頗豐，不管是技術方面，還是團隊寫作方面，但是我們也還有許多不足之處，如果曆史重來一遍，我們就能多避免出錯，并有更好的安排計劃

• 設計/實作

  • 1.設計工作在什麼時候，由誰來完成的？是合适的時間，合适的人麼？
    • A：設計工作是在小組會議上不斷讨論決定的。由組長牽頭讨論，大家共同商讨，最後由組長決定。時間一般是晚上9點過後，這時候大家都在宿舍。
  • 2.設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？
    • A：有碰到過。早期關于關聯鬧鐘的取消方式團隊有過争議。最終采取少數服從多數的辦法解決。
  • 3.團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實作？這些工具有效麼？
    • 團隊使用了UML來對需求和軟體功能進行分析。使用單元測試，對已實作的函數進行測試。這些工具很有效。UML工具幫我們更加明确了需求，系統功能，類間關系等等，使我們對于軟體的開發有更清晰的邏輯。單元測試幫助我們在開發過程中及時排錯，更輕松地排錯。
  • 4.比較項目開始的 UML 文檔和現在的狀态有什麼差別？這些差別如何産生的？是否要更新 UML 文檔？
    • 沒有差別。項目開始後還未對UML文檔進行過更新。
  • 5.什麼功能産生的Bug最多，為什麼？在釋出之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?
    • A：在使用者互動的過程中産生的Bug最多。因為涉及到多個使用者，每個使用者有着不同的操作，控制複雜。系統釋出後發現，使用者隻有在重新登入後才能收到新消息。這個原因在于我們在開發的過程中，沒有考慮到兩個使用者同時線上的情況。
  • 6.代碼複審（Code Review）是如何進行的，是否嚴格執行了代碼規範？
    • A：代碼會由隊長進行稽核，主要要求規範命名和接口。
  • 7.我們學到了什麼? 如果曆史重來一遍, 我們會做什麼改進?
    • 我們剛開始學習軟體開發，要多花時間在學習程式設計上。如果曆史重來一次，我們會在更加花時間在軟體開發上，更完善地完成Alpha版本的設計。

• 測試/釋出

  • 1.團隊是否有一個測試計劃？為什麼沒有？是否進行了正式的驗收測試？
    • A：有一個比較簡單的測試計劃，主要由于團隊中也沒有比較有經驗的人，也沒有進行比較完整的規劃。
  • 2.團隊是否有測試工具來幫助測試？
    • A：有試着用測試工具幫助測試，但基本都是靠自己研究探索，畢竟缺乏經驗。沒有進行正式的驗收測試，就目前完成的軟體來說，仍存在着一些小小的問題，也還沒有達到令人滿意的程度，是以還在嘗試完善優化軟體。
  • 3.團隊是如何測量并跟蹤軟體的效能的？從軟體實際運作的結果來看，這些測試工作有用麼？應該有哪些改進？
    • A：測量效能主要有軟體是否正常運作，運作速度是否高效率，運作效果是否令人滿意等。從實際結果來看，測試工作還是有用的，在測試的過程中還是發現了一些開發時欠缺考慮的問題，改進主要還是從軟體本身出發，争取能更優化下使用者體驗。
  • 4.在釋出的過程中發現了哪些意外問題？
    • A：釋出的過程中，也是因為網絡的問題，沒有統一規範的原因，導緻了最終代碼整合的時候出現了難以解決的困難，基本上每次遇到的困難都是新的困難，都是令人意外的，之前沒出現過的問題。
  • 5.我們學到了什麼? 如果曆史重來一遍, 我們會做什麼改進?
    • A：軟體的開發過程中，測試這一環節是必不可少的。一款軟體即使測試完畢釋出後，仍然會出現或多或少的問題，而這就展現了在測試環節你付出了多少，就決定了你最後遇到的問題是大是小。而測試也是需要有技巧性，有針對性的去測試你的軟體，而不能照搬其他人的測試方式，軟體都有各自獨有的特點。如果曆史重來一遍。我們會在測試的過程前，再進行更多的交流和讨論，争取考慮更多方面可能出現的問題，有針對性的提出一個詳細的測試計劃，并配置設定給多人重複測試，争取減少釋出後遇到的問題。

• 團隊的角色，管理，合作

  • 1.團隊的每個角色是如何确定的，是不是人盡其才？
    • A：有某方面基礎的組員優先安排，有意願做某方面的組員優先安排。由于團隊基本處于零基礎狀态，是以是否人盡其才無法回答
  • 2.團隊成員之間有互相幫助麼？
    • A：團隊成員注重交流，互幫互助，一直是我們的作風
  • 3.當出現項目管理、合作方面的問題時，團隊成員如何解決問題？
    • A：當出現這方面的小問題時，我們會在群内交流，提出各自的看法，當問題較大時，我們會召集開會，商讨解決方案
  • 我感謝何裕捷對我的幫助， 因為某個具體的事情：在我的界面出現bug或者Android Studio出現運作問題時經常能幫我解決。
  • 我們學到了什麼? 如果曆史重來一遍, 我們會做什麼改進?

• 總結:

  • 1.你覺得團隊目前的狀态屬于 CMM/CMMI 中的哪個檔次?
    • A：我覺得團隊目前的狀态還處于第一檔次，即初始級。也是剛剛起步，正學會走路但是走的不快的狀态。
  • 2.你覺得團隊目前處于 萌芽/磨合/規範/創造 階段的哪一個階段?
    • A：我覺得團隊現在剛剛要從磨合階段跨出去，走向規範階段。
  • 3.你覺得團隊在這個裡程碑相比前一個裡程碑有什麼改進?
    • A：相比于前一個裡程碑，團隊現在在隊員溝通這方面做得更好了，基本上遇到難以獨自解決的問題都會是多人一起合力解決，不再像當初自己一個人埋頭苦幹，獨自探索了。
  • 4.你覺得目前最需要改進的一個方面是什麼?
    • A：目前最需要改進的地方是，團隊沒有一個比較核心的人物，比如有豐富的開發軟體的經曆，能夠很好的解析并安排工作的巨人，需要一個這樣的巨人的肩膀。
  • 對照靈活開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。

    • A：做得比較好的靈活開發的原則有

      面對面交談

      每隔一段時間檢討自己，并作出相應調整

      圍繞有積極性的個人建構項目，并且信任他們能夠完成工作。

      主要在Alpha沖刺階段，兩天一次的站立會議會督促着每個人是否有積極完成自己的任務，而且本組成員基本上的基礎都是比較少的，每個人都會遇到大大小小的問題，解決這些問題隻有當面交流，現場調試修改的效率才是最高的。而在這個項目中，基本也是圍繞着學習能力比較強的大佬們，輔助他們來完成主要的功能。當然除此之外，合作的部分也是占着很重的比例。

答辯總結

貢獻比例

組員	工作比例	工作内容
白晨曦	答辯工作準備與前端制作
樂忠豪	0.12	資料庫搭建與後端指導
蔡子陽		接口制作與前端對接
黃培鑫		前端制作
李麒		接口制作與伺服器搭建
王煥仁	0.14
陳德斌	0.11
林志華	0.15	前端制作（主要功能的完成）
何裕捷

工作流程

• 我們組的情況挺特殊的，可能是所有組裡面技術能力最差的一組（隻是針對于本次作業），面對這個問題，我們并沒有立馬開工進行制作，而是先進行學習（當然是在分好大類前端後端之後），利用了2次的部落格報告時間（四天）進行學習和讨論。具有一定基礎之後，我們展開了細節商定大會，先進行自己的學習報告，前後端交流，商讨前端界面的一些細節，功能如何實作等等，之後根據個人的能力來領取任務，對前端後端進行詳細分工。在基本确定所要制作的内容後，開始趕進度，期間經常一起出來肝軟工，有的人在部分前端制作完成後，幫助其他有困難的人進行制作。在所有分工完成後，進行整合，測試。

本組的現場答辯得分

平均分：68.67

其他組對本組提出的問題及本組回答

• 針對第一組問題：
  • 項目進度似乎落後于Alpha前制定的目标,是否考慮在beta前繼續完善産品?
    • A:項目進度似乎落後于Alpha前制定的目标，對此我們感到十分抱歉，在beta沖刺前我們将會完成Alpha制定的目标。
  • 産品的UI似乎缺少必要的風格統一,是否考慮後期統一一下?
    • A:後期我們将會對頁面經行一個統一的美化。
  • 後端如何保證同一時間提醒一個鬧鐘的各個關聯使用者,實作的原理是?
    • A:這個和普通的鬧鐘實作原理是一樣的，相當于每一個關聯使用者都有一個這樣的鬧鐘。
• 針對第二組問題：
  • 計劃界面中的黃底是存在計劃嗎？黑字和紅字是什麼意思？
    • A:黃底表示當天有團隊計劃，紅字表示當天有個人計劃，黑字表示當天無個人計劃。這些在答辯過程中我們解釋過了，請尊重演講者。
  • 計劃界面中的月曆和2018年11月的月曆不相同，是還沒完成嗎？
    • A:兄弟，你是在搞笑嗎？哪裡不一樣了？
  • 計劃是否也會響起鬧鐘？還是會彈出資訊提示？
    • A:計劃本身并沒有附加提醒功能，隻有當關聯上鬧鐘後才會彈出資訊提示。
• 針對第三組問題：
  • 忘記密碼這一塊如果手機也換了有考慮怎麼解決嗎
    • A:我們的賬戶并不是綁定手機的，忘記密碼的話可以通過郵箱找回或其他方法。
  • 有考慮過如何調動組内積極性嗎？如果有考慮好的話也可以給我們組一些建議
    • A:請喝奶茶。
  • 進度似乎有些堪憂，接下來有沒有具體的計劃與任務配置設定呢？
    • A:接下來會完成Alpha定下的目标，其實我們的進度并沒有落後很多。
• 針對第四組問題：
  • 界面美觀問題是如何解決的呢？
    • A: 後期将會對界面經行美化，可能會參考一些目前熱門的界面風格。
  • 上次提到過的團隊鬧鐘問題考慮如何解決嗎？
    • A: 鬧鐘發起者會将鬧鐘傳到資料庫中，團隊中的其他人可從資料庫擷取鬧鐘，以此實作團隊鬧鐘
  • 無視訊示範及現場示範，是否有動态可行式的示範視訊？
    • A: 後期會補上視訊。
• 針對第六組問題：
  • 界面不夠美觀，顔色單調，怎麼解決？
    • A:後期将會對界面經行美化，可能會參考一些目前熱門的界面風格。
  • 如何處理鬧鐘之間關聯的問題？
    • A:鬧鐘之間并沒有關聯，是鬧鐘關聯計劃。
  • 是否要重制面對打“0分”這一問題？
    • A: 沒錯我們要重制面對打0分的問題，這次就打了零分，我求你看一看。
• 針對第七組問題：
  • 如果手機預設鬧鐘設定的時間和你們的APP鬧鐘沖突了，會出現什麼情況，你們怎麼解決？
    • A: 舉個例子，比如你在聽歌的過程中上優酷看視訊，歌曲播放器将會暫停，我們這個鬧鐘也是一樣的，後出現的會頂掉先出現的。
  • ui設計的日期選擇界面配色不夠美觀,考慮再優化一下嗎？
    • A: 配色方面我們後期可能會去修改優化一下。
  • 示範時并未展示視訊,項目進度似乎不太好,有考慮如何加快開發進度嗎？
    • A: 我們這兩天已經有在加快開發進度了。
• 針對第八組問題：
  • 對于落下的進度準備如何彌補？
    • A: 在Beta沖刺開始前，我們将補完Alpha沖刺落下的任務。
  • 小組成員可能學習成本太高而在時間緊湊的情況下如何提升push到每一個人？
    • A: 每一個人盡量不學習到重複的知識，然後互相交各自會的部分。
  • 對于ui界面準備如何美化？
    • A: 可能會參考一些目前熱門的界面風格來進行美化UI。
• 針對第九組問題：
  • ui不夠漂亮，是否有考慮過更簡潔清楚的界面呢？
    • A:UI确實不夠漂亮，我們的界面已經算是比較簡介的了，沒有多餘的東西。
  • 有組員中途參加比賽，對于落下的進度，你們如何彌補？
  • 對于目前實作的功能是否與做到了開始時想做的功能呢？
    • A: 還有些差距，但我們将在Beta沖刺傾盡我們所能完成它。
• 針對關于零分的問題發起的對話
  • 在答辯現場，有人提出了這個問題，我也做出了相應的回應，我說過給出零分的理由，也給出了後續調整的方案，但是你們貌似并沒有認真聽講。在提問環節隻是為了怼而怼。對于你們看不出前面幾次作業的分數微調，我隻能在這裡用這種極端的方法來讓你們明白。就是醬紫，不是所有人都是為了分數來做這個實踐課的，我也不是什麼魔鬼，謝謝————白晨曦

個人部分

PSP表格

PSP2.1	Personal Software Process Stages	預估耗時（分鐘）	實際耗時（分鐘）
Planning		60	90
· Estimate	· 估計這個任務需要多少時間
Development	開發	370	460
· Analysis	· 需求分析 (包括學習新技術)	120	150
· Design Spec	· 生成設計文檔	30
· Design Review	· 設計複審 (和同僚稽核設計文檔)
· Coding Standard	· 代碼規範 (為目前的開發制定合适的規範)
· Design	· 具體設計
· Coding	· 具體編碼
· Code Review	· 代碼複審	10
· Test	· 測試（自我測試，修改代碼，送出修改）	100
Reporting	報告
· Test Report	· 測試報告
· Size Measurement	· 計算工作量
· Postmortem & Process Improvement Plan	· 事後總結, 并提出過程改進計劃	20
合計		580

學習進度條

第N周	新增代碼(行)	累計代碼(行)	本周學習耗時(小時)	累計學習耗時(小時)	重要成長
3	17		Axure up;NABCD模型
4	1000		23	40	八爪魚采集器；字元統計
5-9			140	團隊合作開發項目；java學習
		8	148	java學習，jdk,eclipse
11		1100		178	Android Studio
12		1200	35	213	Android Studio界面

照片