Beta/Gamma事后分析

目录

• 设想和目标
• 计划
• 资源
• 变更管理
• 设计/实现
• 测试/发布
• 团队的角色，管理，合作
• 总结
• 对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
• 照片

设想和目标

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

• beta阶段：
  • 实现学生认证从而将用户信息与学校数据挂钩，给社团提供管理功能，给社员提供入社申请功能，实现简单的社团讨论区，实现网页端供社团录入社团的各种信息，页面风格统一、美化。
• gamma阶段：
  • 实现活动通知功能以及海报生成功能，从而给社团活动的宣传和提醒提供支持。
• 尽管没有要求，但我们坚持在每个阶段开始前进行需求分析，确定当前阶段的核心目标并罗列工作，进行分配。
  • 【Beta】设计与计划
  • 【Gamma】设计与计划
  • 保证了在开始干活前目标定位清楚
• 典型用户和典型场景在【Gamma】“北航社团帮”展示博客已描述

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

• 上述功能均实现
• 交付时间：
  • beta阶段5.24号上线，27号有一次bug修复更新
  • gamma阶段6.14号上线，17号有一次bug修复更新
  • 均按时交付了
• 原计划达到1000用户，入驻社团50个
  • 截止6.17号用户量达到1100，入驻社团67个
  • 更详细的各项用户数据比较见【Gamma】“北航社团帮”展示博客
  • 我们达到了用户数量目标，并在产品迭代过程中用户实际使用小程序的实际不断提高，说明我们的产品逐渐变得吸引用户。

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

• 有所提高
• beta阶段
  • beta阶段我们的工作量大概是alpha阶段的两倍左右，在工作量大幅度增加的情况下，我们依靠详细的需求说明文档保证前后端的高效对接，接口更改次数和alpha阶段相近
  • beta阶段后端进行了后端代码风格统一
  • beta阶段服务器崩溃次数比alpha少的多
• gamma阶段
  • gamma阶段进行了前后端注释添加和冗余代码删除
  • gamma阶段整理了文档
  • gamma阶段每个新功能添加测试后都当即上线，产品更新的频率提高，不再向以前一样等所有功能完成并统一测试后才批量上线

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

与我们的预期基本一致，我们在beta阶段发布后通过社联进行了硬性推广，截止6.17号67个社团入驻，50个社团使用过网页端进行社团信息编辑，社团自主发布16条新闻和12个活动，总数看起来不多，但也要考虑beta阶段发布之时已接近学期末，不在社团的活跃时间段内。gamma阶段提供了更好的宣传支持后也有更多社团管理人员表示愿意下学期活动时在小程序上进行宣传，还有一些社团管理人员则表示如果小程序被更多用户所了解他们会愿意更多地在小程序上发布信息，而我们用户量也在稳步上升。另一方面，学生认证功能上线后渐渐被认可，学生认证人数快速稳定上升，一般用户也表示如果有更多新鲜的社团信息他们会愿意使用我们的小程序进行了解。总体而言，用户对我们的重要功能接受程度在不断提高。

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

beta阶段压力过大，考虑将部分工作挪到alpha阶段。

计划

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

• 是的。从alpha阶段起，我们做计划的流程便是：
  • 每周开始前，由PM定下前后端在本周的任务和目标，并尽量分配具体到每个人的本周目标，同时声明一些特殊时间节点，比如A同学的B任务必须在周x前完成，因为B任务是另一位同学的前置条件。
  • 然后，每个人根据自己本周的目标，以及自己本周其它个人事情的安排，列出自己的每日计划，也可以提出对自己的任务进行转移和调整。（自己做的计划，跪着也要完成）
• 这样做计划的方式，能让团队成员自由把控时间，这样比PM直接分配每日计划要更方便、更人性化、更有可行性，做计划的效率也充分提高！

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

成员可以对自己的本周任务提出疑问、调整或转移，PM会解释自己这样计划本周任务的原因，若还有问题，则由成员们讨论解决，如果需要工作转移，双方协商同意后会保持同样的截止时间进行。

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

• 大多都完成了。
• 没有做完的原因主要包括：
  • 主要原因：该任务难度较大，或不是本阶段的核心任务，权衡后决定暂停、取消或延迟
  • 自己的时间没有安排过来，有其它的事情，过程中有小的延迟，不影响结果。
  • 项目整体目标有变动，原本计划的工作暂停、取消或延迟。

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

大都有清楚定义和衡量的交付件，主要是以下几类：

• 后端开发任务：代码、接口文档

• 前端开发任务：代码、开发版二维码

• PM：博客按期提交、更新issue、数据整理文档等

• 其它调研任务：调研结果小文档，或demo代码

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

• 基本上是按照计划进行。
• 有这么些小意外：
  • 图床bug：beta阶段我们使用了云服务器存储图片，难度相对较大，bug修复时间线较长
  • 无法实现最美好的梦想：自动爬取公众号文章并在小程序前端渲染。
  • 小程序页面跳转二维码需要接入微信服务器获取，并且只能在线上版本使用，造成了较大的调试困难，每次都必须提交审核后在线上版本调试

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

有。其实成员做每日计划的时候，大都会自觉在最后1-2天写上“机动分配”。而且其实PM会把真正的ddl提前，保证及时有少量工作拖延发布时间仍在真实ddl前

我们学到了什么?

Beta

1. 技能上的主要提升：
   1. 使用对象存储中间件来作为图床，使得网页端图片的上传成为可能，也使得小程序端获取图片更为流畅。
   2. 学会了使用redius保存10分钟有效的缓存key数据来进行社长认证。即，每当社长想要跟社联申请社长认证时，就由社联调用这个接口，输入社团id号，生成10分钟内有效的key，社长即可进行认证。
2. UI的设计：PM通过对比多种类似布局的小程序或APP，以及与前端同学进行讨论，来对许多页面的原型设计进行了改版，虽然只是处在模仿和拼接的阶段的，但效果已经不错，下一阶段会争取和设计师合作，从模仿提升到设计。
3. 需求文档的维护和更新：上一阶段对需求文档没有进行更新，而只是停留在口头交代，本阶段对需求文档进行了维护和更新，使得团队成员对需求的理解更加深入，不足的地方在于需求文档的书写不大规范还需完善。

Gamma

1. 技能上的主要提升：

   1.为使用微信的服务：小程序码页面跳转和模板消息推送，我们将服务器接入了微信服务器。熟悉了微信服务接口的使用流程并在实践中积累了一些debug经验。

   2.前端学会用js生成图片（海报），实现过程可谓到处是坑，相当艰辛。

   3.后端实现了一个简单的定时任务系统，用于在社团活动前开始24h推送消息到用户微信。

   4.需求筛选。Gamma阶段我们仍有很多可以实现的功能（之前版本功能的拓展，社联希望我们支持的功能，社团管理人员希望我们支持的功能，一般用户希望我们支持的功能），我们最终综合实现成本、收益分析、后续维护问题以及用户需求调研进行了筛选决定了gamma阶段实现的功能。锻炼了软工的需求分析能力。

   5.面向当前阶段用户建立了一个答疑群，对小程序使用进行了答疑，用户反馈了很多Bug以及意见，对小程序的改善有重要作用。锻炼了与用户沟通的能力。

2. UI设计：这一版没有大改UI，新的UI继承上一版的风格，小程序UI整体风格逐渐统一。

3. 文档维护和代码注释：这一版补充了一些技术博客、配置文档，保持新接口在接口文档中的更新，并在代码中加入许多重要注释，方便后续维护和增量开发。同时，前后端都对冗余代码进行了删除，有助于软件工程质量的提高。

资源

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

基本还算足够，团队整体的时间和能力，我们收集的数据和需求等，都基本能够完成各项任务。gamma阶段成员时间相对紧张，只完成了核心的高优先级需求，建议课程组删除gamma阶段或缩短gamma阶段实际scrum时间。

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

由每个人制定每日计划时自己估计，一般来说精度较高，遇到坑时则可能出现大幅度超过预期时间的情况。

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

• 还算足够。测试分为前后端，前端测试直接由PM完成，后端单元测试由该单元的编写者负责测试，后端覆盖率测试由振亚完成，后端压力测试由廓然完成，分工还算合理，资源还算足够。（虽然还蛮肝的
• 是的。PM觉得原型设计相当费劲，尤其在beta阶段统一风格重新设计时经过了激烈的讨论，同时写博客也很费劲。

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

• 有时候有这种感觉。不过，虽然有人在这个任务上能做得比我更有效率，但他还是应该去做他该做的事，每个人按时交付自己的任务，整个项目才能正常推进。所谓更有效率大多也只是熟练程度的差异，做多了自然就熟练了。

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

• 尽早进行完整了UI设计考虑，早晚都要改不如一开始做好
• 根据测试工作量让更多人参与测试前端（beta阶段PM表示前端测试累的吐血

变更管理

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

是的，不紧急的在每日例会上通知，紧急的变更消息直接由PM私聊通知到位。

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

PM根据对项目进度的整体把握、需求优先级、需求实现难度等做出权衡和判断，然后在例会上大家可以对此提出质疑。

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

• 兼容性：对Android和IOS操作系统、不同版本的微信都兼容。
• 易用性（用户友好）：底部导航易用，功能入口明显，交互结果的弹窗提示等。
• 功能正确性：各功能正确，页面跳转正确。

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

是的。对于很重要的变更，我们还会制定plan A 和 plan B.

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

• 经常出现的一个情况是，后端将接口设计并实现后，前端发现之前写的请求数据文档还差点东西，于是向后端提出新的接口。
• 成员们能够有效处理。团队成员具有自己的判断力，会先判断这个意料之外的工作任务是否真的必要，经常会向PM提出质疑，甚至请求调整该任务。团队成员的主动判断和质疑，以及PM的及时沟通和处理，使我们能够有效地处理意料之外的工作请求。

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

回过头看，在变更响应上我们已经做得很好了，面对变化的需求开发人员能提出自己的观点并积极对接。非要说改进的话，大概就是一开始把需求写的更更更确切一点，调研地更清楚，优先级更明确，从而变更可以更少些。

设计/实现

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

• beta和gamma阶段第一周（计划和设计）进行。
• 主要由PM完成功能、需求、原型方面的设计和计划，由少昂和雨飞完成技术架构方面的设计和计划。
• 是的。

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

有遇到小细节上的模棱两可，但这些可以暂不理会，毕竟现实和计划是有差别的，计划时更多的是考虑全局的东西，特别细节的东西不需要过于纠结，模棱两可即可。

gamma阶段有大量需求选择，我们在任务设计上进行了详细的讨论和调研进行需求筛选。

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

• 我们运用了单元测试、代码覆盖率插件、gitlab代码管理、issue进度管理、墨刀原型设计、xmind思维导图等来帮助设计和实现。
• 这些工具蛮有效的。
• 我们没有使用UML文档

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

• beta阶段学生认证功能，因为数据库字段不统一（如一个学院的名字后面还有括号说明等类似问题）
• gamma阶段的二维码跳转
  • 只能上线后才debug
• 对于前者，数据库是从学校网站上某公开文档爬下来的，然后学校数据库使用的名字并不对应，属于意外
• 对于后者，是微信开发的限制，没办法突破。
• 二者上线后收到Bug反馈后都快速、及时地进行了问题定位，并解决。

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

• beta阶段后雨飞加入后端代码复审，极大的提高了复审的效率。前端代码无复审机制。
• 还算严格。

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

• 我们会让功能更加明确，让前后端人员对需求有比较深入的理解。

测试/发布

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

有。

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

是的，在beta和gamma阶段的最后4天，我们进行了正式的、全面的验收测试。分为前后端，前端测试直接由PM完成，后端单元测试由该单元的编写者负责测试，后端覆盖率测试由振亚完成，后端压力测试由廓然完成，分工合理，完成度较好。

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

是的。后端代码覆盖率测试使用了插件；小程序自带性能测试指标工具。

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

• 后端进行了压力测试，前端使用的是小程序自带的性能测试指标工具。
• 从软件实际运行的结果来看，这些测试工作还是有点用处的。
• 需要改进的地方就是没有在各种机型上进行小程序的前端性能测试。

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

发布非常顺利，alpha阶段1天过审时我们感慨微信的工作效率，beta阶段和gamma阶段竟然半天就能过审，微信的审核效率之高令人震惊。

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

如果重来一遍，我们会把测试做得更充分、更细致，这就需要我们提前完成开发任务，给测试留下更多的时间。

团队的角色，管理，合作

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

主要是根据成员的意愿，同时会考虑团队的需求，来确定每个人的角色。有些人是想做自己擅长的，这些人是“人尽其才”，有些人想挑战没有经验的角色，我们也尊重他的意愿。beta阶段我们没有进行角色轮换，主要原因是工作量较大。gamma阶段4个成员更换了角色，体验不一样的工作，也都快速学习后努力完成了开发任务。

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

有的。主要是 后端内部、前端内部之间互相帮助，比如遇到问难时请教经验比较丰富的成员，或者觉得任务难度较大，请求进行协助，

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

小问题可以线上聊天解决，比较重要的问题一般会提上会议议程，在每日例会中讨论解决。

总结

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

CMMI的第二级，即管理级。我们的项目在实施时能够遵守既定的计划与流程“在管理级水平上，企业在项目实施上能够遵守既定的计划与流程，有资源准备，权责到人，对相关的项目实施人员有相应的培训，对整个流程有监测与控制，并与上级单位对项目与流程进行审查”。

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

alpha阶段出于磨合阶段后半期。beta阶段和gamma阶段已经充分熟悉队友，能以较高的效率合作，属于规范阶段，可能离创造阶段还有些距离，毕竟做的功能都算不上很新颖。

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

在接口设计和复审确认阶段，需要留更多的时间，由前后端和PM三方人员参与，以减少后续更改接口的数量。

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

这里是敏捷开发的12条原则，其中我们做得最好的是：

• [4]业务人员和开发人员在项目开发过程中应该每天共同工作。
  • 具体来说，就是我们每天都开例会，交流需求、功能、和技术，同时PM会在团队群、前端群、后端群中把握进度、协调解决问题。
• [10]保持简明——尽可能简化工作量的技艺——极为重要。
  • beta阶段和gamma阶段开始前我们都做了详细的需求分析和筛选，保证工作优先级的正确，也细化了工作目标，使任务尽可能简明容易理解。
• [11]只有能自我管理的团队才能创造优秀的架构, 需求和设计。
  • 我们的每日计划制定由个人来完成，具体的：由PM定下每个人/小组的本周目标，同时声明一些特殊时间节点，然后，每个人根据自己本周的目标，以及自己本周其它个人事情的安排，列出自己的每日计划，也可以提出对自己的任务进行转移和调整。这样，成员们自我管理，执行自己制定的计划，同时接受团队其它成员的监督。
  • 每日例会上，每人汇报今日进度，互相监督，然后积极讨论自己今天遇到的困难等，并对前端的页面提出意见，不断进行完善。
• [2]敏捷流程欢迎需求的变化, 并利用这种变化来提高用户的竞争优势。
  • beta阶段发布后我们建立了一个社团管理人员的答疑群，不断收到用户提出的需求反馈，我们并没有急于实现，而是对这些反馈进行了详细分析和筛选后才确定我们的工作目标。

照片

时间：2019年6月18日 22:30-23:00

• beta阶段发布后我们也进行了事后分析，主要罗列剩余的bug和讨论角色更换问题。