第一次迭代心得

一、设想和目标

1.1 我们的项目要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？

我们的项目是基于知识图谱的药物推荐系统。

我国的“看病难”问题普遍存在，医患之间的巨大数量差距带来了一系列问题，如费用和时间成本高、登记难等。且医药零售连锁企业的信息化工作严重滞后于本身业务的发展。这些问题一个共同的特点就是缺乏统一集成的自动化导诊系统。

该系统主要是为了让用户在网上就可以查询到与自己所输入症状或者疾病相对应的药品的具体信息，应用于广大的网上用户中，既方便快捷有效，又在一定程度上解决可我国目前“看病难”。

典型用户：去医院难、无法承担过高的诊断费用、没有时间去医院的人群

典型场景：由于工作的忙，没有时间去医院排队、挂号等，可以通过我们的网站对自己的病情做一个简单的诊断，以便对病情有个大致了解，并找到合适的药方

 

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

实现情况：

1. 以关键字匹配查询某种药品

2. 注册，登录

3. 在个人空间查看曾经搜索过的历史记录。

3. 管理员可以在管理员页面输入信息然后在主页下方的小常识处显示。

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

暂未投入使用，用户实际接受成度未知

功能在逐步完善，离目标更近了

1.4有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

由于做这个项目之前，我们有很多知识都不知道，对知识的难易程度也不知道，导致分工侧重点不够好，后期难点部分很吃力，而负责其他部分的成员也没法帮忙。如果重来，要在做之前做一个难度分析，再根据难度适当的分工

 

二、计划

2.1 是否有充足的时间来做计划?

时间是不够的，因为做之前对很多东西都不了解，计划很难做

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

由于分工太明确，每个成员都没有去了解其他成员的要学习的知识，导致其他成员很难对别人提出意见

2.3 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?

第一次迭代计划我们都完成了，因为第一次迭代的主要内容就是网站的显示，是可以通过学习之后慢慢完成的，然后我们是打算把核心算法放在第二次迭代中去，完成后再与主系统对接起来。

2.4 有没有发现你做了一些事后看来没必要或没多大价值的事?

有，在刚开始时对于每个药物的功能，我们都打算用正则表达式从药品说明书中取出来，但是取出来的效果并不好，后来直接找到了药物和其功能的数据

 

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

因为我们的项目是网站的开发，第一次迭代中主体是网页的显示，所以都有比较清楚的定义，不太清楚的地方商讨一下可以很快得出结论。

 

2.6 是否项目的整个过程都按照计划进行?

对于我的这部分分工很难按照原计划进行，主要是因为我要等前一部分做出来了我才好开始，前面的时间只能看看书

2.7 在计划中有没有留下缓冲区，缓冲区有作用么?

我们一般没有留缓冲区，因为每周的任务我们都尽量根据实际情况来部署，任务适量。

2.8 将来的计划会做什么修改？（例如：缓冲区的定义，加班）

我们打算留一个缓冲区出来应对紧急情况，互相监督任务完成情况。

2.9 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

我们会对任务安排的更加合理，避免某个人任务过重完成不了。

 

三、资源

 

3.1 我们有足够的资源来完成各项任务么?

没有，对于核心部分要大量的优质的数据才能完成

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

由于对任务所涉及的知识了解不够，很难估计

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

测试上面暂时还没有详细的安排，我们是在每次整合，有做一点简单的测试，但是测试时考虑的不是很全面，美工方面确实不足。

3.4 你有没有感到你做的事情可以让别人来做（更有效率）?

暂时每个人还是各司其职。

3.5 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

我们会对任务安排的更加合理，避免某个人任务过重完成不了。

 

 

四、变更管理

4.1 每个相关的员工都及时知道了变更的消息?

都有及时收到消息。

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

我们是根据难度和重要程度来决定的。

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

 能够满足项目的需求文档的所有需求

4.4 对于可能的变更是否能制定应急计划?

没有提前制定应急计划，但是每次变更会及时对计划做出相应调整。

 

4.5 员工是否能够有效地处理意料之外的工作请求？

虽然不希望有意料之外的工作请求，但是真正有的时候还是会尽力去完成。

 

4.6 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

面对可能发生的变更情况我们要提前做出应对方案。

 

五、设计/实现

5.1 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？

团队的设计工作是在需求分析阶段小组成员一起确定的。

5.2 设计工作有没有碰到模棱两可的情况，团队是如何解决的？

设计时有短暂的不确定不过可以很快的跟老师组员商量后确定下来。

5.3 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？

有使用UML图来帮助设计

 

 

5.4比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

项目进行中需求会发生变化，从而导致UML的更新。

 

 

5.5 什么功能产生的Bug最多，为什么？ 为什么我们在设计/开发的时候没有想到这些情况?

在核心算法机器学习那一块的bug最多，因为这个功能最难，学习起来难度太大，实际测试使用的时候准确性和有效性难以得到保证。

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

组员一起按照代码规范来审核的，每一段都严格对照了代码规范。 

 

六、测试/发布

6.1 团队是否有一个测试计划？为什么没有？

每次整合都有一个简单的测试，但是并没有一个具体的测试计划。

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

没有

 

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

没有 

 

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

测试工作做的不够到位，我们需要设置一个比较完善的测试计划并且将每次测试结果记录下来。

 

 

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

暂时不考虑发布

 

 

6.6 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

测试工作做的不够到位，我们会设置一个比较完善的测试计划并且将每次测试结果记录下来。

 

七、团队的角色，管理，合作

7.1 团队的每个角色是如何确定的，是不是人尽其才？

团队角色确定尽量切合所有成员的意愿，然后进行协商。

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

团队之间经常交流，互相帮助。

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

我们的分工合作并没有出现过什么大问题，互相之间谁有困难都会尽量去帮忙。

 

八、总结

1、分工上没有完全利用好团队资源，使得部分人员工作负担略重；

2、计划不够完善，导致做了很多无用功

转载于:https://www.cnblogs.com/luozichao/p/10091776.html