第一次迭代心得

 

设想和目标

 

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

(1) 

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

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

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

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

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

 

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

(1) 原计划：网站设计，注册登录，搜索药，查看药的详细信息，管理员发布消息

历史纪录

(2) 实现情况：基本实现，注册密码提示有缺陷

  

 

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

(1) 暂未知，功能在逐步完善，离目标更近了

 

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

(1) 暂未知

(2) 第二次迭代完善

 

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

(1) 一二次迭代内容调整，时间分配也要更注重，主要是核心的东西太难，并不是第一次迭代没做，而是没做出来

 

计划

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

(1) 开始看起来还充足，每周都找项目老师进行了讨论，将本周所做内容展示，并讨论确定下周要做的内容

 

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

(1) 计划都是统一的，分工明确，意见基本没有，前端做出来，会一起讨论，有什么点子都会说

 

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

(1) 我的工作是建数据库而且填充数据，第一次迭代的时间里我的也基本完成差不多了

 

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

(1) 有，开始在给数据库填充数据库时，根据老师的意思是要用正则表达式，后来用了以后发现并不能达到要求，后来用别的方法解决的

 

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

(1) 我的工作主要与核心算法相沟通，都有清楚定义

 

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

(1) 基本按计划进行

 

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

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

 

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

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

 

 

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

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

 

 

 

资源

 

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

(1) 第一次迭代因为把核心放在第二次迭代整合所以时间上还是勉强够用的。

 

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

(1) 这一次开发对各自的任务刚开始并没有多少概念，所以是走一步看一步的，大概估计一下。

 

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

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

 

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

(1) 分工后暂时不存在这种问题

 

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

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

 

 

变更管理

 

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

(1) 都有及时收到消息。

 

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

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

 

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

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

 

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

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

 

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

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

 

 

 

 

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

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

 

 

设计/实现

 

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

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

 

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

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

 

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

(1) 有使用UML图来帮助设计，项目进行中需求会发生变化，从而导致UML的更新。

 

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

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

 

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

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

 

 

 

 

测试/发布

 

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

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

 

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

(1) 第一次迭代验收

 

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

(1) 没有

 

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

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

 

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

(1) 暂未发布

 

 

 

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

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

 

 

 

团队的角色，管理，合作

 

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

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

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

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

 

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

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

 

 

总结:

 

  1、我们的整个开发过程并不成熟，显得十分生涩，许多项目中需要备注和记录的地方 都 没有保存下来；

2、正式开发前没有完全定义好接口，使得整合工作难度加大；

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

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

 

 

 

转载于:https://www.cnblogs.com/xujiang/p/10091359.html