[I.3] 个人作业：结课总结

21373254-肖灿 2024-06-30 22:51:35

项目	内容
这个作业属于那个课程	软件工程
这个作业的要求在哪里	第三次个人作业
我在这个课程的目标是	获得软件工程方面的知识，提高自己的编程能力，团队协作能力。开发一款令自己满意的软件。
这个作业在哪个具体方面帮助我实现目标	梳理一下自己整个软工课程学习过程中的收获，通过反思达到更好的学习效果

我的问题

之前的问题看到这一篇博客
下面是我现在对于这些问题的理解：

问题1：关于两人合作的一点疑问

在结对编程与两人合作一文中，邹欣老师提到了许多两个人之间磨合的策略与路线。
但有一点没有覆盖到，我也很疑惑，关于两个人合作的时候，我时常会有一种心态，就是感觉我应该提一种要求，但是也提多了也会感觉有一种“负罪感”，这也属于是磨合的过程吗。有什么办法克服这种心理。

现在大致没有这个疑惑了，因为轻身体会过后，我发现这种心态是确实是处于一种磨合的心态。但俩人有默契之后不会为提要求这种事情而烦恼，要把心态调整为"两个人一起解决问题，而不是一个人解决问题。"所以，就算是提出要求，也只需要把它当成是一种解决问题的提案，而不是一种指令，两个人合理的进行讨论，"负罪感"就不太会存在。
还有一个亲身体会就是：结对编程的队友也是我之前数据库大作业的唯一一个队友，对比了一下两次的合作，我才发现上一次确实是在磨合，这一次就很顺利，因为我们之间的默契已经建立起来了。

问题2：对Scrum的灵活性的疑问

在Scrum/Sprint一文中，提到了Scrum在实践中可能会遇上的问题，可能会流于形式。但想Scrum如果严格执行为每天的会议，很容易会导致这个问题，因为有的时候，这几天的任务可能就是很重需求就是很模糊，大家可能根本也就干不出来什么东西。这个时候每天的会议不仅仅会流于形式，而且会破坏士气。
我认为Scrum Meeting的开展周期可以分阶段开展，而不是按照时间开展。

这个我在实际的开发过程中进行了一下探索，我认为Scrum Meeting有两种职能，一种是"催进度"，另一种是"整理进度展望未来"，所以我认为Scrum Meeting也完全可以分为两种：
- 一种是集体赶工的集中开发，这种就不需要大家挨个汇报，而是大家分为了几个前后端对接的功能小组，每组集中开发（有点像结对编程），然后PM全程跟踪，这种情况下，进度得以保证。而且在大家都挺忙的大背景下，这种分组开发的方式也有利于增加灵活性。
- 第二种是每到有一个新的点子或者功能被提出来的时候，或者取得了比较大的进展的时候，再召开一个Scrum Meeting，这个时候就是大家汇报一下自己的进度，然后大家一起讨论一下接下来的工作，这个时候就是"整理进度展望未来"的时候了。这种情况下，大家的士气也会得到保证，而且也能够保证项目的进度。

问题3：PM spec的具体实践看法

在邹欣老师的讲义设计阶段Spec中，提到了两个写spec的例子，一个是外星人系鞋带，一个是三峡的防水等级。两个例子都是非常具体的和有趣的。同时还提到了spec最大的两个问题是乏味和时间。但是文中并没有提到如何有效解决这两个问题。

我认为，spec作为对接用户与实现者之间需求的桥梁，实践中很重要的一点是让用户和实现者参与到spec的编写中来。在后续更新spec时，好好设计实现过程中的选择问题与创造性问题，让用户来回答。可以有效克服时效性问题。在编写spec时，让程序员参与审计与编写，同时适当让他们看到用户的原始需求的数据，把spec从指令变成一种讨论，可以有效克服乏味问题。同时避免了PM或者是spec编写者的个人主观意识对spec的影响。
这是我个人对于spec实践的一点看法，虽然会增加一些沟通成本，但是我认为这是值得的。对于这一点，也需要在实践中不断的调整。
- 比方说我们团队的软工实践项目，其实在这一点上是吃亏的，设计的环节缺乏用户参与，也缺乏程序员的审计，导致了后续的开发过程中出现了很多问题。这也是我在这一点上的一个反思。

问题4：用户需求问卷设计的看法

我在其他活动中接触过社科类的同学怎么设计一个问卷，当时了解到的一个方法很有用处。
讲义中提到引导性倾向是一个很大的问题。问卷有一个很大的问题就是区分有效的问卷和无效的问卷，所以有的时候设计一些带有明显倾向的傻瓜题，可以有效的区分有效的问卷和无效的问卷。
问题定义不准确这也是文中提到的一个问题。但我认为这是一个需要折中的问题，太明确的是or不是问题，可能会导致用户的回答不准确，但加入一个没有关心过的选项，则能够有效的区分用户的需求。

这个问题我在实际的开发过程中也有一些体会，我们最开始的问卷设计就遵循了这一原则，最大程度上的给予用户能够用最少的时间给出最大的信息量的原则。我觉的可能需要考虑如下几点：
- 问卷的设计：第一得简洁，让用户扫两眼就知道该点哪；第二得有趣，让用户弄够做下去。
- 问卷的宣发：第一得渠道广，第二得宣发得足够吸引人。
- 问卷的分析：第一得关注傻瓜题筛选，第二得关注用户的回答是否有逻辑性。
其实稍微一想，软件的设计发布和收集反馈的过程，和问卷设计的过程是有很多相似之处的。

问题5：关于典型用户和典型场景以及用户界面设计的一点想法

在用户界面设计一文中，提到了你姥姥的遥控器的例子，在前面也讲到过典型用户和典型场景的概念。
我认为实际应用中，典型用户可能可以分为几类，这个时候，我们或许需要给前端界面做一些可选项（而且是很容易找到的可选项）。就比如姥姥的遥控器可能需要一个大字体的显示，但是对于年轻人来说，功能丰富一点可能更好。这个时候，我们可以在界面上加一个“老年模式”和“年轻模式”的切换按钮，这样可以有效的解决典型用户的问题。
当然，遥控器这么做会很麻烦，但是在软件界面上，这是一个很好的解决方案。