第15周:Flutter 项目实践(第二部分)

周学习目标

学会小组协作开发,掌握产品设计和原型制作方法,理解用户需求,能够规划和分工开发完整的功能模块。


📚 核心内容

讲授(2小时)

一、产品设计与需求分析

产品开发流程

需求分析 → 产品设计 → 原型制作 → 视觉设计 → 开发实现 → 测试验收 → 发布迭代

需求分析文档模板

# 产品需求文档 (PRD)

## 1. 文档概述
- 产品名称
- 文档版本
- 最后更新日期
- 产品负责人
- 设计人员

## 2. 产品概述
### 2.1 产品定位
- 目标用户群体
- 用户痛点
- 产品价值主张

### 2.2 核心功能
- 功能 1
- 功能 2
- 功能 3

## 3. 用户故事 (User Stories)
以用户视角描述需求:

作为一个 [用户角色] 我想要 [用户需求] 以便 [受益/价值] 接受标准:

示例:

作为一个学生用户
我想要保存我的待办事项
以便我不会忘记我的任务

接受标准:
- [ ] 能添加新的待办项
- [ ] 能标记待办项为完成
- [ ] 待办项在应用关闭后仍保存

4. 功能需求

4.1 用户注册

4.2 用户登录

5. 非功能需求

6. 用户界面流程 (User Flow)

[流程图]

7. 数据流程

[数据流图]

8. 成功指标

用户故事卡

┌─────────────────────────────────┐
│  作为 [用户角色]                │
│  我想要 [功能]                  │
│  以便 [受益]                    │
├─────────────────────────────────┤
│  接受标准:                     │
│  ☐ 条件 1                       │
│  ☐ 条件 2                       │
│  ☐ 条件 3                       │
├─────────────────────────────────┤
│  优先级:High/Medium/Low        │
│  估算工时:__ 小时              │
│  分配给:                       │
└─────────────────────────────────┘

二、产品原型设计

低保真原型(Wireframe)

用于快速验证概念和布局

┌──────────────────────────┐
│      AppBar              │
├──────────────────────────┤
│                          │
│    主要内容区域          │
│                          │
│                          │
├──────────────────────────┤
│  按钮1  |  按钮2         │
└──────────────────────────┘

中保真原型(Mock-up)

包括基本的设计元素和颜色

┌────────────────────────────────┐
│  ← 返回    标题    ⋮           │
├────────────────────────────────┤
│  □ [图片]  产品名称 ★★★★☆     │
│  价格: ¥99  分类: 电子产品     │
├────────────────────────────────┤
│  描述:这是一个很好的产品...   │
│                                │
│  库存: 50 件   已售: 100 件    │
├────────────────────────────────┤
│       [添加到购物车]            │
│       [立即购买]                │
└────────────────────────────────┘

高保真原型(UI Design)

完整的视觉设计,接近最终产品

推荐工具

Figma 基础操作

1. 创建项目和文件
2. 绘制矩形、圆形等基本形状
3. 添加文本和图像
4. 创建组件库
5. 制作交互原型
6. 分享和协作
7. 导出设计资源

三、小组协作与分工

团队角色分工

产品经理 (PM)
├── 需求分析
├── 用户研究
├── 产品规划
└── 需求优先级排序

设计师 (Designer)
├── 产品原型
├── UI 设计
├── 用户体验
└── 交互设计

前端开发 (Frontend Developer)
├── Flutter UI 实现
├── 页面开发
├── 交互逻辑
└── 前端集成

后端开发 (Backend Developer)
├── API 设计
├── 数据库设计
├── 业务逻辑
└── 数据存储

QA 测试 (QA Tester)
├── 功能测试
├── 性能测试
├── 安全测试
└── 缺陷跟踪

敏捷开发流程(Scrum)

Sprint 周期:2 周

Day 1: Sprint Planning
├── 产品负责人介绍功能
├── 团队估算工时
├── 制定 Sprint 目标
└── 分配任务

Days 2-9: Daily Standup
├── 每天上午 10:00
├── 每人 2-3 分钟
├── 讨论:我昨天做了什么
│        我今天要做什么
│        遇到了什么问题

Day 10: Sprint Review + Retrospective
├── Sprint Review(展示完成的工作)
├── Sprint Retrospective(总结经验教训)
└── 计划下一个 Sprint

任务分解(Work Breakdown Structure)

功能:用户登录模块

├── 需求分析(3小时)
│   ├── 分析需求文档
│   ├── 设计用户流程
│   └── 确定技术方案
│
├── UI 设计(4小时)
│   ├── 设计登录界面
│   ├── 设计错误提示
│   └── 制作交互原型
│
├── 后端开发(8小时)
│   ├── 设计 API 接口
│   ├── 实现认证逻辑
│   ├── 实现令牌管理
│   └── 编写文档
│
├── 前端开发(6小时)
│   ├── 实现登录页面
│   ├── 实现表单验证
│   ├── 集成 API
│   └── 错误处理
│
├── 测试(4小时)
│   ├── 功能测试
│   ├── 安全性测试
│   └── 性能测试
│
└── 上线部署(2小时)
    ├── 代码审查
    ├── 上线前检查
    └── 灰度发布

四、沟通与协作工具

项目管理工具

协作工具使用示例(GitHub Projects)

1. 创建 Project
2. 配置列:Todo | In Progress | In Review | Done
3. 添加卡片(Issue 或手动)
4. 自动化工作流
   - PR 打开时移至 "In Review"
   - PR 合并时移至 "Done"
5. 查看进度和统计

沟通最佳实践

同步沟通(需要即时反馈)
├── Daily Standup 会议
├── 代码审查讨论
├── 问题解决讨论
└── 需求澄清会议

异步沟通(可延迟)
├── Issue 讨论
├── PR 评论
├── 文档更新
├── 邮件沟通
└── Slack 消息

沟通原则
├── 及时更新进度
├── 主动报告风险
├── 提出问题时给出方案
├── 尊重他人观点
└── 文字记录重要决定

五、版本管理与发布

版本号命名(Semantic Versioning)

版本号格式:Major.Minor.Patch(如 1.2.3)

Major:重大版本
- 功能重构
- 不向后兼容的变更
- 如 1.0.0 → 2.0.0

Minor:次版本
- 新增功能
- 向后兼容
- 如 1.0.0 → 1.1.0

Patch:补丁版本
- Bug 修复
- 优化改进
- 如 1.0.0 → 1.0.1

发布检查清单

代码质量
☐ 所有 CI 测试通过
☐ 代码审查完成
☐ 没有重大警告
☐ 代码覆盖率 > 80%

功能完整性
☐ 所有计划功能已实现
☐ 非功能需求已满足
☐ 已完成集成测试
☐ 已测试各种网络情况

文档和发布说明
☐ 更新了 CHANGELOG
☐ 更新了版本号
☐ 编写了发布说明
☐ 更新了 README(如需要)

部署准备
☐ 已备份生产数据
☐ 已准备回滚方案
☐ 已通知相关方
☐ 已安排发布后监控

CHANGELOG 示例

# Changelog

All notable changes to this project will be documented in this file.

The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).

## [1.2.0] - 2024-01-15

### Added
- 支持暗色主题
- 添加了用户设置页面
- 新增了离线模式

### Changed
- 优化了列表加载性能
- 改进了搜索功能
- 更新了 UI 设计

### Fixed
- 修复了登出后的状态混乱问题
- 修复了图片加载失败的问题
- 修复了深链接导航的问题

### Deprecated
- 废弃了旧的 API 端点 v1,将在 v2.0.0 移除

### Removed
- 移除了过时的权限请求

### Security
- 更新了依赖安全补丁

## [1.1.0] - 2024-01-01

### Added
- 支持多语言(英文、中文)
- 添加了应用内帮助文档

### Fixed
- 修复了 Android 10+ 的权限问题

六、常见问题和解决方案

开发中的常见问题

问题 原因 解决方案
进度延迟 需求不清 提前澄清需求,进行充分的技术调研
技术风险 技术选型不当 提前进行 POC,制定备选方案
集成困难 接口不匹配 提前定义接口规范,并行开发测试
性能问题 架构不合理 进行性能测试,及早优化
质量问题 测试不足 编写足够的单元测试和集成测试
沟通问题 信息不对称 增加同步沟通,定期评审
人员变动 知识分散 编写详细文档,进行知识转移

防范策略

风险评估(Risk Assessment)
├── 识别潜在风险
├── 评估风险概率和影响
├── 排序风险优先级
└── 制定缓解措施

定期监控
├── Sprint 回顾会
├── 风险追踪
├── 进度评审
└── 质量监控

团队建设
├── 技能培训
├── 知识共享
├── 建立代码评审制度
└── 鼓励主动沟通

实操(2小时)

实操任务

  1. 产品需求分析
    • 选择一个简单的应用(如天气、日记、购物等)
    • 编写产品需求文档
    • 列出核心功能和非功能需求
    • 创建用户故事卡
  2. 设计原型
    • 使用 Figma 创建低保真原型
    • 设计主要页面流程
    • 标注尺寸和交互说明
    • 邀请团队成员审查
  3. 团队分工规划
    • 列出所有任务
    • 分解任务为子任务
    • 评估每个任务的工时
    • 分配给团队成员
    • 创建 GitHub Projects 管理
  4. 制定开发计划
    • 规划 Sprint(如 2 周为一个周期)
    • 选择迭代 1 的功能
    • 创建详细的技术任务
    • 制定验收标准
  5. 团队协作演练
    • 分组(3-5 人一组)
    • 每组选择一个功能模块
    • 进行 Sprint Planning
    • 模拟 Daily Standup
    • 进行代码审查
    • 完成 Sprint 回顾
  6. 综合案例:社交应用原型
    产品:社交分享应用
       
    主要功能:
    - 用户认证(注册、登录)
    - 发布帖子(文字、图片)
    - 浏览动态(时间线)
    - 点赞和评论
    - 用户关注
    - 消息通知
       
    分工:
    - PM:需求分析、原型设计
    - 设计师:UI 设计
    - 前端开发:UI 实现、页面逻辑
    - 后端开发:API 设计、数据库
    - QA:测试计划、缺陷管理
       
    交付物:
    - 需求文档
    - 设计稿
    - 原型交互
    - 代码实现
    - 测试报告
    - 部署说明
    

📝 课后作业

必做作业

  1. 撰写完整的产品需求文档
    • 包含用户故事
    • 包含功能需求清单
    • 包含用户流程图
    • 包含成功指标
  2. 设计应用原型
    • 使用 Figma 设计 5+ 个页面
    • 包含交互说明
    • 注明设计规范(颜色、字体、间距)
  3. 制定项目计划
    • 创建 GitHub Projects
    • 分解任务并估算工时
    • 分配团队成员
    • 制定 2 周 Sprint 计划
  4. 小组协作实践
    • 分组完成一个功能模块
    • 进行 Daily Standup 会议
    • 进行代码审查
    • 撰写 Sprint 总结报告

选做作业

  1. 进行用户调研和需求验证
  2. 创建产品路线图(Roadmap)
  3. 设计详细的视觉设计系统

📚 学习资源

产品设计

原型工具

项目管理

敏捷开发


✅ 学习检查清单

知识点检查

实战能力检查

协作质量检查


🔍 常见问题解答

Q1:如何处理需求变更?

使用变更请求流程,评估影响,调整计划,获得批准后才能实施。

Q2:团队遇到进度延迟怎么办?

立即识别原因,制定应对措施,与相关方沟通,必要时调整计划。

Q3:如何进行有效的代码审查?

关注代码质量、设计合理性、是否符合规范,提出建设性意见。

Q4:新成员如何快速融入团队?

提供详细的入职文档、进行知识转移、分配清晰的初始任务。


预计完成时间:4小时课内 + 8小时课外
难度等级:⭐⭐⭐⭐
重要程度:⭐⭐⭐⭐⭐