软工读书笔记 week 7 ——《构建之法》

总时长近两周的结对项目终于算是结束了，马上要重新开启团队项目。于是这几天决定对《构建之法》一书中与团队项目及需求分析有关的章节进行重点阅读，希望能够从中得到启发，并运用到接下来的团队项目中去。

       团队模式

团队这一部分提到了软件团队的很多模式。我认为，就我们目前的团队项目而言，更合适的应该还是“交响乐团模式”和“功能团队模式”。

先说“交响乐团模式”（吐槽一下书上给交响乐团配的图真是错误百出，当然这不是重点，只是觉得应该还是要严谨一些），我自认对一个乐团还是非常了解，在一个乐团中，可能有数十种乐器，大家负责各自的部分，这也就是团队项目里的“分工”；但大家必须紧密配合，才能完成一个好的作品，这也就是所谓的“合作”；再就是大家需要严格遵守谱面上的内容，同时听从指挥的要求，指挥也要时刻注意乐团里各个声部的情况，并及时指出问题，这也就类似于一个团队项目中的“规则”以及“领导”。一个乐团演奏时，一定是遵循一定章法的，而我希望我们的团队也能够有一定的章法，只有这样，事情才能按照我们所希望的进行下去。

而“功能团队模式”更像是一个小组，当然我们这样也算是一个小组，没有管理和被管理的关系，小组内的成员平等协作、交流频繁，小组的目的就是去实现一个又一个的功能，这种方式对于我们学生的课程项目来说，应该也是适用的。

但是现在的问题是，我们目前的状况更像是前面提到的“一窝蜂模式”，由于我们团队是在安卓平台上开发app，不像网页端那样有比较明显的前端和后端界限，所以我们现在的分工就不是很明确，可能还是需要有相关开发经验的个人或团队来指导指导。

       需求分析

软件开发者要学会需求捕捉，有的需求是用户提出来的，这个肯定要考虑，但有时用户不知道自己确切的需求，这就需要软件开发者设身处地地去为用户着想。就像现在手机上很多功能，我们没用过时，并不能想象出来，但是一旦用过了，就会觉得确实好用。

书上提到获取需求的方法有很多，不过我们大多数组采取的都是其中一种——调查问卷，调查问卷可以在短时间内收到较多反馈，但有几点需要注意，一是问题的定义要明确，二是修饰的形容词副词尽可能恰当具体， 三是题目设计对用户友好一些，这些我们上次设计问卷时也都有考虑。还可以采取的比较好的像“卡片分类”、“日志研究”等方式，在做进一步需求分析时可以采用。

还有很重要一点就是对功能分类，以及功能的优先级排序。我们团队讨论时，更多是感性上的认识。书中提出了两种分类方法，一是分为“杀手功能”和“外围功能”，二是分为“必要需求”和“辅助需求”，软件的重点应该放在杀手功能和必要需求的交集上，力求做的独特、做到精。就我们的日记app而言，这一部分应该重点放在情绪的记录统计与查看上。

 开发时间

实际时间花费取决于估计时间以及做过类似开发工作的次数，这一点在之前的个人作业和结对作业中就很有体会，这些作业虽然都是采用c++编写，但是像结对作业这样的模式，还是第一次，缺乏经验，所以也花费了超出预期几倍的时间。

 分而治之

最后一点就是“分而治之”，要学会分解任务，但是子任务要做到不重叠并且全部覆盖父级功能，就是说每个子任务要是互斥的，但他们并起来应该等于我们所需要的全部功能，这个能让我们的进度更容易量化，是非常重要的。