敏捷开发简介

Posted 2021-04-25 宇智波IT

1. 何为敏捷

敏捷是基于一种不确定性较高，未来环境难以预测的背景下产生的一种管理理念，这种理念并不意味着应该丢弃传统的管理方法中的一些方法而是应该以快速传递价值给客户为目标进行管理，只要某个方法能加速我的价值传递就应该使用。

敏捷宣言

• 个体和互动高于流程和工具；

• 工作的软件高于详细的文档；

• 客户合作高于合同谈判；

• 响应变化高于遵循计划。

以上价值观并不是右边不重要，而是认为左边更重要。

十二原则

客户为主：我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。

拥抱变化：欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。

短迭代交付：要不断交付可用的软件，周期从几周到几个月不等，且越短越好

业务参与：项目过程中，业务人员与开发人员必须在一起工作。

以为人本：要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。

面对面沟通：无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。

成功导向：可用的软件是衡量进度的主要指标。

保持节奏：敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。

追求卓越：对技术的精益求精以及对设计的不断完善将提升敏捷性。

简单务实：要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。

团队自组织：最佳的架构、需求和设计出自于自组织的团队。

持续改进：团队要定期反省如何能够做到更有效，并相应地调整团队的行为

2. 敏捷生命周期

预测型——类似传统的瀑布型

迭代型与增量型

敏捷型

四种生命周期的区别

3. 敏捷团队

自组织

大量个体基于简单规则的互相作用，无需中央调控，能够涌现出整体上的新秩序

组建高绩效团队

致力于共同的目标，并为了实现绩效 目标自主承担共同的责任

主要特点

• 具备合适技能和积极性的人员

• 承诺和有效授权

• 建立信任

• 胜于其他团队并超过预期

• 保持可持续的速度去交付高质量软件

• 一致性和可预见的速度

• 具备技术水平和商业知识

主要特征

• 参与式领导力

• 有效的决策

• 开放和清晰的沟通

• 价值多样性

• 相互信任

• 管理冲突

• 清除目标

• 明确定义角色和职责

• 协调关系

• 积极的氛围

敏捷教练——仆人式（服务式）领导

特点

• 以身作则，乐于成为仆人，以服务来领导

• 倾听并支持团队做出决策

• 理解他人，具备同理心

• 鼓励并支持每个个体的个人发展

• 劝说，而非使用权利

• 主动寻求帮助他人，并信守承诺

• 在跟随者中建立信任

• 提前思考未来，超越每日实现

职责

• 教育相关方法，使其了解为什么要敏捷以及如何敏捷

• 通过指导、鼓励和帮助团队提供支持

• 通过技术项目管理活动

• 庆祝团队成功

• 为团队与外部团队合作提供支持，并起到桥梁作用

• 创造互相欣赏的积极氛围，建立加强合作的良好意愿

敏捷团队激励

马斯洛需求理论

金字塔五层：生理需求、安全需求、爱与归属 的需求、自尊需求、自我实现需求。只有低层次满足了才会产生高一层级的需要

赫兹伯格双因素理论

激励因素：来自工作条件本身，能带来满意、成就，例如：重视、成就、个人成长

保健因素：是必须的但是不能给予激励，缺少它会导致不满意，例如：地位、工作安全、薪水等

敏捷项目团队需要保健因素去建立最低水平的团队绩效。同样，激励因素决定团队是否能实现高绩效

大卫动机理论

主要激励因素	对应类型人的特征
成就	设定和完成挑战性目标的强烈愿望 愿意承担可能的风险去完成目标 愿意收到来自进展和成就的反馈
社交	喜欢有集体归属感 想要被喜欢 喜欢协作竞争 不喜欢高风险或不确定性
权力	喜欢权力和影响他人  享受竞争和胜利  享受地位和重视

4. 敏捷实践

精益软件开发（LSD）

解决影响生产过程中的问题

• 过度：对于雇员和过程施加不必要的额外压力

• 违规：不切实际的需求导致过程中的不均匀

• 浪费：非增值活动或过程

精益 7 原则

极限编程（XP）

一种基于频繁交付周期的软件开发方法，一种开发哲学，基于以下五大价值观

验收测试驱动开发（ATDD）

• Discuss：讨论

• Distill：提取

• Develop：开发

• Demo：示范

测试驱动开发（ADD）

• 编写测试代码

• 核对和确认测试

• 编写产品代码，接着采用测试

• 重构产品代码

Scrum

Scrum流行的原因

• Scrum提供简单和可证明的结果

• 它包含其他敏捷工程技术

• 它强调小型团队和团队授权

• 欢迎需求的变更

• 它允许单一来源的优先项目工作开展

• Scrum会议包括日常状态会议

• 提供团队在冲刺阶段一个潜在的可交付增量承诺

三大角色

• 产品负责人——告诉团队要做什么，做功能的先后顺序是怎样的，需求有变动时该如何处理

• Scrum Master——引导团队建立团队规则，维护团队和指导团队外部成员遵守团队规则，移除团队障碍

• 开发团队——执行冲刺，包括：每日检视和调整、梳理产品列表、冲刺规划、检视和调整产品与过程

 三大工件

• 产品待办列表：一份涵盖产品中已知所需每项内容的有序列表，它是产品需求变动的唯一来源

• 冲刺待办列表：一组为当前Sprint选出的产品待办列表项，同时加上交付产品增量和实现Sprint目标的计划

• 产品增量：一个Sprint完成的所有产品待办列表的总和，以及之前所有Sprint所产生的增量的价值总和

五大会议

• 产品待办事项梳理——为即将到来的冲刺做准备，并对事项进行分解和估算

• 冲刺计划会议——如何完成交付所需的工作

• 每日站立会议——检查冲刺目标的进度，并检视完成冲刺待办列表的工作进度趋势

• 冲刺评审会议——产品负责人说明待办项列表的完成和未完成；开发团队讨论冲刺期间做得好的、碰到的问题及解决方法

• 冲刺回顾会议——Scrum团队检视自身并创建下一个Sprint改进计划的机会

Scrum实施流程

5. 敏捷工具

用户画像

PERSONA七要素

• P代表基本性(Primary)：指该用户角色是否基于对真实用户的情景访谈；

• E代表同理性(Empathy)：指用户角色中包含姓名、照片和产品相关的描述，该用户角色是否引同理心；

• R代表真实性(Realistic)：指对那些每天与顾客打交道的人来说，用户角色是否看起来像真实人物；

• S代表独特性(Singular)：每个用户是否是独特的，彼此很少有相似性；

• O代表目标性(Objectives)：该用户角色是否包含与产品相关的高层次目标，是否包含关键词来描述该目标；

• N代表数量性(Number)：用户角色的数量是否足够少，以便设计团队能记住每个用户角色的姓名，以及其中的一个主要用户角色；

• A代表应用性(Applicable)：设计团队是否能使用用户角色作为一种实用工具进行设计决策

可以用来克服项目成员在产品开发过程中的若干难题

• 需求分析阶段：确定产品功能以及用户行为的优先级，辅助场景设计，让产品更为聚焦。

• 产品设计阶段：协助与项目成员以及利益相关者进行沟通交流，就设计意见达成共识和承诺。提高设计效率。

• 用户调研阶段：许多其他的用户研究环节对于用户的招募以及研究内容确定都需要依据persona。

• 产品策略阶段：明确市场推广方向、预估市场规模，更准确地为产品做决策以及定位市场

用户故事

三要素

• 角色：谁要使用这个功能

• 活动：需要完成什么样的功能

• 业价值：为什么需要这个功能，能带来什么价值

3C原则

• 卡片（Card）：用户故事一般写在晓得记事本卡片上

• 交谈（Convertsation）：用户故事背后的细节来源于和客户或产品负责人的交流沟通

• 确认（Confirmation）：通过验收测试用户的故事被正确完成

六个特性-INVEST

• 独立性（Independent）— 要尽可能的让一个用户故事独立于其他的用户故事。

• 可协商性（Negotiable）— 一个用户故事的内容要是可以协商的，用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述，不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通。

• 有价值（Valuable）— 每个故事必须对客户具有价值（无论是用户还是购买方）。

• 可以估算性（Estimable）—开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。

• 短小（Small）— 一个好的故事在工作量上要尽量短小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。

• 可测试性（Testable）—一个用户故事要是可以测试的，以便于确认它是可以完成的

确定用户故事优先级

相对优先级=价值/工作量 估算每个故事的价值和工作量，计算相对优先级。莫斯科（MoSCoW）规则

• 必须有（Must have）：基本功能

• 应该有（Should have）：很重要但是短期内有替代方案的功能，如果没有时间约束，此类功能是强制性的

• 可以有（Could have）：没有时间就可以在发布中不予考虑的功能

• 这次不会有（Won't have this time）

卡诺Kano模型：有时候基础型需求部分实现就可以了，尽可能多的完成期望型需求，确定少量兴奋型需求。

估算——对交付计划产品所需要的成本、进度、投入或者技能进行的预测

敏捷估算基础

• 估算让团队可以了解项目规格，计算ROI和IRR，形成项目执行许可的基础。

• 敏捷团队基于产品负责人的投入来估算需求，Scrum Master进行保守估算。

• 敏捷估算在整个项目期间进行。在项目逐步完善中更多信息出现，团队定期评估新需求。

• 团队使用计划扑克或者亲和估算等技术来确定需求估算。

准确性和精确性

• 敏捷估算致力于准确性而非精确性，因为实现精确性让估算过程拉长并且昂贵

故事点：描述一个用户故事及其相关努力总体规模的测量单元

特点

• 是相对测量；

• 用户故事的故事点互相进行对比；

• 故事点是团队运用计划扑克等估算技术确定的；

• 故事点对一个项目来说是独特的，不能同其他项目相比较。

• 分配故事点需要考虑的

• 任务规模-故事规则取决于以下因素：复杂性、投入量、风险大小

• 相对价值-故事点是规模的相对测量，绝对值不是很重要。

• 估算-估算运用基准来完成，相对值被运用。

•  选取最小故事估算价值为一个故事点。

•  选取中等规模故事分配5个故事点。

故事点估算的步骤

• 用户故事拆分为更小的功能，并确保每个故事具有投资属性。理想情况下，每个故事应该由1个人占用不超过2天的时间完成。

• 确定团队达成共识的故事作为基线，创建它的故事点价值。

• 将所有其他故事卡片同基线故事对比。

• 每次迭代末期，将故事点同故事卡片上记录的校准。

• 故事点之类比估算故事点估算可以通过对比来有效完成

估算规模敏捷评估旨在合理预测估算，不追求精确

两种非线性规模常用于估算

• 非线性规模-斐波那契数列：1，2，3，5，和8，后一个数字是前面两个数字的总和

• 非线性规模-翻倍：1，2，4和8，每个数字翻倍得到下一个数字

宽带德尔菲

宽带德尔菲的步骤

• 团队选择：选择负责估算的专家团

• 启动会议：计划启动会议去说程序和落地规则

• 个人准备：允许团队成员针对每个任务个人收集初始估算

• 估算会议：实施一系列迭代步骤组成的估算会议

• 配置任务：收集个人估算，编译最终清单

• 任务评审：评审估算程序、最终任务清单和假设的结果

计划扑克

• 每个团队成员收到有编号的卡片，如果需要数字可以延伸；

• 产品负责人朗读每个故事卡片并回答团队问题；

• 每个团队成员评估故事所需投入以及运用相对尺码给故事分配点；

• 当Scrum Master要求时，每个人必须同时举起写有他们估算的数字卡；

• 如果这里有差异，团队成员要解释估算偏高或偏低的原因；

• 讨论后，团队成员重新估算直到达成一致