软件技术基础第二次作业2020.11.2

• 2020 年 11 月 2 日
• 笔记

这个作业属于哪个课程｜//edu.cnblogs.com/campus/zjlg/rjjc20
这个作业的目标｜<阅读《构建之法》并提出三个问题>
姓名-学号｜<林效民>-<2018330301085>

    在略读《构建之法》后，我暂列以下几点。我看到了这一段文字，巴克斯顿说技能的反面是“Problem Solving” —— “解决问题”，这个听起来有点绕，我们看看IT人士熟悉的一个例子吧。一个IT专业的大学生来面试，简历上写“技能：精通Visual Studio C#编程”。于是面试官请他用Visual Studio IDE写一段程序。一个“不精通”的面试者的编程过程实际上就是一个“解决问题”的过程。
    这是关于“技能”的描述，在我查阅了资料，结合了自己的实践经验后，我觉得在实际学习和实践过程中，我们往往需要用到多门语言，在这个过程中，不得不同时进行着解决“底层次问题”和“中间层次的问题”，而所谓把所有“低层次问题”都解决了，再解决“较高层次的问题”的方法实施上存在许多问题。通过不断的练习，把那些低层次的问题都解决了，变成不用经过大脑的自动操作，然后才有时间和脑力来解决较高层次的问题。
    我还看到了这段文字。可以看出，这些团队有共同的特点：

•   团队有一致的集体目标，团队要一起完成这目标。一个团队的成员不一定要同时工作，例如接力赛跑。
  

•   团队成员有各自的分工，互相依赖合作，共同完成任务。
  

…
这是关于近十种模式确实形象地描述出了不同形态的团队合作模式。在我查阅了资料，结合了自己的实践经验后，我觉得在真正着手完成任务的时候，团队协作、管理与分工会遇到不少困难。就像因组员能力差异，分配任务很难做，最终每个人的完成情况差异也很大，甚至出现不得不由某些组员完成多个模块等等。关于团队管理者问题，团队中需要有一到两人对任务整体理解更透彻，来负责任务分配。但对组员的监督，任务过程种种问题的解决更应该是全员的任务。团队中任意两个组员之间的协作和监督无处不在才能使整个任务过程不变得支离破碎，此时管理者的作用反而不再那么重要。总的来说，团队协作不论哪种模式，总是会在任务的不同阶段出现或大或小的各种问题，这些问题有的能在早期的分析阶段提前避免，有的问题却几乎无法避免，我们只能在每一次的任务中吸取教训作为下一次参与项目的经验。
还有以下这段文字。一个软件或者服务要有人买就得找到顾客。顾客有各种需求，有些靠谱，有些不靠；有些容易做到，有些难以做到。软件团队要从需求分析开始，把合适的需求梳理出来，然后逐步展开后续工作。那么就有疑问，在开展项目之前的需求分析阶段，各种分析数据是软件团队自己去搜集还是团队从其他途径获取，如果软件要求很难，但一旦做出来会盈利不少，软件团队该如何选择。
在我看来，前期的需求分析是一个软件或服务的重要组成部分，如果需求分析不到位，那么做出来的软件或服务就可能没人使用，最终导致软件或服务的流产，浪费资源。但是前期的需求分析需要大量的数据，如果只让开发团队去搜集，就会耽误大量开发时间，所以如何快速高效准确分析成为重中之重。
企业的目的在于盈利，所以一般情况下都会选择做这个项目而不会考虑软件团队是否能完成这份工作，所以软件团队很多时候都无法自由的做出选择。并且这个选择有两面性，选择做，就意味着工作量大，虽然盈利但由此也会引发一些其他问题；选择不做，减轻了开发团队的负担，使开发人员不至于压力太大，但会损失提高开发能力的机会，所以如何选择要根据情况出发，做出正确的评估，评估开发团队的实力以及软件的程度。