敏捷 – 第2页小小书 XXshu

Stride的精益咖啡

精益咖啡的概念起源于2009年的西雅图。这个概念有点像开放空间：一群人聚集在一起，召开一次结构性但无议程的会议。结果：真正源自员工的想法。在Stride，我们采用并改编了精益咖啡的概念。这个想法源于我们希望经常聚会以进行简短，有效的讨论的想法。我们知道我们不希望时间由PowerPoint驱动，我们也不希望所有时间都花在一个人身上，或者是一小撮人在讲话。我们正在寻找的是一种让整个公司中的任何个人都可以听到的方式。这是Stride精益咖啡的一瞥： 8：45–9：00am抵达和早餐大步走聚集。我们拿起咖啡，水果，百吉饼和酸奶，然后坐在座位上。 9：00–9：15每月闲聊我们领导团队的一两个成员对Stride的运行情况进行了快速更新。我们分享战略计划的最新动态，欢迎新员工，并大声疾呼任何晋升。 9：15–9：20主题构想在这里，我们正在寻找主题思想进行辩论。好的主题创意会影响整个组织。主题构想也应该是可能引起来回激烈辩论的问题或机会。例如，如果我们可以在五秒钟内说“是”，那么“我们都应该获得新办公室的钥匙”不是一个好话题。…

提示编码产品

Membahas mengenai 编码 atau aktifitas menulis脚本dalam sebuah bahasa pemrograman untuk menjadi sebuah aplikasi yang di inginkan adalah sebuah…

为什么每个创意者都需要在手工艺中接受秩序

订单-个人和专业品质制造商，手工艺者和创意者需要。此语句听起来是否熟悉： “该死的（在此处插入广告素材的名称/角色）！！！该家伙应该在（插入疯狂的时间范围内）完成此操作” 这是许多处理广告素材和制作商类型的客户中非常普遍的一条线，即提供出租服务并承诺回报质量。当您获得所需的东西时，与完成工作的时间和承诺的时间相比，质量已经不是什么大问题。裁缝或开发人员通常会接受您的项目并以他们可以产生的质量程度向您出售，但是交付质量的时间和过程却传达出一件事-没有专业知识。顺序在其真实定义中激起了诸如适当，令人满意，良好的工作条件和可靠的词语。当提到这个词时，安全性，严格性，僵化性和组织性的感觉也随之而来。但是，鉴于广告素材的性质，上述词语都不是其词汇的一部分。对于一个极富创造力的人来说，采用流程和使用简化的方法来完成任务是非常陌生的。以SCRUM为例。这是一个旨在确保质量和管理项目范围的软件过程，但对所谓的创意作品爆发工匠提出了挑战。流程，例行程序和进度表是传递创造力的渠道。如果您在没有适当的最终目标的情况下漫无目的地从一项活动跳到另一项活动，并声称这是您的过程的一部分，那么您在任务结束时就不会有什么固执的东西。领先的创意人已经证明，对创意流动性的某种僵化可以使创意在现实的环境中蓬勃发展。不管您的工匠素质多么出色，如果您不这样做，您将无法按时交货： 1.…

第9部分。持续关注技术卓越性和良好的设计，以及……10.简单性

实际上，我发现这处于市场上几乎所有当代敏捷开发人员的理解和能力之上的水平。如果他们理解这一点，他们通常会是建筑师。对细节的关注度非常低，使大多数开发人员无法相信对一种好的设计模式的理解就足够了，而无需了解每种设计都特别适合一种情况而不是另一种情况的权衡取舍。这对他们来说是一个危险的职位，因为反模式是模式选择不当或要求无法满足模式无法预期的结果。此外，低级开发团队没有看到的是整体设计中的优化点，以允许并促进团队中代码或组件的重用。在这里，解决方案架构师可以通过具有更高层次的视图来弥合理解上的差距，从而使他们可以在部署交付物时看到它们，并可以管理这些软件资产的重用，这成为解决方案构建块，并已添加到解决方案构建块中。企业资源库是解决方案连续性的一部分。确实，跨团队进行重复工作非常容易，而错过了这一步骤。毕竟，如果一个开发团队信任另一个开发团队来抵抗第一个开发团队发出的“拉动”信号，而第一个开发团队则交付自己的相关功能，并被客户或更糟的第二个团队信任来提供此功能。精打细算的主要罪恶之一就是阻止工作重复，因为它是浪费的直接形式。除了产生必须交付以允许企业参与的架构功能之外，企业架构师不承担原则9的责任。他们的简单性观点（原则10）是组合优化，它降低了组合复杂性，从而减少了涉及的开发团队为交付软件而进行的每组迭代所需的工作量，并获得了更大的收益。企业改变方向所需的精力。请考虑以下两种情况。开发团队生产的一块软件（例如，一项服务）实现了一个业务流程，该业务流程本身消耗了公司周围其他4个服务中的功能。其他4个服务都相互双向链接，但不是第一个（即，对于4个内部服务，通过6个通道有12条通信链接）。这里有5个服务，并且假设这4个内部服务之一更改了其服务合同。负责此服务合同的开发团队将开发并发布新接口，这将断开与服务的所有其他连接（其他3个）。然后，其他3个团队必须更改其对该服务合同的使用并相应地编码。涉及的工作量很大。这已经打破了一致性治理原则的对称性。…

最低可行的官僚机构-扩展敏捷项目管理的实用方法

与新的数字颠覆者并肩转型的公司通常谈论的是最低限度可行的产品（或者更好的是最低限度可爱的产品）。但是，这些企业应该考虑的另一个“最低可行”类别-最低可行官僚机构（MVB）。官僚主义往往具有非常消极的含义，尤其是在敏捷企业中，其流动性高于传统企业。但是，Mozilla和Spotify已使MVB在敏捷企业中变得流行，这使高管们得以回答一个永恒的问题-我们如何在不妨碍创造力的前提下保持大规模的效率和一致性？关于实现MVB的理论很容易，但是实际实现更具挑战性。以下对实际MVB实施的见解应为平衡敏捷性和治理提供一条更清晰的途径。规划最低可行架构的高层步骤大多数项目都具有特质，添加敏捷方法会使涉及更长视野的全公司范围的计划变得更加困难。很难确定正确的计划工具集-可视化公司的运作方式是您第一步的目标。为此，请从厚实的角度对公司进行可视化处理-一个是从项目角度来看，另一个是从知识转移角度来看。项目切片提供了详尽的信息，例如涉及哪些团队（从销售一直到执行）以及从事特定项目的个人。业务的知识转移部分显示了团队和个人如何在整个项目中进行交互。随着规模的扩大，您将无法与项目中的60个团队成员以仅10个团队的方式进行沟通。可视化这部分业务可以帮助您确定当前和未来的质量和数量瓶颈。…

如何应对积压的商品？

如果您习惯于将工作流程存储在可视化板上，那么您可能会遇到积压的永远增长的诅咒–在这种情况下，您可能会想“ 我们永远不会完成这个项目 ”。有可能-您可能是对的！考虑一下您实际上要处理列表中最后一项的几率，如果通常优先级较高的新项不断堆积。对于软件开发人员来说，早晚要添加另一个专栏或项目并不少见，这对于保持他们要及时处理的任务并不陌生，因为他们非常了解，原始的，现有的积压工作有太多的想法。永远都不会。可以这样说，如果积压量超过一定大小，它也可能会停止存在，因为它变得无关紧要，“ 天上掉馅饼 ”，“ 不是一个好人的好地方”总是有时间工作。那么，还有什么选择呢？限度一个想法，尽管是激进的，但首先是不要让积压的工作积压团队的能力。换句话说，如果团队正常情况下每周可以处理40个任务，则每周积压40个任务。通常，您应该考虑在所有积压订单中都设置一个时间范围（任何时间范围）。这是确保事情不会最终被写下来并长时间闲置的一种逻辑方法。将计划的工作分为紧迫性和时间表不同阶段的待办事项非常好：按季度，每月，每周，细分为：紧急和次要…

每日尖峰

最近在我的工作（蓝瓶咖啡）中，我一直在为各种项目和想法做一些“准备工作”。如果您不熟悉，“秒杀”是一个敏捷术语，它的意思是实质上就某个主题进行简短的研究会议，而没有期望随后再发布任何内容。 “可交付成果”通常只是知识（尽管有时知识可以打包成报表。如果您不在敏捷工作流程之内，这听起来可能很愚蠢，但是在该工作流程之内，您通常会根据可交付成果来管理时间。我发现自己想做很多事情（因此需要写这篇微博），但是我也遭受了分析瘫痪的困扰，或者是无法开始做任何事情，因为我花了很多时间思考如何工作上。对于互联网上的每个想法，其中1/3都是关于如何提高效率和生产力的，所以这里还有一个。想法：我想每天计划第二天的30分钟高峰。由于这种通用性，它可以是“读取XXX”。但是它强调规划研究（部分受此启发）轻松获胜（可实现的小目标）我个人使用Forest来完成许多专注任务和装箱等工作，但这根本没有必要。鸡蛋计时器也可以。无论我身在何处或拥有什么资源，这个目标似乎都是可以实现的。我将尝试一个星期，如果您尝试一下，请告诉我！

你有力量！

障碍物全在您的脑海中。粉碎它们。如果您正在阅读本文，我想您是某种软件开发人员。程序员，工程师。一个编码器。是什么让您想成为其中之一？对我而言，这是我可以使计算机做我想做的任何事情的想法。我想这可能是其他人的类似原因。在我们的数字领域中，我们是无所不能的超级翻转神。但这是有趣的事情：有时候我认为我们忘记了这一点。您是否曾说过类似的话： “该功能尚未完成，因为我正在等待另一个团队完成其API”？那该怎么办： “我们无法发布此功能，因为我们已经合并了另一个功能，而由于前端团队还没有完成他们的任务，所以还没有准备好，所以我们只需要等待”？强大的翻转超级神灵？发生了什么？ API未完成？编码存根。…

查看您的Sprint评论

Sprint评论是我绝对喜欢的Scrum实践。为什么？从生产率的角度来看，它是主要的反馈机制。从健康的角度来看，这是将爱带给您的敏捷团队的机制。什么是Sprint评论（或Sprint演示）？在每个sprint的结尾，团队都会证明Sprint Planning承诺的工作已经完成。这使产品负责人有机会在投入太多时间之前说“不是我想要的东西”或“那正是我想要的东西”。无论您是否敏捷，这里都有一些Sprint评论的巨大优势！与您的产品负责人/客户建立信任。通过在工作完成时建立完全的透明度，您将建立与客户的信任。您可能需要重新组织计划，以便您交付有价值的数据块，而不是建立基础并放在顶层。低信任度团队发现透明的想法违反直觉。我听到他们说“我们的客户不在乎，他们只是想做到这一点。”正如我所听到的许多次说法，每次都被证明是错误的。他们发现，它建立了真正的合作伙伴关系，并且客户对这项工作表示赞赏。让行动者大放异彩。在大型公司中，幕后工作人员很少看到他们的工作受到赞赏。当我看到程序员在演示自己的工作时喜出望外时，Sprint评论让我眼泪汪汪。…

敏捷评估的秘密。

方法在敏捷估计中，斐波那契数列（1、2、3、5、8、13、21）用于故事指点。该量表在敏捷中被广泛使用，因为它不仅可以反映工作量，还可以反映风险和不确定性。例如，当一个故事得到13分时，它可能需要进一步修饰和/或需要分解成较小的故事。尽管尝试将故事点与实际时间关联起来比较容易（即在4天之内完成3个故事点的故事），但我们应该记住，并非总是如此。具有较高分数的故事表明涉及较高风险元素，例如不熟悉代码库，要使用的功能或技术，或者仅仅是因为与其他团队成员存在相互依赖性。例如，让我们比较一个错误修复程序，我们认为它很棘手，因为我们不知道根本原因，或者开发人员是那部分代码的新手，这意味着需要时间进行调查，而另一个故事还涉及一个小尺寸功能，一个三点式的故事，一个功能要求明确并且开发人员熟悉代码库等。我们应该期望构建这个小功能将花费更长的时间，但是确定性更强，并且错误修复的风险更小。但是，通过将漏洞修复仍指向三个，团队中的每个人（包括利益相关者）都可以了解根据故事要点解决漏洞修复的确定性。同时，故事点可以用作参数，以根据团队的速度来预测积压工作中可能需要多少冲刺。例如，如果一个团队每个冲刺能够完成15个故事点，而积压中的剩余故事点总计为60分，则产品所有者和项目经理可以推断出要完成该工作将需要4个冲刺。故事点比例表。比例示例以下是故事情节量表的一些示例。故事点 1个这是一个费力而又复杂的故事。它的范围可能从文档任务到例如在应用程序的两个屏幕中更改副本或颜色。我们不仅应该负责开发工作，而且还要负责构建和分发以及质量保证。…