Sunny-Code Beta版总结会议

时间:2015-6-12

地点:基教601

参会人员:Sunny-Code全体成员

设想和目标

我们的软件要解决什么问题?是否定义得很清楚?

  我们打算做一款集成小蝴蝶功能、Ip快速修改功能、WiFi共享功能的一款软件。目的是为了解决晚上小蝴蝶断线重连问题。还有新生不会修改IP问题。

  功能定义清楚。

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

  我们共同提出问题,然后大家集体商量可行性,最后投票解决。

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

   应该时刻保持商量,协同进度,及时沟通,才可以保证最后不出现功能难以合到一个界面的情况。

计划

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

  

  原计划的工作都完成,没做完的部分是在部分笔记本上无法使用,最初计划的时候没有考虑到。

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

  有类似功能的程序,自己辛辛苦苦编写,最后发现并不能移植到其他笔记本上。

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

  任务在spring冲刺会议中写的比较简略,但由于比较简单,大家都能明白。

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

  基本上大家各自为战,进度还是有的。

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

  有,缓冲区是为了最终合成出现问题的时候,进行临时调整的。

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

 1.多查阅相关资料,了解编程语言在多个平台的可移植性

 2.要善于利用百度,没必要所有东西都自己写出来。有现成的可以使用。

资源

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

  三台笔记本足矣。

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

  大家抽取自己所用时间,没有好好进行好好估算时间。精度更是谈不上了。

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

  最后用了两天时间测试,发现移植问题。资源够用。

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

  没有。

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

 1. 估计任务所用时间时,需要询问队员意见

 2. 留给队员学习的时间

变更管理

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

  变更在我们上课的时候协商,大家都能及时知道消息。

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

  功能的重要性,越重要的越先实现。

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

  所有页面整合在一起,通过了各项测试,就“做好了”

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

  没有。

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

 1. 多沟通,尽管总是在一起,但是真正好好商量的时间少。

设计/实现

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

  设计工作在Sprint的前三天。由大家头脑风暴设计而出。是。

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

没有。

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

 团队用vs2010,自带的测试工具测试。

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

 合成的时候,出现了好多bug,还无法修改,最后不得不放弃最初的打算。另谋出路。

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

 有。

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

 做好各个功能的接口,留待最后合成的时候使用。

测试/发布

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

  团队有明确的测试计划。

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

  没有。。

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

  只有vs2010自带的测试工具测试。

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

 1. 熟练使用vs2010,断点调试等功能。

时间: 2024-10-01 20:24:37

Sunny-Code Beta版总结会议的相关文章

Beta版总结会议

1.会议过程及问题 我们首先梳理了一下这两次冲刺过程,仔细考虑过程中的每个细节,将过程与最后的成果一并进行分析,发现此过程中的确存在着几个问题. ①在我们的两次冲刺过程中,时间以及工作量的安排存在一定问题,总的来看,两次均是前几天过于松散,导致最后几天只能加班加点来赶工程,现在分析看来,是有几下几个 原因导致的: 开始的时候对软件的基本设计存在偏差,没有设计的足够perfect: 对团队能实现的技术没有把握,对软件的期望过高,在付诸实际下,才发现有些功能无法简单地实现: 团队中工作的分配不够明确

alpha版、beta版、rc版

很多软件在正式发布前都会发布一些预览版或者测试版,一般都叫“beta版”或者 “rc版”,特别是开源软件,甚至有“alpha版”,下面来解释一下各个版本的意思. alpha版:内部测试版.α是希腊字母的第一个,表示最早的版本,一般用户不要下载这个版本,这个版本包含很多BUG,功能也不全,主要是给开发人员和 测试人员测试和找BUG用的. beta版:公开测试版.β是希腊字母的第二个,顾名思义,这个版本比alpha版发布得晚一些,主要是给“部落”用户和忠实用户测试用的,该版本任然存 在很多BUG,但

Fedora 24 Beta 版发布下载!

Fedora 24 Beta 在经过三次延期后终于在 2016 年 5 月 10 日放出,除了对传统 32 位和 64 位架构的支持外,此次 Fedora 24 Beta 还额外增加了对 PPC64.PPC64el 和 ARM64 的支持.此外,你还可以下载和测试基于云和 Docker 的 Beta 映像.为了满足不同的测试环境和特定用例,此次的测试版主要发布了 Fedora 24 Cloud Beta.Fedora 24 Server Beta 和 Fedora 24 Workstation

alpha版、beta版、rc版的意思

很多软件在正式发布前都会发布一些预览版或者测试版,一般都叫“beta版”或者 “rc版”,特别是开源软件,甚至有“alpha版”,下面来解释一下各个版本的意思. alpha版:内部测试版.α是希腊字母的第一个,表示最早的版本,一般用户不要下载这个版本,这个版本包含很多BUG,功能也不全,主要是给开发人员和 测试人员测试和找BUG用的. beta版:公开测试版.β是希腊字母的第二个,顾名思义,这个版本比alpha版发布得晚一些,主要是给“部落”用户和忠实用户测试用的,该版本任然存 在很多BUG,但

unity4.6 Beta版 UI控件之Button

最近需求,需要用到4.6版本uGui了,所以抽时间来学习学习,就UI控件在Unity工具里创建预设这块来说相比较于NGUI,我觉得是没有什么太大的区别的. 比如:Canvas--Camera . Text--Label.ImageMask-- Panel 等. 可能是目前4.6版本还不稳定,其UI控件下所挂载的组件脚本代码我们是没法直接点击脚本看到更别说在代码里直接调出修改了,这点就目前来说确实没有NGUI方便. 好了"方不方便"恐怕并不能直接影响每次unity版本的更新带给我们的惊喜

【云快讯】《微软Sharepoint 2016 Beta版发布,强化混合云搜索功能》

2015-08-26 张晓东 东方云洞察 点击上面的链接文字,可以快速关注"东方云洞察"公众号 SharePoint Server 2016是微软的团队协作软件产品的最新版本,刚刚发布的Beta测试版的目的是让IT管理人员对即将在明年发布的SharePoint新版本有一个初步的了解和体验. SharePoint 2016的新主要功能包括:对10GB大型文件的支持和一个新的应用程序启动器,使得用户能够更方便的从SharePoint导航栏打开新应用程序.另外,微软还简化了共享文件的控制机制

Xamarin for Visual Studio 3.11.666 Beta 版 破解补丁

注意:本版本是 Beta 版 前提概要 全新安装请参考 安装 Xamarin for Visual Studio. 最新稳定版请参考 Xamarin for Visual Studio 3.11.590 稳定版 破解补丁 Version 3. Release Notes 3.11.666 C5SR2 原版下载链接:Xamarin.VisualStudio_3.11.666.msi,度盘备份 Release Notes:简略.详细 旧版备份 3.11.584 C5SR2 Release Log:简

发布《.NET 相依性注入》电子书 beta 版

初次发文,不知繁体中文可否.如不符规定,请多包涵,我可以用工具转成简体中文贴上来. 这是一则新书消息,从我的另一个部落格转发过来的,想了解这边是否有朋友对这块主题的书籍有兴趣. 书籍进度本书目前已经开始发行 beta 版,完成进度约 60%,共 133 页.(我希望这本书不要超过 200 页,目前看起来应该没问题.) 简介 我已经发布了<.NET 相依性注入-学习笔记>电子书的试阅章节,如有兴趣,请至本书主页免费下载.主页除了下载试阅章节,另外还提供了订阅出版通知以及读者意见回馈的功能. 试阅

beta版1.1.1

先期发布的alpha版1.0.0版本通过张硕组的测评,我小组跟进修改了出现的问题. 1.首先解决了互测版本中无法正常退出界面的问题,并有退出提示,(确定,取消). 2.就之前提到的关于前期部分功能的割去,我小组表示会在符合小组的具体功能及需求的基础上进行修改,并广泛尊重互测小组的意见. 3.对于此项,我小组积极修改,并在一定程度上呈现出相对友好的界面,在进入界面,选择功能,点击按钮等方面有很大的改变. 4.对于项目图片的收集,我小组有专门的组员进行操作,就此项,我们会反馈落实到到相关人员进行修改