zoukankan      html  css  js  c++  java
  • [原]敏捷开发-故事与估算

    ## 创建故事的时机

    1. 由Scrum Master和Product Ower来写故事。敏捷虽然是要提高大家的积极度或参与度,但是故事创建并不需要每个成员都参与,如果都参与写故事会造成故事风格不统一,对整体评估和说明反而不利。


    2. 故事创建要提前。Scrum Master需要提前安排好下次迭代开发的故事,并把需求转化为故事,产品需求文档和故事基本可以同时送到团队开发成员。我们上次开发是,一起过需求,然后给大家需求分析时间,然后列故事,对故事进行评估。这样就造成一点不好,Scrum Master和开发人员同时拿到需求,都需要时间分析,而Scrum Master创建故事的时候,大家是没事干的,这个时间至少需要半天。所以Scrum Master需要提前把下次迭代的故事列到backlog里面,下次迭代直接选取优先级高的故事开发,更有利也更合理。

    ## 如何创建故事

    编写好的故事,关注六大特征 INVEST:独立的 (Independent),可讨论的 (Negotiable),对用户或客户有价值的 (Valuable to Purchasers or Users),可估计的 (Estimatable),小的 (Small),可测试的(Testable)。我们开发中的经验是更注重,小的,独立的,可测试的。
    * 大的故事一定要拆分,别超过5天,否则故事到Done的时间过长,也不利于控制。
    * 独立的,避免故事之间的相互依赖,如果过大,按第一条拆分。
    * 可测试的,表示对用户有价值的一个流程,而不是通过页面来划分,很容易陷入这种模式,一个或几个设计界面组成一个故事,这种看是明确的东西,其实隐藏了需求关联性,也容易在开发中容易造成功能遗漏,比方说页面之间的关联功能。故事描述格式可以写作,作为用户,需要什么功能,以便做什么事情。比方说,作为用户需求登录功能进入后台管理。

    ## 时间预估

    扑克牌,每人根据自己情况得出一个天数
    如果估算不一致,通过最多和最少估算人说出自己的估算方式,避免遗漏,也避免考虑过多
    不需要把故事的需求细节了解的太细,而且不要把细节或实现方式放到估算会上,故事细节由用户和开发人员讨论得出。
    预估是估算,不可能每个故事都特别准确,但最终的整体时间是可参考的

  • 相关阅读:
    【转】shell脚本常用命令
    【转】应该知道的Linux技巧
    背景颜色变成豆沙绿色~
    缓冲区溢出攻击
    恶意代码简介
    atitit.  web组件化原理与设计
    Atitit.vod 视频播放系统 影吧系统的架构图 架构体系 解决方案
    Atitit.跨语言异常转换机制 java c# php到js的异常转换
    atitit.React   优缺点 相比angular react是最靠谱的web ui组件化方案了
    Atiti。流量提升软件设计大纲规划 v1 q45
  • 原文地址:https://www.cnblogs.com/purediy/p/3843229.html
Copyright © 2011-2022 走看看