回顾你的课程计划 （第一周的计划）， 你完成的程度如何？请列出具体数据和实际例子
我当时的计划是通过阅读软件工程的相关材料，以及软件工程课上的项目，提升自己的软件开发的相关技能，并且学习在个人编程/团队合作中的科学方法，提高自己的工程效率。我的完成程度10分满分的话我给自己打8分吧，在这门课里，我学习并实践了结对编程以及敏捷流程这些团队开发技术。在团队项目中，体验到了完整的开发流程。
你在课程开始快速浏览了《构建之法》，提了 5 个问题， 请回顾那些问题， 自己回答它们。如果不能回答，为何软件工程课不能让你回答这些问题？
当时提的几个问题现在或多或少有了一些认识。
第16章 IT行业的创新 16.1节 创新的迷思(P350)
大众通常把科研和创新等同起来，这也是不准确的。以发明即时贴闻名世界的3M公司的杰弗里·尼科尔森对两者做了明确的区分，他认为"科研是将金钱转换为知识的过程"，而“创新则是将知识转换为金钱的过程”。
关于科研和创新的区别，杰弗里·尼科尔森的观点的前半句我是认同的，而后半句话中的“创新”我感觉有些狭隘，我觉得不是所有创新都是将知识转化为金钱的过程，有些创新本来就是需要投入大量的成本，做大量的实验后才能得到的，此处杰弗里·尼科尔森所说的“创新”应该特指将如何将新的技术转化为实际应用的过程。
关于这个问题，我现在和当时的观点差不太多，但确实也体会到了上面所说的科研和创新的这种区别。
第16章 IT行业的创新 16.1节 创新的迷思(P353)
微软公司的中文输入法产品曾经是Office软件的一部分，在20世纪90年代到21世纪的前10年，Office多长时间发布一次呢？平均18个月到两年。中文输入法呢？也自然一样（中间可能有一到两次发布补丁的机会）。自2005年开始，一些新的挑战者开始做中文输入法，它们的更新频率是多少？是一个月，甚至半个月。那么谁更有机会做出适合用户的改变，谁更有希望赢呢？
这里关于产品的“更新周期”我有一些疑问，我们应该怎么来确定产品的“更新周期”？还有“更新周期”是越短越好吗？如果更新周期太短，是否会因为每次的更新内容都没有带来实质性的变化导致用户没有兴趣进行更新甚至感到有些烦？
我现在觉得更新周期确实需要根据具体项目具体确定，然后可以根据上一轮的周期中的用户数据来优化产 品，进行下一轮更新。
第6章 敏捷流程 6.2节 敏捷流程的问题和解法（P112）
另一个改进是，要在每一个任务中记载我们完成这个任务还需要多少时间。
敏捷流程我觉得是一个很好的提高效率的做法，但是这里的关于每个任务的剩余时间的估计我有一点疑问。就是我们在一个做一个全新的/不熟悉的问题时我们怎么更好的估计完成这个任务的剩余时间？
在团队项目中我发现估计任务的完成时间确实是一个很难的事情，特别是对于自己不熟悉的任务，可能对于有些问题会高估完成时间，在很短时间内就解决了，甚至发现根本不是问题，但是对于有些问题，特别是有外部依赖存在的，可能一开始根本不知道有这个问题，但最后却要花非常多的时间来解决。所以我觉得在一开始的时候应该需要确认好可能会遇到的外部依赖等不确定因素，才能更好的估计完成时间。
第5章 团队和流程 5.2节 （P92）
关于“主治医生模式”，文中提到在学校中经常会退化为一个人干活的情况，这里我有一个疑问就是“主治医师”如何让所有其他人都有能动性，能主动参与进来？
关于团队合作的模式，在团队项目中我也体验到了一些，我觉得需要通过PM来协调大家的时间和任务，并且通过每日例会等团队讨论来确保每个人都能明确自己的当前任务，从而不会退化到所谓的一个人干活的情况。
看看还有什么新的问题产生，请列出来，建议列出 2-3 个新问题。 可以让老师和助教来回答
我有一个问题是在一个软件开发项目的初期，如何更好地确认这个项目需要哪些外部的依赖，以及对于这些外部依赖，怎么更好的估计它所需要花费的时间？
你看了一些软件工程的文献， 你的团队也做了一两次 “事后诸葛亮”分析， 可以再去看一遍，现在有什么新的感想？
我又看了一遍我们的团队项目的alpha阶段的总结，当时就提出了我们的软件在alpha阶段的两个最为致命的问题：速度和UI，这也成为了我们beta阶段的主要解决的问题，我体会到了在团队开发中，“事后诸葛亮”分析这样的阶段性的总结反思还是非常有必要的，它能让你明确下一阶段的目标和努力方向。
对比一些技能评价表，你有什么提高？ 还有什么收获是不能用数字衡量的？
上这门课之前的技能评价表：
| Programming: Comprehension | Programming: Design | Programming: Implementation | Program: Performance | Personal Software Process |
|---|---|---|---|---|
| 4 | 3 | 3 | 3 | 3 |
上这门课之后的技能评价表：
| Programming: Comprehension | Programming: Design | Programming: Implementation | Program: Performance | Personal Software Process |
|---|---|---|---|---|
| 6 | 6 | 5 | 5 | 5 |
除了技能评价表上体现出来的，还学会了如何进行结对编程，如何进行团队项目的合作。
设想一年之后， 你到了你职业发展的下一个阶段（高年级， 读研，工作），回头看这门课， 你对于这门课的教学方法， 老师和助教的工作，和其他课程的衔接，有什么意见和建议？
我觉得到了下一个阶段中，到时回头来看这门课，可能这门课产生的影响已经潜移默化的改变了自己平时的科研和开发的流程。关于建议，我觉得在团队项目中有些项目可以基于前几年别人的项目继续开发，从而收获到继续开发别人项目的一些经验，也可以让团队项目的成果可以持续维护下去。