设想与目标
我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
- 解决的问题
- 总体解决的问题：新手编程者配置编程环境难、本地编写的代码跨设备同步难、本地ide安装使用过程繁琐等问题
- alpha阶段解决的问题：基本项目的创建，自动补全，编译运行
- beta阶段新增：
- 随手写简单代码、项目多人合作中的分享和协作开发
- 美化功能，让使用者感觉更加赏心悦目。
- 进一步解决软件启动速度问题。
- 定义是否清楚：
- 是否对典型用户和典型场景有清晰的描述：
- 有，面向简单使用、临时使用的用户。如，用户只想测试一个语法特性。
- 具体用户场景描述可以参见以往博客：
- 单个典型用户场景描述以及测试
- 多用户场景，可以考虑为多个典型用户同时使用，例如在学校的上机测试，上机实验环节，多用户场景测试
我们达到目标了么（原计划的功能做到了几个？按照原计划交付时间交付了么？原计划达到的用户数量达到了么?)
- 我们的基本目标基本已经达到了，原计划的语言支持功能（包括自动补全，查看定义，代码纠错等），编译运行功能已经完成，并且支持了cpp和python语言。
- beta阶段计划的功能也是完整的实现了：
- 我们实现了菜单栏美化、主题设置等alpha阶段的功能完善
- 实现了新增的包括单文件和多文件的断点调试功能
- 实现了草稿纸和代码模板等全新的便捷性功能
- 实现了项目协作功能。
- 按原计划交付了，甚至比原计划要提早3天交付
- 用户量也是基本达到目标（计划：100，实际：92）
和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
- 质量明显提高了，主要在以下几个方面体现：
- 在代码更新时说明（commit）和PR、issue等信息上有了重大进步，开发者对自己已完成和待完成的工作更加明确了（有github的ISSUE记录以及石墨文档的工作安排记录），同时PM也能通过commit记录/issue和PR记录等更方便地了解项目的实际进展了。
- 测试方面，我们每周都会安排一个时间点（周日）将这一周完成的所有功能打包并发布到服务器上进行实际测试
- 代码质量方面：统一使用Vscode自带的格式化工具进行格式化处理
- 功能质量方面：明显提高，在测试阶段发现的bug数量比alpha阶段少很多
用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
- 基本一致
- 从用户反馈来看，用户对重要功能的接收程度和我们事先的预想基本一致，我们也的确满足了用户的需求，无论是UI设计还是功能的丰富性，都得到了用户的好评，相比于alpha阶段，我们离最初定下的线上便捷ide的目标更加接近。
- 离我们目标更近了，在Beta阶段实现了Debug功能，完善了IDE页面各种UI以及功能，在实际使用上更像一个IDE了
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
- 现在的需求分析都是组内6人开会讨论出来的，可能存在脱离普通用户的情况。如果再来一次，我们可能会使用调查问卷等方式研究普通/专业/入门用户等不同用户的实际需求和意见。
- 关于邮箱验证方面，我们使用的发送验证码的邮箱会被部分邮箱认定为垃圾邮件进行屏蔽。插件的使用人数也没有达到预期。如果重来一遍，我们会提前调研好邮箱验证可能会遇到的麻烦，并且大力推广插件。
- 产品推广时机不好。如果重来，会提早进行产品的推广，尽早将用户吸引到我们的产品上来。
- （alpha阶段的经验）在不熟悉一门技术的前提下，对完成功能和完成所需时间进行估计不太现实。有一些功能实现起来比想象中困难，有一些功能没能找到最合适的解决方案。如果能再来一次，我会尝试尽量找到有丰富前端经验的人询问清楚。
计划
是否有充足的时间来做计划?
- 有足够的时间进行计划。小组讨论了很长时间来决定产品要实现哪些功能，并给不同功能的实现划分到了不同的阶段。
- 在Alpha阶段开始前，小组共召开了4次组会讨论项目的详细细节，并且在计划时间结束前完成了整个Alpha的规划
- 在Beta阶段开始前，小组共召开了2次组会讨论Beta阶段新增功能的具体细节，以及要修缮的各种功能。
团队在计划阶段是如何解决同事们对于计划的不同意见的？
- 对于不同的意见，首先是一起讨论后进行投票决定；若不同意见分歧比较大，会让大家去做好调研工作后开一次研讨会，再进行一次深入讨论投票。
你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
- 基本上都完成了。有个编辑器下拉菜单被遮挡的问题到了最后也没有解决，主要是因为该问题对功能的正常使用影响非常小，因此优先去开发了新功能，对该问题进行了搁置，其次一些通用解决方法经过尝试并没有成功解决此问题，最终作罢。
- 没有解决的都是一些不影响全局的小bug，并且难以发现的bug。在事后我们还会慢慢进行解决
有没有发现你做了一些事后看来没必要或没多大价值的事?
- 前端方面：在完成主题切换时，重构了许多次css样式及其改变的控制方法，主要是由于对iview组件以及vue模块的技术不是很熟悉，网上资料的解决方法也都七零八碎，因此踩了很多坑走了许多弯路，最终我们也将解决方法进行整理作为技术博客发布。
- 而且部署版本与开发版本样式不统一，最初在开发版本上调整好的样式发现部署时不生效，又得重新调整，浪费了一些时间
- 后端方面：Beta阶段工作都进展的很顺利，没有价值不大的事情。
是否每一项任务都有清楚定义和衡量的交付件?
在前期计划阶段，对于每一个功能的实现，没有清楚定义和衡量的交付件，但实际操作时影响不大。
- 首先大部分功能都不是新发明的功能，因此开发者对该功能有自己的合理预期（如和其他产品或自己使用过某产品的体验类似）。
- 这样，若代码达到了预期功能则进行交付。虽然没有明确书面定义交付件，但PM和开发者和用户对该功能的理解几乎相同。若代码基本完成了预期功能但尚有bug/缺陷/未完成细节，我们将当前issue关闭、开启一个新的issue解决该问题。在开启新issue时，自然会对需要提高和维护的内容进行自我梳理和明确。
- 因此虽然没有明确定义的交付件，但交付标准是团队的共识和常识，因此对我们的产品开发过程来说不是问题。
在后期的每个人开发阶段，每个人对自己的任务进行细化，几乎每个任务都有清楚的定义和衡量的交付件。涉及到自己的部分和其他人负责的部分交互的时候，就需要清楚定义每个部分实现的功能以及传递的信息，需要做到封装完善，没有bug 才会交付。
在alpha阶段的基础上，beta阶段需要修复的遗留bug和需要实现的每个新功能都非常明确。比如说，前端的遗留bug都很细碎且数量多，只凭各人想到有什么就修什么，不能高效地全覆盖所有bug，而且修复的粒度过细、可能并不适宜用常规issue来管理。因此我们花费了一些时间将遗留bug拆分成多个独立的条目，并记录在共享文档中，前端团队的每个成员都及时认领，并在解决问题后在共享文档中标记已完成，这样就能够清晰地把握进度。
是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
- 大部分任务基本按计划进行，除了部分任务与预计计划有些许偏差：
- 对于浏览器插件的审核和发布机制把握得不好，导致最终浏览器插件没有很好的对外推广。因为浏览器插件项目的开发工作启动较晚，启动时基本没有额外时间处理这方面的问题了。
- 前端部分的意外主要是部署版本和开发版本样式不统一导致样式需要反复调整。
在计划中有没有留下缓冲区，缓冲区有作用么? 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
- 计划初期有缓冲区，对于每一个阶段安排了最后一天进行上机对接测试;在整个项目完成后，安排了3天时间进行对接测试
- 前期缓冲区作用：提前做好对接工作，不至于后续对接时手忙脚乱
- 后期缓冲区作用：提前部署，做好测试准备
- 但是实际上与计划并不一致。我们将Beta阶段分为时间几乎均等的两个子阶段。但操作中第一个子阶段用了超过一半的时间才结束，第二个子阶段只用了不到一半的时间就完成了。其原因是对任务的估计和分解不准确，导致部分同学在第一个阶段就在做第二个阶段涉及功能的支持了，相当于将部分内容从二阶段迁移到了一阶段，导致看起来一阶段拖延了工期，但实际上在第一阶段已经超额完成了大部分功能。
- 因此整个Beta阶段在最后预留下的缓冲区比计划的要多。
- 因此应该的改进是： 1. 进一步细分和明确任务 2. 准确估计任务所需时间 3. 显式地留出缓冲区和绝对意义的DDL，避免存在拖延DDL的心理（缓冲区前为软DDL，实在没完成可以拖延至缓冲区，但缓冲区后为硬性DDL）。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
就上面所提的出现的风险来说，“具体规划”这件事不能在一开始定得太死，导致后期大修大改，也不能开始得太晚导致拖延进度。又或者说，也许没有必要在前一个任务完全完成后才开始下一个任务的规划。提早规划，可以让已经完成前一个任务的空闲工作力投入到下一阶段中。计划中最好进一步细分和明确任务，准确估计任务时间，以便对后续时间做更好的评估。
资源
我们有足够的资源来完成各项任务么?
- 劳动力资源：基本足够，但感觉如果多一名擅长美工设计的人员会更好？
- 前端部分学习资源：
- 基本足够，有官方文档，官方教程，官方论坛辅助debug
- 代码资源如组件模块之类的，基本上不需要重复造轮子，有现成的组件和框架。
- 前端部分也不需要什么硬件资源。
- 后端资源：
- 就目前用户量而言，资源基本足够，因为并发度并不高
- 如果要做更大的推广，则需要更强大的后端服务器，因为该项目本身后端就很吃资源
- 另外邮箱资源是个问题，没有一个被信任的邮箱，整天被拦截。
各项任务所需的时间和其他资源是如何估计的，精度如何?
- 修复bug方面，会根据此bug的难度预估一定的时间；新功能方面，会首先进行功能技术实现的调研，然后根据难易程度进行时间上的估计。
- 精度基本准确
测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
- 由于我们前端是边开发边部署进行回归和集成测试，每个人完成一个新功能自测后，都会通知团队其他人，再各自测试使用，因此测试方面比较充足，bug也能及时发现。
- 美工的确低估了难度，比如在完成主题切换、美化样式时低估了需要花费的时间，最终总的实现时间比预估要长一些。
你有没有感到你做的事情可以让别人来做（更有效率）?
- 没有。由于功能划分足够细致，每个人都各有专攻，人尽其用。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
- 如果重来一遍，一定要好好衡量好后端资源需求，及时申请配置更加强大的后端服务器。
变更管理
每个相关的员工都及时知道了变更的消息?
- 由于我们基本上是每天一例会，团队有了什么新想法、新问题也都会在群里及时交流，因此都是及时知道的。
- 后端遇到问题会两个人及时交流，一般没有一拖一整周的情况
我们采用了什么办法决定“推迟”和“必须实现”的功能?
- 根据NABCD模型和项目功能四象限的划分，如果遇到特别难以解决的问题，会开会讨论，根据其重要性决定是否继续在上面花费时间，比如前端编辑器右键菜单遮挡问题难以解决，且不影响正常功能的使用，就将其推迟，先开发“杀手功能”。
- 在石墨文档上记录待办事项，在备注栏注明事项的紧急程度
- 在github的ISSUE上新增标签，注明事项重要程度
项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
- 有，功能完善，单元测试通过，UI美观就是出口条件
对于可能的变更是否能制定应急计划?
- 能，我们小组每个人基本都负责对应的具体领域，另外也有中间人即做前端也弄后端。
- 如果那个部分由突发情况无法按时交付，可以让中间人帮忙。
员工是否能够有效地处理意料之外的工作请求？
- 能，我们小组的所有成员能力都很强，都能按时完成自己的任务，那处理意外任务更是绰绰有余。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 可能会尝试在项目开始时就完全决定好样式设计。其实最初的计划也是这样的，但是由于种种原因没能坚决执行。如果能够再来一次，可能会定死在第一阶段坚决完成，并且约定之后不再进行大的变动。
- 没有什么经验教训，如果重来一遍，我们还会按照当前的流程顺利完成任务。
设计/实现
设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
- 设计工作在正式开发之前
- 是PM发起，团队一起讨论决定的设计方案。
- 是合适的时间：大家都充分阅读了用户反馈，并对项目的下一步走向进行了分析和思考。
- 是合适的人：PM领头，团队共同讨论。
- 我们是在开发阶段的前若干天以集体讨论的形式完成的，但效果并不好，原因一是不同人有自己的不同的想法和风格，有的人喜欢各抒己见，有的人却不喜欢提出新点子也不喜欢对方案表达明确的喜恶，导致团队难以民主地决定一个具体的方向和方案。其实应该通过用户调查的方式来确定，但我们没有，我们六人闭门造车却意见不同，才导致这种情况发生。另一个原因是设计和思考需要时间，我们不应该指望在一次会议中将目标完全定下来，应当先让各自提前思考，再一起头脑风暴，最后讨论充分后进行决定。设计和计划占一个星期的时间不是没有道理，我们应当好好利用的。
设计工作有没有碰到模棱两可的情况，团队是如何解决的？
- 有。先大致规划方向，交由负责的小组具体讨论。
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
- 有运用单元测试，前后端均有
- 具有一定效果，能够帮我们排除一部分bug
- 有区别，区别在于开发进行过程中发现一部分接口并不能很好的实现预想的目标，需要修改或新增接口。
什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
- 美化样式方面的bug最多。由于对iview组件和前端框架的不熟悉导致的，而且开发版本与部署版本样式不统一，一开始没能发现。
- 发布之后发现的重要bug：重名项目的重名文件会由于vue生命周期而出现内容保留的问题。开发的时候考虑到了同一项目的重名文件问题，但没有考虑和测试周全，以为同一项目的问题解决了，不同项目也就没问题了。是关于生命周期的bug，发生这些状况的主要原因还是前端开发经验不足、不能完善地考虑各种问题。
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
- 最开始是在每日例会上，由大家共同检查没问题后，才进行代码的签入。
- 后来发现了github的review提醒功能，引入该功能，每次有人想要签入代码时，提醒相关人员进行代码复审，没问题后才同意签入，提高了不少效率。
- 我们有严格的开发流程和代码规范规定（PR流程），大家都在严格执行。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 测试十分重要，如果重来，会采用其他比如测试驱动开发等开发模式，让测试更规范。
- 开发流程非常重要，如果重来，我们会依旧采用我们流畅的PR流程
- 设计过程非常重要，如果重来，我们会重新认真考虑用户需求，真实的去采访用户询问他们真正的需求，而不是单纯几个人在构思。
测试/发布
团队是否有一个测试计划？为什么没有？
- 有测试计划，安排每周一天将当前已完成的版本打包发布测试
- 在最后一周的测试中，有一位同学专门进行一次压力测试，测试并发情况；另外的同学分别对自己写的部分进行单元测试
是否进行了正式的验收测试？
- 有进行验收测试，详见测试报告
团队是否有测试工具来帮助测试？
- 有
- 后端使用SpringBoot的单元测试框架，以及nodejs的单元测试框架
- 另外也有使用Jmeter进行压力测试
团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
- 通过JMETER定制测试，采用多线程模拟多用户进行压力测试。
- 有用，通过压力测试发现了前端的性能问题，从而进一步采取了相应的对策解决了前端性能问题
- 例如前端后续就进行了cdn优化以及gzip优化，再次进行测试后前端加载速度提高了近3倍
在发布的过程中发现了哪些意外问题？
- 没有意外
我们学到了什么? 如果重来一遍, 我们会做什么改进?
- 测试一定要使用好框架，开发一定要定好流程，这样效率很高并且bug率很低。
团队的角色，管理，合作
团队的每个角色是如何确定的，是不是人尽其才？
-
角色是按照先报名后分配的方式确定的，有明确角色意愿的同学首先被满足，没有明确方向的同学补上剩下的岗位。
-
在Alpha阶段的学习和历练之后，每个同学由于自己的分工（开发流程中的分工、实现功能不同的分工……）不同，使得每个人都成为了某领域独一无二的“专家”。因此在团队合作中，经常有涉及到其他同学所精通领域的时候，我们都会主动与对应的同学沟通请教，让专业的人做专业的事，不仅做到了人尽其才更提高了工作效率。
团队成员之间有互相帮助么？
- 有，前端组员会互相交流共性问题的解决方案；如果一人的任务出现了暂时难以解决的问题，其他已经完成自己任务的团队成员会主动认领新任务、保证项目顺利推进。
- 后端两位组员会积极讨论，共同解决出现的各种问题
当出现项目管理、合作方面的问题时，团队成员如何解决问题？
- 一定要积极沟通，不要怕问“弱智问题”可能导致的尴尬。
- 积极沟通才能了解对方在干什么，规划好自己要干什么，共同完成同一功能
每个成员明确公开地表示对成员帮助的感谢
| 成员 | 感谢信 |
|---|---|
| 李PX | 我感谢韩WZ对我的帮助，因为他积极和我探讨后端各种优化的方法 我感谢向WL对我的帮助，因为他总能提出一些令人意想不到的想法，帮助我们更好的解决问题 我感谢田ZJ对我的帮助，因为他总能在我们遇到bug的时候，提出修复方案，帮助我们修复bug 我感谢韩FJ对我的帮助，因为耗费大量精力完成了很牛逼的文件树拖拽功能，帮助团队省下了很多美化工作 我感谢万ZF对我的帮助，因为每一次对接时只要说一遍万ZF就能理解，而且能快速完成对接任务 |
| 田ZJ | 我感谢李PX对我的帮助， 因为他邀请我进入这个新的充满活力的团队，在熟悉项目方面有什么疑问，他也都积极帮我解答，也和我一起讨论terminal相关模块的实现和设计，帮我发现了一些bug，还帮我复审了代码。 我感谢向WL对我的帮助，因为他协助我完成了debug的功能实现并帮我测试出了一些bug，在美化样式方面也提出了一些很好的建议和帮助，教我如何在本地进行build版本的测试。 我感谢韩FJ对我的帮助，因为她跟我一同讨论iview组件样式覆盖的问题，帮我熟悉文件树部分的代码逻辑，帮我复审过代码，共同完成草稿纸页面的实现。 我感谢万ZF对我的帮助，因为他帮我熟悉了登陆注册部分的代码逻辑，共同完成了草稿纸页面的实现。 我感谢韩WZ对我的帮助，因为他在团队会议上帮我讲解了后端的实现逻辑，让我对整个项目实现有总体上的把握，还帮我进行了docker的完善支持了gdb等功能，对项目功能的规划也非常积极热心地提出了许多好的建议。 |
| 韩WZ | 我感谢李PX对我的帮助，因为他帮助我对后端项目的质量进行把控，提出了很多不错的建议 |
| 向WL | 我感谢李PX对我的帮助，因为遇到bug经常能耐心听我小黄鸭式debug，聪明的大脑也能很快想到问题所在；同时团队内有一些工作也会主动包揽，减轻了其他同学的负担。 |
| 韩FJ | 我感谢李PX对我的帮助，因为某个具体的事情: 为前端提供清晰的接口文档；完成前端待解决任务文档，push效果显著 我感谢万ZF对我的帮助，因为某个具体的事情: 共同完成了文件树的许多新功能；完成菜单栏代码的编写，为我完成草稿纸菜单栏提供了很好的参考 我感谢田ZJ对我的帮助，因为某个具体的事情: 解决了许多第一阶段前端遗留的bug，对项目质量的提高帮助极大 我感谢向WL对我的帮助，因为某个具体的事情: 高效明确地完成前端为了实现新功能对编辑器的提出的新需求 |
| 万ZF | 我感谢李PX对我的帮助，因为某个具体的事情：替我解决了文件上传的bug 我感谢田ZJ对我的帮助，因为某个具体的事情：帮我解决了某些组件主题切换的bug 我感谢韩WZ对我的帮助，因为某个具体的事情：和我积极交流了账号邮箱绑定的新想法 |
总结
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
- 第三档
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
- 我认为已经做到了“规范”，进入了“创造”阶段
- 其中一部分原因是团队确实有很好的规范和习惯，从项目管理到团队合作都已经过了磨合和规范期的不稳定。但更大一部分原因是团队内部对于软件工程方法论的依赖程度并不高，大家都是以工程师的心态进行合作，不需要过多的条条框框进行约束和额外规范，相互的帮助和协作成为了工程师文化的一部分、是优秀的习惯，因此目标、规范与习惯、计划等都较为一致，难以产生大的矛盾，注意力主要都集中在产品和开发本身上。
你觉得团队在这个里程碑相比前一个里程碑有什么改进?
- 有了更加规范的开发流程和统一的代码规范
- 团队的活力更强了，大家的投入度更高，配合更加默契，每个人对于自己以及团队的工作进度都能够有比较全面的把握。
你觉得目前最需要改进的一个方面是什么?
- 项目推广方面需要加大力度
- 尽管和上一阶段相比更有活力了，但还是感觉团队比较严肃，虽然在问题上大家很活跃，但是团队整体氛围还是十分严肃的。
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
- 高效的每日例会：每日例会上高效的进行工作汇报以及交流讨论
- 最小功能集开发：遇到棘手的、不影响功能的问题，及时将其移出正常的开发流程，之后再解决，以免被卡住进度
- 代码管理：善用github。
- 业务人员和开发人员必须相互合作。我们团队的所有成员都是开发成员，也都会参与到功能性的设计中
- 经常地交付可工作的软件。在alpha阶段中一切工作以努力完成一个可用的IDE为目标。在beta阶段，将工作划分为多个新任务，往往在前一个任务完全结束后才开启下一个，基本没有遗留问题。
正如我们前面提到的， 软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提高软件工程的质量呢？
- 进一步加强测试方面的工作，真正实现测试驱动开发。
代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？
- 继续严格执行定好的代码规范，代码复审要更加仔细，复审时开发人员和复审人员同时在场。
整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？
- 通过对代码模块进一步解耦、模块进一步细分来提高代码质量，代码的拓展性可以衡量质量的提高。
其它软件工具的应用，应该如何提高？
- 前端jest单元测试工具的使用需要进一步落实，保证前端也能做到所有代码的高覆盖率。
项目管理有哪些具体的提高？
- 引入了一套标准化的开发流程。具体见github，contibute.md文件
项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？
- 通过管理数据库的用户信息、登录服务器查看访问量来知道每日/周活跃用户等数据
项目文档的质量如何提高？
- 约束文档撰写规范，保证文档的使用者能很清楚的明确含义
对于人的领导和管理， 有什么具体可以改进的地方？ 请看《构建之法》关于PM、绩效考核的章节， 或者 《人件》等参考书
-
对于鼓舞团队士气、凝聚团队人心的工作明显不足。如果说Alpha阶段的主要动力来自于对功能目标的追求、对新鲜事物的兴趣、对完成项目的野心，在Beta阶段团队的主要动力就是持续工作开发新功能的惯性、和每日例会自己不能摸鱼的基本心理。在团队动力不足的时候，作为PM应当使用向团队展示项目进度 / 预发布项目并收集用户积极反馈等手段，推动团队继续前进并提振士气。
-
拥有一个明确可达的目标也是重要的手段之一，在Alpha阶段PM做出了详细且可信的功能规格说明书，从而让大家有明确的目标努力。然而在Beta阶段PM并没有给出像Alpha阶段一样的功能规格说明书和技术规格说明书，使得团队成员的目标只是口头描述的样子，可信程度和明确程度都不高，心理上难免产生摸鱼的动摇（如典型的“到时候再说”）。
对于软件工程的理论，规律有什么心得体会或不同意见？ 请看阅读作业。 (这个作业的期中阅读)
- 团队会议的确能够提高团队开发效率，鞭策队伍不要拖延。
