软件工程提问回顾与个人总结

标签：项目   强制   解决   效果   测试方法   法规   时间   普通用户   hub   

提问回顾

问题博客链接

问题1

问题：

    结对编程有如下的好处：
    ......
    总之，如果运用得当，结对编程可以取得更高的投入产出比（Return of Investment）

这里的投入产出比很笼统。结对编程需要经历磨合阶段，在这个阶段中，就算实现约定了代码风格等诸多规范，但由于思维方式的不同、技术水平的差距、以及性格、行为动机上的种种差异，导致两个人在磨合阶段的投入十分巨大。这样的投入与结对编程相对于复审的优势相比如何权衡？

回答：

结对编程相对于代码复审有着更好的实时性和交流性。结对编程中两人分工不同，输入代码的人称作”驾驶员“，提出意见和审查代码的人称作”领航员“。在结对编程的过程中”领航员“主要起到对”驾驶员“的修正作用，在整个过程中时刻修正“驾驶员”的思路和方向；同时在许多关键细节的实现问题上，两人可以进行深入的交流沟通，通常能够比单人编程更快地得到解决方法。

代码复审要求复审人员首先通过代码理解编程人员的思路，这从最开始就降低了效率；并且审查出的不足之处需要进行重新修改、测试、再复审，这些繁琐的工作更加降低了代码复审的效率。

在课程的结对编程项目中，我与队友进行了深入的沟通，从而对核心算法、接口设计等方面打成了高度一致，使得我们在实际编写时进展迅速，取得了理想的效果。

问题2

问题：

    随着时间的推移，这几类功能也会发生变化，例如手机的多点触摸曾经是“惊喜”的功能，后来是所有厂家竞争的核心功能，再后来已经是最基本的功能了。

在书中讲到，项目的生存期是18个月。其次，项目开发需要一定的周期。在这个周期中，有的需求的性质可能会很快发生变化，而另一些需求在很长一段时间内不会改变。因此，在前期的需求分析工作中，是否应该将“惊喜”需求和核心功能向基础功能衰退的速度作为对需求考量的一个指标？

回答：

本次团队作业中，我们的开发周期较长，但实际上功能类型的变化周期更长。从我们对于需求分析的实际实现上来看，更多的还是从核心功能入手。在完善了核心功能后，我们列出了可选的开发功能并从功能的实用性、实现难度等方面进行考察并调研，最终确定开发哪些功能。

问题3

问题：

    我是做PM的料么？在校学生如何为成为PM做准备

看完这一章之后，让我感觉PM更需要各个方面的综合能力。一个优秀的PM固然在每一个方面都很强，然而这也很难做到。在经验和能力不足的情况下，作为大学生，是否应该从底层的技术开发岗位开始做起，还是说应该更早的开始锻炼PM的能力？

回答：

在团队编程的实践后，我更多地了解到了PM的定位与职责。我认为技术经验对于PM来说不是一个必选项，但拥有相关技术经验会给PM的项目管理工作带来巨大收益。PM的职责更多地在于需求分析、项目管理和产品质量管理等方面。PM可以不精通技术，甚至对技术仅仅达到了解的程度也可；然而一个对技术有深刻了解的PM对于团队分工与职责，以及项目进度和质量管理等方面有着更好的尺度，这对于团队管理是非常有利的。因此在校学生若想成为PM，可以先从简单的项目开始尝试，带领一个小团队开发项目，如果能够同时参与其中进行开发会更好。

问题4

问题：

    怎样才能定义典型用户呢？我们首先要定义用户的角色。正如戏剧中有正面和反面的角色，软件系统也有受欢迎的和不受欢迎的典型用户。如果用户有不同的安全需求，切记要定义不同的角色来适应这些需求。

我认为这一步非常重要。例如淘宝网当年的刷单现象，如果网站策划事先定义刷单者和刷单商家这样的典型用户形象，是否能够避免刷单现象的发生。推而广之，怎样更系统、更全面地定义典型用户，这个问题我认为很有价值。

回答：

定义典型用户要考虑各个方面。对于我们团队开发的项目而言，由于用户群体比较明显而目标群体并不多，也不涉及任何利益关系，因此基本只有老师、助教以及学生这三个角色。然而对于电商来说，会有各种需求的卖家和买家，以及从中攫取利益的人。在定义典型用户时会考虑到卖家的经营品类、买家的消费心理和消费水平等各种因素。虽然防止刷单行为更多地属于风险控制部分，但就区别刷单用户和普通用户这个方面来说，只有精确定义了典型用户和用户行为，才能够更有效的对用户类型加以区分。同时，刷单有时能够对电商本身带来利益，因此这更需要法律法规等更加强制的措施才能遏制刷单现象。

问题5

问题：

目前市面上很多软件充斥着广告，并且为了广告流量收入，广告常常被设计到最显眼的界面甚至诱导用户点击。这些广告的加入极大地降低了用户体验。这种做法又是否可取？

回答：

人是要恰饭的嘛。不过不合理的广告设计确实会极大地影响用户体验。因此就算是广告也需要精心设计，考虑广告内容以、广告投放位置和方式等因素。

知识点

需求阶段

学习了NABCD分析方法。并且由于是继承项目，我们采用竞争性分析方法，不仅将市面上的类似项目作为竞争对手，还分析了原项目的优劣。

设计阶段

设计要以需求为导向，有些看似技术难度高的功能可能实际上并没有相匹配的需求价值。首先定义典型用户，从而明确需要实现的功能，再对功能细节进行设计。

实现阶段

采用GitHub进行项目的版本管理，fir.im进行发布版本的管理。然而在团队开发方面没有做到版本的完全独立，这一点上还有很多值得学习的地方。

测试阶段

作为开发人员，主要进行单元测试。对于测试人员的集成测试、压力测试、真机测试过程和自动化测试方法仅停留于理论方面的了解。

发布阶段

发布阶段对于发布版本的选择；APP的发布有很多审核条件，对于应用市场的选择和发布渠道的选择会对产品的推广产生很大影响。

维护阶段

对于没有测试完善的bug和一些用户反馈的问题，做到及时响应。

心得

首先是结对项目。结对编程真的很需要两人的默契和不断磨合。这里的默契包含了太多方面，包括对于课程的重视程度、对于作业的态度等，这些因素会导致队友之间互相影响。结对编程优缺点都非常明显，使其适用的场景受到了很多限制。此外，时间也是一个很难协调的因素。总之，由于各种原因，在这一个较短的结对周期内，我们的结对项目在后期没有取得较好的效果。但不否认结对编程对于我们最初对项目的理解和配合起到了很大的促进作用。

其次是团队项目，我很幸运我能够加入现在的团队。我的所有队友们都很有热情，对自己的职责范围内的事情也从来没有任何推卸和延误。大家都很努力，PM对于项目、文档以及app发布自始至终都尽心尽力，各位开发和测试不仅有扎实的技术也认真负责。我们例会也很积极，每次在会上都有idea的碰撞和新想法的产生。虽然整体项目难度不算太大，最终我们也开发出了一个功能基本完善的app，甚至得到了博客园官方的一定认可，令我欣慰。

团队项目中也有不足，就我个人而言，在后期有些乏力，特别是在app的UI重构阶段我没有能够尽到更多职责。但我个人开发的页面的UI适配却是靠队友帮助完成，而我在此同时只是实现了几个小功能，比较惭愧。

另外，项目中注释和文档仍然不完善，这也是非常遗憾。我们最初接手项目时，由于不熟悉项目框架，也没有很详尽的文档说明，我们花了很多时间才对项目有所熟悉，甚至有些已经实现的接口和函数也被我们重新实现了一遍。回顾我们的开发过程，虽然加入了一定的注释，写了一些文档，但是这些注释和文档仍然没有形成体系，比较杂乱。

软件工程提问回顾与个人总结

标签：项目   强制   解决   效果   测试方法   法规   时间   普通用户   hub   

原文地址：https://www.cnblogs.com/swearitagain/p/11082167.html