1.代码复审的形式有哪些？复审的目的又是什么？
在我自己读这本书之前，我一直认为代码复审只需要自己审查一遍就好。书中要求代码复审包括：自我复审，同伴复审，团队复审。复审的目的在于
（1）最基础的找出代码的错误。
（2）发现逻辑错误。在自己编写代码的时候，可能会遇到虽然代码可以正常的运行，但是其实代码本身存在着逻辑错误的问题。
（3）发现算法错误。因为不同的算法会有不同的优化程度，所以复审对于算法的检查也是必要的。
（4）发现潜在的错误，和回归性的错误。
（5）发现可能需要改进的地方。
2.用户体验有哪些重要的要素，评价的标准又是什么？
用户的体验评价标准可以参考费茨法则（Fittslaw）、Nielsen启发式评估十条原则以及其他经验。原则包括
（1）尽快提供可感触的反馈系统状态
（2）系统界面符合用户的现实惯例（Familiarity，AvoidSurprise）
（3）用户有控制权
（4）一致性和标准化
（5）适合各种类型的用户
（6）帮助用户识别、诊断并修复错误
（7）有必要的提示和帮助文档
提问:考虑到实际情况，帮助文档是否在大多用户眼中很难去自己学习。能否有更好的办法让用户更好的使用软件，从而获得更好的体验。
3.提问：书中在敏捷流程中提到不要和管理层谈流程，他们只关心结果。因为我还没有工作经验，对于这个问题有些不解。如果和管理层完全不谈流程，如果在工作量巨大的情况之下，那么怎么才能保证结果按时完成？这时是否迫切的需要和管理层进行交流？
4.提问：书中在msf敏捷开发模式中提到更强调与用户的交流，因为项目的商业价值要用户说的算。我非常同意这个看法，因为用户才是项目的最终目标。但是在实际情况中，经常会出现用户的想法和设计人员的想法相冲突的情况。在这种状况下，要怎么权衡自己和用户的感受。如果一味的坚持采用用户的想法，是不是会挡住创新的路？
5.提问：在进行测试的时候，提到微软的bugbash活动。我认为这个活动确实可以开阔思路，让测试更加完整。但在实际情况中，如同书中所说，容易遇到滥竽充数的情况。结合实际的成本问题，这种活动展开的意义是不是就变得很小？能否跳过这个阶段？
1.当时的项目有多少用户，给用户多少价值？现在还有人用吗
我们做的是类似于俄罗斯方块的小游戏。作为一个休闲游戏，当时用户大概是百人左右。现在具体的人数已经不好统计了
2.这个项目能否给我们团队继续开发，源代码/文档还有么
当时的团队里应该还有人保存着，如果想要继续开发完善应该也是可以的。不过我们这仅仅是一个小项目，对你的帮助可能也很有限。
3.项目开发有什么经验和教训
4.对学好软件工程有什么建议
这个作品是一个相对来说比较简单的五子棋游戏，可以进行两人对战，并且具有保存和提示的功能。
这款游戏是一款简单，方便，大家都熟知的。作为一个棋牌类的小游戏，该有的功能它都具备。但是交互方式是通过wasd键盘来操作，就显得有些不够方便。同时，作为一款五子棋游戏，这款作品的棋盘有些小，考虑到五子棋的游戏特性，棋盘是肯定不够用的。值得称赞的是，它具备了提醒的功能，更加完善了用户的体验。
这个作品是为了给临近期末考试的学生帮助他们来背题做题。同时支持自行录入题目，这样让软件更加灵活，方便学生的复习。
我把这款作品拿来说的目的就是，它作为一个作品，该有的功能都可以实现。期末时候题库确实可以为学生的复习带来很大的便利。但是同时，他的界面过于简单。导致操作逻辑虽然不难，但是步骤却很多，导致不方便用户的操作。作为项目的编写人员，也同时要考虑到用户的操作和体验。
这个作品是为了方便人们出行旅游而设计的移动端app。它不仅可以同步旅游景区的最新信息，同时也可以在app上直接预定酒店，机票等。极大方便了人们旅游出行的需求。同时为了用户的个人隐私也做出了相应的保护。
最后作为点评，我把这个相对成熟的项目放在最后来说。相对于第一款作品，它的交互方式符合用户的操作习惯。相对于第二个作品来说，它的操作界面明显更好。同时作为一个手机app，它希望实现的基本功能都可以实现。同时它的整体界面，也和目前主流的手机app相符。定位准确，设计符合用户操作习惯才能让一款项目可以有真正的实用价值。