软工网络15个人作业4——alpha阶段个人总结

软工网络15个人作业4——alpha阶段个人总结

一、个人总结

用自我评价表：http://www.cnblogs.com/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：