第一次迭代心得

Posted 2021-01-25 xk00

一、设想和目标

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

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

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

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

典型用户：患有小病的人群

典型场景：去医院不方便但是想知道一些病症对应的药品

 

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

实现情况：

用户可以以游客的身份直接在主页以关键字匹配查询某种药品，查询之后点击出现的更多信息可以跳转到药品页面查看药品的具体信息，也可以先注册登录再查询，登录之后可以在个人空间查看曾经搜索过的历史记录。

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

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、正式开发前没有完全定义好接口，使得整合工作难度加大；

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

4、对软件的测试不够全面，并且没有保留测试记录；