# 敏捷实践

## 极限编程实践

极限编程的价值观（《学习敏捷》）：

- **沟通**。每个团队成员都清楚其他人在做什么。
- **简化**。开发 保内尽量让写出的代码简单、直接。
- **反馈**。不断进行测试和反馈，以保证产品的持量。
- **勇气**。每个团队成员都应该专注于为项目作出更佳的选择，即使这意味着不得不抛弃失败的方案而从不同的角度去解决问题。
- **尊重**。每个团队成员对项目都是重要的、有价值的。

对应的实践整理如下：

```process-step
 - 反馈
   - 测试驱动开发
   - 计划游戏
   - 用户代表
   - 结对编程
 - 持续流程
   - 持续集成
   - 代码重构
   - 小的发布
 - 代码理解
   - 简单设计
   - 代码集体所有制
   - 编码标准
   - 系统隐喻
 - 工作环境
   - 每周 40 小时
```

## 结对编程

模式：

- 领航员和驾驶员（Driver-Navigator）。键霸出没，请小心。
- 乒乓模型。基于测试驱动开发的模式
- 鼠标和键盘模式。

注意事项：

1.  多沟通
2.  确定开发任务列表
3.  定期交换小伙伴
4.  可持续的结对工作
5.  多给新人机会
6.  勇敢加勇敢
7.  反馈
8.  不是所有的场景都适合结对

## 持续集成

### 依赖管理

#### 二进制管理 vs 源码依赖管理

|          | 二进制依赖管理                                                       | 源码依赖管理                                                                          |
| -------- | -------------------------------------------------------------------- | ------------------------------------------------------------------------------------- |
| 构建速度 | 直接使用二进制文件，速度快                                           | 所有代码全量构建，速度慢                                                              |
| 重构支持 | 不能同时修改依赖的代码和项目自身的代码，重构困难                     | 可以同时修改项目自身和依赖的代码，重构简单                                            |
| 提交操作 | 不同的代码仓库在不同的工作空间下分别提交代码，管理简单，效率较高     | 在同一个工作空间下管理多个仓库代码，代码修改分别提交到不同的仓库，容易出错 ，效率较低 |
| 开发调度 | 调度时无法跟踪到源码，即使发现依赖的问题，也无法修改                 | 调试时可以看到源码，发布问题时也可以即时修改                                          |
| 响应变化 | 发布需求和问题时，需要寻找依赖提供方的帮助，并放在下一次的开发计划中 | 可以直接修改并马上应用                                                                |

# 需求管理

## 设计思维

来源：《[ ThoughtWorks 唐婉莹——从 1 到 100，设计思维提升产品体验 ](https://myslide.cn/slides/7741))

### 设计思维是什么？

如何进行创新探索的方法论，其中包含了很多创新的方式。

他的宗旨是

- 从用户出发：解决问题的出发点是用户需求，而不是商业或技术先行
- 两种思维结合： 分析性思维和直觉性思维相结合
- 发散与收敛： 善用发散－收敛的方法
- 协作方式：共同认可的团队协作式设计，角色与角色的重叠

```process-card
| 实践 | 设计 | | 思维 |  探索 |
|-|-|-|-|-|
| 场景、需求 | 用户、目标  | | 方案、产品 | 测试、优化 |
| 探寻改进问题 | 定义用户类型 | 定位价值主张  | 发散解决方案 | 原型验证 |
| 探寻关键用户 | 识别场景需求 | | 优先级排序  | 优化方案 |
| 深度用户访谈 | 寻找机会点   | | 原型设计  | |
```
