Beta里程碑总结

设想和目标

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

要解决的问题是软件程序编写者找不到以前所写的代码的困扰;定义的基本清楚,团队成员都了解;曾经从数据库管理员的角度对典型用户和典型场景有清晰的描述。

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

两次冲刺之间的时间我们团队做了详细的计划,并分工。

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

激烈的讨论,这样能够出结果。

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

用户量和设想的差不多,但用户好像要求比较高;但是离目标更近了。

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

进行更加充分的准备,更为详细的讨论。

计划

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

没有都做完,只完成了一个发布、删除、修改消息的功能;因为原计划的目标设立不合适,所以只完成了1/4左右。

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

这样的事比较多,我们的分工不是特别明确,对项目还有很多不懂的地方,走了很多弯路,毕竟是第一次做,这样以后就有经验了。

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

不清楚,但是可以查可以问。

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

是,但是总是完不成,毕竟没有经验。

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

有,有一星期左右的缓冲时间;这段时间可以完善项目,写文档等。

6. 将来的计划会做什么修改?(例如:缓冲区的定义,加班)

团对合作还需要加强。

我们学到了什么?如果历史重来一遍, 我们会做什么改进?
定好最终的目标,不能过高也不能过低;团队成员多一些合作。

资源

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

有,图书馆的书、网上的教程、学长学姐的程序

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

任务完成时间比预期的长,是根据工作量、工作难度与个人能力估计的,精度不是很高。

3. 用户测试的时间,人力和软件/硬件资源是否足够?

测试时间很长;人力不够;软件/硬件是足够的。

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

有,因为自己有时候认识问题不够全面。

 

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

合理安排时间,团队成员之间加强沟通

变更管理

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

是,通过每天站立会议通知变更的消息。

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

成员间互相讨论,都认为不重要的功能推迟实现,比如发布校园动态。认为重要的功能及与设定的目标密切相关的必须实现,比如消息的增删改查等。

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

版本稳定,功能已基本实现,很少的bug

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

能,四个人的力量是无限的。

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

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

合作的方式可以让项目成功事半功倍;设定合适我们的团队的合作方式。

设计/实现

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

由组长王宏伟提出,三个成员一起出点子;在团队成立之后提出的。

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

有,团队成员讨论得出一致结论。

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

有用到单元测试,其他的没有;比较有效。

4. 什么功能产生的Bug最多,为什么?

将文件存入数据库的BUG较多,对这方面的知识不了解。

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

由两位成员检查调试;基本符合规范。

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

把程序规范化团队合作并非想象之中那样简单。

测试/发布

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

写过测试计划

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

没有

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

没有,是自己测试的

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

通过用户的使用感受和反馈进行改正。

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

投票阶段出现一点问题;发布力度小。

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

总结

你觉得团队目前的状态属于CMMI中的哪个级别?

可重复级:建立了基本的项目管理过程来跟踪费用、进度和功能特性。制定了必要的过程纪律,能重复早先类似应用项目取得的成功经验。

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

处于磨合和规范之间。

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

团队合作的更加紧密。

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

有阶段性的总结;前期的分工不是很明确;时间估计不准确,时间没有把握好

时间: 2024-12-18 12:11:48

Beta里程碑总结的相关文章

事后诸葛亮分析(Beta阶段)

设想和目标 1.我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述? 解决用户想要随时锻炼四则运算能力的问题:定义的很清楚:有清晰描述. 2.是否有充足的时间来做计划? 有时间,在alpha阶段后,我们调整了小组成员后,进行了一次讨论,然后再详细划分每个成员任务. 3.团队在计划阶段是如何解决同事们对于计划的不同意见的? 主要通过聚在一起然后进行讨论,最后确定一个方案,就一起按照这个方案去执行. 计划 1.你原计划的工作是否最后都做完了? 如果有没做完的,为什么?

Beta阶段事后诸葛亮分析

设想和目标 1. 我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述? 要解决的问题:学生们经常在实验室上课,时常会遇到实验器械出现故障需要报修,而普通的方法就是直接向老师汇报,有时候老师会忘记,并且还需要想维修的人员进行转达,学生也无法知道合适完成了维修.所以开发了实验室报修系统方便学生和教师. 典型用户:集美大学老师和集美大学学生 场景如下: 学生们正在上实验课,同学甲发现一台机器出现故障,同学甲可以登陆保修系统,填写故障机器的编号,故障的问题. 后台管理员可以

[Beta]M2事后分析

计划 你原计划的工作是否最后都做完了? 如果有没做完的,为什么? 答:没有,全部的功能没有实现.其中,界面还差两个,逻辑还差闹钟逻辑和群组逻辑,可以说这些东西是我们的核心功能之一,缺失了他们对我们整个团队的影响非常大.原因错综复杂,然而最主要的原因还是因为繁重的课业压力和“不作为”的心态. 有没有发现你做了一些事后看来没必要或没多大价值的事? 答:重新检测后端,重新分配任务.事实证明我们就应该先办个培训.技术断层出现了,让成员们跟的很辛苦.安卓平台多种多样的语句再次给程序的编写带来了麻烦.另外大

团队Beta阶段事后分析

团队Beta阶段事后分析 设想和目标 我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述? 我们的软件要解决用户的休闲娱乐问题,为用户提供好玩的模拟经营类的游戏,游戏主题是软件开发公司的成长历程.对典型用户和典型场景有清晰的描述. 我们达到目标了么(原计划的功能做到了几个? 按照原计划交付时间交付了么? 原计划达到的用户数量达到了么?) 我们的功能达到了基本目标,总共5个功能做了3个,但没有按照原计划按时交付延期发布,并因此用户没有达到基本目标. 和上一个阶段相比,

Rancher 2.0 Beta版正式发布!

Rancher 2.0 Beta现已正式发布!这是在4月底Rancher 2.0 GA之前最重要的里程碑发布,Rancher 2.0主分支现已包含所有关键功能,Rancher Labs团队即将进入最终Beta阶段,将工作焦点放在测试.文档和扩展性上. 自2017年9月Rancher 2.0技术预览版I发布以来,Rancher Labs研发团队持续进行着Rancher 2.0的功能开发和代码重构工作,先后继续发布了Rancher 2.0技术预览版II和III,且收到了来自客户及开源社区的极为积极的

各软件发布版本简写(Alpha Beta RC GA DMR)

Alpha:是内部测试版,一般不向外部发布,会有很多Bug.一般只有测试人员使用. Beta:也是测试版,这个阶段的版本会一直加入新的功能.在Alpha版之后推出. RC:(Release Candidate) 顾名思义么 ! 用在软件上就是候选版本.系统平台上就是发行候选版本.RC版不会再加入新的功能了,主要着重于除错. GA:General Availability,正式发布的版本,在国外都是用GA来说明release版本的. RTM:(Release to Manufacture)是给工厂

【第二组】项目冲刺(Beta版本)第六次每日例会 2017/7/24

项目冲刺(Beta版本)第六次每日例会 开发小组:Hunter 冲刺经理:林贵渊 小组成员:林轩宇,张太,李明君,刘仁人 1.每日例会内容 (1)昨天做了什么 1.林轩宇:Button音效及服务器相关内容. 2.刘仁人:二维码制作. 3.张太:查找本地内容. 4.李明君:LOGO设计,Button美化. 5.林贵渊:本地内容整理优化. (2)遇到了什么问题 1.图像传输问题(林轩宇) 2.部分功能存在一些小BUG(李明君,林贵渊) 3.控件及界面优化(刘仁人,李明君) 4.玩家交互没有好的构想[

Beta分布(转)

背景 在Machine Learning中,有一个很常见的概率分布叫做Beta Distribution: 同时,你可能也见过Dirichelet Distribution: 那么Beta Distribution和Dirichlet Distribution的意义何在呢? 解释 1. 如果给你一个硬币,投这个硬币有\theta的概率抛出Head,有(1-\theta)的概率抛出Tail.如果在未来抛了五次这个硬币,有三次是Head,有两次是Tail,这个\theta最有可能是多少呢?如果你必须

【Beta】 第七次Daily Scrum Meeting

第七次meeting会议 [Beta] 第七次Daily Scrum Meeting 一.本次会议为第七次meeting会议 二.时间:10:00AM-10:20AM 地点:禹州楼 三.会议站立式照片 四.今日任务安排 成员 昨日任务 今日任务 林晓芳 重观界面问题上的美化处理 对现有的东西进行总结,主要是关于此次采用的一些方法.库等等 林清青 与其他组探讨交流进度 对于接下里的任务方向与大家探讨 陈惠 重观界面问题上的美化处理 基于现有的东西进行更深入的完善,例如,如何让闹钟提醒更人性化 郑莹