教师本想偷懒一下，奈何有人催逼前行啊。
谢谢冉华同学迅速更新。
0. 重要 预习要求
0.1 学习scrum案例
[http://www.cnblogs.com/Chronos/p/5030912.html]
[http://www.cnblogs.com/bugphobia/p/5047025.html]
0.2 预习 四象限
0.3 学习 [https://en.wikipedia.org/wiki/Minimum_viable_product]
选择一个功能，先写出可执行的代码。
部分作业截止
到截止期3月24日24:00，收到作业及站立会议报告34份。
请继续提交每日站立会议报告，本周要求5个工作日。
请往下面看，作业缺项的同学注意 你需要一份 check list，本周要交的作业内容。
互评
请各位同学开始互评吧，不然到周五上课前，工作量巨大。
抢跑项目
选做加分项 在此贴下回复认领此项目，限前3位同学。3位同学分别做3个不同的版本。
吴军同学、齐嘉亮同学 认领完毕，还剩2个名额。
如果别人做完的自己就不用再做一次了，就少了一次进步的机会。实验和学习的目的，最主要的不是达成结果，而是过程。
把 [http://www.cnblogs.com/xinz/p/3852177.html] 的量表做成APP或网上调查问卷，并发布在微信朋友圈中。
可以借用现有调查问卷系统，自动核算得分，注意版本引用和致谢，注意排版美观。
齐嘉亮同学的样例 [http://www.sojump.com/m/7505837.aspx?from=groupmessage&isappinstalled=0]，正在讨论选项的分值。
吴军同学的样例 [http://www.sojump.com/m/7505121.aspx?from=timeline&isappinstalled=0]。
4人小组
-
耐撕团队: 郑蕊组长，齐嘉亮，刘伟硕，濮成林，将完成抢答器。
-
OneZero团队: 夏一鸣组长，王巍，冉华，张敏，将完成记账本。
-
fantacy团队: 杨若鹏组长，郭又铭，臧润强，何美琪，将完成词频扩展。
-
爆打团队: 严一格组长，包玲玲，吴军，彭杨，将完成四则运算扩展。
每日站立会议
批评 21日，第一个工作日 以下团队未提交每天都应提交的站立会议更新: 耐撕团队、fantacy团队、暴打团队。
表扬 OneZero团队及时提交。
1. 作业点评
1.1 冉华 [http://www.cnblogs.com/ranh941/p/5291504.html]
词频统计 及 PSP。
由程序员成长为工程师的途中。
1.2 夏一鸣 [http://www.cnblogs.com/xiaym896/p/5294329.html]
scrum的总结，非常精准。请各位同学前去围观。
1.3 夏一鸣 [http://www.cnblogs.com/xiaym896/p/5293887.html]
与王巍的结对编程体会，值得一读。三周已过，我发现值得一读、值得一批、值得讨论的技术博客多起来了。祝贺各位的进步。
1.4 夏一鸣 [http://www.cnblogs.com/xiaym896/p/5299256.html]
OneZero团队非正式站立会议。持续1小时，讨论需求、边界。三人参加，一个事后参与讨论。
OneZero团队的计划产品是 记账软件。
1.5 张敏 [http://www.cnblogs.com/zhangminss/p/5300136.html]
OneZero团队启动 报告。要点清晰。
1.6 郭又铭 [http://www.cnblogs.com/guoyouming/p/5300220.html]
个人能力提升训练；
fantacy团队 词频扩展 需求讨论。
1.7 郭又铭 [http://www.cnblogs.com/guoyouming/p/5300315.html]
词频扩展 的UI原型
1.8 王巍 [http://www.cnblogs.com/shirlywangwei/p/5301682.html]
结对体会。PSP，进度条。
1.9 夏一鸣 [http://www.cnblogs.com/xiaym896/p/5301526.html]
OneZero第一次站立会议报告。可圈可点，下了功夫。
1.10 张敏 [http://www.cnblogs.com/zhangminss/p/5305748.html]
OneZero团队的站立会议刷屏中。
1.11 张敏 [http://www.cnblogs.com/zhangminss/p/5305892.html]
The Return of the Queen.
1.12 刘伟硕 [http://www.cnblogs.com/WeSure6/p/5306397.html]
耐撕团队21日站立会议报告，22日更新。
团队中一人病倒，一个病着站立，但是团队还在。
高风险问题都已开始讨论，内容专业，值得细读。
1.13 夏一鸣 [http://www.cnblogs.com/xiaym896/p/5306582.html]
OneZero 3月22日站立会议。注意到控制时间，并且控制得不错（似乎受到教师的启发以前就注意到了）。
高风险问题都已开始讨论。
1.14 濮成林 [http://www.cnblogs.com/charliePU/p/5307039.html]
词频需求等开始更新，结对体会颇深。
1.15 濮成林 [http://www.cnblogs.com/charliePU/p/5307620.html]
原创git安装教程。
总结经验教训，记笔记发博客（因此以后自己也容易找到），是以后提高的不二法门。
此文堪为典范，可以炫耀。
1.16 严一格 [http://www.cnblogs.com/yyyyg/p/5308384.html]
爆打团队站立会议，开始 四则运算扩展需求。
四则运算完全可能有巨大~~的下载量，加油 !
1.17 濮成林 [http://www.cnblogs.com/charliePU/p/5308510.html]
耐撕团队3月22日站立会议。
两位成员病倒，团队未倒。
UI原型值得一观。
1.18 包玲玲 [http://www.cnblogs.com/linglingbao/p/5308665.html]
结对，4个项目，PSP。
站立会议的独立报告，很好。对于同一个会议，大家会有不同的观点和角度。
如果别人做完的自己就不用再做一次了，就少了一次进步的机会。
1.19 刘伟硕 [http://www.cnblogs.com/WeSure6/p/5309062.html]
结对，词频。赞刘伟硕和濮成林对结对的独立报道，都可圈可点。
1.20 郭又铭 [http://www.cnblogs.com/guoyouming/p/5309096.html]
Fantacy团队第一次站立会议，22日。赞在组长之外独立思考和报道。
请各位同学去围观我的点评，并回复各位的点评。对于“好”“学习了”跟“顶”一样没有营养，不算点评。
1.21 杨若鹏 [http://www.cnblogs.com/robinYangRP/p/5309109.html]
Fantacy团队第一次站立会议，22日。
请各位同学去围观我的点评，并回复各位的点评。
1.22 郭又铭 [http://www.cnblogs.com/guoyouming/p/5309232.html]
结对编程体会，对结对的负面评价。
1.23 夏一鸣 [http://www.cnblogs.com/xiaym896/p/5310794.html]
读“软工实践总结作业”有感。这是杨贵福明确各位同学文字谈感想的作业，你完成的如何？
1.24 夏一鸣 [http://www.cnblogs.com/xiaym896/p/5311784.html]
OneZero第三次站立会议（2016.3.23）。在继续需求，建议开始编程。各位同学的评论很积极。
1.25 彭杨 [http://www.cnblogs.com/pengy813/p/5312417.html]
结对编程体会不错。4人小组项目词频的需求和技术讨论。
1.26 彭杨 [http://www.cnblogs.com/pengy813/p/5312426.html]
KNN算法，聚类。技术积累。
1.27 吴军 [http://www.cnblogs.com/wujunzero/p/5312557.html]
爆打团队站立会议。选择了SCRUM工具。请立即开始编程。
1.28 郑蕊 [http://www.cnblogs.com/zhengrui0452/p/5312911.html]
开始第三周作业。快速迭代，先占位置，是正确策略。
1.29 刘伟硕 [http://www.cnblogs.com/WeSure6/p/5313120.html]
”耐撕“团队 2016.3.23 站立会议。恢复为三名成员，郑蕊参加站立会议，齐嘉亮倒了。
1.30 夏一鸣 [http://www.cnblogs.com/xiaym896/p/5313251.html]
漫长的PSP。
只要不病倒，持续努力。把玩的时间用来编程和进步。在我看来，这只是此前多少年逍遥自在的补课。我也是这样的，我还在补大一的离散数学和高中落下的英语。加油 !
夏一鸣 加油，赞努力。我用十多年追赶，欢迎你加入。
1.31 臧润强 [http://www.cnblogs.com/zangrunqiang/p/5313385.html]
结对，站立会议。虽然具体内容和感想还没有写，但是大纲已经有了。
1.32 严一格 [http://www.cnblogs.com/yyyyg/p/5313405.html]
作业大纲 及 PSP。
1.33 郭又铭 [http://www.cnblogs.com/guoyouming/p/5313526.html]
第一位回应NABCD模型的同学，有心人。请各位参见下文的3.4节。
1.34 郭又铭 [http://www.cnblogs.com/guoyouming/p/5313776.html]
PSP，积累进步的证据。
1.35 何美琪 [http://www.cnblogs.com/heyjoymq/p/5314096.html]
补交作业。欢迎归队，战士。
1.36 张敏 [2016.3.24 OneZero站立会议]
产品BACKLOG需求。期待本轮迭代的可执行代码。
1.37 濮成林 [http://www.cnblogs.com/charliePU/p/5317410.html]
耐撕团队站立会议 24日。数据流图。
1.38 夏一鸣 [http://www.cnblogs.com/xiaym896/p/5316550.html]
OneZero站立会议。开发环境和架构选择。
1.39 郭又铭 [http://www.cnblogs.com/guoyouming/p/5317863.html]
需求分析 词频，根据《构建之法》第8章需求分析。
2. 作业重点
2.1 齐嘉亮同学的整理
2.2 请不要忘记
2.2.1 PSP 和 进度条 是每周都要求的
2.2.2 4人小组项目开题需求、站立会议每工作日更新。
2.2.3 技术博客应包括 scrum sprint, 需求、计划
补充要求1 站立会议每日更新要包括 burn down、甘特图，截图粘贴到技术博客中。
会出错不可怕，错误是正常应该出现的，错误帮助成长；最大的错误是为了防止犯错而退缩。
需求怎么写、站立会议应该包括什么，甚至需求和站立会议是什么，其中的细节杨贵福是不会讲的。
凡是课本或网上你容易找到的东西，都不会在课堂上讲，这是对您身为硕士研究生的尊重。祝贺你有机会获得尊重。
补充要求2 本周的迭代，不仅应有总体需求和计划，应包括架构的 代码实现，参见 RUP 的 architecture-centered。
2.2.3 词频/四则运算 的代码改进 是每周都要求的，缺需求spec的请补上。要求结对进行。
当你终于发现需求spec的价值的时候，词频/四则运算就由编程大作业演进为了项目。
重申参考 用户需求及spec: 四则运算 [http://www.cnblogs.com/jiel/p/4810756.html]
这条线索不要求 burn down 和 甘特图。
2.2.4 重申部分
- 文字给出的感想呢？
邹欣老师指出:
这的确是一个要点。 建议让同学们看看以前学生的总结：
http://www.cnblogs.com/malinlin/p/5058509.html
各位同学，读完什么感想，请文字给出。
请不要说“老师你记性真好”，我只是重新又读了一遍。你也能做到，请从此刻开始，养成严谨的习惯，不要等到这个习惯养成再去工作。
-
你欠邹欣老师和杨贵福的回答
-
互评。
已作为惩罚性作业，要求评论所有人的所有技术博客。即使你评“没啥可评的”也是开启双向交流，毫无行动，就是放弃交流。
3. 预习和思考题
3.1 单元测试
幻飞龙博士的 极简单元测试示例
谢谢牛宝乐老师供应资料。
3.2 汉堡模型
结对或4人小组吵架的时候，请参考邹欣老师的汉堡模型
3.3 编程 vs. 工程
在课堂上，杨贵福提到 代码鉴赏力。那么，什么是 好的 代码，什么是 坏的 代码，代码之好坏是否可能因环境或需求的变化而变化？
什么是好的工程项目，什么是坏的工程项目，是否可能 代码很好但是由它形成的工程项目糟烂，是否可能 代码糟糕而形成的工程项目不错？
3.4 功能 vs. 用例
邹欣老师提到:
一个反馈： 看到大家列出很多想做的功能， 很好！ 但是， 如果是一个公开发表的软件， 建议从用户的需求出发。 列出用户有什么痛点需要满足， 我们如何满足。 而不是从程序员的角度出发，罗列各种可能的功能点。
请看 http://www.cnblogs.com/xinz/archive/2010/12/01/1893323.html
请特别注意最初选择的用例，要现实、可以按期完成。
第一周仅有可执行框架，也在可接受范围内。
3.5 来自工业现实的声音
“无效的昵称”说: （感谢 无效的昵称 先生）
在我们这里，基本上都是短平快。从需求提出到上线，时间短，而且今天确定是这个需求，明天做完了，后天需求变了。需求一般深度教浅，先上线再说，效果好就继续迭代。产品更新速度快，产品今天上去了，明天可能就死了。在这种环境里面，TDD开发，代码可读性，注释等问题一般写代码的人是不会关注的，只有读代码的人才去了解一下。一般代码都是先上线，上线看到有这个那个问题，然后就再迭代改进，改进一般都是在大的结构范围内，细节基本上没有，比如：A系统调用B系统，调用耗时较多，就会加个缓存，但A系统内部有没有文档，有没有单元测试，基本上很少关注。不过现在在开始重视单测，不对是开始重视自动化测试，减少人工嘛。另外我们这边对性能关注较多，性能测试一般是必须的，不过到了大促了有一个不好风气就是堆机器，大促完成后，看到机器多了，第二年就又是各种性能优化。
工程实践并不局限于经典教材中的标准答案。
请各位同学思考，这里哪些是软件工程经典教材里提到过的手段，如果在 质量、范围、时间、代价 间妥协？为什么实践中工程师会这样选择，你会如何选择，这些手段与经典教材中的理论矛盾么，为什么？
接下来的讨论在[http://www.cnblogs.com/younggift/p/5240521.html#3385640]。