软工网络15我的做业4——alpha阶段我的总结

时间 2019-12-12

标签网络我的 alpha 阶段总结栏目系统网络繁體版

原文原文链接

软工网络15我的做业4——alpha阶段我的总结

1、我的总结

用自我评价表：http://www.cnblogs.com/xinz/p/3852177.html 总结Alpha冲刺过程。html

因为直接用markdown生成的表格优势不太好看，因此用了截图+拼接
算法

2、回答问题

咱们在课程开始之初，曾经要求你们针对软件工程提出问题：我的阅读做业2，那么在通过alpha阶段，你们是否对软件工程有了必定的了解？请结合本身提出的问题进行回答。服务器

我的阅读做业2markdown

Q1.

本题算是有点钻字眼了，在豆瓣中做者也作出了回复“平等在这个上下文，主要是指两我的在面对具体工做的时候，是有平等的发言权的。 不会是资历低的人只能遵从别人。”在当初我只是考虑到了一个队伍中每一个人能力是不一样的，因此负责的任务量确定有所不一样，不多是平等的，在这里不能用“平等”这个词。而其实做者想表达的是发言权的平等，应该联系上下文来理解这个“平等”。

Q2.

严格来讲“各方面水平较高的那一位”是能够起到主导做用、并影响到程序质量的。好比咱们团队优秀的PM同窗，在管理项目的同时也身兼客户端开发一职。那么这个时候，保证了客户端的质量也对服务器的开发有所监督，并对整个项目进度有很好的拿捏，从这个层面来讲就很大程度上决定了项目的质量。

Q3.

这个学期咱们就是结合敏捷开发来完成一个团队项目的，大致来讲对“敏捷开发”有了基本的认识，着实好好地体验了一把hhh

Q4.

本题我好像已经完成了自问自答，就目前的理解来讲，应该除了符合准则，有的方法论还有必定的流程，而咱们本学期就是SCRUM的团队开发模式。

Q5.

还有待解决=-=。

3、再提问题

你们必定会在实践同时产生更多问题，结合你的读书（教材，博客，参考书），实践，再提出关于软件工程的 5 个问题。网络

在每一个问题后面，请说明哪一章节的什么内容引发了你的提问，提供一些上下文。
列出一些事例或资料，支持你的提问。
说说你提问题的缘由，你说由于本身的假设和书中的不一样而提问，仍是不懂书中的术语，仍是对推理过程有疑问，仍是书中的描述和你的经验（直接经验或间接经验）矛盾？框架

一个模板能够是这样：
我看了这一段文字（引用文字），有这个问题（提出问题）。我查了资料，有这些说法（引用说法），根据个人实践，我获得这些经验（描述本身的经验）。可是我仍是不太懂，个人困惑是（说明困惑）。【或者】我反对做者的观点（提出做者的观点，本身的观点，以及理由）。单元测试

Q1.项目经理须要具有什么条件？

做者在书中写道：测试

软件团队里除了能写代码、测试代码和画图作设计的成员，还有一类角色，不作上面这些事情但也很重要，咱们叫他们项目经理——PM。
--第9章项目经理ui

从这里看，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：