敏捷方法

图难于其易，为大于其细；

天下难事，必作于易；

天下大事，必作于细。

是以圣人终不为大，故能成其大

老子

不积跬步，无以至千里；

不积小流，无以成江海。

骐骥一跃，不能十步；

驽马十驾，功在不舍

荀子

敏捷是一种方法, 代表一种精神, 让事情变得简单高效, 就象 XP 创始人 Kent Back 所说的快速地拥抱变化.

所以敏捷的精神在于快速的应对变化, 告别冗长的流程, 专注于提供对于用户有价值的软件.

敏捷宣言

我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：

个体和互动 高于 流程和工具 
工作的软件 高于 详尽的文档 
客户合作 高于 合同谈判 
响应变化 高于 遵循计划

也就是说，尽管右项有其价值，我们更重视左项的价值

敏捷原则

通过快速交付有用的软件来满足客户需求
欢迎不断变化的需求，即使是在开发后期
工作软件频繁交付（几周而不是几个月）
业务人员和开发人员之间密切的日常合作
项目是围绕有积极性的个人建立的，这些人应该值得信任
面对面交谈是最好的沟通方式（同地办公）
可以工作的软件是衡量进度的主要标准
可持续发展，能够保持恒定的步伐
持续关注卓越技术和良好设计
简单性 — 最大化未完成工作量的艺术非常重要
自组织团队
定期适应不断变化的情况

精益思想

确保团队采用的流程要有助于构建对客户有价值的产品

MMF 最小市场特性
MVP 最小可行产品

消除浪费
增强学习
推迟决定
尽快交付
授权团队

Scrum

以相对固定的几周一个迭代周期(Sprint), 以跨职能,自组织的 Scrum team 持续交付对用户有价值的软件. 它比较强调节奏感, 仪式感, 可操作性强, 在多数互联网公司中广泛应用 Scrum 是一个轻量的框架，它通过提供针对复杂问题的自适应解决方案来帮助人们、团队和组织创造价值。简而言之，Scrum 需要 Scrum Master 营造一个环境，从而：

一名 Product Owner 将解决复杂问题所需的工作整理成一份 Product Backlog。
Scrum Team 在一个 Sprint 期间将选择的工作 Sprint Backlog 转化为有价值的 Increment。
Scrum Team 和利益攸关者检查结果并为下一个 Sprint 进行调整。
重复以上步骤

Scrum 的价值观

承诺：致力于达成其目标并且相互支持。
专注：主要关注点是 Sprint 的工作，以便尽可能地向着这些目标获取最好的进展。
开放：对工作和挑战持开放态度。
尊重：相互尊重，彼此是有能力和独立的人，并因此受到与他们一起工作的人的尊重。
勇气：有勇气做正确的事并处理那些棘手的问题

Scrum 的 3-5-3 要点

3 种角色：
1. 产品负责人（Product Owner）
2. Scrum Master
3. Scrum团队
5 种事件:
1. Sprint 冲刺过程
2. Sprint计划会议（Sprint Planning Meeting）
3. 每日站会（Daily Scrum Meeting）
4. Sprint评审会议（Sprint Review Meeting）
5. Sprint回顾会议（Sprint Retrospective Meeting）
3 种工件:
1. 产品Backlog（Product Backlog）
2. SprintBacklog（Sprint backlog）
3. Increment（产品增量）

敏捷实践

1. User Story Writing Guide

1.1 采用 Role-Action-Benefit 格式例如

“As a Role, I want to Action, so that benefit”
作为一个招聘者，我想在各大招聘平台发布新的职位信息，从而让应聘者方便快捷地发现我们的职位并来求职

1.2 User Story 讲究 INVEST 原则

“I” ndependent (of all others) 独立的: 每个用户故事应该代表一组独特且独立的业务价值，这样，如果它单独发布，它将比之前的状态提供增量价值。
“N” egotiable (not a specific contract for features) 可协商的: 虽然最终目标可能被清楚地描述，但实现该目标的方法应该是可协商的——在产品负责人和开发团队、产品负责人和客户或任何其他相关利益相关者之间——以防止对特性或功能的不切实际的要求
“V” aluable (or vertical) 有价值的：任何用户故事的商业价值都应该通过阅读故事而容易被识别，并且每个故事都应该代表特定用户类型的某种价值
“E” stimable (to a good approximation) 可估量的：我们必须有足够的信息来正确确定故事的大小，以便我们可以正确地计划和致力于我们的工作
“S” mall (so as to fit within an iteration) 足够小的，用户故事应该足够小，以便能够在一个 sprint 冲刺内完成
“T” estable (in principle, even if there isn’t a test for it yet) 可测试的: 团队的所有成员都需要一种清晰、准确的方法来验证用户故事是否已完成

1.3 User Story 要清楚地描述此用户故事可被接受为完成的条件 DoD (Definition of Done)

如有设计文档，请提供文档链接, 并通过了相关团队成员的审阅(review and signoff)

如有代码更改：

代码更改要创建相应的 git pull request ，并由团队成员 review 和 approve ，测试无误后合并到主开发分支
代码更改要有相应的测试用例和测试结果 (Unit testing, API testing or manual testing)
代码实现符合详细设计和上述描述要求，没有严重 bug，通过 Acceptance Test Case

User Story Priority

Priority 优先级 (MoSCoW Prioritization Method)

P1 – Must have: What is described in the User Story must be developed compulsorily. 必须有, 紧急并重要的任务 Urgent + Important
P2 – Should have: The User Story should be developed if possible. 应该有，不紧急但重要的任务 Important
P3 – Could have: It could be developed, but it is not essential for users or business teams. 可以有, 紧急但不重要的任务 Urgent
P4 – Won’t have: It won’t be included in the medium term, but it could be useful in a later version. 最好有, 也可以没有，不紧急也不重要的任务

Example

作为一名 RFC 的读者，我想快速将英文写的协议文本翻译成中文，并更新索引，这样我就能以母语快速掌握协议要点

Description

英文的 RFC 的输入可以是 txt 或者 pdf 格式，中文的 RFC 的输出可以是相同的格式
文本的翻译可以调用 Google, Bing 或者 Baidu 的 API, 要求是免费并且快速, 对文本的长度没有过多限制（可翻译至少 100页文本）

DoD (Definition of Done)

代码实现符合详细设计和上述描述要求，没有严重 bug
代码更改要创建相应的 git pull request ，并由团队成员 review 和 approve ，测试无误后提交到开发主分支
代码更改要有相应的测试用例和测试结果 (Unit testing, API testing or manual testing)，证实满足上述 description 的要求

Bug Report Guide

报 Bug 所需要的内容

Defect ID
Defect Title
Defect Description: 实际的结果以及期望的结果
Steps to Reproduce
Environment
Severity and Priority
Evidence
Other Comments

Bug Severity

S1. Block issue S2. Critical issue S3. Major issue S4. Minor issue S5. Trival issue