[Gamma阶段]事后分析博客

Gamma阶段事后分析博客

目录

• Gamma阶段事后分析博客
  • 设想和目标
  • 计划
  • 资源
  • 变更管理
  • 设计/实现
  • 测试/发布
  • 团队的角色，管理，合作
  • 总结
  • 讨论照片

作业要求：Gamma阶段事后分析

设想和目标

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

  我们软件要解决的问题是：现阶段各类组队招募、实习招募信息常常被埋没在大量微信聊天消息中，翻阅十分困难，且申请流程差异巨大，招募、申请的效率极低。

  解决方法：通过微信小程序为同学们提供一个统一的，功能全面的招募信息发布平台，让同学们可以方便快捷的完成组队的招募、申请。

  我们团队对于要解决的问题定义非常清楚，对于目标用户群体的划分也非常准确，具体，就是各个大学中的，希望组织或加入别人项目的同学们。

  这一点在Gamma阶段中依然保持不变。

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

  原计划功能的实现：在三个迭代过后，我们通过30个不同页面，完成了预期的全部功能。还加入了标签、搜索、分类检索、数学建模模块等额外功能。

  交付时间：在Beta阶段中，由于小程序审核条件突然变严导致了交付时间的拖延。在Gamma阶段我们吸取了教训，预留了充足的时间给发布阶段。最后提前完成了交付。

  用户数量：截止2019.06.17日，我们的用户数量达到了400，比我们的预期成果高不少。

• 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？

  和之前两个阶段相比，我们的软工质量的提高主要体现在以下两个方面：

  • 团队合作更加顺利

    在Gamma阶段中，团队经过了之前的磨合，各自分工明确，从开始的计划阶段，到开发阶段，再到最后的测试、发布阶段，每个人都对自己的职责有非常清晰的认识。这样其实PM没有每天催着成员完成任务，成员也会以很高的积极性、自觉性去完成自己分内的工作。

  • 设计、接口文档的完善

    在Gamma阶段中，我们的前、后端设计文档都更加规范了。在前端我们有详细的页面设计，通过PPT预先对页面布局、UI、配色进行设计，并对其中可互动部分做了示意。

    而在后端，我们对所有接口都有详细的设计文档，包括接口的名称、参数名、参数类型、返回值名称、返回值类型、不同错误码的含义、各个参数的合法性检查条件等等。

  

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

  用户对主要功能，即发布、申请及相关管理功能的接受度挺高。这一点主要得益于在Beta、Gamma阶段中不断修复BUG的努力。相比Alpha阶段，Gamma阶段的产品BUG数量下降了非常多，现在几乎没有明显的影响体验的BUG。可以说离最初的目标，即完成一个“完整的产品”近了很多。Alpha和Beta阶段的成果更像是“原型”而非产品。

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

  根据用户反馈进行产品的修改是非常重要的。根据用户反馈进行改正的效率往往远大于闭门造车， 团队自己 闷头苦想。

  如果重来一遍：我们会在每个阶段的最终发布前一周先发布一个版本，并收集尽量多的用户反馈，根据用户反馈修改后再发布迭代的最终版本。这样每个迭代发布的产品质量会高很多。

计划

• **是否有充足的时间来做计划? **

  是的，因为每阶段前都有半周时间作为计划与设计的时间，因此计划时间充足。

  我们的计划流程是：

  • 在开发阶段前，经过讨论，由PM决定这一阶段的总体目标，并以周为单位分解总体目标
  • 每周前由PM规划本周的工作流程，将本周工作分解至不超过2天时间的具体工作。

  这样的计划流程，保证了在每日任务不会过于臃肿的情况下，对项目整体进展有精准的掌握，确保主要任务的顺利完成。

  这一点在Gamma阶段依然保持。并且在每个迭代末尾的发布后，我们就会考虑下个迭代的大致方向。

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

  对于不同意见，我们会给成员充足的时间，通过语言、手稿等方式展示自己的想法，阐述这么做的原因，最后达成共识，或少数服从多数。对于不同类型的问题，比如规划、设计类问题，前端问题，后端问题，我们会着重考虑PM、前端负责人、后端负责人的意见。

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

  我们原定的主要功能全部都完成了。

  有一些规划之初就作为“有时间的话可以完成”的额外任务没有做完。例如发布举报功能、提醒功能。

  没有完成的主要原因有：

  • 在既定页面上添加某些功能，难以保证页面整齐美观，可能需要大幅改动页面，会花费非常巨大的精力，得不偿失。
  • 期末阶段，大家有比赛、期末复习、期末大作业、实习要忙，各有各的事，时间紧缺。

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

  从最后的结果来看，个人资料页面似乎并没有什么用。

  之所以做个人资料页面，是以为最初设计中，打算让用户直接上传一个文件作为申请一个招募时的简历，因此实现了一个个人资料页面，储存用户的一些基本信息。但是由于微信小程序不允许上传除了相册中的照片、视频意外的文件，所以无法实现。为了解决这个问题我们实现了简历模板的功能。而个人资料中填写的项目，简历中基本都有。

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

  任务定义：

  • 前端：具体页面的原型图，其中按钮的功能
  • 后端：数据库的详细设计规格，接口的详细设计规格

  交付件：

  • 前端：可体验的前端页面
  • 后端：可供前端直接调用的后端接口

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

  在Beta阶段的发布中，遇见了一个很大的意外，导致我们的发布被拖延了一段时间。

  意外及风险：在Beta阶段中，我们前两次发布小程序时顺利通过。但是在修复了部分BUG后，进行第三次发布时（除了修复了BUG以外与第二次发布没有任何区别），我们的发布以“个人版小程序不能有信息发布功能”为理由被打回。之后的审核一直没有通过。直到我们升级为了企业版小程序。

  没有估计到的原因：没有想到完全一样的小程序，一天前毫无阻碍的通过了审核，一天后就再也无法通过审核了。。。这一点某种程度上来说是不可预知的。。。

• 在计划中有没有留下缓冲区，缓冲区有作用么?

  缓冲区：Gamma阶段中，由于有Beta阶段的教训，我们留出了将近一周的时间作为发布的缓冲时间。

  作用：避免出现一些意料之外的问题再次出现。同时，也为宣传留出更多时间，以积攒更多的用户量。

• 将来的计划会做什么修改？（例如：缓冲区的定义，加班）

  如果有下一阶段的话，大家会尽量先大概告知最近的情况，将大家的复习、大作业、比赛等等占用时间的事项更多的、更详细的纳入计划范围。

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

  我们的经验：不同类型的任务尽量分离，让不同成员完成。尽量让每个人在同一时间内只负责某一种类型的工作。这样可以提高大家完成任务的速度和质量。

  若重来一遍，我们会尝试将每个人每日的工作更新在ISSUES中，不知这样的话会不会让每日任务的追踪、燃尽图更加合理。

资源

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

  同Alpha阶段一样，资料基本足够。最紧缺的是时间资源，因为有团队成员忙于实（jia）习（ban）、考研加分相关的比赛，Gamma阶段还有各科期末的考试、大作业等。

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

  在Gamma阶段，各项任务需要的时间主要是根据前两个阶段的经验来估计的。从最后的结果来看，我们对各项任务时间的估计还是非常准确的。

• **测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度? **

  测试阶段的各类资源足够。因为留出了足够的时间进行测试。

  在有了Alpha阶段的经验之后，我们正确意识到了非编程任务的难度，并分配专人完成相关任务。

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

  我们一致同意最后Gamma阶段的分工是比较合理的，抛开个人能力的些微差距，大家完成任务的效率都是较高的。

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

  一些难以直接统计、难以数字化的资源也非常重要。比如在申请企业版小程序时，有认识的朋友、同学拥有注册企业，可以提供帮助的话，就是一项非常难得、非常宝贵的资源。

  我们会做的改进：如果重来一遍，我们会提前了解产品所在的平台有何限制，而不是仅仅了解这个平台有何优点。

变更管理

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

  是的。因为每日的讨论及交流非常频繁，团队成员往往也一起吃饭、上课，因此消息的同步速度很快。

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

  我们认为一个功能的重要程度，取决于这个功能的缺失对产品的功能完整性及用户体验的影响程度，也就是“删去这个功能会造多大的影响”。

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

  Gamma阶段的出口条件概括为：完成一个界面美观的数学建模比赛组队模块。
  数学建模模块的具体功能如下：

  • 填写、修改数学建模相关信息功能
  • 用户填写问卷后，根据用户填写的答案自动打分，并匹配相应队友
  • 通过搜索对特定用户发出组队邀请
  • 通过首页推荐模块对匹配的队友候选发出邀请
  • 管理自己发出、收到的所有邀请
  • 用户不满意当前队伍时，可以自行退出当前队伍
  • 当A用户向B用户发出了邀请，且B用户还未答复，或B用户与A用户处于同一队伍时，不再向A用户推荐B用户

• 对于可能的变更是否能制定应急计划?

  能。若每日总结时发现有任务未能完成，会对本周接下来的任务、项目总体计划进行及时的更改。

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

  能。比如临时新添接口的设计、展示用各界面的屏幕捕捉gif等，这类临时工作我们会优先分配给平时完成任务较少的同学，即保证了公平，也给他们赚取更高贡献分的机会。

• 我们学到了什么? 如果历史重来一遍,我们会做什么改进?

  我们的经验：一开始的计划越详细，后面需要做的更改就越少，实现时所作的无用功就越少。

  如果重来一遍：我们会在每个迭代计划阶段的一开始，就完成每个页面的布局、功能设计，这样前后端都能有更加具体的目标，所需要做的更改就更少。

设计/实现

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

  时间：设计工作在设计与发布阶段完成。

  负责人：产品的功能、页面设计由PM完成。同时也采纳了其他成员的合理建议。

  后端接口由PM、前端、后端共同讨论决定每个接口功能后，由SZY汇总为具体的文档。

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

  基本没有这种问题。因为我们对最后所要实现的目标非常明确。因此计划阶段基本没有这样的情况。

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

  使用的工具：使用了单元测试。使用的工具是Django Coverage。还进行了服务器的压力测试，使用了locust。除此之外还使用了git bash管理代码，issues管理任务，process on进行原型图的设计。

  这些工具还是能提高相应任务的完成效率及质量。

  没有使用UML文档，但是有前后端相应的详细设计文档。

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

  产生BUG最多的是一些逻辑关系复杂部分，比如在数学建模模块推荐队友时的屏蔽规则。

  没有想到的主要原因是需要屏蔽的情况较多，但是屏蔽条件由不过过多，因为整体用户量有限。

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

  代码复审：代码复审主要由前后端的负责人进行。

  对于代码规范的执行程度仍需要提高。尤其是前端。

• 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

  我们的经验：微信小程序本身还不是非常成熟，其内置的许多工具在安卓和IOS系统的适配上存在许多问题，一定要对于两种操作系统做详细的测试。

  如果重来一遍：我们会在实现每个页面后就尽量对两种系统都进行测试。这样可以更彻底的检查系统适配问题。在全部完成后再进行测试，很容易有遗漏，并且那时全部功能都已经完成，可能会出现“牵一发而动全身”的情况。

测试/发布

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

  有。在开发阶段结束后分别对前后端进行测试，分别进行了不同机型的功能测试、单元测试和服务器的压力测试。详细测试请见Gamma阶段测试报告

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

  是的。在申请发布小程序前，我们对所有页面及功能都进行了一边复查。

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

  使用了Django coverage来跟踪我们的单元测试的代码覆盖率，利用Locust来对服务器的压力负载能力进行了测试。详情同样见Gamma阶段测试报告

• 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？

  微信小程序自带有对各页面的截载时间统计功能。这些工具主要可以让我们了解哪些页面加载的最慢，最影响用户体验，并有针对性的对比如与后端的通信方式、交换的数据等方面进行修改。

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

  在Beta阶段中，我们前两次发布小程序时顺利通过。但是在修复了部分BUG后，进行第三次发布时（除了修复了BUG以外与第二次发布没有任何区别），我们的发布以“个人版小程序不能有信息发布功能”为理由被打回。之后的审核一直没有通过。直到我们升级为了企业版小程序。

  没有估计到的原因：没有想到完全一样的小程序，一天前毫无阻碍的通过了审核，一天后就再也无法通过审核了。。。这一点某种程度上来说是不可预知的。。。

• 我们学到了什么? 如果重来一遍， 我们会做什么改进?

  我们的经验：单元测试非常有用。保持单元测试的跟进，可以让测试全面、简单很多。

  如果重来一遍：如果重来一遍，我们会提前申请企业版小程序。避免发布出现问题。

团队的角色，管理，合作

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

  确定依据：根据每个成员的性格，以及其在之前阶段中的表现来决定。

  因为有之前阶段的经验，具有一定参考， 因此每个人的分工都是大家认为比较合理，比较适合自己的。

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

  有。不懂的问题请教其他成员、在平时的交流中帮助其他成员等等。

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

  出现问题时，首先通过QQ、微信通知对方，能在线解决的小问题争取在线解决。若问题比较复杂或者麻烦，就到某一方的寝室详细讨论，当面解决。

总结

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

  我们认为，在经过了三次迭代过后，我们的团队基本达到了“已管理级”的要求。

• 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?

  我们认为我们的团队达到了“规范”阶段的基本要求。

  • 我们的所有讨论、工作都是透明的，成员也比较认可PM的能力，前后端各自成员也有一定的自管理。
  • 因为分工的细化、固定，不再需要PM不断的提醒、催促成员完成各自任务。
  • 我们的目标统一明确，有较高的一致性。
  • 大家的合作非常愉快，关系友好。

• 你觉得目前最需要改进的一个方面是什么?

  我们认为可以将Issues交由负责完成任务的相关成员自己管理，而不再是PM统一管理。这样ISSUES的进度追踪本身就起到了一个监督自己完成每日工作的功能，其次，也能对整体实现过程有更好的记录，这样能更好的发现存在的问题。

• 对比敏捷的原则，你觉得你们小组做得最好的是什么？

  我认为我们小组做的最好的是：

  • 无论团队内外，面对面的交流始终是最有效的沟通方式

    我们团队的成员面对面沟通的时间远大于在线交流时间，尤其是前、后端主要开发人员，在开发时基本是当面一起编程，保证了交流的效率。

  • 可用的软件是衡量项目进展的主要指标

    在计划时，每阶段任务基本以可使用的，功能完整的页面作为任务目标，因为这一目标涵盖了具体的前端页面以及配套的后端数据库。

    在实际开发过程中，每日总结时也以具体页面的完成情况、页面中功能的完整度作为衡量的主要指标。

  • 投资最大化

    在Gamma阶段，由于与期末重叠，因此时间紧张。所以我们将有限的时间都花费在了必要的页面、功能上。最后直接根据用户反馈进行改进，尽量实现投资最大化。

• 在下一阶段中我们要改进的地方

  • 寻找更可靠、更好看的UI控件：自己开发大部分UI是非常浪费时间、非常不划算的。网上有许多现成的代码。尽量少重复造轮子可以留出更多时间实现其他功能。
  • 宣传工作的加强：由于微信小程序本身非常便捷，不需要下载，不需要注册账号，通过微信可以直接进入并登陆。因此对于小程序来说，宣传的效用比是非常高的：只要让潜在用户知道该小程序的存在，因为使用的成本非常低，用户就有很高的概率会进行尝试。

讨论照片