Agile

点数估算 敏捷开发点数估算 为什么用点数比用小时和天数更好？ 故事点数是通过对比以前开发过的大小相似的用户故事得到的。这种对比相对大小的估算方式，在有大量样本数据的情况下，比独立估算每个用户故事要准确得多。 举个例子，我们可以很容易的说出，从大连到长春的距离是从大连到沈阳的两倍，而不是大连到长春的距离是676.1千米， 大连到沈阳的距离是378.9千米。 (数据来自百度地图) 这样，团队不用花太多的时间来估算每个用户故事所要花费的准确时间和天数，就可以快速完成所有用户故事的估算。 不同的开发团队，是否可以使用统一的故事点数基准？ 不同的开发团队，对于故事点数有不同的度量基准，取决于各个团队所要估计的用户故事。除非他们是在开发相同的系统，否则团队A开发1个点的工作量和团队B在不同系统中开发1个点的工作量是不同的。这种差异将会影响团队的迭代交付速率。 如果有一个很大的项目，需要分成多个小团队来共同开发，人们很可能想去尝试定义一种点数标准应用到所有小团队。这有悖于估算用户故事点数的目的，每个小团队都会有自己的主观衡量标准。 我们如何估算试探性研究(Spike)的用户故事？ 为了弄明白如何实现一个特定的功能，或者验证某种概念，我们需要试探性研究故事 (Spike) 。由于很难知道到底总共需要多少工作量，通常我们要提前在团队中达成共识，对这种研究做出一定时间限制。这些用户故事可是通过观察交付速率趋势图，转换成大致的点数。 例如，如果需要计划一周的时间来完成一个试探性研究，而交付速率是16个点 (迭代周期为两周) ，那么就可以估算这个故事为8个点。 用户点数是否和业务价值有关？ 用户故事点数是对实现用户故事所需要工作量的团队内部度量。无论如何，与用户故事所能提供多少业务价值没有关系。 很可能在同一个系统中，1个点数的用户故事会比4个点的故事有更大的业务价值。业务价值最好是留给产品经理和相关的业务决策者来衡量。 在介绍敏捷估算的方法之前，我们先来回顾一下基于人天的传统估算的思路。传统的工作量估算是估计一个绝对值，单位是人天或者人时。 比如: David喝完一小杯热咖啡花费1.2个小时 (工作量 1.2人时) David喝完一大杯热咖啡花费2.4个小时 (工作量 2.4人时) 由于人的能力是有差异的，所以David的工作量对于Tom来讲可能就不适用，Tom喝完一小杯热咖啡可能需要1.5小时。这样一来，工作量、参与人以及完成这些工作的时间周期就是强相关的，因为强相关会带来如下挑战: 做计划时必须把人和周期关联到具体的任务上，会让计划很复杂。 团队成员的分工发生变化时对计划的影响比较大，管理和维护计划成本高。 (这是甘特图的价值所在 ) 由于第二条的原因，这种工作量的估算方式不利于团队协作。 接下来，我们来看看敏捷估算的思路。 在探讨具体的思路之前，我们先思考一下做估算的目的什么，通常有两个目的: 核算成本和周期，我们要了解这这个项目或产品的投资回报。 做计划，根据项目的需要，我们要知道什么时间点应该交付什么内容才可以满足市场、用户或客户的期望。 做敏捷估算时，请先忘掉人天或人时，敏捷估算关注的是工作量的规模 (大小) ，而不关心谁来做，不关心花多长时间做完。它的规模计量单位使用的是一个抽象的单位——故事点，故事点是一个相对值，是一个相对倍数，和人天，人时没有关系，它和公里、吨、摄氏度类似，只是一个计量单位而已。我们可以定义喝一小杯热咖啡花费的工作量为参考基准，是 1 个故事点。中杯看起来是小杯的2倍大，所以我们可以估算喝一中杯热咖啡花费的工作量是小杯的两倍， 是 2个故事点，大杯是小杯的三倍，所以工作量是3个故事点。 敏捷估算的步骤: 找一个参考基准，作为一个故事点。比如: 把开发一个简单的查询页面工作量作为基准，定义为一个故事点。 拿其它的故事和基准进行比较，估算他们之间的倍数，从而得到其它故事的故事点数。比如: 查看个人基本信息这个故事和开发一个简单的查询页面的规模差不多大，所以它也是1个点，录入个人基本资料的这个故事要复杂一些，大概时3个点。 3 . 累计产品backlog中的所有故事，得到所有故事总的故事点数。 得到了总的故事点规模，我们还要知道团队速度。团队速度是指: 1个敏捷团队在一个迭代中完成的故事点总数。比如: 某Scrum团队1个迭代可以完成 80个故事点，那么80个点就是他们的速度。 有了总的规模，我们也知道了团队一个迭代的速度，我们就可以很容易推算多少个迭代可以做完。 如下图所示，总的规模是1600个点，团队总共8个人，每个迭代完成80个点，我们就可以推算20个迭代完成。 每个迭代2周，所以40周可以完成，8个人40周的成本投入也可以很容易得出。 敏捷估算要点小结: 相对估算，使用故事点作为单位，故事点是一个相对倍数。 估算规模，规模的计量单位是故事点，规模和时间、周期无关，和人天，人时无关。 敏捷估算关注团队的速度，不关注单个人的速度。 通过总规模和团队速度，推算周期 http://www.yugusoft.com/article/%E6%95%8F%E6%8D%B7%E5%BC%80%E5%8F%91%E7%82%B9%E6%95%B0%E4%BC%B0%E7%AE%97.htm?f=blog_page https://cloud.tencent.com/developer/article/1104793

用户故事, user story 故事story是粗略的勾勒的需求，它是信！号！卡！，指向真正的需求或者叫故事详情，怎么说都好。 而需求就是需求。 这里隐含了敏捷的一个要素，就是，延！迟！决！策！ 当需求不是被细化的摆放着，而是粗略的STORY的时候，才能更好的表达延迟决策。首先我们并不在一开始就把所有的东西都想清楚，而是仅仅以STORY的方式跟踪记录我们未来要做的事情。当开发前，我们才去细化STORY故事，把他变成需求。或者，开发前，我们扔掉STORY，因为它已经不重要了。see。故事可以帮我们更好的做延迟决策。保证所有的事情是在开发前才定下来的，而且保证我们不会遗漏。所以这里，就是为什么敏捷要用STORY而不是需求去进行需求的管理。 作者: 马菲菲 链接: https://www.zhihu.com/question/26996772/answer/35078718 来源: 知乎 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。 用户故事 https://www.tapd.cn/forum/view/43571 https://www.cnblogs.com/jetlian/p/3946359.html http://www.scrumcn.com/agile/scrum/4823.html http://www.scrumcn.com/agile/scrum/20026.html https://blog.csdn.net/GitChat/article/details/78410016 用户故事 (User Story) 和验收标准 (Acceptance Criteria) 那么什么是用户故事呢？一个用户故事就是一个功能或者feature的需求 (requirement) ，被写出了也就一两行字，最多5行。一个用户故事通常是最简单的可能性需求，有且只能是一个功能或feature。最常见使用的标准格式的用户故事如下: 作为一个用户/客户角色，我想要达到的目标是什么，以及达到目标的原因e.g:作为社交工具微信的用户，我想要在聊天对话框中有一个拍照图标去自拍和发照片，那么我就可以和朋友一起相互发照片。 什么是验收标准？验收标准就是一系列可以接受的条件或者业务规则，且与功能或feature相互匹配和满足，同时也能被产品负责人和相关人接受。这是用户故事完成很重要的一部分，它需要被产品负责人和业务分析人员认真的学习，因为错失一个很小的标准都会损失惨重。这是简单的编号或者编号列表。格式如下: 在我做某些动作 (action) 之前请赐给一些先决条件，然后期望结果发生。举个栗子: 1. 假设我正在和朋友聊天，我应该能够拍照2. 当我点击照片时，我应该可以在照片上添加一些文字，然后发给朋友3. 如果我的手机照相机有问题，一条错误信息，如"摄像头无法打开"…，相应的也应该出现因此，用户故事为任何功能或feature定义了需求，另一方面，验收标准为用户故事或需求定义了"完成标准的定义"。作为QA，理解用户故事非常重要，同时深刻理解验收标准，并且在测试开始前没有一点的疑惑。 https://www.jianshu.com/p/bde45187a78f

迭代回顾, Sprint Retrospective Scrum - Sprint Retrospective 在Scrum中,每个Sprint结束的时候会有两个会议 (Sprint Review/Demo和Sprint Retrospective回顾) 。 这两个会议是对过去的一个Sprint的一个总结,其中Review/Demo是检查过去一个Sprint的产出 (What) ,主要是PO根据先前的计划来检查Team在过去一个Sprint的工作成果,包括一些Demo,以及未完成部分的总结和分析；而Retrospective则是回顾过去一个Sprint整个Team的运作模式,有什么好的和不好的实践,怎样在未来的Sprint做的更好,强调How。 Sprint Retrospective (回顾) Sprint Retrospective会议主要是整个Team讨论过去的一个Sprint的运作,如何改进使Team更良好的运作。讨论的内容可以是任何有关Team建设的问题,包括工作流程、团队实践、团队内部/外部沟通、团队气氛以及相关工具的使用等等。 Scrum并不是一种方法,而是给软件开发流程提供了一种框架,在整个框架下,不同的项目、团队需要根据具体条件,适时调整实践方法。而Retrospective会议正是一个Scrum团队自我调整的机会。 会议的参加者包括整个Scrum团队、Scrum Master和Product Owner。会议由Scrum Master主持,一般以下边两个问题开始: 过去的一个Sprint里,我们有哪些好的方面？ 过去一个Sprint存在哪些问题？ 整个Team就这两个问题进行公开讨论,方式也可以是多样的。可以大家一起讨论,Scrum Master在讨论过程中将大家的观点记录在白板上；也可以让Team每个成员在便签纸上写下自己的答案,可以要求每个问题至少写三点,然后每个人把自己的答案贴在白板上,并给出相关解释。 讨论完毕后,对讨论结果进行分类。对于好的方便,在下个Sprint继续保持并发扬；对于存在的问题,列出Action Point去解决问题。列出的Action Point也会在下个Sprint的backlog中体现出来,并且是高优先级的项目。 探索者 (E) 代表对这个会议的内容充满期待,很有兴趣听听看看大家都是怎么看待过去这段时间的工作的,想以此来分析我们为什么是这样工作的； 推销者 (S) 是带着想法过来的,他有一个idea想借这个会议推销给大家,比如一个新的工作方式的建议,给团队增加一个流程来改进某一个方面的问题,总之这个人看到了问题,也带来的解决办法； 度假者 (V) 把这个会议当做一个休闲的方式,他们觉得有个机会大家一起聊聊天,胡扯一通挺有意思的,可能比自己工作的时候更让他放松。度假者对会议的内容是没有期待的。 囚犯 (P) 是极不愿意来参加这个会议的,他们要么就是厌恶会议,要么就是忙得没时间参加会议,总之他们是被迫来的,他们期望着会议能马上结束就好,没有心思参与到会议的讨论中来。 http://blog.csdn.net/ljinddlj/article/details/5328404 https://www.jianshu.com/p/95a59fe7844c

‘Scrum,Sprint Review Meeting’

Daily Scrum, stand-up meeting, 站会 日常站立会议 (daily stand-up meeting) 是每天早上举行的短期会议。该活动起源于敏捷开发方法,在Scrum开发中很常见。日常站立会议一般用时五到十五分钟,有时候指代站立的早晨点名或每日例会。 日常站立会议 (daily stand-up meeting) 的目的是让每个团队成员回答以下三个问题: What did I do yesterday? 你昨天做了什么？ What will I work on today? 你今天要做什么？ What is in my way? 你遇到什么困难了吗？ 站立,而不是坐着,强化了该会议打算简短且避免浪费时间的想法。站立会议并不是一个解决问题的地方,而是让一个团队意识到现在的状态。如果需要讨论,适当部门可以安排另一个更长的会议。 在Scrum开发中,站立会议的目的是更新团队的状态,而不是管理,这一点必须得强调。在一些Scrum团队中,管理层会参加会议,但是只有团队成员讲话。https://less.works/less/framework/daily-scrum.html

迭代计划会议 迭代计划会议 重新讨论、确定本次迭代需要实现的Story，达成共同理解； 若有必要的话，则继续细化Story； 对Story进行优先级排序； 开发、测试、资料人员认领任务，估计工作量并做出承诺，这是敏捷的重要实践之一: 开发团队决定承诺完成工作量的多少，而不是由SE或项目PL安排工作量。 共同制定本次迭代的迭代开发计划。要输出针对本次迭代的详细的开发计划，开发、测试、资料是以Story为单位的，所以迭代开发计划也是以Story为核心的。计划中要包括本次迭代要开发的每个Story的开发人员是谁？测试人员是谁？什么时候开始？什么结束？谁来Review？等等。 优秀实践: 明确任务责任人 (包括开发、测试、资料) 和任务完成时间点； 任务和问题都可作为跟踪项进行跟踪； 计划中根据Story优先级和依赖关系，严格按Story驱动制定计划，尽量减少Story并行开发；

Use Story Points, task hours [http://www.scrumalliance.org/articles/439-story-points-versus-task-hours]1 http://www.mountaingoatsoftware.com/blog/why-i-dont-use-story-points-for-sprint-planning

us, 用户故事 as a xxx, i would like to xxx so that xxx. As a “user”, I want to “do sth”, so that “sth” “user” - 就是我们抽象出来的persona (Definition refer to wiki http://en.wikipedia.org/wiki/Persona) “do sth” - 要实现的功能 最后so that后面的 “sth” - 价值 价值说起来很简单，也很容易理解，就是 实现这个story后对用户的价值所在。 可是再多问一个问题，为什么要有这个价值，为什么一定要写这个so that呢？ 如果你的目的是想买一条裙子，20年前，唯一的就是去商场买，但是今天我们还可以选择网上购物。 这也就是说，对于同一个story，不同的技术背景，不同的地域，不同的时代都会有不同的实现，这就是so that存在的价值。

迭代规划 团队会在Sprint开始之初召开Sprint计划会议并制定目标，团队成员会在Scrum每日例会上分享工作进展。当Sprint快结束时，团队会在评审会议中将进展展示给项目干系人。紧接着评审会议之后是回顾会，会上总结当前Sprint中团队的合作情况并为后续Sprint寻找可改进的地方。 计划会 Sprint开始时，团队与项目负责人共同制定下个Sprint的计划，这需要两个会议：Sprint优先级会议和Sprint计划会议。其中优先级会议需要准备产品Backlog、用户故事，并识别潜在的Sprint目标，而计划会议需要构建当前Sprint的Backlog，以确实际开发任务。 优先级会议 Sprint优先级会议的目的是挑出产品Backlog上优先级高的条目，并选择潜在的Sprint目标。我们在产品需求池通过属性来配置任务的优先级。 (图：任务的优先级设置） 在排序之后，PO和团队便可以挑选出高优先级的需求功能作为Sprint的目标。如果高优先级功能实在太多，无法在一个Sprint中完成，这些功能就要分解成更小、更适宜在同一Sprint中完成的小功能，然后放入已创建好的Sprint中。 (图：一个Sprint中的需求功能） 计划会议 在确定当前Sprint的目标需求后，团队从每个需求中分解出任务条目以构成Sprint的Backlog，这是在Sprint计划会议上面进行的，这个会议的参与者包括PO、Scrum Master以及团队中的每个人，和可以帮团队更好预估工作量的各领域专家。 (图：构建一个Sprint Backlog流程） 大家需要在会上讨论每个需求的设计与实现，最好的预估工作量的方法是检查团队过去Sprint中的工作完成情况，比如团队在近期的几个Sprint中完成了平均400小时的工作量，他们就有把握承诺在下个Sprint中完成同样多的工作量。除此之外，一个Sprint是否包括节假日、是否有重要员工离职以及其他影响 (比如是否在开发需要试错的新模块）等等因素也需要考虑进来，最终形成一个可按时交付的Sprint Backlog。 https://ones-ai.gitbooks.io/ones-ai/content/31-si-ge-gai-nian/43-gui-hua-die-dai.html