<th id="v9g6b"><track id="v9g6b"></track></th>

  • <em id="v9g6b"><acronym id="v9g6b"></acronym></em>
    <progress id="v9g6b"><pre id="v9g6b"></pre></progress>
    <tbody id="v9g6b"></tbody>
    <button id="v9g6b"><acronym id="v9g6b"></acronym></button>
    <rp id="v9g6b"><ruby id="v9g6b"></ruby></rp>

        <dd id="v9g6b"></dd>

        <em id="v9g6b"></em>

          深入敏捷框架--公司级Story培训指导书(二)

          阅读导航 本文分四个章节,本文接着介绍后两章:
          第一章是Story基础知识,阐述Story是什么,怎么开发,为什么使用Story。
          第二章是Story写作指导,阐述Story的写作步骤,写作标准,写作技巧。
          第三章是实施指导,阐述在基于Story的开发中,怎么制定计划,怎么验收等。
          第四章是FAQ。

          3 实施指导

          3.1 基于Story的计划

          3.1.1 估计方法
          敏捷框架中,建议采用Story点数估计方法。Story点数是一个相对值,不同开发人员完成相同点数需要的时间不一样。估计的时候需要考虑整个Story实施的工作量,而不仅仅是开发工作量。

          3.1.2 迭代周期
          客户组和开发人员共同协商一个合适的迭代周期,一般在两周到四周左右。在整个项目开发全过程中都应该采用相同的迭代周期。确定迭代周期后,开发人员需要估计每个迭代能够完成多少工作,称为迭代开发速度。因为没有办法知道将来还没有发生的情况,刚开始对开发速度的估计一般都是不准确的。但我们可以用最初的估计来描绘一个粗略的草图或者发布计划,包含了每个迭代中有哪些工作以及需要多少个迭代。

          3.1.3 Story优先级
          Stroy优先级
          敏捷框架中首先实现高价值,高风险的需求;然后是高价值,低风险的需求;接下来是低价值,低风险的需求;对于低价值,高风险的需求,放在最后面,甚至不考虑实现。

          3.1.4 版本计划
          在迭代开发之前,需要制定版本计划。版本计划需要明确版本什么时候发布,分几个迭代,迭代周期多长,每个迭代做哪些Story。版本发布时间需要在用户期望的特性和上市时间之间进行权衡。需要根据Story优先级和Story依赖关系决定每个迭代实现哪些Story。版本计划是针对整个版本的计划,比较粗略,不需要很准确。

          3.1.5 迭代计划
          每个迭代开始的时候,需要制定迭代计划。迭代计划需要明确本轮迭代完成哪些Story,投入哪些人,什么时候结束,怎么分工。迭代计划时,如果以前划分的Story比较大,需要进行拆分。如果对Story有新的认识,需要重新估计实施Story需要的点数。迭代计划是针对当前迭代的计划,比较具体明确。

          3.2 澄清和维护

          3.2.1 Story澄清

          Story澄清用于明确需求细节。只要有不明确的,开发人员就应该找业务人员澄清;业务人员有新的想法也应该及时找开发人员沟通。澄清活动贯穿整个Story实施过程,而不仅仅是刚开始做这个Story的时候。我司测试人员代表客户验收Story,属于业务人员的范畴。PO、开发人员、测试人员等一起参与澄清。通过澄清,让每个参与这个Story的人,都明白这个Story需要做什么,做成什么样子,怎么验收。

          3.2.2 需求维护

          一般通过卡片的方式写作Story,卡片正面是Story描述,背面是澄清细节。Story卡片直接贴在状态墙上,非常直观。 有时澄清的需求细节很多,通过卡片很难描述,对于这种情况,可以通过辅助文档的方式记录需求细节。对于白板上的讨论意见,如果有条件,可以拍下来或者打印出来,没有条件就只能手工抄下来。可以通过文档共享或者配置库的方式管理辅助文档,更好的方式是使用工具(WIKI、JRE等),团队中的每个成员都可以非常方便地编辑和查阅。

          3.3  Story验收活动

          Story验收用来验证Story是否开发完成,并按客户期望的方式工作。Story验收包括以下步骤:
          ?记录测试要点,通过澄清明确验收标准;
          ?根据验收标准编写验收用例;
          ?验收用例自动化;
          ?执行验收测试;

          3.4  Story验收原则

          在具体开发之前明确如何测试
          由与客户直接接触人员编写验收用例
          测试是开发过程的一部分
          尽可能地自动化测试
          兼顾其他测试类型

          4 FAQ

          Story与需求规格

          需求规格比较正式,会长期存在,而Story只是过程记录,强调沟通和交流。在瀑布模型开发中,一开始就编写需求规格文档,通过文档传递需求,而在敏捷开发中,强调文档后置,先讨论,等讨论清楚了,甚至测试通过了,再用文档记录下来,以备将来查阅。 需求规格描述的是产品应该做什么,而Story描述的是用户需要什么。需求规格试图把所有的需求细节描述清楚,篇幅很大,而Story描述只是一两句话,起提醒作用。

          Story与基础框架怎么划分

          对于于基础框架,开发工作量很大,没办法细分,怎么办?对于这种情况,可以在迭代开发之前增加一个阶段,负责实现基础框架,称为基础级迭代,也叫迭代0。迭代0的时候,可以由设计师和架构师组成,不需要成立项目组,也不需要按Story的方式划分。如果能拥有一套现场成熟的基础框架那是再最好不过的,Web开发框架包含开发一套软件的所需要的所有基础功能。

          网站&系统开发技术学习交流群:463167176

          本站文章除注明转载外,均为本站原创或翻译,欢迎任何形式的转载,但请务必注明出处,尊重他人劳动,共创和谐网络环境。
          转载请注明:文章转载自:华晨软件-云微开发平台 ? 初识敏捷框架--公司级Story培训指导书(二)
          本文标题:初识敏捷框架--公司级Story培训指导书(二)
          本文地址:http://www.sajuice.com/OrgTec/Agile/0003.html">

          相关文章: 敏捷框架原创系列1 |

          电话
          电话 18718672256

          扫一扫
          二维码
          本港台开奖 <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <文本链> <文本链> <文本链> <文本链> <文本链> <文本链>