软件猿扫地僧

Story Writing%TOC%为什么使用Story？软件行业40年多来，需求分析技术已经很成熟了，但是MRD驱动的过程不堪重负。因为往往MRD编写会占去很多时间，MRD评审又会占去大量时间，编码完成过后提测，压力又全部倾注在QA身上，往往临计划上线时间，或者体验还差，或者bug还太多，或者项目延期。使用story，项目完成时间会大大缩短，上市时间大大缩短。主要原因：A

-- Main.yangyang - 2012-05-07 敏捷开发，QA面临的10个挑战敏捷开发，QA面临的10个挑战1.没有MRD，如何管理好需求？2.没有需求评审，怎么保证需求质量？3.研发模式变更，怎么把握进度？4.没有详细设计如何保证设计没有问题？5.没有测试设计如何保证测试质量？6.何时提测？提测频繁，如何降低提测成本？提测时间不固定，如何分工？

转自ThoughtWorks敏捷软件开发是从1990年代开始逐渐引起广泛关注的一种新型软件开发方法，是能够应对快速变化的需求的一种软件开发能力，它作为一种新型的开发模式，被越来越多地应用到软件项目中。敏捷软件测试指的是在敏捷软件开发过程中跟质量相关的一系列活动，和传统意义上的软件测试有很多区别，因为敏捷软件测试的概念一直比较模糊，所以经常会有人走入误区，我曾经在

基于story的敏捷基础知识----需求管理（二）（1）定期发布定期发布上线，把整个项目划分为一个个迭代，每个迭代时间大小固定（基本固定），迭代结束时上线交付一次。（2）迭代规划迭代规划相当于整个迭代的计划，帮助我们管理并保证每个迭代的交付。A.迭代规划的前提：story沟通及验收条件的补充完成。PM给出story的优先级RD、QA给出story的估点，

基于story的敏捷基础知识----需求管理（三）（3）每日站会站会的目的有三个：（1）周知进度仅从用户故事和任务的层面周知进度，任务进度只有两种状态：完成或未完成（完成百分比）。（2）周知计划你将会在下次会议之前做哪些工作？（3）抛出问题哪些东西阻碍你的进度？（“没有问题”，意味着你能够交付自己当前的任务，而且符合估算的时间范围）如果遇到需要解决的问题，可以在

基于story的敏捷基础知识----需求管理（一）基于story进行需求管理（1）使用story模式来管理需求，将庞大的MRD划分为一个个合适粒度，且可独立交付的story（通常每个story能在1~5天内完成，包括设计、开发、测试），需求清晰明了，易达成一致，且可节省大量的需求评审时间。（2）要求PM在第i个迭代上线前一天，完成所有第i+1迭代的需求拆分，和RD、QA达成理解一致，且

基于story的敏捷基础知识----story编写为什么使用Story？软件行业40年多来，需求分析技术已经很成熟了，但是MRD驱动的过程不堪重负。因为往往MRD编写会占去很多时间，MRD评审又会占去大量时间，编码完成过后提测，压力又全部倾注在QA身上，往往临计划上线时间，或者体验还差，或者bug还太多，或者项目延期。使用story，项目完成时间会大大缩短，上市时间大大缩短。主要原因：

题记本系列笔记将从测试人员的角度，总结在百度两年来的测试经验，记录一个完整的基于敏捷流程的验收测试驱动开发的全过程，分享在测试过程中的一些知识和经验，以及自己的一些理念。总结自己，也希望对大家有益。概念验收测试驱动开发（ATDD）和测试驱动开发（TDD）是完全不同的两个概念。TDD更偏重自动化case先行，而ATDD更偏重于验收细节、质量标准先行。在了解ATDD之前，先

什么是验收测试驱动开发在准备实施一个功能或特性之前，首先团队需要定义出期望的质量标准和验收细则，以明确而且达成共识的验收测试计划（包含一系列测试场景）来驱动开发人员的TDD实践和测试人员的测试脚本开发。   注意：测试人员必须是团队的一部分，并在ATDD的过程中扮演关键和掌控性的角色。   典型的ATDD开发过程是：    Step 1：产品负责人向测试人员和开

【2012年5月18日】 总结一下回顾会议怎么开0.回顾上次会议中的问题top3有没有被解决1.会议的目的是回顾过去的一个迭代，顺便发泄发泄。2.会议内容包括但不限于表扬、批评（如case study）、叙述、吐槽、抱怨、bui等，总之想说啥说啥，大家畅所欲言3.会议主持人讲上述话题记录到亮点、问题 以及疑问三个象限（如果有百事贴，大家写好自己贴上去，再一个个过，这样大家就更没

-- Main.yangyang - 2012-06-01

介绍一下策略story的两种常见类型的拆分方法：（1）流程型上面这种流程型的程序，可以这样来拆分：如上图，按步骤来划分storykey1：实现前面的步骤时，后面的步骤用一个PM和用户都可接受，且成本很小的简单逻辑来代替，key2：后面的步骤划分story时，将对之前stroy中实现的逻辑的修改也加进本story中去。按优先级实现，这样保证每个stroy可单独上线

1．我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。尽早地交付具有部分功能的系统和系统质量之间具有很强的相关性。初期交付的系统中所包含的功能越少，最终交付的系统的质量就越高。以逐渐增加功能的方式经常性地交付系统和最终质量之间有非常强的相关性。交付得越频繁，最终产品的质量就越高。敏捷实践会尽早地、经常地进行交付。我们努力在项目刚开始的几周内就交付一个具有基本功能的系统。然后，我

-- Main.yangyang - 2012-04-27 基于story的敏捷基础知识 %TOC% 1 敏捷12条原则 1． 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。 尽早地交付具有部分功能的系统和系 统质量之间具有很强的相关性。初期交付的系统中所包含的功能越少，最终交付的系统的质量就越高。以逐渐增加功能的方式经常性地交付系统和最终质量之

1）定期发布定期发布上线，把整个项目划分为一个个迭代，每个迭代时间大小固定（基本固定），迭代结束时上线交付一次。（2）迭代规划迭代规划相当于整个迭代的计划，帮助我们管理并保证每个迭代的交付。A.迭代规划的前提：story沟通及验收条件...