标签：功能 week17 代码 Beta 阶段 测试 团队 bug 灵境

Beta阶段事后总结

项目	内容
这个作业属于哪个课程	2022年北航软件工程
这个作业的要求在哪里	团队项目-Beta阶段反思

会议截图：

Part1 设想和目标

1.1 产品

① 产品定位

『 主打VR社交的趣味高校元宇宙 』

在alpha阶段的普通大学生和教师的社交的基础上，beta阶段重点考虑趣味性，设计了TD线和钢琴湖小游戏的娱乐性功能。

② 典型用户和场景

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

beta阶段将典型用户场景与具体的功能进行绑定

典型用户	定制功能
关注点清奇的找乐子玩家	北航TD线闯关，中传钢琴湖音游
即将毕业的女大学生	好看的人物装扮，高自由度的个人空间定制
无法见面的异地恋情侣	两人虚拟装扮坐在电影院场景一起看电影 好友用户互动功能
学识渊博的大学教师	适合团建的多人在线的会议室场景
热爱交友的社牛男大学生	好友聊天系统 树洞倾诉与倾听功能
专心科研的研究生学霸	适合团建的多人在线的会议室场景

③ 目标完成度

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

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

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

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

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

  原计划500，实际200+

④ 用户反馈

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

beta阶段的开发目标根据问卷结果确定：

新增的树洞功能讨论气氛很好，符合预期：

新增的TD线和钢琴湖小游戏也都有人打榜：

原有的高校场景新增了北航新主楼，广场也有所完善，引发了一波呼朋唤友对世界最高点的冲刺：

<iframe allowfullscreen="true" border="0" frameborder="no" framespacing="0" height="600" scrolling="no" src="//player.bilibili.com/player.html?aid=897743406&bvid=BV1CN4y137mf&cid=751832505&page=1" width="60%"> </iframe>

⑤ 经验教训

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

• GUI 风格统一

  • 树洞关于树木，主色调为黄绿

  • icon图标风格为简洁风，既有线性也有面性

  • 其他页面GUI主色调为白色+紫色

• UI确定流程：

  • 和中传开会讨论基本功能、跳转逻辑、整体外观

  • UI原型图、流程图

  • 前端制作基本框架、实现基本功能

  • 中传查看效果提出建议

• 前端代码规范

  • unity文件的组织管理标准化
  • git版本控制流程的优化

• 服务端安全性

  • 对用户鉴权进行细致考虑和处理，构建隐私安全性更高的服务。

• 和中传对接

  • 加强与中传同学的交流，在我们自己的实际开发难度以及目标和他们的设计目标之间找到平衡点。

• 完善需求分析

  • 发问卷，调查已有产品缺陷，确定beta阶段侧重点。

• 服务端问题

  • 用拦截器处理一些错误的时候不能无脑返回，否则会暴露一些数据库或代码的实现细节

1.2 计划

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

  在开发自己分配的功能前，如果具有必要，先进行详细设计和技术调研，再继续进行开发。

  例如lyyf对AR和人脸表情映射进行调研并制作demo，tsq对自动化测试和安卓模拟器产品广泛调研测试

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

  由于多数成员不在校，主要依靠两日的例会和有对接需要时的语音电话进行沟通交流，并不断磨合形成最终的结论。

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

  基本完成 【Beta阶段】计划阶段要求 - 功能规格说明书 中规划的功能。

  首页地图没有完成主要原因是中传建模时间紧迫，目前还只有北航和中传的建模，其他学校尚未添加到产品中，也没有绘制高校地图。

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

  • 实用功能上，钢琴湖游戏吸引力不足

  • AR可用性不强，最初尝试的AR人脸功能完全废弃，AR场景难以找到合适应用

  • Alpha阶段为Beta阶段准备而做的桌游小游戏、电影放映厅等功能并没有用上

  • 在还有功能性bug的前提下，过分关注UI的美观一致

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

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

  制定工作流程和需求-任务-缺陷描述规范

  详见博客：【Beta阶段】计划阶段要求 - 初始任务分配

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

  基本上没出现重大意外。

  但是最后发布过程中疯狂hack出很多bug，导致预期的发布时间并没有修完，最终发布时间推迟了两天。

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

  一些指向性不强的功能（不是某个成员功能的子功能）留下了一些灵活处理的空间，例如最开始指定给lyyf的人物建模骨骼动作功能，实际上由gcy和lhy合作完成；yrb计划学习完成的渲染，最终由lyyf完成漫画风格shader。

Part2 设计与实现

2.1 功能设计

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

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

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

  • 在例会时进行解决，集合众人的想法

• 直接由当事人进行文字或者语音交流

2.2 bug分析

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

  • 用户相关的接口。原因是用户鉴权和信息保护的处理相对较为繁琐复杂，相应的逻辑也会带来很多bug。
  • 个人空间。原因是3D物品拖拽和unity中的定位较为复杂，如果自己实现往往需要很多控制代码；邀请好友功能涉及到多人在线mirror的团队功能，以及实时更新物品，很容易出问题。
  • 好友管理相关功能。原因是整个流程较为复杂，需要前端后端对每一个API接口都保持完全相同的认知，才能实现好功能。

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

  比较严重的问题：

  • 手机验证码问题
  • 安卓版本32位和64位问题

  其他的是一些更细节的bug：

  • UI问题：细节上的显示问题
  • 切换问题：切换页面时未更新、未关闭等问题

  因为虽然有功能测试，但是毕竟不是覆盖性测试，还是会有所疏漏；并且不同机型可能会导致不适配bug。

  ID	问题	优先级
  #342	钢琴选择界面有元素没居中	中
  #347	树洞默认头像显示问题	中
  #349	“已邀请”乱码、显示位置重叠、上下不等距	中
  #350	场景内人物表情未更新	中
  #351	左上角按钮在个人空间和高校大世界不一样大	中
  #352	个人空间横屏下收起/展开侧边栏会移动左侧控件位置	中
  #353	音游开始后BGM还在放	中
  #354	返回按钮在个人主页和好友列表位置和大小都不同	中
  #355	修改个人形象不保存直接返回，模型更改未撤销	中

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

  • 前后端都使用自动的代码风格检查插件，因此可以保证执行了代码规范。
  • 前端合并出现冲突时由涉及相关人员协商解决。

2.3 变更管理

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

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

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

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

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

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

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

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

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

Part3 测试与发布

3.1 测试计划

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

• 后端有一套完整的测试流程，即开发者自行简单测试—单元测试—压力测试，同时在和前端对接后进行及时的修改完善。
• 前端主要是进行功能测试，即运行之后对于自己所负责的功能进行功能体验，并测试是否符合自己的预期。然后发送测试任务并关联需求，发给测试人员。测试人员发现bug后发布缺陷，等待解决。

① 前端测试人员

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

② 缺陷规范

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

③自动化测试工具

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

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

3.2 验收测试

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

  最后三天

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

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

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

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

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

3.3 经验教训

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

yrb

收获：

技术上：进一步学习了unity布局方式，代码中规范和unity布局结合

团队协作上：需要统一的问题公开讨论投票后公示，新的idea询问所有团队成员意见确定

改进：c#代码风格规范，利用语言特性，增强可复用性

fzc

收获：

技术上：

• 了解socket消息实时推送

• 学习了如何利用coding进行敏捷开发项目管理以及持续集成部署

• 熟悉了springboot后端框架，了解了redis，mybatis-plus，swagger，netty的基本用法，了解了jwt鉴权验证和基于session的用户验证

团队协作上：对团队过程正义有了改进

beta：

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

lyyf

收获：进一步学习了unity的多人同步，包括人物服饰、mirror团队，学习AR相关知识技能

改进：后续攻克相关技术时应更带有目的性，重点调研技术的局限性以保证功能稳定实用，开发时的团队协作也应更加规范

lhy

收获：

技术上：

• 学习了Unity引擎的使用和C#语言的基本用法，实践了一些设计模式
• 学习并实现读取图片的库。
• 考虑代码和UI复用性，特别是预制体

团队协作上：不同意见及时提出

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

gcy

收获：向大佬学习UI风格的美化，对于资源商店的更好的利用

改进：开发规范有待提高，开发流程的时间分配不够合理，对布局的修改有待进一步学习提高

xwq

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

改进：后期冲刺测试的时候没有下安卓模拟器测试 最后等发布之后才用ios测试找了些小bug 以后应该更积极地参与测试

tsq

收获：

技术上：几乎尝试了市面上所有安卓模拟器，最后使用逍遥模拟器，既能在开启hyper-v电脑上运行，也能适配原生c++游戏

团队协作上：用好自动化工具，开始前做好设计和规范，使用coding等团队协作工具，每日例会核对进度，提高团队效率

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

团队整体总结

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

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

Part4 团队角色和管理合作

4.1 分工

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

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

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

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

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

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

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

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

前端主要功能需求分工

beta阶段大致分工安排

前端

• TD线+人物模型绑定 gcy
• 钢琴湖+UI统一 yrb
• 树洞 lhy
• 好友聊天 fzc
• 会议厅+mirror同步+shader渲染调整 lyyf

后端

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

QA&测试&发布

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

4.2 合作

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

• fzc：
  • lyyf：对unity比较了解
  • lhy：封装的很实用，所有前端人员复用
  • gcy：UI设计很好
  • tsq：各种麻烦的杂活
  • xwq：netty相关的研究
  • yrb：UI布局很好，idea想法比较多，工作认真比较肝
• lyyf：
  • lhy：请求很好用，复用快捷方便，弥补对unity请求研究的不足
  • fzc、yrb：团队管理很熟练，整体过程很顺利
  • yrb：合作顺利，虽然不知道代码怎么跑，但是
  • gcy：主动承担工作（人物等），很辛苦
  • tsq：测试严密，保证APP质量
  • xwq：后端接口
• lhy：
  • fzc、yrb：承担会议记录、团队博客工作，团队合作整个过程顺利
  • fzc：性格较好，适合合作，有事情能说开
  • lyyf：对Unity比较熟练，提供很强的安心感，新手期提供很多帮助
  • gcy：魔方做得很漂亮，很遗憾地图设计在beta没用上
  • xwq：执行力很高，改接口迅速完成度高
  • tsq：承揽了整个团队的一切杂活，对产品稳定性做出很大贡献
• gcy：
  • lyyf：执行力强，多人在线
  • yrb：承担了UI修改的工作，分担工作量
  • lhy：做的工作功能性强、实用性强
  • tsq：审美一致，保证了整体UI的美观
  • xwq：执行力强
  • fzc：作为组长保证团队协调
• tsq：
  • 总体：每个同学都很有工作热情，积极完成自己工作
  • fzc、yrb：分工较为合理，团队合作整体过程很顺利
  • lyyf：非常大佬，有问题都可以去问
  • yrb、lhy、gcy：UI修改很细致，最后效果很好
• xwq：
  • fzc：已经合作过很多次了，每次都是队长，带领团队能力很强，我就只用接活干活就行，也能处理很多比较麻烦的任务，包括后期聊天他突然加入前端在短时间内能跑通也很厉害。
  • yrb：可能没fzc那么有统筹能力，但是你们每次会议记录都能做的很好，然后很能肝，感觉经常通宵干活，注意身体。
  • lyyf：没有什么协作，但是我觉得他会的面很广，一开始我以为可能文字、语音聊天可能需要我做很多，但是他直接就搞好了，省了我很多事。
  • lhy：我感觉是很有想法的人，每次能想到新想法而且确实是感觉很不错的想法，然后沟通效率也很高，每次接口请求的内容都写得很清楚。
  • tsq：我觉得测试很严格，比如刚开始对于后端接口的测试，我之前对于输入都是默认前端传来饿数据得符合我的想法，很少加以判断然后可能会报告500错误，当时可能觉得没啥但是仔细想想这确实是接口写的不够严谨，也找出了很多缺陷，很感谢他！
  • gcy：的话也是沟通效率很高，主页、学校的内容一下子就可以确定下来怎么做并且很快就实现了。总的来说和大家的合作很愉快！

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

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

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

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

Part5 敏捷开发实践体会

5.1 开发原则

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

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

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

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

  举例：每天服务端会进行一次持续集成，不断进行单元测试和部署，为客户端提供数据服务支持。

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

  举例：因为疫情原因，beta阶段并没有做到线下一起工作，但是保证线上文字、语音沟通渠道通畅。

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

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

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

  举例：这一点做的并不好。因为疫情原因，beta阶段无法在校线下面对面交流，更多的是语音交流，这样会带来一些效率问题。不过前端和后端对接时也常常采用语音聊天的形式及时跟进问题，高效解决问题。

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

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

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

  举例：在【Beta阶段】计划阶段要求 - 功能规格说明书 中对Beta阶段要实现的功能做出明确规划，实际上基本全部完成。

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

  举例：在Beta阶段做出改进，制定工作流程和需求-任务-缺陷描述规范

  详见博客：【Beta阶段】计划阶段要求 - 初始任务分配

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

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

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

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

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

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

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

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

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

5.2 跟踪用户数据

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

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

5.3 项目文档质量

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

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

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

5.4 团队组织管理

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

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

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

5.5 软件工程理论

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

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

标签：功能,week17,代码,Beta,阶段,测试,团队,bug,灵境
来源： https://www.cnblogs.com/hair-duang-duang/p/16411124.html

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