码迷,mamicode.com
首页 > 其他好文 > 详细

第一次迭代总结

时间:2018-12-10 19:39:07      阅读:174      评论:0      收藏:0      [点我收藏+]

标签:结果   里程碑   难度   框架搭建   出现   总结   优先级   审核   基本   

设想和目标

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

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

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

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

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

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

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

原计划功能:用户登陆注册,查看历史记录,搜索药品。

功能还未完全实现,尚未交付使用。

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

暂时还没有投入使用,对于用户量和用户对重要功能的接受程度还是未知的。

项目正在逐渐完善,离我们的目标肯定是越来越近了的。

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

因为是第一次真正做一个项目,所以感觉对于项目的分工上有点不够合理,目前第一次迭代已经结束,但是我们的核心功能还没有完成,感觉应该在核心功能上多分配一点人手。如果历史重来,我们会给增加给核心功能的时间和人力。

 

计划

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

 感觉时间稍微有点紧张,随着项目的进行,计划也在不断调整。

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

 大家共同讨论,分析利弊,选择大家都认为最合适的计划。

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

 原计划的工作并没有完全完成。因为需要学习很多新的东西,感觉自己的学习效率较慢,而且平时的时间安排有点不够合理,有点跟不上进度。

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

暂时没有。

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

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

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

 项目的整个过程没有都按照计划进行,因为在项目进行的过程中,觉得有的部分觉得需要调整,然后前端界面的设计改变了一些。

 前端的框架搭建不是很好,在后面的开发设计中发现带来了一些问题。

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

 暂时没有。

8. 将来的计划会做什么修改?

 还有不到一个月就要验收了,项目的核心功能还没实现,接下来会努力尽快实现核心功能,还有完善数据库的设计。

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

学会制订切实可行的计划,不要过于高估自己的能力,合理安排自己的时间,多学习新知识。如果历史重来一遍,我一定会提前好好学习前端界面的知识的。

 

资源

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

有,网上可以学到很多需要的东西,相关书籍也很多,软件也有。

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

时间主要时按任务量来分配的,不过每个人由于自身水平的限制,所以具体完成的时间也会有所差异,精度感觉一般。

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

暂时还没有进行系统的测试,很多情况还不清楚。对于那些不需要编程的资源,虽然不需要编程,但是感觉任务量还是不少,估计难度还是不小的。

4. 你有没有感到你做的事情可以让别人来做(更有效率)?

觉得有些事情别人来做可能真的更有效率,因为我本身水平比较一般,效率不是很高。

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

应该好好学习,勤练技术。

 

变更管理

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

是的,我们建了一个专门的群来进行讨论,有问题也会及时在群里进行通知。

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

核心代码明显是必须实现的,优先级是最高的,至于其他的辅助功能,根据情况实现。

3. 项目的出口条件(Exit Criteria)有清晰的定义么?

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

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

没有制订,感觉应该不会出现很大的变化。

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

应该可以,因为大家每周的任务分配不同,每个人的水平也有差异,所以互相协作一下,问题应该不大。

 

设计/实现

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

设计工作是在项目的初期,由老师先给出核心的功能,然后大家共同讨论辅助功能的添加和大体页面的设计问题,最后和老师确认得到的。应该是合适的时间,合适的人吧。

2. 设计工作有没有碰到模棱两可的情况,团队是如何解决的?

有,大家共同讨论,给出明确的决定。

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

在设计原型时我们用了axure这个软件,在画uml图时我们用了startuml这个软件,感觉用起来都很方便。比较项目开始的uml文档和现在的状态,感觉内容更丰富了,发生了一些变化,因为计划在不断调整,同时也需要更新uml文档。

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

在核心算法的部分bug最多,因为核心算法最复杂,容易出bug,学习起来也很复杂,现在感觉在使用时候的准确性和有效性还难以保证。

5. 代码复审(Code Review)是如何进行的,是否严格执行了代码规范?

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

 

测试/发布

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

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

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

暂时只完成了第一次迭代的测试,还没有进行完整项目的测试,项目也还没有完成。

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

暂时没有。

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

测试工作目前还做得比较少,感觉不太到位,接下来打算制订一个比较完善的测试计划并且将每次测试结果记录下来。

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

暂未发布。

 

团队的角色,管理,合作

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

团队角色是根据大家得意愿并且结合实际情况确定的,大家都在努力发挥自己的作用。

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

有,团队之间大家经常互相交流自己碰到的问题,共同解决。

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

 基本没有出现什么大的问题,大家分工明确,合作也不错。

 

总结:

     你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?

    我觉得团队目前的状态属于CMMI的初始级

   你觉得团队目前处于萌芽/磨合/规范/创造阶段的哪一个阶段?

   我觉得属于磨合和规范之间吧。

   你觉得团队在这个里程碑相比前一个里程碑有什么改进? 

      大家的磨合程度更高,相互之间的配合比最开始的时候更有效率了。

   你觉得目前最需要改进的一个方面是什么?

   代码的规范性方面还存在一些问题,要尽快实现核心功能。

 

 

第一次迭代总结

标签:结果   里程碑   难度   框架搭建   出现   总结   优先级   审核   基本   

原文地址:https://www.cnblogs.com/w-2018/p/10096526.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!