提问回顾与个人总结
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2020春季计算机学院软件工程(罗杰 任健) |
| 这个作业的要求在哪里 | 提问回顾与个人总结 |
| 我在这个课程的目标是 | 提高自己的团队协作能力，体会软件的开发过程 |
| 这个作业在哪个具体方面帮助我实现目标 | 回顾之前提出的问题，对这学期的收获进行总结 |
一、链接到以前提问题的博客
二、请尝试对自己曾经提出的问题进行解答，并阐明，是如何通过看书，实践，或者讨论弄清楚的。
问题1
问题来自7.2.4 “各司其职，对项目共同负责”一节。
问：如果我要做一件事情，但是周围的人有不少不同意见，短时间又不能完全说服他们，怎么办？
答：对此事负责任的角色要自己拿主意。
在大家共同完成一个项目时，的确会发生一些意见不统一的情况，书中说负责人要自己拿主意。但是怎么才能让意见没被采纳的其他人不感到自己被无视了，或者避免在意见存在冲突时产生矛盾呢？
在实践中我的体会是，当我们的团队成员发生意见不统一的情况的时候，其实是可以通过沟通和协商，达成一致的意见的。如果实在有些时候需要有人做出让步，大家作为一个团队，其实也都是可以接受自己做出退让的。在提出这个问题的时候，可能我太担心团队合作中发生分歧了，其实这些都是很正常的，也非常感谢我的队友们，在这个和谐的氛围中进行团队合作让我很开心。
问题3
问题来自16.2 “创新的时机”一节。
很多大家正在使用的“新颖”产品，往往是经历了迷茫期之后的第二代产品，那些在泡沫最大的时候匆忙出现的第一代产品大多数都没有等到这一天。
如作者所说，获得成功的往往不是这个领域最初的开拓者，而是吸取了前人经验教训的后来之人。所以就是说不要在一个产业刚刚新兴的时候就匆忙加入吗？怎么才能把握时机呢？
我看了一篇关于快手和抖音竞争的文章。无论是先加入市场的快手，还是后来加入的抖音，这两款软件在内容、用户、运营方面，都有自己的特点。快手可以说是短视频领域的开拓者，现在依然有非常强的竞争力，主要是由于明确的商业策略。如果说抖音的风格是酷炫，那么快手的风格就是简朴，能够获得用户的共鸣和认同感。作为开拓者加入一个领域，虽然风险较大，但也可以做肥沃的土壤上最初的收获者。作为后来之人，尽管能吸取前人的教训，但也失去了一段时间的收益。无论在什么时候加入，最重要的都是有足够的实力和策略，应对竞争和变化。有些时候成功与否，看的就是一个时机，如何把握机会，需要经验积累出的头脑和眼光，或许也有几分运气的成分在吧。
问题4
问题来自3.2 “软件工程师的思维误区”一节。
这一节中提到了两种问题——“过早优化”和“过早扩大化”，它们一个是陷入了局部问题，一个是过于扩展，两者都会成为成功的阻力。既要不过分拘泥于细节的优化，但又不能太泛泛而谈一个大问题，怎样才能平衡局部和整体之间的关系呢？
在实践中我的体会是，一个成功的软件一定是兼顾了局部和整体的，但在每个阶段中，“优化”和“扩大化”的重要性不同。在Alpha阶段，我们实现了项目的最小可用版本，确保每个功能的基本使用。在Beta阶段，我们对功能进行了优化，目的是提升用户体验。在项目开发中，优化和扩大化是同步进行的，也需要根据用户需求进行调整，比如重点对用户需求较高的功能进行优化，延后扩展用户需求不是很高的功能。
问题5
问题来自3.3 “软件工程师的职业发展”一节。
这一节中讨论了“专和精的关系”，在学生时代，更应该侧重只钻研一门技术，还是每一项都做一些了解呢？在软件工程项目的各个职位中，哪些职位更偏重“作曲家写乐谱”型，需要对每种乐器都了解一些，哪些职位更偏重“演奏家演奏乐器”型，需要只精通一种乐器呢？
在实践中我的体会是，在项目前期更偏重“作曲家写乐谱”型，需要对整个项目大致都有一个了解，选择适合自己的岗位。在进入开发的节奏后，就更偏重“演奏家演奏乐器”型，需要在自己的岗位上做到精通。总体来说，我认为在职场环境中，精通比全能更重要，因为在一个大型项目中，每个人所做的工作是相对固定的一个位置，通过经验的积累和钻研，让自己在这个位置上成为不可替代的人，而不是无论在哪个岗位上工作都是可有可无的角色，随时可以被替换。
三、是否原来的问题还不明白？如果有，请分析。
问题2
问题来自9.3 “PM做开发和测试之外的所有事情”一节。
是由一个松散的集体通过不断改进产品来取得成功，或者由某个有远见的个人主导？......牛人主导的项目，往往会大起大落；PM主导的产品中，“不犯大错”成了一个特点，微软的很多产品在长期的竞争中，靠“不犯大错”，从第三版开始，赶上并超越对手。这也是了不起的能力。问题是，在新的商业模式下，用户是否能耐心地等待第三版？
大起大落的风险较大，但“富贵险中求”，可能短期内会有很大的收益。走“不犯大错”的路线，可能需要较长时间的竞争才能体现出优势。在现在的商业模式中，是“大起大落”更好，还是“不犯大错”更好呢？
这个问题我还不能够给出自己的解答，目前还比较缺少对商业模式的实践和理解，没有直观的感受。仅从个人偏好而言，我比较喜欢PM主导的产品，通过不断改进来取得成功的方式。
四、是否产生了新的问题？如果有，请提出。
如何确定团队成员的分工？在我们的团队项目中，成员的分工主要是大家自愿选择的，但在今后进入职场工作中，是否给团队成员留有选择的余地较小？作为团队的领导者如何做好任务的分配，尽可能发挥出每个成员的特长呢？
五、软件工程这门学问有很多 “知识点”， 这门课强调 “做中学” - 在实践中学习知识点。
请问你们在项目的 需求/设计/实现/测试/发布/维护阶段（一共6个阶段）中都学到了什么“知识点”，每个阶段只要说明一个知识点即可。
- 在需求阶段，使用NABCD分析方法，对需求、方法、好处、竞争者和发布进行分析。需求不只是在功能上的需求，也包括对产品开发过程的需求，例如文档、代码规范等，还有非功能性的需求和综合需求。在我们的项目初期，可能更关注了功能需求，而对产品开发过程的需求有些不够重视，我们渐渐意识到了这项需求也是非常重要的。
- 在设计阶段，使用WBS进行任务拆解，将大型的任务分解为小型而具体的交付件。
- 在实现阶段，使用GitHub进行项目管理，规范issue和commit，commit信息这些看似容易被忽略的细节，实际上是一个项目规范性的体现。
- 在测试阶段，需要进行场景测试，将各个模块综合起来作为一个整体，考虑用户在现实环境中使用软件的流程，模拟这个流程进行测试。
- 在发布阶段，需要开一个事后总结会议，总结这个阶段的工作，反思在哪些地方可以做得更好，有哪些地方是之前没有想到的。其实很多时候重要的不是完成任务的结果，而是在完成任务后的反思和复盘。
- 在维护阶段，需要广泛地收集用户反馈，根据用户反馈修复bug。
结合自己在个人项目/结对编程/团队项目的经历，谈谈自己的理解或心得。
在个人项目中，我对单元测试有了基本的了解，之前可能不太明白单元测试的作用是什么，后来渐渐懂了，在方法层面的测试是项目稳定的基石。
在结对项目中，我和队友的沟通合作是比较顺利的，这次合作留给我们的磨合和适应时间很短，我们能够快速进入结对编程的节奏，相互促进。而且比起一个人编程，两个人更能拓展思维，遇到自己一个人难以解决的问题，可以在彼此的帮助下更快解决。
在团队项目中，我明白了有效的沟通是团队工作效率的保障。我们几乎每天都会开一次例会，分享项目的进展，共同解决遇到的问题，这种沟通和交流使得我们的项目进展一直处在稳定前进的状态。在项目中期，我们团队也经历了人员的变动，在老陈最后一次和我们一起开会的时候，其实我有点难过，只能想着聚散离合也是人间常态，面对突发的变动，尽快去调整和适应，也是能力的一种体现。所以在后来我们的新成员加入的时候，我们也想要尽快帮助她融入我们，在配置环境和技术学习方面，大家都比较热情地提供了帮助。这学期我从团队项目中收获了很多，不仅是软件工程方面的理论和实践知识，也让我思考了团队合作的模式，以及在团队合作中如何做好自己的角色。
