胡奇 的BLOG
用户名：胡奇
文章数：75
评论数：93
访问量：59193
注册日期：
阅读量：5863
阅读量：12276
阅读量：388216
阅读量：1079329
[匿名]51cto游客：
51CTO推荐博文
首先强调一些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和其他相关的人员。一般该会议为４小时。
Sprint retrospective meeting - 对刚结束的Sprint进行总结。会议的参与人员为团队开发的内部人员。一般该会议为３小时。
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描述模板，如下：
650) this.width=650;" onclick='window.open("/viewpic.php?refimg=" + this.src)'
border="0" alt="" src="/attachment/893296.png" />
很多团队曾试过用很多字段描述“故事”，但最后发现，只有上面提到的六个字段会一直使用下去。
内部质量和外部质量我建议尽力把内部质量和外部质量分开。
外部质量是系统用户可以感知的。运行缓慢、让人迷糊的用户界面就属于外部质量低劣。 内部质量一般指用户看不到的要素，它们对系统的可维护性有深远影响。可维护性包括系统设计的一致性、测试覆盖率、代码可读性和重构等等。 一般来说，系统内部质量优秀，外部质量仍有可能很差。而内部质量差的系统，外部质量肯定也不怎么样。
松散的沙滩上怎么可能建起精美的楼阁？
Scrum Master 把外部质量也看作Scrum范围的一部分。有时出于业务考虑，可能会先发布一个系统版本，其中用户界面给人的感觉可能比较简陋，而且反应也很慢；不过随后会发布一个干净的版本。Scrum Master 都是让 Product Owner 做权衡，因为他是负责定义项目范围的人。
不过内部质量就没什么好说的了。不管什么时候，团队都要保证系统质量，这一点毋庸置疑，也没有折扣可讲。现在如此、将来如此、一直如此，直到永远。
一个典型的Sprint计划会议时间表Sprint 计划会议：13:00 C 17:00 （建议每小时休息10分钟）
13:00 C 13:30 产品负责人对Sprint目标进行总体介绍，概括产品Backlog。定下演示的时间地点。 13:30 C 15:00 团队估算时间，在必要的情况下拆分Backlog条目――把“故事”进一步拆分成“任务”。 产品负责人在必要时修改重要性评分。理清每个条目的含义。所有重要性高的Backlog条目都要填写“如何演示”。 15:00 C 16:00 团队选择要放入Sprint中的故事。计算生产率，用作核查工作安排的基础。 16:00 C 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 以后，故事就算完成了吗？还是被部署到测试环境中，经过集成测试组的验证以后才算完成？
我们尽可能使用这样的定义：“随时可以上线 ”，不过有时候我们也可以这样说：“已经部署到测试服务器上，准备进行验收测试”。
如果你常常对怎样定义完成感到困惑，或者你故事的“完成”定义是不能确定的，那么，你或许应该在每个故事上都添加一个字段，起名为“何谓完成”。
如何精确的估算如果让整个团队进行估算，通常那个对故事理解最透彻的人会第一个发言。不幸的是，这会严重影响其他人的估算。
有一项很优秀的技术可以避免这一点――它的名字是“计划纸牌 ”。
650) this.width=650;" onclick='window.open("/viewpic.php?refimg=" + this.src)'
border="0" alt="" src="/attachment/958531.png" />
每个人都会得到如上图所示的13张卡片。在估算故事的时候，每个人都选出一张卡片来表示他的时间估算（以故事点的方式表示），并把它正面朝下扣在桌上。所有人都完成以后，桌上的纸牌会被同时揭开。这样每个人都会被迫进行自我思考，而不是依赖于其他人估算的结果。 如果在两个估算之间有着巨大差异，团队就会就此进行讨论，并试图让大家对故事内容达成共识。他们也许会进行任务分解，之后再重新估算。这样的循环会往复进行，直到时间估算趋于一致为止，也就是每个人对这个故事的估算都差不多相同。
估算需要注意以下几点1 试着避免技术故事。 努力找到一种方式，把技术故事变成可以衡量业务价值的普通故事。这样有助于产品负责人做出正确的权衡，因为产品负责人可能对技术知之甚少。
2 如果无法把技术故事转变成普通故事，那就看看这项工作能不能当作另一个故事中的某个任务。 例如，“重构DAO层”可以作为“编辑用户”中的一个任务，因为这个故事会涉及到DAO层。
3 如果以上二者都不管用，那就把它定义为一个技术故事，用另外一个单独的列表来存放。 产品负责人能看到它，但是不能编辑它。用“投入程度”和“预估生产率”这两个参数来跟产品负责人协商，从Sprint里拨出一些时间来完成这些技术故事。
我们该如何管理Backlog这个问题看起来有点难搞。
用Excel来管理产品 Backlog 很不错，不过你仍然需要一个Bug跟踪系统，这时Excel就无奈了。可以用Jira。
那我们怎么把 Jira 上的 issue 带到 Sprint 计划会议上和我们每日的工作中来呢？我的提议是： 把 Sprint Backlog 计划，贴到“白板”上！
以下不多说废话，直接上图――看图说话：
很明显，这是一张“健康”的燃尽（Burn Down）图，随着时间的推进，以 人/天 为单位的故事点基本上沿着标准线减少，直至“燃尽”……
650) this.width=650;" onclick='window.open("/viewpic.php?refimg=" + this.src)'
border="0" alt="" src="/attachment/022687.png" />
一面典型的、简洁的、实用的“白板”。很不幸，它描述了“计划赶不上变化”的场景――临时插入的大量任务阻塞了计划，导致了燃尽图“燃而不尽”。
650) this.width=650;" onclick='window.open("/viewpic.php?refimg=" + this.src)'
border="0" alt="" src="/attachment/184218.png" />
一般来说，我们把高优先级的任务放在上面，是为了先做之。这面“白板”很成功的描述了次序颠倒、“捡了芝麻、丢了西瓜”的错误工作顺序。
650) this.width=650;" onclick='window.open("/viewpic.php?refimg=" + this.src)'
border="0" alt="" src="/attachment/087000.png" />
燃尽图是个很好的玩意，它可以让我们以最简单的方法发现项目进行中的一些问题。下面的任务似乎太多或太难了，正在逐渐偏离计划。也许需要寻找问题了，也许需要调整一下现行的计划了……
650) this.width=650;" onclick='window.open("/viewpic.php?refimg=" + this.src)'
border="0" alt="" src="/attachment/690015.png" />
下面计划定的似乎太宽松了，作为开发人员也许很Happy:-)，但如果你是老板或管理者该怎么办？加活吧！让弟兄们的工作来的更加“充实”些吧……
650) this.width=650;" onclick='window.open("/viewpic.php?refimg=" + this.src)'
border="0" alt="" src="/attachment/719359.png" />最后，呼应一下前面：我们用 人/天 作为所有时间估算的基础（我们也把它叫做故事点）。它的最小值是0.5，也就是说小于0.5的任务要么被移除，要么跟其他任务合并，要么就干脆给它0.5的估算值 。干净利落。本文出自 “” 博客，转载请与作者联系！
了这篇文章
类别：┆阅读(0)┆评论(0)
10:27:57 10:31:36 10:33:26 18:04:43 18:11:55scrum中，为什么用story point 来估计难度，而不直接使用“人天”？ - 项目管理 - Tech - ITeye论坛
scrum中，为什么用story point 来估计难度，而不直接使用“人天”？
锁定老帖子
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
来自: 北京
发表时间：&&
相关知识库：
scrum中使用story来做需求分析和开发计划，
story中包括：
1.story的标题和内容
2.story的business value
3.story的estimated point
其中“estimated point”用来估计story的难度，它和开发的“人天”没有固定的联系，对于不同的team， point和“人天”的对应关系是不同的。而每一个iteration的目标是完成多少的points。
我不太明白，既然是估计story的难度，为什么不直接使用“人天”作为单位呢？ iteration的完成的工作也可以用“人天”作为单位啊。
哪位来分析一下。
来自: 上海
发表时间：&&
人天是绝对的，而故事点是相对的，采用相对的估计单位可以采用类比法进行估计。
最本质的区别故事点是规模单位，人天不是。结合故事点和团队工作效率可以得到估计的人天。
请登录后投票
等级: 初级会员
来自: 杭州
发表时间：&&
你没看仔细，他这个story point就是和人天挂钩的。只是每个team不同project的 story point粒度是不一样的。比如一个小项目可能story point粒度是半个人天，大项目可能就是1-2和人天。但是在具体某一个项目中是一致的。Scurm是靠拆分Story Point，才可以更精细的掌控进度，得到Team的效率。
请登录后投票
文章: 1087
积分: 2446
来自: 深圳
发表时间：&&
故事点是指难度还是工作量?!
另外,如果有改善趋势的话,其实开始使用哪种方法都差不多,总会发现到底啥合适的.
请登录后投票
来自: 墨尔本
发表时间：&&
partech 写道故事点是指难度还是工作量?!
另外,如果有改善趋势的话,其实开始使用哪种方法都差不多,总会发现到底啥合适的.
难度跟工作量是挂钩的吧。工作量又不能简单地按照代码行数来算。
请登录后投票
抛出异常的爱
文章: 13675
积分: 2762
来自: 北京
发表时间：&&
故事点与人天的关系是:
如果故事点难度大的话,贡献就大.
如果故事点难度小贡献就小.一天可以作几个.
如果故事点难度大于一人天,就把故事点切成几个故事点.
故事点的数量应该大于人天数.
请登录后投票
yh_private
等级: 初级会员
来自: 长春
发表时间：&&
故事点大概等于一个完美人天。
而这样的完美人天少而又少，需要计算贡献成度来得到TEAM或每个人在当前Iterator可以完成多少故事点。
个人认为这样可以提高估算的准确度。
请登录后投票
等级: 初级会员
来自: 上海
发表时间：&&
因为人天不是你发布给客户的结果的粒度，而和结果无关会导致实际的估计不measurable
liano 写道scrum中使用story来做需求分析和开发计划，
story中包括：
1.story的标题和内容
2.story的business value
3.story的estimated point
其中“estimated point”用来估计story的难度，它和开发的“人天”没有固定的联系，对于不同的team， point和“人天”的对应关系是不同的。而每一个iteration的目标是完成多少的points。
我不太明白，既然是估计story的难度，为什么不直接使用“人天”作为单位呢？ iteration的完成的工作也可以用“人天”作为单位啊。
哪位来分析一下。
请登录后投票
跳转论坛:移动开发技术
Web前端技术
Java企业应用
编程语言技术JIRA项目执行与管理方案_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
JIRA项目执行与管理方案
上传于||暂无简介
阅读已结束，如果下载本文需要使用1下载券
想免费下载本文？
定制HR最喜欢的简历
下载文档到电脑，查找使用更方便
还剩7页未读，继续阅读
定制HR最喜欢的简历
你可能喜欢jira - How to manage story points when there are a number of tasks? - Stack Overflow
to customize your list.
Join the Stack Overflow Community
Stack Overflow is a community of 6.7 million programmers, just like you, helping each other.
J it only takes a minute:
I am trying to get my head around how story points are assigned to sub tasks and how the story points are managed in Jira.
I have a user story which we have estimated at 25 points.
A developer will take this user story and split it up in to a number of tasks.
Should he allocate a number of story points (of the 25) to each task? So in all, all tasks should add up to 25 points? And if the user closes a task of 10 story points, will Jira know that 10 story points have been burned from the main user story of 25 points?
Also, if at the end of the sprint the user story is not complete (say only 20 points have been completed), do I create a new user story of 5 points in the next sprint?
47.5k6102169
5,398954101
Let's pretend Jira isn't the issue for a moment.
First, tasks should be estimated in hours, not points.
Second, stories should only be counted toward the burn down when they're complete. ()
Second, consider what value you are getting from the tasks.
In teams where we have done tasks, I've found the work of creating the tasks a great validator of whether or not the story has been defined well enough.
Marking off the tasks has been of less use to my teams.
Third, when a story is not complete at the end of the sprint, it should go back into the backlog for the product manager to re-prioritize.
It may be that it's no longer a priority (especially if it's taking much longer than expected).
- "All incomplete
Product Backlog Items are re-estimated and put back on the Product Backlog."
Personally, I don't like to re-estimate because then some effort is "lost".
If you don't re-estimate, then your velocity balances out over time, even if each individual sprint velocity bounces up an down.
In some cases, when stories tend to be large, when they are estimated to take more than 4 or 5 days you can easily lose track of progress within a sprint.
This is especially true if the sprint is 2 weeks long.
Teams I've worked with have moved away from tasks in favor of smaller stories.
(Currently, we use a rule that if it's > 13 story points, it's probably too big and should be split up).
All this considered, Jira should fall in line fairly well.
3,67231628
I find sub-tasks to be the hardest feature to use in conjunction with agile in JIRA. It always ends up being one of two scenarios, reminding why I try to never use sub-tasks to begin with:
Each sub-task is actually a story, and the initial story was way too broad.
Every time I'm in this situation, the original story goes over 1 sprint, if not many sprints (causing the developer to rush, shirk, be stressed, etc)
Or, the sub-tasks themselves are too detailed and aren't worth putting in JIRA instead you should just add a comment to describe progress or ruminations to the original issue/story and avoid the JIRA overhead.
EDIT: In response to @DaveHillier
I don't like creating subtasks because it's more JIRA pushups.
I think the allure of subtasks is that it makes your use of JIRA appear more structured,
but I think an important part of using JIRA well is to keep issue count as low as you can, and yet still be effective for the team.
I can't possibly justify this why I think issue count should be low in this thread, other than to say, ' with JIRA, less is more'.
Let me show you what I do that satisfies the following requirements:
transparent progression on the issue (other users can be notified if they want)
lets me organize my own thoughts
remains inline with the issue, letting someone look at my one story and understand quickly where I'm at
I make a list in the description of my main story, using JIRA markup like so:
Build the thing. Lots of words blah blah.
h3. Progress
* deploy it
Then using JIRA markup, I can add little green checkmarks as I get done using (/) next to each bullet point, letting any 'listeners' of the bug stay abreast of my progress.
Build the thing. Lots of words blah blah.
h3. Progress
* (/) code it
* (/) test it
* deploy it
1,90411018
Should he allocate a number of story points (of the 25) to each task? So in all, all tasks should add up to 25 points?
No, tasks of a story are not assigned any points because one completed task will not provide much value to the client / enduser. All the tasks combined will deliver a working piece of code much would be of some value for the enduser.
In essence a story is not complete till all of its tasks are done. Remember: .
if the user closes a task of 10 story points, will Jira know that 10 story points have been burned from the main user story of 25 points?
Since task dont have any points (as mentioned above), this becomes obsolete.
if at the end of the sprint the user story is not complete (say only 20 points have been completed), do I create a new user story of 5 points in the next sprint?
If a story remain incomplete at the end of the sprint then you have two options, either move the whole story back to the product backlog or if any part of the incomplete story can be salvaged and treated as a working piece of software then split the story into two. Working part will be considered complete in the current sprint and non-working part will become part of the product backlog. This part will be treated as a new story and it should be estimated as a separate story. You cannot split story points between the working part and non-working part.
11.8k73958
Sub tasks don't work well in with Jira Agile.
In my current team we don't use them.
I disagree with sethcall, that there are no reasons that I should be using sub tasks.
I'd like to track that I can't easily at the moment:
tasks for completing each point of a definition of done
tasks to make acceptance tests pass
There are plugins that support acceptance testing, (e.g. ) however I have no experience of them.
Some have suggested to
for your definition of done (and acceptance tests), but I'm not keen on that idea as there are too many exceptions to the list.
that suggests using checklists for acceptance tests.
Might be worth a try.
7,27552973
Your Answer
Sign up or
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Post as a guest
By posting your answer, you agree to the
Not the answer you're looking for?
Browse other questions tagged
rev .25058
Stack Overflow works best with JavaScript enabled}