祝贺同学们完成了第一个里程碑 M1. 经过报告/评论/Postmortem, 大家对各自项目在M1 的优缺点都应该有很深的了解, 也理解到做一个好的软件和实现一个算法的差别。请把这些对于软件工程的感悟体现在M2 的具体工作结果中。
关于转会 - 软件工程师换工作是常有的事，优秀的软件工程师都会留下足够的文档, 到哪里都能高效工作, 我相信经历了转会的工程师会以更高的热情投入到新的工作中。
M2 阶段的要求:
主要目标是要把M1 计划的功能进一步做好, 不贪多，必要时可以削减功能。
要用测试用例，单元测试，代码覆盖率，自动测试等工具和标准来保证软件模块的质量。最后会重点考察各项目测试的代码覆盖率。请测试的同学加把劲，如何保证你项目的60% 以上的代码都验证过? 都被测试用例覆盖了?
要有每日构建，每天都应该把代码集成进TFS, 并能够编译成功。
用真实世界的数据和用户来衡量软件的质量。 我们写软件是为用户写, 请考虑在适当时候请用户来试用软件, 收集用户反馈。
爬虫组: 每个小组搞定至少 4 万个英文文档; 5千个中文文档。 两个小组可以分工 (东西海岸, 不同文档类型等) , 文档处理要满足 Pipeline 组的要求。
数据Pipeline 组: 处理爬虫组的文档，并生成符合 UI 组要求的数据库。 (关键字, 问答对)。
UI 组: 基本UI 要流畅好用, 使用场景完备。 搜索要快速，并能处理中英关键字的搜索, 用户的管理, anti-spam, anti-abuse 要达到实用的标准。 要能满足 效能测试/负载测试/压力测试的要求。
AbsoluteDefense, iLifer, 背单词小组: 不要过于强调自己的技术有多麽先进, 把软件做到满足典型用户的要求, 让用户喜欢你们的软件, 是最重要的。同时要尊重知识产权
所有的工作都写成了 TFS 的任务加入 TFS 中, 并有任务时间的估计, 所有的成员的任务都要写在里面
和M1 类似, Daily Scrum 的 blog 打分细则如下:
连续10天, 只要求 10 天, 从11/27日开始到12/10，各团队自己决定周末是否计入. 有特殊要求的请和老师说明。
当天没有博客, 则得 负5分。事后补交 (日期不对) 得 0 分。
有博客, 并有每人工作记录, 包括工作的任务号 (work item ID), 则加五分。
没有ID 的例子: http://www.cnblogs.com/76er/archive/2012/10/30/2747245.html
有ID 的例子: http://www.cnblogs.com/fightingsnail/archive/2012/11/08/2761664.html
博客有TFS remaining work 报表, 或自己做的 Burn down 报表, 加五分。
例子: http://www.cnblogs.com/fightingsnail/archive/2012/10/31/2747290.html
博客如果有其它优缺点, 则可酌情加减分数 (1~5 分) 。
例如: 有代码测试覆盖的报告, 有测试用例的报告, 或者有最新程序运行的截屏, 等。
每天最高 12 分。 最低 -5 分。
用户测试报告: 在10天的冲刺完成后, 在适当的时机 (一两天后) 请项目的目标用户来试用软件, 记录用户反馈, 并写报告, 报告要有用户使用你们软件的照片。
要点: 不要先告诉用户操作细节, 而是告诉用户一个目标 (例如想找有关 机器学习的资料), 让用户自己试着摸索。 反复几次, 收集反馈, 并思考如何改进。 所有小组都要做。 crawler 和 pipeline 小组要找其他开发人员 (假设他们以后要维护这个网站, 并且要处理更多文档) 来做用户调查。 请看移山之道或其它教材/资料关于用户调查/user study 的做法。
现在就可以考虑软件要如何发布, 最后项目评审的时候要拿出实际用户的数据, 所以要求你们的软件要在实际世界中运行了一段时间。
所有软件的发布日期都是 (12/17 中午)。 如果软件在发布之后有新版本,可以多次发布，但是12/17 号必须有第一次发布。
每个项目预期发布20 天 (1/7 中午) 之后的下载用户数量, 或者活跃用户数量。 各个项目可以自己找渠道推广各自的软件/网站.
要求所有项目都要在下列的网站发个帖子, 做宣传:
http://www.newsmth.net/nForum/#!board/NewSoftware
请把截屏和用户的反馈加入到报告中。
1/7/2013 进行最终项目终审。要求在这里:
http://www.cnblogs.com/xinz/archive/2012/12/26/2833855.html
