|
|
|
|
@ -1,40 +1,59 @@
|
|
|
|
|
小组周计划-第1舟
|
|
|
|
|
团队名称和起止时间
|
|
|
|
|
团队名称： 菜鸟队
|
|
|
|
|
开始时间： 2025-10-13
|
|
|
|
|
# 小组周计划-第1周 #
|
|
|
|
|
## 团队名称和起止时间 ##
|
|
|
|
|
团队名称： 菜鸟队
|
|
|
|
|
|
|
|
|
|
开始时间： 2025-10-13
|
|
|
|
|
|
|
|
|
|
结束时间： 2025-10-19
|
|
|
|
|
本周总体目标
|
|
|
|
|
## 本周总体目标 ##
|
|
|
|
|
本周作为项目的**“奠基周”，核心目标是完成所有开发前的准备工作**。我们不编写任何业务功能代码，而是专注于统一团队认知、搭建协作基础、完成核心设计，确保在下周能立即、顺利地进入高效的编码阶段。
|
|
|
|
|
任务分解与分配
|
|
|
|
|
序号 任务内容 负责人 参与者
|
|
|
|
|
1 项目规划与协作流程建设 PM 全体成员
|
|
|
|
|
1.1 开会
|
|
|
|
|
1.2 创建Git仓库，研读规范定义分支管理规范。
|
|
|
|
|
2 开发环境配置并统一标准 全体成员
|
|
|
|
|
2.1 各自搭建并成功运行一个对应技术栈的demo项目（仅用于证明已经构建好开发环境）。
|
|
|
|
|
3 核心业务逻辑梳理 成员D 全体成员
|
|
|
|
|
4 系统架构设计 成员A 成员B, D
|
|
|
|
|
4.1 设计并文档化后端分层架构。
|
|
|
|
|
4.2 设计并文档化Android客户端的MVVM架构及模块划分。
|
|
|
|
|
5 数据库与API设计 成员A 成员B, C, D, E
|
|
|
|
|
5.1 根据业务流程图，设计数据库核心表并绘制ER图。
|
|
|
|
|
5.2 定义（不实现）用户认证模块的API接口，并编写文档。
|
|
|
|
|
## 任务分解与分配 ##
|
|
|
|
|
|序号|任务内容|负责人|参与者|
|
|
|
|
|
|:---:|:---:|:---:|:---:|
|
|
|
|
|
|1|项目规划与协作流程建设|PM|全体成员|
|
|
|
|
|
|1.1|开会| | |
|
|
|
|
|
|1.2|创建Git仓库，研读规范定义分支管理规范| | |
|
|
|
|
|
|2|开发环境配置并统一标准|全体成员| |
|
|
|
|
|
|2.1|各自搭建并成功运行一个对应技术栈的demo项目（仅用于证明已经构建好开发环境）| | |
|
|
|
|
|
|3|核心业务逻辑梳理|成员D|全体成员|
|
|
|
|
|
|4|系统架构设计|成员A|成员B, D|
|
|
|
|
|
|4.1|设计并文档化后端分层架构| | |
|
|
|
|
|
|4.2|设计并文档化Android客户端的MVVM架构及模块划分| | |
|
|
|
|
|
|5|数据库与API设计|成员A|成员B, C, D, E| |
|
|
|
|
|
|5.1|根据业务流程图，设计数据库核心表并绘制ER图| | |
|
|
|
|
|
|5.2|定义（不实现）用户认证模块的API接口，并编写文档| | |
|
|
|
|
|
|
|
|
|
|
其中ABCDE所指成员待本周第一次会议后分配
|
|
|
|
|
预期成果
|
|
|
|
|
到本周末，我们期望达成以下可交付的成果：
|
|
|
|
|
一份清晰的项目范围定义文档：明确了本次项目的核心功能边界。
|
|
|
|
|
一个配置好分支保护和协作规范的Git仓库：所有成员均已熟悉协作流程。
|
|
|
|
|
一份标准化的《开发环境搭建指南》文档：确保成员能建立开发环境。
|
|
|
|
|
两份核心业务流程图 (BPMN或泳道图)：直观展示了注册和支付的业务逻辑。
|
|
|
|
|
一份数据库设计文档：包含所有核心表的ER图和字段说明。
|
|
|
|
|
一份API接口文档初稿 (使用Swagger/Postman)：定义了用户模块的API“契约”。
|
|
|
|
|
风险与应对措施
|
|
|
|
|
风险：团队成员对业务逻辑理解不一致。
|
|
|
|
|
描述： 在讨论中可能出现对支付、认证等流程细节的理解偏差，若不解决会影响后续开发。
|
|
|
|
|
应对措施： 强制要求所有业务逻辑的讨论都必须以流程图的形式具象化并存档。在评审环节，由不同角色的成员（如前端、后端）复述流程，确保理解一致。
|
|
|
|
|
风险：技术选型或架构设计过于理想化，脱离团队实际能力。
|
|
|
|
|
描述： 可能会选用一些流行但团队不熟悉的技术，或设计过于复杂的架构，导致后续开发困难。
|
|
|
|
|
应对措施： 技术选型严格遵循“成熟优先”原则，优先选择团队已有一定了解或学习资源丰富的技术。架构设计上，KISS (Keep It Simple, Stupid) 原则，先保证能跑起来，后续再考虑优化。
|
|
|
|
|
风险：环境配置问题消耗过多时间，挤占设计讨论时间。
|
|
|
|
|
描述： 个别成员在环境搭建上可能遇到顽固问题，导致无法参与到后续的设计环节。
|
|
|
|
|
应对措施： 设定明确的时间节点（如周二下班前）作为环境搭建的Deadline。对于超时仍未解决的成员，立即启动“结对帮扶”机制，由组长或其他有经验的成员介入，一对一协助解决，确保不让单个成员掉队。
|
|
|
|
|
## 预期成果 ##
|
|
|
|
|
到本周末，我们期望达成以下可交付的成果：
|
|
|
|
|
|
|
|
|
|
* 一份清晰的项目范围定义文档：明确了本次项目的核心功能边界。
|
|
|
|
|
|
|
|
|
|
* 一个配置好分支保护和协作规范的Git仓库：所有成员均已熟悉协作流程。
|
|
|
|
|
|
|
|
|
|
* 一份标准化的《开发环境搭建指南》文档：确保成员能建立开发环境。
|
|
|
|
|
|
|
|
|
|
* 两份核心业务流程图 (BPMN或泳道图)：直观展示了注册和支付的业务逻辑。
|
|
|
|
|
|
|
|
|
|
* 一份数据库设计文档：包含所有核心表的ER图和字段说明。
|
|
|
|
|
|
|
|
|
|
* 一份API接口文档初稿 (使用Swagger/Postman)：定义了用户模块的API“契约”。
|
|
|
|
|
## 风险与应对措施 ##
|
|
|
|
|
1. **风险：** 团队成员对业务逻辑理解不一致。
|
|
|
|
|
|
|
|
|
|
- **描述：** 在讨论中可能出现对支付、认证等流程细节的理解偏差，若不解决会影响后续开发。
|
|
|
|
|
|
|
|
|
|
- **应对措施：** 强制要求所有业务逻辑的讨论都必须以流程图的形式具象化并存档。在评审环节，由不同角色的成员（如前端、后端）复述流程，确保理解一致。
|
|
|
|
|
|
|
|
|
|
2. **风险：** 技术选型或架构设计过于理想化，脱离团队实际能力。
|
|
|
|
|
|
|
|
|
|
- **描述：** 可能会选用一些流行但团队不熟悉的技术，或设计过于复杂的架构，导致后续开发困难。
|
|
|
|
|
|
|
|
|
|
- **应对措施：** 技术选型严格遵循“成熟优先”原则，优先选择团队已有一定了解或学习资源丰富的技术。架构设计上，KISS (Keep It Simple, Stupid) 原则，先保证能跑起来，后续再考虑优化。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
3. **风险：** 环境配置问题消耗过多时间，挤占设计讨论时间。
|
|
|
|
|
|
|
|
|
|
- **描述：** 个别成员在环境搭建上可能遇到顽固问题，导致无法参与到后续的设计环节。
|
|
|
|
|
|
|
|
|
|
- **应对措施：** 设定明确的时间节点（如周二下班前）作为环境搭建的Deadline。对于超时仍未解决的成员，立即启动“结对帮扶”机制，由组长或其他有经验的成员介入，一对一协助解决，确保不让单个成员掉队。
|
psoyzuart
Yorkeyra