提问回顾与个人总结

项目	内容
这个作业属于哪个课程	2021春季软件工程 （罗杰 任健）
这个作业的要求在哪里	提问回顾与个人总结
我在这个课程的目标是	提高软件开发能力，锻炼团队协作能力
这个作业在哪个具体方面帮助我实现目标	在经历实际开发过程后，回顾学期初的问题，给出答案，并对本学期的学习过程进行反思

回答问题

Q1 结对开发是否真的能提高效率？

有这样的疑问主要源于以下几个方面：

• 4.6 两人合作的不同阶段和技巧中提到萌芽阶段和磨合阶段：

  如果我们做的项目是真实的，有具体而多变的需求，有工期、质量和资源的矛盾，团队成员各自的水平、目标也不一致，那么团队内部不可能没有矛盾。

  每个人有不同的习惯、解决问题的方式，所以两人在许多细节的问题可能有不同的意见，这种时候产生的矛盾如何解决？如果都是听从水平较高的程序员，那与该程序员一个人完成有何区别？而且这个阶段耗费的时间是否都是有意义的时间？

• 结对开发需要经常交流，并且是有效的沟通，这就增大了社交的压力，增大了矛盾发生的可能性，尤其是对于不善言谈的人来说。并且在 6.1 敏捷开发的第三步提到

  一切交流只能通过Scrum大师来完成。这一措施较好地平衡了“交流”与“集中注意力”的矛盾。

  那是否说明在编程的时候专注于编程、交流的时候专注于交流才能取得更好的成果？结对开发中是否存在“交流”与“集中注意力”的矛盾？

• 4.5.2 中提到

  结对编程中，因为有随时的复审和交流，程序各方面的质量取决于一对程序员中各方面水平较高的一个。

  如果说结对开发对于水平较差的人来说能提高自己的水平，那对于那个水平较高的人有什么意义？

• 4.5.3 不间断的复审中提到

  每个人每天的高效率工作时段不超过3-4个小时。
  一对程序员完成预定任务之后，就可以休息，或者开展其他较轻松的工作，而不应该死板地按照工作日八小时的规定而继续编程。

  结对编程加剧了压力，长时间紧张工作，导致工作时段降低，再加上两人同时完成一个任务，是否耗费了更多的时间？

解答

在我们结对编程的实际过程中，我对以上几方面相关问题有了如下的理解：

• 我们在编程的过程中确实遇到了一些意见不同的时候，我们选择了一起讨论，直至一个人说服另一个人的方式，这个讨论的过程也是互相学习的过程，我们可以学习到对方一些好的编程习惯，也能了解到一种不同的思维方式，虽然耗费一些时间，但我并不认为这个时间是无意义的，这些收获都是独自编程无法体会到的。
• 因为我和我的队友比较熟悉，可以直接清楚地说出自己的意见，而不用过多考虑措辞等其他方面，所以相比于编程，社交方面增大的压力可以忽略不计。
• 我和队友的编程水平处于持平的状态，所以会听取双方的建议、从中择优，在这个过程中，我们都能有所收获。我认为，即使是水平高与水平低的人一起编程，也总会有一些收获。
• 如在第一点所述，虽然在讨论的过程中会耗费时间，但我并不认为这个时间的花费是毫无意义的，在这个时间里，我们收获了自己编程难以得到的体会，如不同思维方式间的碰撞等。

Q2 在设计中应该关注人数更多那类人群的使用体验还是兼顾多种人群的使用体验？

12.3 评价标准的第5条是适应各种类型的用户：

适应各种类型的用户
我们的软件要为新手和专家提供可定制化的设计。一些操作方式，如快捷操作，用户可以自行调整。我们还应该为存在某些障碍的用户（色弱、色盲、盲人、听力有缺陷的用户、操作键盘鼠标不方便的用户等）提供一定程度的便利。

如果要兼顾多种人群的使用体验和使用感受，则需要为软件设计更多的功能以适应不同人群的需求。但更多的功能会增大使用软件的认知阻力，且对于多数人群，一些功能可能是不必要的，甚至有些累赘的。
在12.1.2 从用户角度考虑问题也提到了

用户对那些选项对话框的种种选择会有更大的畏难情绪。

那我们在设计中应该关注人数更多那类人群的使用体验还是兼顾多种人群的使用体验？

解答

这个问题在我们团队开发的过程中已经得到了答案：
在设计的过程中，团队经过讨论定义了典型用户和典型场景，依据用户需求设计各种功能。在有一个新的想法后，我们会讨论这个需求是否属于典型用户、典型场景的需求，在一个产品中并不需要覆盖所有人群的需求，也不需要覆盖某一人群中所有人的需求，而应着重考虑该产品典型人群的需求。若是不加选择地增加功能，只会使产品功能变得冗余。近年来用户对于产品的选择也越来越倾向于简约轻量，所以有时在设计时比做“加法”更重要的是做“减法”。

Q3 是否需要为部分操作的表示用语制定行业标准？

12.3 评价标准的第4条 一致化和标准化中提到：

在软件中，对同一事物和同类操作的表示用语，各处要保持一致。例如，某词典软件有“帮助用户收集生词并且背诵生词“的功能。这个功能要有明确一致的称呼，不能混杂着叫”单词本“、”生词本“、”Word List“、”Word Book“、”单词文件“……等等。

在我对各种软件的使用体验中，影响用户体验的因素不只是某一软件操作的表示用语，更多的是不同软件对于同一操作的表示用语、同一功能的称呼各不相同，带来了一定的认知阻力，那是否需要为这些操作的表示用语制定行业标准？

解答

我认为这是非常需要的。我们在团队小程序的开发过程中，遇到的一个很大的问题就是用户觉得难用，而其中有一个重要因素是操作用语是用户不熟悉、不理解的。比如，通常情况下，我们习惯于将统计图的信息划分为横坐标、纵坐标，在表格中输入横纵坐标画出图像。但为了适应多种图表类型，在开发过程中，我们定义了数据组的数据结构，然后在表格中提示用户输入横坐标和数据组，而这显然是不符合用户认知的，用户并不知道数据组具体指什么，这就给用户使用增加了一定难度。
从这个例子中，我体会到了统一标准的操作用语的重要性，这会大幅度减小用户的使用阻力。除了统一的操作用语之外，统一的图标表示、页面布局等都会降低用户使用一个新产品遇到的的障碍.

Q4 专人负责和团队负责，哪个模式更有利于团队工作？

7.2.4 各司其职，对项目共同负责中提到：

团队的各个角色合起来，对整个项目最终的成功负责，为什么？因为每个角色在其职责范围内的失败都会导致整个项目的失败，而且各个角色的工作都是互相渗透、互相依赖的。这种互相依赖的方式也鼓励团队成员在自己本职之外为其他领域做贡献。

14.2.1 中提到：

所有人都可以参与QA的工作，但是最后要有一个角色对QA这件事负责。不但角色要独立，而且在最后软件发布时，必须得到此角色的签字保证。

每个人的工作相互渗透、相互依赖，但如果所有人都对项目最终成果负责，是否会导致责任推脱？如果最终有一个角色对成果负责又是否会造成其他人的懈怠？
专人负责和团队负责，哪个更有利于工作？

解答

在经过实际的团队协作后，我认为每个人都必须对项目负责，至少对自己完成的部分负责，最终可以根据项目不同部分的实现成果进行评估。但同时，团队也需要一个pm的角色分配任务、督促成员，把控项目整体质量。我们在Alpha阶段采取了pm轮值的方式，Beta阶段选出了一个人做pm，我认为后一种方式使团队效率更高、凝聚力也更强。

Q5 二维的完成任务维度、团队贡献维度的评价体系是否全面合理？

17.6 绩效管理中提到：

为了更客观地反映员工绩效的不同因素，有些公司实施过二维的评价体系：
完成任务维度：主要由团队成员和直接经理商量年度目标，直接经理有较大的自由度决定“超额完成/完成/未完成”的比例。
团队贡献维度：还是严格根据人员百分比，评出团队中最好的20%、中间的70%，以及最需要改进的10%。

首先，团队贡献维度很难量化，根据工作量计算，还是根据工作类型计算，还是根据工作时间计算，依旧难以找到一个合理公平的方式，没有解决根本问题。

17.6 中还提到一种情况：

一个心不在焉的程序员可以一天写2000行代码，然后测试人员和其他开发人员要花很多时间来修复其中的缺陷，这些同事原本要做的任务就被耽误了。

在这种情况下，也许这个人完成了自己的任务，也有不小的工作量，但所得到的结果却适得其反，给其他人造成了较大的工作量，这种情况下，又该如何量化？

解答

在团队实际的开发过程中，我们团队的任务得分由基本分和质量分构成，基本分根据任务难度以及需要花费时间得出，质量分由团队成员复审给出。我认识，这样的方式比较合理地评估了每个人的任务量，同时也解决了上面提到的需要修复缺陷的情况。但在大型项目中，对每个任务都进行难度判断、完成时间预判以及完成质量评价，可能会导致比较大的工作量。

新的问题

在小程序的开发过程中，由于团队只有五个人，在全员开发的过程中，很难再分出人做测试、pm、美工，在这种情况下，强行给一部分人安上测试、pm的角色是否反而会降低开发效率和工程质量？那是否这些角色的设置可以由每个团队按需配置？

知识点

需求

在需求分析阶段，主要应用了NABCD分析的方式。

Need部分的分析同时也是功能设计的依据，通过对用户需求的分析，我们大致确定了需要图表绘制、模板分享、分类管理等功能。Approach部分我们确定了以微信小程序的方式开发应用程序、实现产品功能 。Benefit部分我们确定了产品的优势，构思了一些杀手级功能。Competitor部分我们与市场上类似功能的产品做了比较，进一步确定了我们开发的方向。在Delivery部分我们设想了一些推广宣传产品的方式。这个分析的过程，也就是我们对功能进行初步设计的过程。

设计

在设计过程中，我们定义了典型场景、典型用户，从用户需求出发进行设计，在设计的过程中还需要考虑实现的方式及难度，合理分配时间和任务。

在设计过程中，还需要进行界面原型设计，初步绘制示意图，确定小程序的功能布局。最后，还需要后端进行数据库设计以及前后端接口设计。在设计阶段，我们都是采取一个人主要设计，其他人提出想法建议，一起讨论修改的方式，这样大大提高了会议的效率。

实现

在实现过程中，根据提前定义好的前后端接口、功能设计等，前后端同步开始实现，遇到问题在微信群以及会议中积极商讨解决。同时在实现过程中，为了能更好地协作，一些工具链的使用是必要的，如gitlab、共享文档等。

在实现过程中，团队成员间有效的沟通是非常有必要的，所有可能有歧义的地方都需要进一步确认，在对设计作出修改时需要通知到所有人，确保每个人的接口文档都是最新版，否则很有可能会导致做出“无用功”。

测试

测试是非常重要的一个阶段，也是保证软件工程质量的重要手段。除了单元测试外，还需要压力测试、场景测试等。与以往的课程有完整的输入输出定义进行开发不同，由于与不同用户进行交互，需要考虑到各个方法，如用户的错误输入、不同手机的版本问题等，只有进行了全面详尽的测试，才能保证用户的体验。

发布

在发布过程中，需要考虑到微信小程序的审核时间的问题。在发布时，需要考虑多种宣传方式，寻找目标人群，用海报的形式吸引用户眼球。同时需要建立用户群，积极收取用户意见。

维护

在维护阶段，需要充分听取用户反馈，修正用户遇到的bug。对于用户的一些针对功能以及外观方面的建议，需要在用户群体中进行调查问卷，听取更多人的意见，并在团队内进行商讨，最终决定是否进行修改以及如何进行修改。

个人总结

个人项目

在阅读了《构建之法》并且根据自己的理解写了三篇博客后，我对软件工程有了基于理论上的初步理解。在提问的同时，也进行了相关的思考。在案例分析作业中，我通过对软件的调研、分析、对比、评测，对开发软件有了一定的理解和想法，并在自己开发的过程中对于用户的实际体验有了更多的重视。

结对编程

在结对编程的过程中，起初思维方式以及编程习惯的不同，我们会产生一些分歧，然后针对这些问题进行讨论。但讨论的过程其实也是一个互相学习的过程，同时在讨论中，我们对题意也有了更细致的理解。总体来说，虽然结对编程相较于个人会多花费一些时间，但是在这些时间里，我们能学习到一些新的东西，而不是一直按照自己的习惯一成不变。

团队项目

在团队项目中，我们完成了绘制图表的小程序，在这个过程中，每位队友都付出了自己的努力，克服了许多开发过程中遇到的困难。我主要负责后端代码的开发，总体来说完善地完成了自己的任务，并且收获了许多开发经验。
团队协作中有效的沟通是非常重要的，我们在一次次会议中对遇到的问题逐一讨论、解决，充分听取每个人的意见，在经历需求、设计、实现、测试、发布、维护这些阶段后，顺利发布了符合预期的小程序，并且每个人都有自己的收获，我也实现了自己“提高软件开发能力，锻炼团队协作能力”的课程目标。
最后，感谢各位老师、助教、队友的辛勤付出！