标签：功能 week12 用户 开发 测试 alpha Alpha 灵境 进行

Alpha阶段事后总结

项目	内容
这个作业属于哪个课程	2022年北航软件工程
这个作业的要求在哪里	团队项目-Alpha阶段软件发布声明

Part1 设想和目标

1.1 产品

① 产品定位

『主打VR Chat功能的高校元宇宙』

主要考虑对于普通大学生和教师的社交，在设计之初没有考虑到有许多单纯想获得乐趣的找乐子人。之后尝试设计更多娱乐性功能，同时将娱乐功能和一些常见社交功能相结合进一步体现社交属性。

② 典型用户和场景

对典型用户和典型场景的理解是否一致？

在alpha阶段典型用户和场景主要是为了写而写，没有进行非常一致性的表述，没有特别设计针对每种用户的具体的功能。beta阶段考虑将典型用户场景与具体的功能进行绑定

③ 目标完成度

• 原计划的功能做到了几个？

  功能	描述	开发阶段	完成情况
  用户注册	大学学生或教师使用自己的身份信息进行注册	Alpha	✔
  用户登录	用户使用手机验证码或者账号密码登录	Alpha	✔
  登录引导	登录后进行必要的引导	Alpha	❌
  个人信息	个人信息管理	Alpha	✔
  设置	app设置与身份信息管理	Alpha	✔
  首页学校地图	选择学校进入	Alpha	❌
  校园场景社交服务	本校/其他学校校园场景社交服务	Alpha	✔
  我的空间	个人自定义空间	Alpha	✔

• 按照原计划交付时间交付了么？

  由于各种bug延迟了接近2天

• 原计划达到的用户数量达到了么？

  原计划100，实际约60

④ 用户反馈

用户对重要功能的接受程度和我们事先的预想一致么?

用户对于高校场景的喜爱和体验与我们事先预想一致，同时由于没有太多具体功能，用户粘性不够也是事先预想到的。

设计并发布问卷，包含已有功能评价反馈，待做功能优先级，对每个功能的需求程度，以此为依托确定beta阶段的开发目标。

⑤ 经验教训

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

• 前端代码规范
  • unity文件的组织管理标准化
  • git版本控制流程的优化
• 服务端安全性
  • 对用户鉴权进行细致考虑和处理，构建隐私安全性更高的服务。
• 和中传对接
  • 加强与中传同学的交流，在我们自己的实际开发难度以及目标和他们的设计目标之间找到平衡点。
• 完善需求分析
  • 发问卷，调查已有产品缺陷，确定beta阶段侧重点。

1.2 计划

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

  由于各种原因，alpha阶段的开发往往缺少一定的计划，beta阶段在开发自己分配的功能前，需要先进行详细设计和技术调研，再继续进行开发。

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

  主要依靠语音或者面对面交流交换彼此的意见，并不断磨合形成最终的结论。比如以下例子：

  • 个人空间形态改了三版，主要是依靠yrb和中传同学的反复讨论得出。
  • 首页的形态经过多次会议的意见打磨。
  • lhy和fzc关于用户信息管理以及JWT安全认证的内容进行了多次讨论，有问题及时进行语音交流，确保双方对于同一个API的认知保持一致
  • fzc和xwq对于技术方案进行及时讨论
  • 需求分析与初始计划阶段对于开发目标以及是否完全自行开发产生了一些问题，最后是由两位PM向持有不同意见的同学进行了详细的解释，从而解决了问题。

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

  没有完全做完，主要原因有：

  • 前期对unity的技术难度预估不足，真正开发之后需要解决很多技术问题，包括代码整合，3D场景内物品拖拽，unityUI的布局，多人同步等难点。
  • 时间相对比较紧张，3周内团队内成员存在时间不统一的情况。不能自始至终都有充足时间实现自己的任务。

  beta阶段的解决是，前端同学加强沟通交流，将lyyf设置成救火队员的角色，在完成自己任务之后在有空时加入其他部分开发。同时，由fzc负责文字聊天及消息系统的开发，减轻前端同学压力。

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

  部分同学对于一些细节过分较真，导致没有从根本上解决问题

  没有善用unity的资源商店提供的工具，一些功能的实现上重复造轮子了

  门户网站的管理系统，由于没有人有空来进行维护，因此其实是质量很低的，也没什么价值

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

  任务的定义和交付仍然停留在较为模糊的表述，没有非常清晰的描述，beta阶段会制定严格的工作流程和需求-任务-缺陷描述规范。

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

  基本上没出现重大意外，但是语音交流和ios发布出现了些许问题，主要原因是实际需要时间与预估时间有较大差距。ios发布当天苹果官网还崩溃了。

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

  留下了一些灵活处理的空间，比如初始任务时给tsq分配的任务相对较少，从而在中后期测试和ios发布时依靠他完成了很多工作。同时，类似文档编写，安卓发布，网站搭建等初始时都放置在缓冲区中，合适时间分配给合适的人做。

Part2 设计与实现

2.1 功能设计

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

  • 对于基本的功能由前端同学进行主导设计，后端同学辅助进行接口设计
  • 复杂的功能和中传同学进行商议后进行确定

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

  • 在例会时进行解决，集合众人的想法
  • 直接由当事人进行面对面或语音交流

2.2 bug分析

• 什么功能产生的Bug最多，为什么？

  • 用户相关的接口。原因是用户鉴权和信息保护的处理相对较为繁琐复杂，相应的逻辑也会带来很多bug。
  • 个人空间。原因是3D物品拖拽和unity中的定位较为复杂，如果自己实现往往需要很多控制代码。
  • 好友管理相关功能。原因是添加好友—查看申请列表—同意或拒绝整个流程较为复杂，需要前端后端对每一个API接口都保持完全相同的认知，才能实现好功能。

• 在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?

  • 安全性问题：用户可以查看修改其他用户信息。
  • 不允许语音会导致app崩溃的问题
  • 个人主页和好友消息的点击与显示出现了问题
  • 穿模，穿透点击问题。

  原因在于时间有限，往往是想着能跑起来即可的想法，没有注重安全管理。同时缺少充分的测试，即使测出来了也可能会缺少解决办法。

  ID	问题	优先级		时间
  #149	鼠标穿透bug	中		2022/05/14 20:46
  #148	完成对于版本号的判断和获取最新版本号	高	alpha总结与完善	2022/05/14 17:49
  #147	添加对于版本号的判断操作	高	alpha总结与完善	2022/05/14 17:49
  #146	改接口	中		2022/05/14 19:28
  #145	接口异常	中		2022/05/14 19:28
  #144	需要新的获取用户信息接口	中		2022/05/16 15:39
  #143	/user/getuserinfobyphonenumber接口逻辑错误	中		2022/05/16 15:39
  #142	关于token的处理	高	alpha总结与完善	2022/05/14 20:44
  #141	修改因为后端权限验证引起的变化	紧急	alpha总结与完善	2022/05/14 17:53
  #140	Model+Profession+School+Source+User接口权限判断	高	alpha总结与完善	2022/05/13 21:38
  #139	Friend,Hobby,Info,Message接口权限判断	高	alpha总结与完善	2022/05/13 21:38
  #138	修复好友申请界面的返回箭头比其它返回箭头偏大的问题	中	alpha总结与完善	2022/05/14 17:55
  #137	利用redis的管理员路由表在jwt prehandle方法内进行直接拦截	中	alpha总结与完善	2022/05/13 21:38
  #136	利用redis缓存数据库增加一个管理员路由表	中	alpha总结与完善	2022/05/13 20:00
  #135	优化注册登录、个人信息等静态页面性能，无更改时主事件循环要阻塞、不要轮询刷帧，从而降低CPU占用	中	alpha总结与完善	2022/05/13 19:14
  #134	后端实现完备的鉴权机制、消除非法请求的 500 Internal Error 问题	紧急	alpha总结与完善	2022/05/14 17:49
  #133	修复个人主页按比例缩放导致文字过小的问题	高	alpha总结与完善	2022/05/13 18:51
  #132	修复首页魔方点击不容易点上的问题	紧急	alpha总结与完善	2022/05/13 19:17
  #131	统一字体为“阿里普惠体”，统一代码文件编码为utf-8，规范字符串相关代码，修复iOS端获取验证码后及选择学校乱码问题	紧急	alpha总结与完善

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

  • 目前是每次代码合并的时候由团队内一位同学进行审核，只有审核通过才能合并到dev主分支。
  • 前后端都使用自动的代码风格检查插件，因此可以保证执行了代码规范。

2.3 变更管理

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

  • 由于每两天的组会大家都会阐述自己的任务完成进度和将要完成的事项，组内成员都能很好地通气，及时获知最新的任务以及项目进展。

  • beta阶段将让每个成员将coding和微信账号绑定，从而可以在微信里接受项目的一些通知和查看todo

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

  • 首先充分尊重每个同学的意见，在例会时确定好最紧急的任务，以及需要推迟的任务。
  • 犹豫不决时，根据实际技术难度和alpha计划阶段定的优先级，由两位PM根据实际情况确定最终的计划。

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

  • 对于每周日的产品体验，只要没有明显bug（比如闪退，无法运行）就认为是达到了出口条件
  • 对于正式的发布版本，需要等到已经没有明显bug可以修复的时候，不会有任何功能上的问题导致用户使用体验不佳，内部测试和审核没有问题之后进行发布。

• 对于可能的变更是否能制定应急计划?成员是否能够有效地处理意料之外的工作请求？

  • alpha阶段对于技术难度较大的部分我们也会采取解耦的方式，将每个人负责的部分分开，从而让每个成员都能单独地开发自己的部分，不会依托于其他成员的工作内容进行修补。因此遇到可能的变更也能以最小的代价让成员切换到新的任务中。
  • 由于团队内成员都比较负责，能力也较强，在遇到突然发布的任务时都能做出很好地应对。

Part3 测试与发布

3.1 测试计划

团队是否有一个测试计划？

• 后端有一套完整的测试流程，即开发者自行简单测试—单元测试—压力测试，同时在和前端对接后进行及时的修改完善。
• 前端主要是进行功能测试，即运行之后对于自己所负责的功能进行功能体验，并测试是否符合自己的预期。beta阶段可以加入自动化测试手段，用工具对app进行自动模拟点击从而进行测试。

① 前端测试人员

我们安排了tsq同学完成QA和测试的工作，对于前后端的代码进行测试和质量保障。

② 缺陷规范

Coding平台“缺陷”提出规范：至少包含bug出现位置、触发条件、出现频率、严重性等内容，此部分在第5部分进行严格定义，此处不再赘述。

③自动化测试工具

• 团队是否有测试工具来帮助测试？很多团队用大量低效率的手动测试，请提出改进计划：至少一个方面的测试要用自动化的测试工具，自动化的测试结果报告，比较测试结果的差异，等等。

• 后端代码实现了持续集成部署，内含编译，单元测试，推送服务器部署三个过程。详情可以参见【技术博客】Coding平台的Spring项目持续集成部署

• 前端使用unity的Unity Test Runner进行测试，参见官网测试指导

3.2 验收测试

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

  没有进行。此部分将在beta阶段由一篇验收报告测试进行体现，主要由全员对功能规格计划书中的验收标准进行测试，同时最终由QA成员tsq进行确认和发布。

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

  tsq利用自动化工具ab对服务端的最复杂接口进行了大规模压力测试，并确认了后端能够支撑1000人级别的用户规模。

  单元测试中也对于部分代码的效率进行了测试，起到了优化代码的作用。

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

  • 来自ch同学的hack导致一些alpha阶段没有解决的安全问题被暴露出来，我们及时进行了修复，目前的安全性和用户鉴权得到了较大幅度的完善和提升
  • 发布后大幅改动结果从而导致token不可用，用户被迫重新安装app。
  • 增量开发存在一些问题，由于C#本身是一种编译型语言，无法直接在之前版本基础上进行集成，只能重新更新版本。

3.3 经验教训

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

yrb

收获：学习了unity布局方式，对3d建模和游戏开发增进了解，实践体验软工项目团队合作

改进：unity中的版本管理和代码规范混乱，coding团队管理功能待熟悉

fzc

收获：学习了如何利用coding进行敏捷开发项目管理以及持续集成部署。同时熟悉了springboot后端框架，了解了redis，mybatis-plus，swagger，netty的基本用法，了解了jwt鉴权验证和基于session的用户验证。学习了如何集成阿里云的oss相关sdk以及腾讯云的短信相关sdk。

改进：项目开发流程上需要进行优化，任务管理分配，代码复审，测试流程，质量保障都有待完善。

lyyf

收获：学习了unity的多人网络同步、unity的语音服务

改进：后续攻克相关技术时应更带有目的性，开发时的团队协作也应更加规范

lhy

收获：学习了Unity引擎的使用和C#语言的基本用法，实践了一些设计模式。

改进：alpha阶段对于新功能、新需求的制定流程不够规范。在beta阶段将制定合理的流程规划每一个功能。

gcy

收获：学习了unity的基本操作与脚本的编写

改进：开发规范有待提高，开发流程的时间分配不够合理

xwq

收获：学习了netty框架和jwt鉴权的基础知识并且应用于项目之中

改进：后端代码规范约定不够细致，导致前后端中期一些处理没那么流畅。在alpha阶段结束后重新制定并优化规范，在beta阶段严格遵循。

tsq

收获：学习了SpringBoot下使用MockMVC结合JUnit的单元测试方法，学习了使用ApacheBench发送含header的POST请求进行压力测试的方法。学习了Unity + XCode打包发布iOS TestFlight APP的方法。

改进：发现问题之后要及时提issue，能够提高bug修复的效率。

团队整体总结

大家在alpha阶段都对于自己负责的部分的技术都进行了较为深入的学习，都有了比较多的了解，对于敏捷开发的基本流程有了一定的认知。

beta阶段需要更明确和完善的设计文档，分工，任务管理，开发测试流程

Part4 团队角色和管理合作

4.1 分工

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

  • 整体分工为前端4人，门户网站1人，后端2人，测试&QA一人
  • 基本上达到了较好的效果，每个人的任务基本都在自己的能力范围内，开发时没有人遇到了超出能力范围的需求，也没有人会觉得自己做的太多或者太少。

• 我们有足够的资源来完成各项任务么?各项任务所需的时间和其他资源是如何估计的，精度如何?

  • 由于分工得当，且事先考虑到了前端的难度，因此整体来说资源充足，每个人都能完成自己的目标
  • 时间的估计出现了一些不准确的情况，因为有些任务事先无法评估整体的时间需求，精度有待提升

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

  • 由于实际开发时美工设计与文案工作主要交给中传的专业人员进行制作，所以整体没有影响我们的开发进度。

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

  • 前端的部分同学在遇到一些场景内的UI自己不清楚怎么做时，没有及时求助lyyf和yrb，导致了自行开发效率较低的情况。后续需要更加统一组内资源，让每个同学的技术能力得到更大限度的发挥
  • 一些后端接口在调试和修改时出现了修改他人写的接口的情况，导致了一些bug。后期需要更加明确后端，测试人员的职责。

前端主要功能需求分工

beta阶段大致分工安排

前端

• TD线+人物模型绑定 gcy
• 钢琴湖 yrb
• 树洞 lhy
• 好友聊天 fzc
• 小房间（会议厅）+脸部 lyyf
• shader渲染调整 lyyf

后端

• 日常API编写 xwq
• 服务器维护与后端代码维护 fzc

QA&测试&发布

• 前端每两日一测 tsq
• 后端周测 tsq
• ios发布 tsq
• 安卓发布 lyyf

4.2 合作

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

• lyyf对于技术的深入研究和调研让项目没有卡在关键技术难点上，先后解决了多人同步，模型加载，语音聊天等关键难题。
• yrb对于UI的接近于强迫症般的要求和布局研究，带来了较为统一的界面。同时也带来了设计精巧的个人空间
• lhy对网络请求以及用户鉴权和信息管理的研究，让前后端对接更加流畅，对于接口统一规范的坚持也让后端的API定义部分代码得到了优化
• gcy持续的尝试各种demo让魔方，电影院等功能得以快速实现，同时对UI的统一化做出了重要贡献
• tsq对后端测试框架的研究，让严谨细致的单元测试和并发压力测试的实现成为了可能。同时对于ios端的了解也加速了ios端的产品发布
• xwq对netty框架的研究，让即时通信服务得以实现。同时在前期用自己对于springboot开发框架的了解让项目的API构建得以快速进行。
• fzc凭借对于阿里云，腾讯云等的熟悉，以及对于coding平台的了解，让持续集成以及稳定的后端服务得以实现。同时也不断跟进前端需求，解决了包括swagger，jwt在内的技术问题。

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

• 前端脚本代码规范，文件组织管理需要提前确定好
• 后端制定更详细的代码规范

4.3 每人说一说

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

  • yrb：代码规范，版本管理，要减少自己的强迫症
  • lyyf：明确功能优先级，让开发进度加速
  • gcy：个人时间安排需要更加科学合理。后端需要统一对一些接口返回数据的格式定义。
  • lhy：明确功能优先级，让开发进度加速
  • fzc：发布阶段需要各位都深入体验产品，并及时修复bug。平时开发时也尽量安排好个人时间，跟进团队的开发进度
  • xwq：后端需要协调好一些职责，debug时需要明确自己的修复范围

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

此处采取打分和举例的形式，满分3星。在我们的这次开发中，为了描述方便，客户可以认为是中传为主的创业团队。

1. 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意

   打分：⭐⭐⭐

   举例：我们在alpha阶段通过持续的开发集成，最终发布了版本，带来了60多名用户，用户群人数达到80+，带来了一定的用户积累，同时让用户体验到了初始版本，获得了许多乐趣。

2. 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。

   打分：⭐⭐⭐

   举例：在设计之初，客户提出了一些基本功能，而中途在他们的设计完善之后，加入了诸如AR换脸在内的功能，我们也做出了及时调整，让产品更加有竞争力。

3. 经常性的交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。

   打分：⭐⭐⭐

   举例：我们每周都会发布一个新版本供内部包括中传的美工UI建模同学以及开发人员进行内测。而且每周的版本都是可以正常运行使用的。同时每天服务端会进行一次持续集成，不断进行单元测试和部署，为客户端提供数据服务支持。

4. 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。

   打分：⭐⭐

   举例：开发阶段，我们和中传的同学不断试用产品，并提出自己的建议。不过由于大家的事务繁忙，并没有做到每天都一起工作。

5. 围绕被激励起来的个人来构建项目。给他们提供所需要的环境和支持，并且信任他们能够完成工作。

   打分：⭐⭐⭐

   举例：团队内部鼓励成员深入挖掘技术，alpha阶段一共有4名同学各自发布了1篇技术博客，对自己研究的内容进行了深入探讨，包含unityUI布局，多人同步技术调研，后端持续集成部署等。我们信任每个个体，让每个成员各司其职，并将自己负责的部分研究得透彻深入。

6. 在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。

   打分：⭐

   举例：这一点做的并不好。因为各种原因，alpha阶段我们并没有做到定期面对面交流，更多的是语音交流，这样会带来一些效率问题。不过前端和后端对接时也常常采用语音聊天的形式及时跟进问题，高效解决问题。

7. 工作的软件是首要进度度量标准。

   打分：⭐⭐

   举例：alpha阶段我们每到一定的阶段就会由lyyf打包一个版本供大家使用，从而提升了整体的开发热情。但是除了周发布以外的产品并没有做到都可以完全无明显bug的运行。

8. 敏捷过程要保持可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。

   打分：⭐

   举例：alpha阶段出现了每周的进度不统一的情况，前期开发进度相对缓慢，第二周的进度却明显更快，一方面是由于第一周的技术攻关需要时间，另一方面也是我们没有做到定期线下集体开发交流问题。

9. 不断地关注优秀的技能和好的设计会增强敏捷能力。

   打分：⭐⭐⭐

   举例：后端在开发之前就调研了并发框架，并确定了springboot+netty这一主流方案。用户鉴权设计之初确定的是利用session，然而之后因为实际开发时发现基于session的认证已经不适用于客户端服务端结构了，因此调整为更流行的jwt认证方案，从而加速了用户鉴权功能的实现，提升了稳定性。前端在设计之初想过直接用websocket与后端相连的方式进行多人同步，但是之后发现这样工作量较大，且自己实现的往往不稳定，因此经过调研使用了unity中的开源框架mirror，高效的解决了多人同步问题。

10. 简单----使未完成的工作最大化的艺术----是根本的。

    打分：⭐

    举例：设计之初对于一些功能的描述并不准确，没有让每个功能都简单清晰。

11. 最好的构架、需求和设计出自于自组织的团队。

    打分：⭐⭐

    举例：我们团队虽然是自组织，但是并没有做到前端的良好架构，原因是一开始没有确定严格的文件组织规范。

12. 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。

    打分：⭐⭐

    举例：每次例会都会总结一段时间内的工作，但是并没有每次都进行反省和及时提升。alpha总结阶段大家通过线下交流和线上的聊天，畅所欲言，对过去遇到的问题进行了及时反思总结。做出了以下调整：1.完善了用户鉴权以及服务端安全控制。2.发布了用户调查问卷，对需求分析做出完善。3.通过事后总结确定了beta阶段的开发测试流程，以及确定了细致的功能需求。

• 团队在下一阶段应该如何提高软件工程的质量呢？

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

    更加明确每个人各自的职责，定义清晰的文件组织管理规范，每两天做一次代码复审和测试。

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

    前端的代码架构进行优化，清除无用的代码。

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

    使用相关插件进行git版本控制

• 项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？

  记录用户每一次的请求日志，将用户日志保存到数据库中，从而知道每天和每周的用户活跃量。

• 项目文档的质量如何提高？

  通过分担给多个人的方式提升每一部分文档的质量

  通过PM最后的审核进行进一步美化和修改

• 团队组织管理， 有什么具体可以改进的地方？ （关于PM、“人件”、绩效考核）

  平时需要更加细致的使用coding自带的数据统计功能进行团队开发管理，细致的安排需求，任务和代码审核。

  分工上需要安排救火队员，对于其他同学的技术问题做出及时的增援和回复。

• 对于软件工程的理论，规律有什么心得体会或不同意见？ 请看阅读作业“这个作业的期中阅读”

  • 软件工程其实是一个社会活动。对于我们的项目来说，从诞生之初就不仅仅是一个代码层面的工作，还要和包括老师，中传，清华同学进行不断地交流与合作，包括功能需求确定，美工UI建模的合作，团队的宣传，创业比赛的评审等，都远远超出了软件开发的范围。但是实际上在真正的软件工程中，往往就是需要花大量时间来和客户，用户，以及除了开发人员以外的市场营销，美术设计等各方面的同学打交道。这个时候，最好的做法就是定期交流，并不断给他们发布我们的体验版本，让大家都能有一个很强烈的参与感，及时了解项目的进度，都能成为项目的主人。
  • 软件工程的代码质量控制与开发速度其实是一个trade-off。如果过分追求质量而忽视了速度，显然达不到敏捷开发的持续集成部署的要求。而一味追求速度，短期内可以快速迭代出可用产品，长远来看却会带来很多隐藏问题。因此较好的做法是，在开发之初确定一套相对宽松的代码审核，测试，交付标准，在开发过程中根据开发技术的难度和实际情况，做出必要的调整。比如我们的项目在alpha阶段，还处于一种技术探索和稳定的阶段，因此对于代码复审，架构管理，存在些许问题。不过经历了alpha阶段，我们的产品功能更加清晰，技术难关也得到了大部分的解决，需要追求更高层次的代码质量问题，而不只是实现功能跑起来这么简单。
  • 精确的流程能带来进度上的统一和更高的工程质量。软件开发绝不仅仅是几个人写好各自代码，合并好再部署这么简单。而是需要有一个完善的机制来确保整个开发过程顺利进行。
  • 面对面的交流很重要。一味的进行线上语音交流虽然能带来一时的高效，但是带来不了持久的高效。想要打造高质量的代码，需要更频繁的线下开会交流，更多的面对面互相询问与回答。

Part5 beta阶段开发注意事项

5.1 冲刺阶段开发流程

每日开发

以2天为单位，完成一次循环

• 开始开发前由PM进行需求分配，每个成员对应一个需求（需要遵守模板）。
• 每个成员将需求进度转成进行中，将PM表述不清楚的部分按照自己理解进行完善补充，并将需求转换为自己的具体任务，并根据实际情况确定每个任务优先级和截止时间（原则上不晚于下一次例会的日期）。开发中完成了某个任务后，先自行对所完成任务进行测试，至少保证自己的任务的基本测试无误。
• 在完成了两日内全部任务的测试之后（或者认为已经做完了2日内的工作之后），将之前的需求设为已完成，同时发布一个测试需求，完善每个需求对应功能的描述，指定任务对象为tsq，等待tsq进行功能测试。
• tsq测试如果遇到了bug，确认是和这个任务本身相关的问题，直接在对应的任务处留下评论并将相关任务设置为进行中，并通知相关人员进行相应修改。如果发现了与所在功能无关的其他bug，发布一个缺陷给对应人员。（如果不知道给谁就先发给yrb）
• 在解决了某个任务的问题后，开发人员将任务设置为已完成。解决了某个缺陷需要将缺陷设置为关闭。
• 每两日例会，例会之前每个人需要明确自己做了什么，开会后需要大致明确之后两天需要做什么。同时发布在平台上，确认自己到底要做什么，自己来给自己定任务

每周构建

• 每周开始之前PM确定本周的大致开发目标，并具体描述出来。
• 每周日内部发布内测版本，要求至少所有安卓用户都需要进行产品试用，并提出相应缺陷。

5.2 需求模板

开发需求

标题格式为：开发需求-[简要描述]

具体内容为对于这个开发需求的具体介绍，以一个数字列表形式呈现。

截止日期需要指定为下一次例会开始时间。

功能需求

此需求模板是针对一些奇思妙想的收集

标题格式为：功能需求-[简要描述]

具体格式包括功能说明+可能的实现方式/技术方案两个方面

测试需求

标题格式为：测试需求-[简要描述]

具体内容为一个todo列表，内容为自己完成的功能的简单描述和对应的issue。大致为功能具体描述：issue编号

截止时间需要指定为下一次例会时间。

5.3 任务模板

标题为：任务简要描述，比如：聊天服务

每一个任务尽量是不可再分的，即如果再拆分对于自己没有积极意义。

同时需要包含3个方面，任务具体描述，实现方案（包含设计和具体实现），简单测试结果（简单测试用例，在什么样的情况下测试无误）

截止时间需要设置为某次例会时间。

5.4 缺陷模板

标题为bug的简要描述

具体内容包含bug出现位置、触发条件、出现频率、严重性。

标签：功能,week12,用户,开发,测试,alpha,Alpha,灵境,进行
来源： https://www.cnblogs.com/hair-duang-duang/p/16290082.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。