敏捷变更或采用总是从为什么开始

Your organization has decided to become more “Agile.” Why? As we learned in a previous blog post, “Because Our Competitors Are” is not a valid – or sensible – reason. Before embarking on a change, adoption, or improvement program, you need to know the rationale behind that decision. So… why Agile? A traditional approach to answering this question might see the executive team going off-site for two to three days and holding a workshop where they decide why they should be Agile, then design an adoption strategy, and then summarize the whole thing in a few sentences to be sent out in a memo. Typically, large-scale change initiatives have a lot more ceremony, more meetings, and more setup than this. However, there are several key failings, including that they involve only a select few executives in the envisioning and decision-making process, and they attempt to plan for the long haul. There are dozens of examples in our industry of failed change efforts that have cost billions of dollars and proved that this approach doesn’t work. At Nokia, Stephen Elop issued the famous ‘burning platform’ memo in 2011, and yet two years later the company was sold to Microsoft. In 2013 Avon had to write off $125 million[1] of work that built an enterprise software implementation which drove representatives away. This was change that failed to help the very people it was intended for. These and other failures involve some combination of the following: Why – The “Why” isn’t understood by most of the victims of change. Strategy – The “Strategy” created by the executive group doesn’t make sense to all of the people doing the work. Ownership – People at the edges of the system (who do most of the work) feel no ownership of the change. Connection – The strategy doesn’t appear connected to the problems that the people at the edges of the system are experiencing. Improvement -The strategy appears to improve the lot of the executives, but not of the doers. Culture – The change doesn’t fit the organization culture. Leadership – Top level is asking for change but doesn’t appear to be involved in making it happen. To be effective, Agile organizational change needs to… well, involve the Organization! Not just the executives who have made the decree, often without fully understanding what the goals of the change are. This shouldn’t be a quick decision made at a two-day corporate retreat. It needs to be an ongoing effort to figure out the “why” collaboratively and share it effectively, being mindful of some essential ingredients. We will address those ingredients in the next several blog posts. Avon’s Failed SAP Implementation A Perfect Example Of The Enterprise IT Revolution – Ben Kepes: http://www.forbes.com/sites/benkepes/2013/12/17/avons-failed-sap-implementation-a-perfect-example-of-enterprise-it-revolution Image attribution: http://photodune.net/

简单

在201x,全球金融市场崩溃了。原因:抵押贷款给了那些不能’负担不起他们。然后,将这些债务重新打包并作为良好债务出售给银行和其他机构。 (“The Big Short”迈克尔·刘易斯(Michael Lewis)撰写的这篇文章非常出色)。但是,更大的问题仍然存在。为什么没有’金融监管体系虽然还很小,但能及早发现问题?答案?复杂。在 “狗与飞盘”(pdf),英格兰银行金融稳定性执行总监安德鲁·霍尔丹(Andrew Haldane)解释了捕捉飞盘狗必须了解和理解的所有事项:风速和方向,飞盘的旋转速度,大气条件和重力。可能需要获得物理学学位才能知道如何表达与捕捉飞盘有关的控制问题。然而,没有物理学位的狗每天都会这样做。他们遵循一个简单的规则/启发式:“以一定速度运行,以使凝视与飞盘的角度保持恒定”。经验主义和朴素。敏捷之所以有效,是因为它是一个经验过程,使用不断的反馈来更新工作本身和我们的工作方式。 Haldane继续表明,金融监管体系已从银行许多人可以理解的简单事物演变成只有少数人可以理解的事物。最终,它变得如此复杂,以至没有人了解整个系统。较早的监管框架之所以运作良好,部分原因在于许多人都了解,因此许多人可以在问题变得过于复杂和庞大而无法解决之前及早发现问题。当我们与规模更大的组织打交道时,’试图说这种复杂性的增加是可以的,因为我们’再大一点。但是,如果金融危机教会了我们什么,答案应该是“否”。系统越大,使用简单的控制机制,简单的反馈回路和所有人都能理解的简单措施就越重要。降低复杂度– not increasing it –必须是我们所有决策的核心。与此相伴的是,必须具有快速响应和适当改变的能力。 图片归因:damedeeso,通过photodune

“因为我们的竞争对手是”无理由成为敏捷组织

公司开始陷入陷阱,这种情况会发生,“我们的合作伙伴/竞争对手/…敏捷,所以我们需要敏捷。”在没有正当理由的情况下成为敏捷将损害您的组织。我可以’ t指出更简单。在里面‘80s and ‘90年代,竞争对手的制造商经常造访丰田的工厂,丰田很高兴欢迎他们,因为丰田知道,即使他们的竞争抄袭了公司的做法,做法也会改变。什么竞争对手’ t复制是首先创建实践的文化,’ s真正的价值所在。因此,我们在许多北美制造商中都配备了Cargo Cult Lean,’ t产生公司希望的结果。我们’再次看到与敏捷。它’ s仅仅因为您的竞争对手就不足以成为敏捷并复制敏捷实践。除非您发展出一种能够创建自己的实践的文化,否则这只会导致敏捷的货运文化,而不是真正的敏捷组织。什么竞争对手’ t复制是首先创建实践的文化,’ s真正的价值所在。那么,成为敏捷的一些有效理由是什么?其中一项主要功能是能够轻松适应不断变化的环境。其他原因包括:弹性;可预测性;降低风险;士气和保留;早期的投资回报率;可预测性;客户满意度和简单性。考虑百视达如何适应在线视频,或者出租车行业对Uber / Lyft的反应。与拥护变革的竞争对手相比,以控制为重点的组织难以迅速适应并生存。当问题明确且解决方案可重复时,传统/等级制组织运作良好,但不幸的是,在这种情况下蓬勃发展的组织在情况变化时脆弱,他们可以’ t适应。传统组织的结构是在创新和变革步伐要慢得多的世界中演变而来的。可以在几年后发现变化,可以做出回应,并且组织会做得很好。这个世界不再存在。如果他们对变化的反应不佳,整个行业将在短短几年内死亡’ t快速而灵活。 Cynefin可以在其中进行对话。 Cynefin Cynefin是一种了解我们发现自己所在的问题领域并确定哪些工具适合进行响应的方法。乍一看脸红有些令人生畏,但请和我一起忍受’会看到它没有’ t必须。它’ s仅仅是一个问题“cause and effect”, and how simple or complicated that plays out within the context of your organization. The Cynefin Framework breaks down into 5 different domains to describe different types of relationships between 因果 –从简单到复杂,再到不存在。首先,很明显。顾名思义,显而易见(以前称为Simple)。所有相关人员都清楚这些上下文。如果为X,则为Y。在过程的任何阶段,很明显下一步是什么。例如银行业务(利息计算),保险(保险费计算)等方面。此领域中的组织从一定程度的结构中获取价值,以确保人们遵守规则。标准做法在这里适用。一个简单的例子?让’ s关于成长的事情。发展你的绿色拇指。在一个明显的系统中,我们有一块海绵。如果在上面加水,它会膨胀并增长。因果关系最简单的形式。海绵+水=更大的海绵。那’s Obvious. The next domain is a little less so. Complicated is where the relationship between 因果 is harder to see. It requires analysis and, often, expertise to find and understand the relationship(s). Once understood, “best practices”可以在这个领域开发。回到日益增长的类比,这是我们’re growing one plant in a pot, which is considerably more complicated than growing a sponge, but there is still logical 因果 involved. Seed + Soil + Water + Sun + Food = Plant. In this world, there are rules of thumb (green or otherwise) and 最佳做法 . It’重要的是要指出,复杂域的风险之一是我们仅听取专家的意见。它’s vital that we also factor in our own observations and environment. The next domain is more Complex and, in these contexts, 因果 relationships are only understood in hindsight. Given the unpredictability of this domain, we’最好进行探测,感知和响应,而不要尝试控制或计划。与其寻找复杂的解决方案,不如寻找简单的规则或启发式方法以帮助在这种环境下正常工作。试图帮助我们的孩子成长是复杂领域的一个例子。我们要求他们做一些事情(探测),他们以一种意想不到的方式做出回应(感觉)。它’ s仅在回顾中,我们才能了解他们为何如此回应。下次,我们适应(我们的响应),根据对新短语/音调的理解,更改其措词/音调。复杂的领域需要许多不同的观点来帮助解决。尽管具有挑战性,但他们’re still much easier to navigate than Chaotic. In Chaotic Domains, there is no relationship between 因果. Emergency/disasters are examples of the Chaotic domain. In these cases, the goal is simply to try and bring them back from Chaos to the world of the merely Complex. We don’ t在商业世界中经常看到此域,因此我们’在此不进行探索。第五个也是最后一个域是 混乱,当它没有时存在’t yet been determined what the 因果 relationship is.  It’ s在这种状态下,人们最容易根据自己的舒适区做出决定。如今,企业通常在复杂域中工作,这意味着传统的,老式的方法已经不再存在。’ t现实。我们可以’如果组织希望在这个新的,快速发展的世界中蓬勃发展,则不能让简单组织的DNA持久存在。因此,我们需要创建可以适应的组织–甚至蓬勃发展–在复杂的世界中,并帮助简单和复杂[…]

Taking组织改善Seriously – Case Study

(作为单独的Scrum系列文章的第4部分的附带案例研究提出。)在上一篇文章中,我们讨论了它是如何进行的。’ s不足以在上海福彩官方网站级别练习Scrum并期望它将解决所有问题。高级管理层必须参与进来,以实现真正的敏捷变革并实现高性能。其中一个重要方面是系统性问题解决,我们’将仔细研究世界’ s最小的在线书店作为案例研究的例子。系统性问题解决我遇到的大多数上海福彩官方网站都非常擅长本地解决特定问题(在上海福彩官方网站级别)。所缺少的是更大的整体看法。系统思考(pdf)是可帮助您掌握系统知识的工具–或更大的图片–整个系统的视图。让’ s以几个常见的组织问题为例– namely “回归周期长” and “Product Owner can’ t似乎始终专注于全局”. 回归周期长 Hereafter: LongRegressionCycle The Org Team recognizes that it has a problem with the regression cycles as illustrated: When long regression cycles are an issue, without a systemic approach the organization might first try adding more people to do regression testing. As a second step, they might try automated testing through the browser/GUI using a special team who has access to an expensive tool. Unfortunately, as we see below, this will likely lead us down the wrong path: This is a simple causal loop diagram –it’ s旨在帮助我们寻找  past the initial problem and see deeper causes. Variables create 因果 within a system. In a causal loop diagram, you start with a single part of the system that you can already identify and just keep asking “什么影响这部分?”然后使用指向影响方向的箭头在互连的零件之间绘制链接。一旦您不再考虑要添加的其他部分或影响,便有了一个闭环。在此示例中,我们可以设想通过循环播放可能发生的情况,从“Features added”并跟随其对“回归周期长度”。继续进行下去,我们可以看到,经常使用的简单解决方案要求一个特殊的上海福彩官方网站通过浏览器/ GUI自动执行回归测试,这会影响许多变量,并最终加剧了要解决的问题。该图清楚地表明,基于GUI的自动化非常脆弱,由一个特殊上海福彩官方网站完成的所有工作正在创造知识的孤岛。这两个问题结合在一起,增加了查找错误的时间,甚至最终增加了错误本身的数量。为了解决潜在的初始问题,我们还必须找到一种方法,’ t重新创建这些相同的问题!而不是由一个专门的上海福彩官方网站来完成所有的测试自动化,而是应该由每个上海福彩官方网站来完成这项工作。与其通过浏览器进行所有自动化,不如通过公共api进行大部分自动化’ s(或其等价物)存在于系统的边界。在进行任何更改之前,上海福彩官方网站会创建因果关系的新版本&循环图以查看他们提出的解决方案是否是对原始解决方案的改进。产品负责人可以’ t此后将注意力集中在全局上:UnfocusedProductOwner在第二个示例中,上海福彩官方网站看到产品所有者对上海福彩官方网站进行了频繁的修订’在Sprint中的工作。我们可以就此与采购专员谈谈,但是我们可以’ t只是期望PO会发生变化,除非我们也确定并解决潜在的问题。如该图所示,我们可以看到真正的问题是,采购订单每天都受到利益相关者的压力,无法解决实际和可感知的客户问题。面临的挑战是如何留出足够的时间来解决这些问题,同时又要在更大的目标上取得进展。这样的因果关系图应有助于组织发现对项目组合管理的需求,这将使产品负责人在应接受上海福彩官方网站短期工作的范围上有一定的界限。在每种情况下,关键点是组织改进上海福彩官方网站必须确保他们’解决系统性–不只是表面–问题。所以让’ s看世界如何’最小的在线书店上海福彩官方网站可能会使用类似Scrum的框架来实现这一目标。我们的世界’ s最小的在线书店组织改进上海福彩官方网站正在进行为期两周的Sprint,以与他们的开发上海福彩官方网站保持同步。正如我们在这篇博文中了解到的那样,组织改进上海福彩官方网站的运作方式与常规Scrum上海福彩官方网站类似,只不过带有一些稍微重新标记的组件。让’ s看到组织改进上海福彩官方网站将如何解决这些问题。组织改进队列(又称产品待办事项列表)由于上面的因果循环图向我们展示了为测试自动化创建专门的上海福彩官方网站并只是要求产品负责人进行更改的原因’ t要解决问题。组织上海福彩官方网站可以避免将时间浪费在无效的本地化解决方案上,而将“改进队列”的重点放在寻找可以为系统带来积极成果的特定事物上。如:LongRegressionCycle–让每个开发上海福彩官方网站的更多成员参与测试自动化; LongRegressionCycle-查找测试自动化的替代方法’ t涉及浏览器;不专心的产品负责人–支持产品负责人拒绝更多加急的客户要求 …组织队列优化(又称产品待办事项列表优化)在与开发上海福彩官方网站代表和上海福彩官方网站级别产品负责人讨论之后,我们一致认为,采购经理希望在两天内响应所有客户问题的压力正在逐渐阻碍上海福彩官方网站提供高质量(这会导致更多的客户问题)和总体情况。他们还确定了对站点许可证JetBrains IntelliJ和“将产品构建时间从15分钟减少到5分钟”。 Sprint计划组织改进小组致力于运行多个实验来解决UnfocusedProductOwner难题。由于此问题需要几个月的时间才能完全解决,因此他们决定执行以下操作:[…]

红色,黄色,绿色或RYG / RAG报告:它们如何掩盖真相

What is Red Yellow Green? Red-Yellow-Green (or Red/Amber/Green) is a status reporting mechanism used to help executives understand the current state of a project. Green means everything is good; we’re on track both with time and budget. In some cases, green means within 5% of budget. Yellow means there is some risk that there are scope or time problems, but with sufficient re-planning we can come back to target. Yellow is usually measured by some number crossing a predetermined threshold. Red indicates the project is in serious trouble. Models RYG is just a model of reality (in truth, all reporting simply models reality). All models hide details with the goal of making the situation easier to read and understand. Some are hidden so much that the truth gets lost. A team’s Task Board, Scrum Wall, or the overall Portfolio Kanban Wall are all first-order models of reality. While not perfect mirrors of the current state of the work, they’re fairly close. They help demonstrate qualitative information; i.e. which stories are complete, not just how much. A Release Burndown Chart, Burnup Chart or Cumulative Flow Diagram are all second-order models of reality. In other words, they summarize information contained on the Walls/Task Boards. They’re useful because they help spot trends. The Cumulative Flow Diagram provides the most information on trends, but it still has less information on it than the Portfolio Kanban. Red Yellow Green Reports are models of the charts, in that they summarize the charts, hiding even more informational details. They assume that a plan’s scope, budget, and time are fixed and unchanging. Models might be adequate in a world where these are true, but in a world that accepts change as the norm, colour-coded reports are dangerous. At best, these reports don’t measure truly done so much as whether a team is on track to make a target. In addition, since RYG reports usually have green as a default state, often there are too few questions that are asked until it’s too late. Charts Even burndowns, burnups, and cumulative flow diagrams are imperfect because they focus on output (# of Stories or story points achieved) and not outcomes (the right features delivered to the customer.) Charts of all forms appear to promise certainty, when there isn’t any, which creates a false sense of security. If we’re going to chart at all, we should use forecasts and not precise lines, and make it clear this a forecast. If your chart just shows the average velocity, then you should provide a forecast that says we have a 50% chance of achieving this rate for the foreseeable future. If you want to get more sophisticated, you can track error bars as well. 我 asure your best and worst three Sprint’s Velocity in the last six months, and use these as your 20% and 80% confidence bars. Then you can say that you’re 80% confident you will do at least as well as your worst three sprints, and 20% confident that you will do as well as your best three sprints. Even this model has a weakness in that it assumes your velocity will follow normal distributions. The reality is likely that it won’t. However, forecasting with error bars (or lines) usually gets the idea across that we’re forecasting a range of possible outcomes. Genchi Genbutsu Finally, all reports discourage people from leaving their offices. They give us the false feeling of safety. The report seems real and so it gives a good model of what is actually happening. Toyota has the practice of Genchi Genbutsu – go and see, literally. Review the charts but then leave your office and go to the place of the work. Watch, listen, ask, and review the Portfolio Kanban wall with the team(s). This will bring you back in contact with the reality of which features have been truly done. This will help you see if all the Story Points in the charts delivered the value that they claimed. Stop/Do So stop using RYG reports. They hide too much information. Do use Burndowns/Burnups/Cumulative Flow diagrams as a tool to help you spot trends, but don’t rely on them alone as the source of truth. And most importantly, review the Portfolio Kanban Wall with the Team(s) on a regular basis, as this is our best measure of reality. http://www.drdobbs.com/dr-dobbs-agile-newsletter/191600661 Other have taken up on it as well: http://www.solutionsiq.com/greenshifting-and-redshifting-within-projects/ http://www.edmundschweppe.com/2013/12/the-green-shifting-anti-pattern/ http://calleam.com/WTPF/?p=1205

单独的Scrum还不够

要长期成功使用Scrum,您需要的不仅仅是基本框架。这是故意的。 Scrum提供了结构作为起点,但是它’旨在与其他有效模式一起使用时效果很好。就像后期的设计模式运动’90年代,图案可以单独使用或与他人一起使用。例如。命令模式和记忆模式可以结合起来以构建有效的撤消/重做系统。 Scrum仅是一支上海福彩官方网站的一种模式。它为您提供了可能可行的最低限度的框架,但是在许多情况下,您将需要合并其他工具/模式以构建更有效的系统。除了Scrum,您还应考虑:–      有效的敏捷工程实践–例如单元测试,持续集成,测试驱动开发,验收测试驱动开发(或BDD),结对编程。没有这些实践,代码库的运行状况将随着时间的流逝而降低。–       Kanban –(一种了解和改善流程的工具),以帮助了解上海福彩官方网站和组织层面的工作流程。如果对组织中的工作流程没有很好的了解,我们可能会做出局部改进但会损害整体的更改。–      投资组合管理–做出大图决策的技术,以决定业务接下来要专注于哪些主要工作。组织需要资产组合管理,以确保上海福彩官方网站理解主要优先事项’产品负责人,并按优先顺序进行工作。–      组织改善–Scrum帮助找到的许多问题可以’不能由上海福彩官方网站或其ScrumMaster解决。相反,组织需要建立一个持续不断的改进上海福彩官方网站来致力于解决这些问题。–      上海福彩官方网站内部协调–您将如何协调上海福彩官方网站之间的工作? Scrum of Scrums是最著名的模式,但很少是最佳选择。–       Team Organization –您将如何组织上海福彩官方网站?作为组队?作为功​​能上海福彩官方网站?使用小队,部落和行会的Spotify模型?那里 are no 最佳做法 . Scrum itself could prescribe all of this, but that would be missing an important Agile point: there are no 最佳做法 . A practice that works well in one organization (or context) may not work well in yours.  当要大规模有效地工作时,可重复模式才刚刚开始出现时,尤其如此。即使在开始出现一致模式的地方(例如,大型Scrum,Enterprise Scrum,…),通常不清楚哪种方法适用于特定情况。最后,请记住Scrum不是’旨在适合您当前的组织及其现有结构。目的是迫使我们考虑什么是可行的,哪些需要改进。 Scrum只是起点。 在接下来的几个月中,我将探索在更大规模地尝试Scrum(三个以上的上海福彩官方网站)时可能有效的模式。您希望我探索什么主题?

欢迎来到高效能上海福彩官方网站游戏

您的上海福彩官方网站正在研究世界’ s最小的在线书店,为每个搜索(而不是地球上的每个结果)提供最佳结果(仅几个)的网站。我们’是一个秃capital资本投资的公司,所以如果我们不’ t交付,我们的资金将被削减。因此,开始了高性能上海福彩官方网站游戏的开幕。我的目标是帮助您了解选择/权衡对生产率和上海福彩官方网站凝聚力的影响。尽管敏捷的某些好处发生在个人层面,但有很多因素会影响上海福彩官方网站成员之间的关系,从而影响上海福彩官方网站的整体凝聚力和生产力。该游戏由5-9人组成的上海福彩官方网站进行,&5-6轮。在每个回合中,都有一些上海福彩官方网站合作,一些关于科学的讨论以及一些游戏性。每轮代表6周,或3个2周的冲刺。在每个回合中,您都可以根据上海福彩官方网站的工作量/工作量来预算’ s容量。该预算中的一些必须用于交付功能,否则业务将威胁到您放手。其中一些应该花在发展上海福彩官方网站和他们的工程技能上,否则你不会’ t获得更多预算能力。一些领先的研究[1] [2]提出,高绩效上海福彩官方网站的关键要求是凝聚力。凝聚力是衡量单个上海福彩官方网站成员之间关系强度的方法。在本节中,我们将使用这项研究发现:·     我们可以监控简单的沟通模式以发现上海福彩官方网站的健康状况。·     我们可以使用简单的工具来测量和跟踪这些模式。·     水冷却器的位置有什么影响?午餐桌有什么作用?·     有凝聚力的上海福彩官方网站会给您带来麻烦吗?·     上海福彩官方网站内部持不同意见和多样性的重要性。·      Bonuses –敏捷社区已经很好地理解了个人奖金的负面影响。但是,我们’离开与问题:有好奖金?下载可用的游戏资料(“ Dropbox”文件夹):上海福彩官方网站成员讲义上海福彩官方网站操作工作表(每个上海福彩官方网站1个) 辅导员资料:上海福彩官方网站游戏样本游戏–马克·李维森(Mark Levison)制作的《幻灯》和《上海福彩官方网站科学》游戏版播放了游戏的四种可能路径 除了游戏资料,我’已在 “建立高绩效上海福彩官方网站的5个步骤”。喜欢和您的上海福彩官方网站一起玩。 来自GOAT的反馈(2015年渥太华加蒂诺敏捷之旅):在进行游戏时&在会议上,只有主持人知道每项行动的利弊&比赛进行了。结果,在90分钟的会议中,一些上海福彩官方网站遇到了困难&跟踪计算时间。将来的版本将在与会者之后的回合中将所有计算细节以纸质形式向与会者公开。’ ve演奏了。 [1]桑迪·彭特兰–建立伟大上海福彩官方网站的新科学[2] Ben Waber–人物分析 

JIRA不敏捷

I’我听到人们说,“我们开始使用Jira和GreenHopper,因此我们’re Agile now”。 Rally,VersionOne,LeanKit,TargetProcess等也有类似的说法。在进行这些声明时,它会’很明显,他们没有’完全不了解敏捷。敏捷的核心是一套价值观和原则:…. ·     个人与互动 过度的流程和工具·      Working software 全面的文档·     客户合作 过度合同谈判·     应对变化 过度执行计划也就是说,尽管右侧的项目有价值,但我们更重视左侧的项目。这些基础是一种心态,侧重于自律,自组织和适应变化。 Scrum的实践(Sprint计划,每日Scrum,Sprint审查和Sprint回顾),角色(ScrumMaster,产品所有者和开发上海福彩官方网站)以及工件(产品待办事项列表,Sprint待办事项列表和产品增量)仅对上海福彩官方网站有所帮助。支持这些原则并实现交付工作软件的目标。电子工具(任务墙,开发环境,…)或物理工具(任务栏,…)仅在为这些原则和惯例提供支持的情况下才有用。如果您的敏捷采用是从工具和一系列实践开始的,那么这一切都被遗漏了,核心– the essence –在了解敏捷之前,需要仔细检查敏捷性。

ScrumMaster故事–卡住等待其他上海福彩官方网站

约翰(ScrumMaster)和上海福彩官方网站正在为SmallestOnlineBookStore精心构建出色的新功能。九个月前,随着首个大型发行的巨大成功,风险投资资金已经流入公司。除了创建几个新的开发上海福彩官方网站以外,在运营,安全和网络方面也进行了大量投资。不幸的是,所有这些新手使上海福彩官方网站更加难以部署自己构建的软件。新上海福彩官方网站通常会在软件发布之前对软件进行自己的审查和处理 ’部署。某些更改将增加网络的负载,并且需要网络上海福彩官方网站进行审查。其他更改会影响支付网关,后端管理和服务上海福彩官方网站,这些交付周期为三周。所有这些审查在提高安全性的同时,大大减慢了新功能的交付。开发上海福彩官方网站感到沮丧的是,他们认为下游的上海福彩官方网站会人为地减慢他们的工作(即网络和安全性)。客户之所以烦恼是因为以前大量的功能已减慢了速度。此外,上海福彩官方网站还为每个开发人员创建了一个故事的工作进行中(aka WIP)。这既加剧又揭示了问题。它’之所以加剧,是因为上海福彩官方网站没有’无论何时遇到主要任务,都没有工作的背景。这也表明真正的问题是’在工作要进行的上海福彩官方网站层面“almost”完成。 John为上海福彩官方网站创建了一个简短的选择列表:将每个在制品的限制提高到2个;更改“完成”的定义,以便安全和网络审核’完成的一部分;在他们的Scrum任务墙上添加一列来说明其他两个小组,并开始与其他部门合作以更快地完成工作。分析在探讨这种情况下的选择之前,我更喜欢收集数据。在这种情况下,最好的方法是创建一个看板墙,以跟踪故事从最初的构思到其瞬间的进度。’已部署,并令客户满意。结合累积流程图,这将有助于上海福彩官方网站的来源’的压力。 John意识到这可能是一个问题,已经跟踪了一个多月的数据:从数据中我们可以生成一个如下所示的累积流程图:那么该图表显示了什么?上海福彩官方网站不是’在这种情况下的瓶颈。我用来告诉一个简单的测试是这样的:“如果我们有一种神奇的方法可以将您提供故事/功能的速度提高一倍,那么这将对客户获得功能的速度产生真正的改变吗?”在开发上海福彩官方网站一级–代码,代码审查,测试– clearly that isn’在这种情况下,瓶颈就在“Done in Development”,这实际上只是一个缓冲,并进行了网络/安全性审查。而不是在上海福彩官方网站级别进行更改,我们需要查看可以做些什么来优化下游工作。根据这些数据,让’重新检查上海福彩官方网站’s选项:将单个在制品的限额从1增加到2–这实际上只是掩盖了问题,当原始项目卡在“网络”或“安全性”中时,会给其他人提供其他工作。正如我们’我已经看到极限是’t在上海福彩官方网站一级,因此在那里进行优化’没有帮助。更改“完成”的定义,以便故事在执行时被视为“完成”’移交给外部上海福彩官方网站。– This doesn’不能真正帮助客户,因为该物品仍然是’部署后,它只会使每个开发人员都感觉更好。但是,在为下游组创建附加列时,我们有效地为每个列创建了“完成定义”。看板称这些“policies”。所以我们改变了“Done”但这只是以使我们的问题更加明显的名义。在Scrum任务墙上添加一列– We didn’确实做到了,相反,我们创建了看板墙,以确认某些工作超出了我们的上海福彩官方网站’控制范围。所以让’■添加新选项:开始与其他部门合作以更快地完成工作–在以看板为导向的世界中,上海福彩官方网站蜂拥向下游阻塞。在我们的案例中,这绝对是个好主意。  如果我是约翰的教练,我会让他与其他上海福彩官方网站和部门一起设置看板跟踪墙,以便整个公司可以看到工作的位置。我将邀请每组的人员每两天来更新一堵墙。通过参与设置和跟踪,其他上海福彩官方网站(即安全和网络)的人员将意识到数据反映了他们的世界,并且他们将更愿意对数据采取行动。此外,John(及其上海福彩官方网站)将对影响网络和安全的因素有更深入的了解。–也许公司在6月底遭受了拒绝服务攻击,几天后,两个上海福彩官方网站都被撤消了审查以处理运营问题。上海福彩官方网站可能还会发现他们’被发现经常违反安全惯例。在这种情况下,来自安全部门的指导可能会增加上海福彩官方网站’领域的技能水平,并减少在审核阶段花费的时间。在这种情况下,经常对上海福彩官方网站进行交叉培训(请参阅:上海福彩官方网站变得瓶颈)以帮助减少下游瓶颈会有所帮助,但是我们赢了’t know until we’我们收集了数据,并与其他上海福彩官方网站一起找出了真正的问题所在。顺便说一句,我不’当作为Scrum上海福彩官方网站的一员工作时,建议每个WIP限制–而是专注于整个上海福彩官方网站的在制品。它’这是一个很小的变化,但很显然,上海福彩官方网站的生产力比任何一个人的生产力都重要。

用户故事的生命周期

用户故事通常用作敏捷需求的轻量级形式。他们的目标是 用以下文件代替较重的规格文件“卡片,对话和确认”。人们首次发现用户故事时’很难看到它们如何工作,因为我们经常采取静态观点–即我们只在发布计划或实施过程中看到它们。我们’留下许多问题:用户故事从何而来?它们何时创建?谁参与了他们的创作?为了说明这一点,我将使用WorldsSmallestOnlineBookStore中的小插图。每个小插图将显示一个用户故事发生了什么。 “作为经常读书的人,我想保存我的地址,这样我就不会’每次我访问书店时都不必重新输入”在上海福彩官方网站中’在此故事的第一次发行计划会议(亦称初始产品积压提炼)。经过几轮计划性的扑克之后,共识估计是大小为20,允许初始输入地址,更新和删除旧地址。由于该故事在短期内似乎不太重要,因此上海福彩官方网站将其转移到其他项目上。&你好;在Sprint#5的“积压细化”会议中,PO Sue重新审视了Story,并询问上海福彩官方网站对问题的理解在过去两个月中是否已改变。他们进行了几分钟的讨论,并决定仍然是20。Sue抱怨说,对于这么多的人来说,这只是一个很小的功能。道格建议将故事拆分–他使用CRUD(创建读取更新删除),在短期内建议允许用户添加新地址并使用它。但是,他们不会’ t能够更新和删除。这将分隔故事。在围绕含义进行了几分钟的交谈之后,Sue要求他们估算三个分开的故事:“作为经常读书的人,我想保存我的地址,这样我就不会’每次我访问书店时都不必重新输入.” “作为经常的购书者,我想删除旧地址,这样我就不会’不必担心我的书会寄到错误的房子。” “作为经常读书的人,我想更新我的现有地址以纠正一些小错误,以便我’ t不必重新输入。” &上海福彩官方网站确定“save address”故事是8号,“delete address”故事大小5,以及“update address”故事大小8。根据此Sue移动“save address”产品待办事项顶部的故事,“delete address”大约还有15个项目“update address”已经移到了很低的水平,将永远无法解决。由于苗条“save address”现在是产品待办事项列表中没有接受标准的头条新闻,上海福彩官方网站花了几分钟时间为其创建标准。他们首先画一个快速的铅笔素描来了解关键点。他们根据此草图开始创建示例表:1 Sussex Drive,加拿大安大略省渥太华,K2K 010有效白金汉宫,英国伦敦,加拿大/美国以外的地址1600 Pennsylvania Avenue NWW华盛顿特区20500有效,而不是尝试创建此时,他们只是创建了一个详尽的清单,以概述问题的边界。在上海福彩官方网站中’在下一个Sprint计划会话中,Sue询问上海福彩官方网站是否可以执行此故事。他们给它“thumbs up”。在上海福彩官方网站开始讲故事之前,Tonia(质量保证专家),Brad(文学士),Doug(开发人员)和Ian(开发人员)开会,以敲定接受标准。 915 E 7th St. Apt 6L布鲁克林NY 11230有效期24 Willie Mays Plaza,加利福尼亚州,加利福尼亚州94107有效期24 Willie Mays Plaza,加利福尼亚州,加利福尼亚州否邮政编码24 Willie Mays Plaza,旧金山,94107否州45 Rosenfeld CrOttawa,ONK2K 2L2有效的45 Rosenfeld Cr,渥太华,ONK2K 2L2有效的45 Rosenfeld Cr,渥太华,ONK2K 2 222无效的邮政编码45 Rosenfeld Cr,渥太华,ON 邮递区号遗失&你好; (此样式称为“示例规范”–重点是在构建某些内容之前先提供规范)。布拉德(Brad)出发查看示例是否存在任何极端情况’ t掩护。 Ian和Tonia结对,将示例转换为Fitnesse [1]中的可执行规范(即验收测试)。道格开始在GUI上大做文章,看看他需要组装哪些零件。编写完初始测试后,Ian会尝试构建业务逻辑以支持示例。几天后,当伊恩和道格认为他们’已经完成了故事,并且符合示例,他们向Tonia展示了该故事。一旦她发现满足测试用例,就会花一些时间进行一些探索性测试–了解真正的用户玩游戏时应用程序的行为。满意后,她致电Sue寻求其他反馈。 Sue对此行为感到满意,但要求对布局进行一些更改。完成这些步骤后,她同意故事将完成。在Sprint期间,Ian演示了我们现在可以支持接受来自加拿大和美国的地址的不同方式。在Sprint结束时,上海福彩官方网站将完成的故事从墙壁上取下来并将其存档在文件柜中(他们将它们存放在附近以备以后审核)。———在Sprint#6期间,布拉德(BA)在走廊上看到了伊恩(开发人员),他们开始谈论仓库管理员,即负责完成订单的人。布拉德评论他’ s看到跑步者花费大量时间来追踪自己的脚步,因为订单中的书单是按字母顺序排列的–但不幸的是仓库没有’ t按字母顺序排列。他们创建了一个新的故事:“作为跑步者,我希望书单的印刷顺序相同,所以我会在仓库中找到它们,所以我不’ t必须跑到最远”在“待办事项优化”会话中,[…]