最新 AgileDo根据活跃度持续更新CAP. 当前更新时间：2024 年 07 月 11 日
迭代管理
迭代增量开发
通过重复循环（迭代）和一次较小的部分（增量）来开发系统，从而使相关人员能够利用在系统的早期部分或版本的开发过程中得到反馈和优化技能。虽然迭代和增量开发一词在软件行业中兴起，但许多硬件和嵌入式软件开发工作都在使用迭代和增量技术。SpaceX 一直致力于将迭代设计实践引入航天工业，并将该技术应用于航天器、运载火箭、电子和航空电子设备以及运营飞行硬件操作
每日站会
团队每天在同一时间开会，以便为每个人提供对协调至关重要的最新信息：“正在做”、“已完成”和“遇到的障碍”。会议最长持续时间为15分钟，任何引发讨论的主题会被添加到“停车场(parking lot)”列表中，并在会议结束后进行更深入的讨论
燃尽图
表示剩余工作量的工作图表，由横轴（X）和纵轴（Y）组成，横轴表示时间，纵轴表示工作量。这种图表可以直观的预测何时工作将全部完成
任务板
最基本的形式是，任务板可以绘制在白板上，分为三列，分别标记为“待办事项”、“进行中”和“已完成”。用于记录任务的便签放置在反映任务当前状态的列中，一般在每日站会时更新状态
Kanban：看板
通过平衡需求与可用容量以及改进对系统级瓶颈的处理来管理工作。看板方法的两个最主要实践是可视化工作和限制在制品 (WIP)。看板源于精益开发，目前在纯软件开发、硬件开发和嵌入式开发都有非常多的应用
估算：计划扑克
团队在产品负责人在场的情况下开会。每个团队成员都拿着一套扑克牌，上面有适合用户故事点估计的数值。每个成员不受影响的独自估算并同时展示。如果有不一致的估值，对高估计值和低估计值的两个（或更多）团队成员的推理进行讨论后，团队可能会通过进行一轮或多轮估算来寻求达成共识
定期回顾
团队定期召开会议，通常遵循迭代的节奏，明确反思自上次会议以来发生的最重要的事件，并做出旨在补救或改进的决策。回顾促进项目团队在流程各个方面的所有权和责任感；参与者可以理解所有流程决策背后的基本原理
产品管理
Backlog：待办列表
在Scrum中，产品待办列表是一个排序的列表，包含所有产品需要的东西，也是产品需求变动的唯一来源。产品负责人负责产品待办事项列表的内容、可用性和优先级。规模化敏捷框架（SAFe）引入了一系列积压工作来取代产品积压工作，包括产品组合待办列表、解决方案待办列表、程序代办列表和团队待办列表
用户故事
从用户角度编写的任何业务需求的简要描述，最流行的格式如下：作为（系统的）用户，我想要（采取行动）以便（拥有此功能的好处）。好的用户故事遵循INVEST模型。INVEST 代表独立、可协商、有价值、可估计、小颗粒和可测试
3C:“卡片、对话、确认”
“卡片”：记录用户故事; “对话”：相关人员（客户、用户、开发人员、测试人员等）沟通用户故事。主要是口头的，但最常辅以文件； “确认”：沟通已经达成共识
Story Mapping：故事映射
故事映射是一种排列用户故事的方法，以二维方式排列：垂直方向表示优先级，而水平方向表示用户在系统中执行操作所采取的步骤。故事映射的主要作用包括：它描绘了产品如何使用的全貌；2）可以识别功能或需要关注的领域中的漏洞；3）确定优先级的绝佳工具，无论是对于 MVP还是后续版本
Story Splitting：故事拆分
在敏捷框架内，完成的工作通常基于用户故事。故事拆分的目的是可以在一个合理的时间内完成（例如一个冲刺内）。故事拆分是将单个用户故事分解为更小的故事的过程，同时保留每个用户故事单独具有可衡量的业务价值的属性
Give-When-Then
Give-When-Then 公式是一个模板，旨在指导用户故事的验收测试的编写，JBehave、RSpec、Cucumber 等工具鼓励使用此模板：
- 1.（给出）一些背景
- 2.（何时）执行某项操作
- 3.（然后）应该获得一组特定的可观察结果
MVP：Minimum Viable Product
最小可行产品（MVP）是精益创业的一个概念，强调学习在新产品开发中的影响。 Eric Ries 将 MVP 定义为新产品的版本，它允许团队以最少的努力收集最多经过验证的客户反馈。 这种经过验证的学习表现为客户是否会真正购买产品。
敏捷发布计划
敏捷中的发布计划是一份战略文档，概述了向客户发布产品功能或迭代的时间表。 与通常依赖于详细的长期规划的传统项目管理不同，敏捷发布计划具有灵活性和适应性，重点是及时有效地为客户提供价值。 该计划通常包括冲刺或迭代的时间表、要开发的关键功能以及表明重大进展或主要功能完成的里程碑。
敏捷团队
自组织
最好的架构、需求和设计来自自组织团队，敏捷开发强调围绕积极主动的个人构建项目。为他们提供所需的环境和支持，并相信他们能够完成工作。“自我管理”对团队的要求很高，团队需要具体的 Scrum 经验才能真正理解如何管理自己以及如何承担规划和开展自己活动的责任和权力。
跨职能
跨职能团队的成员都具备适当的技能组合，可以向客户交付可工作的产品增量。在 Scrum 中，这个概念转化为 Scrum 团队由“完成工作所需的所有能力，而不依赖于团队之外的其他人”组成
Team Room：团队室
敏捷的一个原则是：业务人员和开发人员必须在整个项目中每天一起工作，所以团队在项目期间会使用专用空间，与其他项目团队的活动分开。该空间配备了团队可能需要的各种便利设施：工作站、白板和活动挂图、用于显示任务板、项目计划或其他 图表的墙壁空间等
团队拆分
敏捷开发建议规模大的团队拆分为多个小型的团队，以保证沟通和交付的效率。”恰到好处“的团队规模是多少？Scrum建议不超过10人，QSM公司认为4-5人最佳，也有研究表明1-6-1（PO-Dev-Test）最佳。拆分团队时平衡团队之间的技能、重新定义既定的团队界面并仔细分解工作职责至关重要。意外的依赖关系和潜在的新瓶颈可能会出现并减慢交付速度
Scrum of Scrums
一种规模化敏捷技术，用于集成多个 Scrum 团队在同一项目上的工作。它允许团队相互沟通，以确保每个团队的软件输出与其他团队的输出良好集成，特别是在存在重叠或事件顺序很重要的领域。Jeff Sutherland定义的Scrum of Scrums是：负责在 Sprint 结束时将所有团队的工作软件交付到完成的定义
T型技能
“T型”：T的垂直部分代表主要、首选技能的深度，T的水平部分代表可以用来协作并完成团队工作的其他技能。拥有"T型"技能的成员，跨职能团队的工作效果最佳
内置质量
结对编程
两个程序员在一个计算机上共同工作。一个人输入代码，而另一个人审查他输入的每一行代码。输入代码的人称作驾驶员，审查代码的人称作观察员。两个程序员经常互换角色。结对编程可以降低15%到50%的缺陷率，并可以有效消除学习债务和技术债务
- 更多
- 处理技术债务的具体实践
单元测试
针对程序模块（软件设计的最小单位）来进行正确性检验的测试工作，目标是隔离程序部件并证明这些单个部件是正确的。单元测试允许程序员在未来重构代码，并且确保模块依然工作正确
持续集成
将所有软件工程师对于软件的工作副本持续集成到共享主线（mainline）的一种举措。实践持续集成的团队寻求两个目标：1）最大限度地减少每个集成阶段所需的持续时间和工作量；2）能够随时提供适合发布的产品版本
TDD：测试驱动开发
首先编写单元测试，然后编写仅足以通过这些测试的代码，最后重构新代码以满足代码标准。团队采用TDD要考虑以下因素：学习曲线、初期开发速度放缓、可能的过度设计和测试覆盖的盲点
代码重构
在不改变代码的外部行为情况下而修改源代码。重构既不修正错误，也不增加新的功能。它的目的是用于提高代码的可读性或者改变代码内部结构与设计或者删除死码，使其在将来更容易进行维护和开发。尽管代码重构一词最初只用于软件代码的重构，但近年来，硬件描述语言也出现了相应的代码重构的概念。硬件重构（hardware refactoring）是对硬件描述语言中的代码进行重构的简称。
BDD：行为驱动开发
鼓励软件项目中的开发者、QA和非技术人员或商业参与者之间的协作。行为驱动开发人员使用混合了领域中的统一语言来描述他们的代码目的。这让开发者得以把精力集中在代码应该怎么写，而不是具体的技术细节。主要的做法包括：1）使用例子来描述应用程序的行为；2）使用“应当(should)”来描述软件的行为；3）使用“确保(ensure)”来描述软件的职责；4）使用mock作为还未编写的相关代码模块的替身；5）通过自动运行这些例子，提供快速反馈，进行回归测试
DoD：完成的定义
DoD定义了产品积压项目何时变为增量，通常是用户故事被视为“完成”之前必须满足的标准列表，团队就此列表达成一致，并在团队房间的显着位置显示。在冲刺结束时未能满足这些标准，意味着工作不应计入该冲刺的速度。
DoR：就绪的定义
DoR可以帮助团队确定产品积压项目何时可以开始工作。这对于依赖比较严重的任务之间是非常有效的，所以硬件开发、嵌入式开发等领域越来越重视DoR
集体所有权
各个团队成员拥有更新任何相关资产所需的技能和权限。这种方法减少了团队之间的依赖性，并确保任何单个团队成员或团队都不会阻碍价值交付的快速流动。集体所有权使每个人都能理解和维护每个组件的质量。“T 型技能”进一步促进了集体所有制。
学习左移
学习发生得更早，或者向左移动，开发过程中的问题和风险就会更快地暴露出来，从而能够以最小的影响采取纠正措施。不但是软件开发，敏捷硬件开发也正在应用这个实践，建模和仿真、快速原型制作都是具体的示例
最新 AgileDo提供免费的服务售前咨询，您可以 联系我们!