軟工 · 第十一次作業 - 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.我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
    • A：
      制定計劃不要剛剛好，應該要有緩衝的餘地，否則遇到問題將會很頭疼；同時也要考慮制定短期計劃，否則容易拖延導致最終計劃不能實現。如果歷史重來一遍，我們會決定在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, 或者其他工具來幫助設計和實現？這些工具有效麼？
    • A：
      團隊使用了UML來對需求和軟體功能進行分析。使用單元測試，對已實現的函式進行測試。這些工具很有效。UML工具幫我們更加明確了需求，系統功能，類間關係等等，使我們對於軟體的開發有更清晰的邏輯。單元測試幫助我們在開發過程中及時排錯，更輕鬆地排錯。
  • 4.比較專案開始的 UML 文件和現在的狀態有什麼區別？這些區別如何產生的？是否要更新 UML 文件？
    • A：
      沒有區別。專案開始後還未對UML文件進行過更新。
  • 5.什麼功能產生的Bug最多，為什麼？在釋出之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?
    • A：在使用者互動的過程中產生的Bug最多。因為涉及到多個使用者，每個使用者有著不同的操作，控制複雜。系統釋出後發現，使用者只有在重新登入後才能收到新訊息。這個原因在於我們在開發的過程中，沒有考慮到兩個使用者同時線上的情況。
  • 6.程式碼複審（Code Review）是如何進行的，是否嚴格執行了程式碼規範？
    • A：程式碼會由隊長進行稽核，主要要求規範命名和介面。
  • 7.我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?
    • A：
      我們剛開始學習軟體開發，要多花時間在學習程式設計上。如果歷史重來一次，我們會在更加花時間在軟體開發上，更完善地完成Alpha版本的設計。

• 測試/釋出

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

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

  • 1.團隊的每個角色是如何確定的，是不是人盡其才？
    • A：有某方面基礎的組員優先安排，有意願做某方面的組員優先安排。由於團隊基本處於零基礎狀態，所以是否人盡其才無法回答
  • 2.團隊成員之間有互相幫助麼？
    • A：團隊成員注重交流，互幫互助，一直是我們的作風
  • 3.當出現專案管理、合作方面的問題時，團隊成員如何解決問題？
    • A：當出現這方面的小問題時，我們會在群內交流，提出各自的看法，當問題較大時，我們會召集開會，商討解決方案

  • 我感謝 _______<姓名>______對我的幫助， 因為某個具體的事情: _____________________。

  • 我們學到了什麼? 如果歷史重來一遍, 我們會做什麼改進?

• 總結:

  • 1.你覺得團隊目前的狀態屬於 CMM/CMMI 中的哪個檔次?
    • A：我覺得團隊目前的狀態還處於第一檔次，即初始級。也是剛剛起步，正學會走路但是走的不快的狀態。
  • 2.你覺得團隊目前處於 萌芽/磨合/規範/創造 階段的哪一個階段?
    • A：我覺得團隊現在剛剛要從磨合階段跨出去，走向規範階段。
  • 3.你覺得團隊在這個里程碑相比前一個里程碑有什麼改進?
    • A：相比於前一個里程碑，團隊現在在隊員溝通這方面做得更好了，基本上遇到難以獨自解決的問題都會是多人一起合力解決，不再像當初自己一個人埋頭苦幹，獨自探索了。
  • 4.你覺得目前最需要改進的一個方面是什麼?
    • A：目前最需要改進的地方是，團隊沒有一個比較核心的人物，比如有豐富的開發軟體的經歷，能夠很好的解析並安排工作的巨人，需要一個這樣的巨人的肩膀。
  • 對照敏捷開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。
    • A：做得比較好的敏捷開發的原則有
      面對面交談
      每隔一段時間反省自己，並作出相應調整
      圍繞有積極性的個人構建專案，並且信任他們能夠完成工作。
      主要在Alpha衝刺階段，兩天一次的站立會議會督促著每個人是否有積極完成自己的任務，而且本組成員基本上的基礎都是比較少的，每個人都會遇到大大小小的問題，解決這些問題只有當面交流，現場除錯修改的效率才是最高的。而在這個專案中，基本也是圍繞著學習能力比較強的大佬們，輔助他們來完成主要的功能。當然除此之外，合作的部分也是佔著很重的比例。

答辯總結

貢獻比例

工作流程

• 我們組的情況挺特殊的，可能是所有組裡面技術能力最差的一組（只是針對於本次作業），面對這個問題，我們並沒有立馬開工進行製作，而是先進行學習（當然是在分好大類前端後端之後），利用了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衝刺開始前，我們將補完Alpha衝刺落下的任務。
  • 對於目前實現的功能是否與做到了開始時想做的功能呢？
    • A: 還有些差距，但我們將在Beta衝刺傾盡我們所能完成它。
• 針對關於零分的問題發起的對話
  • 在答辯現場，有人提出了這個問題，我也做出了相應的迴應，我說過給出零分的理由，也給出了後續調整的方案，但是你們貌似並沒有認真聽講。在提問環節只是為了懟而懟。對於你們看不出前面幾次作業的分數微調，我只能在這裡用這種極端的方法來讓你們明白。就是醬紫，不是所有人都是為了分數來做這個實踐課的，我也不是什麼魔鬼，謝謝————白晨曦

個人部分

PSP表格

學習進度條