甜美女孩專案2048結果

整理：鄧畫月、曾禕祺

設想和目標

1. 我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？

  弄一個給使用者消磨時間的遊戲，定義的很清楚。該遊戲玩法簡單，典型使用者大概是學生，主要是空閒時間比較多的大學生，空閒時間在宿舍或者其他地點進行遊戲。

2.是否有充足的時間來做計劃?

有時間，但是大部分人並不知道如何利用這一段時間來做計劃。

3. 團隊在計劃階段是如何解決同事們對於計劃的不同意見的？ 

團隊一起討論的時候，有不同意見的話當時就會提出，然後一起解決。一般來說，少數服從多數。

計劃

1.你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?

原計劃中的兩個功能沒做完，一是因為水平問題，自己學的知識還太少了。二是因為時間問題，做專案期間有兩場較重要的期末考試，需要比較多的時間用來複習。

2. 有沒有發現你做了一些事後看來沒必要或沒多大價值的事?

有一些，但是大家認為與其不斷地爭論某些事情有沒有必要，不如做了再說。

3.是否每一項任務都有清楚定義和衡量的交付件?

大部分是有的，但可能各人理解會有偏差

4. 是否專案的整個過程都按照計劃進行?

基本按照計劃進行。

5. 在計劃中有沒有留下緩衝區，緩衝區有作用麼?

好像沒有留緩衝區。

6. 將來的計劃會做什麼修改？（例如：緩衝區的定義，加班）

將來的計劃應該就是留緩衝區。

資源

1. 我們有足夠的資源來完成各項任務麼?

有吧

2. 各項任務所需的時間和其他資源是如何估計的，精度如何?

大概估計的，精度不太高。後來隨著專案任務的加重，大家只顧得上幹活，沒時間考慮精度問題。

3. 使用者測試的時間，人力和軟體/硬體資源是否足夠?

    足夠

4. 你有沒有感到你做的事情可以讓別人來做（更有效率）?

我們分工還挺明確的，有美工有開發有測試。各自完成自己的任務就可以了，還挺有效率的。

變更管理

1. 每個相關的員工都及時知道了變更的訊息?

正常情況下都可以。

2. 我們採用了什麼辦法決定“推遲”和“必須實現”的功能?

討論。

3.  專案的出口條件（Exit Criteria）是否得到清晰的定義?

不太清晰。

4. 對於可能的變更是否能制定應急計劃?

基本沒有，到時候隨意抓人頂上。

5. 員工是否能夠有效地處理意料之外的工作請求？

規定所有請求都轉到PM那裡處理，這樣減輕了開發人員的壓力，讓他們有大部分時間花在自己那一畝三分地上。

設計/實現

1. 設計工作在什麼時候，由誰來完成的？是合適的時間，合適的人麼？

專案一開始，由美工和負責介面的同學完成。是的。因為要定好介面大小，圖片按鈕之類的東西。

2. 設計工作有沒有碰到模稜兩可的情況，團隊是如何解決的？

很多，就看具體執行的人是如何解決的。一般由美工和介面的直接解決。

3. 團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效麼？

沒有

4.  什麼功能產生的Bug最多，為什麼？

紙牌2048！大概是因為還沒有實現遊戲功能（哈哈哈哈哈）

5. 程式碼複審（Code Review）是如何進行的，是否嚴格執行了程式碼規範？

專人複審。一開始定了程式碼規範，但後來並沒有嚴格執行。

測試/釋出

1.   團隊是否有一個測試計劃？為什麼沒有？

我們有測試計劃。

2.  是否進行了正式的驗收測試？

否

3.  團隊是否有測試工具來幫助測試？

否

4.  團隊是如何測量並跟蹤軟體的效能的？從軟體實際執行的結果來看，這些測試工作有用麼？應該有哪些改進？

直接執行點選“玩遊戲”，在玩的過程中測試演算法是否有問題等等。

5.  在釋出的過程中發現了哪些意外問題？

基礎2048的演算法有一些不太對的地方。

討論照片：

            團隊成員在Alpha階段的角色和具體貢獻：設總分20*6=120