第一次迭代总结

设想和目标

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

时间: 2024-10-10 07:10:46

第一次迭代总结的相关文章

第一次迭代作业提交

程序java代码: 1 import java.util.Arrays; 2 import java.util.Scanner; 3 4 public class volleyball { 5 6 public static void main(String[] args) { 7 8 int[][] scoreArr = new int[5][2];// 定义二维数组,用于记录每局比赛分数 9 int red = 0; 10 int blue = 0;// 定义红蓝变量,用于判断红蓝整场比赛输

关于排球计分系统的第一次迭代

关于这个比赛系统的第一次迭代,使用的是java语言编写的,因为现在的技术有限,所以只能选择在控制台上与用户发生交互,没有实现界面化.之后随着学习的进一步深入,会使用界面来简化操作. package game.volleyball; import java.util.Scanner; /** * 排球计分系统 * * 使用DD排球计分系统可以进行简单的排球计分操作以及查询某一局的比分. * 1.比赛总共5局,每一局5分,若是有一方领先对方3分,则视为这一方胜利. * 5局结束后,统计两方胜利的次数

第一次迭代感想

第一次迭代感想写的有点晚,但是不妨碍我的想法. 这次我们的项目跟前几次实训有点类似,但是又有区别.组长分配任务,组员认领任务. 第一次的迭代目标我认领的任务是登录界面的设计.因为有之前实训的基础,所以这次的这个任务还可以,没用多久就写出来了,但是还有不足,需要后续完善. 这是java代码: public class LoginActivity extends AppCompatActivity { private EditText username; private EditText passw

Team--时代团队第一次迭代总结

一.设想和目标 1.1 我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述? 我们的软件<flappy bird>是一款全新动作类的游戏,与市面上的存在的游戏不一样的是,我们增加了很多功能.从传统的单人作战,转变为更有趣的团队作战.从传统的单一模式转变为可以选择的游戏模式.游戏因此变得紧张成刺激.节奏感强,玩家在游戏中便能获得更多的乐趣与成就感.从而既解决了flappy游戏相对比较枯燥无聊被动的问题,使玩家能够乐在其中,又不会像大型游戏一样占用玩家过多的时间精力,

第一次迭代目标

第一次迭代目标功能分配如下:欢迎界面及Logo的设计.登陆界面的设计.登陆界面功能的实现.注册界面的设计.注册界面功能的实现 小组成员功能认领如下: 魏静:欢迎界面及Logo的设计 黄希:登陆界面的设计 张佳慧:登陆界面功能的实现 孙刘兰:注册界面的设计 张梦霞:注册界面功能的实现

Team--时代团队第一次迭代分数分配

紧张的第一次迭代落下帷幕,便到了分数分配这样令人揪心又无奈的日子.如何进行分数分配,以使大家都能满意,这一直是个难以非常好地处理的问题.幸运地是,我们团队的所有成员每个人都对本次迭代乃至整个项目过程付出了很多,每个人都尽力地做好自己的事情.这让分数分配的环节显得容易了许多. 最后我们根据上次例会产生的团队个人排名,并按照老师的"各人不同分"的要求,对此次迭代的各人分数进行了分配. 一.本次迭代团队个人排名及工作的简单介绍: 1.李帅. 李帅在本次迭代中主要负责了主要代码编写这一重要又较

慢阻肺疾病管理APP——第一次迭代心得

时光匆匆,不知不觉就到了第十二周.--第一次迭代都完成了,最终迭代还会远吗? 一.第一次迭代的过程: 对于安卓,我一无所知.但是从无到有,虽然过程是让人崩溃的,但是当看到结果,心里还是很欣慰的,我想这就是一个程序员能从早到晚面对代码毫不懈怠的原因--因为有所期待,所以才会坚持. 另外,当初我们设想自己能完成巨多的任务,实际上上手操作,和想象中还是有差距的,这也许就是现实和梦想的距离.前期期望过高,就会造成过程中的尴尬,还好这些问题也被我们的机智给化解了. 自律和自学的能力在这个过程中显得无比重要

第一次迭代开发心得

通过第一次迭代,我真正意义上地体会到了当程序媛的感觉.有面对bug时的抓狂,有解决bug时的喜悦,也知道了整整一天都在码代码是什么感觉. 接下来就说一说我们组项目(基于联邦型知识图谱上的搜索引擎)第一次迭代的心得. 一.起步 因为之前大部分时间一直都在写各种各样的文档,所以我们的项目起步比较晚,真正意义上编写代码的时间只有不到两个礼拜.而且,我们当初把项目实现想得过于理想,导致后来时间有些不够用,所幸,在验收前一天,大家一起在图书馆泡一天,最终实现了第一次迭代的需求.这也是下次迭代需要注意的地方

第一次迭代心得体会

社区电商平台项目,小豆芽小组. 随着助教检查第一次迭代结果,小组之间互相查看代码规范以及小班课的结束,这个项目的第一次迭代在我心中终于落下了帷幕. 可以说,第一次迭代的过程,是我从开始学习编程以来最快乐的一次写代码,它让我第一次感觉到团队的力量是无穷的,也见证了一个团队由陌生到熟悉的过程,这种体验真的是极好的. 我们的项目是做一个电商小程序,虽然我们所用的语言相比较其它一些组来说是比较简单的,但是对于我们这几个从来没有学过这种类似语言的人来说,确是异常的艰难的,而且发现我们根本没有时间先去学会这

在线电力监测系统——第一次迭代开发心得

第一次做项目,第一次用javaee开发web工程项目,很多东西不会,摸着石头过河,也学到了很多东西. 第一次迭代开发,小组总体做出来的东西不多,与计划相比少了不少.完成的大致有两个半模块,其一是登录注册,其二是报警信息展示,其三是工单处理,还在技术上研究了动态数据在图表上的动态展示的实现(基于单个数据项的展示).总体来说,很多后台工作没实现,前端做的页面倒是蛮多,交互功能也有,前端的工作进度是先于后台的:后台开发的滞后性,以致于功能模块的集成进度受到了阻碍. 后台人员主要做了登录,注册,验证码验