【敏杰开发】Beta阶段事后分析
【敏杰开发】Beta阶段事后分析
设想和目标
Q
- 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
- 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
- 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
- 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
我们对典型用户和场景有较为清晰的描述分析，可以参考我们的功能规格书，主攻科研群体，细微提供小而美的服务。
就beta结果来看，我们实现了设计时制定的所有功能需求，在alpha的基础上新增实现了用户个人中心、随笔功能、高级文献管理功能、路书编辑器人性化定制、社区功能、最新论文推荐，对界面及布局也做了一定程度的美化。我们收到的用户反馈绝大多数都是4分及以上的积极评价。总的来说，从完成度、美观度、用户满意度来看，我们都认为切实达到了本阶段的开发目标。在本阶段通过我们的大力推广，包括课程组与助教帮助我们的大力推广，我们的用户数量已经达到了预期的200人并且超额完成了计划。
我们目前的工程质量虽然不是完美的，但完全处于可控范围内，这主要得益于我们较为合理的协作方式和开发流程，允许我们更从容地管理工程。我们依然沿用alpha阶段的工程管理方法，并将其总结成一篇项目管理技术博客，供他人借鉴。在本阶段中，我们更加注意在代码复审时加入评价，做到一切问题有迹可循。
用户对于功能的反馈可以查看我们的项目展示博客，总的来说我们关注的特性大多也是用户关注的，如文献批量添加、bibtex批量导出、文献作者统计、界面美观、随笔路书结合等。另外还有一些用户向我们提出了更多有意义的需求，可见我们的产品还有更大的需求和提升空间。
计划
Q
- 是否有充足的时间来做计划?
- 团队在计划阶段是如何解决同事们对于计划的不同意见的？
- 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
- 有没有发现你做了一些事后看来没必要或没多大价值的事?
- 是否每一项任务都有清楚定义和衡量的交付件?
- 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
- 在计划中有没有留下缓冲区，缓冲区有作用么?
- 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
总的来说我们还是有相当充足的时间进行计划与规划的。实际上开发初期大家的主要工作就是学习开发技术并作一些开发计划。当然，计划永远赶不上变化，所以我认为我们的一大优势就是可以不间断地调整计划、补充计划从而适应变化，这得益于我们强调开发人员“可替代性”与“不可替代性”权衡的协作节奏。我想，这也是敏捷开发的哲学内含，以不断的变化来应对快节奏的开发与交付
我们的不同意见大多可以在同步会中解决，一方面是因为团队气氛自由融洽，大家可以很好地表达自己的观点、参考别人的观点，因此分歧总能快速消除。实际上这或许也是前段时间三明治交流法的实践结果。我观察到大家在对待异见时总能先总结对方的优点，再指出其不足，并给出自己的解决方案————这样的沟通理性而容易达成组内共识
原计划的工作全部完成，并额外完成了一些工作，可以参考上一节。唯一遗憾的是我们一直受限于资源与政策，没有解决部署域名的问题，或许下个阶段我们能找到一些免费的解决方案，或替代方案。
总的来说我们的每一项工作都是有意义的，开发节奏紧凑充实。唯一（看起来）没什么价值的工作是给全体组员开了个超级用户账号，最后发现大家大部分时候还是用自己的（普通用户权限）账号密码登进去做测试……（主要因为我们几乎不需要手动修改生产环境的数据，这其实是个好现象）
分发的每一个任务都会在开会时清楚定义，并在issue中描述要点。但衡量标准往往是不固定的，因为我们希望组员根据自己的实际开发情况与个人理解决定手头正在开发的功能需要实现到什么程度（当然后端开发，尤其是测试，是有非常明确的验收指标的，比如后端的两位同学很辛苦地把覆盖率拉到了100%），背后的思想是：司令部把指挥权交给战地指挥官往往是合理的。
项目整体按计划进行，意外大多来自第三方组件。比如我们调研到的一款markdown渲染插件，它的实现有一些问题，传入slot中的内容没有实现数据双向绑定，数据更新后必须重新挂载渲染组件才能刷新————这是我们意料外的，并且有些反直觉而难以排查。所以花费了额外的精力去定位、修复这个错误。
我们使用了测试-生产双分支的形式管理代码仓库，这实际上就是一种缓冲机制。
资源
- 我们有足够的资源来完成各项任务么?
学习资源：
- 非常充足。
- 无论是前端的 Vue.js，还是后端的 Django，网上的学习资料都十分丰富。
- 同时，本组有资深开发人士，能提供足够的技术支持。
人员配置：
- 较为充足。
- 4 人负责前端，2 人负责后端，1 人机动。
硬件资源：
- 匮乏。
- 自己的服务器性能较差。
- 缺少可使用的域名资源。
- 各项任务所需的时间和其他资源是如何估计的，精度如何?
在每次的任务发布之前，通过例会进行任务拆解，分发到个人头上。
每个人领取 issue，将分解任务的时间资源按小时级别估计，需求任务的时间资源按天级别估计。
估计在大部分时间是比较精准的，但是由于某些不可抗力的干扰，偶尔会出现估计错误。
- 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
足够。
后端组 2 人负责测试工作。分别从 CURD、Permission 和 Auth 三个方面进行测试工作。
关于美工设计与文案方面，美工设计方面的难度不是很大，但是我们对文案的重视程度有一定不足。
- 你有没有感到你做的事情可以让别人来做（更有效率）?
没有。我们组强调每个开发者专精一个方向（不可替代性）并熟悉其他人的开发方向（可替代性），从前者的角度来看，我做的事情由我来完成是效率最高的。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
项目的领导者一定要能掌握前后端的所有情况，我们alpha阶段的PM有足够的能力指导前后端所有的开发工作，但是由于我在alpha阶段主要做前端工作，对后端不是很熟悉，导致在多个任务的叙述中与后端同学理解不同，导致很多返工的情况，十分浪费时间。
后来我认真研读并学习了后端代码，让自己真正“全栈”，这样便可以更好地与后端同学对接需求，更准确地表达出前端需要后端做的东西是什么了。在必要的时候我也充当了后端开发的角色，贡献了一些简单的后端代码。
改进：PM看似一个“多余”的角色，但是一个真正优秀的PM，真正懂得项目各个部分的PM更能高效地带领团队，做出真正优秀的产品。
变更管理
Q
- 每个相关的员工都及时知道了变更的消息?
是的，我们采用GitHub上的项目管理相关功能来保证队友及时了解变更代码或者消息。
- 在每次dev代码更新之后，都可以了解更新的内容和时间，git自带的拉取功能也能随时确保自己的代码是最新的。
- 团队采用issue和解决issue的开发模式，每个issue合理分配给不同的队友，我们在接收到issue之后，会收到GitHub的邮件，保证任务分发和出现突发变更的时候，3. 每个队友都能及时知晓。
周期性的大组会和随时的小范围会议，保证了每个成员都能了解项目的进度与方向的变更。而且每个成员的问题都能随时得到解决。
- 我们采用了什么办法决定“推迟”和“必须实现”的功能?
我们在项目最初设计文档时，确定了必须功能和附加功能，所以在面对具体功能的规划时，可以参考 最初设计文档的功能规划，来决定这一项功能时必须按时完成的核心功能还是可以推迟的提升功能。
- 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
有，出口条件也是在最初的设计文档中确定了的。在设计文档中，除了确定必须功能和附加功能外，也确定了𝝰阶段和𝝱阶段的可发布的几大核心功能。
同时，从测试和debug的角度出发，出口在满足核心功能的同时，也需要整体代码有90%以上的测试覆盖率，以及前端代码审核后交付且新手可流畅使用。
- 对于可能的变更是否能制定应急计划?
可以。
我们面对代码上可能的变更，可以及时发布新的issue，其中可以设计各种label比如优先级程度、是否是bug、是否是核心功能，并分配个一个人或者多人来完成。
在大的代码思路上可能出现的变更，我们有密集的大小组会，可以随时统一思想，并且集思广益理清思路、解决问题。
- 员工是否能够有效地处理意料之外的工作请求？
是。
我们团队采用网状式扁平化的团队开发方案，每个队友都有各自最擅长的开发方向，而且也通过组会交流对其他人的开发代码比较了解，能够处理自身开发代码之外的功能需求，并且可适应跨功能的开发。
而且，整体队友的开发积极性高。能够在完成基本功能的基础上，发动自己的主观能动性，开发提高功能，并且自己思考打磨各自的模块，开发主动性高，可以有效处理意料之外的工作请求。
例如本阶段，我们的PM被换到了其它团队，这对我们的团队无疑是一次重创，因为在alpha阶段完全是PM一手操刀，教我们如何上手，带领我们完成各自的任务。在他被换走以后，我接替了他的工作，按照他留下的项目管理模式依然将项目完成的很好，这充分体现了我们团队应对意料之外事件的能力。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们学到了软件工程的团队开发的方法。比如基于GitHub的代码管理，团队会议组织方法，面对变更的群策群力，等等。
如果历史重来一次，我们会做：
- 在初期需求分析的学习阶段，每天请同学进行学习交流，进行知识交流，并同步组内的学习进度。
- 设定开发每个时间分段的任务和人员安排，让开发更有节奏，让每个队友也知道自己的进度安排。
- 项目领导者应该今早熟悉项目所有模块的情况。
设计/实现
Q
- 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
在我们团队的敏捷开发过程中，不同层面的设计工作其实贯穿了整个流程。初期时，设计工作关注功能，在撰写产品功能说明书时，我们侧重从用户使用角度去设计产品的目标和功能；而在实际开发时，我们侧重从技术角度设计整个软件框架、工程维护规则、界面风格规范、错误处理规范、axios请求规范等；而到beta阶段接近完成时，随着测试和使用反馈，又进入了新一论的设计和实现过程。
我们认为团队在参与设计的时间是合适的，正如《构建之法》在介绍设计、编码、测试等内容在敏捷开发的流程时的图示，每一部分并不是完全割裂的，而是此消彼长式地相互融合。
- 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
在没有编码实现或编码实现初期时遇到过模棱两可的情况，例如前端向后端的请求接口设计在没有实现情况下很难做到完备地考虑。
解决思路：构建一个基础的设计先行实现，并能够在demo环境下完成功能。而后在scrum例会时，向组员讲解清楚功能实现，由团队共同协商再提出新的具体优化内容，由此产生迭代的过程，最后达到满意的结果。
- 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
团队针对后端使用了单元测试，并检验了代码覆盖率。
- 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
整体上项目的Bug分布比较均匀，在各处均有产生。在修复问题时，遇到问题比较多是脑图MindMap组件的定制，主要涉及到了css风格自定义以及传统js&vue的编程，因此比较困难。
在实现时，我们采用了release/dev双分支的设计，所有的pull request均合并到dev分支，待检验完毕后合并至release分支，在每个版本发布前均会进行测试，因此分布版本未遇到什么重要的bug。对于小问题，发布后曾出现了页面跳转错误的情况，事后分析是由于vue.router部分调用方式不遵循解耦思想，在Beta阶段时，需要规范组员在路由器跳转、错误处理、axios请求调用接口上的使用规范。
- 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
Code Review 借助 Github 的 Pull Request 和 Issue 功能实现，所有的pr要求必须有一名组员同意，github会根据近期的编码历史，向pr发起者推荐合适的reviewer。
代码规范：我们团队并没有自行定义一套完整规范，而是使用了代码规范ESLint+WebStorm风格检查代码的规范。经过组员反馈，对两套规则下的代码复审和阅读持好评。
对于团队大部分组员来说，这是我们第一次基于Github合作完成工程项目，在流程上，我们体验了软件开发一个周期中的设计、实现、测试的流程，在内容上，具体了解了Web开发的技术，在合作技术上，基本掌握了基于Github的项目推进和团队合作方法。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
如果历史重来一边，我们会改进的地方有：
- 明确Issue和Pr的规范和格式。
- 测试更早时间介入。
测试/发布
Q
- 团队是否有一个测试计划？为什么没有？
有测试计划
- 是否进行了正式的验收测试？
是, 在正式发布前， 我们寻找了目标用户, 让目标用户在软件的环境中使用了一段时间， 在未知用户操作的情况下， 让用户能够接受软件。
- 团队是否有测试工具来帮助测试？
测试工具主要使用django rest test和coverage, 通过django rest test对后端的CURD， 鉴权， 用户注册等操作进行正确性验证， 利用coverage工具对django测试的代码覆盖率进行检查， 如果添加新功能后， 代码覆盖率没到100%， 那么继续添加测试。 前端主要是使用场景测试， 在前端web app的几个主要的界面和路书的功能场景内进行测试。
- 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
测试工具对于前后端的验证有作用， 之后需要对前端添加更多自动测试。
- 在发布的过程中发现了哪些意外问题？
我们学到了什么? 如果重来一遍, 我们会做什么改进?
我们需要添加功能后进行更细节的测试， 使用CI CD工具进行回归测试。 在beta阶段， 我们会添加更多功能， 在之后的开发中， 需要不断完善测试， 如果再来一遍， 我们会更早使用TDD(测试驱动开发）。
团队的角色，管理，合作
Q
- 团队的每个角色是如何确定的，是不是人尽其才？
- 团队成员之间有互相帮助么？
- 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
团队角色是第一次开发会上划分的，由于大家基本都没有相关经验，只是凭借兴趣选择方向。大家开发积极性都很高，再加上我们的任务的动态调整机制，总的来说是人尽其才的
相互帮助是肯定存在的，我们的协作中穿插了大量结对编程与小范围会议，不乏互相帮助的过程。我们也通过这种形式解决了大部分合作问题，余下的难题留给同步会与集中开发。
- 每个成员明确公开地表示对成员帮助的感谢 （并且写在各自的博客里）：
我感谢zwx对我的帮助，因为我是beta阶段新进组的成员，他带领我尽快熟悉本组的软件开发流程，让我可以尽早上手开发，并且和他学到了很多知识，我十分感谢。
我感谢zzy对我的帮助，在我学习研读后端代码时，zzy同学认真地向我讲解了后端代码的架构，每个文件和函数的作用，让我少走了很多弯路。
总结:
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
你觉得团队在这个里程碑相比前一个里程碑有什么改进?
你觉得目前最需要改进的一个方面是什么?
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
正如我们前面提到的， 软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提高软件工程的质量呢？
团队阶段介于“规范”与“创造”之间
最需要改进的是代码质量管理
做的最好的是：学习全部经验
在程序质量上，我们会引入更多测试与错误处理相关的机制，借助自动化手段将劳动力解放并确保质量。这或许可以借助Github Action实现
在工程质量上，我们会紧抓代码质量管理，重构一小部分有“坏味道”的代码，更注意规范命名、注释与项目结构管理，写出更可读、可维护的代码
- 代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？
目前的复审形式良好，前期出于“快速实现”的思想并没有十分严格要求代码规范，后续提升过审标准即可。这需要一次同步会议进行全组范围内的规范与说明
- 整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？
整体架构良好。前端追求更扁平的页面/组件嵌套逻辑，并将常用操作集抽象为工具函数。后端已经借助插件框架实现了比较好的工程结构
- 其它软件工具的应用，应该如何提高？
我们前端所有成员使用jetbrain公司的web storm软件，对于前端的开发十分方便，在其上可以配置很多快捷键，比如根据eslint代码规范自动适配代码风格等等。
后端在开发时使用jetbrain公司的pycharm软件，也是python开发最常用的软件之一，在开发效率上十分出色。
我们的每日例会均使用石墨文档软件进行记录，可以进行多人协同编辑，十分方便。
- 项目管理有哪些具体的提高？
在本阶段，我们重点加强了代码互审时的评论，如果对方的代码有问题，要在评论中给出记录，而非只在微信中说，这样能够做到有迹可循，对后续开发有利。如果没有发现问题，也要评论无问题，准许迁入。
- 项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？
我们没有进行用户的跟踪统计，但是我们在beta阶段的用户人数有了很大提升，目前的注册用户数已经达到了230人。有了这个规模的使用群体之后，可以考虑进行用户的跟踪统计。
- 项目文档的质量如何提高？
我们在beta阶段做了详细的代码文档，其中
-
前端：我们在前端仓库的wiki中写了详细的文档，首先介绍代码的整体架构，使用的框架和工具，之后详细说明代码仓库中每个文件的意义，再按功能模块说明每个功能的实现思路、编码细节等，方便以后自己查看或其它团队接手。
-
后端：自动化文档。借助django restful framework与coreapi生成的自动api文档，便利前后端协作的同时解放后端同学双手
-
产品：为方便用户尽快上手我们的产品，我们为其撰写了一份上手文档，利用随笔功能发布在我们的知识路书平台，同时发布在博客园。
如果更细致的话，我们还可以做另一种文档，服务器配置文档，但是由于我们的配置方式采用成熟的nginx+uwsgi的方法，网上的配置方法已经很多，所以目前没有写这份文档。
- 对于人的领导和管理， 有什么具体可以改进的地方？ 请看《构建之法》关于PM、绩效考核的章节， 或者 《人件》等参考书
对于领导和管理，我们团队并没有出现大的问题，的成员是十分齐心的。唯一出现的一点小问题就是，有些同学由于其它事情有些繁忙，可以开发的时间有限，但是我们都通过一些方法解决了，比如调整他的开发时间段，或者其它有时间开发的同学替补他的任务。
- 对于软件工程的理论，规律有什么心得体会或不同意见？ 请看阅读作业。
软件工程的理论一定要在实践中进行探索，不能坐而论道，空谈理论。我们在学期初用了一周的时间快速阅读了《构建之法》的全书内容，其中有大量的理论我都不能理解，在经历了这一个学期的软件工程项目实训之后，其实有很多当时不能理解的理论都已经直接融入到我们的思想之中。在这篇博客提问回顾与个人总结中有更详细的介绍。
讨论截图
关于后续如何重构/改进代码质量的问题，组员积极讨论：
