[知识路书]过后分析

设想和目标

Q

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

参考咱们的选题博客，咱们但愿解决“文献梳理、呈现与展现没有直观形式”这个问题，但愿可以围绕学术阅读中的需求，以知识导图为主要形式，实现一款集文献管理与内容呈现于一体的软件。因为这个概念略显新颖，定义并非十分精准明确，可能随着迭代演进产生细微调整，但大的方向不会改变。

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

就alpha结果来看，咱们实现了初期制定的全部功能需求，根据实际须要又额外实现了用户权限系统、路书分享外链、bibtxt批量导入等功能，同时定制了路书编辑器，对界面及布局也作了必定程度的美化。咱们收到的用户反馈绝大多数都是4分及以上的积极评价。总的来讲，从完成度、美观度、用户满意度来看，咱们都认为切实达到了本阶段的开发目标。惟一的遗憾是咱们的用户数量没有达到预期的100人，咱们已经讨论分析了推广策略、推广渠道等存在的问题，并有但愿在下一步的推广中更快速增添用户量

咱们目前的工程质量虽然不是完美的，但彻底处于可控范围内，这主要得益于咱们较为合理的协做方式和开发流程，容许咱们更从容地管理工程。下一步咱们会进一步强调代码质量，尤为是命名规划与必要性注释。

用户对于功能的反馈能够查看咱们的项目展现博客，总的来讲咱们关注的特性大多也是用户关注的，如文献批量添加、界面美观、用户引导等。期待后续在解决用户提出的问题后咱们能收到更多正向反馈

计划

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. 你有没有感到你作的事情可让别人来作（更有效率）?

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

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

因为经验不足，错误类型的接口定义和错误处理方式小组成员未作统一约定，致使错误提醒内容存在差别和错误。

因为对后端文献数据内容形式的不了解，以及文献表格显示哪些内容也不清晰。咱们文献管理的table以及建立文献的drawer的相关字段设计混杂，不够人性化，table和drawer之间字段也有冲突。

改进：在和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. 员工是否可以有效地处理意料以外的工做请求？

是。
咱们团队采用网状式扁平化的团队开发方案，每一个队友都有各自最擅长的开发方向，并且也经过组会交流对其余人的开发代码比较了解，可以处理自身开发代码以外的功能需求，而且可适应跨功能的开发。
并且，总体队友的开发积极性高。可以在完成基本功能的基础上，发动本身的主观能动性，开发提升功能，而且本身思考打磨各自的模块，开发主动性高，能够有效处理意料以外的工做请求。

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

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

1. 在初期需求分析的学习阶段，天天请同窗进行学习交流，进行知识交流，并同步组内的学习进度。
2. 设定开发每一个时间分段的任务和人员安排，让开发更有节奏，让每一个队友也知道本身的进度安排。
3. 提早推广，更早的知道用户的反馈，辅助后续开发。

设计/实现

Q

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

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

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

对于功能设计和工程实现设计，咱们主要交由本组开发经验丰富的hdl和zwx同窗完成。后期分析，咱们认为这样的设置是合理的，避免团队设计不切实际的目标或走过多的弯路，同时也有助于其余组员学习。

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. 每一个成员明确公开地表示对成员帮助的感谢 （而且写在各自的博客里）：

我感谢 _______<姓名>______对个人帮助， 由于某个具体的事情: _____________________。

总结:

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

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

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

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

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

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

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

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

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

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

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

TODO

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

暂无，目前管理流程运做流畅，维持现状便可

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

因为未成规模，暂时没有相关统计。后续咱们考虑引入一些第三方BaaS服务统计DAU等指标

6. 项目文档的质量如何提升？

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

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

讨论截图

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

Q: 对比敏捷的原则，你以为大家小组作得最好的是什么？ Q: 什么是在下个阶段要改进的地方？越具体越好。