敏捷开发知识体系整体框架

阅读量：5922 次

发布时间：2019-06-19

本文共 6661 字，大约阅读时间需要 22 分钟。

敏捷开发工程实践

项目管理

迭代开发

风险价值生命周期

多级项目规划

完整团队

每日站立会议

任务板

燃尽图

需求管理

需求订单

业务流程草图

用例驱动开发

用户故事

架构

演进的架构

演进的设计

基于组件的架构设计

开发

结对编程

测试驱动开发

重构

代码规范

测试

单元测试

并行测试

测试管理

变更管理

持续集成

自动构建

团队变更管理

敏捷开发管理实践描述

定义和特征说明

主要角色

主要活动和最佳实践

主要输入输出

工作流程

敏捷开发工程实践描述

定义和特征说明

应用说明

案例说明

敏捷开发核心价值观和原则

敏捷软件开发宣言

个体和互动 高于 流程和文档工作的软件 高于 详尽的文档客户合作 高于 合同谈判响应变化 高于 遵循计划也就是说, 尽管右项有其价值, 我们更重视左项的价值.12345

敏捷软件开发的核心价值观

敏捷开发的核心理念就是以最简单有效的方式快速打成目标, 并在这个过程中及时地响应外界的变化, 做出迅速的调整.

核心价值观

以人为本

目标导向

客户为先

拥抱变化

敏捷开发的原则

我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。

欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。

经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。

业务人员和开发人员必须相互合作，项目中的每一天都不例外。

激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。

不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。

可工作的软件是进度的首要度量标准。

敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。

坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。

以简洁为本，它是极力减少不必要工作量的艺术。

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

团队定期地反思如何能提高成效，并依此调整自身的举止表现。

敏捷开发管理实践

Scrum

Scrum是一种迭代式增量软件开发过程，通常用于敏捷软件开发。Scrum包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员。

Scrum中的角色

“猪”角色

产品负责人（Product Owner）
- 通常由市场部门的人担任

敏捷教练 (Scrum Master)
- 通常由开发组组长担任

开发团队 (Scrum Team)
- 包括开发,需求,测试

“鸡”角色

用户
- 软件是为了某些人而创建！就像“假如森林里有一棵树倒下了，但没有人听到，那么它算发出了声音吗”，“假如软件没有被使用，那么它算是被开发出来了么？”

利益所有者 (客户，提供商)
- 影响项目成功的人, 但只直接参与冲刺评审过程。

管理者
- 为产品开发团体架起环境的那个人

主要活动和最佳实践

迭代式软件开发

两层项目规划 (Two-Level Project Planning)

整体团队协作 (Whole Team)

持续集成

冲刺规划会议 (Sprint Plan Meeting)

每日站立会议 (Sprint Daily Meeting)

冲刺复审会议 (Sprint Review Meeting)

冲刺回顾会议 (Retrospective Meeting)

scrum方法中得主要活动和交付件

主要输入输出

产品订单(Product Backlog)

冲刺订单(Spring Backlog)

燃尽图(Burndown Chart)

新的功能增量

工作流程

scrum方法全景图

项目管理过程

在Scrum项目管理过程中产品负责人获取项目投资, 并对整个产品的成功负责.

产品负责人协调个中利益干系人, 确定产品订单中初始的需求清单及其优先级, 完成项目商业价值分析和项目整体规划, 并任命合适的敏捷教练开展项目工作.

项目开发过程

在Scrum软件开发过程中, 每个冲刺就是较短的迭代, 通常为2~4周.

在每个冲刺开始时, 产品负责人和敏捷教练通过召开冲刺规划会议和”两层项目规划”的最佳实践, 制定冲刺订单(类似迭代计划)

产品负责人明确在本次冲刺中实现的需求清单, 响应的工作任务和负责人.

在每个冲刺迭代中, 团队强调应用”整体团队协作”的最佳实践, 通过保持可持续发展的工作节奏和每日站立会议, 实现团队的自组织, 自适应和自管理, 高效完成冲刺工作.

在每个冲刺结束时, 团队都会召开冲刺复审会议, 团队成员会在会上分别展示他们开发出的软件(或其他有价值的产品), 并从产品负责人和其他利益关系人那里, 得到反馈信息.

在冲刺复审会议之后, 团队会自觉招开冲刺回顾会议, 回顾整个项目过程, 讨论哪些方法做的好, 哪些方面可以改进, 实现软件交付过程的持续, 自发的改进.

XP

OpenUp

Lean

敏捷开发工程实践

迭代式开发

敏捷迭代开发是指每次按照相同的开发方式短期的开发软件的部分, 或前期开发并不详尽的软件, 每次开发结束获得可以运行的软件, 以供各方干系人观测, 获得反馈, 根据反馈适应性的进行后续开发, 经过发福多次开发, 逐步增加软件部分, 逐步补充完善软件, 最终开发得到最后的软件. 每次反复开开发叫一次迭代, 在Scrum中成为Sprint, 中文常译为”冲刺”.

持续集成

持续集成(Continuous integration)是指当代码提交后, 马上启动自动编译, 自动部署金额自动化测试来快速验证软件, 从而尽快的发现集成错误.

多级项目规划

多级项目/产品规划, 在软件开发领域, 是指以迭代开发为基础, 形成多层次的, 逐步细化的项目或产品计划. 这些层层相关的项目/产品规划包括:

项目/产品愿景

项目/产品路线图

版本发布计划

迭代计划

每日实现

项目/产品愿景

在计划阶段, 首先, 项目stakeholder, 项目/产品负责人将参与并组成工作组, 他们负责阐述项目的重要性, 给出项目成功失败的关键标准以及项目整体层面”完成”的定义; 在过程中, 可以利用形成项目愿景的一些个工具, 包括愿景盒子(Vison Box), 业务收益矩阵(Business Benefits Matrix), 项目范围矩阵(Scope Matrix), 滑动器(Slider), 成本收益矩阵(Cost/Benefit Matrix)等; 最后, 项目愿景需要使用尽量简要的文档固定下来, 并保证项目团队成员都能了解.该文档需要包括:

当前的问题

机会描述和理由(描述项目的重要性)

项目的价值

项目如何和组织的战略目标达成一致

解决方案综述

项目包含的关键功能

项目必须服从的技术和约束条件

项目范围

项目的关键时间线

项目收益分析

项目和其他项目的依赖性

项目的相关风险以及如何消除

项目/产品路线图

主要描述为了达到产品愿景而需要交付的关键功能和特性, 这些特性基本处于Epic和特性层面, 不包裹用户故事(User Story). 它从时间的维度来表述对愿景的支持和实现. 它从时间维度来表达对愿景的支持和实现. 当项目/产品需要发布多个版本时, 项目线路图就非常重要, 否则, 它和发布计划相同, 项目/产品线路图由项目负责人和项目经理维护, 并保持更新. 通常, 会形成路线图问题或幻灯片, 使用大图标显示重要的里程碑, 包含的功能和发布日期等, 让所有项目/产品相关人员都清楚产品各个组件的可能发布日程.

版本发布计划

版本发布计划由团队成员和项目/产品负责人共同制定, 并通过版本发布计划会议讨论通过. 它包括了当前版本需要交付的, 达成一致的关键功能, 并经过优先级排序, 可以包含EPIC和User Story. 版本发布计划中常使用的概念包括:故事点, 迭代团队速率和优先级排序. 通常, 项目/产品负责人提出本次发布的目标, 团队成员根据目标和功能特性的重要性对故事进行排序, 并依据团队速率觉得本次发布需要包含的故事点. 前几次版本发布使用估算值, 其准确性随着项目/产品的时间持续而逐步精确. 版本发布计划是剧本适应性可调整的计划, 会随着项目演进而改变.

迭代计划

迭代计划是对版本发布计划的再次细化, 同样由团队成员和项目/产品负责人共同制定, 并听过迭代计划会议讨论通过. 迭代会议负责两件事情:

根据当前状态确定是否需要对版本计划做出更新

为当前的迭代计划制定迭代计划

迭代计划中常使用的概念包括: 拆分Epic和User Story, 任务, 任务估算. 在迭代会议上, 成员首先根据当前的项目变化对发布计划进行更新, 然后根据更新后的, 重新排序过的故事制定当前迭代需要完成的故事, 并对这些故事进行详细的任务拆分. 成员在认领完任务后, 会对任务的实现时间做出估算, 估算值需要具体到这些估算信息可以方便任何成员追踪任务的进度.

每日实现

没事实现是团队成员完成任务的具体过程, 它依据任务估算值并根据任务最终实现情况更新该值. 在敏捷方法中, 使用每日站会议来报告进度. 通过15分钟的站立形式, 团队成员报告故事或者任务的完成,未完成状态, 而解决层面的问题则在会议之后处理.

完整团队

Scrum团队必须具备的三个完整性:

团队职责完整性

产品负责人（Product Owner）

确定产品的功能。

决定发布的日期和发布内容。

为产品的收益(profitability of the product)负责。

根据市场价值确定功能优先级。

在30天内调整功能和调整功能优先级。

接受或拒绝接受开发团队的工作成果

敏捷教练 (Scrum Master)

负责监督整个Scrum项目进程, 调整开发计划

保证团队资源完全可被利用并且全部是高产出的。

保证各个角色及职责的良好协作。

解决团队开发中的障碍。

做为团队和外部的接口，屏蔽外界对团队成员的干扰。

保证开发过程按计划进行，组织 Daily Scrum, Sprint Review and Sprint Planning meetings。

需要知道什么任务已经完成，哪些任务已经开始，哪些新的任务已发现，和哪些估计可能已经发生变化. 根据以上的情况更新反映每天完成的工作量以及还有多少没有完成的燃尽图

需要找出阻碍Scrum的障碍和依赖, 根据优先级指定计划解决这些障碍

个人问题或冲突在Scrum里是需要解决的。这些都需要被澄清，或通过内部的沟通解决，或向管理层和HR寻求帮助解决

Scrum Master需要知道什么任务已经完成，哪些任务已经开始，哪些新的任务已发现，和哪些估计可能已经发生变化。Scrum Master需要根据以上的情况更新反映每天完成的工作量以及还有多少没有完成的Burndown Chart。 Scrum Master还必须仔细考虑进展中的开放任务数，进展中的工作需要得到最小化，以实现精益生产率的收益。