（第十周）Beta Review会议

项目名：食物链教学工具

组名：奋斗吧兄弟

组长：黄兴

组员：李俞寰、杜桥、栾骄阳、王东涵

Beta Review会议

时间：2016.11.14   10:00——11:30、13:30——15:00

地点：冬华楼一楼大厅

会议内容：

食物链教学系统Beta Review结果

设想和目标

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

　　对教师食物链教学的辅助功能。起初定义的很清楚，在实现的过程中发现也适合于家长和学生使用。有啊，典型的用户是教师，场景是课堂。

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

　　有时间，但遗憾的是没有进行合理的利用，因此计划的不是很详细，一些细节部分是在不断地开发过程中想到的。

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

　　主要是采取少数服从多数的原则，当双方人数相等时，由组长做出最后的决定。

计划

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

　　没有全部完成。因为没有正确预估其中某项工作因难度问题所需要耗费的时间，还有要花费大量的时间去解决突然出现的Bug。

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

　　有，比如说：属性面板的移动方式，研究设计了几种，最后还是决定用了sdk中自带的移动方法，其实效果差不多。还有就是偶尔过度纠结某个问题，其实这个没有什么价值。

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

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

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

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

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

　　有缓冲区，原来认为没有必要，后来发现还是有用的，缓冲区的存在更有利于大家的互相配合。主要是每个人任务完成的进度不一样，有些模块不断地有一些小问题，花了很长时间才能做好。

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

　　先是要完成全部计划的功能，然后对整个项目进行完善，再根据具体的情况决定是否添加新的功能。还有就是应该明确缓冲区的长度。

资源

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

　　资源足够，但是开发项目的时间不够。每天用来做项目的时间有限，也不是很多，所以很多地方没有进行深入的考虑，没有做到更好。

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

　　先是粗略估计，然后随着项目的进行，由于了解程度加深，会调整这个估计值，通过这个估计值来对项目进行相应调整，精确度会有提高，但不会很高 。

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

　　足够

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

　　没有，每天都会根据各自情况分配相应的任务。但若得到其他已完成自己任务的人的帮助会更快更好的完成任务。

变更管理

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

　　是的，消息传达的很及时。

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

　　进行投票，民主表决。

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

　　大家都不太懂“出口条件”是什么。

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

　　能

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

　　能处理，只要不是太离谱的请求。

设计/实现

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

　　整体的项目构思在最开始的时候由大家共同参与完成，设计工作也有多人合作完成，并且在项目的进行过程中，不断做出调整，争取达到好的效果。是合适的时间合适的人。

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

　　有很多，大家都不知道如何处理。这样的情况就会进行投票，采取少数服从多数的原则。

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

　　没有。

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

　　添加自定义生物功能的Bug最多，因为我们开始的时候对这个功能的考虑过于复杂，所以走了很多弯路，有很多Bug产生，后来把不可能实现的给去掉，就容易多了。

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

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

测试/发布

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

　　有测试计划，这样可以更有效率，节省工作时间。

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

　　进行了验收测试，但是没有那么正规。

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

　　没有。

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

　　没有进行效能测试。

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

　　alpha发布时，因为所带电脑没有一个特定的端口，所以无法将电脑和投影仪连接起来，无法达到好的演示效果。在Beta发布时解决了这个问题，但在演示的过程中，介绍的内容还是有一点点欠缺，还能够介绍的再详细一点。

Questions:

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

2、团队在beta 阶段吸取了那些alpha 阶段的经验教训?

3、12 条敏捷开发的原则中, 团队做得最好和最不好的各列举2点。

4、对照 The Cathedral and the Bazaar (大教堂和集市), 你的团队开发模式是哪一种, 优势/劣势在哪里?

Answers:

1、

成员	Beta阶段的实践和alpha阶段有何改进
黄兴	责任心更强了，积极性也有了很大的提高，对整个项目的继续进行有了更加清晰的认识，对整个项目进度的掌握性有一定的提高，与团队成员的交流加强，对每位成员的具体情况有了更多的了解，也更加尊重每位成员的意见和看法。
李俞寰	和组员间的配合更加默契了，我们的很多工作是一起完成的，大家互相提醒和补充，大大提高了工作效率，明白了工作中沟通是非常重要的，一定要把信息处理的及时、有效和清晰。同时自己的编程技术也有所提高，比如对bug的定位和修改的速度更快了等。
杜桥	较alpha发布阶段的积极性有了明显的提高，组长分配任务之后组员会很快地执行，每天分配的任务会尽量按时完成。默契程度明显的提高，团队成员之间会把不懂的地方或问题提出来大家一起讨论，之间有关系的任务会频繁的沟通。
栾骄阳	虽然是Beta阶段新来的成员，但在其他成员的帮助下，对本队的项目有了深刻的了解，学到了软件开发过程的控制，站立会议内容及流程，还收获了团队协作精神，与其他人配合的默契度在不断加强。
王东涵	虽然是新成员，但在其他人的帮助下很快了解了组内的项目，学到了很多新的技术知识，也更懂得如何与其他的队友合作去完成项目，提高了做事的效率，同时与其他人配合的默契度在不断加强。

2、

吸取了alpha阶段中，对功能的需求分析不够仔细，没有很好的了解真实用户的需求的教训，在Beta阶段结合了朋友提出的需求，添加了新的功能；

吸取了alpha阶段中，组员间沟通少的教训，组员之间进行了及时沟通，避免了进行重复或无用的工作；

吸取了alpha阶段中，组员的积极性不高，工作效率提不上来的教训，进行了调整，调动了积极性，提高了工作效率；

吸取了alpha阶段中，项目掌控程度不够，项目完成度不够的教训，随着项目的进展，组员间默契度的提高，是对项目的掌控程度有了提高，对alpha阶段的功能进行了完善和补充；

3、

最好的两点：第3点和第7点

3: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale

翻译：经常发布可用的软件，发布间隔可以从几周到几个月，能短则短

7: Working software is the primary measure of progress

翻译: 可用的软件是衡量项目进展的主要指标

最不好的两点：第2点和第12点

2: Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage

翻译：敏捷流程欢迎需求的变化, 并利用这种变化来提高用户的竞争优势

12: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly

翻译: 时时总结如何提高团队效率, 并付诸行动

4、

我们团队的开发模式在alpha初始阶段更倾向于做成封闭的教堂，然后在实际开发过程中慢慢向集市方式转变。采用这样的模式：

我们的优势在于能够更加贴近用户的需求，随时倾听用户的想法，包括功能点和整体软件使用感受等方面。

劣势在于因为没有太多的时间的原因，我们项目的细节方面没有达到一种更好的效果。

在以后的项目中，还是需要提高效率，理清项目继续进行的思路，争取能够完善细节的地方。