图书馆管理系统项目冲刺博客 Day1

图书馆管理系统项目冲刺博客 Day1
团队名称：花好月圆
冲刺周期：第12-13周
冲刺目标：交付具备图书管理、读者管理、借还书核心流程的可运行系统

一、各个成员在 Alpha 阶段认领的任务

成员	角色	认领的核心任务	主要职责
袁斯楷	前端开发	前端界面设计与实现
		用户交互与体验优化
		响应式布局与组件开发	负责所有用户界面的实现，确保界面美观、交互流畅，并适配不同设备。
颜嘉盈	后端开发	数据模型与存储层设计
		核心业务逻辑实现
		API接口开发与维护	负责系统后端架构，包括数据库设计、业务规则实现和数据持久化。
黄思博	统筹测试	项目进度与质量管理
		用户认证与权限系统
		测试用例设计与执行	负责整体项目协调，确保开发流程规范，并主导安全认证与测试工作。
何昊天	性能优化	搜索算法与性能优化
		系统性能监控与调优
		高级功能（推荐、缓存）实现	负责系统性能提升，优化关键算法，并实现智能推荐等增强功能。

二、明日各个成员的任务安排

成员	明日具体任务	预期产出
袁斯楷	搭建项目前端基础框架（HTML/CSS）	项目基础目录结构
	设计并实现登录页面静态布局	登录页面HTML/CSS代码
	制定UI组件规范	UI组件设计文档
颜嘉盈	设计核心数据模型（ER图）	数据库ER设计图
	实现本地数据存储基础框架（Store）	Store模块基础代码
	编写基础工具函数（加密、日期等）	工具函数库
黄思博	制定用户认证与路由方案	认证系统设计文档
	编写首个冲刺的测试计划	测试计划V1.0
	配置项目开发与测试环境	环境配置指南
何昊天	调研前端搜索与排序算法	算法选型报告
	制定性能基准测试方案	性能测试用例
	协助搭建项目基础构建流程	项目构建脚本

三、整个项目预期的任务量

1. 任务分解（WBS）与故事点估算
基于Product Backlog，我们将Alpha阶段的核心功能分解为以下模块，并采用故事点进行工作量估算：

功能模块	子任务	故事点	优先级
用户认证与路由	登录/注销、权限控制、路由导航	9	P0
数据存储层	本地存储设计、CRUD操作、数据初始化	10	P0
图书管理	图书编目、副本管理、信息维护	13	P0
读者管理	读者注册、信息管理、权限配置	12	P0
借还书业务	借书、还书、续借、状态跟踪	15	P0
前台用户界面	读者端：检索、个人中心、借阅历史	11	P1
后台管理界面	管理员端：数据管理、操作界面	9	P1
搜索与推荐	图书检索、算法优化、随机推荐	8	P1
统计与报表	借阅统计、超期报告、数据可视化	7	P2
系统设置	参数配置、数据导入/导出、日志	6	P2

2. 冲刺总工作量与燃尽图起点
总故事点估算：9 + 10 + 13 + 12 + 15 + 11 + 9 + 8 + 7 +6 = 100 故事点

Alpha阶段目标：完成所有P0级功能及部分P1功能，计划完成 100故事点。

燃尽图起始值：本次冲刺的燃尽图将以“100故事点”作为起点。

3. 工作量分配策略
并行开发：前端与后端同步进行，每日站会同步接口。

优先级排序：严格遵循P0>P1>P2的顺序，确保核心功能优先完成。

缓冲时间：预留10%的故事点（10点）作为风险缓冲，应对需求变更或技术难题。

四、敏捷开发前的感想

袁斯楷（前端开发）：
“第一次参与正式的敏捷开发，既期待又有些紧张。期待能与后端同学紧密协作，快速将设计稿转化为可交互的界面。担心的是界面细节调整可能会比较频繁，希望每日站会能帮助我们及时对齐预期。”

颜嘉盈（后端开发）：
“数据模型和业务逻辑是系统的基石，必须设计得稳健且灵活。采用敏捷开发意味着我们需要更频繁地沟通和调整API接口，这对我是一个很好的锻炼机会。希望团队能建立起高效的沟通机制。”

黄思博（统筹测试）：
“作为统筹，我最大的责任是确保进度透明、质量可控。敏捷开发要求我们‘拥抱变化’，这对测试计划和用例设计提出了更高要求。我相信通过每日站会和持续集成，我们能及早发现并解决问题。”

何昊天（性能优化）：
“我对算法优化和性能调优充满兴趣。敏捷冲刺的快节奏可能会让性能优化面临挑战，但我计划将性能基准测试嵌入开发流程，确保每次提交都不引入性能退化。期待与团队一起打造一个既功能完善又响应迅速的系统。”

五、团队期望

1. 冲刺目标
“在两周内，交付一个可运行的图书馆管理系统核心版本，实现图书的录入、查询、借阅、归还功能，并为管理员和读者提供清晰易用的操作界面。”

2. 质量目标
代码质量：遵循统一的编码规范，关键代码块注释率100%。

测试覆盖：核心业务逻辑单元测试覆盖率不低于80%。

可用性：主流程用户操作路径清晰，无阻断性缺陷。

3. 协作期望
每日站会：准时参加，发言聚焦“昨日进展、今日计划、当前障碍”。

沟通机制：使用团队协作工具（如GitHub Issues）跟踪任务，阻塞问题不过夜。

代码评审：所有合并请求（Pull Request）必须经过至少一名其他成员的Review。

4. 成果交付物
可本地部署运行的系统原型。