零、数据补充

题士访问最高并发数：3413

题士接口最高访问量：100815

题士6.19~6.25的7天平均日活：574

题士累计用户量：717

题士累计分享次数：104

题士小程序评级：双优秀

一、设想与目标

1.我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？

题士，是针对学生考试刷题、学习交流等需求开发的一款具备题目讨论、社区共享、错题整理等功能的优质刷题软件

根据需求调研分析结果，我们实现了如下功能以更好地满足用户的需求

关于典型用户和典型场景的分析我们也有清晰的调研和分析，具体可以参考：典型用户和典型场景。

2.我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?）

我们实现了所有预期功能：知识卡片、考期日历、问答社区和资源社区，并进一步实现了评论举报，消息通知等原本未在最初计划之内的功能

按原计划交付时间交付，超过预期用户数量，详见数据补充部分

3.和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？

与Alpha阶段相比，Beta开发过程团队软件工程质量明显提高，具体体现在

• 功能开发与单元测试同步进行
• 单元测试覆盖率达到95%
• 完成了对题士、产品主页和后端管理系统三个项目的拆分
• 功能设计与实现和Bug修复等均与issue相对应
• 产品主页与后端管理系统相分离

4.用户量，用户对重要功能的接受程度和我们事先的预想一致么？我们离目标更近了么？

用户量高于预期，用户对于重要功能的接收程度与我们事先预想的一致，具体数据见数据补充部分

5.有什么经验教训? 如果历史重来一遍，我们会做什么改进？

活跃的用户社区需要有完善的社区管理机制作为保障，在初始规划阶段应同时考虑到社区管理方面的功能，从而更为准确的预估工作量

二、计划

1.是否有充足的时间来做计划？

相比于Alpha阶段，Beta做计划的时间较为充足，在Beta阶段初始任务分配中已经明确了Beta阶段的主要工作：根据用户反馈与测试结果修复Alpha版本中的bug、进一步开发改进Alpha内容和按Beta原计划开发完善题士功能

同时在收到对题士Alpha的深度评测后，进一步调整开发任务，建设更好的题士

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

以需求为导向，讨论任务完成的预期结果，结合具体开发的难度，敲定功能实现方案，以功能模块化的形式明确责任，从项目规范的文档中可见一斑：

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

我们成功完成了Beta版本阶段制定的所有任务，同时实现了评论举报，消息通知等原本未在最初计划之内的功能

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

纵观整个开发过程来看，项目初始时有些过于担心小程序难以审核的问题了，事实上，小程序的审核较为顺利（不过还是有些玄学，中间出现过几次不能正常通过审核的情况，不同审核的人的标准不尽相同），所以项目初始时可以主打小程序，没有必要为APP的开发做更多的适配

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

针对开发需求的每一项任务和开发过程中修复的bug，我们都在issue形成了记录，并在功能规格说明部分进行了明确的交付指标的定义

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

题士组Beta阶段的开发工作的启动时间早于课程组原定时间，这为Beta阶段功能实现提供了充足的时间，并为解决未知问题预留了一定的缓冲时间

事实证明，缓冲时间是十分必要的，Beta开发部分时间段与考试时间段重合，团队成员需要全身心复习备考，由于缓冲时间的存在，团队成员可以较为从容地安排开发和备考的时间

7.在计划中有没有留下缓冲区，缓冲区有作用么？

在计划中不仅预留了时间缓冲，还预留了任务开发缓冲，比如为同一功能设计不同的开发计划，视开发时间长短与开发难易程度选择合适的功能实现方案

8.我们学到了什么？如果历史重来一遍，我们会做什么改进？

在计划前进行充分调研，比如小程序的审批时间，限制功能等以便题士的顺利审核与发布

三、资源

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

在经历转会环节后，团队仍为最初的六人，具体职责与项目功能一一对应，详见Beta项目展示-团队分工，所以人力资源尚且可以支撑团队完成开发任务

虽然Beta阶段部分开发时间与考试时间重合，但是我们早于课程组原定计划启动Beta阶段开发，为考试复习等预留了充分的缓冲时间，所以时间资源可以保证阶段计划完整实现

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

团队在Beta阶段初始时，会充分划分任务并以issue的形式分配给团队成员，详见Beta阶段初始任务分配

尽可能将每个issue的完成时间控制在1-2小时之间，所以最后取完成每个任务的平均值为1.5小时，再乘以任务总数，得到团队整体时间的预估

目前服务器、邮件发送等服务均采用按量计费的方式，从而较好地把控团队的开发资金

各项任务完成时间预估主要结合过往开发经验以及客观开发难度决定，在Beta阶段大部分任务的完成时间在1-2小时之间，与Alpha阶段相比，Beta阶段进行了更细粒度地任务划分以便更好地把握项目进度

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

开发与单元测试、功能测试同步进行，产品发布之前会进一步进行后端压力测试和前端性能测试

产品UI与产品宣传文案等由团队内LS和QSY设计制作，团队成员并未低估其难度，而是对每一个页面的设计，每一份文案的制作都抱有充分的准备和充足的信心

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

团队目前分工较为明确且合理，所以团队成员并无此感

5.有什么经验教训? 如果历史重来一遍,我们会做什么改进?

服务器配置略显仓促，如果历史重来一遍，我们会选择通过学生认证的方式，申请六台服务器的配置，利用nginx进行负载均衡，而非当前的一台在有限的资金支持下配置相对较高的服务器

四、变更管理

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

团队以线下开发为主，每次变更都能及时地通知每一位团队成员

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

按照需求的重要程度，并结合团队具体的开发进度，用户的反馈以及深度评测结果等，综合决定“推迟”和“必须实现”的功能

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

通过Beta-测试报告中的小程序性能测试、前端测试和压力测试的结果，以及微信公众平台对小程序审核通过的结果，可以认为题士达到出口条件

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

Beta阶段在收获Alpha题士的深度评测后及时形成回应，同时制定相应的应急计划，重新设计产品主页，并针对深度评测提到的部分问题进行修复和改进

5.员工是否能够有效地处理意料之外的工作请求？

在收获Alpha题士的深度评测后，题士团队所有开发人员立刻调整任务实现计划，可以较为灵活地应对意料之外的工作请求

6.我们学到了什么? 如果历史重来一遍,我们会做什么改进?

在Beta阶段开始时并未计划针对产品主页进行翻新，但是正如Alpha题士的深度评测中所指出问题一样，题士不单单指题士小程序，而是与题士相关的所有内容，包括产品主页和后台管理系统，只有精致地设计开发产品主页、完善后台管理系统功能后，才能使题士、产品主页和后台管理形成完整的系统

五、设计与实现

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

我们的设计工作主要在开发前期完成，所有成员一同参与。在Beta阶段的第一次Scrum Meeting 0522中，完成了各个功能的接口设计、数据库设计和页面UI设计等

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

经历了Alpha开发阶段后，题士的功能及待完成的任务已经较为明确，所以在Beta开发阶段，依次针对待实现的功能一一设计，并未出现模棱两可的情况

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

我们使用了单元测试、UML、CI/CD工具辅助开发

单元测试使用nodejs的第三方模块mocha+nyc+supertest框架进行，然后使用GitLab CI/CD工具进行持续集成，这使得我们每次开发完都能保证回归测试的正确，同时Beta阶段的测试覆盖率达到了95%

我们在数据库设计阶段使用了UML图进行描述，这样有助于我们理清表之间的关系

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

问答社区的Bug最多，其逻辑在Beta开发过程中最为复杂，且涉及的组件较多，在显示评论，状态变化等功能上均遇到了bug，所有bug已完整记录在Beta测试报告中，在设计开发阶段已经根据其实现难度预料到后续测试中会出现较多的bug，在测试发现bug后，团队负责成员一一对其进行修复，保证了最后功能的正常

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

我们的代码复审包括三个阶段：

• 首先是自我评审：代码书写者自己对照事先约定的代码规范进行审查
• 其次是同行评审：同样负责前端/后端的几个开发者之前互相评审对方的代码。
• 最后是桌面评审：开发者当着其他成员的面，对着代码阐述功能、逻辑等，其他成员进行评审。

我们的代码严格执行了代码规范

6.我们学到了什么？如果历史重来一遍，我们会做什么改进？

合理拆分项目，充分利用CI/CD，真正做到持续集成，敏捷部署，同时部署代码规范化检查，保证良好代码风格

六、测试与发布

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

有测试计划，开发时开发人员撰写单元测试，开发完成后由测试人员进行综合测试、场景测试和压力测试等，同时利用微信公众平台的性能监控完成小程序的性能测试

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

进行了正式的测试验收，具体测试验收情况请参考博客Beta阶段测试报告

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

有。团队借助Gitlab的CI/CD配置，结合JavaScripts的Mocha测试框架来完成自动化的代码测试。最终测试覆盖率达到95%

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

团队主要通过记录分析请求时间、功能测试和场景测试来测量软件的效能。压力测试情况请参考Beta阶段测试报告-压力测试。从软件实际运行结果来看，这些测试工作有用，保证了题士在高并发的访问场景下运行正常

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

由于发布时处于毕业季和临近7.1等因素，未能按原定计划在北航官媒上进一步宣传题士，不过我们仍然通过各种渠道宣传题士，同时题士在最后的考期阶段，在目标人群之间形成了自发宣传的效果

6.我们学到了什么？如果历史重来一遍，我们会做什么改进？

提前制定测试计划，并在开发测试过程中，严格执行测试计划，从而保证软件的按时以及高质量的交付与发布

七、团队角色管理与合作

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

团队角色由各自的开发经验确定。

团队一共六人，其中

• QSY，LS，CWM三人有前端开发经验，故在团队中担任前端开发与测试角色

• LKL，CYY，WCC三人有后端开发经验，故在团队中担任后端开发与测试角色

• QSY具有较多的学生工作、团队开发和宣传推广的经验，故在团队中同时担任PM的角色

从两阶段实现结果来看，前后端开发进度稳步推进，设定功能基本实现，团队成员贡献度均较高，所以可以认为人尽其才

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

团队成员彼此熟识，配合默契，在开发过程中互相帮助，以此保证了进度的正常推进。

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

Beta开发阶段团队每两天进行一次线下例会，每次例会总结个人开发进度，讨论开发成果，制定开发计划，并进行集中高效开发

PM完善并推进主体开发计划，如Beta阶段需要实现微信小程序开发，产品主页的翻新和后台管理系统的完善等，前后端具体开发内容在每次线下例会讨论时确定，团队成员可以及时沟通，及时调整

八、总结

1.团队目前的状态属于 CMM/CMMI 中的哪个档次?

根据CMM定义，结合Alpha开发过程得出团队目前的状态为优化级(Optimizing)

2.团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?

团队目前符合博客中描述的创造阶段的若干特征与现象，故处于创造阶段

3.团队在这个里程碑相比前一个里程碑有什么改进?

和Alpha阶段相比，Beta阶段更注重任务划分的粒度、利用issue进行了更完整的记录、提升了单元测试覆盖率，有效地提升了软件项目质量

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

根据《构建之法》中敏捷开发12条原则的定义与描述，小组两阶段阶段做的最好的原则包括

• 尽早并持续地交付有价值的软件以满足顾客需求：在设定时间内实现题士Beta版本预期的所有功能，功能和用户需求可以做到一一对应，结合用户反馈，用户使用Beta版本的题士较为满意，题士团队也将根据用户反馈进一步改进，提升用户体验，持续交付
• 经常发布可用的软件，发布间隔可以从几周到几个月，能短则短：每次迭代开发的版本会直接申请小程序的审核，审核通过后用户即可使用，发布间隔较短
• 无论团队内外，面对面的交流始终是最有效的沟通方式：团队每两天集中开发，面对面沟通交流，及时调整，效率较高
• 只有能自我管理的团队才能创造优秀的架构、需求和设计：团队成员均对项目抱有认同感，可以主动提升团队开发任务相较于个人任务的优先级，优先保证项目进度正常推进，团队可以做到自我管理，项目整体完成度较高

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

项目采用gitlab的Milestone+issue+Merge Request的方式进行代码管理、版本控制等，通过进一步规范项目管理过程，比如指定分支作为测试分支，不同开发分支有效隔离，阶段性成果及时merge等，提升项目整体的代码质量

代码复审时需尽可能地保证同行评审（负责前端/后端的几个开发者之间互相评审对方代码）和桌面评审（开发者当着其他成员的面讲解代码功能），开发人员在开发过程中需遵守标准的代码规范，从而提高代码复审和代码规范的质量

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

题士项目的技术架构为

题士各页面跳转逻辑为

可以通过设定规范完整的API，尽量降低前后端耦合性，从而提高质量

衡量质量的提高的方法具体包括系统bug数量的减少量，修复bug耗时的减少量，整体功能完成时间的减少量等

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

充分利用gitlab的Milestone+issue+Merge Reques的管理方式，如降低issue的粒度，及时创建/关闭issue，及时merge成果

9.项目管理有哪些具体的提高？

在项目管理方面，相较于Alpha阶段，开发任务和Bug均与issue形成了一一对应，保证了任务的明确和开发/修复过程的详细记录

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

通过搭建后台管理系统，同时借助微信公众平台，实时统计日活、访问量等数据，具体数据部分见本博客数据补充部分

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

通过在开发阶段及时补充、完善和规范项目文档，统一文档格式等方式提高项目文档的质量

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

• 让团队中每个人的长板变得更长：既然组成一个团队，那么就要充分利用每个人的长板，比如团队中的成员相较于文字，更喜欢也更善于写代码，那么他应当承担更多的代码工作，而非博客作业的撰写

• 对团队中的每个人抱有足够的信任：既然把某项任务分配给团队中的某个人，说明相信他可以完成此任务，即对他抱有足够的信任，当然，及时的push和进度把控也是必要的

13.对于软件工程的理论，规律有什么心得体会或不同意见？

详见Beta阶段性总结

九、建议

回顾题士两阶段开发过程，在项目管理上尚存不规范之处，为此进行了相应的反思与总结，单独形成一篇敏捷开发规范化的博客，希望可以为未来的团队进行规范化敏捷开发提供参考价值

十、讨论会

十一、题士再相逢

十二、团队开发回顾

十三、最好的题士，最棒的我们

Beta事后分析