軟工網絡15我的做業4——alpha階段我的總結

軟工網絡15我的做業4——alpha階段我的總結

1、我的總結

用自我評價表：http://www.cnblogs.com/xinz/p/3852177.html 總結Alpha衝刺過程。

因爲直接用markdown生成的表格優勢不太好看，因此用了截圖+拼接

---

2、回答問題

咱們在課程開始之初，曾經要求你們針對軟件工程提出問題：我的閱讀做業2，那麼在通過alpha階段，你們是否對軟件工程有了必定的瞭解？請結合本身提出的問題進行回答。

我的閱讀做業2

Q1.

本題算是有點鑽字眼了，在豆瓣中做者也作出了回覆「平等在這個上下文，主要是指兩我的在面對具體工做的時候，是有平等的發言權的。 不會是資歷低的人只能遵從別人。」在當初我只是考慮到了一個隊伍中每一個人能力是不一樣的，因此負責的任務量確定有所不一樣，不多是平等的，在這裏不能用「平等」這個詞。而其實做者想表達的是發言權的平等，應該聯繫上下文來理解這個「平等」。

Q2.

嚴格來講「各方面水平較高的那一位」是能夠起到主導做用、並影響到程序質量的。好比咱們團隊優秀的PM同窗，在管理項目的同時也身兼客戶端開發一職。那麼這個時候，保證了客戶端的質量也對服務器的開發有所監督，並對整個項目進度有很好的拿捏，從這個層面來講就很大程度上決定了項目的質量。

Q3.

這個學期咱們就是結合敏捷開發來完成一個團隊項目的，大致來講對「敏捷開發」有了基本的認識，着實好好地體驗了一把hhh

Q4.

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

Q5.

還有待解決=-=。

---

3、再提問題

你們必定會在實踐同時產生更多問題， 結合你的讀書（教材，博客，參考書）， 實踐， 再提出關於軟件工程的 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：