【BUAA软工】Beta阶段过后分析

设想与目标

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

• 解决的问题
  • 整体解决的问题：新手编程者配置编程环境难、本地编写的代码跨设备同步难、本地ide安装使用过程繁琐等问题
  • alpha阶段解决的问题：基本项目的建立，自动补全，编译运行
  • beta阶段新增：
    • 随手写简单代码、项目多人合做中的分享和协做开发
    • 美化功能，让使用者感受更加赏心悦目。
    • 进一步解决软件启动速度问题。
• 定义是否清楚：
  • 定义的很清楚，可参见以往博客设计与规化：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阶段同样的功能规格说明书和技术规格说明书，使得团队成员的目标只是口头描述的样子，可信程度和明确程度都不高，心理上不免产生摸鱼的动摇（如典型的“到时候再说”）。

对于软件工程的理论，规律有什么心得体会或不一样意见？ 请看阅读做业。 (这个做业的期中阅读)

• 团队会议的确可以提升团队开发效率，鞭策队伍不要拖延。