用户故事颗粒度如何确定

㈠ 如何提高用户故事的任务分解效率

很多敏捷团队将故事点和复杂度点作为同义词来使用，他们相信这比使用“小时”更好，因为这些点数是基于复杂度和相对大小的。Mike Cohn则表示，使用故事点来描述特性的开发复杂度是不对的，应该使用工作量。
Mike提到：
我发现太多的团队认为，故事点应该基于用户故事或特性的复杂度，而不是开发所需的工作量。这些团队通常将“故事点”定义为“复杂度点”，这看起来不错，可能还更精确，但却是错误的。故事点与特性的复杂度无关，而与开发特性所花费的工作量有关。
Mike给出了一个有趣的例子，他比较了舔1000枚邮票和做一个简单的脑外科。Mike认为，抛开复杂度上显而易见的不同，这两件事应该有相同的故事点数，因为它们需要花费相同的时间。
在Scrum Development group上有一个类似的讨论.Adam Sroka提到，为了能够比较稳定的测量velocity，团队需要测量的数据能够接近所耗费的时间。因此，故事应该基于相对工作量，而工作量应与花费的时间有关。
但是，这并不意味着应该以小时为单位进行估算。许多人已经发现以小时为单位的估算是一种浪费，而且也不准确。Mark Levison说到：
估算本身就是浪费。使用小时进行估算则更加浪费，人们花费几个小时去讨论细枝末节，还不如赶快开始工作。虽然使用点数进行估算也是浪费，但为了可以使项目的进度更加易于预测和透明，用户故事应该大致上有相同的大小，再加上一定的差异。对于大多数（成熟或者不成熟的）团队来说，这并不容易，因此他们需要故事点。
Jeff Sutherland也比较了故事点与基于小时的估算。Jeff说：
估算故事点比小时更快速、更好也更经济，高效团队会完全弃用任何以小时为单位的估算，因为他们认为这是一种浪费，只会拖慢他们。
Mark Kilby提出，应该确保那些新接触敏捷的人不会假设故事点＝工作量＝小时。Mark认为，在决定故事点时，虽然工作量很重要，但还需要充分考虑不确定性。Mike则同意点数和小时之间不存在等价关系。
Mike还说，
或许我们可说，点数是工作量、风险和不确定性的函数，SP＝f(E,R,U)。（如果你愿意，也可以把其中一个称为复杂度，但这不重要。）重要的是，点数是关于工作量的估算。风险、不确定性、复杂度、未知因素以及其他相关的事，仅当他们会影响工作量时才应被包含进去。如果某些事确实很复杂，但却不会影响实现特性所花费的时间，那么复杂性就不应该对估算产生影响－这才是故事点。
因此，故事点应该基于工作量，而工作量应该考虑风险、复杂度、未知因素等等。关键是明白故事点要回答的问题。就像Mike说的：
估算的目的是回答如“什么时候才能完成？”或者“到某天为止我们可以得到多少功能？”这样的问题。如果这确实是真的，那么不管用什么单位、什么途径进行估算，都必须是与时间相关的。

㈡ 服务颗粒度的灵活性

所谓灵活性，就是能够容易地因情形做出改变的能力。SOA的目标之一就是让IT变得更灵活，能够更快地适应持续变化的业务环境。因此，灵活性作为设计良好的服务的重要考量，理所当然地也是选择服务粒度的重要标准之一。众所周知，细粒度的服务可以更容易地组装，为交付新的业务功能或改变业务流程提供了更多的灵活性。但是，仅仅考虑灵活性将导致大量的细粒度的服务，带来昂贵的开发成本，并使得维护变得困难。因此，在考虑业务流程灵活性的同时，考虑后台服务的良好组织、效率和开发维护成本，对于识别和设计粒度适中的服务是至关重要的。
我们知道，服务识别方法之一就是top-down的一级级流程分解，直到不能或者不需要进一步分解为止，其中识别出来的的业务活动就是候选的业务服务。因此，一个有效的经验法则就是区别对待不同的业务流程，因为并不是每一个业务流程都需要相同的灵活性。如何确定哪些流程需要更多的灵活性，哪些流程不需要，可以参考SAP就企业业务流程的一个观点。SAP将流程划分为核心流程（core process）和支撑流程(context process)。其中，支撑流程是指那些不可或缺的，但又不影响企业差异化的流程，如财会管理流程等，它们关注的是如何提升生产效率，降低生产成本。因此这些流程在分解过程中，一旦识别出自治的（事务一致、上下文独立的）、粗粒度的服务就可以结束，因为它们相对稳定。而核心流程是指企业独特的，差异化的，代表企业竞争力的业务流程，如营销销售流程等。它们需要比支撑流程更细粒度地分解，以获得最大的灵活性，因为它们是时刻变化的。

㈢ 固体颗粒度是什么

就是固体微小颗粒直径的大小

㈣ 应该如何把握项目计划的颗粒度

可选择的项目战略
面向实施: 工作有太多的不确定性，与其冥思苦想制订计划，不如把计划制订得稍微简单一些，在实施过程中边执行边修改，在实施中加强控制。

㈤ [原创]流程管理经验（1）流程应当写到一个怎样的颗粒度才合适

同样的一个流程说明文件，有的人看了可能会觉得比较粗，不知道怎么操作；有人看了觉得太细，束缚了大家的手脚。按同样的标准、模板梳理流程，有的部门提交上来的写得非常细；有的部门就写得很粗。大家不禁要问：“流程应当写到一个怎样的颗粒度才合适？”，如何使得各部门提交的流程统一？如何使得流程说明文件能够满足大多数人的需求？回答这个问题之前，先介绍一个我过去流程梳理的经历。我们公司物流部门的领导请我辅导他们部门的流程梳理工作，辅导的方式是我来对各部门提交的流程文件初稿进行评审，提出问题点及修改要求。我记得部门提交上来的流程非常的简洁，每个流程活动的描述很简单，基本上与活动名称没有太大差别。由于我不熟悉具体的仓储管理、运输管理业务，首先我问：“这么简洁的流程能够满足员工操作指导的要求吗？”他们回答说，一看就明白，不需要展开了，而且也不知道怎么展开，已经写得不能再细了。接着我又问：“按你们写的流程操作，能够满足质量、风险、成本等控制要求吗？”这时个部门员工沉默了，物流部领导忍不住抢着说：“当然不行！我梳理流程的目的就是要减少由于操作不规范带来的各类问题，就是流程写得不够细致，我需要精细化管理。”知道方向之后，我用5W2H结构引导大家，将物流相关操作程序完成了细化，得到了物流部门的高度认可。同时，我想举一个相反的例子。我的一个朋友在一家企业负责运营管理，他当时制定了公司流程文件管理流程发给我审核把关。文件写得非常详尽，其中文件规范性审核让我印象非常深刻，审核点多达20多项，细致得无以复加。我直接电话问他：“你这份流程文件管理流程关键的风险点是什么？”“对这份厚的流程文件操作质量如何进行管理，要管到哪一个度”。朋友回答，其实也没有什么精力来管理是否得到有效执行，写的细致是出于严密思考及为作业者提供操作指引服务的。我建议他既然没有办法管理复杂的流程操作，还不如简化到可管理的颗粒度。否则写那么多，没有实际意义。说完以上两个例子之后，大家可以看到流程文件描述的颗粒度是因流程而异，因管理目的而异的。简单思考下来，我认为总体来说颗粒度把握有以下几条原则/标准：1 流程重点描写关键的风险控制点，将关键的控制要求、质量要求写清楚即可，必须要做到的。除此这外的细节操作更多地可以通过知识管理来将成功的最佳实践固化，当实践经验上升为规则，变为具备可管理性（价值超过管理付出成本）时，再将其补充到流程文件中；2 流程文件颗粒度要与人员能力相匹配，人员平均能力与素质高，流程会粗一些，反之流程则细一些。3 流程文件颗粒度要与流程可管理性（管理收益大于付出管理成本才具有可管理性）匹配。对于流程成熟度高、流程发生频率高、用户多的流程，颗粒度相对细一些，反之不需要太细。比如上万人使用的流程与10个人使用的流程肯定不一样。4 流程文件的颗粒度要与管理能力匹配，简言之，流程文件内容能够检查得过来吗？能够有精力评估到这个颗粒度级别吗？如果做不到，不如写得少一些，写得简单一些。即ISO说的，写你能做的。我相信当管理或业务经验丰富的人写出非常详细的流程制度被简化的时候一定感觉非常可惜，但不用担心，这些详细的内容都会保留在相关的知识文档，可以用来被参考、借鉴，甚至用来做培训材料，只是换个方式来实现价值。 1 我顶！

㈥ 焊接热输入如何确定

焊接热输入是很关键的，对于焊接来说，一定要关注热输入。
焊接热输入，是指从焊接过程中过渡到母材的能量。

有时候有人叫线能量，但线能量是单位长度的热输入，这样你就知道区别了。

计算公式是：电流*电压/速度

最快捷的方法，您也可以通过焊林院的热输入计算器，只需要输入相应电流，电压和速度，即可得到

焊接热输入影响关系重大，可以影响焊缝的力学性能，金相，颗粒度等，随意一定要选择合适的热输入。

希望可以帮到你

㈦ 如何使用用户故事驱动敏捷开发

首先来说什么是用户故事？

用户故事是从用户的角度来描述用户渴望得到的功能。既不是用来替代传统需求，也不是仅仅记录一下用户的需求的，用户故事是用来讨论和跟踪的。使用用户故事，我们的目的是让用户可以自然的讲述需求，这样才能确保信息的真实性。因为任何软件产品都是为了帮助用户完成某种任务，可以说任何的软件产品或者系统都是通过交互来解决问题的，而交互的双方可能是人和系统，也可能是系统和系统，也可能是模块和模块。这样理解的话，任何的需求其实都是某个个体（人，系统或者模块）在和其他个体进行交互的过程中，我们希望的行为方式。
关键点：角色（人：谁要使用这个功能），活动（过程，需要完成什么样的功能）和目的（为什么要这样的功能，有何商业价值）
简单的举个例子：作为一个“网站管理员”，我想要“统计每天有多少人访问了我的网站”，以便于“我的赞助商了解我的网站会给他们带来什么收益。”需要注意的是用户故事不能够使用技术语言来描述，要使用用户可以理解的业务语言来描述。
用户故事其实就是一个沟通工具，如何编写并不重要，重要的是可以把用户和技术团队联系在一起，让团队里的每个人都知道需要交付的内容。
如何讲用户故事？
第一步：找出故事主角
一般情况下用户是不知道从哪开始讲故事的，不要紧，就按照平时我们跟别人讲故事那样，先从我们的角色讲起，在这个故事中，我们先把角色找出来了，就可以慢慢的丰满
你会发现，当团队开始整理不同的类型的用户的时候，他们已经开始自然的讲述故事，因为要把一个角色说清楚，你就必须考虑他要做的事情，故事自然就出来了。但是在这个阶段，我们切记不要过于发散，明确我们的目的是整理用户画像，只要不同用户类型间的边界清晰了，就可以结束，不要为细节纠缠。另外，在后续的过程中我们也会发现可能有些角色还需要添加进去，那么就到时候说。
第二步：画出故事主线
有了故事主角，我们再来讲故事，在这个阶段主要做的就是帮助团队把故事的每个步骤都想好，通过在看板上进行可视化，我们就可以达到这个目的。这里， 我们可以使用简化版的影响地图，如下图：
标准的影响地图上有4个列，分别是WHY WHO HOW和WHAT，这种结构在进行比较大和模糊的目标讨论的时候，如：战略规划，会很好用，因为HOW和WHAT比较容易区分；
影像地图就是为了可视化，大家可以聚焦在白板前，讨论步骤可以如何细化，如何做的更好。

第三步：使用用户故事地图进行功能分析
之前是做了一个故事的主线，现在用规格化的过程，现一些在故事主线中看不到的技术细节。我们可以使用用户故事地图的方式来进行，团队一起根据故事主线中的每个步骤进行讨论，分析出在产品的特定区域（模块）中的功能点，并使用技术人员容易理解的方式来描述这部分的功能。这整个过程就是从将需求从用户角度的描述转换到技术实现角度描述的过程。

最上面2层是产品的功能区域（模块）
每个模块下面功能点，这些功能点来自于用户故事中的某个步骤的分析
每个功能点的即时贴上标注出用户故事的ID，这样便于我们比对影像地图找到对应的功能点
一些在影响地图中没有明确列出的内容在这张图上被显示出来，比如上图中后台管理和系统功能部分的内容
用户故事的六个特性- INVEST
一个好的用户故事应该遵循INVEST原则。
独立性（Independent）— 要尽可能的让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划，确定优先级，工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。
可协商性（Negotiable）— 一个用户故事的内容要是可以协商的，用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述，不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通。
有价值（Valuable）— 每个故事必须对客户具有价值（无论是用户还是购买方）。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。
可以估算性（Estimable）—开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。但是让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。
短小（Small）— 一个好的故事在工作量上要尽量短小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。
可测试性（Testable）—一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子：软件应该是易于使用的。

㈧ 需求池跟backlog有什么关系

颗粒度的区别。需求池中存放的有可能是大颗粒的需求，也有可能是小颗粒的需求，而backlog是根据用户故事拆解出来的比较小的具体任务，颗粒度会比较小

㈨ 用户故事的概念

用户故事
（user
story）是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素：1.
角色：谁要使用这个功能。2.
活动：需要完成什么样的功能。3.
商业价值：为什么需要这个功能，这个功能带来什么样的价值。用户故事通常按照如下的格式来表达：英文：As
a
,
I
want
to
,
so
that
.中文：作为一个<角色>,
我想要<活动>,
以便于<商业价值>举例：作为一个“网站管理员”，我想要“统计每天有多少人访问了我的网站”，以便于“我的赞助商了解我的网站会给他们带来什么收益。”需要注意的是用户故事不能够使用技术语言来描述，要使用用户可以理解的业务语言来描述。Ron
Jeffries的3个C关于用户故事，Ron
Jeffries用3个C来描述它：卡片（Card）
-
用户故事一般写在小的记事卡片上。卡片上可能会写上故事的简短描述，工作量估算等。交谈（Conversation）-
用户故事背后的细节来源于和客户或者产品负责人的交流沟通。确认（Confirmation）-
通过验收测试确认用户故事被正确完成。

㈩ 如何计算空气颗粒度的浓度和分布度我需要计算的公式或者具体的方法，越多越好

服务颗粒度

什么是服务的颗粒度？一般的说法，服务颗粒度（service granularity）就是指一个服务包含的功能大小。举个例子，对于电信九七系统中的营业受理来说，提交客户订单就是一个典型的粗粒度的服务，而实现这个提交订单服务的一系列内部操作，比如说创建客户资料，生成客户订单，记录产品属性，更新帐务关系等等就可能成为一系列细粒度的服务。细粒度的服务（fine-grained）提供相对较小的功能单元，或交换少量的数据。完成复杂的业务逻辑往往需要编排大量这种细粒度的服务，通过多次的服务请求交互才能实现。相反，粗粒度的服务（coarse-grained）则是在一个抽象的接口中封装了大块的业务/技术能力，减少服务请求交互的次数，但相应也会带来服务实现的复杂性，交互大量的数据，并因此而不能灵活更改以适应需求的变化。就像任何事物都有两面性一样，服务粒度不能太大或者太小，而应该大小合适。一个良好的SOA架构设计，必须在服务粒度设计上维护一种平衡，以获得成本降低，灵活响应的好处。 尽管没有一本Bible让我们可以依此正确地设计服务的粒度，但我们还是能从与之相关的多方面利弊权衡的设计实践中，总结出一些能够帮助正确选择服务颗粒度的经验法则。识别并设计一个粒度适中的服务，我们可以主要从以下三个方面权衡考量。 x 重用性 所谓重用性，就是指服务能够应用于不同上下文的能力。重用可以说是SOA的核心思维，通过重用获得降低开发维护成本，缩短应用交付周期，提升质量等种种好处。 与任何基于分解的范例相一致，颗粒度的大小直接影响到服务的可重用性。一个简单的经验法则就是细粒度的服务更容易被重用。换句话说，就是颗粒度越粗，服务越少被重用或者越难以被重用。因为随着颗粒度增加，越来越多的业务规则和上下文信息被嵌入到业务逻辑中，服务逐渐变得具有特定的业务意义。要使用它，我们必须首先了解它到底封装了哪些规则，否则我们无法确信这个服务正是我们所需要的。这并不意味着我们就不要构建粗粒度的服务，事实上粗粒度的服务往往还停留在”business-grained”层面，它让业务用户和IT人员可以直接对话，对业务有直接的意义，应该暴露出来。同时，如果我们仅仅机械地考虑重用性，将导致大量颗粒度很小的功能单元，这将对系统整体性能和容量带来严重的影响。就拿大家常用来描绘SOA的乐高玩具为喻，一个最小尺寸的1x1的乐高积木，带有一个标准的凸起接口，通过它几乎可以与任何其它乐高积木拼装出任意可以想想的物体，其广泛的重用性是不言而喻的。但是当你真正尝试用这种粒度的积木完成一个复杂物体拼装的时候，你可能会感叹：“Oh, My God! It’s mission impossible!”，因为，为此付出的时间和成本的代价几乎是不可接受的。因此，我们在一心希望构建美好的重用世界之前，需要先掂量清楚服务颗粒度的选择。 在这里，我借用关于演讲的一个有名的“迷你裙定律”来尝试表达服务颗粒度的选择上的权衡之道。“mini-skirt theory”告诉我们，一个出色的演讲应该“short enough to keep people interested, but long enough to cover the important part”。套用在服务颗粒度的选择上，一个设计良好的服务应该“fine-grained enough to be reusable, but coarse-grained enough to make business sense”。 x 灵活性 所谓灵活性，就是能够容易地因情形做出改变的能力。SOA的目标之一就是让IT变得更灵活，能够更快地适应持续变化的业务环境。因此，灵活性作为设计良好的服务的重要考量，理所当然地也是选择服务粒度的重要标准之一。众所周知，细粒度的服务可以更容易地组装，为交付新的业务功能或改变业务流程提供了更多的灵活性。但是，仅仅考虑灵活性将导致大量的细粒度的服务，带来昂贵的开发成本，并使得维护变得困难。因此，在考虑业务流程灵活性的同时，考虑后台服务的良好组织、效率和开发维护成本，对于识别和设计粒度适中的服务是至关重要的。 我们知道，服务识别方法之一就是top-down的一级级流程分解，直到不能或者不需要进一步分解为止，其中识别出来的的业务活动就是候选的业务服务。因此，一个有效的经验法则就是区别对待不同的业务流程，因为并不是每一个业务流程都需要相同的灵活性。如何确定哪些流程需要更多的灵活性，哪些流程不需要，可以参考SAP就企业业务流程的一个观点。SAP将流程划分为核心流程（core process）和支撑流程(context process)。其中，支撑流程是指那些不可或缺的，但又不影响企业差异化的流程，如财会管理流程等，它们关注的是如何提升生产效率，降低生产成本。因此这些流程在分解过程中，一旦识别出自治的（事务一致、上下文独立的）、粗粒度的服务就可以结束，因为它们相对稳定。而核心流程是指企业独特的，差异化的，代表企业竞争力的业务流程，如营销销售流程等。它们需要比支撑流程更细粒度地分解，以获得最大的灵活性，因为它们是时刻变化的。 x 性能 灵活性和效率往往是成对出现的，性能因素自然也是限制服务粒度不能太大或者太小的约束之一。Dan Foody曾在他的weblog里建议Webservice的每一个operation执行应该在5ms到5s之间完成，小于5ms或者 大于5s就意味着服务粒度要么太小，要么太大。我在这里倒不想评价这个量化的指标有多大指导意义，而是借此希望引起大家的思考，并不是服务粒度越小或者越大，系统性能就会一定越好。 一个服务本身的复杂度以及业务到服务映射的复杂度（即实现一个业务活动所需的服务调用次数）是影响SOA性能的两个主要方面。服务颗粒度越大，意味着包含的功能越多，业务逻辑越复杂，网络延迟就会增加，对客户端响应变慢。而服务颗粒度越小，也就意味着包含的功能越简单，虽然单个服务执行效率很高，但从业务意义上，完成一项业务任务所需的服务调用次数越多，来回请求响应次数增加。一般来说，服务都是远程调用的，这种来回请求响应的次数增加意味着显着的性能开销。因此，为了保证服务的性能可控，一方面需要限制服务包含的功能范围和复杂度，也就是说服务粒度不能太粗；另一方面需要限制服务调用的次数和复杂度，也就是说服务粒度不能太细。我想这才是前面提到的5ms和5s背后真正的原因。很显然，二者的着眼点是背离的，为了符合性能的需求，需要在二者之间折中妥协。 除以上几点之外，还存在其它可能影响服务颗粒度决策的因素，比如服务类别和使用范围等等。如果服务使用的范围有限，如仅仅在Intra-Application范畴，则可以选择相对较细粒度的服务接口，为服务请求者提供更多的灵活性；随着范围扩大，服务大小也应随之扩大，如Multi-Enterprise的范畴，则要求服务尽可能提供粗粒度的、较稳定的接口，保证服务请求者以一致的方式使用系统中所暴露出的服务。最后，需要记住的一点是，服务的颗粒度在其生命周期内不是一成不变的，它是随着业务的调整变化，以及服务的迭代发展过程，不断演化精炼、甚至重构的。