【敏杰开发】Beta阶段过后分析

【敏杰开发】Beta阶段过后分析

设想和目标

Q

1. 咱们的软件要解决什么问题？是否认义得很清楚？是否对典型用户和典型场景有清晰的描述？
2. 咱们达到目标了么（原计划的功能作到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
3. 和上一个阶段相比，团队软件工程的质量提升了么？ 在什么地方有提升，具体提升了多少，如何衡量的？
4. 用户量, 用户对重要功能的接受程度和咱们事先的预想一致么? 咱们离目标更近了么?
   有什么经验教训? 若是历史重来一遍, 咱们会作什么改进?

咱们对典型用户和场景有较为清晰的描述分析，能够参考咱们的功能规格书，主攻科研群体，细微提供小而美的服务。

就beta结果来看，咱们实现了设计时制定的全部功能需求，在alpha的基础上新增实现了用户我的中心、随笔功能、高级文献管理功能、路书编辑器人性化定制、社区功能、最新论文推荐，对界面及布局也作了必定程度的美化。咱们收到的用户反馈绝大多数都是4分及以上的积极评价。总的来讲，从完成度、美观度、用户满意度来看，咱们都认为切实达到了本阶段的开发目标。在本阶段经过咱们的大力推广，包括课程组与助教帮助咱们的大力推广，咱们的用户数量已经达到了预期的200人而且超额完成了计划。

咱们目前的工程质量虽然不是完美的，但彻底处于可控范围内，这主要得益于咱们较为合理的协做方式和开发流程，容许咱们更从容地管理工程。咱们依然沿用alpha阶段的工程管理方法，并将其总结成一篇项目管理技术博客，供他人借鉴。在本阶段中，咱们更加注意在代码复审时加入评价，作到一切问题有迹可循。

用户对于功能的反馈能够查看咱们的项目展现博客，总的来讲咱们关注的特性大多也是用户关注的，如文献批量添加、bibtex批量导出、文献做者统计、界面美观、随笔路书结合等。另外还有一些用户向咱们提出了更多有意义的需求，可见咱们的产品还有更大的需求和提高空间。

计划

Q

1. 是否有充足的时间来作计划?
2. 团队在计划阶段是如何解决同事们对于计划的不一样意见的？
3. 你原计划的工做是否最后都作完了? 若是有没作完的，为何?
4. 有没有发现你作了一些过后看来不必或没多大价值的事?
5. 是否每一项任务都有清楚定义和衡量的交付件?
6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为何没有估计到?
7. 在计划中有没有留下缓冲区，缓冲区有做用么?
8. 未来的计划会作什么修改？（例如：缓冲区的定义，加班）
   咱们学到了什么? 若是历史重来一遍, 咱们会作什么改进?

总的来讲咱们仍是有至关充足的时间进行计划与规划的。实际上开发初期你们的主要工做就是学习开发技术并做一些开发计划。固然，计划永远赶不上变化，因此我认为咱们的一大优点就是能够不间断地调整计划、补充计划从而适应变化，这得益于咱们强调开发人员“可替代性”与“不可替代性”权衡的协做节奏。我想，这也是敏捷开发的哲学内含，以不断的变化来应对快节奏的开发与交付

咱们的不一样意见大多能够在同步会中解决，一方面是由于团队气氛自由融洽，你们能够很好地表达本身的观点、参考别人的观点，所以分歧总能快速消除。实际上这或许也是前段时间三明治交流法的实践结果。我观察到你们在对待异见时总能先总结对方的优势，再指出其不足，并给出本身的解决方案————这样的沟通理性而容易达成组内共识

原计划的工做所有完成，并额外完成了一些工做，能够参考上一节。惟一遗憾的是咱们一直受限于资源与政策，没有解决部署域名的问题，或许下个阶段咱们能找到一些免费的解决方案，或替代方案。

总的来讲咱们的每一项工做都是有意义的，开发节奏紧凑充实。惟一（看起来）没什么价值的工做是给全体组员开了个超级用户帐号，最后发现你们大部分时候仍是用本身的（普通用户权限）帐号密码登进去作测试……（主要由于咱们几乎不须要手动修改生产环境的数据，这实际上是个好现象）

分发的每个任务都会在开会时清楚定义，并在issue中描述要点。但衡量标准每每是不固定的，由于咱们但愿组员根据本身的实际开发状况与我的理解决定手头正在开发的功能须要实现到什么程度（固然后端开发，尤为是测试，是有很是明确的验收指标的，好比后端的两位同窗很辛苦地把覆盖率拉到了100%），背后的思想是：司令部把指挥权交给战地指挥官每每是合理的。

项目总体按计划进行，意外大多来自第三方组件。好比咱们调研到的一款markdown渲染插件，它的实现有一些问题，传入slot中的内容没有实现数据双向绑定，数据更新后必须从新挂载渲染组件才能刷新————这是咱们意料外的，而且有些反直觉而难以排查。因此花费了额外的精力去定位、修复这个错误。

咱们使用了测试-生产双分支的形式管理代码仓库，这实际上就是一种缓冲机制。

资源

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

学习资源：

• 很是充足。
• 不管是前端的 Vue.js，仍是后端的 Django，网上的学习资料都十分丰富。
• 同时，本组有资深开发人士，能提供足够的技术支持。

人员配置：

• 较为充足。
• 4 人负责前端，2 人负责后端，1 人机动。

硬件资源：

• 匮乏。
• 本身的服务器性能较差。
• 缺乏可以使用的域名资源。

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

在每次的任务发布以前，经过例会进行任务拆解，分发到我的头上。

每一个人领取 issue，将分解任务的时间资源按小时级别估计，需求任务的时间资源按天级别估计。

估计在大部分时间是比较精准的，可是因为某些不可抗力的干扰，偶尔会出现估计错误。

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

足够。

后端组 2 人负责测试工做。分别从 CURD、Permission 和 Auth 三个方面进行测试工做。

关于美工设计与文案方面，美工设计方面的难度不是很大，可是咱们对文案的重视程度有必定不足。

4. 你有没有感到你作的事情可让别人来作（更有效率）?

没有。咱们组强调每一个开发者专精一个方向（不可替代性）并熟悉其余人的开发方向（可替代性），从前者的角度来看，我作的事情由我来完成是效率最高的。

有什么经验教训? 若是历史重来一遍, 咱们会作什么改进?

项目的领导者必定要能掌握先后端的全部状况，咱们alpha阶段的PM有足够的能力指导先后端全部的开发工做，可是因为我在alpha阶段主要作前端工做，对后端不是很熟悉，致使在多个任务的叙述中与后端同窗理解不一样，致使不少返工的状况，十分浪费时间。

后来我认真研读并学习了后端代码，让本身真正“全栈”，这样即可以更好地与后端同窗对接需求，更准确地表达出前端须要后端作的东西是什么了。在必要的时候我也充当了后端开发的角色，贡献了一些简单的后端代码。

改进：PM看似一个“多余”的角色，可是一个真正优秀的PM，真正懂得项目各个部分的PM更能高效地带领团队，作出真正优秀的产品。

变动管理

Q

1. 每一个相关的员工都及时知道了变动的消息?

是的，咱们采用GitHub上的项目管理相关功能来保证队友及时了解变动代码或者消息。

1. 在每次dev代码更新以后，均可以了解更新的内容和时间，git自带的拉取功能也能随时确保本身的代码是最新的。
2. 团队采用issue和解决issue的开发模式，每一个issue合理分配给不一样的队友，咱们在接收到issue以后，会收到GitHub的邮件，保证任务分发和出现突发变动的时候，3. 每一个队友都能及时知晓。
   周期性的大组会和随时的小范围会议，保证了每一个成员都能了解项目的进度与方向的变动。并且每一个成员的问题都能随时获得解决。

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

咱们在项目最初设计文档时，肯定了必须功能和附加功能，因此在面对具体功能的规划时，能够参考 最初设计文档的功能规划，来决定这一项功能时必须按时完成的核心功能仍是能够推迟的提高功能。

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

有，出口条件也是在最初的设计文档中肯定了的。在设计文档中，除了肯定必须功能和附加功能外，也肯定了𝝰阶段和𝝱阶段的可发布的几大核心功能。
同时，从测试和debug的角度出发，出口在知足核心功能的同时，也须要总体代码有90%以上的测试覆盖率，以及前端代码审核后交付且新手可流畅使用。

4. 对于可能的变动是否能制定应急计划?

能够。
咱们面对代码上可能的变动，能够及时发布新的issue，其中能够设计各类label好比优先级程度、是不是bug、是不是核心功能，并分配个一我的或者多人来完成。
在大的代码思路上可能出现的变动，咱们有密集的大小组会，能够随时统一思想，而且集思广益理清思路、解决问题。

5. 员工是否可以有效地处理意料以外的工做请求？

是。
咱们团队采用网状式扁平化的团队开发方案，每一个队友都有各自最擅长的开发方向，并且也经过组会交流对其余人的开发代码比较了解，可以处理自身开发代码以外的功能需求，而且可适应跨功能的开发。
并且，总体队友的开发积极性高。可以在完成基本功能的基础上，发动本身的主观能动性，开发提升功能，而且本身思考打磨各自的模块，开发主动性高，能够有效处理意料以外的工做请求。
例如本阶段，咱们的PM被换到了其它团队，这对咱们的团队无疑是一次重创，由于在alpha阶段彻底是PM一手操刀，教咱们如何上手，带领咱们完成各自的任务。在他被换走之后，我接替了他的工做，按照他留下的项目管理模式依然将项目完成的很好，这充分体现了咱们团队应对意料以外事件的能力。

咱们学到了什么? 若是历史重来一遍, 咱们会作什么改进?

咱们学到了软件工程的团队开发的方法。好比基于GitHub的代码管理，团队会议组织方法，面对变动的群策群力，等等。
若是历史重来一次，咱们会作：

1. 在初期需求分析的学习阶段，天天请同窗进行学习交流，进行知识交流，并同步组内的学习进度。
2. 设定开发每一个时间分段的任务和人员安排，让开发更有节奏，让每一个队友也知道本身的进度安排。
3. 项目领导者应该今早熟悉项目全部模块的状况。

设计/实现

Q

1. 设计工做在何时，由谁来完成的？是合适的时间，合适的人么？

在咱们团队的敏捷开发过程当中，不一样层面的设计工做其实贯穿了整个流程。初期时，设计工做关注功能，在撰写产品功能说明书时，咱们侧重从用户使用角度去设计产品的目标和功能；而在实际开发时，咱们侧重从技术角度设计整个软件框架、工程维护规则、界面风格规范、错误处理规范、axios请求规范等；而到beta阶段接近完成时，随着测试和使用反馈，又进入了新一论的设计和实现过程。

咱们认为团队在参与设计的时间是合适的，正如《构建之法》在介绍设计、编码、测试等内容在敏捷开发的流程时的图示，每一部分并非彻底割裂的，而是此消彼长式地相互融合。

2. 设计工做有没有碰到模棱两可的状况，团队是如何解决的？

在没有编码实现或编码实现初期时遇到过模棱两可的状况，例如前端向后端的请求接口设计在没有实现状况下很难作到完备地考虑。

解决思路：构建一个基础的设计先行实现，并可以在demo环境下完成功能。然后在scrum例会时，向组员讲解清楚功能实现，由团队共同协商再提出新的具体优化内容，由此产生迭代的过程，最后达到满意的结果。

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

团队针对后端使用了单元测试，并检验了代码覆盖率。

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

总体上项目的Bug分布比较均匀，在各处均有产生。在修复问题时，遇到问题比较可能是脑图MindMap组件的定制，主要涉及到了css风格自定义以及传统js&vue的编程，所以比较困难。

在实现时，咱们采用了release/dev双分支的设计，全部的pull request均合并到dev分支，待检验完毕后合并至release分支，在每一个版本发布前均会进行测试，所以分布版本未遇到什么重要的bug。对于小问题，发布后曾出现了页面跳转错误的状况，过后分析是因为vue.router部分调用方式不遵循解耦思想，在Beta阶段时，须要规范组员在路由器跳转、错误处理、axios请求调用接口上的使用规范。

5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
   Code Review 借助 Github 的 Pull Request 和 Issue 功能实现，全部的pr要求必须有一名组员赞成，github会根据近期的编码历史，向pr发起者推荐合适的reviewer。

代码规范：咱们团队并无自行定义一套完整规范，而是使用了代码规范ESLint+WebStorm风格检查代码的规范。通过组员反馈，对两套规则下的代码复审和阅读持好评。

对于团队大部分组员来讲，这是咱们第一次基于Github合做完成工程项目，在流程上，咱们体验了软件开发一个周期中的设计、实现、测试的流程，在内容上，具体了解了Web开发的技术，在合做技术上，基本掌握了基于Github的项目推动和团队合做方法。

咱们学到了什么? 若是历史重来一遍, 咱们会作什么改进?

若是历史重来一边，咱们会改进的地方有：

• 明确Issue和Pr的规范和格式。
• 测试更早时间介入。

测试/发布

Q

1. 团队是否有一个测试计划？为何没有？

有测试计划

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

是, 在正式发布前， 咱们寻找了目标用户, 让目标用户在软件的环境中使用了一段时间， 在未知用户操做的状况下， 让用户可以接受软件。

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

测试工具主要使用django rest test和coverage, 经过django rest test对后端的CURD， 鉴权， 用户注册等操做进行正确性验证， 利用coverage工具对django测试的代码覆盖率进行检查， 若是添加新功能后， 代码覆盖率没到100%， 那么继续添加测试。 前端主要是使用场景测试， 在前端web app的几个主要的界面和路书的功能场景内进行测试。

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

测试工具对于先后端的验证有做用， 以后须要对前端添加更多自动测试。

5. 在发布的过程当中发现了哪些意外问题？
   咱们学到了什么? 若是重来一遍, 咱们会作什么改进?

咱们须要添加功能后进行更细节的测试， 使用CI CD工具进行回归测试。 在beta阶段， 咱们会添加更多功能， 在以后的开发中， 须要不断完善测试， 若是再来一遍， 咱们会更早使用TDD(测试驱动开发）。

团队的角色，管理，合做

Q

1. 团队的每一个角色是如何肯定的，是否是人尽其才？
2. 团队成员之间有互相帮助么？
3. 当出现项目管理、合做方面的问题时，团队成员如何解决问题？

团队角色是第一次开发会上划分的，因为你们基本都没有相关经验，只是凭借兴趣选择方向。你们开发积极性都很高，再加上咱们的任务的动态调整机制，总的来讲是人尽其才的

相互帮助是确定存在的，咱们的协做中穿插了大量结对编程与小范围会议，不乏互相帮助的过程。咱们也经过这种形式解决了大部分合做问题，余下的难题留给同步会与集中开发。

4. 每一个成员明确公开地表示对成员帮助的感谢 （而且写在各自的博客里）：

我感谢zwx对个人帮助，由于我是beta阶段新进组的成员，他带领我尽快熟悉本组的软件开发流程，让我能够尽早上手开发，而且和他学到了不少知识，我十分感谢。
我感谢zzy对个人帮助，在我学习研读后端代码时，zzy同窗认真地向我讲解了后端代码的架构，每一个文件和函数的做用，让我少走了不少弯路。

总结:

你以为团队目前的状态属于 CMM/CMMI 中的哪一个档次?
你以为团队目前处于 萌芽/磨合/规范/创造 阶段的哪个阶段?
你以为团队在这个里程碑相比前一个里程碑有什么改进?
你以为目前最须要改进的一个方面是什么?
对照敏捷开发的原则, 你以为大家小组作得最好的是哪几个原则? 请列出具体的事例。
正如咱们前面提到的， 软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提升软件工程的质量呢？

团队阶段介于“规范”与“创造”之间

最须要改进的是代码质量管理

作的最好的是：学习所有经验

在程序质量上，咱们会引入更多测试与错误处理相关的机制，借助自动化手段将劳动力解放并确保质量。这或许能够借助Github Action实现

在工程质量上，咱们会紧抓代码质量管理，重构一小部分有“坏味道”的代码，更注意规范命名、注释与项目结构管理，写出更可读、可维护的代码

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

目前的复审形式良好，前期出于“快速实现”的思想并无十分严格要求代码规范，后续提高过审标准便可。这须要一次同步会议进行全组范围内的规范与说明

2. 整个程序的架构如何具体提升？ 如何经过重构等方法提升质量，如何衡量质量的提升？

总体架构良好。前端追求更扁平的页面/组件嵌套逻辑，并将经常使用操做集抽象为工具函数。后端已经借助插件框架实现了比较好的工程结构

3. 其它软件工具的应用，应该如何提升？

咱们前端全部成员使用jetbrain公司的web storm软件，对于前端的开发十分方便，在其上能够配置不少快捷键，好比根据eslint代码规范自动适配代码风格等等。
后端在开发时使用jetbrain公司的pycharm软件，也是python开发最经常使用的软件之一，在开发效率上十分出色。
咱们的每日例会均使用石墨文档软件进行记录，能够进行多人协同编辑，十分方便。

4. 项目管理有哪些具体的提升？

在本阶段，咱们重点增强了代码互审时的评论，若是对方的代码有问题，要在评论中给出记录，而非只在微信中说，这样可以作到有迹可循，对后续开发有利。若是没有发现问题，也要评论无问题，准许迁入。

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

咱们没有进行用户的跟踪统计，可是咱们在beta阶段的用户人数有了很大提高，目前的注册用户数已经达到了230人。有了这个规模的使用群体以后，能够考虑进行用户的跟踪统计。

6. 项目文档的质量如何提升？
   咱们在beta阶段作了详细的代码文档，其中

• 前端：咱们在前端仓库的wiki中写了详细的文档，首先介绍代码的总体架构，使用的框架和工具，以后详细说明代码仓库中每一个文件的意义，再按功能模块说明每一个功能的实现思路、编码细节等，方便之后本身查看或其它团队接手。

• 后端：自动化文档。借助django restful framework与coreapi生成的自动api文档，便利先后端协做的同时解放后端同窗双手

• 产品：为方便用户尽快上手咱们的产品，咱们为其撰写了一份上手文档，利用随笔功能发布在咱们的知识路书平台，同时发布在博客园。

若是更细致的话，咱们还能够作另外一种文档，服务器配置文档，可是因为咱们的配置方式采用成熟的nginx+uwsgi的方法，网上的配置方法已经不少，因此目前没有写这份文档。

7. 对于人的领导和管理， 有什么具体能够改进的地方？ 请看《构建之法》关于PM、绩效考核的章节， 或者 《人件》等参考书

对于领导和管理，咱们团队并无出现大的问题，的成员是十分齐心的。惟一出现的一点小问题就是，有些同窗因为其它事情有些繁忙，能够开发的时间有限，可是咱们都经过一些方法解决了，好比调整他的开发时间段，或者其它有时间开发的同窗替补他的任务。

8. 对于软件工程的理论，规律有什么心得体会或不一样意见？ 请看阅读做业。

软件工程的理论必定要在实践中进行探索，不能坐而论道，空谈理论。咱们在学期初用了一周的时间快速阅读了《构建之法》的全书内容，其中有大量的理论我都不能理解，在经历了这一个学期的软件工程项目实训以后，其实有不少当时不能理解的理论都已经直接融入到咱们的思想之中。在这篇博客提问回顾与我的总结中有更详细的介绍。

讨论截图

关于后续如何重构/改进代码质量的问题，组员积极讨论：