近两年，随着容器、Kubernetes 等技术的兴起，DevOps 这个概念被广泛提及并被大量使用。本文将会从DevOps的产生、DevOps 与容器/Kubernetes 之间的关系、DevOps 的技术实现方式几个方面，结合实验展现的方式，让读者
【摘要】到底该选择Monolith还是Microservices呢？业界没有一个统一标准的答案，本文通过分析比较Monolith和Microservices的优缺点，给出了在哪些情况下，建议选择Mon
作者 | Adrien Joly 译者 | 平川 策划 | 丁晓昀 将单体拆分成服务会带来维护多个存储库（每个服务一个存储库）的复杂性，每个存储库都有独立（但相互依赖）的构建流程和版本控制历史。Monorepo 已经成为一种降低复杂性的流行解决方案。 尽管 Monorepo 工具开发商有时会提供建议，但在现有代码库中配置 Monorepo 并不容易，尤其是单体代码库。更重要的是，迁移到 Monorepo 可能会给代码库开发团队带来巨大影响。例如，需要将大多数文件移动到子目录中，这会与团队当前正在进
本文比较了微服务和模块化整体架构(modularized monolith )的区别。现在大家一股脑从整体单片monolith迁移到微服务，但是这种转变真的适合你公司吗?整体单片monolith确实有
Monolith、SOA、DDD、The two-pizza rule、分库分表这些概念跟微服务有啥关系，你知道吗？这篇文章记录我的理解，分享给大家。
当承诺（Commitment）、专注(Focus)、开放(Openness)、尊重(Respect)、和勇气（Courage五大价值观为 Scrum 团队所践行与内化时，Scrum 的透明、检视和适应三大支柱成为现实，并且在每个人之间构建信任。Scrum 团队成员通过Scrum 的角色、事件和工件来学习和探索这些价值观。Scrum 的成功应用取决于人们变得更为精通践行五项价值观。人们致力于实现 Scrum 团队的目标。Scrum 团队成员有勇气去做正确的事并处理那些棘手的问题。每个人专注于Sprint 工作和 Scrum 团队的目标。Scrum 团队及其利益攸关者同意将所有工作和执行工作上的挑战进行公开。Scrum 团队成员相互尊重，彼此是有能力和独立的人。
1. 请简述一下什么是敏捷开发（Agile Development），以及什么是持续集成。 敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。、 持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的
在软件领域， Agile和Scrum一直是比较热的词汇，包括很多企业已经实践了敏捷很多年，但是实施效果一直不是很理想。那我们今天在谈论如何实施Scrum之前，我们先确认一下，您的企业真的需要Scrum吗？
团队在践行敏捷的过程中，会有多种选择：Scrum、XP、Kanban、Crystal、精益生产、规模化敏捷等，其中最流行的敏捷开发方法当属Scrum。正因如此，大部分人对其产生了刻板印象： 认为敏捷就是Scrum，实施敏捷就是套用Scrum方法。
导读：本文的目的是分享有关Scrum Agile框架中软件测试活动的想法。本文分为两个主要部分。第一部分着重于解释Scrum方法，谁是参与者，计划如何转化为行动，关键仪式以及Scrum冲刺中会发生什么。在第二部分中，我描述了Scrum方法论中遵循的软件测试过程，以及如何将其集成到Scrum sprint中。
伴随着Scrum的实施，你若想取得长久的成功，需要的可不只是基础的框架。Scrum是故意这么设计的，它提供了框架结构作为起点，而它生来就能与其他的有效模式组合应用。 就像20世纪90年代晚期倡导的设
Scrum Master敏捷教练，简称SM(不要想歪了)。PO是build the right thing,而SM则是build the thing right。很多人把PO对应上传统项目中的产品经理，SM对应传统项目的项目经理。他们有相同之处，更多的是不同之处。
现在公司在使用敏捷开发模式进行日常的开发和管理工作，所以我看了下Ken Schwaber的《Scrum Guide》这本小册子，原本是英文的，这里提供中文的，以供日后复习和参考。
https://trailhead.salesforce.com/content/learn/modules/salesforce-agile-basics
Scrum 使用固定的时间来产生规律性，以此来减少Scrum之外的其它会议的必要性。所有时间都是有时间盒限定的时间，也就是说每一个时间限制在最长的时间范围内。一旦Sprint开始，它的持续时间是固定的，不能缩短或是延长。而其他时间则可以在该事件的目标达成之后可以立刻终止，如此确保时间被适当地使用而不会造成过程中的浪费。
关于敏捷开发的问题，被提及最多的便是关于团队和人员的问题。定义里会告诉你：Scrum 团队是自组织、跨职能的完整团队。那么究竟怎样的团队才是自组织的团队，什么样的分工算是跨职能？我们将在本文中为您详细介绍。
Scrum是由Ken Schwaber 和Jeff Sutherland在1990年创建的主流敏捷技术。进入新世纪，互联网带来的巨变使敏捷方法受到了更多开发团队的青睐，而且中Scrum以其扩展性、门槛低、名字和术语更容易被项目经理接受等原因，逐渐成为最受欢迎的敏捷流派，超过50%以上的项目在运用这项方法。与其说Scrum是一种方法，不如将其称之为一个框架更为贴切，在此框架中人们可以解决复杂的自适应难题，同时也能高效并创造性地交付可能最高价值的产品。自上世纪90年代以来，它就已经被用于管理复杂产品的工作上。Scrum并不是一种过程、技术或者决定性方法。倒不如说它是一个框架，在此框架中，我们可以使用各种不同的过程和技术。Scrum让我们的产品管理和工作技术的相对成效更加清晰地显现出来，以便我们可以持续改进产品，团队和工作环境。
作者 | Alaa Tadmori 译者 | 明知山 策划 | 丁晓昀 注：本文纯属个人观点，不代表我的公司。谨将本文献给我的导师 Marcel May。 我并不是故意要把 POC 和 Scrum 与低质量的软件联系在一起，它们的流行确实令人生畏，但我们应该客观地考虑构建高质量软件涉及的所有因素。准确地说，POC 和 Scrum 并没有本质上的缺陷会导致它们成为低质量软件的促成因素，但经常会产生导致低质量软件的副作用。 虽然它们不是唯一的因素，但正是因为它们本身并没有缺陷，当我们意识到它们的副
最近小 G 在各大平台分享了一些蛮优质的开源项目，其中一部分来自于水友自荐，今天刚好周五，借此机会跟大家简单汇总一下，希望大家喜欢。
Scrum是一个用于开发和维护复杂产品的框架，是一个增量的、迭代的开发过程。迭代是贯穿敏捷管理的一个特有概念，Sprint是冲刺跑的意思，在敏捷里指的是一次迭代，而一次迭代的周期一般是2~4周，也就是要把一次迭代的开发内容以最快的速度完成它，这个过程我们称为迭代。Scrum团队试图在每一个迭代中都构建出一个潜在可交付、并且充分测试过的产品增量。
软件工程是一个非常复杂的过程。在软件开发阶段要遵循不同的软件开发生命周期模型来指定和设计。这些模型也称为软件开发生命周期（SDLC）模型/方法。每个过程模型都遵循其类型所独有的一系列阶段，以确保软件开发步骤中的成功。
导语 | Monorepo是一个“单仓多包”的代码管理策略，由于众多大型厂商和开源项目在其上的实践，Monorepo受到了越来越多的关注，和其他已有的代码库管理方案相比，有着自身独特的优势。本文仅讨论Monorepo在前端开发场景中的应用及实践，里面提到的概念和示例都会有所局限，可依据实际情况自行扩展阅读其他资料。 “代码（code）” 是程序员用开发工具所支持的语言写出来的源文件，用于实现或支持所有依托于计算机的程序及应用，因此，如何管理代码是开发人员在项目进程中非常重要的一环。 而“仓库（reposit
1. Scrum是经验型方法，是”可能性的艺术“ 2. Scrum使得所有事项充分可见，使“秘密交易”最小化 3. Scrum的运作基础是个人和团队的承诺，而非严密的规划及控制。相对于强行控制计划，其忠诚度、自组织和员工责任感是更为有效的机制 4. 团队成员只有事先集体负责，承诺在固定时间内交付实际产品后，才算真正掌握Scrum
敏捷开发所倡导的是通过若干个短期的迭代周期（也称为冲刺sprint，范围一般是1周- 1个月），按一定的优先级不断增量开发和实现产品功能，每次迭代获得一个可运行的产品增量功能包。
例2 场景：你选择了使用三个小团队的方式。不过观察一下sprint中的交流方式，你就会发现团队1和团队2一直在交流，而团队3比较孤立 解决办法：如果团队1和团队2在整个sprint中一直聊来聊去（把团队3扔在一边），在下个sprint中你大概就得把团队1和2合并到一块。如果在sprint的前半阶段，团队1和团队2一直交流，然后在后半阶段，团队1和团队3又相谈甚欢，那合并或者保持原样就都是可行的。你可以在sprint回顾会议上提出这个问题，让团队自己决定
敏捷开发很早就已经流行过了，之前也零碎地了解了一些相关知识，并在团队中进行了部分实践，但效果都不怎么好。最近又重新梳理了一遍，并结合现状，准备在团队中重新实践敏捷。
项目管理是大家非常关注的话题。最近，总能得到一些不错的内幕消息的 Gergely 做了一项调查，探寻科技巨头们是怎么运营技术项目的，涉及了 100 多家科技企业，他意外地发现 Scrum 在大多数大型科技企业里“奇怪”地缺席了。
“敏捷方法”是一个囊括了各种框架和方法的涵盖性术语，它指的是符合《敏捷宣言》价值观和原则的任何方法、技术、框架、手段或实践。
什么是敏捷开发 敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。 在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
每周五都是总结的时候，不过这次因为五一假期，所以有了些调整，在周三的阿里认证后回顾公开课要到8号了。由于VIP的课程这次讲的东西比较多，所以也配合的拆成了两段，Scrum和用户故事。
Product Owner：主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。
作者 | Gergely Orosz 翻译 | 核子可乐 策划 | Tina 项目管理是大家非常关注的话题。最近，总能得到一些不错的内幕消息的 Gergely 做了一项调查，探寻科技巨头们是怎么运营技术项目的，涉及了 100 多家科技企业，他意外地发现 Scrum 在大多数大型科技企业里“奇怪”地缺席了。 Scrum 是一个轻量级项目管理框架，它将团队化繁为简，分为产品负责人、Scrum Master 和开发团队三种角色，同时强调产品梳理会、迭代计划会、每日站会、迭代评审会、迭代回顾会。在过去十多
接触过敏捷的我们，一定对Scrum都不陌生，Scrum是众多轻量级敏捷框架中应用最广泛的一种。
Scrum 使用固定的事件来产生规律性，以此来减少 Scrum 之外的其他会议的必要。所有事件都是有时间盒限定的事件，也就是说每一个事件限制在最长的时间范围内。
第14章 我们怎样做测试 这是最困难的部分 你大概没法取消验收测试阶段 理想化的Scrum世界中，每个sprint最终会产生一个可部署的系统版本 很恶心的bug会因此出现。如果质量对你来说还算重要，你
*****三个角色，三个工件，四个流程（五个事件），四大支柱，五大价值观*****
在过去的五年时间里，我所在的公司和团队一直使用的都是敏捷开发模式，我也在2018年底获取了Scrum联盟的CSM认证，对于敏捷的理解也是从最初的感性认识到现在的理性认识。今天开始和你一起重新温习敏捷，先来正确理解一下敏捷吧。
《敏捷宣言》发布后，“敏捷”被越来越多的小型开发团队认可。与此同时，另一个问题也逐渐暴露了出来：以 Scrum 为首的敏捷方法论对那些大规模的开发团队并不友好。
Scrum 是一个轻量级框架，可帮助人员、团队和组织通过针对复杂问题的自适应解决方案创造价值。
编译 | 明知山、Tina Ruby on Rails 之父：“即使是亚马逊也无法理解无服务器或微服务。” 来自亚马逊 Prime Video 团队的一个案例研究在开发者社区中掀起了轩然大波。 在该案例中，Prime Video 团队将一个监控系统从微服务架构迁移到单体架构，并避免使用昂贵的服务（如 AWS Step Functions 和 Lambda 无服务器函数），并对此举所带来的降本效果进行了评估。 他们的需求是使用一个监控工具来识别“用户查看的视频流”的质量问题，因为有“成千上万个并发流”，
相信通过前面一篇文章的介绍，你已经对 Scrum 有了一定的了解了。但是这玩意怎么用呢？XP 的实践如果是做过软件开发的同学，或者是带过软件开发团队的同学一定或多或少的都接触过，至少也是听说过。但就像上篇文章说过的，XP 很偏重于具体的软件开发实践，而 Scrum 则更全面地渗透到管理层面，更加的宽广包容一些。还记得上篇文章中最后的那个 Scrum 过程图吗？
Scrum 当中有三个角色：PO（product owner），敏捷教练（scrum master）和开发团队。虽然这看起来很清晰，但如何处理现有职位的问题可能会让人感到困惑。许多团队询问在采用 scrum 时是否需要更改岗位名称？最简洁的答案是“不”。在本文中，我们将讨论 scrum 的角色定义以及如何将它们融进你的组织中，而你无需打印新的岗位名片。
Scrum 当中有三个角色：PO（product owner），敏捷教练（Scrum master）和开发团队。虽然这看起来很清晰，但如何处理现有职位的问题可能会让人感到困惑。许多团队询问在采用 Scrum 时是否需要更改岗位名称？最简洁的答案是“不”。在本文中，我们将讨论 Scrum 的角色定义以及如何将它们融进你的组织中，而你无需打印新的岗位名片。
其实本来最近想写一些别的内容的，不过疫情当前我们就介绍一点医疗相关的。“紧接着”去年的这篇种草文，介绍一下这个案例。我们之前整理的一些基础概念翻译可以看这里。
敏捷者希望开发高质量和高价值的软件，而开发高价值软件最简单的方法就是首先实现最高优先级的需求。这使他们能够最大化涉众的ROI。因为需求经常变化，您需要一个精简的、灵活的方法来进行需求变更管理:简而言之，敏捷者努力真正地管理变更，而不是阻止变更。这一做法有三个版本:
这次我们来聊聊“正确的做事”。现在大家都在聊敏捷，虽然都遵循着敏捷的基本理论和价值观，但外在的实践形式不尽相同。有人的地方就有江湖，江湖的一大特色就是流派众多，敏捷实践也例外，KANBAN、Scrum、XP、Lean（精益）、DSDM（动态系统开发方法）、FDD（特征驱动开发）等等百花齐放。团队在落地实践这些敏捷内容时，表现也各不相同。有的只是蹭概念，有的把大瀑布变成了小瀑布。也有的团队做得很好，真的把DevOps实践出自己的道路来，进而提升了团队效率。如何识别自己团队的是否真的在往这方面在走呢？
我在Scrum培训课程中听到的一个常见问题是，“我们应该做多少Product Backlog，在Product Backlog中应该包含多少细节?” 首先，让我们看一下Scrum指南。 Product
软件工程是一门研究用工程化方法构建和维护有效的、实用的和高质量的软件的学科。它涉及程序设计语言、数据库、软件开发工具、系统平台、标准、设计模式等方面。
微服务其实就是服务化思路的一种最佳实践方向，遵循 SOA（面向服务的架构） 的思路。
在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
