Sunny-Code Beta版总结会议

时间:2021-01-27 10:19:06

时间:2015-6-12

地点:基教601

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

Sunny-Code Beta版总结会议

设想和目标

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

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

  功能定义清楚。

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

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

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

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

计划

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

  

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

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

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

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

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

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

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

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

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

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

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

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

资源

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

  三台笔记本足矣。

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

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

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

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

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

  没有。

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

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

 2. 留给队员学习的时间

变更管理

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

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

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

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

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

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

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

  没有。

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

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

设计/实现

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

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

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

没有。

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

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

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

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

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

 有。

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

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

测试/发布

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

  团队有明确的测试计划。

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

  没有。。

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

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

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

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