【CodingNoBorder - 10】无际软工队 - 求职岛：ALPHA 阶段事后分析

admin管理员组

文章数量:1627945

无际软工队 - 求职岛：ALPHA 阶段事后分析

项目	内容
这个作业属于哪个课程	2022年北航敏捷软件工程
这个作业的要求在哪里	团队项目-Alpha阶段事后分析
我们在这个课程的目标是	熟悉敏捷开发的方法论，并通过实际开发产品进行实践。
这个作业在哪个具体方面帮助我实现目标	熟悉敏捷开发的方法论：按照给定的模板了解产品总结所应涉及并反思的各个方面。 通过实际开发产品进行实践：对照产品 ALPHA 阶段的实际开发，分析实践带给我们的宝贵经验。

Author: 无际软工队

Date: 2022.05.19

我们如何完成这篇事后分析？

依然按照本团队的优良传统，例会讨论后共同完成文档的撰写，再由协调员 PM 进行总结。

以下各部分会注明各部分的初稿编写成员。

设想和目标

By Selia & JJLeo.

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

本项目将开发一款聚焦校内科研实习和内推信息聚合的中和求职平台，主要解决问题有以下几点：

1. 方便本科生寻找合适的实验室实习，了解更多校内前沿实验室和研究方向，为未来的学业规划打下基础。
2. 方便学生寻找校内的内推信息，快速加入企业实习，与学长学姐进一步交流经验，为未来的职业生涯打下基础。
3. 方便教师发布招收实习生需求信息，招收到更多合适的本科实习生，为相关领域注入新鲜血液。
4. 方便已就业的学长学姐发布内推信息，快速招收本校高质量实习生，促进企业与学生之间的交流，帮助树立良好的企业形象。

我们的需求定义明确清晰（选题和需求分析），进行了充分的调研，对使用者的需求有较好的把握。

我们对典型用户和典型场景有清晰的描述（功能规格说明书），我们的典型用户主要有四类，与前文需求中的四个角度相对应，分别是寻找校内实习的本科生、寻找企业实习的学生、招收实习生的教师、有发布内推需求的往届生。典型使用场景著有为校内实习生招收和企业内推两部分，思路清晰，定义明确。

我们达到目标了么？

在原计划中，我们设计了个人控制台、主页功能、通知与消息三大基本功能模块。在 Alpha 阶段，我们完成了面向求职者的各项功能和面向招聘者的部分功能。

求职者用户可以通过个人控制台管理个人简历信息，实现了包括个人基础信息、教育经历、科研经历、获奖经历等简历信息的管理功能。求职者也可以体验主页功能，浏览各项招聘信息，查阅招聘详情和对应的实验室、招聘人员的公开信息，并投递个人简历，与招聘人员取得联系。在投递简历后，求职者可以收到来自招聘人员的消息，或在个人控制台中查看相关进展。

招聘者的管理功能尚在完善，后续我们将在 web 平台和小程序中完善招聘者视角的信息管理功能，让招聘者更方便快捷地操作。

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

团队的工程质量有所提高，主要体现在以下几个方面：

1. 在本阶段中，代码管理质量有较好提高。我们对仓库的代码管理有明确规则方案，团队按照相关规范进行内容的提交和分支的合并。我们对前后端代码拥有完备的自动化代码风格检查，每次提交都将进行自动化测试。
2. 在本阶段中，代码质量有较好提高。对于后端部分，我们深入学习了 Django 的 Restful 相关框架，使得我们的代码更简洁，更有健壮性。对于前端部分，我们基于 MVVM 架构开发，一位开发者专司原型设计和视图绘制，其余两位基于 VueX 状态管理框架处理 ViewModel，在高效分工的同时也保证了代码的可靠性，为后续增量开发降低了成本。
3. 在本阶段中，团队配合更好。经过一段时间的团队磨合，我们在交流过程中更有经验，结合使用Notion 和群聊，让信息传递更加简明和精准。

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

预想的基本一致，用户对于主要的功能很有期待。在联络老师或往届学生提前入驻平台时，很多人都说“这是好事”、“这很不错”等等。在 Alpha 版本发布时，很快积累了百余位学生用户。可见，不论是求职者还是招聘者，都对我们的平台的初期基本功能较为满意。然而，我们在设计过程中仍有不足，一些细节设计尚未完善，比如少数重要的按钮容易误触，以及招聘者平台的不完善等等。

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

我们积极反思，发现我们的问题主要集中在以下几个方面：

1. 细节设计不足，在一些按钮设计上，我们不能假设使用者是“理性”的，我们要考虑到他们可能出现的误触、误操作等情况。
2. 在设计修改上不能得心应手，由于在与职协的合作中有对平台上进行比赛的要求，使得我们的设计有所调整。我们在调整过程中未能较快地确定方法进行修改，使得后期部分功能未能顺利上线。

综合上述问题，我们深入思考，总结经验，在以下几个做出改进：

1. 请更多的测试用户来对我们的产品进行体验，体验人员应当尽可能涉及更多的专业领域，而不局限于信息类学生。
2. 在设计发生修改时，需要相关技术负责人尽快确定解决方案，并准确清晰地告知相关开发人员，做好协调工作，保证任务按时完成。

计划

By Selia & TakiVotoid.

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

在本阶段，我们拥有足够的时间来做计划。在项目进行初期，我们对整个项目的调研、开发、测试等相关工作做了详细的长期计划。在各项阶段进行的过程中，我们坚持周例会、Scrum Meeting 制度，规划短期任务。

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

无际软工队由七名成员组成，大家性格各异、技能及对产品的理解亦各不相同。

——在项目开发的每一个阶段，都希望能发挥每个人的技能和才智。

基于这个朴素的愿望，项目开始时团队成员一致同意：我们更进一步，在产品成型的各个流程都打破传统意义上的层级关系，扁平化组织结构，在重视每一个人参与和思考的前提下，完成不只限于开发，更包括调研策划、文档完成、宣发推广等在内的各项任务。

在团队决策上，由于上述原则和特点，团队避免采用 PM 拍板方式，也不采用简单的多数决方式来完成开发过程中涉及的各项决策。每次团队讨论依照：提出方案——寻找问题——解决问题——确立共识的方式来进行。

当遇到意见分歧时，我们会先请具有不同观点的团队成员简明扼要、重点突出地阐述理由。然后其他同学加入，进行一段时间的自由讨论。对于每一个策划提案，大家需要从各个角度提出潜在问题和疑虑。我们从疑虑少的方案入手，一项项讨论解决方案，直到取舍和平衡被所有人接受为止。

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

还真都做完了，哈哈！

——虽然很想这么说，本团队在实际开发过程中，受合作方需求变更和微信小程序审核时效的影响，进行了计划的二次调整：具体而言，将双端并进的任务规划调整成先完成求职者的完成可用小程序平台，再进行后台管理封装——用户后台开发的两步走工作量设计。

二次调整后的工作量，则基本按照计划进行，完成了 ALPHA 阶段预期的全部内容。

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

在后端开发时，我们几经修改接口的实现形式。最初，我们没有注意到 DJango 和 Restful 框架为我们提供的一些相关简化使用方法，在完成 API 的设计时，代码繁琐，安全性和健壮性差。后来经过组员的沟通和协作，我们引入相关组件，重构了相关代码。在这一事项中，先前的探索看似无用而又浪费时间，但是这样的探索也能作为后续开发的经验和教训供我们反思。

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

是的，在项目的开发过程中，我们以前端为主要导向，前端每一项需要后端提供的 API 都在 Notion 中以文档的形式明确给出相关需求，后端完成相关 API ，将调用方法以及需要注意的细节填写到相关文档中。这些 API 即是一个个独立的交付件。

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

项目开发过程中，有两项意外事件：

1. 由于平台的特殊性，平台域名备案在漫长的管局审核过程中，由于缺少资质文件被打回。这一事项在服务商的前置审核中也没有被提前指出和纠正。这是我们始料未及的事项，团队只好采取将平台部署至备用已备案服务器上的方式、重新进行压力测试和性能调优的方式来临时应对这一意外。事后复盘，我们认为，面对不可抗力因素要确保平台的正常上线和如期稳定运行，要预先做好信息准备、留足时间提前量、维护备用系统。
2. 由于合作方职协的需求变更，团队需要优先完成微信小程序端。在这一点上，团队提前做了考虑——我们采用多端可用、代码易迁移的跨端框架以编码前端，在风险来临时顺利纾解了危机。

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

在计划中，我们预留了缓冲区，用来应对意外，例如：

1. 小程序审核出现问题；
2. 服务端部署出现问题；
3. 服务器、域名的购买、申请出现问题；
4. 需求临时更改带来的功能设计的重新规划和重构问题；
5. 在实现中发现原本设计方案中存在的问题。

第三、四点我们真切地遇到了，第五点在实现的细微之处体现。

——产品最终顺利发布，留下的缓冲区帮了我们大忙。

将来的计划会做什么修改？

综上所述，团队应当继续坚持留足提前量、做好 PLAN B 准备的做法。

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

团队对审核等政策风险估计不足，应当继续学习相关知识，积累经验。

资源

By TakiVotoid.

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

团队共有七人，工作量分配合理。在物质资源上，由于有合作方和大学生创业支持，不存在经济上的问题。在宣发资源上，团队采取针对性投放、争取合作方展示资源等方式，实现了较好的宣发效果，可以说资源足够。

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

每周例会，我们都回顾了上一阶段的工作、进行下一阶段的工作量评估，团队始终处在磨合、再认识的动态调整过程中，因而对时间和资源分配具有较合理的把握。任务的粒度管理上，我们压缩到两日内完成的粒度，加以基于 Scrum Meeting 的周期性动态管理的方式，没有出现太大的、可避免的问题。

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

从测试报告来看，团队的系统即使在 ALPHA 阶段也达成了较高的完成度和测试覆盖率，没有出现严重的 BUG。

美工设计工作交由团队的原型设计来完成，后文会提到代码实现上出现的问题，但非编程因素并没有造成问题的产生。

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

后文介绍了团队分工的具体方式和实践，总体来说团队的任务分配是合理的。

在前端的最后成型阶段，有进行线下的密集小组集体开发，团队成员各司其职成功完成了任务，可以认为虽然进度管理在不可抗力因素的打击下出现了一定问题，但团队的成员管理和任务分工是经受住了挑战的。

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

团队应当进一步细化分工，确保每个人的工作粒度更细、团队岗位分工更具针对性。

变更管理

By TakiVotoid.

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

团队采用 Notion 进行项目文档管理，并通过任务看板、Github Issues 方式来展示任务；团队组织了有效的会议，并实行会议纪要轮值制，确保每一位成员对项目进度的把控和了解。在变更管理上没有产生明显的问题。

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

团队优先考虑合作方的需求，决定首先冲击上线的平台。

对于用户的两种角色，团队优先处理只能采用 to C 模式解决的部分：求职者；对招聘者则优先采用 to B 模式，以团队沟通、定制化对接工作来减少开发工作量，缓解开发压力。

对于功能组，我们优先完成基本功能，其次完成惊喜功能，最后进行体验的打磨。

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

有。项目的出口条件可见 ALPHA 阶段测试报告。

对于可能的变更是否能制定应急计划？

前文已经指出了团队所预见的风险和预案。团队遇到的两项意外及对这些意外的成功应对和处理，体现了团队在应急计划制定上所做的努力。

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

从由于微信审核不可抗力因素导致的，前端最终的线下小组开发冲击上线的过程来看，团队具备完成意料之外工作请求的能力。

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

团队管理和分工建构的鲁棒性，决定了团队面对挑战和变更的能力。团队应当进一步健全管理机制，保证各尽其能，宏观调控每个人的工作量和投入，帮助团队更好地面对挑战。

设计／实现

By roife & TakiVotoid.

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

设计工作在编码之前进行，由团队共同讨论完成。

• 首先，由 PM 根据项目的规划提出项目需求，并将需求划分为 Alpha 阶段需求和 Beta 阶段需求两部分；
• 然后在 Scrum Meeting 上由PM与团队进行讨论，根据开发难度对需求进行重新规划；
• 规划完成后，在实现过程中仍然可能发生部分需求上的变化，由开发者反馈至 PM，汇总后在 Scrum Meeting 上讨论决定。

从 Alpha 阶段开发结果来看，目前顺利完成了 Alpha 阶段预期的功能。

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

在设计中存在一些模棱两可的分歧，主要在架构设计与 UI 设计等方面上。

当发生这种情况时，有不同想法的成员首先会在私下交流解决。如果交流后仍然有不同意见，则会在 Scrum Meeting 上进行讨论。目前在开发过程中遇到的设计上的分歧都能够在当次 Scrum Meeting 上解决，保证了开发的推进。

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

团队在开发过程中充分利用了 Unit Test，并且后端单元测试覆盖率达到了 93%。同时，每次将功能分支和 BUG 修复分支合并到开发主分支时，会自动触发设置的 CI，从而进行回归测试等。

单元测试很好地保证了代码的健壮性，大大减少了开发过程中因为不谨慎以及多人协作冲突导致的 BUG。

同时，前后端仍然使用了 Notion 作为开发交流的渠道。Notion 可以记录文档的修改者以及修改历史记录，同时可以给团队成员分配任务，大大提高了开发效率，减少了沟通成本。

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

本项目在建立之初就充分考虑了安全性等问题，因此在发布后没有发现严重的 BUG，大部分 BUG 来自于前端的显示和交互等。

目前大部分 BUG 来自于微信小程序的开发框架导致的前端交互 BUG。由于一些不明原因，微信小程序的真机测试版与发布版存在使用上的区别，导致一些原定的交互操作不能很好触发。但是这并没有影响到主要功能的使用，且用户较难发现。

我们认为这是因为我们对于微信小程序端开发的经验尚不充足，没有想到微信小程序框架存在的一些坑，导致 BUG 在送审前因为无法被触发而未被发现。

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

代码规范分为两部分。

首先是代码风格相关的规范，这一点由我们的 CI 以及相应的 Lint 工具保证。

其次是代码实现的规范。在项目初期，由一名同学负责审查成员的代码，并对不规范的写法进行纠正，且这一过程持续了数天。

当团队成员已经能够写出符合规范的代码后，这名同学就减少了审查方面的工作，并将精力投入到开发工作中。

当然，在后续的开发中，我们仍然会在 Scrum Meeting 上进行部分代码复审工作，以保证大家严格执行了代码规范。

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

磨刀不误砍柴功，明确的、引入自动化的代码规范及质量管理机制，为团队带来了很大的帮助。Code Review 工作弥合了大家的经验差异，为团队的总体开发质量带来了较大的提升。

测试／发布

By 春日野くさ & TakiVotoid.

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

有。

团队针对各 API 功能组、用户端模块和操作流程，完成了单元测试、场景测试、压力测试等多维度、全方位的测试。对后端稳定性和预期功能、安全性，前端交互体验、视图逻辑等方面做了尽可能全面的测试。

同时，团队提供了一套 BUG 收集及反馈机制，并通过直接访谈、或用户群的方式触达用户，虽然时间紧迫，但仍收获了不少宝贵意见。

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

在验收阶段，团队组织全体团队成员进行了功能性测试，从用户的视角出发，补全用户故事的各个方面，以平台提供的功能序列为主干，测试边界问题。

即便如此，还是存在视图逻辑上的瑕疵未能解决，但这主要是由于不可抗力的审核发布时效过长，留给团队修复的时间过紧所致。

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

团队基于 DevOps 的最佳实践，实现并完善了 CI／CD 自动化单元测试。对于压力测试，也同样引入了自动化工具。

详见 ALPHA 阶段测试报告。

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

为了测试软件的性能，在使用 nginx + uwsgi 部署好服务器之后，我们使用 JMeter 进行了压力测试。测试过程均采用高并发利用全部服务器资源。

在进行压力测试时，我们对典型 API 进行了测试，覆盖网络连接、数据库性能、服务器端算力开销、内存占用等多个方面，详见 ALPHA 阶段测试报告。

基于压力测试，成员进一步进行了特定接口的调优、服务器资源管理和监控。

从实绩上来看，平台稳定运行一周有余，初始宣发的大流量也远没有达到给平台造成负担的程度。可以认为平台 ALPHA 阶段的测试设计和实践是卓有成效的。

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

发布的过程中，我们遇到的问题主要集中于前端：

1. 小程序桌面端渲染机制的不同导致小程序的布局等视图呈现在桌面端存在不同形式的龃龉；
2. 小程序的发布版本上滑加载逻辑失效，而测试版本无法复现，推测与小程序框架的代码打包发布、发布版脚本运行机制有关。

这两项问题指出了团队产品验收、稳定和发布流程中两个可以进展的方面：

1. 即便非预期平台，也应该进行覆盖面更广的兼容性测试，以尽可能吸引用户；
2. 吃一堑长一智，即便是这种唯有正式发布才能浮现的问题，也并非没有可以做的工作：积累经验是一方面，另一方面在完成相关逻辑时，应当做更全面的调研，选择最佳实践来完成编码任务。

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

除了上述提到的数点，我们还意识到，尽早地引入内测用户，对产品的打磨非常重要。内测用户能够跳脱出开发团队的预想情景、思维定势，展现最真实的用户使用情况。

团队的角色，管理，合作

By BUAA_Wander & neumy & TakiVotoid.

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

本团队成员共七人，三名前端开发人员，三名后端开发人员，一名机动开发队员。PM 由前端开发人员担任，团队整体以前端需求为驱动，前端与后端的交流与沟通贯穿了整个并行开发流程。

团队成员的角色主要由成员们各自所掌握的技能和工作经验决定。

PM 具有充足的前端开发设计经验，有一套稳定成熟的UI设计风格，且对产品交互设计有独到见解。

机动开发人员具有丰富的全栈开发经验，作为PM的补充，在技术问题上辅助PM进行决策，并在实际开发过程中辅助观察督促前后端进度。

后端开发人员均能够熟练使用Django框架，且在接口安全性设计、后端服务架构与性能调优方面也有丰富经验。

前端开发人员能够熟练使用Vue（及其衍生的Nuxt和uni-app）框架，在用户界面设计与提高交互体验方面表现出色。

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

团队开发过程中尽量坚持线下会议，并保持着极高的全员到会率，在会上我们就前后端的技术问题进行深入探讨，并在核心问题上进行全组讨论。

“授人以鱼不如授人以渔“，凭借着良好的分工方案，团队成员之间的帮助方式主要包括：

• 提出可行的技术方案，解决他人提出的技术难题；
• 在开发冲刺阶段，共同完成剩余的工作。

以后端为例，在项目开始前期，后端技术总监同学带领整个后端速览 Rest framework 的使用规范；每次开会的时候，后端会对最近的工作遇到的技术问题进行讨论与解答；后期后端将数据库换为 PostgreSQL ，这时组员们互相帮助重新配置开发环境，保证大家都能继续正常进行开发。

通过上面的过程，组员间相互学习借鉴，都能够学习到他人的技术长处，并且没有出现“拖油瓶”情况。

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

团队开发过程中，组员间学习氛围浓厚。团队成员在定期组会机制和有效的项目管理下，对项目进度保持良好的敬畏，使得项目推进顺利。

前后端合作过程中借助良好的接口文档规范和交流沟通机制，API接口对接较为顺利，虽然出现了部分开发不同步的情况，但是并未耽误正常项目进度。

项目开发期间为了应对突发的微信小程序审核事件，前端组需要紧急进行一次高强度开发。团队及时调配了机动开发人员来辅助工作，并在开发后的组会上对参与该次紧急开发的成员们给予了额外奖励分。

团队成员间的感谢

团队成员都很腼腆，但他们 给出的奖励分 是真实的。

如果需要的话，请课程组来现场听听大家的心声（课堂总结环节）。

总结

By TakiVotoid.

你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?

团队完成了本阶段的所有功能需求，进入完善阶段；同时，团队正在进一步丰富产品功能。处于 CMM 的已管理级（Managed）阶段和 CMMl 三级，明确级。

你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段？

团队的产品开发已步入正轨，各方面已形成完善的工作流，正处于创造阶段。

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

团队应当改进风险管理能力，并在需求挖掘上进一步投入精力。

对照敏捷开发的原则，你觉得你们小组做得最好的是哪几个原则？

示例已经在以上的各个分项、项目展示中提到过了，以下针对各条给出一个自评。

原则	完成质量
尽早和持续地交付有价值的软件来满足客户	⭐⭐⭐⭐
欢迎对需求提出变更	⭐⭐
要不断交付可用的软件	⭐⭐⭐
项目过程中，业务人员与开发人员必须在一起	⭐⭐⭐⭐⭐
要善于激励项目人员	⭐⭐⭐⭐
最有效的沟通方法是面对面的交谈	⭐⭐⭐⭐
可用的软件是衡量进度的主要指标	⭐⭐⭐
提倡可持续的开发	⭐⭐⭐⭐
对技术的精益求精以及对设计的不断完善将提升敏捷性	⭐⭐⭐⭐
要做到简洁，尽可能减少不必要的工作	⭐⭐⭐
最佳的架构，需求和设计出自于自组织的团队	⭐⭐⭐⭐⭐
团队要定期反省如何能够做到更有效，并相应调整团队的行为	⭐⭐⭐⭐

正如我们前面提到的， 软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提高软件工程的质量呢？

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

应当完善代码注释。代码规范团队做得已经较为完善，应当进一步扩大 Code Review 的范围和团队交流的代码质量层次和方面。

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

前端要重新规范层次化、模块化的 VM 架构，利用好集中式、树形展开的状态管理模式。后端要完善 API 版本机制、设计和实现迭代更新的具体步骤和流程，保证平台接口的鲁棒性，提高平台对新需求的适应能力。

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

尝试引入 Slack 等团队沟通工具，现有基于 QQ 的团队线上通讯手段存在局限性。

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

对于活跃用户分析，在后端运行了团队编写的数据统计与分析模块，但收集的数据仍不够全面。下一阶段可以考虑引入第三方数据记录与分析平台，分析用户热点。

代码层面以外，团队还应进行更密切、长期化的用户调研和跟踪，了解用户的反馈意见。

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

除了已有的 API 文档等项目文档，对于特定复杂模块、关键模块的具体实现机制，应要求开发成员做补充。

对于人的领导和管理，有什么具体可以改进的地方？

PM 要承担起宏观调控层面的更多责任，不只依靠各位优秀成员的主观能动性完成各方面工作。

虽然很可惜现在在封校，但项目进行过程中和项目完成后 PM 很难不请大家吃饭。

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

课堂学习时体会不深，实际实践下来的体验让我们意识到：软件工程的方法论是软件开发的生命之源。

其他感想和体会

By TakiVotoid.

开发方面的感想

DevOps 的重要性

由于团队（尤其是后端）在自动化工具上采用了高标准和最优实践，BUG 的出现大大减少，代码统一且高质量，为平台的稳定性提供了充分保障。

工期管理

项目的冲刺阶段，从燃尽图即可看出，进度出现了巨大的落后，最后不得不以通宵加班的方式完成开发。导致这一现象的原因一是微信审核等不确定性的叠加，从根本上来看更是项目分工的估计不足、容错率不高。项目前端的视图层开发与想象中相比花费了两倍以上的时间——这一迟延主要来源于对小程序端开发工具和机制的不熟悉。Beta 阶段，团队的开发重点将转移到更为熟悉的 Web 平台上来，但 ALPHA 阶段这一惨痛的教训仍应铭记在心，应进一步细致化前端的进度管理。

再谈前端开发实践

对于前端，团队基于 MVVM 思想进行开发，两位成员处理 VM、进行简单的原型开发，一位成员负责视图绘制和组装。

理想很美好，现实则不尽如人意。采用这种开发模式是我们做的最好同时也是最坏的决定。一方面，完全解耦的开发分工，不仅（在简陋的微信小程序开发环境下）消除了代码合并的问题，更大大利于调试和协作，为后期并行快速开发提供了条件；另一方面，没有层次化的 VM，搭配上高度层次化的视图层，导致了行为逻辑和数据的龃龉，视图层的组装困难程度大大加深，代码可读性下降——各调各的没问题，视图层和 VM 层之间几乎无法互相 Debug。

团队得到的启示是：除了自以为是的解耦措施之外，前端开发时在层次化、模块化方面也应当预先制定规范，统一架构再行开发。

看向开发之外——

项目合作

与职协的合作磋商和最终达成，是本团队开发之外所做最大的努力。

强有力的合作者，为平台引入了更坚固的背书、更明确的目标，以及在路上的更大声量。

但另一方面，也为平台带来了更多的要求、制限和“不可控”——尤其是在另一侧是无法松动的课程要求、既定安排的情况下。

作为产品的直接负责人——项目的开发者们，在需求和需求缠斗的正中间，面对滚动着压过来的名为工期的巨大落石，需要足够的智慧、足够谨慎的安排、留下足够的余量才能够勉强逃生，去攀登更高的山峰，去成就更为平衡、更为完善的产品。

——又或许，我们只是需要更多的实践，更多的经验，需要练就更好的与合作方沟通、探知和了解其需求的能力。

合作为我们带来了正向的促进和负向的压力。在 Beta 阶段，我们会继续挑战它——一块滚滚如雷的巨石，一方巍巍耀眼的峰顶。

团队氛围

Bravo。

——太棒了，大家！整个 ALPHA 开发过程中，团队的所有人共进退，共同面对挑战、克服困难、消解疑虑、各尽所能。我们会在初夏的阳光下兴奋地讨论产品，也曾在深夜的新主楼 G 座里一人一台电脑啃着麦当当奋战到天明。

十分庆幸，团队的七个人能走到一起，不只是完成一门课，更是完成一款雄心勃勃的产品，留下一段虽有缺憾但仍足以笑出来的回忆。

冒险仍在继续，我们将继续前行。

本文标签： 事后阶段CodingNoBorderAlpha软工队