第一次迭代心得

一，设想和目标

1. 咱们的软件要解决什么问题？是否认义得很清楚？是否对典型用户和典型场景有清晰的描述？

①解决的问题：咱们的软件是一款基于联邦型知识图谱的关键词搜索引擎。目前，联邦RDF 系统由许多自治的SPARQL 端点组成，SPARQL 端点只提供查询接口而用户不能经过此接口远程下载数据集来创建全局倒排索引，所以，关键字检索难度很大。咱们基于一种在联邦RDF 系统上进行关键字搜索的方法，经过SPARQL 端点上下文检索把关键字映射到子图结构中，而后经过子图生成SPARQL 查询来查询Endpoints 上的数据集，而不须要在不一样SPARQL Endpoints 上创建全局倒排索引。为了提升查询性能，咱们设计了多重查询优化策略来重写查询语句，普遍的实验证实咱们的技术仍是有效的。

②典型用户及典型场景：咱们这个项目定位不属于商业应用型项目，而是一个算法研究型项目，因此典型用户不是咱们这些平常的搜索引擎的使用者，而是专门的程序员或者RDF技术研究者，典型场景也偏向于研究而不是商业应用，更倾向于为专门的研究者服务，为算法研究提供前端界面并保存下大量中间结果及查询日志以方便研究者进一步改进算法。

2. 咱们达到目标了么（原计划的功能作到了几个？  按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)

咱们基本达到了第一次迭代的计划于目标，咱们原计划的功能包括要实现用户登陆，注册，邮箱激活，权限管理，搜索算法实现，结果展现等六大功能，最终咱们按照进度如期完成了原计划的迭代。可是在页面美化尤为是结果页的处理上还须要在第二次迭代时进一步优化。

3. 和上一个阶段相比，团队软件工程的质量提升了么？ 在什么地方有提升，具体提升了多少，如何衡量的？

与以前一阶段相比，咱们团队的工程质量提升了不少包括

①软件架构层面的优化：咱们组以前的代码基本没有思考软件架构的优化，因此先后端混在一块儿，全部事物基本都使用代码实现，而且每次数据操做均须要频繁开关链接，因此代码拓展性和可维护性极差，可是如今咱们组将前端，数据库，业务逻辑彻底剥离，而且使用了不少配置文件来避免“硬编码”，还使用了链接池来专门管理链接，整个工程分为了若干模块，代码拓展性和可维护性都大大提升。

②代码的复用性的改良：咱们组以前在写代码时不少函数直接写死了并且数据粒度比较大使得代码复用性比较差，在此次迭代中咱们注意了这个问题，一些函数采用了接口的形式，而且下降了不少函数的数据粒度来加强代码的复用性。

③编码习惯的改良：咱们组以前的代码在变量命名上比较随意而且基本不注释，因此代码可读性比较差，通过了一个阶段的修正咱们组如今在编码时就比较注意变量命名规范性以及增长必要的注释。

4. 用户量, 用户对重要功能的接受程度和咱们事先的预想一致么? 咱们离目标更近了么?

用户量及用户的接受程度基本符合预期，由于目前咱们的系统是一个研究型项目，面向的主要是专门的代码研究人员，用来方便他们的算法研究因此与不懂电脑的普通人相比，咱们的用户做为比较专业的程序员对于咱们的系统比较容易上手。

5.有什么经验教训? 若是历史重来一遍, 咱们会作什么改进?

 对于典型用户与典型场景必定要明确清晰，若是重来咱们会发扬此次的经验，在项目开始时尽快肯定项目的用户及场景。

 

二，计划

1. 是否有充足的时间来作计划?  

咱们组比较严格地按照边老师的要求，在每周日晚会讨论决定小组的周计划，以后我的再根据小组进度安排本身的周计划。

2. 团队在计划阶段是如何解决同事们对于计划的不一样意见的？

咱们组在计划阶段小组内部确实产生了不少不一样意见，咱们是先一块儿评估一下争议点的工程量及咱们的能力最后讨论肯定最终的计划的。

3. 你原计划的工做是否最后都作完了? 若是有没作完的，为何?

第一次迭代的原计划的工做基本都完成了，关于页面美化尤为是结果页的处理上还须要在第二次迭代时进一步优化。

4. 有没有发现你作了一些过后看来不必或没多大价值的事?

有不少，好比一些其余架构的探索以及使用socket通讯时一开始采用了txt文件来过渡等等，不过感受这些虽然最后没有使用在最终的工程里可是对于技术探索仍是有益的。

5. 是否每一项任务都有清楚定义和衡量的交付件?

咱们组在需求文档和第一次迭代开发文档里对每一项任务都有清楚定义和衡量的交付件。

6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为何没有估计到?

项目整个过程基本是按照计划进行，固然中途也出现了些意外，在验收前五天时项目组的服务器意外宕机了，致使当时项目组进度被停滞，这一点是以前没考虑到的，主要是想以前没有提早思考硬件故障的问题（尤为是腾讯这种大厂居然说出问题也出问题。。。）

7. 在计划中有没有留下缓冲区，缓冲区有做用么?

此次咱们制做计划时没有留下缓冲区，致使最后几天频繁刷夜（整个周末感受比高三时还拼╥﹏╥...），缓冲区能够为一些意外事件提早留出解决的时间。

8. 未来的计划会作什么修改？（例如：缓冲区的定义，加班）

未来计划咱们必定要提早考虑到各类意外出现的可能性，留足缓冲区时间，避免最后几天刷夜（实在肝不起了）

9.咱们学到了什么? 若是历史重来一遍, 咱们会作什么改进?

 咱们学到了在计划中要留下缓冲区，若是重来一遍咱们会提早考虑到各类意外出现的可能性，留足缓冲区时间

 

三，资源

1. 咱们有足够的资源来完成各项任务么?

①硬件方面咱们组有本身的一台服务器和老师的一台服务器基本知足需求

②软件方面咱们组均为一个专业的，空闲时间比较集中，编程能力上你们自学能力也都比较强，因此基本能够完成任务。

2. 各项任务所需的时间和其余资源是如何估计的，精度如何?

咱们组是根据任务的工程量，要作到的精细程度和咱们自身的编码能力来评估所需时间和资源的，精度比较准确。

3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不须要编程的资源 (美工设计/文案)是否低估难度? 

前期估计比较准确，因此在测试阶段资源基本足够，对于不须要编程的资源好比文案及UML图等咱们小组都是一块儿解决的，因此并无低估难度。

4. 你有没有感到你作的事情可让别人来作（更有效率）?

基本没有过，小组分工还算合理，我比较擅长数据库及先后端联系，软件架构层面，最终分配任务也是承担的这方面的任务。

5.有什么经验教训? 若是历史重来一遍, 咱们会作什么改进?

尽管小组分工比较合理，但仍是不够细化，小组开发时仍是不少时候出现了交叉甚至每一个人慢慢地都快变成了“全栈工程师”，固然这主要是由于咱们仍是在一些基础技术上掌握得不是很熟练，不少技术架构都是直接现学现用致使很容易碰到问题因此小组只能是每一个人每一个地方都会些，一我的出现问题了可能全组人一块儿帮助解决。若是重来一遍，一个team仍是要尽可能避免这种交叉编程的。

 

四，变动管理

1. 每一个相关的员工都及时知道了变动的消息?

项目组有专门的群用来讨论以及变动的通知。

2. 咱们采用了什么办法决定“推迟”和“必须实现”的功能?

咱们组通常会根据任务的工程量，功能是不是核心功能以及咱们自身的编码能力先讨论决定“推迟”和“必须实现”的功能，固然若是意见迟迟不能统一就投票决定或是向指导老师请教。

3. 项目的出口条件（Exit Criteria – 什么叫“作好了”）有清晰的定义么?

咱们组在需求文档及项目原型中对项目的出口条件进行了清晰的定义。

4. 对于可能的变动是否能制定应急计划?

咱们组没有在项目开始时事先制定应急计划，但此次迭代中发生变动时咱们组都会抽时间一块儿讨论来快速制定应急计划。

5. 员工是否可以有效地处理意料以外的工做请求？

咱们会进行动态的任务分配，一些意料以外的任务可能会动态的分配给一些编程能力较强的人。

6.咱们学到了什么? 若是历史重来一遍, 咱们会作什么改进?

咱们学到了 对于项目的出口条件，应急计划等必定要提早计划好，若是重来一遍，咱们会在项目开始时事先制定下大概的应急计划。

 

五，设计/实现

1. 设计工做在何时，由谁来完成的？是合适的时间，合适的人么？

咱们的设计工做是第七周左右开始的，而且采起了全组一块儿完成的方式（全组均为开发人员），时间节点上比较合理，人员分配基本合理。

2. 设计工做有没有碰到模棱两可的状况，团队是如何解决的？

团队通常会讨论最后表决肯定最终的设计

3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其余工具来帮助设计和实现？这些工具备效么？ 比较项目开始的 UML 文档和如今的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

①咱们组使用了starUML来制做UML图以及powerdesigner来制做数据库的E-R图，可能咱们的工程与真实企业项目仍是有差距，这些工具备做用能够帮助咱们明晰需求及项目设计但用处不是很是大

②由于项目需求文档最后进行了必定的修改，项目开始的 UML 文档也进行了相应的更新

4. 什么功能产生的Bug最多，为何？在发布以后发现了什么重要的bug? 为何咱们在设计/开发的时候没有想到这些状况?

搜索这个核心功能bug最多，由于它牵涉核心算法，数据库操做与socket通讯等多个模块，在发布前进行了大量测试发现了数据库链接空指针报错，链接服务器超时，socket通讯空指针错误等多个bug但都在发布前解决了。

5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

代码审查咱们是依据边老师以前发的阿里编程规范文档中的要求结合网上一些案例进行的，总体上比较严格地执行了代码规范。

6.咱们学到了什么? 若是历史重来一遍, 咱们会作什么改进?

咱们学到了不少，包括各类工具的使用以及编码规范等，若是重来一遍，咱们会在迭代时学习使用单元测试等工具及github或工蜂等代码托管平台的使用来避免咱们串联工程时一遍遍地import工程。

 

六，测试/发布

1. 团队是否有一个测试计划？为何没有？

项目最后事先留了一成天来进行各子模块及整个工程的测试。

2. 是否进行了正式的验收测试？

项目进行了正式的验收测试

3. 团队是否有测试工具来帮助测试？

此次团队没有使用专门的测试工具来帮助测试

4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工做有用么？应该有哪些改进？

团队是交叉测量对方负责模块的效能的，这些测试工做帮助咱们找到了不少bug使咱们在发布前解决了软件的bug

5. 在发布的过程当中发现了哪些意外问题？

在发布前进行了大量测试发现了数据库链接空指针报错，链接服务器超时，socket通讯空指针错误等多个bug但都在发布前解决了。

6.咱们学到了什么? 若是历史重来一遍, 咱们会作什么改进?

 咱们学会了要提早留出测试的时间并作好测试的计划，若是重来一遍，咱们还会学习下专门的测试工具来帮助测试。

 

七，团队的角色，管理，合做

1. 团队的每一个角色是如何肯定的，是否是人尽其才？

团队是根据成员的编程能力来肯定角色的，基本算是人尽其才，但分工能够进一步细化

2. 团队成员之间有互相帮助么？ 

团队采起了先我的编程搭好框架，再团队一块儿编程遇到问题一块儿解决的方式（图书馆二楼基本快被软工16级占没了。。）

3. 当出现项目管理、合做方面的问题时，团队成员如何解决问题？

小组通常会讨论最后表决肯定最终的设计

4.咱们学到了什么? 若是历史重来一遍, 咱们会作什么改进?

咱们学会了什么才是一个team（话说最后一个周末仍是第一次五我的从早到晚连吃饭都在一块儿连续待了两天半）若是历史重来，咱们会进一步细化分工，避免小组成员全变成“全栈工程师”的趋势。

 

八，总结:

1.你以为团队目前的状态属于 CMM/CMMI 中的哪一个档次?

嗯，以为大致在第二等级到第三等级上（咱们没第一等级辣么差，嗯，也没第四第五等级那么好）

2.你以为团队目前处于萌芽/磨合/规范/创造阶段的哪个阶段?

团队合做的话处于规范这一阶段（嗯，谦虚点）
3.你以为团队在这个里程碑相比前一个里程碑有什么改进? 

①软件架构层面的优化：咱们组以前的代码基本没有思考软件架构的优化，因此先后端混在一块儿，全部事物基本都使用代码实现，而且每次数据操做均须要频繁开关链接，因此代码拓展性和可维护性极差，可是如今咱们组将前端，数据库，业务逻辑彻底剥离，而且使用了不少配置文件来避免“硬编码”，还使用了链接池来专门管理链接，整个工程分为了若干模块，代码拓展性和可维护性都大大提升。

②代码的复用性的改良：咱们组以前在写代码时不少函数直接写死了并且数据粒度比较大使得代码复用性比较差，在此次迭代中咱们注意了这个问题，一些函数采用了接口的形式，而且下降了不少函数的数据粒度来加强代码的复用性。

③编码习惯的改良：咱们组以前的代码在变量命名上比较随意而且基本不注释，因此代码可读性比较差，通过了一个阶段的修正咱们组如今在编码时就比较注意变量命名规范性以及增长必要的注释。

4.你以为目前最须要改进的一个方面是什么?

具体设计上结果页的处理及美化是当前最须要改进的

 

最后但愿咱们的第二次迭代也能圆满结束，不然都对不起咱们组的咖啡钱和夜晚里掉落的头发（ヾ(´∀`o)+）