1.题士开发总结
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 项目评审
建议统一项目评审标准,细分不同的评审内容,而非当前的纯主观评价与排名机制