Okidoki - Beta阶段事后分析 - TEAM LESS ERROR

项目	内容
这个作业属于哪个课程	课程社区的链接
这个作业的要求在哪里	作业要求的链接

设想和目标

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

   我们的软件目标是实现一个支持分层管理的计划APP。在我们的系列文档中，我们对于我们的任务目标的定义都是十分清晰的。在我们的NABCD分析文档、功能规格说明书以及Alpha阶段以及Beta阶段软件发布声明等文档中，我们都不断在强调并且拓宽一些典型的用户以及场景，比如：

   ⼩A是在读⼤学⽣，准备考研，事情⼜多⼜杂，不仅需要详细规划每天的学习计划，也需要在课上或者会议中及时速记。 刷题、阅读或者作业时，常常需要分层管理⾃⼰的任务；有的⻓期作业需要有更细致的分化。 同时，⼩A在图书馆或者在宿舍⼯作学习时，也需要⼀个强制⾃⼰专注下来的模式。

2. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么？）

   在Alpha阶段，我们达到了预先设定的目标。关键功能（Memo、Event、按照不同指标排序、完成进度、查看已完成、Memo转入Event、DeepFocus专注模式等）全部在规定时间内实现、交付，且测试结果良好。用户量也超出我们预先预期的50人，达到了139次。可惜的是，受制于其他课程的时间挤占，我们预先设计的一些高级功能，比如上传书单目录自动生成阅读计划等，暂无法在Alpha阶段实现。
   在本次Beta阶段，我们虽然遇到了一些挫折，将任务拖慢了一天，但是整体的功能实现还是很理想的。我们在Beta阶段主要在Alpha阶段的基础上增加实现了四个主要功能：

   • 图片自动生成事项
   • 个性化设置
   • 云同步
   • 系统提示

   这些功能开发难度普遍大于Alpha阶段，但是开发效果较好，用户反馈也较为不错。但是Beta阶段的用户量略低于我们的预期，现在的下载量统计为 211 次（包含Alpha阶段时的139次），Beta阶段的下载量为72次。究其原因，可能是因为临近期末，大家普遍减少了一些闲心来下载。

3. 用户量、用户对重要功能的接受程度和我们事先的预想一致么？ 我们离目标更近了么？

   从用户反馈来看，Beta阶段开发的核心功能，尤其是图片识别自动生成事项这个新实现的杀手级功能，是符合目标群体口味的，基本符合预期。至此，我们对于这个软件工程在学期初的预期已经完全实现。当然，由于我们和CSDN团队正在尝试进行对接，所以我们并不会止步于此，可能在这之后，我们会和CSDN团队一起设计开发更多的功能，并长期进行产品维护。

4. 有什么经验教训？ 如果历史重来一遍，我们会做什么改进？

   我们在Beta阶段遇到的最大的教训就是一定要非常笃定才可以使用一些 git 命令，不然有可能导致代码管理混乱。在Beta阶段的开发中，由于有成员对 git 指令和机制不是很熟悉，所以误用了 --force 来进行代码推送，消抹了其他成员的代码，造成了不小的成本增加。如果历史重来一遍，我们会在Alpha阶段就对所有成员进行 git 规则的详细讲解，防止使用 git 管理代码得不偿失。

计划

1. 是否有充足的时间来做计划？

   我们在Beta阶段初级的计划制定还是非常缜密的，因为我们在当时尚有有充足的时间来做计划。但是，我们在Beta阶段无可预见地遇到了很多挫折，比如大规模疫情复发和大规模学生返乡、隔离；这些始料未及的事情较为严重地打乱了我们的开发计划，拖慢了我们的时间进度。加之我们在学期后程需要花大精力去复习各科期末考试，挤占了大量的开发时间，所以往往觉得有些力不从心。

2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？

   与在Alpha阶段一样，无论是不同意见、疑惑或者争执，我们都会及时开展小组会议，记录每一个人的想法，最后由全体成员和PM共同商议。如果是关于设计的重大异议，在经过讨论后，这个意见要通过必须获得过半成员和PM同时同意（即 $过半成员同意\&\&PM同意$）。我们按照这个原则，一步步优化我们的APP，最后的成果是不错的。

3. 你原计划的工作是否最后都做完了？ 如果有没做完的，为什么？

   我们计划的必完成工作虽然迟交付了一天，但是仍旧保质保量地完成了。

4. 有没有发现你做了一些事后看来没必要或没多大价值的事？

   因为吸取了在Alpha阶段的经验教训，我们在Beta阶段并没有做一些现在看来没有必要的事情。只是确实有一些有必要但是没有做的事情，比如事先给没有用过 git 同学来培训其使用方法等。

5. 是否每一项任务都有清楚定义和衡量的交付件？

   同Alpha阶段一样，我们并没有严格针对每一项任务都独立设定一个交付件，而是采用代码融合，也就是Merge，来管理任务交付。这样更加高效，没有必要花无谓的精力在每一次的任务交付上，因为最终的软件成果是只有一个交付的。在完成每一项任务后，相应的完成人需要解决当前分支代码冲突后发起Merge Request，等待PM查验通过。如果查验不通过，PM告知其原因，修改后再次发起Merge Request。

6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到？

   我们在Beta阶段开发的过程中遇到的最大意外就是团队成员对于 git 命令的不熟悉而导致团队代码受到较大程度的影响，进度也被拖慢了许多。另外一个没有估计到的问题就是在图片识别模块开发时JavaScript接口使用时团队对接时出了一个困扰我们很久的问题，即每次单独运行图片识别模块没有任何问题，但是一旦接入软件就会出现缺少依赖项的报错。这个问题是我们对Node.js不熟悉导致的，其实解决起来非常简单，只需要保证 node_modules 文件夹以及 package.json 文件唯一即可。这个问题警示我们必须要对所涉及的技术十分熟悉才可以保证开发效率，得多看官方文档，多看 StackOverflow，少看百度。

7. 我们学到了什么？如果历史重来一遍，我们会做什么改进？

   我们在Beta阶段主要学到了人员培训的必要性以及技术专业的必备性。如果历史重来一遍，我们会提前进行必要的技术人员培训，尤其是涉及到代码管理等可能影响团队中其他成员的事情时。另外，我们也需要保证我们对于自己负责部分的技术十分熟悉，保证团队中的每个人都可以做到对自己完成的工作有十足把握来修复问题。

资源

1. 我们有足够的资源来完成各项任务么？

   相比于Alpha阶段，我们在Beta阶段还是遇到了资源不足的情况，甚至现在也在受这方面的困扰。我们的服务器并没有十分优秀的性能来支持我们的图像识别模块，所以暂时还是把图像识别放在本地完成的。这个确实不符合工业界要求，但是在现阶段只得首先保证软件的可用性和正确性。希望在之后我们可以获取更好的服务器资源来支持我们的服务器端功能。

2. 各项任务所需的时间和其他资源是如何估计的，精度如何？

   同Alpha阶段一样，PM在估计任务所需时间时，首先会考虑如果是自己来做会需要多久，然后就以这个时间加一天作为一个期限。以这个方法估计出来的时间还是比较合适的，没有出现剩余很多时间或者时间不够的情况。至于资源，在我们的软件工程中并不需要做什么估计。

3. 测试的时间，人力和软件/硬件资源是否足够？ 对于那些不需要编程的资源 （美工设计/文案）是否低估难度？

   除了上文所说的服务器资源有些受限，人力以及硬件资源都是够用的。至于美工设计和文案，我们并没有遇到任何难处。甚至根据用户的反馈，我们在无用户界面设计师的帮助下设计出来的用户界面也是广受好评的。

4. 你有没有感到你做的事情可以让别人来做（更有效率）？

   每个人各有长处，但是在这次的任务分配中，我认为都是尽量满足了每个人的倾向和长处的。然而不可否认的是，有几位同学是第一次接触移动开发，自己擅长哪一个端其实没有什么非常有根据的概念，所以难免会遇到一些比较基础的问题，需要其他端的同学帮助。不过总体而言，团队开发的效率是得到了保证的。

5. 有什么经验教训？如果历史重来一遍，我们会做什么改进？

   在分配人员任务时，需要对每个人的能力进行更加完全的评估，不然可能会出现分配的任务无法完成而导致成员贡献分很低的情况。如果历史重来一遍的话，我们会尽量以正规面试的流程走一遍能力评估，之后根据评估来更加合理地分配任务，而不是纯粹按照个人的倾向来分配。

变更管理

1. 每个相关的员工都及时知道了变更的消息？

   同Alpha阶段一样，我们的交流主要是在两个平台，微信和Discord。我们发布重要消息都是在Discord上面进行，然后微信通知。因为大家看微信都会比较勤，所以基本不会出现漏掉的情况。另外，重要信息都会在Discord的对话线中被pin起来，所以就算讨论已经进行了一段时间，晚来的成员也不会错过重要消息。

2. 我们采用了什么办法决定“推迟”和“必须实现”的功能？

   我们的软件必要功能已经在Alpha阶段全部实现，所以在Beta阶段我们会更放注意力在一些兴奋性需求的满足上，比如图片识别自动生成事项等高级功能等实现。我们主要根据用户反馈来决定“必须实现”。比如，在Alpha阶段之初，我们在NABCD调查时了解到许多用户都希望有一个拍照自动生成计划等功能，所以我们将拍照自动生成事项这个功能作为“必须实现”目标。

3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么？

   一个最基本的出口条件就是软件功能的正确性必须完备，之后考虑用户体验（UI设计、动画等），如果内测用户体验良好，那么我们规定项目可以交付。

4. 对于可能的变更是否能制定应急计划？

   我们通过尽量遵守高内聚低耦合的开发原则，如果有紧急变更，我们可以很方便地只修改对应模块，尽量缩小修改范围，而不需要对项目整体进行庞大的改动。

5. 员工是否能够有效地处理意料之外的工作请求？

   在我们的开发阶段，并没有给到成员意料之外的工作请求。我们尽量在开发开始之前解决任务规划和分配问题。

6. 我们学到了什么？如果历史重来一遍，我们会做什么改进？

   我们在变更管理上做得还是很好的，能够合理运用GitLab、Discord等平台来管理团队项目。我们在整个开发过程中整体而言都是比较井然有序的，所以最后能够较好地完成任务。

设计/实现

1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？

   同Alpha阶段一样，设计工作在正式开发进行之前，主要由PM来负责，之后在开发过程中如果有具体的修改建议，再在小组会议上讨论决定通不通过。我认为在设计上，时间和人选都是比较合适的。

2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？

   同Alpha阶段一样，设计时难免会遇到模棱两可的纠结局面，在此时就先由PM定夺第一版开发计划。之后，如果开发时有成员提出这个地方有更好的解决方式，那么就通过开小组会议来决定是否通过。

3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

   在Beta阶段开发中，我们使用了单元测试和一些常用的准确率实验来评估几个关键功能模块，比如云同步和图片识别等。但是我们没有使用UML来表述我们的类间关系。

4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug？ 为什么我们在设计/开发的时候没有想到这些情况？

   在Beta阶段其实没有遇到什么代码正确性上的问题，唯一让我们伤透脑筋的问题就是图片识别模块的准确率始终难以更进一步。在发布之后，我们收到的bug反馈主要就是有些时候点击登录会没有反应甚至闪退。这个问题是远端服务器没有启动导致的，其实只需要开启即可。我们在设计时确实没有考虑服务器开关机的情况，犯了一个基础性错误。

5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

   在每一次Merge Request，PM首先会查看提交的代码是否符合 Google JavaScript Style Guide 规范，不符合则需要打回；如果符合，则审查正确性、完备性和复杂度。如果有正确性或者完备性问题则需要打回；如果有更优的复杂度，则按照团队贡献分扣除相应分数，之后由PM修改为更好的复杂度。

6. 我们学到了什么？如果历史重来一遍，我们会做什么改进？

   在这个部分，我们还是遇到了一些问题的，比如由于对边界等特殊情况考虑不周全而导致bug出现。如果再来一遍，我们会花更多的精力在设计和构思阶段，尽量想到每一种可能的情况，保证项目的完备性。

测试/发布

1. 团队是否有一个测试计划？为什么没有？

   我们的测试计划为每添加一个新功能都要保证最基本的正确性和完备性，尤其是云同步的正确性、安全性和图片识别的准确性。最后，在Beta阶段收尾阶段，由测试成员对我们的软件进行一个全方面的测试，并反馈修改意见，为最后完善留足空间。

2. 是否进行了正式的验收测试？

   我们进行了比较完整全面的验收测试，由团队的测试成员完成，相关测试可见于我们的 Beta测试文档。

3. 团队是否有测试工具来帮助测试？

   我们使用了腾讯的WeTest测试工具，并且在每一次单元测试，用WebStorm原生插件来测试代码覆盖率。

4. 团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？

   我们的效能测试主要是在排序功能和内存占用上。对于这两个方面的测试，我们都加入大量数据，进行一个超出正常使用时会遇到的数据量的压力测试。然而，由于我们的项目暂为离线单机软件，我们并不需要进行并发测试。从实际结果来看，这些测试是极必要的，因为这帮助到我们发现bug以及一些比较严重的软件问题。

5. 在发布的过程中发现了哪些意外问题？

   发布过程中遇到的一个比较严重的问题就是Expo打包程序无法编译某些依赖项，导致发布暂时无法进行。我们在最近的一次会议中找到了问题缘由并且成功解决。

6. 我们学到了什么？如果重来一遍，我们会做什么改进？

   我们在测试和发布阶段总体来说还是比较顺利的，就算遇到了发布的问题也清楚问题为什么会发生，不会耽误太多时间。如果重来，我们会做的改进主要是把Expo的打包流程规定清楚，不要过度依赖其提供的默认打包配置。

团队的角色，管理，合作

1. 团队的每个角色是如何确定的，是不是人尽其才？

   我们的成员角色主要是通过个人倾向来确定的。虽然确实实力参差比较大，但是每个人都参与到了团队里面来，无论是通过讨论、代码编写还是文档编写，大家都没有对团队零贡献或者甚至负贡献。在开发人员中，有实力强劲的成员也有实力稍弱的成员，实力强劲的可以承担起更多的责任，当然也会获得更高的贡献分；实力稍弱的成员也在开发过程中尽自己所能为团队做出贡献，虽然贡献量较少，但是这并不影响团队整体进度稳步进行。

2. 团队成员之间有互相帮助么？

   团队成员之间会互相帮助，不会存在止步于自扫门前雪的自私心态。一些实力较强的成员会主动帮助进度稍慢的同学，为他们讲解功能设计的底层逻辑，甚至在他们无法很好地完成自己的任务时补上位置，尽自己所能不让进度拖沓。这也是我们Alpha阶段较为成功最为重要的原因之一。

3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？

   出现项目管理或者合作上的问题时，我们还是依托于小组会议的形式，在Discord上讨论出解决方案。

总结

1. 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次？

   我认为我们达到了CMM的2级过程区域，因为我们满足了该区域要求的需求管理、项目策划、项目监督和控制、供方协定管理、测量和分析、过程和产品质量保证、配置管理等特征，但是还没有满足3级过程区域要求的组织过程聚焦、组织过程定义、组织培训等特征。

2. 你觉得团队目前处于 [萌芽/磨合/规范/创造] 阶段的哪一个阶段？

   我认为我们团队目前处于规范阶段。因为团队已经可以很自然地进行公开讨论流程和工作，并且随着项目的发展和成员们的互动，一些成文或不成文的规则逐步建立起来了。作为一个整体，团队要做和不要做的事情都更加明确。并且，成员之间的讨论更加友好，大家意识到并尊重各人的个性，但不影响一个更坚定的共同目标。

3. 你觉得目前最需要改进的一个方面是什么？

   在后期每日例会的到会和反馈情况不积极，导致组员间沟通并不如之前有效，这个需要做出改进。

4. 对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则？ 请列出具体的事例。

   在敏捷开发的原则里，我觉得我们小组做的最好的地方是：

   • 需求变更灵活：我们严格按照两天一次的频率开展小组会议，商议有无需求变更，并且得益于我们遵守的高内聚低耦合原则，很多新的需求变更都可以很快实现；
   • 业务人员与开发人员始终在一起：我们的团队没有严格分化团队职责，每个开发人员都可以是业务人员，帮助推广软件；
   • 可用的软件是衡量进度的主要指标：我们自始至终都坚持保证软件的可用性，并以这个原则来设计单元测试以及最终的全面测试；
   • 简洁，尽可能减少不必要的工作：我们的团队在开发阶段尽可能避免不必要的冗余工作和功能开发，并且两个人做同样的事这种情况是从来不允许也没有发生的。我们的整个开发流程是非常简洁高效的；
   • 定期反省并调整：在开发过程中，我们难免会遇到成员进度不一的情况，但是我们每次都可以通过小组例会来帮助加快已经拖沓的进度，及时做出人员调整来保证进度。

5. 正如我们前面提到的， 软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提高软件工程的质量呢？

   1. 代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？

      我们需要在下一阶段让所有人都参与到一个比较专业的代码管理中来，完全取缔掉业余的手发代码的形式。另外，在代码复审和规范环节，我认为如果严格按照先行方法是不会在Beta阶段出问题的。

   2. 整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？

      我们的程序架构值得重构的地方一个在于UI系统的风格文件（StyleSheet）需要从组件中抽离出来。因为一个软件的UI风格应该是统一的，并不需要每次都在组件代码文件中重新规定一次风格。我们需要做的应该是建立一个抽离的风格文件，让每个组件库可以调用其中的具体风格。

   3. 其它软件工具的应用，应该如何提高？

      我们在之后仍然可以学习如何高效利用React Native开发者工具，因为React Native的报错信息其实很让人费解，在解决警告以及报错这方面上我们花了不少时间。

   4. 项目管理有哪些具体的提高？

      在项目管理上，我认为我们的管理机制没有问题，重要的是人员的参与意识。

   5. 项目跟踪用户数据方面，计划要提高什么地方？

      在Beta阶段，我们给所有用户提供一个反馈窗口，并且通过软件发布平台跟踪用户数据和报错log信息。在这个基础上，我们打算固定跟踪一部分用户的使用行为来优化我们的软件。

   6. 对于软件工程的理论，规律有什么心得体会或不同意见？

      我想通过几点心得体会来描述我对软件工程理论的理解：

      • 专业性

        显然，开发团队应该具备出色的编程技能。此外，优秀的开发团队除了传统的开发，也会重视创新对重要性。并且，团队成员善于跟上技术趋势，知道如何以务实的方式使用它来提高绩效。

      • 定期和清晰的沟通

        沟通是让任何团队运作良好的关键，团队需要确保沟通有规律（频率取决于需要）和清晰（没有秘密，意见可以自由分享）。有两种类型的沟通至关重要：团队内部的沟通和与第三方（利益相关者）的沟通。在团队中，领导者应该鼓励团队以健康的沟通来产生有效的流程、工具和解决方案。在与第三方沟通时，在沟通的帮助下，团队可以清晰地设定目标、审查流程、讨论新机会、选择正确的工具等等。

      • 对目标的承诺

        设定明确和可实现的目标对任何团队都至关重要。在制定长期和短期计划并将任务交给团队之前，确保每个人都知道他们在项目结束时的目标是什么。

      • 明确的角色和职责

        为了正常运作，团队需要了解流程的所有方面，以及他们的职责和责任。团队成员还应该了解他们的角色和职责与项目目标的关系。

      • 理解数字产品的业务逻辑

        优秀的开发团队了解他们真正的客户。通过与产品所有者和利益相关者的沟通，他们真正了解最终用户的需求，因此能够做出正确的技术）决策。这是创建成功的定制软件的唯一方法。

      • 自由与灵活性

        每个团队成员都应该可以自由地自行寻找新出现的困难的解决方案。在一个优秀的团队中，团队成员可以灵活地选择工具和与之合作的技术堆栈。当他们以目标为导向并受到启发时，他们会尝试找到最佳解决方案。有些时候，PM对他们的规范不太严格也许可以提供更好的代码，并让开发人员在工作时更快乐。一定的试验自由度有助于开发人员建立具有内部流程和文化的团队模型。

        优秀的开发团队也可以灵活地规划他们的工作日程，因为人类不可能整天保持生产力。他们需要时间放松，在咖啡机旁聊天，或者去健身。所有人都需要一些放松来创新和创造。通过这样做，他们确保了高动力，从而在特别需要时最大限度地提高生产力。