标签：控制 添加 pre 请求 沟通 内容 分析 com nbsp
项目名：食物链教学工具
组名：奋斗吧兄弟
组长：黄兴
组员：李俞寰、杜桥、栾骄阳、王东涵
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也最多。
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初始阶段更倾向于做成封闭的教堂，然后在实际开发过程中慢慢向集市方式转变。采用这样的模式：
我们的优势在于能够更加贴近用户的需求，随时倾听用户的想法，包括功能点和整体软件使用感受等方面。
劣势在于因为没有太多的时间的原因，我们项目的细节方面没有达到一种更好的效果。
在以后的项目中，还是需要提高效率，理清项目继续进行的思路，争取能够完善细节的地方。
标签：控制 添加 pre 请求 沟通 内容 分析 com nbsp
原文地址：http://www.cnblogs.com/huangxman/p/6059235.html
