设想和目标

 

1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？

 

解决”学霸“系统资料源的问题，我们会用爬虫爬取美国东海岸的学校计算机学院的网站以及问答网站（中文的为博问，英文的为stackoverflow），提供4万个网页。因为我们跟下一组pipeline的组商量讨论过，所以定义的十分清楚。我们整个七个组的典型用户就是寻找计算机问题答案的相关人员。典型场景就是一个用户想要寻找一个关于计算机问题的答案，但是怎么也找不到，这个时候他发现了XueBa，发现了一片新大陆。

 

2. 是否有充足的时间来做计划?

 

有，M1时我们就集体讨论过两次关于整个工程构架方面的。M2时，我们的计划整体不变，所以计划充足。

 

 

 

3. 团队在计划阶段是如何解决同事们对于计划的不同意见的？

 

在集体讨论中，每个人提出自己的看法，然后我们讨论每种看法的可行性。在这个过程中我们交换了意见，消除了异议。

 

 

 

 

 

计划

 

1. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?

 

都做完了。M2阶段我们主要是满足下载网页的数量需求，工作完成了。

 

 

 

2. 有没有发现你做了一些事后看来没必要或没多大价值的事?

 

花了不少时间做了个关于计算机科学的词典，结果送给其他组用了。

 

 

 

3. 是否每一项任务都有清楚定义和衡量的交付件?

 

部分任务有清楚的定义。有些任务因为我们也是第一次做，很难衡量能做到什么程度，对于这些任务没有清楚地定义。至于交付件，主要是通过改代码实现的。

 

 

4. 是否项目的整个过程都按照计划进行?

 

基本都是按照计划进行的，就是项目起始时进展慢于计划。俗话说万事开头难。后续的都是按照计划进行的。

 

 

 

5. 在计划中有没有留下缓冲区，缓冲区有作用么?

 

没有留下缓冲区，因为给我们的总体时间就比较少，又接近考期，又有很多大作业，没有多余时间用在缓冲区。缓冲区可以提高软件质量，比如在缓冲区DEBUG，进行充分的测试，保证项目准时保证质量的完成。

 

6. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）

 

接下来可能整个计划的节奏会加快。至于加班什么的，不太现实。我们也不可能把大部分精力都放在软工课上，平常别的课的考试压力、大作业压力也很大。

 

 

 

资源

 

1. 我们有足够的资源来完成各项任务么?

 

资源还是很充足的，老师提供了一个服务器，我们平时就可以在服务器上让它日夜的下网页了，还是很方便的。

 

2. 各项任务所需的时间和其他资源是如何估计的，精度如何?

 

估计主要看任务的难度和任务人的效率。精度还可以，基本+-20%内。

 

 

 

3. 用户测试的时间，人力和软件/硬件资源是否足够?

 

时间不充足，人力和软件/硬件资源还是足够的。

 

 

 

4. 你有没有感到你做的事情可以让别人来做（更有效率）?

 

 有的，每个人都有专攻，比如有些人文笔比我好，有些团队博客他来写会比我写效果好。

 

 

 

变更管理

 

1. 每个相关的员工都及时知道了变更的消息?

 

每次有最新消息，我都是第一时间群发邮件给组员的，我们还建立了一个QQ讨论群，以及定期也会集体讨论，所以每个人都知道变更信息的。

 

 

 

2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?

 

根据需求，需求大的就无法推迟。下一组同学要求的我们商量过的就必须实现。其他功能根据难易度和时间剩余情况决定优先级。

 

 

 

3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?

 

我们刚开始就是把网页存入本地文件夹，把条目信息存入数据库，很明确的。

 

 

 

4. 对于可能的变更是否能制定应急计划?

 

应急计划主要是如果某个人的进度没有赶上，会要求其他组员加入这个任务，帮助这个组员赶上进度。

 

 

 

5. 员工是否能够有效地处理意料之外的工作请求？

 

组员当然有些不情愿，但是这个是一个团队的要求，而且我们的评分计划也是差不多评分，所以这是每个人的责任与义务。如果大家在这个层面达成共识，工作请求就不是问题。

 

 

 

 

 

 

设计/实现

 

1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？

 

 在团队作业开始第一周的前半周设计的，有PM和大家讨论完成。合适的时间，合适的人。

 

 

 

2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？

 

有呀，有一些功能可做可不做，有一些解决方案多种多样，我们组内也有分歧，但是大家讨论完就可以解决出一个不错的方案。

 

 

 

3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？

 

这些用的比较少，因为时间比较短，我们是敏捷开发，文档什么的比如UML就不用画了，还有我们的功能也没有全面到画UML的程度。至于单元测试，肯定是做了的，每个人完成自己的任务时，提交前都测试了，然后提出自己的BUG。不过我们用了eclemma进行代码覆盖率测试，还是很有用的。

 

 

 

4. 什么功能产生的Bug最多，为什么？

 

当然是爬取是对于HTTP请求时BUG比较多。因为可能那个网页可能不接受请求或者不让我们下载，或者要我们先登录。不同的网站不同的页面都不一样，所以BUG比较多。

 

 

 

5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

 

 大家基本都懂代码规范的，虽然有些代码改的比较乱，但是注释还是有的。

 

 

 

 

 

测试/发布

 

1. 团队是否有一个测试计划？为什么没有？

 

测试计划还是有的，下网页的过程前就需要做很多测试。比如这个网页是否允许多线程下载等等。

 

 

 

2. 是否进行了正式的验收测试？

 

已经把下到的32万个网页提交给了下一组。

 

 

 

3. 团队是否有测试工具来帮助测试？

 

用的不多。因为我们是用JAVA写的，像VS提供的很多测试工具我们就没法用。我们用了eclemma进行代码覆盖率测试，还是很有用的。

 

 

 

4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？

 

软件效能为持续下载的网页个数。测试工作还是很有用的，可以发现不少异常。

 

 

 

5. 在发布的过程中发现了哪些意外问题？

 

完美发布，超额完成了老师要求的工作量。