标签:
时间: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,断点调试等功能。
标签:
原文地址:http://www.cnblogs.com/sunny-code/p/4581995.html