軟工網絡15個人作業4——alpha階段個人總結

一、個人總結

用自我評價表：http://www.rzrgm.cn/xinz/p/3852177.html 總結Alpha沖刺過程。

由于直接用markdown生成的表格優點不太好看，所以用了截圖+拼接

二、回答問題

我們在課程開始之初，曾經要求大家針對軟件工程提出問題：個人閱讀作業2，那么在經過alpha階段，大家是否對軟件工程有了一定的了解？請結合自己提出的問題進行回答。

個人閱讀作業2

Q1.

本題算是有點鉆字眼了，在豆瓣中作者也做出了回復“平等在這個上下文，主要是指兩個人在面對具體工作的時候，是有平等的發言權的。 不會是資歷低的人只能聽從別人。”在當初我只是考慮到了一個隊伍中每個人能力是不同的，所以負責的任務量肯定有所不同，不可能是平等的，在這里不能用“平等”這個詞。而其實作者想表達的是發言權的平等，應該聯系上下文來理解這個“平等”。

Q2.

嚴格來說“各方面水平較高的那一位”是可以起到主導作用、并影響到程序質量的。比如我們團隊優秀的PM同學，在管理項目的同時也身兼客戶端開發一職。那么這個時候，保證了客戶端的質量也對服務器的開發有所監督，并對整個項目進度有很好的拿捏，從這個層面來說就很大程度上決定了項目的質量。

Q3.

這個學期我們就是結合敏捷開發來完成一個團隊項目的，大體來說對“敏捷開發”有了基本的認識，著實好好地體驗了一把hhh

Q4.

本題我好像已經完成了自問自答，就目前的理解來說，應該除了符合準則，有的方法論還有一定的流程，而我們本學期就是SCRUM的團隊開發模式。

Q5.

還有待解決=-=。

三、再提問題

大家一定會在實踐同時產生更多問題， 結合你的讀書（教材，博客，參考書）， 實踐， 再提出關于軟件工程的 5 個問題。

• 在每個問題后面，請說明哪一章節的什么內容引起了你的提問，提供一些上下文。
• 列出一些事例或資料，支持你的提問 。
• 說說你提問題的原因，你說因為自己的假設和書中的不同而提問，還是不懂書中的術語，還是對推理過程有疑問，還是書中的描述和你的經驗（直接經驗或間接經驗）矛盾？

一個模板可以是這樣：
我看了這一段文字 （引用文字），有這個問題 （提出問題）。 我查了資料，有這些說法（引用說法），根據我的實踐，我得到這些經驗（描述自己的經驗）。 但是我還是不太懂，我的困惑是（說明困惑）。【或者】我反對作者的觀點（提出作者的觀點，自己的觀點，以及理由）。

Q1.項目經理需要具備什么條件？

作者在書中寫道：

軟件團隊里除了能寫代碼、測試代碼和畫圖做設計的成員，還有一類角色，不做上面這些事情但也很重要，我們叫他們項目經理——PM。
--第9章 項目經理

從這里看，PM好像只需要管理領導就行了，但是我們團隊的PM卻基本是參與了項目的各個方面，真的很辛苦。那么我們對PM的分配是不是有誤解呢？除了會管理項目，PM還需要有什么能力呢？
一些任課老師也和我們說起過項目經理，表示項目經理各方面都要涉獵。我是比較贊同這個觀點的，如果一個人對項目中的每個環節都沒有做到基本的了解，是沒辦法很好地指導整個項目順利進行的。
但是如果只是涉獵各個領域，會不會出現隊員因為認為PM沒有自己精通這個領域所以沒有話語權無法信服的情況呢？

Q2.測試人員要多少個才能算合適？

這個問題是我在做項目的過程中想到的。
我和SZW同學是負責客戶端的部分的，本身開發過程就穿插著許多的測試，同樣的一個版本的拖動操作，他使用就沒有問題，但是我使用就有問題，原先我們以為是IDE問題，再找了別的隊友，發現這個bug的出現很“隨機”。深入研究發現如果拖動的位置是“彈簧”，這個bug就會觸發，因為大家的點擊習慣都有所不同，所以如果不是多人測試就不一定會發現。
至于Alpha沖刺最后的測試，我們的測試人員都表示“我測試不出來bug，你們一起使用以下找找bug”。這看起來好像我們的項目做的很完美，但是我總覺得不踏實，感覺有很多潛在的bug，需要多次甚至多人測試才能找到的那種。
所以我就很困惑，到底多少個測試人員才算合適。

Q3.怎么才能做到“完全測試”？

作者在書中提出了如下測試方法：

1 單元測試（Unit Test）
2 代碼覆蓋率測試（Code Coverage
Analysis）
3 構建驗證測試（Build Verification
Test，BVT）
4 驗收測試（Acceptance Test）
5 “探索式”的測試（Ad hoc Test）
6 回歸測試（Regression Test）
7 場景/集成/系統測試（Scenario/
Integration / System Test）
8 伙伴測試（Buddy Test）
9 效能測試（Performance Test）
10 壓力測試（Stress Test）
11 內部/外部公開測試（Alpha/Beta
Test）
12 易用性測試（Usability Test）
13 “小強”大掃蕩（Bug Bash）
--第13章 軟件測試

有這么多的測試方法，想要完整體系地把項目測試完需要完成以上所有測試嗎，還是取其一二？
或者說沒有真正意義上的“完全測試”，項目本身就是一直反饋修改反饋修改的過程，包括正式發布后的顧客反饋和版本更新？

Q4.Alpha階段的成果應該是什么樣的？

Alpha：指集成了主要功能的第一個試用版本。

十一周我們進行了一次復審，發現各個團隊的成果進度都有所不同。
比如有的團隊是完成了一個框架，本身功能性的算法還沒有實現；有的團隊似乎已經完成了所有任務。所以開始不明白Alpha階段呈現的成果應該是什么樣子的。
一定要發布出來嗎？是選擇界面完成而部分功能滯留到下一階段還是選擇功能相對功能完善了界面欠缺待改善？如果發布了一個平臺的客戶端，如PC端，手機端和網頁雖然是作為期望卻沒有在這個階段完成，算是未完成嗎?在Alpha階段將所有的任務都基本完成了導致Beta階段沒有什么事情做算是安排不當還是效率高呢？

Q5.一定要讀懂隊友的代碼嗎？

在團隊項目中，每個人都會有自己的任務，那么負責不同的模塊的隊友之間需不需要相互熟悉代碼呢？比如說我作為一個客戶端的開發者，需要對服務器的代碼了如指掌嗎，了解了似乎對代碼的融合有所幫助，但是會不會因此浪費了很多時間？還是說只需要接口商量清楚就可以了？

【附加題】

請將問題提交至豆瓣：https://book.douban.com/subject/27069503/， 并在博客中給出鏈接,在豆瓣頁面的最下方 “讀書筆記” 那里發言， 《構建之法》的作者會親自答復問題

我操作了一下，發現點擊寫筆記會出現之前的筆記內容，如下圖，害怕是覆蓋了之前的筆記，所以沒敢交QvQ：