1.题士开发总结

<iframe allowfullscreen="true" frameborder="0" src="https://v.qq.com/txp/iframe/player.html?vid=l3253zzdq5i" style="width: 100%; height: 500px"></iframe>

2.反思

2.1 Issue管理

从0522敲定各个功能的API后，团队成员及时沟通，积极开发，但由于开发过程没能有效体现在issue上（如未能及时在issue上形成记录，功能开发完成后未能及时关闭issue等），而是等到0529（当然时隔一周才进行第二次例会，一方面是因为题士Beta阶段开发开始日期本身早于原定计划，时间弹性较大；另一方面是因为0522至0529这一周组内部分成员需要同时参与各种比赛，时间并不宽裕）再次例会时才统一进行处理，实属不当，未能较好地记录这一周的开发过程，不过在后续的开发过程中，做到了在issue中图文并茂地记录Beta开发过程。

2.2 产品设计

Beta阶段开发初始并未计划对产品主页进行翻新，直至Alpha阶段深度评测博客的出现(再次感谢老师、助教对题士的深度评测)，让我清醒地意识到“产品”不单单指题士小程序，而是与题士相关的所有内容，包括产品主页和后台管理系统。故而开始着手产品主页的重新设计，并将产品主页与后台管理系统分离，真正使题士、产品主页和后台管理形成完整的系统，做到了好马配好鞍，面里均具备。

3.建议

以下建议为开发过程中的所思所想，个人观点，仅供参考

3.1 燃尽图

建议统一燃尽图标准，推荐使用Issue数量变化曲线作为燃尽图主体曲线，既能考察Issue划分粒度，又能考察Issue管理，还能客观直接地展现项目未完成的任务数量

3.2 团队选题

不建议继续提供往届题目作为备选选项（从本届选题结果来看，确实无人选择往届题目），往届项目作为已经经历一学期打磨的产品，核心功能已经较为完善，再次开发的难度较大

建议将往届优秀项目作为团队选题时的参考，并系统地说明优秀之处，对后续团队开发等过程具有更大的价值和意义

3.3 项目评审

建议统一项目评审标准，细分不同的评审内容，而非当前的纯主观评价与排名机制