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

TEAMLESSERROR

已于 2022-05-18 22:53:52 修改

阅读量213

点赞数

文章标签：团队开发

于 2022-05-18 22:48:43 首次发布

本文链接：https://blog.csdn.net/czl_yt/article/details/124853026

版权

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

Alpha阶段事后分析

设想和目标
计划
资源
变更管理
设计/实现
测试/发布
团队的角色，管理，合作
总结

设想和目标

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

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

⼩A是在读⼤学⽣，准备考研，事情⼜多⼜杂，不仅需要详细规划每天的学习计划，也需要在课上或者会议中及时速记。刷题、阅读或者作业时，常常需要分层管理⾃⼰的任务；有的⻓期作业需要有更细致的分化。同时，⼩A在图书馆或者在宿舍⼯作学习时，也需要⼀个强制⾃⼰专注下来的模式。
我们达到目标了么（原计划的功能做到了几个？按照原计划交付时间交付了么？原计划达到的用户数量达到了么？）

总体来看，我们的Alpha阶段还是符合预期的，达到了预先设定的目标。关键功能（Memo、Event、按照不同指标排序、完成进度、查看已完成、Memo转入Event、DeepFocus专注模式等）全部在规定时间内实现、交付，且测试结果良好。用户量也超出我们预先预期的50人，达到了139次。可惜的是，受制于其他课程的时间挤占，我们预先设计的一些高级功能，比如上传书单目录自动生成阅读计划等，暂无法在Alpha阶段实现。
用户量、用户对重要功能的接受程度和我们事先的预想一致么？我们离目标更近了么？

从用户反馈来看，核心功能是符合目标群体口味的，基本符合预期。不过也有比较专业的用户提出了一些使用体验上的修改意见，能够帮助我们更进一步。
有什么经验教训？如果历史重来一遍，我们会做什么改进？

在设想和目标这一块儿挺顺利的，并没有出现太大的波折。但是需要注意的一点是在正式开始具体开发细节之前，必须三思自己的设想的可行性和最优性，不然可能涉及到后期费大力气重构整改甚至推翻重来。

计划

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

我们的时间虽然不宽裕，但是计划还是比较完备地拟出并且在之后严格执行了。
团队在计划阶段是如何解决同事们对于计划的不同意见的？

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

我们计划的必完成工作都如期完成了，然后一些弹性的高级功能由于其他课程的时间挤占，暂时无法在Alpha阶段保质保量地完成。我们计划将这些高级功能纳入Beta阶段的必完成工作。
有没有发现你做了一些事后看来没必要或没多大价值的事？

我们在设计阶段确实有设计一些意义不大的特性，比如我们最开始设计了给每个Event都赋予一个参与人属性和地点属性，后来发现这样并没有让软件更好用，反而徒增用户使用时的负担。所以我们在之后的具体开发时，用一个备注代替了这些冗杂的属性。这也是我们小组会议讨论通过的结果。
是否每一项任务都有清楚定义和衡量的交付件？

我们并没有严格针对每一项任务都独立设定一个交付件，而是采用代码融合，也就是Merge，来管理任务交付。这样更加高效，没有必要花无谓的精力在每一次的任务交付上，因为最终的软件成果是只有一个交付的。在完成每一项任务后，相应的完成人需要解决当前分支代码冲突后发起Merge Request，等待PM查验通过。如果查验不通过，PM告知其原因，修改后再次发起Merge Request。
是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到？

项目出现的最重大的一次意外就是在数据存储和逻辑上经历了一次大变动。我们从原本的Realm by MangoDB切换为了React Native原生的AsyncStorage，这增加了许多转移功能的工作量。之所以要进行这一次变动是因为我们发现AsyncStorage更加轻量并且后期如果要对接CSDN团队会很方便，因为它是严格基于json的，不会有奇怪的特性干扰后期可能存在的对接。这在最开始选择工具链时确实疏忽了，总归还是对这些数据存储工具不熟悉，不得不吃一吃亏。
我们学到了什么？如果历史重来一遍，我们会做什么改进？

我们中途吃的最大的一个亏就是变动数据库，这也提醒我们在之后进行规划时，必须对作出的决定烂熟于心，不然到后期的修改是事倍功半的。如果历史重来一遍，我们会先横向比较多种数据存储方式，细致比较权衡优劣，最后构思出一个最优方案以及这种数据存储方式在这个方案中的应用方式，再开始正式代码编写。

资源

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

资源肯定是充足的，毕竟不是什么大型的复杂软件开发，也没有用到深度学习等烧显卡烧设备的技术。
各项任务所需的时间和其他资源是如何估计的，精度如何？

PM在估计任务所需时间时，首先会考虑如果是自己来做会需要多久，然后就以这个时间加一天作为一个期限。以这个方法估计出来的时间还是比较合适的，没有出现剩余很多时间或者时间不够的情况。至于资源，在我们的软件工程中并不需要做什么估计。
测试的时间，人力和软件/硬件资源是否足够？对于那些不需要编程的资源（美工设计/文案）是否低估难度？

人力以及硬件资源都是够用的。至于美工设计和文案，我们并没有遇到任何难处。
你有没有感到你做的事情可以让别人来做（更有效率）？

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

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

变更管理

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

我们的交流主要是在两个平台，微信和Discord。我们发布重要消息都是在Discord上面进行，然后微信通知。因为大家看微信都会比较勤，所以基本不会出现漏掉的情况。另外，重要信息都会在Discord的对话线中被pin起来，所以就算讨论已经进行了一段时间，晚来的成员也不会错过重要消息。
我们采用了什么办法决定“推迟”和“必须实现”的功能？

首先我们评估软件离了哪些功能无法正常运作，比如Memo添加删除，然后把这些功能纳入必须实现的范畴。至于一些软件的惊喜需求，比如说上传书单目录自动生成计划等，则可以推迟开发，放到Beta阶段。
项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么？

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

我们通过尽量遵守高内聚低耦合的开发原则，如果有紧急变更，我们可以很方便地只修改对应模块，尽量缩小修改范围，而不需要对项目整体进行庞大的改动。
员工是否能够有效地处理意料之外的工作请求？

在我们的开发阶段，并没有给到成员意料之外的工作请求。我们尽量在开发开始之前解决任务规划和分配问题。
我们学到了什么？如果历史重来一遍，我们会做什么改进？

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

设计/实现

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

设计工作在正式开发进行之前，主要由PM来负责，之后在开发过程中如果有具体的修改建议，再在小组会议上讨论决定通不通过。我认为在设计上，时间和人选都是比较合适的。
设计工作有没有碰到模棱两可的情况，团队是如何解决的？

设计时难免会遇到模棱两可的纠结局面，在此时就先由PM定夺第一版开发计划。之后，如果开发时有成员提出这个地方有更好的解决方式，那么就通过开小组会议来决定是否通过。
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

在开发中，我们使用了单元测试来评估几个关键功能模块，比如增删编辑Event或者Memo等。但是我们没有使用UML来表述我们的类间关系。在Beta阶段我们可以加入这个工作来更加清晰地管理我们的项目。
什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug？为什么我们在设计/开发的时候没有想到这些情况？

在我们的测试阶段发现递归获得子Event信息的Bug最多，因为我们有些时候会忽略一些特殊情况，比如在获取子Event中最紧迫期限时我们没有考虑已完成的Event不应该被纳入考虑，从而导致功能上有缺陷。不过这些比较明显的bug都是在发布之前发现并且修缮的，发布之后暂时还没有获得bug反馈。我们在设计/开发时还是对特殊的一些情况没有做很完备的考虑。
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

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

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

测试/发布

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

我们的测试计划为每添加一个新功能都要保证最基本的正确性和完备性。最后，在Alpha阶段收尾阶段，由测试成员对我们的软件进行一个全方面的测试，并反馈修改意见，为最后完善留住空间。
是否进行了正式的验收测试？

我们进行了比较完整全面的验收测试，由团队的测试成员完成，相关测试可见于我们的 Alpha测试文档。
团队是否有测试工具来帮助测试？

我们使用了腾讯的WeTest测试工具，并且在每一次单元测试，用WebStorm原生插件来测试代码覆盖率。
团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？

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

安卓平台的发布过程还是比较顺利的，然而在iOS上的发布受制于没有一个苹果的开发者账号，所以暂时无法发布脱离模拟器的应用程序版本。我们在Beta会解决这个问题并且发布iOS版本。
我们学到了什么？如果重来一遍，我们会做什么改进？

我们在测试和发布阶段总体来说还是比较顺利的，就算遇到了iOS发布的问题也清楚问题为什么会发生，不会耽误太多时间。但是确实我们在前期测试过于依赖手动测试了，在Beta阶段我们需要降低手动测试的比例，增大自动化较大规模测试的比例。

团队的角色，管理，合作

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

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

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

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

总结

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

我认为我们达到了CMM的2级过程区域，因为我们满足了该区域要求的需求管理、项目策划、项目监督和控制、供方协定管理、测量和分析、过程和产品质量保证、配置管理等特征，但是还没有满足3级过程区域要求的组织过程聚焦、组织过程定义、组织培训等特征。
你觉得团队目前处于 [萌芽/磨合/规范/创造] 阶段的哪一个阶段？

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

我认为现在在Beta阶段最需要改进的一个地方就是代码管理必须让所有成员严格执行约定好的流程来。现阶段由于一些成员对Git的一套机制还不熟悉，还存在手动发代码的行为，这是比较不可取的。我们会在Beta阶段取缔掉这种业余的代码管理漏洞，以防在最后的Beta发布出现严重的代码管理问题。
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则？请列出具体的事例。

在敏捷开发的原则里，我觉得我们小组做的最好的地方是：
- 需求变更灵活：我们严格按照两天一次的频率开展小组会议，商议有无需求变更，并且得益于我们遵守的高内聚低耦合原则，很多新的需求变更都可以很快实现；
- 业务人员与开发人员始终在一起：我们的团队没有严格分化团队职责，每个开发人员都可以是业务人员，帮助推广软件；
- 可用的软件是衡量进度的主要指标：我们自始至终都坚持保证软件的可用性，并以这个原则来设计单元测试以及最终的全面测试；
- 简洁，尽可能减少不必要的工作：我们的团队在开发阶段尽可能避免不必要的冗余工作和功能开发，并且两个人做同样的事这种情况是从来不允许也没有发生的。我们的整个开发流程是非常简洁高效的；
- 定期反省并调整：在开发过程中，我们难免会遇到成员进度不一的情况，但是我们每次都可以通过小组例会来帮助加快已经拖沓的进度，及时做出人员调整来保证进度。
正如我们前面提到的，软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提高软件工程的质量呢？
1. 代码管理的质量具体应该如何提高？代码复审和代码规范的质量应该如何提高？
  
  我们需要在下一阶段让所有人都参与到一个比较专业的代码管理中来，完全取缔掉业余的手发代码的形式。另外，在代码复审和规范环节，我认为如果严格按照先行方法是不会在Beta阶段出问题的。
2. 整个程序的架构如何具体提高？如何通过重构等方法提高质量，如何衡量质量的提高？
  
  在Beta阶段，我们有可能和第三方团队（CSDN）做后端对接，并且可能扩展运行平台到微信小程序、Web等。这就要求我们对我们的关键模块进行更加严格的解耦，这可能涉及到不小规模的代码重构。至于衡量质量提高的标准，我们暂定以跨平台测试中不会出现渲染问题为标准。
3. 其它软件工具的应用，应该如何提高？
  
  在Alpha阶段，由于React Native报错的冗杂，耽误了不少时间。我们在Beta阶段可以学习如何高效利用React Native开发者工具。
4. 项目管理有哪些具体的提高？
  
  在项目管理上，我们初步决定沿用Alpha阶段的管理模式。
5. 项目跟踪用户数据方面，计划要提高什么地方？
  
  在Alpha阶段，我们统计的用户反馈面比较狭窄；在Beta阶段，我们准备给所有社会用户提供一个反馈窗口，并且通过软件发布平台跟踪用户数据和报错log信息。
6. 对于软件工程的理论，规律有什么心得体会或不同意见？
  
  我想通过几点心得体会来描述我对软件工程理论的理解：
  - 专业性
    
    显然，开发团队应该具备出色的编程技能。此外，优秀的开发团队除了传统的开发，也会重视创新对重要性。并且，团队成员善于跟上技术趋势，知道如何以务实的方式使用它来提高绩效。
  - 定期和清晰的沟通
    
    沟通是让任何团队运作良好的关键，团队需要确保沟通有规律（频率取决于需要）和清晰（没有秘密，意见可以自由分享）。有两种类型的沟通至关重要：团队内部的沟通和与第三方（利益相关者）的沟通。在团队中，领导者应该鼓励团队以健康的沟通来产生有效的流程、工具和解决方案。在与第三方沟通时，在沟通的帮助下，团队可以清晰地设定目标、审查流程、讨论新机会、选择正确的工具等等。
  - 对目标的承诺
    
    设定明确和可实现的目标对任何团队都至关重要。在制定长期和短期计划并将任务交给团队之前，确保每个人都知道他们在项目结束时的目标是什么。
  - 明确的角色和职责
    
    为了正常运作，团队需要了解流程的所有方面，以及他们的职责和责任。团队成员还应该了解他们的角色和职责与项目目标的关系。
  - 理解数字产品的业务逻辑
    
    优秀的开发团队了解他们真正的客户。通过与产品所有者和利益相关者的沟通，他们真正了解最终用户的需求，因此能够做出正确的技术）决策。这是创建成功的定制软件的唯一方法。
  - 自由与灵活性
    
    每个团队成员都应该可以自由地自行寻找新出现的困难的解决方案。在一个优秀的团队中，团队成员可以灵活地选择工具和与之合作的技术堆栈。当他们以目标为导向并受到启发时，他们会尝试找到最佳解决方案。有些时候，PM对他们的规范不太严格也许可以提供更好的代码，并让开发人员在工作时更快乐。一定的试验自由度有助于开发人员建立具有内部流程和文化的团队模型。
    
    优秀的开发团队也可以灵活地规划他们的工作日程，因为人类不可能整天保持生产力。他们需要时间放松，在咖啡机旁聊天，或者去健身。所有人都需要一些放松来创新和创造。通过这样做，他们确保了高动力，从而在特别需要时最大限度地提高生产力。