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