敏捷— Scrum入门

作为软件开发人员,您当然知道Scrum。 您可能已经使用过Scrum或仅听说过它。 在本文中,我想向您概述什么是Scrum以及如何应用这种方法。 加:即使是单独或以小组形式进行副项目,您也可以使用许多原则。 Scrum可能是敏捷软件开发中最著名的流程模型。 它是用于管理项目的定义和工具的集合。 Scrum不是一个刚性的结构,而是一个灵活的工具箱。 Scrum项目团队由三方组成:产品所有者,负责确定下一个sprint(即下一个迭代)中要开发的内容;开发团队本身,负责结果的实现和呈现,以及Scrum。主人,保证项目的顺利进行。 Scrum专为小型,自组织的团队而设计。 如前所述,根据Scrum的项目实现由几个迭代组成,即所谓的sprint。 冲刺通常持续一到四个星期,用于从产品待办事项列表(项目的所有需求)中对选定的用户故事(从用户角度制定的公式化系统需求)进行优先级排序,然后将这些选择转移到sprint待办事项中(集合)当前冲刺中的处理要求)并予以实施。 需求的优先级排序和选择称为Sprint计划。 尽管需求是由产品所有者设置的,但在计划阶段已与团队达成了一致。 这应确保计划的要求也切实可行。 在冲刺期间,每日Scrum每天举行一次简短的会议,讨论当前状态并阐明可能的问题。 冲刺完成后,进行冲刺审核,团队与产品负责人一起验证各种要求并检查其实现情况。 接下来是Sprint回顾,Scrum团队在其中讨论与Scrum Master的合作并提出改进建议。…

当前的现实树

今年,在苏格兰精益敏捷组织上,我参加了有关构建当前现实树的研讨会,这是约束理论中的思考过程。 该技术有点像“ 5个为什么”,但结构更多。 它旨在帮助您发现和理解所有不同问题之间的关系,并确保您解决了正确的问题。 在复杂的系统中,实际问题并不总是很明显,而通过“解决”明显的问题,实际问题仍然存在,并继续引起问题。 基础 当前的现实树结构相当简单,在树的顶部具有“不良影响”(UDE),在树的下方具有中间效应,在树的底部具有根本原因。 基本上,您要建立因果链,直到找到根本原因。 如果需要发生两个(或更多个)事物以产生效果,则可以使用椭圆将它们链接起来。 然后,您将精力集中在解决根本原因而不是中间影响上。 简化树的示例如下所示。 怎么做 第一步是同意您要解决的问题的范围。 在继续创建宇宙之前,继续进行原因非常容易,但这并不是特别有用,您不能为此做很多事情! 他们的关键是要回到足够远的地方,但不要停得太早。 从可以控制的事物和可以影响的事物的角度来思考它。 下一步是集思广益,找出所有不良影响,然后确定它们之间的关系,注意逻辑上的飞跃,并绘制不相关的事物之间的因果关系。 在执行此操作时,您还应该考虑涉及哪些人,您需要足够的人员来发表各种意见,但不要太多,建议您从一个小组开始起草初稿,然后扩展讨论范围。通过更多的人来进行调整,并根据需要进行调整。…

产品刺身好吃!

2010年10月2日,星期六,我与JB Rainsberger和Bonnie Aumann一起参加了“生鱼片”工作坊。 这次研讨会的目的是学习如何“薄薄地切片产品”,以便您实际上可以快速交付有价值的东西。 我们还花了很多时间来研究如何将模糊的客户产品构想变成可以开始使用的具体东西。 我这样总结给我的团队:您的客户进来了,他们通常要求鲸鱼。 在项目结束时,他们真正想要的是一只螃蟹。 您的工作是从他们的鲸鱼请求开始 将鲸鱼切成他们真正想要/需要的肉质部分, 将肉的部分切成薄片,以便您实际上可以开始开发并很快提供价值。 我碰巧在一个学术环境中工作,在这个环境中,我的客户是对软件和工具有想法的同事,这些想法将有助于他们的研究或在内部用于员工。 每个项目实际上都没有钱易手,但是我的团队是一个稀缺资源,我们有很多项目要处理,远远超过我们实际可以交付的数量。 这与我担任顾问的时候并没有什么不同,当时我是一位付费客户,他们需要以最小的成本获得最大的解决方案,而他们昨天才需要。 您始终希望尽快实现价值,这意味着将问题细化,并且要确保您知道自己首先在做最有价值的事情,这意味着了解他们的业务和他们的需求。 最大的挑战是了解客户的要求。 很多时候,他们很难用语言表达出来。 有时他们可以描述他们正在寻找的解决方案,但是与他们描述的问题不符。 作为知识渊博的技术资源,我们立即希望了解他们想要的东西,因此我们的第一个问题是“您为什么想要那个?”…

精益持续交付管道的要素

想要连续交付生产吗? 每个博客都错过了重要的一步…… 连续交付是一种软件实践,使您能够以小幅,快速的增量将软件提供给客户。 它是精益方法和某种程度上敏捷方法(快速而不是连续的敏捷方法)的核心部分。 这样做有很多好处,但绝对不是万灵丹。 那么,持续交付流程的哪些阶段以及我们如何管理它们? 大多数代码都需要以某种方式进行构建或打包,我们甚至以某种方式使“非编译”代码(例如javascript)都需要复杂而明智的构建要求。 为此,我们使用持续集成工具。 在featureflow上,我们使用circleci,我们认为它很棒–还有其他托管选项,例如代码集–我建议您是否可以使用托管然后再使用。 如果您的公司坚持或要求内部运行,那么詹金斯就是最流行的老马。 出现它们的主要原因是在将代码签入源代码控件时生成代码。 尽可能保持简单,如果您运行托管的CI,那么您的devops家伙就不会失业。 他们只会做得更好! 这可能需要一个帖子和一个书。 但是前提是–使用上述工具来运行两个测试套件。 单元测试按功能单元划分,它们是独立的,完全可重复的,并且不需要后端或外部集成。 然后是集成测试–这些测试通常结合了一些服务。 如果您需要一条完整的CD流水线,那么建议您在一个完整的构建拆解环境中进行投资-例如,由Docker组成的托管服务集和数据库可用于运行一组测试。…