敏捷开发中story评分_敏捷开发中story - CSDN
  • 谈到敏捷开发, 许多人纠结的第一个问题便是: User Story 如何的划分? 更有不少人, 一遇到在 User Story 上有延迟交付或交付的质量不佳时, 便说是因为 User Story 的拆分不对, 就整天在纠结所谓 User Story 颗粒度...

    谈到敏捷开发, 许多人纠结的第一个问题便是: User Story 如何的划分? 更有不少人, 一遇到在 User Story 上有延迟交付或交付的质量不佳时, 便说是因为 User Story 的拆分不对, 就整天在纠结所谓 User Story 颗粒度大小的问题。

    然而, 事实的真相是如何呢?

    首先, 先从敏捷开发实践的本身说起:

    敏捷开发之所以强调 “敏捷” , 主要是希望藉由 User Story 的划分 , 能帮助开发人员, 有效的管理版本开发上需求的复杂度, 而使开发人员能在最短的时间内 “发现自身的问题”, “发现自身的不足”, “发现因自身的问题、不足与外部的变化所造成的风险” 。

    所以, 敏捷开发的核心基础, 最强调的便是: “User Story 必需要是可测的” 与 “User Story 间的持续集成” 。

    接下来再谈一下, 人的思维、人的一念之间是如何严重的扭曲了敏捷开发?!

    当一个开发人员, 他 (她) 只是在证明自己“没做错事” 时, 而不是在 “发现自身的问题” 时, 那在拆分User Story 上, 便会发生这些场景:

    1.       将 User Story 拆的需 3 周甚至一个月以上才能完成; 这样的思维与作法, 只是在证明自身所负责开发的 User Story 是可被 “测试的” 。但, 却只是被 “测试人员可测试的” ; 也就是说, 有的开发人员希望将 User Story 要拆的 “够大”, 只是要掩饰自身无法做 “有效” 的 “开发者自动化测试” 罢了。

    2.       将 User Story 拆的只需完成单一且极简单的 “功能点”; 这样的思维与作法, 只是在证明自身所负责开发的 User Story 是可被 “如期交付的” ; 也就是说, 有的开发人员希望要将 User Story 拆的 “够小”, 只是要掩饰自身无法理解与掌握 “完整的业务场景” 与 “软件架构” 罢了。

    所以, 我们要纠结的不应该是所谓 User Story 颗粒度大小的问题; 而是应协助开发人员能诚实的发现与面对自身的不足与所面临的问题, 并给予开发人员适当且必要的赋能与协助。因为, 唯有如此, 开发人员的能力提升了, 则开发人员便自然能在 “更短的时间内” “真正有质量 (有品味)” 的完成 “复杂度越高” 的User Story。

    所以, 我们要纠结的不应该是所谓 User Story 颗粒度大小的问题; 我们应该真正专注的是: 如何能使开发人员能在 “更短的时间内” “真正有质量 (有品味)” 的完成 “复杂度高” 的 User Story。

     

     

    展开全文
  • 首先强调一些Scrum的基本概念本文只想为那些不断实验敏捷开发方法、追寻快速交付产品的IT管理者提供全套经过验证的实践经验,供之参考。我首先假设你已经理解了Scrum这种敏捷开发方法的基本概念并认同之,但是仍然,...

    首先强调一些Scrum的基本概念

    本文只想为那些不断实验敏捷开发方法、追寻快速交付产品的IT管理者提供全套经过验证的实践经验,供之参考。我首先假设你已经理解了Scrum这种敏捷开发方法的基本概念并认同之,但是仍然,我还是要强调以下我们对Scrum达成的“共识”:-)

    Scrum开发流程通常以30 天或者更短的一段时间为一个周期,由产品经理(Product Owner) 提供新产品的需求规格开始,开发团队(Dev Team) 与产品经理于每一个阶段开始时挑选该完成的规格部分,开发团队必须尽力于周期时间内交付成果,团队由开发主管(Scrum Master) 召集,每天使用15分钟开会检查每个成员的进度与计划,了解所遭遇的困难并设法排除之。

    Scrum的重要名词

    Backlog - 可以预知的任务集,包括功能性的和非功能性的所有任务。

    Sprint - 一次迭代开发的时间周期,一般最多以30天为一个周期。在这段时间内,开发团队需要完成一个制定的Backlog。

    Product Owner - 这个角色被称为产品经理。他负责定义产品并向开发团队提出需求,最终验收开发团队的工作成果。

    Scrum Master - 负责监督整个Scrum进程、修订计划的一个团队成员。

    Sprint planning meeting - 在启动每个Sprint前召开。一般为一天时间(8小时)。该会议需要制定的任务是:Product Owner和团队成员将Backlog分解成小的功能模块(即任务),决定在即将进行的Sprint里需要完成多少小功能模块,确定好这个Product Backlog的任务优先级。另外,该会议还需详细地讨论如何能够按照需求完成这些小功能模块。

    Daily scrum meeting - 开发团队成员参加,一般为15分钟。每个开发成员需要向Scrum Master汇报三个项目:今天完成了什么? 是否遇到了障碍? 即将要做什么?通过该会议,团队成员可以相互了解项目进度。

    Sprint review meeting - 在每个Sprint结束后,将这个Sprint的工作成果演示给Product Owner和其他相关的人员。一般该会议为4小时。

    Sprint retrospective meeting - 对刚结束的Sprint进行总结。会议的参与人员为团队开发的内部人员。一般该会议为3小时。

    Scrum过程简单介绍

    1 将整个产品的Backlog分解成若干Sprint Backlog,每个Sprint Backlog是按照目前的人力物力条件可以完成的。

    2 召开Sprint planning meeting,划分、确定这个Sprint内需要完成的任务,标注任务的优先级并分配给每个成员。

    3 进入Sprint开发周期,在这个周期内,每天需要召开Daily Scrum meeting。

    4 整个Sprint周期结束,召开Sprint review meeting,将成果演示给Product Owner。

    5 团队成员最后召开Sprint retrospective meeting,总结问题和经验。

    6 周而复始,按照同样的步骤进行下一次Sprint。

    下面开始进入正题——最佳实践指导思想

    Scrum和极限编程(XP)都要求团队在每一次迭代的结尾完成一些可以交付的工作片段。迭代要短、有时间限制。将注意力集中于在短时间内交付可工作的代码,这就意味着Scrum和XP团队没有时间进行理论研究。他们不会花时间用建模工具来画UML图、编写完美的需求文档,也不会为了应对在可预计的未来中所有可能发生的变化而去写代码。实际上,Scrum和XP都关注如何把事情做好。这些团队承认在开发过程中会犯错,但是他们明白:

    要投入实践中,动手去构建产品,这才是找出错误的最好方式;不要只是停留在理论层次上对软件进行分析和设计。

    Scrum不是方法学,它是一个框架。也就是说Scrum不会告诉你到底该做些什么。因此,以下和你分享的Scrum经验,只可以说是供你参考的个案。你不需要完全仿照以下的做法。实际上如果换个不同的场景,也许某些实践方式就应该换了。

    Scrum的强大和令人痛苦之处就在于你不得不根据自己的具体情况来对它进行调整。

    Backlog - Story


    如何描述我们的“故事”(以下的“故事”等同于Backlog),最佳实践证明至少需要包括这样一些字段:

    ID—— 统一标识符,就是个自增长的数字而已。以防重命名故事以后找不到它们。

    Name—— 简短的、描述性的故事名。比如“查看你自己的交易明细”。它必须要含义明确,这样开发人员和产品负责人才能大致明白我们说的是什么东西,跟其他故事区分开。它一般由2到10个字组成。

    Importance—— 重要性。产品负责人评出一个数值,指示这个故事有多重要。例如10或150。分数越高越重要。
    提醒:我一直都想避免“优先级”这个说法,因为一般说来优先级 1 都表示“最高”优先级,但如果后来有其他更重要的东西就麻烦了。它的优先级评级应该是什么呢?优先级0?优先级-1?思考一下吧:-)

    Initial estimate—— 初始估算。团队的初步估算,表示与其他故事相比,完成该故事所需的工作量。
    我认为估算是最具有技术含量和不确定性的部分,当然也是Scrum过程中需要持续不断改进的部分
    最小的单位是故事点(Story Point),一般大致相当于一个“理想的人天(man-day)”。

    什么是“理想的人天”? 问一下你的团队:“如果可以投入最适合的人员来完成这个故事(人数要适中,通常为2个),把这些人锁到一个屋子里,有很多食物:-P 在完全没有打扰的情况下工作,那么需要几天,才能给出一个经过测试验证的、可以交付的完整实现呢?”如果答案是“把3个人关在一起,大约需要4天时间”,那么初始估算的结果就是12个故事点。
    一些小经验: 不需要保证这个估值绝对无误(比如两个故事点的故事就应该花两天时间),而是要保证相对的正确性(即,两个点的故事所花费的时间应该是四个点的故事所需的一半);区别于“人月神话”中的“人月”,Scrum方法最小的估算粒度一般为“人天”,有时候可以小到“0.5人天”,再小就值得商榷了,我是这样认为的。这足够“敏捷”了。

    How to demo—— 如何做演示成果。它大略描述了这个故事应该如何在Sprint 演示上进行示范,本质就是一个简单的测试规范。“先这样做,然后那样做,就应该得到……的结果”。如果你在使用TDD(测试驱动开发),那么这段描述就可以作为验收测试的伪码表示。

    Notes—— 注解。相关信息、解释说明和对其它资料的引用等等。一般都非常简短。

    利用以上的经验,我们可以设计出一个最为简单有效的Backlog描述模板,如下:
    image

    很多团队曾试过用很多字段描述“故事”,但最后发现,只有上面提到的六个字段会一直使用下去。

    内部质量和外部质量

    我建议尽力把内部质量和外部质量分开。

    • 外部质量是系统用户可以感知的。运行缓慢、让人迷糊的用户界面就属于外部质量低劣。
    • 内部质量一般指用户看不到的要素,它们对系统的可维护性有深远影响。可维护性包括系统设计的一致性、测试覆盖率、代码可读性和重构等等。

    一般来说,系统内部质量优秀,外部质量仍有可能很差。而内部质量差的系统,外部质量肯定也不怎么样。

    松散的沙滩上怎么可能建起精美的楼阁?

    Scrum Master 把外部质量也看作Scrum范围的一部分。有时出于业务考虑,可能会先发布一个系统版本,其中用户界面给人的感觉可能比较简陋,而且反应也很慢;不过随后会发布一个干净的版本。Scrum Master 都是让 Product Owner 做权衡,因为他是负责定义项目范围的人。

    不过内部质量就没什么好说的了。不管什么时候,团队都要保证系统质量,这一点毋庸置疑,也没有折扣可讲。现在如此、将来如此、一直如此,直到永远。

    一个典型的Sprint计划会议时间表

    Sprint 计划会议:13:00 – 17:00 (建议每小时休息10分钟)

    • 13:00 – 13:30 产品负责人对Sprint目标进行总体介绍,概括产品Backlog。定下演示的时间地点。
    • 13:30 – 15:00 团队估算时间,在必要的情况下拆分Backlog条目——把“故事”进一步拆分成“任务”。 产品负责人在必要时修改重要性评分。理清每个条目的含义。所有重要性高的Backlog条目都要填写“如何演示”。
    • 15:00 – 16:00 团队选择要放入Sprint中的故事。计算生产率,用作核查工作安排的基础。
    • 16:00 – 17:00 为每日Scrum会议(简称每日例会)安排固定的时间地点——如果和上次不同的话。

    Sprint应该多长才好?

    时间短就好。公司会因此而变得“敏捷”,有利于随机应变。

    短的Sprint = 短反馈周期 = 更频繁的交付 = 更频繁的客户反馈 = 在错误方向上花的时间更少 = 学习和改进的速度更快

    众多好处接踵而至!

    但是,时间长的Sprint也不错:-) 团队可以有更多时间充分准备、解决发生的问题、继续达成Sprint目标,团队成员也不会被接二连三的Sprint计划会议、演示等等压得不堪重负。

    产品负责人一般会喜欢短一点的Sprint,而开发人员喜欢时间长的Sprint。所以Sprint的长度是妥协后的产物。做过多次实验后,我们最终总结出了最受欢迎的长度:三个星期 (当然,这仍然需要根据你们正在开发的产品的实际情况调整!)。绝大部分团队的Sprint长度都是三周。它不长不短,既让我们拥有足够的敏捷性,又可以让团队进入“流畅”的状态。

    此外还有一个有效的经验:刚开始要根据实际情况试验Sprint的长度。不要浪费太多时间做分析。选一个可以接受的长度先开始再说,等做完一两个Sprint再进行调整。

    为啥要确定Sprint的目标?

    这个目标可以是“挣更多的钱”,或者“完成优先级排在最前面的三个故事”,或“让老板满意”,或“把系统做的足够好,可以作为beta版发布给真正的用户使用”,或“添加基本的后台系统支持”等等。它必须用业务术语表达,而不是技术词汇,因为需要让团队以外的人也能够理解。

    刚开始制定Sprint计划的时候,这个目标也许看上去即愚蠢又不合适,但它在Sprint中常常会被提到,这样,至少大家不会对自己整天忙忙碌碌究竟是为啥而感到困惑。

    如何估算Sprint中该包含哪些Story

    有两个经过实践验证的技术:

    1 本能反应
    2 生产率计算

    有一个很简单的办法:看看团队的历史。看看他们在过去几个Sprint里面的生产率是多少,然后假定在下一个Sprint里面生产率也差不多不变。这项技术也被叫做“昨日天气(yesterday’s weather)”。要想使用该技术,必须满足两个条件:团队已经完成了几个Sprint(这样就可以得到统计数据),会以几乎完全相同的方式(团队长度不变,工作状态等条件不变)来进行下一个Sprint。

    “昨日天气”用起来很方便,但需要考虑一些常识:

    如果上一个Sprint干得很糟,是因为大部分成员都病了一星期,或其它很难碰上的变故。那你差不多可以放心假设这次运气不会那么坏,给这个Sprint设个高点的投入程度;

    如果团队最近刚装了一个执行速度快如闪电的持续集成系统,那你也可以因此提高一下Sprint的投入程度;

    如果有新人加入这个Sprint,就得把他的培训占用的精力也算进来,降低Sprint的投入程度;

    如何定义“完成(done)”

    有一点很重要:产品负责人和团队需要对“完成”有一致的定义。所有代码被 check in 以后,故事就算完成了吗?还是被部署到测试环境中,经过集成测试组的验证以后才算完成?

    我们尽可能使用这样的定义:“随时可以上线 ”,不过有时候我们也可以这样说:“已经部署到测试服务器上,准备进行验收测试”。

    如果你常常对怎样定义完成感到困惑,或者你故事的“完成”定义是不能确定的,那么,你或许应该在每个故事上都添加一个字段,起名为“何谓完成”。

    如何精确的估算

    如果让整个团队进行估算,通常那个对故事理解最透彻的人会第一个发言。不幸的是,这会严重影响其他人的估算。

    有一项很优秀的技术可以避免这一点——它的名字是“计划纸牌 ”。

    image
    每个人都会得到如上图所示的13张卡片。在估算故事的时候,每个人都选出一张卡片来表示他的时间估算(以故事点的方式表示),并把它正面朝下扣在桌上。所有人都完成以后,桌上的纸牌会被同时揭开。这样每个人都会被迫进行自我思考,而不是依赖于其他人估算的结果。
    如果在两个估算之间有着巨大差异,团队就会就此进行讨论,并试图让大家对故事内容达成共识。他们也许会进行任务分解,之后再重新估算。这样的循环会往复进行,直到时间估算趋于一致为止,也就是每个人对这个故事的估算都差不多相同。

    估算需要注意以下几点

    1 试着避免技术故事。 努力找到一种方式,把技术故事变成可以衡量业务价值的普通故事。这样有助于产品负责人做出正确的权衡,因为产品负责人可能对技术知之甚少。

    2 如果无法把技术故事转变成普通故事,那就看看这项工作能不能当作另一个故事中的某个任务。 例如,“重构DAO层”可以作为“编辑用户”中的一个任务,因为这个故事会涉及到DAO层。

    3 如果以上二者都不管用,那就把它定义为一个技术故事,用另外一个单独的列表来存放。 产品负责人能看到它,但是不能编辑它。用“投入程度”和“预估生产率”这两个参数来跟产品负责人协商,从Sprint里拨出一些时间来完成这些技术故事。

    我们该如何管理Backlog

    这个问题看起来有点难搞。

    用Excel来管理产品 Backlog 很不错,不过你仍然需要一个Bug跟踪系统,这时Excel就无奈了。可以用Jira。

    那我们怎么把 Jira 上的 issue 带到 Sprint 计划会议上和我们每日的工作中来呢?我的提议是:
    把 Sprint Backlog 计划,贴到“白板”上!

    以下不多说废话,直接上图——看图说话:

    很明显,这是一张“健康”的燃尽(Burn Down)图,随着时间的推进,以 人/天 为单位的故事点基本上沿着标准线减少,直至“燃尽”……
    image

    一面典型的、简洁的、实用的“白板”。很不幸,它描述了“计划赶不上变化”的场景——临时插入的大量任务阻塞了计划,导致了燃尽图“燃而不尽”。
    image

    一般来说,我们把高优先级的任务放在上面,是为了先做之。这面“白板”很成功的描述了次序颠倒、“捡了芝麻、丢了西瓜”的错误工作顺序。
    image

    燃尽图是个很好的玩意,它可以让我们以最简单的方法发现项目进行中的一些问题。下面的任务似乎太多或太难了,正在逐渐偏离计划。也许需要寻找问题了,也许需要调整一下现行的计划了……
    image

    下面计划定的似乎太宽松了,作为开发人员也许很Happy:-),但如果你是老板或管理者该怎么办?加活吧!让弟兄们的工作来的更加“充实”些吧……
     image   

    最后,呼应一下前面:我们用 人/天 作为所有时间估算的基础(我们也把它叫做故事点)。它的最小值是0.5,也就是说小于0.5的任务要么被移除,要么跟其他任务合并,要么就干脆给它0.5的估算值 。干净利落。

    本文的很多经验来自于 硝烟中的Scrum和XP (原文: http://www.crisp.se/henrik.kniberg ),以及本人的实践总结和经验体会。

    展开全文
  • 敏捷开发敏捷开发宣言敏捷开发路线敏捷开发(Agile development) 敏捷开发是以认为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都将经过验收测试,具备可...
    • 敏捷开发
    • 敏捷开发宣言
    • 敏捷开发路线

    敏捷开发(Agile development)

      敏捷开发是以认为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都将经过验收测试,具备可运行的特征。简而言之,就是把一个大项目分为多个项目联系,但是可独立运行的小项目,并分别完成。在此过程中软件一直处于可使用状态。

    瀑布开发模型是以文档为驱动,在瀑布的整个开发过程中,要写当量的文档,把需求文档写出来之后,开发人员多少个我根据文档进行开发的,一切以文档为依据;而敏捷开发它只需要写必要的文档,注重的是人与人之间,面对面交流。

    敏捷开发宣言

     个体交互                  胜过   过程和工具

      可以工作的软件       胜过  面面俱到的文档

      客户合作                 胜过  客户谈判

      响应变化                 胜过  遵循计划

      虽然右项目也有价值,但我们认为左项具有更到的价值

    敏捷开发线路

        我们公司敏捷开发实践:

        迭代开发(Iteration)

            看可以工作的软件胜过面面俱到的文档。因此,敏捷开发提倡讲一个完整的软件版本划分为多个迭代,

            每个迭代实现不同的特性。重大的、优先级高的、风险高的优先实现。

            在项目的早起就将软件的原型开发出来,并基于这个原型在后续的迭代上进行不断的完善。

       迭代计划会议(IterationPlanningMetting)

            每个迭代启动时,召开迭代计划会议,领取任务,分析任务,评分任务 明确迭代的开发任务

        功能列表(Feature List)

            功能列表中迭代周期为2星期,交付前测试。当一个功能列表完成后,测试组再进行完整的测试。

            每个任务当前的状态贴在4个区域中,分别是:需求整理,开发中,测试中,用户体验。

            在开发人员开始开发一个Story时,ta需要找来对应的测试人员讲解Story功能,以便测试人员有一致的理解,

            同时开始自动化系统测试脚本的开发。

       站会(Standup Metting) 

           每天早上,所有的团队成员围在一起,开一个高效率的会议,通常不超过15分钟,汇报开发进展,以及今天要做内容

      结对编程(Pair Programming)

          结对编程是指两个开发人员结对编码。

          结对编程的好处是:经过两个人讨论后编写的代码比一个人独立完成会更加的完善,

          一些大的方向不至于出现偏差 ,一些细节也可以被充分考虑到。

          一个有经验的开发人员和一个新手结对编程,可以促进新手的成长,保证软件开发的质量

      回顾总结会议( Sprint Retrospective Meeting)
          总结和反思。每个迭代结束以后,项目组成员召开总结会议,总结好的实践和教训,并落实到后续的开发中。

    展开全文
  • 用户故事是敏捷方法的一部分,有助于将重点从撰写需求转移到讨论需求。所有敏捷用户故事都包含一两句话,更重要的是,有关所需功能的一系列对话。 什么是用户故事? 用户故事是从希望新功能的人(通常是系统的用户...

    用户故事是敏捷方法的一部分,有助于将重点从撰写需求转移到讨论需求。所有敏捷用户故事都包含一两句话,更重要的是,有关所需功能的一系列对话。

    什么是用户故事?

    用户故事是从希望新功能的人(通常是系统的用户或客户)的角度讲述的功能的简短描述。它们通常遵循一个简单的模板:

    作为<用户类型 (Type of User) >,我想<某个目标 (Some Objective) >以便<某些原因 (Benefit) >。

    As a < type of user >, I want < some goal > so that < some reason >.

    ç¨æ·æäºçåçæå°çµæ

    用户故事通常写在索引卡片或便利贴上,存放在鞋盒中,并安排在墙壁或桌子上,以便于规划和讨论。因此,他们强烈地将重点从撰写有关功能的内容转移到讨论它们。事实上,这些讨论比任何文字都要重要。

    你能展示一些用户故事的例子吗?

    敏捷用户故事的一个好处是它们可以以不同的细节级别编写。我们可以编写用户故事来涵盖大量功能。这些大型用户故事通常被称为史诗。以下是来自桌面备份产品的史诗敏捷用户故事示例:

    • 作为用户,我可以备份整个硬盘。
    • As a user, I can backup my entire hard drive.

    ç¨æ·æäºçåçæå°çµæ

    由于史诗对于敏捷团队来说通常太大而无法在一次迭代中完成,因此在处理之前会将其拆分为多个较小的用户故事。上面的史诗可以分成几十个(或可能是数百个),包括这两个:

    • 作为高级用户,我可以根据文件大小,创建日期和修改日期指定要备份的文件或文件夹。
    • As a power user, I can specify files or folders to backup based on file size, date created and date modified.
    • 作为用户,我可以指示不备份文件夹,以便我的备份驱动器没有填满我不需要保存的内容。
    • As a user, I can indicate folders not to backup so that my backup drive isn't filled up with things I don't need saved.

    如何将细节添加到用户故事中?

    可以通过两种方式将详细信息添加到用户故事中:

    • 通过将用户故事分成多个较小的用户故事。
    • 通过添加“满意的条件”。

    当一个相对较大的故事被分成多个较小的敏捷用户故事时,很自然地会假设已经添加了细节。毕竟,已经写了更多。

    满意的条件只是一个高级别的验收测试,在敏捷用户故事完成后才会成立。请将以下内容视为另一个敏捷用户故事示例:

    作为营销副总裁,我想在审查过去广告活动的表现时选择一个假日季节,以便我可以识别有利可图的季节。

    通过添加以下满意条件,可以将详细信息添加到该用户故事示例中:

    • 确保它适用于主要的零售假期:圣诞节,复活节,总统日,母亲节,父亲节,劳动节,新年。
    • 支持跨越两个日历年的假期(无跨越三年)。
    • 假日季节可以从一个假期到下一个假期(例如感恩节到圣诞节)。
    • 假日季节可以设定为假期前的几天。

    谁写用户故事?

    product owner user storiesçåçæå°çµæ

    任何人都可以写用户故事。产品所有者 (Product Owner)有责任确保存在敏捷用户故事的产品积压 (Product Backlog),但这并不意味着产品所有者是编写它们的人。在一个好的敏捷项目的过程中,您应该期望每个团队成员编写用户故事示例。

    另外,请注意,撰写用户故事的人远不如参与讨论的人重要。

    什么时候写用户故事?

    用户故事是在整个敏捷项目中编写的。通常在敏捷项目开始时举办故事写作研讨会。团队中的每个人都参与创建产品待办事项的目标,该产品待办事项完整地描述了在项目过程中添加的功能或其中的三到六个月的发布周期。

    其中一些敏捷的用户故事无疑将成为史诗。Epics稍后会被分解成更小的故事,更容易融入到单个迭代中。此外,新故事可以随时由任何人编写并添加到产品待办事项中。

    用户故事是否取代了需求文档?

    敏捷项目,尤其是Scrum项目,使用产品待办事项,这是在产品或服务中开发的功能的优先列表。虽然产品积压项目可以是团队所需的任何内容,但用户故事已成为最佳和最流行的产品积压项目形式。

    虽然产品积压工作可以被视为传统项目需求文档的替代, 但在有关该故事的讨论发生之前, 重要的是要记住, 敏捷用户情景的书面部分 ("作为用户, 我希望......") 是不完整的。

    通常最好将书面部分视为指向实际要求的指针。用户故事可以指向描绘工作流程的图表,显示如何执行计算的电子表格,或产品所有者或团队所需的任何其他工件。

     


    Agile Software Development

    scrum 文章集合

    展开全文
  • RD:开发 FE:前端开发 QA:测试 TTL:tech team leader 产品负责人、研发负责人、测试负责人 规范|角色 PM(含UE) RD(含FE) QA 备注 迭代、项目...

     PM:产品经理

     RD:开发

     FE:前端开发

     QA:测试

    TTL:tech team leader   产品负责人、研发负责人、测试负责人

    规范|角色

    PM(含UE)

    RD(含FE)

    QA

    备注

    迭代、项目开始前

    项目启动一个月前需要PM给出ppt或者word介绍项目方向,规划等,供相关RDQA知道项目目标;

    参与PM的规划会、或认真研读PM产出的规划文档;

     

    迭代启动的前一周,迭代的story已经在PM内部审核通过,并已经告知了相关的RDQA。

    审核通过后再告知RDQA存在两个问题

    • Story拆分不合理;

    • Story与现有架构设计不一致;

    建议:与TTL,QA根据现有架构进行拆分story

    项目,迭代启动前给出建议(非必选)

    需求技术评审之前,PM内部把迭代的内容内部review通过,确保需求在业务上互相不冲突,关联顺序合理。

     

    需要上下游配合的需求, PM找上下游团队PM协调配合好团队的资源;如果没有协调成功,story不进入迭代。

    需求进入RDQA评审前

    Story已经录入需求管理系统,且描述完整。包含背景,内容,意义和验收点,涉及前端的需求最好有UE图,如没有UE图也尽量绘图描述。验收条件由PM给出,QA后续完善。本迭代需求已经确认后,PM需提前准备下一迭代需求,并准备后补开发需求。

    如有技术优化和过程改进的需求,录入需求管理系统,并和PM讨论后,一并进入评审

    迭代启动会,需求评审

     

    是否在评审之前的拆分的时候就已经明确下来分支。如果一次评审没通过反复评审浪费时间与敏捷精神不符;

    对于Story中没有明确描述的细节(如提示信息、弹出浮层效果等),RD+FE可以结合实现需要,提出改进建议,PM调整story卡片内容(1天内完成);

    评审中提出对PM提供Story的异议;遇到不完整,过于简单的story,如果1天内,PM未完成完善,可以拒绝本迭代完成;(标准:描述完整:包含背景,内容,意义和系统表现,涉及前端的需求最好有UE图,如没有UE图也尽量绘图描述。)

    评估和设计时需要考虑0 bug chekclist的内容。

    PM统一接口并负责管理(含其他业务PM,及RDQA发起的需求);

    即使是自发的需求,也需评审,告知PM

    迭代开始后不许插入新story,特别紧急的情况,需要PM说明紧急的原因,(如“不做该Story的影响范围和导致的损失”),然后发起和RDQA一起评估,选择是否将其他story延后来保证紧急需求;

    对合理的紧急需求尽量想办法响应;对于不合理的紧急需求进行果断拒绝

     

    完成开发估点,明确交付测试团队时间

    完成测试估点,明确测试用例交付RD团队时间,明确测试完成时间,明确阶段性提交story时间避免批量提交积压

        估点和排期是两个概念,对于新人同样的点数下, 允许考虑熟练因素有排期差异;每轮迭代的团队速率是本轮迭代所有卡片的估点取和;
        团队的速率是统计本轮迭代的所有Story、Task、Bug的估点总和。
        除了PM提供的需求Story,RD、FE、QA可以根据项目自身的需要,每迭代增加一些调研、性能优化卡片,以解决一些技术负债,防止出现大规模的影响系统稳定性和性能的问题;此类卡片的点数,要算到团队的迭代交付中。

    全团队统一估点基准,不能局限于自身的经验和技术来做出判断;Story的估点,是对Story复杂程度的衡量,不应考虑当前Story的负责RD是否对这个模块很熟悉,或是不熟悉,应该仅从模块分解后的复杂度入手考虑;

    迭代启动会之前对上次迭代估点进行分析。对估点过大或过小的story分析其原因。

    迭代启动会上,估点完毕+验收条件补充完毕,由QA负责将本迭代的所有需求卡片的状态更新(需求池转待开发),迭代第一天完成

    建议一个RD一次只认领一个卡片,对于有多角色共同实现的Story,可以通过Story拆分为task解决。可以考虑前端、后端的联调,与外部系统的联调等影响复杂度的因素,对估点进行适当的调整;

    建立story Owner制度。负责人对拆分的task进度整体负责

     

    对于复杂的Story(点数>8),可以通过Story拆分,将点数尽量控制在8点之内,以避免卡片太大出现跨迭代的现象;

    开发期间(综述)

    重视项目中RDQA发出的报警或问题邮件,参与一起协商解决问题

    遇到不符预期的外部依赖,相关负责人或接口人,应提前发出邮件周知项目组所有成员,以便跟进解决或调整排期。

     

    过程中发现的需求问题,PM及时跟进,并更新Story卡片(一天内)

    尽量在需求评审中发现需求问题,在项目过程中才发现的需求问题,在与PM沟通时,能够根据当前的业务场景,给出自己的建议,有的放矢的进行讨论,而不是简单的抛问题;

     

    遇到和QA看法不一致的bug,和RDQA裁决是否修改需求;

    不得抵触bug,私自要求QA不发bug;遇到和QA看法不一致的bug,由PM裁决是否修改,不得直接否定bug;

    遇到任何可能是问题的都一律发bug,严格按照bug管理规范填写bug的各个字段;对于不知bug具体负责人的情况,需求bug填写PM负责人,代码bug填写RD负责人;

     

    对RD的minishow给出明确的接受或拒绝结论

    RD在交付之前根据QA提供的冒烟case(什么时候提供,包含在验收标准?)进行minishow; show给PM(截屏,或者视频)和QA(现场)

    对RD的minishow给出明确的接受或拒绝结论; 并记录showcase的次数和失败的百分比;

     

    ReviewQA的测试用例并反馈建议

    ReviewQA的测试用例并反馈建议

    产出测试用例供PM、RD review和参考;PMRD可对测试用例的质量作出判断和打分,反馈给RD负责人,RD负责人定期反馈出来;小组负责人可根据结论做相应的奖励和惩罚。

    质量分级测试,对于AB级别的story,提供RD冒烟测试case,供RD自测,RD自测冒烟通过后,QA测试;对于C级别的story,提供测试用例,RD自测,QA不测;D级别的storyRD自测,QA不干涉;所有测试用例都发给RDPM review。分级过程在PM写完验收条件后由PMQARD共同确定参与

    PM小范围补充完善Story,需确保RDQA知晓,并修改Story卡片,不得私自修改内容

    复杂story产出详细设计,供RD架构师评审,评审后更新设计,不得以项目紧急为由省略设计文档;

    评审详细设计,根据详设拟定相应的测试方案;

     

     

    遇到本迭代不能完成的story,不得发布的跨迭代需求,需新建一个跨迭代分支,将本迭代不发布Story的代码统一提交到此分支;

    违反的发S0P0 bug

    见sheet"Bug提交规范"
    需要注意bug的完整性,包含岗位说明,重现步骤,预期结果和实际结果的差异。避免直接写“ xx页面'经常'报错,xx页面无法操作,xx页面偶尔报错等内容。”应该是XX用户,在XX环境下XX方式登录,点击XX,XX,XXX,出现报错页面,报错内容XXX“
    避免重复bug,如一个页面五个字段没做校验报一个bug,说明有5个字段有问题,如果RD修复时候,只修复了3个字段,reopen该bug,说明哪些没有验证通过;
    再如一个基础指标错误,导致十张报表错误,报一个bug说明原因,如实在不好判断,也可发多个bug,
    RD可协商保留一个bug,其他bug标记为duplicated;凡是做了此操作的的,多个bug算作一个,同样,如果修复后,多个bug只要任何一个bug修复不完整,需要reopen无标记dup的bug。

    紧急上线需将上线的代码提交到上一次上线的分支中用以测试、上线;并同步提交到主干,保证主干的一致性。

    对于估点大于等于3点的Story,指定Code Reviewer(包括FE),代码提交时写明是谁review通过(要求必须要review结论);代码嵌套深度超过10的代码reviewer需要打回;

    用SNV钩子控制注释内容,QA抽查注释质量并记录。
    工具Feedboy发现代码嵌套超过10时会发邮件报警,届时相关QA需记录bug,责任人由代码提交人和reviewer共同承担;

    SVN注释规范见sheet “SVN注释规范”

    每完成一个Story,RD需根据Story的验收条件进行自测,并在负责Story中,发表评论:CR: ***,self-test Pass;如果本Story不需要CR,则添加评论:self-test Pass。然后将Story的状态置为“待测试”;

    QA可根据自己的判断,下结论自测充分等级,提供自测评分给QA负责人,QA负责人定期发布结论;小组负责人根据结论可做响应的奖励或惩罚。

    自测完成后提测,同时挪动卡片到待测试;不及时挪卡的可算作提测延期;

    新增代码超过20行时,单测行增量覆盖率不低于50%目前的平均值已经是60%可以70%,即产品代码与单测代码要同步提交;如每迭代,有三次违规,由小组负责人确定惩罚措施,并邮件出来发送小组成员,抄送RD,QA经理。

    QA配置工具,在每次提交代码时通过Jenkins监控,如果未达到要求,发送邮件通知全组;对于三次不达标的情况,要求RD参与手工测试;

    如果连续两次出现未达标情况,项目组迭代回顾会将进行case study,需个人做出解释和说明,并在学习相关的UT&IT知识后,进行组内分享;

    Story测试

    及时响应需要PM介入的项目问题

    对于需要延期修复的bug,或者认为可不修复的bug,需要和PM,QA协商;

    提测后的story如有不完整的情况,发bug;不擅自接受RD延期完善,或者下个迭代完成的解释;

    QA有发现bug不报bug的情况,算违反项目流程,影响KPI,页面上有些展示例如易用性之类的

    bug修复后自测,自测完成后挪卡到待测试;

    对待测试的bug卡及时验收,验收成功的挪到已解决,验收不成功的及时挪回待开发,并记录reopen的次数到相应的字段;

    针对加入的紧急需求,QA在保证原有上线story功能正确的基础上,保证紧急需求的基本功能点的正确性,异常情况和分支不做保证。

    迭代、项目验收期

    在QA的回归测试环境内做迭代story验收

    确定上线的分支,并冻结代码;只能修复回归测试中发现的小问题,避免大面积的代码改动;

    回归测试,对迭代内的story进行最后的验收;同时提供测试环境给PM做验收;

     

    和RD及时沟通验收问题,看是否有必要调整上线的时间;

    对于大的问题做评估,影响上线的问题需及时告知PM

    和RD及时沟通回归发现的问题,如影响到上线需要和PM进行沟通,调整上线的时间;

     

     

    提供上线步骤和上线checklist的签字文件给QA;

    上线步骤进行review,如有问题,打回让RD重新进行修改;检查是否完成了上线checklist。

    上线cheklist海燕负责更新

    PM根据测试报告确定是否正常上线

    review测试报告,了解项目情况

    产出测试报告供PMRD参考

     

    上线、上线后

    线上验证

    线上验证

    QA发出上线验证checklist,保证PM和RD针对功能点进行线上验证(上线当天完成);

     

    项目回顾总结,对于紧急需求变更做casestudy,防止类似事件发生;

    项目回顾总结,提交的Story,出现大于等于2个bug时,项目组迭代总结会进行CR的case study,针对出现问题的Story,集体进行CR,并review相关知识;

    项目总结,提供项目的过程数据;包括bug量,bug率,reopen率;showcase失败率;自测充分率;注释达标;开发效率等数据,迭代内修改代码量和点数的比率等数据;对于不及时发bug,漏发bug的情况作casestudy;

     

    项目总结回顾会:对项目的整体情况开会总结,避免做的差的问题后续继续犯,分享好的经验供后续发扬光大;专业的态度对待回顾会,对事不对人的提出问题和解决方案;

     

    展开全文
  • 敏捷软件开发

    2008-02-29 00:51:00
    敏捷软件开发 作为三篇系列文章的第一篇,我们将带你了解敏捷软件开发的重要做法——如何使用它们、你可能会碰到什么样的问题,以及你将从它们那里获得什么。敏捷软件开发不是一个具体的过程,而是一个涵盖性术语...
  • 敏捷软件开发[下篇]

    2006-06-27 18:17:00
    作者: Builder出自:http://www.zdnet.com.cn/developer/code/story/0,3800066897,39376003,00.htm在敏捷软件开发方法上下系列的最后一篇文章里,我们将探讨开发小组如何与客户交互,如何让其参与到开发过程里来。...
  • Scrum 是以经验过程控制理论为依据,采用迭代、增量的方法来提高产品开发的可预见性并控制风险。Scrum 的三大支柱支撑起每个经验过程控制的实现。 第一大支柱是高透明度 高透明度确保管理结果的人看得到那些影响...
  • 敏捷测试

    2013-07-23 22:33:27
    框架   一绪论 1 背景介绍   近年来,社会信息化程度不断提高,人们在生活和工作方方面面对软件的依赖成都越来越高,尤其是金融行业,各种金融产品和交易方式的革新,软件...在十多年间,敏捷开发方法逐步从概
  •  在****项目一期迭代二中我们的团队算是开始走进了敏捷开发,迭代二结束后就一直想关于敏捷为主题总结一下,刚好本周又听了来自阿里B2B的一名项目经理孔琳琳关于敏捷的一个分享,和我们团队的实践有一些微小...
  • 简介: 自我管理是敏捷开发中的重要管理思想,但是鲜有文献提及相关实践。本文将以笔者的管理实践为基础,探讨自我管理的具体实践。 -->     标记本文!     发布日期: 2011 年 9 月 30 日
  • Java 技术书籍大全

    2019-08-11 20:38:49
    前言 本文档目前已收录 277本 Java相关领域经典技术书籍,从初级开发者到资深架构师,涵盖 Java 从业者的各个阶段。 涵盖领域:Java入门书籍,Java基础及进阶书籍,...《明解Java》 - 豆瓣评分 8.5 《Java从入门到精...
  • Scrum学习笔记

    2012-10-22 16:39:28
    这两天在挤出时间学习了Scrum资料有很大的感悟,说来惭愧使用快半年的Scrum开发方式竟没好好找个资料看看,借这个机会对以前的工作有个总结!  1、sprint backlog只描述用户功能(用户功能以User Story形式展现)...
  • 敏捷开发过程scrum 一、什么是软件工程?请用一句话描述。  软件工程是一门研究性的学科:它用工程化的方法(联系建筑工程……),构建和维护有效的、实用的,和高质量的软件。简单来说,软件工程有三要素:过程+...
1 2 3 4 5 6
收藏数 103
精华内容 41
关键字:

敏捷开发中story评分