Frontend 事后诸葛亮
设想和目标
我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的软件想降低编程语言入门者的障碍，主要在于消除编程入门者对报错提示的恐惧，以及根据其水平为其推荐合适的题目。事实上在 alpha 阶段前我们对这个需求并不是很明确，对需求的了解也是在 alpha 阶段完成过程中慢慢清晰起来的。
我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
基本完成了alpha阶段前预期的功能，且按原计划时间交付。
和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
没有上一个阶段。
用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
alpha 阶段以最小可用功能为目标，暂时不考虑用户量。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
开发过程中不同组的交流是很重要的一个环节。在前期我们三个组的开发过程其实是处于一种相对隔离的状态，导致我们对需求的了解有些偏差，以及没能非常及时地了解新的需求变更，导致后期时间比较紧张。重来一遍的话我们会更加重视这一点。
计划
是否有充足的时间来做计划?
其实在本次 alpha 阶段中我们并没有花很多时间来做计划，主要是刚开始时对需求仅有一个模糊的把握，同时觉得前端并没有特别大的工作量。但后来发现有一个明确的计划对于工作的推进还是很有必要的。
团队在计划阶段是如何解决同事们对于计划的不同意见的？
我们前端组讨论计划时少有出现意见不一致的地方，主要是大多数成员对前端的开发流程不太熟悉。我们对于计划或需求的困惑或不同意主要来自和其他组协作/协商的时候，这时我们会根据双方的具体情况（实现难度等）做出合理的选择。
你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
都完成了。
有没有发现你做了一些事后看来没必要或没多大价值的事?
一开始我们选用 Vuex 做状态管理，但后来我们发现 Vuex 对于我们这个项目没有太大的帮助，遂摒弃了它。
是否每一项任务都有清楚定义和衡量的交付件?
前期计划中是有的。但在 alpha 阶段后期发生了一次比较大的需求变更，为了快速完成功能我们便没有将后期一些任务记录下来。
是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
项目的一个意外是中途出现的需求变更，当时离 alpha sprint 截止只有三天了，这主要是我们没有和其他组很好地交流导致的。alpha 阶段没有出现意料之外的风险，前期预估的一些风险如组员因赶会议无法抽出时间工作等虽然出现了，但并没有造成很大影响。
在计划中有没有留下缓冲区，缓冲区有作用么?
我们没有设置缓冲区。事实上我们觉得此次alpha阶段后期对接时出现了许多细小的问题，时间有点紧张，缓冲区的设置是有必要的。
将来的计划会做什么修改？
beta 阶段开始时我们应该有更明确的需求，并根据需求将任务分成耦合度低的子任务以方便并行开发。同时应该预留一两天的缓冲期，以避免突发情况。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
alpha 阶段让我们意识到团队成员交流的重要性。不管是组内或是组间的交流都是很重要的。同时交流时需要有良好的记录，一方面可以避免任何一方的理解出现偏差，另一方面方便事后回顾。
资源
我们有足够的资源来完成各项任务么?
前端组的开发不需要很昂贵资源，至于从整个团队看，我们有服务器硬件资源，时间资源也算是充足的。
各项任务所需的时间和其他资源是如何估计的，精度如何?
一开始时任务需要的时间也只是给出一个上界，毕竟不知道在开发过程中会遇到什么突发的问题。
测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
最终测试的时间稍微有点长，但还在预期内。前端组虽然人少，且有同学在 alpha 阶段有其他任务，但在开发前我们考虑到了这些因素，所以人手也算足够。alpha阶段由于不追求特别美观，所以没有在美工设计等方面花费太多时间。
变更管理
每个相关的员工都及时知道了变更的消息?
对于大的变更我们会在每天的scrum同步，每个同学如果有和其他同学工作相关的变更会在teams群中更新，以让对方及时知晓。
我们采用了什么办法决定“推迟”和“必须实现”的功能?
在 alpha 阶段开始前就决定做 MVP，因此在确定需求时就商量好了这两点。
目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
好像没有清晰的定义，我们是以完成“必须实现”的功能作为 alpha 阶段的目标的。
对于可能的变更是否能制定应急计划?
在离 alpha sprint 还有三天时我们获知了一些需求上的变更。对此我们及时召开会议并重新制定计划，分配任务，处理得较为妥当。
员工是否能够有效地处理意料之外的工作请求？
一般来说遇到意料之外得工作请求或状况，我们组内都由经验较为丰富的成员来解决，以最大程度地节省时间。
设计/实现
设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
alpha 阶段前端暂不考虑界面特别美观，因此所谓设计更多是基本架构的确定。此工作由组长在 alpha sprint 开始之前来完成。组长之前有过相关经验，因此是合适的人选。
设计工作有没有碰到模棱两可的情况，团队是如何解决的？
遇到模棱两可时多半是我们组和别的组的理解产生了不一致的地方，对此我们鼓励相关同学积极交流以达成一致。
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
我们没有做单元测试，主要是因为前端的单元测试不是特别 trivial，为了节省学习时间便暂时不做了。开发时我们的测试基本靠手动，以当前的功能来看尚不算特别麻烦。
什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
编辑器的部分，因为这是整个产品中逻辑最复杂的一块。发布时我们发现我们的产品对不同浏览器的兼容性不是很好，对此我们也有预料在先，但由于 alpha 阶段只做 MVP，所以这不算很大的问题。
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
没有做太多的 code review，主要是时间不足。我们用 Linter 保证代码规范。
测试/发布
团队是否有一个测试计划？为什么没有？
团队在 alpha 阶段开始前便确定了 alpha sprint 最后两三天为整体联调的时间。
是否进行了正式的验收测试？
没有正式验收。
团队是否有测试工具来帮助测试？
前端没有使用单元测试。
团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
没有相关措施。
在发布的过程中发现了哪些意外问题？
联调过程中发现编辑器总有一些意想不到的问题（用户可以以特殊的方式突破限制，现有限制影响了用户体验等等）。
团队的角色，管理，合作
团队的每个角色是如何确定的，是不是人尽其才？
团队的角色根据大家对前端开发的认识和经验以及自身时间安排来确定的，基本做到人尽其才。
团队成员之间有互相帮助么？
当经验少的成员遇到问题时，经验丰富的成员常常会帮一把手。
当出现项目管理、合作方面的问题时，团队成员如何解决问题？
找 leader 讨论，并由 leader 最终确定。
总结
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
你觉得团队在这个里程碑相比前一个里程碑有什么改进?
你觉得目前最需要改进的一个方面是什么?
代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？
代码管理的质量需要大家都遵守制定好的 workflow，如使用 PR 合并更新等等。代码规范需要项目的初始化者参考相关的最佳实践（借鉴但不盲从），同时利用相关工具如 Linter 保证提交代码的质量。目前尚没有完善的代码复审的制度，这要求整个团队养成相应的习惯。
整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？
目前 alpha 阶段以快速实现为主要目标，许多地方没有遵循 Vue.js 的最佳实践，同时有些地方写得比较 hacky。我们也许可以参考 github 上优秀的项目来做重构工作。
其它软件工具的应用，应该如何提高？
阅读官方文档是最快也是弯路最少的办法，许多工具的 tutorials/guide 很值得初学者一读。
项目管理有哪些具体的提高？
alpha sprint 后发现及时的交流能减少开发过程中遇到的问题。scrum meeting 是一种很好的而形式。
项目文档的质量如何提高？
可以借助共享写作平台同步文档，当然如果有可能的话，使用相关工具实现 code to doc 是更高效的方式。
对于人的领导和管理， 有什么具体可以改进的地方？ 请看《构建之法》关于PM、绩效考核的章节， 或者 《人件》等参考书
对于软件工程的理论，规律有什么心得体会或不同意见？
