软工网络15个人作业4——alpha阶段个人总结
一、个人总结
自我评价
| 类型 | 具体技能和面试问题 | 现在的回答 | 毕业时找工作 |
|---|---|---|---|
| 语言 | 拿手的语言 | Java 4千左右 | |
| 软件实现 | 有没有在别人的代码基础上进行改进，你是怎么读懂别人的代码，你采取什么方法不影响原来的功能，遇到的bug是什么，怎么解决，bug出现的原因 | 1. 有，根据注释。 2. 在原有的基础上增加新的类。 3. 他的方法全都写在了一个类里。 4. 进行代码重构 5. 代码风格不一样 |
|
| 测试软件 | 你是怎么测试自己的代码，怎么测试别人的代码 | 通过编译软件自带的测试工具。 | |
| 需求分析 | 你做过多少个有实际用户的项目，用户人数多少，你的项目有什么创新之处 | 1. 1个 2. 10人左右 3. 使用微信平台，快捷方便 |
|
| 行业洞察力 | 你最感兴趣的领域是什么，这个领域过去十年有什么创新，你分析过这个领域前十的产品吗，请分析一下他们的优劣，你要进入这个领域，如何创新 | 1. 网络工程 2. 云计算 3. 桌面云，可以实现远程办公，还有很多云产品可以去创新。 |
|
| 项目管理 | 你参加过项目管理吗，如何决定各个任务的优先顺序，如果项目不能及时完成，你要怎么办 | 1. 参加软工项目管理 2. 根据一个项目的流程计划，首先实现主要功能。 3. 实现主要的MVP功能 |
|
| 团队协作 | 描述你在项目中如何说服同伴采取你更好的方案，或是听取别人的意见改进自己的方案，如何说服懒惰的同伴加紧工作 | 1. 首先说出每个人的想法，并且说明可实践性。进行比对，最好有3人及以上在场，这样可以更好的听取别人的建议 2. 将每个人的贡献和他说清楚，让他列好自己所做部分的计划，以及实现时间。定时跟踪他的进度。 |
|
| 理论素养 | 你上过什么数学，计算机或是理论课，举出具体的例子，如何帮你解决问题 | 1. 高数，c语言，JAVA 2. 数据结构，软件工程。 3. 例如：这次alpha阶段 1. 帮助实现编程的思路 2. 如何合理进行一项项目，各个部分该做什么。 3. 有一定的语言基础，方便我学习其他语言。 |
|
| 自我管理 | 全年级你专业排名多少？ 你从刚入学（大一年级）到现在的排名有变化么？ 如何解释你的排名的变化？ | 1. 大三上学期排第2 2. 跌宕起伏 3. 排名主要关系到综测。如果能积极参与活动，分数就会高一些。 |
二、回答问题
A1：
在Alpha阶段我们做的程序是单词app，起初的想法也是在市场原有的app的基础上去改善，也就是问题中所说的发展，所以这边我认为一个创新想要更好的被大众接受，那么节奏可以放慢一点，先在原有的基础上发展，逐步深入人心，逐步发展，最后形成的成果便是创新。
A2：
这个问题我已经表明了态度，无论是“创新”还是“科研”，主要看个人的目标，以及对社会的推动作用，没有必要用金钱去衡量。
A3:
这是在alpha阶段体会最深的部分，虽然不是结对编程而是团体战，但是在这其中并没有能力强弱的具体衡量，每个人都在做着贡献。可能擅长的区域不一样，但一个项目的完成仅仅靠编程能力强未必能够成功，他是要从各个方面来考量的。同时大家的讨论，每个人的参与度，都推动着这个项目向更好的方向。所以我认为只要不是打酱油的，合作的力量还是1+1>2的。
A4:
在我们合作期前并没有出现我设想的这种情形，“各持己见”说的有点武断了。真正合作是更多的是思想的碰撞和磨合，会去接受更好的意见。当然也有可能我们的5个人的团队，相比两个人意见相左更容易解决，大多是少数服从多数，或者是第三人将两者方法都能更好的融合。
A5:
这个问题提的还是有点大的，目前我还不知道如何回答。可能以后步入社会，经历了企业内部的具体流程，可能会有更好的体会心得。
A6:
这个问题我们在Alpha阶段的具体做法是：首先确定好自己要做的项目的大方向，然后在这个方向上，对我们的受众进行依次“调查问卷”的调查，了解这个项目的可行性以及可提高的部分，接受新颖可行的方案。最后在做好MVP功能后，发布体验版再来接受一次受众的建议。
三、再提问题
5章 团队和流程.
Q1:.
交响乐团模式 (Orchestra):
大家看过交响乐团的演奏。我觉得有下面一些特点:
· 家伙多, 门类齐全。
· 各司其职, 各自有专门场地，演奏期间无聊天走动随意交流等现象。
· 演奏都靠谱, 同时看指挥的。
· 演奏的都是练习过多次的曲目, 重在执行。
业余剧团模式 (Amateur Theater Team):
这样的团队在每一个项目（剧目）中, 不同的人会挑选不同的角色。在下一个剧目中, 这些人也许会换一个完全不同的角色类型。各人在团队中听从一个中央指挥（导演）的指导和安排。在学生实践项目或培训项目中, 这样的事情经常发生。
通过交响乐模式与其他的团队模式对比（主治医生模式，明星模式，特工模式等），我认为这是我认为比较中规中矩的模式。而业余剧团模式相对于看起来流动性较强，和目前我们软件工程的模式比较相像。这两个模式在公司中哪一种存活率高？
我认为大多公司都是交响乐模式，各司其职，发挥所长的多，但看文章中的描述业余剧团的竞争力会更强，根据“物竞天择，适者生存”的原理，在一个有竞争的环境企业才会走得很远。所以，目前来说IT企业更倾向于哪种模式？
Q2:.
在这次的alpha阶段，团队合作中老师不断的强调个人贡献排行。并且不准有并列。在一个合作模式中，必然每个人擅长的地方不一样，一个项目的完成每个阶段都必不可少，我想知道一定要排出个你多我少的意义在哪？如果说是加强竞争，防止打酱油的人出现。那么没有必要强调不准有并列。
在实际的企业中也会很注重个人贡献排行吗？
Q3:.
从瀑布模型开始的各种模型都有一个共同点：重计划，重事先设计，重文档表达。
RUP把软件开发的各个阶段整合在一个统一的框架里
四个阶段：
—初始阶段：此阶段的目标是分析软件系统大概的构成，系统与外部系统的边界在哪里，大致的成本和预算是多少，系统的风险主要来自哪里。
—细化阶段：它的目标是分析问题领域，建立健全的体系结构基础，编制项目计划，按优先级处理项目中的风险。
—构造阶段：开发出所有的功能集，并有秩序地把功能集成为经过各种测试验证过的产品。
—交付阶段：重点是确保软件能满足最终用户的实际需求。基于用户的反馈，团队利用迭代对系统进行修改、调整。除了对功能的调整，还要注意处理用户设置、安装和可用性等问题。
在开发初期定好了工程日期，做好了任务计划安排，写明的每个成员在不同的阶段要完成的任务。但在实践过程中和预想的不一致该如何解决？比如说，这次的alpha阶段。我们做好了团员分工，安排好了每个阶段。但是在开发过程中遇到了各种各样的问题。导致没有按计划进行。很多功能未能实现。在过程中老师也有给出建议说：功能略多，工程量偏大，可以先实现MVP功能。这也是不是说明初期的流程计划，是可以根据现实情况进行相应的修改？
8章 需求分析.
从理论的层面谈需求，往往都是一个隐含的假设——只有我们一个团队在做这个软件，仿佛用户不会去考虑和改用其他团队，因此我们可以按部就班的“引导、捉捕、分析”需求。但是这种情况在现实中是不存在的，同一类型的软件往往很多的团队都在开发。因此我们要遵循N（need 需求）、A（Approach 做法）、B（Benefit 好处）、C（Competitors 竞争）、D（Delivery 推广）的原则来开发软件。
Q4:.
在竞争性需求分析中，就我们开发的单词微信小程序来说，在市面上其实有很多背单词的App，他们作为独立的app，各种功能都非常完善。我们当时在竞争性需求分析中，其实是将微信小程序中的单词app作为竞争对手，因为通过查询，在微信平台上并没有功能很完善的背单词小程序。那如果将我们的产品提到更高的角度去看，我们如何可以和市面上哪些繁复多样的APP进行竞争？如果功能相似是不是就没有开发的必要？
15章 稳定和发布阶段.
Q5:.
说道“质量”，我们不得不提“全面质量管理”，因为大家都讲“全面质量管理”，往往以为这我们的质量没有抓到点子上。有人会举出世界著名公司为了“完美”而不惜推迟发布时间的例子，例如苹果公司的一些产品，著名的游戏：“永远的毁灭男爵”，等等......请问：iPhone的第一个版本是完美的吗？他连复制粘贴的功能都没有，但他还是发布了。那么从软件的代码完成（Code Complete）到最后发布，我们要经历那些步骤，有哪些招数能让我们能以比较大的共识、比较小的痛苦走完这段流程？需要什么样血型的团队才能按时推出优秀的软件？
软件发布的流程：
1：提交测试
开发人员经过自测（单元测试）在handoff通过后提交测试代码，测试人员通过自动发布工具部署测试环境（alpha）
2:预发布
测试人员在alpha环境测试并跟踪修改bug达到上线标准（没有A、B级bug,C级bug少于20%）时开始部署beta环境，有测试发起邮件发布流程。
3：验收测试
测试人员对现有功能在beta上进行验收测试（重新执行case）。紧急bug修改走补丁/merge流程。不影响功能的bug留到下次版本解决。确认达到上线。
4：正式上线
测试人员发起，通知相关部门人员配合发起上线操作（具体走发布流程邮件）。
测试人员在线上进行冒烟测试，（紧急bug修改走补丁/merge流程。不影响功能的bug留到下次版本解决）。通过后回复邮件，发布结束。
通过阅读这篇文章了解了任何一个上市的软件未必就是一个完美的毫无BUG的软件，哪怕是著名的公司。那么哪些BUG在发布后是可以被接受的呢？我上网查询了一下资料。
软件上线标准示例:
这只是一个例子。具体情况因项目不同而不同。
· 优先级为1的软件缺陷要100%关掉（严重性为严重且优先级为1）
· 90%的优先级为2的软件缺陷（严重性为高且优先级为2）要被修复。对剩余10%的缺陷必须有变通方案。并且对关掉剩余10%的缺陷要有一个可行计划。
· 生产环境部署清单以及可用性检查清单已经准备好。
· 生产环境支持团队已成立并准备好解决问题。
· 70%的优先级为3的缺陷被解决并且有一个取代计划来解决剩余30%的低优先级缺陷。
值得注意的几点:
· 所有严重性以及优先级定义是在项目开始时客户方和合同方在业务会议上决定的。
· 在所有UAT缺陷被记录并且所有其他缺陷被解决后，UAT协调人员和业务发起人碰头对未解决的缺陷进行评估。
通过书本和查询到的资料我认识到，如果这款产品能满足客户要求，在一定程度上便可以上线，然后对BUG进行优先级排列，可以根据后期的各个阶段去更新修复。
