敏捷 – 第16页小小书 XXshu

我如何组织生活

这是关于生产力的三本书的简短版本：完成工作，Scrum和高效人的七个习惯。当我试图将一长串的义务放在脑海中时，我感到非常压力。每当出现需要引起我注意的内容时，我都会将其记录在一个受信任的中央位置，称为“桶”。对于我的桶，我使用“记住牛奶”作为应用程序和网站。它们同步，所以我始终可以通过手机或PC访问相同的列表。我养成了一个非常可靠的习惯，总是将每个“待办事项”放入RTM。在大多数情况下，这意味着我不具有“我是否应该就某件事回覆某人？”的感觉。这对我的理智非常重要。我至少每周一次清除RTM中的待办事项清单。我将任务列表中的任务按2个区别进行排序：紧急/不紧急和重要/不重要。紧急情况很明显。如果待办事项有最后期限或感到紧迫，那就很紧急。重要性与我的目标有关。我问“这是否有必要使我更接近目标？”，如果是，这很重要。不重要的内容将被删除。这很关键，对我来说是最难的。我想做全部，但不能，所以我必须选择。如果项目紧急且重要（“ I象限”），我将立即执行，或者（如果它们将花费很长时间）将其分解为子任务。…

读书俱乐部又回来了-振作起来，出现吧！

什么？真？一个读书俱乐部？上个世纪不是这样吗，还是奥普拉（Oprah）和她的数千万追随者这样做？我为什么要加入一家读书俱乐部？这是一种构建学习文化的经济有效的技术。当然，您很忙，每周都有一次无聊的会议，您在做的所有事情都是在思考到底是什么，将7分钟的时间拖入60分钟的脑细胞谋杀案对企业来说是值得的！如果这是您的喜好，那么您有很多工作要做。如果您喜欢讨论，发现，辩论，探索想法或做事方式，那么读书俱乐部就是您的最佳选择。他们就像去看电影，在那里您可以闲聊电影。您可以扮演场景的导演，也可以担任演员，看看角色是否对您有帮助。 http://ebookfriendly.com/wp-content/uploads/2013/07/Andertoons-library-cartoon-by-Mark-Anderson.png 认真地说，业务收益是三倍。首先，您有一群专注的同伴以非常经济高效的方式提升了他们的能力。其次，您必须以安全的辩论方式提炼出围绕方法论或技术的所有理论或宣传，从而避免大量失败的采用程序。第三，您可以在企业中建立思想领袖之间的智能互联文化。谁不会雇用这种人？让我们看一下十二个人读书俱乐部的基本费用。…

设置工作空间以实现协作和清晰度

最近，我们完成了一个从第一天开始就具有挑战性承诺的项目。在项目后的讨论中，我很惊讶地听到我们的实际故事墙和冲刺指示器对团队产生了什么影响。在#ThoughtWorks和开放设置中，物理情节提要板是我们设置不可或缺的一部分。站立，项目跟踪，中期迭代审查通常引用这些道具。我们努力使工作场所尽可能可视化，以便一目了然地提供必要的信息。自从几个项目以来我一直在使用三种实践与专栏谈论今天的站立式物理墙使用Sketchboard应用程序创建我喜欢设置“ 开发中”列分为两个部分的项目墙。其中有一个专门的专栏，其中包含有可能完成开发并可以开始测试的故事。进行此拆分有助于多种方式。通常，负责此工作的人员会仔细查看卡片，并向小组更新剩余的内容。它还可以帮助质量保证人员计划工作。如果“今日移动”列中有一堆卡片，以及一些“准备好进行质量检查”队列，则需要评估情况。快速浏览此板可以揭示能源需求的渠道化。从我们最近的项目之一登机根据需要，列和卡片的颜色可能意味着不同的事情。列通常保持不变，有时我们在ToDo之前有Analysis列，表明还有更多分析工作要做。…

为什么我要建立自己的任务跟踪器

首先，我希望您考虑一个事实，我们所有人都不是逻辑上的人。我们在关系中没有逻辑地行动，在经济学中没有理性地行动。我们为什么要遵循组织工作的逻辑？但是从另一个角度来看，我们喜欢将自己视为高度有组织，有逻辑的生物。还记得经济学中所有早期的理论，人们认为它们应该表现得合乎逻辑并最大化自己的利益，而事实证明这是错误的？理论化工作流程时，我们也会犯同样的错误。从侧面看订单时，虽然我们喜欢订单，但我们并不擅长创建订单。面对现实，我们在经济行为或工作上都不合逻辑。像SCRUM，Kanban或其他类似的组织工作的现代过程过于逻辑化，是为机器人而不是人类而设计的。它们看起来不错，我们“购买”它们。但是他们不尊重我们的人类警告。是的，他们接受我们通常在估计和其他一些小问题上是错误的，但这还不够。这就是为什么在现实生活中很难应用它们的原因。我曾在许多小组中尝试使用SCRUM，但在任何地方它都很困难，在所有地方它都会减慢整个过程，同时应该改进它。但是毫无疑问，有效的系统必须顺利进行，因为您会感觉到而不是计算它的有效性。任务跟踪器也存在同样的问题。它们都构建为逻辑系统，可与逻辑工作流程一起使用。而且它们比人类更适合机器人。…

建立软件生命周期集成的业务案例

第1步-确定集成看起来很简单，但是软件交付流程中可能有许多不同的集成，包括开发需求，测试开发，测试需求以及所有学科的项目管理。每个整合都有其价值和风险。例如，将测试与开发联系起来的价值是巨大的，但是当每个开发人员使用不同的工具时，集成可能会非常困难，从而增加了集成工作或相关成本的风险。快速扫描所有可能的整合和风险，直觉感觉是一个很好的起点。对于许多组织来说，由于现有的过程问题，审核问题或严重的沟通问题，已经预先确定了要关注的集成。因此，对所有整合机会的整体识别是毫无意义的；相反，专注于所需的集成往往是重点。但是，从整体上而不是一系列相互联系的学科来审查应用程序生命周期，可以提供经常被遗漏的见识。集中精力于生命周期的一个特定集成或某个方面，而又不考虑该流如何与其他流连接，就太容易了。例如，考虑测试和开发是一个很好的开始，但是在操作和需求的背景下进行检查将有助于您确定业务变化的顿悟。第2步-获取实际财务数字用高，中，低来确定价值是定义要关注的集成的一种好方法，但是集成有成本，因此，确定集成的潜在财务价值很重要。集成成本是识别信息价值的好起点。例如，通过使用IDC在计算信息查找成本时所采用的类似过程，询问团队需要多长时间才能找到正确的内部版本或缺陷列表。查看询问有关需求和构建状态问题的电子邮件数量。然后，该信息应转换为实时和费力的工作，每个角色都需要付出实际成本。第3步-创建年度费用并查找重叠…

每日站立

1914年8月14日上午，军事总督兼巴黎军区司令官约瑟夫·西蒙·加利尼将军召集了他的内阁会议。这次聚会不是普通的会议。距第一次世界大战爆发不到四周，德国军队正在巴黎进军。[1] 将军要求他的内阁而不是坐直，并避免讨论眼下有争议的战略话题-是否应该捍卫巴黎。保卫巴黎的目标已经到位。取而代之的是，要求该小组证明他们同意将军提议的国防状态并审查战术命令。会议只持续了十五分钟。[2] 大约八十年后，Easel Corporation的软件工程师团队从办公桌上崛起，其目标是不同的：将具有所有预期功能的软件按时交付给客户。敏捷管理实践Scrum的联合创始人Jeff Sutherland领导团队，他们陈述了当天的工作以使团队更接近其目标。 [3]站立会议有以下三个规则：每天在同一时间进行，持续时间不超过15分钟，并且所有团队成员都必须参加。在采用这种做法仅一周之后，Sutherland发现他的团队的生产率提高了400％。[4] 站立式技术在技术公司中具有无与伦比的流行度，有80％的软件工程师报告说他们参加了VersionOne调查中的日常站立式工作。像萨瑟兰（Sutherland）的会议一样，站立起来的时间通常不超过15分钟，并且每天在同一时间进行。各个公司的做法各不相同，有些组织要求参与者讲话时要带药丸或对迟到的人处以罚款，但会议的共同目的是：确保团队团结一致，朝着目标前进，以及尽快清除所有障碍。[5] 由17个软件开发人员组成的团队在2001年发布的《敏捷宣言》概述了理想的日常会议。[6] 站立站立时要站立而不是坐着，以鼓励简洁并减少干扰。…

21世纪的自我维持生产力系统

对我而言，一个快乐的系统就是其中系统的维护与该系统的运行直接相关的系统。例如人体。最可怕的系统是维护周期短，需要大量时间和精力来执行的系统。想象一下，如果您每次去干衣服都必须清除棉绒，并且要卸下棉绒陷阱，则需要卸下五个螺栓。话虽如此，我喜欢自我维护系统。一个流行的故事来自精益制造和丰田。您的工作是在汽车上放上门。我的工作是制造汽车门。如果我建造的门超出了您的需求，我们就会遇到问题。因此，我盖了五扇门，然后给您托盘以将它们放在汽车上。您到达第五扇门，有一张卡。卡片上写着：“请盖五扇门。”您将卡片交给我。我盖好第一扇门，在上面放卡片，再盖四扇，然后把货盘拿给您。通过稳定的工作（psst…雇用我）减少了时间，并随着时间的推移写了《 Triumph》（仍然接受beta读者！），我能够改善自己的个人系统，以度过邪恶的和平，富有成效的生活。最近我一直在考虑扩展。不是为了大而把事情弄大，而是要使当前的情况容易地达到正确的复杂度……您知道，敏捷。…

价值流图终极指南

该价值流映射教程旨在帮助您熟悉价值流映射的概念。它提供了与VSM相关的所有内容的详细概述，从其起源到进行价值流图分析时应遵循的步骤。值流映射是一种精益工具，用于可视化生产过程。通过发现瓶颈并消除浪费，它有助于增加产品或服务的价值。价值流图的起源价值流图的起源（即所谓的“物质和信息流”）可以追溯到丰田汽车公司用来了解组织内部物质和信息流的视觉映射技术。 “价值流”一词最早是由詹姆斯·沃马克，丹尼尔·琼斯和丹尼尔·鲁斯在1990年的《改变世界的机器》一书中提出的。1996年，詹姆斯·沃马克和丹尼尔·琼斯在《精益思想》中进一步推广了这一概念。根据他们的说法，价值流是“通过任何企业的三个关键管理任务（解决问题的任务，信息管理任务，物理信息的任务）生产特定产品所需的特定操作的集合”。 Mike Rother和John Shook在“学习观察”（1998年）中详细解释了该方法在制造中的应用。然后在2004年，Beau Keyte和Drew Locher讨论了价值流图在办公和行政流程中的扩展应用。什么是价值流图？…

学与教如何塑造我们

警告：这种理论是在酒吧里幻想的，虽然并不完全清醒。因此，可能完全是胡说八道。你懂。不要说我没有警告过你。图片来自@SpiralSkies 无论如何。前晚我在酒吧里和朋友聊天，他描述了三种人：那些做驴子的人。他们没有任何奇异的技能，他们只需要努力工作。那些只有一件事的人真的很擅长。那些喜欢探索和创新的人。他们有想法，发现新事物，但是在任何一件事情上都不是特别擅长。我不认为您可以轻松地对这样的人进行分类-我认为每个人都是多方面的。大多数人都有自己擅长的几件事。许多人都有自己热衷的事物，但是他们从来没有机会发展这些技能。或存在技能，但他们从来没有机会（或倾向或信心）来展示它们。我想我将我朋友的类别重新包装如下：那些从未有机会展示自己的才能或探索自由的人。…

当敏捷，DevOps和精益还不够时：软件交付中缺少必要的条件

执行摘要精益，敏捷和DevOps原理在许多重要方面改善了软件交付。随着不断发展的市场迫使软件组织提高质量和生产率，对这些概念的兴趣从未如此高。但是，尽管它们在个体和集体方面都有相当大的优势，但它们在解决现代软件组织所面临的各种问题方面仍存在不足。为了缩小差距，必须将这些原则编织在一起，以使您能够充分利用人员，流程和技术的潜能。最快，最有效的方法是创建一个集成的软件生命周期。从计划，开发和测试到部署和维护，集成完成与软件交付相关的所有任务所需的所有工具，将使信息在从业人员之间自由流动，并遍及整个团队。这使扩展的团队更加有效，并提供了急需的项目可见性。满足这一缺失要求的软件组织可以在质量，速度和可追溯性方面获得实质性的收获。不同的路线，相同的目的地过度简化的风险在于，精益原则植根于运营中。他们从汽车工业中广泛采用，专注于提高质量，加快周期时间，消除浪费和缺陷，增强团队能力并促进持续学习的过程。敏捷方法具有这些目标，但更关注个人及其交互。敏捷鼓励采用灵活，分散的软件交付方法，使团队成员通过不断的反馈和协作来应对不断变化的环境。 DevOps原则通过在整个项目生命周期中更加重视开发（“ Dev”）和运营（“ Ops”）团队之间的沟通与协作来进一步发展。他们还强调了集成和自动化在尽快交付更好的软件方面的重要性。…