大多数Scrum团队遇到的挫败感是什么?

2019-03-05
阅读 5 分钟
2.6k
7月7日,Scrum社区聚集在阿姆斯特丹(荷兰)参加第5届Scrum Day Europe。目标是从Scrum社区生成见解并定义Scrum框架的改进。 白天我们要求大家回答5个问题: 在过去的20年里,Scrum的实力已被证明是什么? 未来20年Scrum应该关注什么? 到目前为止,Scrum最让你感到沮丧的是什么? 什么连接你到Scrum? 什么是可以添加到...

Scrum Master 如何做一个仆人领袖?

2019-02-22
阅读 4 分钟
3.9k
虽然仆人式领导的观念是一个至少可以追溯到两千年的永恒概念,但现代仆人式领导运动是由Robert K. Greenleaf于1970年发表的,当时他发表了他的权威文章“仆人作为领袖”,他创造了这些文字。“仆人式领袖”和“仆人式领导”。

Scrum - 指导原则

2019-02-22
阅读 3 分钟
1.8k
例如,Product Backlog细化消耗不超过团队容量的10%。容量是小时数,故事点数还是天数?嗯,没有规则。Scrum团队自我组织并选择最适合他们背景的东西; 遵循我们消耗的指导方针,不超过团队容量的10%。

User Stories - 最佳实践 (Best Practices)

2019-02-18
阅读 2 分钟
2.7k
在转向敏捷之后,很多团队开始使用“用户故事”一词。用户故事是一种简单而优雅的技术,可以收集客户需求。然而,它需要一定的理解和实践才能用User Stories构建出色的软件。

用户案例 - 3Cs

2019-02-18
阅读 2 分钟
2.6k
第一个C (Card) 是原始形式的用户故事,即卡片。用户故事手动写在索引“卡”上,以保持简洁。标准格式有3个基本组件:作为[用户类型],我想/需要[目标],以便我可以完成[理由/商业价值]。该卡只是一个占位符。

Scrum:为什么Sprint长度应该短?

2019-02-15
阅读 2 分钟
3.2k
短Sprint的优势来自于尝试某些事情(快速失败),获得快速反馈,然后快速检查和调整的策略。在存在高度不确定性的情况下,开始研究产品通常会更便宜,了解我们是否做出了一个好的决定,如果没有,在花更多的钱之前快速杀死它。

为什么 scrum 开发人员是一个 T-形的人 ?

2019-02-15
阅读 2 分钟
2.3k
一个T-型的人有两种特性的,因此使用字母“T”来形容他们。字母“T”的垂直笔划描述了他们所具有的特定领域的深层技能,而水平笔划描述了跨多个学科的协作处置。它由两件事组成,即对其他人的学科的同理心和热情,以至于他们可能真正开始练习它们。只熟悉某个特定领域的人称为I形人。下图解释了I形人和T形人之间的差异。

极限编程 (Extreme Programming) - 发布计划 (Release Planning)

2019-02-13
阅读 1 分钟
2.8k
编写用户故事后,您可以使用发布计划会议来创建发布计划。发布计划指定 将为每个系统版本实现哪些用户故事以及这些版本的日期。这给出了一组用户故事供客户在迭代计划会议期间进行选择,以便在下一次迭代期间实施。然后将这些选定的故事翻译成单独的编程任务,以在迭代期间实现以完成故事。

极限编程 (Extreme Programming) - 迭代计划 (Iterative Planning)

2019-02-13
阅读 1 分钟
2.9k
在每次迭代开始时调用迭代计划会议,以生成该迭代的编程任务计划。每次迭代为1到3周。 客户从发布计划中按照对客户最有价值的顺序选择用户故事进行此次迭代。还选择了要修复的失败验收测试。客户选择的用户故事的估计总计达到上次迭代的项目速度。

极限编程 (Extreme Programming) 和用户故事 (User Stories) 的关系

2019-02-13
阅读 1 分钟
3.6k
用户故事与用例具有相同的用途,但不尽相同。它们用于为发布计划会议创建时间估计。它们也用于代替大型需求文档。用户故事由客户编写,作为系统需要为他们执行的操作。它们与使用场景类似,不同之处在于它们不限于描述用户界面。它们的格式为客户在客户术语中编写的大约三个句子,没有技术语法。

敏捷开发: 超级易用水桶估计系统

2019-02-13
阅读 2 分钟
1.5k
“水桶估计系统”是一种用中小型人群估计大量物品的方法,并且可以快速完成。水桶估计系统具有以下特性,使其特别适用于敏捷环境: 它 很快!可以在一小时内估算几百件物品。 这是 合作的。一组中的每个人大致平等地参与。 它提供 相对结果而不是绝对估计(点数与小时数)。 结果无法追溯到个人,因此它鼓励 小组负责。 与...

SPIDR - 完美分割用户故事的五种简单技巧

2019-02-12
阅读 2 分钟
3.9k
根据INVEST原则,对用户故事的要求是它必须“足够小”或具有合适的大小。用户故事应该足够小,可以在冲刺中完成6-10个。当然这也取决于开发团队的速度。为了原则上实现这一目标,必须相应地分割大型故事。在下文中,我想向您介绍Mike Cohn的简单快速的SPIDR方法。他总结了五种技术,几乎每个大型用户故事都可以分为几种。

权威指南: 如何写好用户故事?

2019-02-12
阅读 2 分钟
5.1k
在这篇文章中,我们将介绍如何编写好的用户故事以及应该包含哪些内容。 用户故事代表一小部分功能,具有团队可以在冲刺中提供的业务价值。用户故事和传统需求文档之间的区别在于详细程度。 需求文档往往包含大量文本并且非常详细,而用户故事主要基于会话。 我们可以将用户故事的结构分解为: 需要的简要说明 在积压修饰...

介紹敏捷方法: Scrum, Kanban or Lean?

2019-02-11
阅读 5 分钟
6.3k
構建服務時可以使用許多敏捷方法,每種方法都有自己的一套工具和技術。 本指南介紹了3種最流行的敏捷方法: Scrum 看板 Lean 流行的敏捷方法解釋了 Scrum Scrum是最常用的敏捷方法。 它允許高度結構化的模型具有明確定義的角色和職責。這對於正在轉向敏捷的傳統結構化組織尤其有用。 在Scrum指南中了解有關Scrum功能的更...

Scrum: 什么是经验主义 (Empiricism)?

2019-02-08
阅读 1 分钟
3.2k
产品所有者根据所有当前信息计划发布。他或她列出了目标、实现这些目标的特性和能力,以及可能的成本和交付日期。从那时起,产品所有者的工作就是评估考虑到团队的能力,什么是可能的,并做出最佳决策来达到期望的目标。考虑到技术、市场、需求和人员的性质,进行权衡。有时目标无法以合理的价格实现。有时目标会实现,...

什么是Scrum的增量?

2019-02-08
阅读 1 分钟
7.8k
如Scrum指南中所述,Increment是Sprint期间完成的所有Product Backlog项目的总和,以及所有先前Sprint的增量值。在Sprint结束时,新增量必须是“完成”,这意味着它必须处于可用状态并符合Scrum团队对“完成”的定义。增量是一个可检查的“完成”工作,支持经验主义在Sprint结束时。增量是迈向愿景或目标的一步。无论产品负责...

Scrum: 伟大的发展团队的25个特征

2019-02-08
阅读 3 分钟
2.7k
一个Scrum的团队是个人(通常为5至9个成员之间的)合作,以提供所需的产品增量的集合。Scrum框架鼓励团队成员之间进行高层次的沟通,以便团队能够: 遵循共同的目标 遵守相同的规范和规则 相互尊重 Scrum团队的结构 Scrum团队。Scrum团队包括: 产品拥有者 Scrum Master,和 开发团队 什么是Scrum团队 Scrum团队分享与产...

Scrum: 开发团队的发展阶段

2019-02-08
阅读 3 分钟
1.8k
所有新团队都以团队形式开始。在这个早期阶段,人们正在寻求稳定,休息和对集团的归属感。 团队成员仍在发现彼此以及他们在团队中的位置。因此,他们有一种观望态度,并没有表现出真正的自我。 团队成员主要关注自己并致力于实现个人目标。该小组中的每个独立个人都有自己的标准。这些个人的个人标准决定了人们是否互相...

如何组织 Sprint Retrospective?

2019-02-08
阅读 2 分钟
4.7k
如Scrum指南中所述,Sprint Retrospective是Scrum团队检查自身并创建在下一个Sprint期间制定的改进计划的机会。Sprint回顾是在Sprint Review之后和下一个Sprint Planning之前发生的。这至少是为期一个月的Sprint的三小时会议。对于较短的Sprint,事件通常较短。在Scrum Master的保证事件发生和服务员了解它的用途。这是S...

敏捷 - #12 原则:持续改进 ( #12 Agile - Principle)

2019-02-04
阅读 1 分钟
3.1k
“团队定期反思如何提高效率,然后相应地调整和调整其行为。” “At regular intervals, the team reflectson how to become more effective, then tunes and adjusts its behavior accordingly.”

敏捷 - #11 原则:自组织团队 ( #11 Agile - Principle)

2019-02-04
阅读 1 分钟
2k
“最佳架构、需求和设计来自自组织团队。” “The best architectures, requirements, anddesigns emerge from self-organizing teams.”

敏捷 - #10 原则:简单是必不可少的 ( #10 Agile - Principle)

2019-02-04
阅读 1 分钟
3.9k
“简单——最大化未完成工作量的艺术至关重要。” “Simplicity—the art of maximizing the amountof work not done—is essential.”

敏捷 - #9 原则:持续关注卓越的技术和良好的设计 ( #9 Agile - Principle)

2019-02-04
阅读 1 分钟
2k
“持续关注卓越的技术和良好的设计提高了灵活性。” “Continuous attention to technical excellence and good design enhances agility.”

敏捷 - #8 原则:促进可持续发展 ( #8 Agile - Principle)

2019-02-04
阅读 1 分钟
1.7k
“敏捷过程促进可持续发展。赞助商、开发人员和用户应该能够独立地保持恒定的速度。” Promote Sustainable Development

敏捷 - #7 原则:工作软件是进度的主要衡量标准 ( #7 Agile - Principle)

2019-02-04
阅读 1 分钟
2.3k
“工作软件是进度的主要衡量标准。” “Working software is the primary measure of progress.”

敏捷 - #6 原则:面对面交谈 ( #6 Agile - Principle)

2019-02-04
阅读 1 分钟
3k
“向项目团队传递信息的最有效方法是面对面交谈。” “The most efficient and effective method of conveying information to and within a project team is face-to-face conversation.”

敏捷 - #5 原则:围绕积极性高的个人去构建项目 ( #5 Agile - Principle)

2019-02-04
阅读 1 分钟
1.8k
“围绕有动机的个人构建项目。为他们提供所需的环境和支持,并相信他们能够完成工作。” “Build projects around motivated individuals. Give them the environment and support they> need, and trust them to get the job done.”

敏捷 - #4 原则:業務人員和開發人員必須攜手合作 ( #4 Agile - Principle)

2019-02-04
阅读 1 分钟
1.3k
"在整個專案過程中, 業務人員和開發人員必須每天一起工作。" Business People and Developers MustWork Together

敏捷 - #3 原则:经常提供工作软件 ( #3 Agile - Principle)

2019-02-04
阅读 1 分钟
1.4k
所有敏捷开发过程(如scrum)都基于持续改进。我们希望团队采用一种经验的方法 (empirical approach) 来了解随着项目的进展,哪些是可行的,哪些是不可行的,并在必要时进行调整,而不是采用一个永不改变的严格定义的过程 (defined process)。如果将项目分解为很短的增量 (increments),并且在每个增量结束时进行学习,...

敏捷 - #2 原则:欢迎更改要求 ( #2 Agile - Principle)

2019-02-01
阅读 1 分钟
2.6k
“欢迎不断变化的需求,即使是在开发后期。敏捷流程利用变化来获得客户的竞争优势。” “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”