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，断点调试等功能。

在这项软件里我们主要设计的问题方面有着这三个：

1.WiFi热点无法很好的共享

2.无法记录新的IP修改方案。

3.热点的权限修改的不够高

最终已完全解决，在晚上的时候可以尽情的享受WiFi的快乐了。