一、设想和目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的软件是基于联邦型RDF知识图谱数据库的搜索引擎，我们的目标是利用RDF技术进行搜索。我们的项目定义是十分清楚的，包括从大的框架到小的功能需求细节，都是完全定义好的，可以非常科学有序地一个一个去实现。我们项目目前是为了研发技术而开发的，因此典型用户与典型场景几乎被限定在了“开发”这两个字上，也就是说，使用该搜索引擎的人基本限定在了技术研发人员，与技术研发场景。
2. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
对于第一次迭代（α版本）的目标，我们是完全实现的。原计划中的所有需求功能都得到了实现，且前端页面也得到了美化。我们同时每一周都在deadline之前提交了本周总结、下周计划以及会议记录，以及本周要求提交的文件，项目也在规定的时间内完成了验收。
3. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
目前使用该搜索引擎的用户包括我们整个开发团队（还有其他的开发人员），α版本中我们对于功能需求优先级的定义经过后来的证实是完全合理的，和事先计划几乎完全一致。我们距离项目的完成越来越近了。
4. 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
项目在第一阶段的开发还是存在一些可以改进之处的。比如我们在项目原型的建立上花费了过量的时间，前面几周我们的时间几乎都贡献给了项目原型。而后期项目有了一些变动，因为需求是不断在改变的（我们的需求变动来源于项目导师那边的要求），我们会经常与导师进行沟通，以确认我们项目的需求是否发生了改动。因此制作原型时只需要实现基本功能即可。
二、计划
1. 是否有充足的时间来做计划?
是的，我们在项目开始时就规划好了整个项目开发的框架，给两个不同版本的开发分配好了时间（当然，验收日期也是我们分配时间的一个重要指标），开始开发之后，我们每周周末都会为下一周需要完成的任务列一张清单，确保我们的项目按照计划进行。
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
说实话，我们项目组的成员就计划方面存在的分歧真的不多。项目初期，我们每次讨论都进行地非常顺利，就安排方面，我们每个人几乎都很默契地达成了一致，简单的讨论就可以解决。
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
计划的工作在deadline之前都顺利完成了。
6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
风险是有的。在开发的过程中我们遇到了很多之前没有料想到的问题，但都成功的解决了，在deadline之前。
7. 在计划中有没有留下缓冲区，缓冲区有作用么?
有。作用是很大的，开发完之后，多亏有了缓冲区，我们才有测试bug的时间，整个项目才能达到一个完美的程度。
8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
第二次迭代的开发周期是很短的。相比与第一次开发，我们确实需要在这几周用更多的时间，也就是加班加点去完成它。
三、资源
1. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
时间以及资源都是足够的。测试的时间（也就是前面说的缓冲区）是专门空余出来的，由全组人员进行。对于不需要编程的部分，我们也是精心策划好的，我们觉得美工设计与文案对于一个项目也是非常重要的，能够实现功能是一个项目的基本要求，而美工、文案等就是一个项目的高级需求了。
2. 你有没有感到你做的事情可以让别人来做（更有效率）?
我负责的部分是前端页面的设计以及美化。我自己对于自己任务的完成度基本满意，如果别人来做的话也可能会有更好的提升。
四、变更管理
1. 每个相关的员工都及时知道了变更的消息?
项目的任何变更，我们都会开会讨论，每个成员是不会存在与项目脱节的情况的。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
我们在制定第一次迭代开发计划时就已经确定了必须实现的功能，对于剩下的功能我们采取多多益善的方法，有多余的时间就去开发β版本的功能。
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
项目的完成标准在项目初期时就已经有了明确定义，也就是功能需求的完善与细化。
4. 对于可能的变更是否能制定应急计划?
由于我们项目讨论非常频繁，我们总能在项目需要变更之时立即修改计划，以保证开发的正常进行。
五、设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
项目的设计是由全组人员进行的，在项目初期的时候。因为我们的项目是技术型项目，大家需要一起对于项目的框架做出决策。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
大家在项目设计框架的时候是有不同意见的，但是经过讨论之后就会统一意见，持最佳意见的人会有十分具有说服力的理由，大家便不再存在争执。模棱两可的情况也都有，但是为了尽快进行开发，我们会先把能确定的部分确定下来，然后专门去讨论不确定的部分，这样不确定的问题也会解决地很快。
3. 什么功能产生的Bug最多，为什么？
目前来说是前端的注册登录功能。因为这部分需要前后数据库进行交互连接，网页端开发时会遇到各种各样的问题。但在发布之前都得到了完美解决。
团队的角色，管理，合作
1. 团队的每个角色是如何确定的，是不是人尽其才？
我们项目的工作分配为：后台开发三人、前端开发三人、前后端连接以及测试工作由全组人员一起进行。我们人物的分配就是根据个人能力以及个人特点分配的，因此做到了人尽其才。
2. 团队成员之间有互相帮助么？
我们团队的开发很大程度上都是一起开发的，大家有问题或者不懂的地方都会互相讨论，所以几乎每一次开发都是一个互相帮助的过程。
六、总结:
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
我们的团队目前属于规范阶段。开发形式等都已经磨合得很好了。
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
我觉得我们做得最好的原则是：①我们欢迎需求的变化，即使是在后期。例如：我们项目的后台代码是不断变化的，因此我们需要不断改变功能需求来适应后台搜索算法的变化。
②在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。我们小组的开发几乎全程是一起的，因为我们认为这样才能做到整体进度一致，我们每个人都是有分工的，但是项目的每一个部分都需要进行对接，因此我们基本是见面一起开发。
③简单——尽可能减少工作量的艺术至关重要。我们项目的开发，从前端页面的美化到后端代码的编写，都是秉持简约的风格，但不损失项目完整度。冗余的工作，无论是页面显示太多，还是后端代码太过繁琐，都是我们在尽力避免的事情。
最后，我想感谢我们组的四个其他成员：童天瑶、夏昊、顾杰伟、李斌。他们在我对这个项目的理解，以及分配给我的部分的完成上都给予了我极大的帮助。尤其是PM童天瑶，在完成了后端的情况下帮助了我们完成了很多前端的任务，也帮助我对前端、后端进行连接。他们也教了我许多我不了解的专业知识，我非常感激他们的帮助。