final-review

标签：简便   实践   推荐   内容   验收   可能性   相关   会议   决定   

小组名称：飞天小女警

项目名称：礼物挑选小工具

小组成员：沈柏杉（组长）、程媛媛、杨钰宁、谭力铭

会议时间：12月2号12点

会议内容：

设想和目标

1、我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？

　　我们的软件是为了解决日常生活中特定群里出现送礼困难的问题，定义的非常清楚。典型用户和典型场景都很容易模拟出来。我们的需求规格说明书里有详谈

2、是否有充足的时间来做计划?

　　在α阶段我们没有足够的时间做计划，所以BETA阶段我们做了更为详尽的计划包括每个页面的UI设计，礼物挑选方法，还有礼物推荐的各种可能性，花了将近4个工作日。而且还是觉得不够详尽。这说明我们还是没有足够的时间做计划。4个工作日做计划都还没完成。而且导致后期测试时间都没有了。而FINAL阶段由于时间太过于短暂，只能勉强修补BUG还有增加一个功能而已。

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

　　主要是采取少数服从多数的原则，各种讨论，谁有什么观点请拿出证据论证说服对方。不行就都听组长的。组长大过天，长得好看也中

计划

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

　　没有全部完成。本来是想要用爬虫抓来一定数据，然后用方法嵌入到数据库中，想了很多办法也没敲定时间又紧凑，所以就直接做了最简便的猜你喜欢模块

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

　　没有，做的都很有价值，就算是最后没有实现的部分，做必要的讨论也是很有价值的

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

　　大部分都没有，因为我们大家都不知道做到多少才叫“好”。有些情况下，大家对细节过早地进行讨论，花了很多时间。不如等到后来对项目有了更深的了解后再讨论，这样可以节省时间。

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

　　是的，按照原定计划，功能依次实现。

5、在计划中有没有留下缓冲区，缓冲区有作用么?

　　没有缓冲区，因为全拿来的时间都不够用，所以没有缓冲区。直接把大家都逼死，有停滞就言语鞭策也可以肢体冲突，追着要结果

6、将来的计划会做什么修改？（例如：缓冲区的定义，加班）

　　计划阶段我们做的还不错。缓冲区说实在的还是很有必要的。要不然组员要杀组长了。加班也都是迫不得已的。其实个人非常不想。

资源

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

　　资源还算足够吧，但是开发项目的时间不够。每天基本都拿来做项目了。还是做的很残缺

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

　　先是预判，比如第一天，各组员领任务，第二天站会的时候说明做完了么，为什么没有完成，你觉得还有多久可以完成？这样就更加精确了，毕竟只有做的人才了解真正需要的时间

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

　　完全不够，最后跟本没有测试的时间。按理说应该时开发和测试时间对半分。这样在后期可以补BUG，现在是勉强开发完。根本就没有测试环节

4、你有没有感到你做的事情可以让别人来做（更有效率）?

　　经过α和β阶段，我们分配任务的方式很科学，效率已经i很高了。我们的团队也很和谐

变更管理

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

　　是的，消息传达的很及时。虽然需要不断打电话

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

　　开临时会议，采纳大部分人意见

3、项目的出口条件（Exit Criteria）是否得到清晰的定义?

　　这个问题我们定义的比较模糊，能拿的出手，有整个轮廓就可以。

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

　　可以，比如砍掉某些功能。说砍就砍

5、员工是否能够有效地处理意料之外的工作请求？

　　基本上可以。

设计/实现

1、设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？

　　设计工作在最初期。由组长完成，设计完成后给组员展示，广收意见再做更改，挺合适的。

2、设计工作有没有碰到模棱两可的情况，团队是如何解决的？

　　有，譬如一个功能，想着简直是完美无缺，但是具体怎么实现大家都找不到办法，最后要么砍，要么找人帮忙做

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

　　没有。

4、什么功能产生的Bug最多，为什么？

　　竟然是注册登录哪里BUG最多，因为我们那里处理的很粗糙

5、代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

　　由同伴对已实现的功能进行审查，为了找出代码错误或是否能进行改进，但没有严格执行。

测试/发布

1、团队是否有一个测试计划？为什么没有？

　　没有测试计划，时间段，作业多

2、是否进行了正式的验收测试？

　　没有进行正式的验收测试，就是各个组员在一起尝试运用一下

3、团队是否有测试工具来帮助测试？

　　没有。

4、团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？

　　没有进行效能测试。

5、在发布的过程中发现了哪些意外问题？

　　没有意外问题，我们发布都会进行发布预演。任何情况都可控

每个成员在beta 阶段的实践和alpha 阶段有何改进?

我们的团队经过了三个阶段，已经积攒了足够的默契。如果再次大战三百回合。。。估计我们也是可以的。（但是我们肯定不愿意的）

和其他团队也建立了良好的互帮互助，不带感情色彩的批评与建议，我觉得这样的效果还是很好的，有人指责，才能知道不足，听得进去别人的建议才有进步。

final-review

标签：简便   实践   推荐   内容   验收   可能性   相关   会议   决定   

原文地址：http://www.cnblogs.com/shenbaishan/p/6123450.html