基于story的敏捷基础知识
-- Main.yangyang - 2012-04-27
基于story的敏捷基础知识
%TOC%
1 敏捷12条原则
1． 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
尽早地交付具有部分功能的系统和系 统质量之间具有很强的相关性。初期交付的系统中所包含的功能越少，最终交付的系统的质量就越高。以逐渐增加功能的方式经常性地交付系统和最终质量之间有非 常强的相关性。交付得越频繁，最终产品的质量就越高。敏捷实践会尽早地、经常地进行交付。我们努力在项目刚开始的几周内就交付一个具有基本功能的系统。然 后，我们努力坚持每两周就交付一个功能渐增的系统。如果客户认为目前的功能已经足够了，客户可以选择把这些系统加入到产品中。或者，他们可以简单地选择再 检查一遍已有的功能，并指出他们想要做的改变。
2．即使到了开发的后期，也欢迎改变需求。
敏捷过程利用变化来为客户创造竞争优势。这是一个关于态度的声明。 敏捷过程的参与者不惧怕变化。他们认为改变需求是好的事情，因为那些改变意味着团队已经学到了很多如何满足市场需要的知识。敏捷团队会非常努力地保持软件 结构的灵活性，这样当需求变化时，对于系统造成的影响是最小的。 在本书的后面部分，我们会学习一些面向对象设计的原则和模式，这些内容会帮助我们维持这种灵活性。
3．经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。
我们交付可以工作的软件working software ），并且尽早地（项目刚开始很少的几周后）、经常性地（此后每隔很少的几周）交付它。我们不赞成交付大量的文档或者计划。我们认为那些不是真正要交付的东西。我们关注的目标是交付满足客户需要的软件。
4．在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
为了能够以敏捷的方式进行项目的开发，客户、开发人员以及涉众之间就必须要进行有意义的、频繁的交互。软件项目不像发射出去就能自动导航的武器，必须要对软件项目进行持续不断地引导。
5．围绕被激励起来的个人来构建项目。
给他们提供所需要的环境和支持，并且信任他们能够完成工作。在敏捷项目 中，人被认为是项目取得成功的最重要的因素。所有其他的因素??过程、环境、管理等等??都被认为是次要的，并且当它们对于人有负面的影响时，就要对它们 进行改变。例如，如果办公环境对团队的工作造成阻碍，就必须对办公环境进行改变。如果某些过程步骤对团队的工作造成阻碍，就必须对那些过程步骤进行改变。
6．在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
在敏捷项目中，人们之间相互进行交谈。首要的沟通方式就是交谈。也许会编写文档，但是不会企图在文档中包含所有的项目信息。敏捷团队不需要书面的规范、书面的计划或者书面的设计。
团队成员可以去编写文档，如果对于这些文档的需求是迫切并且意义重大的，但是文档不是默认的沟通方式。默认的沟通方式是交谈。
7．工作的软件是首要的进度度量标准。
敏捷项目通过度量当前软件满足客户需求的数量来度量开发进度。它们不是根据所处的开发阶段、已经编写的文档的多少或者已经创建的基础结构（infrastructure）代码的数量来度量开发进度的。只有当30%的必须功能可以工作时，才可以确定进度完成了30%。
8．敏捷过程提倡可持续的开发速度。
责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。敏捷项目 不是50 米短跑；而是马拉松长跑。团队不是以全速启动并试图在项目开发期间维持那个速度；相反，他们以快速但是可持续的速度行进。跑得过快会导致团队精力耗尽、出 现短期行为以致于崩溃。敏捷团队会测量他们自己的速度。他们不允许自己过于疲惫。他们不会借用明天的精力来在今天多完成一点工作。他们工作在一个可以使在 整个项目开发期间保持最高质量标准的速度上。
9．不断地关注优秀的技能和好的设计会增强敏捷能力。
高的产品质量是获取高的开发速度的关键。保持软件尽可能 的简洁、健壮是快速开发软件的途径。因而，所有的敏捷团队成员都致力于只编写他们能够编写的最高质量的代码。他们不会制造混乱然后告诉自己等有更多的时间 时再来清理它们。如果他们在今天制造了混乱，他们会在今天把混乱清理干净。
10． 简单--使未完成的工作最大化的艺术--是根本的。
敏捷团队不会试图去构建那些华而不实的系统，他们总是更愿意采用和目标一致的最简单的方法。他们并不看重对于明天会出现的问题的预测，也不会在今天就对那些问题进行防卫。相反，他们在今天以最高的质量完成最简单的工作，深信如果在明天发生了问题，也会很容易进行处理。
11． 最好的构架、需求和设计出自于自组织的团队。
敏捷团队是自组织的团队。任务不是从外部分配给单个团队成 员，而是分配给整个团队，然后再由团队来确定完成任务的最好方法。敏捷团队的成员共同来解决项目中所有方面的问题。每一个成员都具有项目中所有方面的参与 权力。不存在单一的团队成员对系统构架、需求或者测试负责的情况。整个团队共同承担那些责任，每一个团队成员都能够影响它们。
12．每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
敏捷团队会不断地对团队的组织方式、规则、规范、关系等进行调整。敏捷团队知道团队所处的环境在不断地变化，并且知道为了保持团队的敏捷性，就必须要随环境一起变化。
2 Story
什么是Story?
整个项目:
story:
story 包括三部分：用户故事卡片、详细描述、验收标准。
（1）用户故事卡片
三要素：用户、任务和活动、目标
框架：
| 作为 |
xxx |
| 我想要 | xxxxx |
|---|---|
| 以便 | xxxx |
实例：
| 作为 | 一个书店管理员 |
|---|---|
| 我想要 | 添加新书到书库 |
| 以便 | 购书者能查阅到这本书 |
（2）详细描述
对如何实现“我想要”的详细描述。
（3）验收标准
Q1:如何确定Story已经完成？
通过验证验收标准里的一系列内容，就能验证实现符合story的需求。
Q2:验收条件通常包括哪些？
a.具体属性
b.功能性验收条件
c.非功能性验收条件
story实例：
好的Story有哪些特点？
- Independent 可以独立开发
- Negotiable 可以协商
- Valuable 有价值
- Estimable 大小可评估
- Sized appropriately 合适粒度（1~5天验收完成）
- Testable 可测试验证
Story的生命周期是什么样的？
3 story的两种常见类型的拆分方法：
（1）流程型
上面这种流程型的程序，可以这样来拆分：
如上图，按步骤来划分story
key1：实现前面的步骤时，后面的步骤用一个PM和用户都可接受，且成本很小的简单逻辑来代替，
key2：后面的步骤划分story时，将对之前stroy中实现的逻辑的修改也加进本story中去。
按优先级实现，这样保证每个stroy可单独上线。
（2）多分支型
上面这种多分枝型的程序，可牺牲分支准确程度对story进行划分：
如上图，按主要流程来划分story
key1：实现前面的步骤时，先实现主要分支，不中要的分支用一个PM和用户都可接受，且成本很小的简单逻辑来代替，后面的story再逐步完善。
key2：分支划分story时，将对之前stroy中对已实现的临时分支的去除也加进本story中去。
按优先级实现，这样保证每个stroy可单独上线，每次上线都有东西交付。
4 卡片墙
卡片墙如下图所示：
需求池：所有新建的story（一般为未经过估点的）卡片贴在此处。
待开发：所有待开发的story卡片贴在此处。
需求池->待开发：讲解沟通完需求、估完点、补充完验收标准后，移动。
开发中：所有正在开发的story卡片贴在此处
待开发->开发中：RD将story拆分完task，并给QA讲解task实现思路，QA同意后，移动。
待测试：所有开发完成，等待QA测试的story卡片贴在此处。
开发中->待测试：RD开发完成story，且完成必要的单测编写，和经过仔细的自测后，移动。
测试中：所有QA正在测试的story卡片贴在此处。
QA singn off：所有经过QA测试，QA认为可以上线的story卡片贴在此处。
测试中->QA singn off：QA经过仔细测试，bug都被修复验证，认为story符合上线标准时，移动。
已验证：所有经过PM验收，可上线的story卡片贴在此处。
QA singn off->已验证：PM在验收环境中验收，认为符合需求后，移动。
加速区：所有需要加速解决的story卡片贴在此处。如卡片中有block测试的bug急需修复，等。
block区：所有被一些问题block的story卡片放在此处。
卡片：story卡、task卡（story编号、估点数、用户故事）。
角色卡：FE、RD、QA的名字，以不同颜色区分，分别写上人名，用于贴在story上。谁在做什么，谁忙谁闲，有多少剩余人力，一目了然。
上线时间：略。
5.燃烧图
| 实践名称 |
燃烧图 |
| What |
燃烧图（burn up chart）是在项目完成之前，对需要完成的工作的一种可视化表示。燃烧图有一个Y轴（工作量）和X轴（时间）。理想情况下，该图表是一个向上的折线（完成工作量），和一个水平波动的折线（总工作量）组成，随着剩余工作的完成，”燃烧“折线慢慢接近于水平线（总工作量）。 |
| How |
1、X轴为时间，一般是迭代周期的每一天； 2、Y轴为工作量，根据项目情况，可以用已完成估点或已完成story点数来表示； 3、最开始，计算出本次迭代要完成的所有工作量(作为y轴刻度，迭代天数作为x轴刻度)，然后，每天站立会议时，了解前一天已经完成的工作量，并计算出迄今为止完成的工作总量。把其画在Y轴上，以此类推(并把y点连接成线)。如果计划比较(理想)准确，燃烧图的最后一天”燃烧“折线将和总工作量折线相交； 4、燃烧图可以用excel表格或者借助工具实现。 |
| Why |
1、燃烧图向项目组成员和上级经理提供了工作进展的一个公共视图，它以图形化的方式展现了完成的工作量、总工作量与时间的关系； 2、燃烧图的分析可以揭示很多问题，比如团队的表现如何、如何进一步改进等等；它有助于把握团队的进展情况。 示例： 该团队的计划并不好，因为绿线（已完成点数）和红线（总点数）最总没有相交，这其中的原因可能有很多。他们需要更好的计划。因此，对于该团队来说，计划与自我管理方面亟需改进。 |
| more | 附件为制作好的excel |
|---|---|