作业介绍
| 项目 | 内容 |
| 课程 | 软件工程(罗杰) |
| 作业要求 | 提问回顾与个人总结 |
| 本次作业要完成的目标 | 反思和总结 |
一、问题链接
二、问题解答
问题1 对于小概率使用的需求，究竟要不要做
我保持之前的看法，认为需求不能一概而论。安全上的问题是即使是小需求也有必要投入精力去完善和维护的，但是功能上的小需求如果只是小概率使用，那么就没有必要做。
经过这三轮迭代之后，我甚至更加认同之前的看法。比如安全问题，之前只是顺着书中的例子想到了人身安全，实际上作为一个程序，它很可能涉及到信息安全和财产安全等等，这些问题一样不容忽视。在课程的中期，就有小组反映他们的网站受到攻击，有的小组甚至数据都没法挽回，这些都是信息安全上需要考虑的，这类问题就算是小概率也是需要做的。但是比如功能上的小概率需求，除了延长开发周期之外，更有引入新bug的风险。作为功能上小概率使用的需求，它的重要程度一般来说不会高，因此这类功能在时间紧张的时候没必要做。
问题2 goto语句
我在项目中没有参加到编程中，因此仍然没法从实际的开发经验来评判goto到底该不该使用。但是从一个PM的角度来讲，在制定好合理的规范的前提下，任何方法都是可用的，反过来讲，没有合理的规范，即使是一般认为的好用的易维护的方法也是有各种缺陷的。
从这个角度回想以前老师的告诫，可能我们都忽略了我们作为刚开始学习的事实而只记住了“不要用goto”。由于没有一个足够好的代码习惯，加上课程都是交了过掉就万事大吉，因此当时用goto很可能会养成很差的代码习惯，与其以后碰壁了再改习惯不如代码规范做好了再考虑使用goto。
问题3 结对编程的好处
结对编程确实有实效意义。就我的结对编程的过程而言，虽然技术相近，但是人与人之间是有不同特点的，我在结对编程的过程中从同伴身上也学到了相当多的东西。而且结对编程一个最直观的效果就是，打开了电脑之后是真的在编程而不是编程两分钟休息两小时的摸鱼状态了。
问题4 结对编程的形式
确实应该坐在一起，正是因为坐在一起，才能够避免摸鱼提高效率，同时，两个人互换角色编程对代码的对接效率远远比两人分开编程使用git来的高，因此就该是书上描述的并排坐在一台电脑前的方式。关于分歧降低效率的问题，实际上交流就能解决，甚至，面对面交流解决这种问题的效率也要比用git或者在线上讨论的效率高得多。
问题5 用户体验
在我们的项目中，并没有遇到用户体验与质量冲突的情况，也没有遇到为了用户体验而牺牲用户体验的情况。在实际的过程中，更多的是没有预料到用户体验在某处的需求。在这种程度的用户体验的问题上，用户体验的问题是非常致命的，一旦有竞争对手在自己之前满足了自己没想到的用户体验问题，用户必然流失。而对产品的提升，不应当对用户体验造成影响。
三、新的问题
在实践中，我对转会仍有疑问，首先转会的目的是让我们体验工程中的这种过程和阶段，那么在工程中转会这种事情是否真的如同我们这个课程中这么普遍。其次，在课程中可能是我们组的项目(PC程序)与其他组的网页、小程序、app等差别较大，导致了转会时无人转入的情况，这对我们的人力资源造成了不小的打击，这种问题该如何解决。
四、学到的知识点
| 阶段 | 知识点 |
|---|---|
| 需求分析 | 站在用户的立场上进行考虑，只有详细具体的分析才能弄清楚用户要什么，我们做什么 |
| 设计阶段 | 设计要从多方面考虑，除了需求还要考虑难度、重要性等等，从这里就要为实现打好基础，眼光要长远 |
| 实现阶段 | 沟通和交流是实现需要的必要过程，积极的交流才方便解决问题 |
| 测试阶段 | 测试阶段必须要有章法有计划，按照计划测试的效率远远高于直接上手，想到什么测什么 |
| 发布阶段 | 将产品送到用户的手上，精准才能避免无用功 |
| 维护阶段 | 已发布的项目要时常收集用户反馈，根据反馈及时提升产品才能避免用户流失 |
五、理解与心得
在一个学期的课程中，我最印象深刻的就是占了大半时间的团队开发，作为停不下来队的PM，很荣幸能与同伴们完成我们的项目，通过这三轮迭代，我学到了很多的东西，体会到了在软件开发过程中不同于编程的另一方面的内容，心得大致总结如下：
- 与人合作，一定要多多交流，交流能够提升互相的理解，加快队伍的磨合，这样就能的达到1+1>2的效果。
- 好的规范和计划是团队重要的一部分，规范让成员容易与人配合，计划让团队成员迅速各司其职。
- PM的工作并不会比开发轻松，这个位置需要有长远的目光并且承担持续的压力，需要有整体的把控。