Alpha阶段事后分析
Alpha阶段事后分析
| 项目 | |
|---|---|
| 这个作业属于哪个课程 | https://bbs.csdn.net/forums/buaa-ase2023?typeId=2469180 |
| 这个作业的要求在哪里 | https://bbs.csdn.net/topics/613598303 |
| 我们在这个课程的目标是 | 学习并实践软件工程开发的方法论。在把握整体流程和内容要素的基础上实践细节，培养开发技术、开发思维、团队协作等能力。 |
| 这个作业在哪个具体方面帮助我们实现目标 | Alpha阶段事后的Postmortem，总结和反思之前的优点和不足，为下一阶段的冲刺做准备 |
一、设想和目标
我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
BUAAMapForum致于为BUAA的同学们提供详细的、可视化的、可交互的、丰富的BUAA地图浏览功能，并且为同学们提供交流讨论学校的内容和设施的平台。主要功能点描述如下：
-
BUAAMapForum拥有登录注册全流程，并且支持邮箱验证
-
在地图上进行标记，以钉子（Pin）的形式展示北航学院路校区的各种不同的点位，并且对点位加入详细信息描述（如Tag、位置描述等），插入图片
-
用户和管理员可以以不同的权限钉子进行增删改查，并且可以进行钉子的高级操作，如反馈钉子信息、公开私人的钉子等
-
论坛全流程。用户在论坛中以Tag和Pin为维度进行讨论，并且可以实现论坛的维护和管理。
详细的功能描述、典型用户和典型场景在功能规格说明书中进行了描述，并且在本阶段已经能够满足一部分的场景需求。
我们达到目标了么？
在功能规格说明书V1.0中，我们定义了Alpha阶段需要完成的任务，并且在Alpha阶段项目展中对功能进行了验收研判，完成了所有Alpha阶段规定的任务，并且完成了一些额外的功能；除此之外，我们还完成了多方面的测试。
在推广的阶段，我们在统计时间内的日活跃量达到了170左右，这超过了我们100的预期；不过注册用户只有50左右，究其原因，是因为我们目前开发的核心功不需要登录注册就可以体验。总体来讲，我们在本阶段达到了大部分的目标。
用户量，用户对重要功能的接受程度和我们事先的预想一致么？我们离目标更近了么？
事实上，大部分用户对于地图功能的体验反馈都是比较满意的（当然，也提出了不少改进意见）。不过需要注意的是，在下一阶段，我们将开发论坛功能，而在Alpha阶段我们的注册量并不多，如何破解这一潜在的隐患，是我们需要考虑的问题。
有什么经验教训？如果历史重来一遍，我们会做什么改进？
-
作为一个团队，一定要多沟通、提前沟通。在Alpha阶段的几天，我们的团队沟通并不多，开发的效率也一般（可以从燃尽图看出）；随着开发深入，我们的交流变得多了起来，同学们相互帮助解决问题，这大大加快了我们的开发效率。而提前沟通能够帮助我们预先想好解决方案，不至于在开发时候被小问题“绊倒”
-
安全性设计不足。在Alpha阶段当中，我们遇到了不少安全性问题，包括前后端同学不小心在文档中泄露了密钥或Token、未关闭Vue Map Source泄露了源代码等等。PM需要加强前后端成员的安全性意识，保证团队资源的安全。
-
可以更好地准备一些宣发的资料，包括介绍视频、海报、文档网站等等。本阶段我们的宣发方式过于单一，虽然效果不错，但是好的宣发方式或许能够让我们的网站流量“更上一层楼”
二、计划
是否有充足的时间来做计划？
我们在本阶段为计划预留的时间稍微有些紧张，主要的原因是大家计网实验的时间分布的比较零散，到周末才有时间聚到一起进行讨论。当然，由于我们Alpha阶段的核心功能比较明确，流程链也不算长，这一失误只在我们开发的前两三天造成了轻微的影响。
团队在计划阶段是如何解决同事们对于计划的不同意见的？
当团队成员在关键问题上产生分歧的时候，大家可以自由的发表意见。如果在潜移默化中出现了分歧场景，那么PM会维护秩序，保证每一位有想法的同学都能“说上话”。当想说话的同学都说完之后，我们会针对每一个方案进行讨论，并且表决哪一个方案到底是最好的。
但需要注意的是，我们没有时间充分讨论并解决每一个问题。在关键的讨论中，当某个问题花费了过长的讨论时间时，或者这个问题本身并不值得“激烈的讨论”，那么PM就会及时打住，选择一个可行（未必是最优）的方案，继续之后的讨论。
原计划的工作是否最后都做完了? 如果有没做完的，为什么？
我们Alpha阶段计划的任务都完成了。
需要注意的是，我们在开发过程中，发现某些计划好的任务并不一定是最理想的，因此我们也对各项任务进行了灵活的调整。另外，我们发现当任务拆分的比较细的时候，一些“关键节点”对于开发整体进度的影响变小了。
有没有发现你做了一些事后看来没必要或没多大价值的事？
在事后分析过程中，经过评估，我们认为导航栏设计需要进行更换。开发的同学没有采用组件化的设计，导致导航栏的构建“不符合规范”。从结果来看，之前的工作似乎失去了意义；但是我们不否认之前搭建导航栏的同学的工作，因为如果我们要完成Alpha阶段所有的功能，导航栏是不可或缺的。
是否每一项任务都有清楚定义和衡量的交付件？
在项目刚开始的时候，我们的验收标准显得有些模糊。老师提醒我们，我们的验收标准可以更加明确，因此我们在开发的过程中调整了验收标准。
验收的时候，我们根据每一个模块的功能和测试结果进行评估，如果产品通过了功能性测试，并且通过了必要的评估性测试（如API测试、压力测试等），那么模块就可以通过验收。
当然，根据老师和其他组成员的评审意见，我们如果能够在验收的过程中加入单元测试是更好的，这一点会在Beta阶段提上日程。
是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到？
需要开发的功能在DDL时间都完成了。助教给出的评价是项目管理有一些不尽人意，这主要是由于前期遇到了学习上技术难题，花费了一些学习时间。事实上，这是可以预估到的风险，但是根据实事求是的原则不得不展示在燃尽图中。
项目中途出现了一次比较大的意外，即在域名备案是在发布时间前后完成的。在配置SLL证书时，发现api请求的写法和https请求不适配。我们花费大概半天的时间修复这一问题，期间我们的产品虽然发布了，但是仍旧处于不可用的状态。这一意外是由于对域名配置不了解导致的（事实上，我们团队的成员都是第一次接触域名备案）。
在计划中有没有留下缓冲区，缓冲区有作用么？
有，缓冲区主要在第一周，我们预估到某些技术可能需要一定的时间进行学习，并口头通知了团队成员，在第一周PM并没有狠狠Push大家。事实上，虽然大家第一周并没有解决很多的issue，但是解决了很多技术性的问题，尽管前期的燃尽图看起来有些捉襟见肘，但是我相信这一缓冲区对于项目的长期开发是有好处的。
将来的计划会做什么修改？
-
任务计划：在Beta阶段，我们的功能计划可能需要进一步的细分，以便于把控团队进度；同时，我们也要在一定程度上修改团队分工，使得团队成员能够做自己较为擅长的事情。另外，我们在计划的过程中需要加入定期的单元测试，并且需要定期复审代码。
-
开发计划：我们计划加入更加频繁的线下协作开发，学期后半段大家其他课程任务的压力会有所降低。当然，不要求所有成员都要到场，因为大家在Beta阶段的冲刺周期需要准备jwsy考试。
-
文档计划：在Alpha阶段，我们撰写了一些后端相关的技术文档，并且发布在了CSDN上。我们希望能够在Beta阶段撰写更多的文档，以记录我们在开发过程中学到的东西。
-
测试计划：我们的多方位测试计划制定的比较晚，是在敏捷阶段快要结束的时候规划的（安全测试、压力测试等）。在Beta阶段，我们可以尝试根据Alpha阶段的经验提前制定全面的测试计划。
-
计划留档：各项计划尽可能留档，方便做后期的审计。目前来看，我们的任务计划、开发计划和文档计划都有在Notion中留档；需要在Notion中补充测试计划的文档。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
-
计划一定要提前制定、详细制定
-
计划的严格执行和制定良好的计划同样重要
-
计划需要留档，便于后期的评审和反思
-
执行计划的过程中，要在坚持核心任务的基础上灵活调整
三、资源
我们有足够的资源来完成各项任务么？
我们在Alpha阶段成功完成了任务，尽管还有不尽人意的地方，或者是可以提高的地方，但这表明我们有能力完成任务。
埃杰团队的每一位成员都有许多自己的事情需要操心，PM很感激大家愿意为团队付出时间和精力。
各项任务所需的时间和其他资源是如何估计的，精度如何？
在开始冲刺之前，我们对时间的估计有限的开发经验（相信在流程完善的企业当中，基于市场统计和分析和丰富的开发经验，对于时间的评估会更加准确）；除此之外，我们也评估了一些其他资源可能产生的开销，包括金钱（在网络上查看价格）、场地（校内场地）等等。
对于任务耗时的估计，颗粒度在小时级。不过在开发的过程中，我们对任务也有灵活的划分。
测试的时间，人力和软件/硬件资源是否足够？对于那些不需要编程的资源 (美工设计/文案)是否低估难度？
按照指定的测试方案，我们顺利的完成了Alpha阶段的测试，没有出现“资源短缺”的情况。当然，如果要加入单元测试，会花费更多的资源开销，这是需要考虑的。
团队成员分配到的工作是否都是合适的？
事实上，尽管我们完成了Alpha阶段任务，但我们的分工并不算完美。
第一个不足之处：我们在开发了三到四天左右的时间后，发现三名前端+三名后端的人员配置并不合适，因为前端的任务比想象的要多。因此，我们将后端的一位同学挪到了前端。
第二个不足之处：我们有两位前端的同学对于所需要负责的模块的开发经验不足，任务完成的质量一般；但我们也在完成Alpha阶段之后重新安排了任务分配，并且给出了一些技术支持。
有什么经验教训？如果历史重来一遍，我们会做什么改进？
在任务开始的时候，直接执行4+2的人员配置。
四、变更管理
每个相关的员工都及时知道了变更的消息？
Scrum Meeting和现代社交软件确保我们能够进行及时的沟通；集中线下协作开确保了沟通的质量。
当然，由于PM本学期的课业负担非常大，有的时候可能通知协调不到位。
我们采用了什么办法决定“推迟”和“必须实现”的功能？
我们的任务分配当中，每一项任务都有设置了前置任务。我们判断任务是否有推迟的可能性时，是通过观察该任务是否处于关键路径之上的。
项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
有，详见我们的功能规格说明书或者是Alpha阶段发布声明。
对于可能的变更是否能制定应急计划？
总体来讲，在Alpha阶段我们并没有遇到需要制定“应急计划”的变更。大部分的变更都是细节上的变更，没有撼动项目的整体逻辑。
员工是否能够有效地处理意料之外的工作请求？
由于我们进行了多次线下集中敏捷，大家都能通过冲刺完成额外的工作请求。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
在进行原型设计、需求分析和计划制定的时候，一定要确保团队成员对于功能、任务的理解到位且没有歧义，这样就不会因为开发出了“不符合预期”的产品而导致发生变更。实际上，埃杰团队成员的沟通还是相当到位的，成员遇到问题的时候都比较积极主动，因此没有遇到大的变更。
在Beta阶段中，涉及到更多流程化的设计，我们通过两次会议充分地商讨了设计的细节，希望能够尽可能减少重大变更的发生。
五、设计/实现
设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
项目方案的制定在敏捷前几周完成。
在Alpha阶段，PM要求Agile团队的每一位成员都提出了一个方案，并且启动了一次线下会议讨论每个方案的可行性。随后我们讨论出一个最终可行的方案，得到了团队成员的一致同意，即BUAAMapForum。
设计在敏捷前的一周完成。
我们同样举办了一次线下会议，根据方案的大致描述讨论方案的细节。我们针对每一个功能点进行了讨论，包括其前端界面设计、功能设计、后端数据模型设计、API设计等，并记录下来，最后汇总形成功能规格说明书V1.0。
当然，设计是会发生变更的。如果发生了设计上的变更，我们会在线下Coding的时候或者是Scrum Meeting上通告全体成员，保证大家都知晓变更的内容。
设计工作有没有碰到模棱两可的情况，团队是如何解决的？
存在。
对于影响很小的模糊功能点（如某一个字段在数据库中的类型），前端或者后端内部可以私下讨论并给出解决方案，并通告其他成员。
对于影响较大的模糊功能点（如涉及流程，或者是一个大的功能模块），我们会在Scrum Meeting上或者是线下Coding时集中讨论。PM会给出处理的建议，并在无法达成一致的时候拍板一个暂定的解决方案。
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML，或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
我们使用Balsamiq Wireframes实现了产品的原型设计；通过绘制流程图实现了流程的设计；我们使用ApiFox设计和管理数据模型和API；使用Github进行代码管理和CICD；使用Notion进行文档管理。问题当中提到的工具使用的不多（说实话，感觉甚至是区别很大）。
我们使用了小范围的单元测试，开发的过程中我们认为功能测试和API测试的意义更大，所以没有进行大范围的单元测试，但在老师的建议下，我们认为在Beta阶段需要添加单元测试的内容。
遇到了什么功能的什么Bug？
-
在进行API对接的时候，产生了比较多的Bug，在对接的过程中发生了API出错、请求丢失等问题。这主要是在刚开始对接时，大家对JS的语法不太熟悉、对ApiFox使用不熟练导致的。当然，随着经验的积累，我们在进行API对接时出现的问题也逐渐减少了。
-
在配置https访问的时候，遇到了API出错的问题。这是由于前期配置API是没有考虑到需要和域名请求方法适配的问题，修复这个问题花费了一定的时间。
-
Redis服务器的问题。在发布后，我们重启了一次服务器，但是我们没考虑到Redis在重启后并不会自动开启，故而邮箱验证失效了一段时间。这是由于经验不足导致的。
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
我们通过Github PR实现代码复审，并且遵循了课程组给出的Github规范（包括分支维护规范）。
当然，我们的工作也有需要改进的地方，包括：
-
可以尝试使用JSLint实现更严格、更自动化的代码风格规范
-
在进行代码复审的时候，可以关联其他的成员，明确复审人（在Alpha阶段我们没发现这个功能）
-
团队成员还要多写注释和文档，便于其他的成员快速上手
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
-
设计前需要详细讨论，尤其是要注重流程的讨论，因为流程通常要涉及多个功能点，并且链条比较长，容易产生模棱两可的地方；
-
开发的时候需要多沟通，并且要明确什么问题是可以自己解决的，什么问题是需要一起讨论的
-
多做单元测试，这对项目有好处
-
可以使用工具协助代码复审和规范
六、测试/发布
团队是否有一个测试计划？为什么没有？
有，我们在Alpha阶段尾声制定了测试计划，我们提前协商好并且进行了分工合作，每个人负责不同的测试。
除此之外，我们邀请了人员对我们进行功能测试，并且我们的成员也进行了功能测试。我们将Bug搜集汇总，并且记录在Notion文档中。
是否进行了正式的验收测试？
我们对功能点进行了功能测试、用户体验测试、API测试、网页性能和压力测试。当然，我们的测试仍旧存在着一些不足，并且被助教发现了（如SQL注入等）。
我们在下一阶段需要考虑更加全面的测试方法，如单元测试等。
团队是否有测试工具来帮助测试？
我们使用了非常多的工具协助测试，包括ApiFox、Vue单元测试、JMeter等工具。测试的方法见我们的Alpha阶段测试报告。
团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
我们主要通过JMeter进行API的压力测试，使用谷歌的插件LightHouse进行网页性能测试。
使用JMeter进行测试后，我们使用GoAccess评估了网站的访问量，得到的结论是我们服务器能够承受的压力完全可以满足网站的流量。
我们使用LightHouse分析网页性能后，将Element-Plus的引入方式由自动引入改为按需引入，提升了网页的性能。
在发布的过程中发现了哪些意外问题？
-
Redis服务器的问题，在上文已经提到过了；除此之外，我们还发现向教育网邮箱发送验证码邮件的时候容易丢失
-
https配置的问题，也在上文提到过了
-
安全性问题，如SQL注入等
-
很多同学反馈，希望能够适配移动端的界面
我们学到了什么? 如果重来一遍, 我们会做什么改进?
-
加入单元测试，提高测试的代码覆盖率
-
了解https配置和路由相关的知识，提前配置好域名
-
在发布后需要长期跟踪，确保发布后的服务一直处于可用的状态
-
了解更多安全性测试的相关内容，进行更全面的安全性测试
七、团队的角色，管理，合作
团队的每个角色是如何确定的，是不是人尽其才？
我们根据上学期数据库大家在数据库小组作业团队中的分工和大家之前的开发经验进行角色的确认；PM是自荐产生的。后端的两位同学都贡献了非常好的表现，PM也顺利地组织了各类任务、文档，前端的完成质量也可圈可点。
总的来说，大家的努力都确保了Alpha阶段任务的完成。
团队成员之间有互相帮助么？
我们在线下、线上进行了非常多的讨论，并且团队成员之间互相提供了技术、方法、思路上的支持。
当出现项目管理、合作方面的问题时，团队成员如何解决问题？
我们认为项目管理主要指的是进度管理问题。如果出现了“任务细分”的问题，我们通过线下敏捷开发实现快速跟进；如果出现了额外需要考虑的任务，那么我们的组员会共同商议解决方案。
另外，我们的合作比较顺利，团队成员经历了由不熟到熟悉的写作过程，并且在相互帮助中不断提高合作的效率。
整体来讲，我们没有遇到重大的项目管理和合作问题，埃杰团队的合作过程是比较愉快的。
八、总结
团队目前的状态属于 CMM/CMMI 中的哪个档次？
CMM等级：我们团队进入了已定义级，我们拥有标准化、文档化的技术工作和管理工作，并且有健全的评审制度和灵活的流程控制。
CMMI明确级：我们的开发逐渐进入流程化的管理，并且启发了Beta阶段的全涉及流程。当然，我们在Alpha阶段中还存在一些项目实施上的波动，未能进入下一等级。我们将在下一阶段尽可能实现更加量化的管理流程。
团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段？
团队目前处于“创造”阶段，在Postmortem会议上，我们回忆了Alpha阶段我们的开发由不成熟到成熟的过程。我们对于任务管理、任务验收等都建立了约定，这使得我们的团队处于“规范”阶段。在Alpha阶段后期，团队成员甚至完成了一些额外、有创新性的工作，这表明我们的团队已经处于“创造”阶段了。
你觉得目前最需要改进的一个方面是什么？
任务的分配。前面提到过，我们进行了一次人员结构的调整，在调整之后我们并没有做针对性强的任务重分配，只是进行了一些简单的调整。事实上，在下一阶段我们可以更细致地分配任务，保证每一位成员的贡献度。
对照敏捷开发的原则，小组做得最好的是哪几个原则？请列出具体的事例。
| 原则 | 完成质量 |
|---|---|
| 尽早和持续地交付有价值的软件来满足客户 | ⭐⭐⭐ |
| 欢迎对需求提出变更 | ⭐⭐⭐⭐ |
| 不断交付可用的软件 | ⭐⭐⭐ |
| 项目过程中，业务人员与开发人员必须在一起 | ⭐⭐⭐⭐⭐ |
| 要善于激励项目人员 | ⭐⭐⭐⭐⭐ |
| 最有效的沟通方法是面对面的交谈 | ⭐⭐⭐⭐⭐ |
| 可用的软件是衡量进度的主要指标 | ⭐⭐⭐⭐ |
| 提倡可持续的开发 | ⭐⭐⭐⭐ |
| 对技术的精益求精以及对设计的不断完善将提升敏捷性 | ⭐⭐⭐⭐ |
| 要做到简洁，尽可能减少不必要的工作 | ⭐⭐⭐ |
| 最佳的架构，需求和设计出自于自组织的团队 | ⭐⭐⭐⭐ |
| 团队要定期反省如何能够做到更有效，并相应调整团队的行为 | ⭐⭐⭐⭐ |
正如我们前面提到的， 软件的质量 = 程序的质量 + 软件工程的质量，那 团队在下一阶段应该如何提高软件工程的质量呢？
-
**代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？**
培训。事实上，团队内部成员对于代码管理的理解确实存在偏差，如不了解Git流程规范的重要性、Push上来的代码破坏了其他同学的代码等等。PM在线下Scrum Meeting时不断地强调这个问题，并且为不了解相关规范的同学进行培训，逐渐提高了代码管理的质量（当然，会存在新的问题）。
-
整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？
首先，需要通过预先设计提高整体程序的架构。有效的设计能够非常好地帮助我们构建良好的工程代码。
其次，需要接受必要的重构。例如，我们在开发过程中，一位同学对Element-Plus提供的导航栏组件并不熟悉，用四个Button做了一个导航栏。其他的成员对此感到哭笑不得，事后给予了这位同学一些技术支持，并敦促他重构，在视觉上起到了比较不错的效果。
-
其它软件工具的应用，应该如何提高？
尽可能多发掘辅助软件的“流程”。如果只是使用一些辅助性软件的单独功能点，未必能够提高开发的效率。但是如果能够将软件的功能应用在流程当中，或者是掌握软件自身提供的流程，那么就能够有效提高开发的效率。
例如，我们使用ApiFox设计数据模型和Api的同时，还使用其进行调试、Api自动化测试。
-
项目管理有哪些具体的提高？
在Alpha阶段中，我们的“燃尽图”有一些坎坷，事实上，这主要是团队成员对技术不熟悉+线下沟通不足造成的。我们在敏捷的第4、5天开始增加了线下沟通的次数，这有效提高了我们的开发效率；除此之外，我们通过文档记录了一些关键的技术流程，减少因遗忘导致的效率下降的次数。
在Beta阶段，我们期望团队成员能够保持高效的沟通，一起合作完成本阶段的开发。
-
项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？
我们使用GoAccess分析Apache2的日志，以及分析后端数据库，实现了对用户数据的跟踪。在下一阶段，由于要加入论坛功能，可能会考虑颗粒度更小的用户数据跟踪（方法待调研）。
-
项目文档的质量如何提高？
-
除了课程组要求的文档外，还要丰富文档的种类。除了管理文档，还可以编写Bug记录文档、信息记录文档等等
-
对于关键的技术流程，应当抽空写文档记录实现过程
-
或许可以使用更先进的文档管理工具（Ficus？，来自其他小组的意见，当然我们认为Notion也是足够的）
-
-
对于人的领导和管理， 有什么具体可以改进的地方？
PM可以多把控把控进度。在开发的时候，埃杰的PM基本上都和团队的成员在一起，一起写代码、文档，并且给出技术上和方法上的建议，这是做的不错的。
当然，前端可能需要有一位同学负责主导性的工作（因为前端有四个人），管理颗粒度更加细小的任务。
-
对于软件工程的理论，规律有什么心得体会或不同意见？
首先，流程是非常重要的。不论是软件的设计、开发的过程还是团队的管理，流程都是非常重要的。我们既要确保流程的完善、高效，又要防止出现冗余无用的流程。流程虽然不是目的，但确实是达成目标的非常好的手段。
其次，沟通是非常重要的，对于新组成的团队来说尤其重要。我们在API对接的时候发现了这一重大问题，并且快速地提高了沟通的次数和效率，这有效地保证了我们能够顺利完成Alpha阶段的任务。
最后，记录是非常重要的。不论是设计、技术、问题还是成果都值得记录，因为记录有助于我们温习、反思。单纯依靠肌肉记忆写代码是不足以生存的，每一个人都必须有自己的笔记本。
额外补充一点：会写代码又可以设计UI的人真的是一个开发团队的宝贵财富。
最后，附上我们的Postmortem会议的截图。PM还带着大家逐个分析了老师、助教和其他队伍的评审意见，用于改进Beta阶段的工作。
-
