敏捷开发知识体系

2017-05-22 10:41:41 qq_14898543 阅读数 150

原文地址:http://blog.csdn.net/uxyheaven/article/details/49618097


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

敏捷开发工程实践

项目管理

  • 迭代开发
  • 风险价值生命周期
  • 多级项目规划
  • 完整团队
  • 每日站立会议
  • 任务板
  • 燃尽图

需求管理

  • 需求订单
  • 业务流程草图
  • 用例驱动开发
  • 用户故事

架构

  • 演进的架构
  • 演进的设计
  • 基于组件的架构设计

开发

  • 结对编程
  • 测试驱动开发
  • 重构
  • 代码规范

测试

  • 单元测试
  • 并行测试
  • 测试管理

变更管理

  • 持续集成
  • 自动构建
  • 团队变更管理

敏捷开发管理实践描述

  • 定义和特征说明
  • 主要角色
  • 主要活动和最佳实践
  • 主要输入输出
  • 工作流程

敏捷开发工程实践描述

  • 定义和特征说明
  • 应用说明
  • 案例说明

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

敏捷软件开发宣言

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

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

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

核心价值观

  • 以人为本
  • 目标导向
  • 客户为先
  • 拥抱变化

敏捷开发的原则

  • 我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意。
  • 欣然面对需求变化,即使在开发后期也一样。为了客户的竞争优势,敏捷过程掌控变化。
  • 经常地交付可工作的软件,相隔几星期或一两个月,倾向于采取较短的周期。
  • 业务人员和开发人员必须相互合作,项目中的每一天都不例外。
  • 激发个体的斗志,以他们为核心搭建项目。提供所需的环境和支援,辅以信任,从而达成目标。
  • 不论团队内外,传递信息效果最好效率也最高的方式是面对面的交谈。
  • 可工作的软件是进度的首要度量标准。
  • 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
  • 坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强。
  • 以简洁为本,它是极力减少不必要工作量的艺术。
  • 最好的架构、需求和设计出自自组织团队。
  • 团队定期地反思如何能提高成效,并依此调整自身的举止表现。

敏捷开发管理实践

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还必须仔细考虑进展中的开放任务数,进展中的工作需要得到最小化,以实现精益生产率的收益。
  • Scrum Master需要找出阻碍Scrum的障碍和依赖。他们需要的优先次序和跟踪。根据优先级指定计划解决这些障碍。其中有些问题可以在团队内部解决,有些则要团队之间的协调,还有的要管理层的介入来解决.

开发团队 (Scrum Team)

  • 具有不同特长的团队成员,人数控制在5-7个左右, 跨职能, 包括开发, 需求, 测试
  • 弱化分工, 每个人都参与设计, 开发与测试
  • 确定Sprint目标和具体说明的工作成果。
  • 在项目向导范围内有权利做任何事情已确保达到Sprint的目标。
  • 向Product Owner演示产品功能。

团队素质完整性

  • 要具备很强的集体协作精神.
  • 要具备良好的沟通能力
  • 必须能积极主动的接受新的事物, 要具备创新能力
  • 要具备极强的自我管理能力和积极主动的精神

沟通的完整性

  • Sprint启动会
  • 每日站立会议
  • Sprint回顾会

案例

验收测试驱动开发ATDD

TDD 只是开发人员的职责,通过单元测试用例来驱动功能代码的实现。ATDD在准备实施一个功能或特性之前,首先团队需要定义出期望的质量标准和验收细则,以明确而且达成共识的验收测试计划(包含一系列测试场景)来驱动开发人员的TDD实践和测试人员的测试脚本开发。面向开发人员,强调如何实现系统以及如何检验。

  • 挑选用户故事
  • 为故事写测试
  • 实现测试
  • 实现故事

结对编程

结对编程可以看做是一种敏捷化的Code Review

新结对编程

两位程序员新成结对小组, 每人一台电脑, 坐在临近的工位上, 两人合作完成一组功能(可以是两个或多个独立的模块)的设计, 代码实现. 但对已某一个模块来说设计和代码是分开的, 一个人负责设计, 另一个人负责写代码, 对于其他模块则反之.

确定冲刺计划

定义和说明

  • 目的: ST和PO共同决定在接下来的冲刺周期内的目标以及那些功能和任务需求要完成
  • 主要角色: ST, PO, SM
  • 主要输入: Product backlog, 团队的能力
  • 主要输出: Sprint Backlog

冲刺会议分两个部分 
1. 解决本次冲刺要完成哪些需求 
2. 解决这些选择的需求要如何被完成

案例

故事点估算

故事点是表述一个用户故事, 一项功能或一件工作的整体大小的一种度量单位. 数值本身不重要, 重要的是这些故事之间对比体现相对大小.

计划扑克

  • 开始时, 美人得到一张扑克, 上面有任务点(?, 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, 无穷).?代表无法估算, 无穷代表故事太大
  • 开始对故事进行估算, 先由PO介绍这个故事的描述. 接着澄清问题
  • 每一个组员从扑克中挑选可以代表这个故事的卡片, 集体亮牌
  • 最高分和最低分的组员像团队做出解释
  • 全组成员自由讨论几分钟
  • 重新打分, 直到全组统一.

敏捷估算2.0(Agile Estmating 2.0)

  • PO像团队成员介绍每一个用户故事, 确保所有需求相关的问题都在做估算前得到解决
  • 整个团队参与游戏: 一次由一人将一个故事卡片放在合适的位置, 规模小的在左,规模大的在右, 一样大的竖排. 轮流移动故事卡片, 直到整个团队都认同白板上故事卡的排序为止.
  • 团队将故事点(Story Point)分配给每个故事.

需求订单(Product Backlog)

记录用户需求的列表, 包括产品所有需要的特征.

  • 每一项包含了需求标题, 描述, 重要性, 故事点(或其他表示大小的数字)
  • 需求订单式开放的, 团队每个成员都可以编写和维护
  • 在整个项目开放生命周期内, 需求订单需要不断维护, 管理与跟踪需求变化

燃尽图

在项目完成之前, 对需要完成的工作的一种可视化表示. 燃烧故事点.每天更新一次

  • 具备可视性
  • 具备风险预估, 提醒团队目前完成情况
  • 具备可估量, 直接显示当前还需要的时间.

燃尽图常见问题

每日站立会议(Daily Scrum)

每日站立会议旨在让团队统一目标, 协调内部问题的解决, 绝非进度汇报.一般不超过15分钟.

  • 我们上次开会后你都干了什么
  • 在我们下次开会之前你要做什么
  • 每个你负责的、正在做的任务还剩下多少时间
  • 你的工作被阻碍了吗

任务板(Task board)

  • 为项目团队提供一个便利的工具用于管理他们的工作
  • 是团队成员对本冲刺的工作一目了然

任务板通常设立与项目团队日常工作的公共空间的一面墙上. 任务板上得信息包括该冲洗计划完成的用户故事和相应的任务, 分别卸载卡片上, 按照一定的方式贴在任务板上(To Do, In Progress, Done). 团队成员通过调整任务卡得位置和上面的信息反映任务的执行情况.

用户故事卡

每张卡片记录一条用户故事, 故事点.

任务卡

每个用户故事卡片通对应的多个任务卡. 每张卡片记录一条任务, 到目前为止完成该任务所需的工作量(小时).随着进展试试更新.

任务板的使用

用户故事

作为<某个角色>, 我希望<实现何种功能>, 以便<带来何种价值>.

如: 作为一个用户, 我希望在每次退出系统前得到是否保存的提示, 以便所有内容都被成功存储了.

测试驱动开发(TDD)

先开发测试用例, 然后再开发代码


2015-05-28 22:40:58 swebin 阅读数 18314

说起敏捷开发,并不是因为敏捷而敏捷。这几年的敏捷开发已经被很多敏捷咨询服务商神话了,这个东西并不是神器,实施了就可以解决所有软件公司的问题,而是要结合自己公司的特点和问题摸索出适合自己的一套模式。

大家都知道,创业公司刚开始需要研发出一款产品并且能够使公司赚钱的产品,不过大部分创业公司没有那么容易一下就能做出来,很多公司还没有成功的产品资金链就断掉了,公司也死掉了。我们公司是这样一个状况,有一条产品线可以维持公司开支并仅仅刚够盈余,要扩大高速发展还不够,一直维持就没有创业的意义。另一条线是做技术创新为未来能够开发一款人气爆棚的产品摸索着,但是又不能饿着肚子去开发。我们是如何结合自身的特点实施敏捷开发的呢?一个难题,很大的难题!

我们技术团队人员是这样的配置:1名技术总监、2名资深开发工程师、1名高级开发工程师、2名潜力开发工程师、1名前端开发、1名测试。技术总监需要处理很多团队管理、客户管理的工作,能够参与项目的时间最多每天二分之一。2名资深开发需要负责给其他工程师做导师,参与新项目开发时间大概有80%。高级工程师要预留项目学习时间,参与项目的时间大概有90%。潜力开发工程师需要有一些时间学习技术和项目,但是基本可以做到70%的时间投入项目。前端开发和测试哪里有需要就在哪里革命,属于机动部队。

现在总共有六个老项目在维护,两个新项目需要开发。六个项目的维护总共需要每周4人天时间(人天指需要花1个人4天的时间完成一个事情)。其中一个新项目“项目1”大概估计120人天的开发时间,需要1个月之内开发完成。“项目2”大概估计要40人天的开发时间,需要2周开发完成。而现在的人力按照能够投入的时间算一下,总共资源为 (1 * 1/2 + 2 * 8/10+1 * 9/10+2 * 7/10) 30天 = 132 人天,6个老项目每周需要4人天,一个月4周,需要 4 * 4 = 16人天。项目能够投入的资源有 132 – 16 = 116人天,而总共需要120 + 40 = 160天,足足少了44人天,这看起来是一个不可完成的任务。

不过到最后,我们还是使用敏捷开发完成了这两个项目,也没有影响老项目的维护。我们是怎么操作的?最开始我们两个开发,这个时候只要两个人就能够很好的合作把产品开发出来,不需要什么模式。随着人员的扩充,团队间如何协作按时按质按量完成任务就需要好好思考下了。

尝试一,传统软件开发模式。整个过程为 需求分析、系统设计、任务分解计划安排、开发设计、编码、测试、交付、验收、维护。这个模式也是大家最常使用的模式,不过套用在我们公司时我们是这么操作的。

传统开发过程
传统开发过程

由于公司创业,老板有一个想法,但并不能很好的描述需求,所以需求分析的任务落在技术总监身上。系统设计和任务分解刚开始是技术总监完成,后面资深开发工程师可以承担一部分。开发设计可以让各个开发工程师完成,资深工程师进行把关,再到测试人员测试,最后再交付用户验收、技术维护。看起来很好的模式,开发了几个产品最终有的延时有的产品离用户的期望差距甚远,参与项目团队的人信心受挫。

为什么会失败呢?后来思考了这些问题:

1、技术总监不是产品经理,不能够承担产品设计的责任。老板是信任技术总监能做好产品,就交给他做。但这里搞混了一个概念,产品经理和项目经理,技术总监应该起到项目经理和架构师的作用。项目经理管控项目进度和计划、架构师把握整体技术问题。而技术总监接到这个任务又不能不做好,责任所在。说到底,就是机制没有把产品设计和项目经理区分开,不等于技术实现者就是产品设计者。更多的应该让老板或者其他业务人员承担产品设计的工作。

2、需求不稳定,变化后改动代价大。由于创业,需求为了适应市场会经常调整,但是一但调整,很多开发计划就会受到相应的调整。如果部分功能已经正在开发,调整需求后很多工作要重新开始,严重影响了技术同事积极性。业务不调整需求是不可能的,他们是为了满足用户的要求,用户满意了才能给企业带来价值。不过如果调整,代价太大,很多代码要重写,大家就会责怪技术总监或者项目负责人没有把握好需求。

3、团队经常加班,但战斗力不强。 核心团队疲于应对需求、技术开发、老系统维护,没时间指导新同事技术学习,而新同事技能暂时还没有发挥出来干活效率低,任务经常延期,没有成就感。核心团队事情很多,没有时间整理项目文档,新员工没有文档上手慢。大家每天很多事情,需要加班才能完成,比较疲惫。每个人除了工作还有很多事情需要做,比如回家看看电视、陪陪家人、看看书学习一下等。如果让一个员工一天二十四小时都是工作,他能同意,他家人也不一定同意。让大家愉悦的开发,比疲惫的上班效率要高很多。

4、交付软件质量差,离用户期望差距大。创业时大家的想法都是好的,大干一番,做一个所有人都爱使用的产品。现实是残酷的,大家辛辛苦苦做出来的东西,老板不满意、用户不埋单,付出的努力没有人认可。交付的软件没时间自测试,或者自测试不充分,交给测试又是一大堆问题。有些公司还没有测试,直接出去给用户,相当危险。这样交出去的公司不仅仅影响了用户的使用,还影响了整个公司的口碑。

不是说传统软件开发模式不好,只是不太适合我们这种创业公司。开始尝试其他模式,如果没有一个很好的体制就不能把大家的最大生产力发挥出来。

尝试二,敏捷开发模式。敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。敏捷方法强调以人为本,专注于交付对客户有价值的软件。在高度协作的开环境中,使用迭代式的方式进行增量开发,经常使用反馈进行思考、反省和总结,不停的进行自我调整和完善。

敏捷开发的主旨

一:个体及交互比流程与工具更具价值

二:可用的软件比冗长的文档更有价值

三:与客户的协作比合同谈判更有价值

四:对变化的响应比遵循计划更有价值

而我们之前的问题,交付软件客户不满意、延期、需求更改代价大貌似都可以解决。这么好的模式赶紧要试试,先看一张敏捷开发的流程图。

创业公司敏捷开发敏捷流程化
创业公司敏捷开发敏捷流程化

敏捷开发简单流程

1、产品负责人将整个产品设计成产品backlog。产品backlog就是一个个需求列表。(backlog可以理解为需求或者要做的事情)
2、召开产品backlog计划会议,预估每个backlog的时间,确定哪些backlog是需要在第一个sprint中完成的,即sprint的backlog。(sprint可以理解为一个团队一起开发的一个任务集合)
3、把sprint的backlog写在纸条上贴在任务墙,让大家认领分配。(任务墙就是把 未完成、正在做、已完成 的工作状态贴到一个墙上,这样大家都可以看得到任务的状态 )
4、举行每日站立会议,让大家在每日会议上总结昨天做的事情、遇到什么困难,今天开展什么任务。(每日站立会议,是在每天早上定时和大家在任务墙前站立讨论,时间控制在15分钟内)
5、绘制燃尽图,保证任务的概况能够清晰看到。(燃尽图把当前的任务总数和日期一起绘制,每天记录一下,可以看到每天还剩多少个任务,直到任务数为0 ,这个sprint就完成了)
6、sprint评审会议是在sprint完成时举行,要向客户演示自己完成的软件产品 。
7、最后是sprint总结会议,以轮流发言方式进行,每个人都要发言,总结上一次sprint中遇到的问题、改进和大家分享讨论。

我们怎么结合敏捷开发解决现有项目的问题,要记得任何措施都是为了保证按时按质按量把软件交付给用户,不要为了敏捷而教条实施敏捷,公司不能产生商业价值,任何先进的理念或者技术都是无意义的。我们做了这些措施:

1、推广敏捷开发理念。不管是大公司还是小公司强制推行一项制度效果一般都不怎么好。要能推行下去的任何东西一定要大家接受的,才能被认可。

  • 首先培养测试小妹学习敏捷开发,后续让她承担部分产品责任人和敏捷指导者的角色,原因有:
    a、测试要验收功能,必须理解业务需求。
    b、测试也是QA质量体系的一块,学习好了对于软件质量有个更深的认识。
    c、团队大部分是男生,女生推广更有亲和力一些。
  • 召集所有技术团队开会准备推广。开始和测试小妹好好讨论下,怎么给大家说更有效,更容易接受。她要讲解一定要自己非常清楚敏捷开发,并且准备充分知识点。开会时先指出我们现在问题,让大家看看有什么想法解决问题吗?现在我们做的产品,客户不认可、老板不满意、自己很累没有成就感,有什么办法解决。在大家讨论后,抛出敏捷开发的优势,一般情况下大家都会认可的。大家可能会问到如何执行、落地,可以尝试找一个项目试点,如果实施成功就可以让大家全面推广,不成功也只影响了部分项目。

2、搭建敏捷开发环境。大家要实施敏捷开发,需要比较好的基础条件保证敏捷开发顺利进行。主要几个关键的软件:nexus 搭建仓库依赖中心、maven 管理工程的依赖、jenkins 持续集成和自动编译发布、svn 集中代码管理、jira 记录需求和状态。具体参考《敏捷开发环境搭建》

3、敏捷项目实施。整个公司建立以业务目标为导向的氛围。就以“项目1”来说,目的是完成这个项目,需要进行这几步:

  • 先根据各自的能力和意向聚集一批完成这个目标的勇士,不管技术和非技术。如果聚集的人不够,技术总监可以根据总体项目的投入机动调整资源以支持,不过条件允许的话还是根据大家意愿来聚集。最终“项目1”召集了一个技术总监、一个资深开发、两个潜力开发、一个前端、一个测试,除去大家做其他事情的时间,总共可以算作4个人。
  • 充分调动客户(老板和业务同事)参与进项目,他们的参与直接决定了项目成功与否。结合之前的经验,如果他们参与不够,最终做出来的东西就不是他们要的,或者离他们要的差距很大。他们刚开始加入的时候,很迷茫有时会表现的比较抗拒,这个时候一定要耐心坚持让大家把第一个sprint开发成功,使大家尝到甜头。让他们全程参与项目也是表示了我们拥抱变化,如果有需求变化,就添加任务到任务墙,大家可以对所有任务的时间有个全面了解,如果超过sprint结束时间就需要业务决策哪些功能不在这个sprint周期加入。
  • 技术总监安排和客户沟通,客户这里指老板和业务。测试小妹负责和客户沟通记录,技术总监辅助。多次沟通后,尝试让测试把需求原型用最简单的工具绘制出来,技术总监审核通过后和客户沟通确认,反复迭代,直到整个需求大家没有异议。很多公司这种需求是有一个专门产品负责人来执行,但按照我们目前的人力是没办法做到的。这里没有让技术总监做主要是为了避免之前出现的问题,过度技术设计产品。
  • 产品设计出来后,召集项目成员分解任务,确定每个任务的时间,可以使用敏捷扑克牌来估计。任务分解尽量控制在 1-2天的粒度,这样大家1-2天就可以做出一个能测试的原型,尽早可以集成测试发现问题。一个sprint的任务集合尽量控制在1-2周,不能太长,也不能太短。太长会出现疲劳,太短的sprint会让大家觉得工作太多,做完一个又一个。“项目1”估算结果为120人天,总共投入4个人,需要30天4周时间,我们切成了4个sprint,差不多1个月时间完成,满足业务的时间要求。
  • 分阶段实施sprint,绘制任务墙,划分未开始、已计划、进行中、完成、燃尽图。把要做的sprint任务上墙,贴到未开始的地方。

创业公司敏捷开发任务墙
创业公司敏捷开发任务墙

  • 每日站立会议大家认领任务。包括业务任务、开发设计、开发编码、前端设计开发、测试等都是一个个任务,统一管理起来。强调的是一个团体,如果有同事请假,其他同事可以顶上完成任务。站立会议总结昨天的任务是否有问题,对于当前的任务有什么建议,尽量控制在15分钟内,有效会议。这里不会像以前业务或者项目经理追着大家屁股要结果,而是团队驱动,每天大家做的事情都反映在墙上,谁出现了什么状况,大家都会帮他想办法,保证整个项目能够成功。每一个任务完成,由项目执行者把任务从进行中贴到完成区域。再从未分配区域认领新任务贴到进行中的区域。
  • 软件开发过程。认领任务后,怎么保证大家开发有质量的代码?团队有资深点的工程师,不需要太多指导,直接可以参与项目的开发。而学习型工程师,需要指导帮助才能一步步做用例、系统分析。技术总监不建议认领太多开发任务,他负责开发团队的概要设计审核,没有审核通过的设计不能开发,并指导大家分析和设计系统。大家都知道,系统思路有了,剩下就是技术实现的过程,只要技能掌握熟练实现基本难度不大。大家可能会问,敏捷开发不是强调软件开发的产品是软件,而不是文档吗?我们这里也不是像传统开发软件一样为了文档而文档,只是让大家把自己的设计思路写下来,只有经过自己仔细设计后才能把思路清晰的写下来。大家写的时候也不需要长篇大论,这样的文档是不欢迎的,受欢迎的文档只需写出用例分析,表设计,复杂的逻辑需要画出流程序列图。
  • 结对编程。之前这个编程模式被无数人调侃过,其实也不可能让每一个项目全程都是两个人结对编程。这个不现实也浪费资源。我们的结对是在大家开发一个难点模块时,会给结对的人增加一项任务去配合其他开发一起完成这个任务。其实我们在开发时,很多时候都会结对,比如指导新同事、讨论设计模块,而之前这些都没有算在我们的开发工作量里。

创业公司敏捷开发结对编程
创业公司敏捷开发结对编程

  • 项目演示和总结会议。在项目结束后,让所有参与项目的成员都参加,一起演示给客户展示,并解答客户的问题,充分让大家感受到收获的果实。总结会议主要对于这个sprint中大家遇到的问题和经验分享,并为下一个sprint做准备。

经过敏捷实施后,我们的生产力提高了很多,员工的积极性提高了,业务的参与使整体需求把控也很好,大家沟通多了,30天的任务提前了5天完成。我们多出来的时间,让大家每周有一天或者半天研究自己感兴趣的领域,但是这些研究最终必须体现出成果。比如后台开发想研究一个新技术,最后做完需要写个ppt 给大家分享下。既能让大家做自己想做的事情,也给大家创造了一个互相学习的氛围。

ps:所有的模式都不应该是教条的模式,先进的模式并不是好的模式,适合自己的才是最好的。套用一句俗话:不管黑猫白猫抓得住耗子的才是好猫。

另曝光一下项目1参与成员:

项目1敏捷团队 
项目1敏捷团队
2017-03-28 08:27:20 kaizi318 阅读数 3426

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

敏捷开发工程实践

项目管理

  • 迭代开发
  • 风险价值生命周期
  • 多级项目规划
  • 完整团队
  • 每日站立会议
  • 任务板
  • 燃尽图

需求管理

  • 需求订单
  • 业务流程草图
  • 用例驱动开发
  • 用户故事

架构

  • 演进的架构
  • 演进的设计
  • 基于组件的架构设计

开发

  • 结对编程
  • 测试驱动开发
  • 重构
  • 代码规范

测试

  • 单元测试
  • 并行测试
  • 测试管理

变更管理

  • 持续集成
  • 自动构建
  • 团队变更管理

敏捷开发管理实践描述

  • 定义和特征说明
  • 主要角色
  • 主要活动和最佳实践
  • 主要输入输出
  • 工作流程

敏捷开发工程实践描述

  • 定义和特征说明
  • 应用说明
  • 案例说明

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

敏捷软件开发宣言

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

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

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

核心价值观

  • 以人为本
  • 目标导向
  • 客户为先
  • 拥抱变化

敏捷开发的原则

  • 我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意。
  • 欣然面对需求变化,即使在开发后期也一样。为了客户的竞争优势,敏捷过程掌控变化。
  • 经常地交付可工作的软件,相隔几星期或一两个月,倾向于采取较短的周期。
  • 业务人员和开发人员必须相互合作,项目中的每一天都不例外。
  • 激发个体的斗志,以他们为核心搭建项目。提供所需的环境和支援,辅以信任,从而达成目标。
  • 不论团队内外,传递信息效果最好效率也最高的方式是面对面的交谈。
  • 可工作的软件是进度的首要度量标准。
  • 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
  • 坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强。
  • 以简洁为本,它是极力减少不必要工作量的艺术。
  • 最好的架构、需求和设计出自自组织团队。
  • 团队定期地反思如何能提高成效,并依此调整自身的举止表现。

敏捷开发管理实践

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还必须仔细考虑进展中的开放任务数,进展中的工作需要得到最小化,以实现精益生产率的收益。
  • Scrum Master需要找出阻碍Scrum的障碍和依赖。他们需要的优先次序和跟踪。根据优先级指定计划解决这些障碍。其中有些问题可以在团队内部解决,有些则要团队之间的协调,还有的要管理层的介入来解决.

开发团队 (Scrum Team)

  • 具有不同特长的团队成员,人数控制在5-7个左右, 跨职能, 包括开发, 需求, 测试
  • 弱化分工, 每个人都参与设计, 开发与测试
  • 确定Sprint目标和具体说明的工作成果。
  • 在项目向导范围内有权利做任何事情已确保达到Sprint的目标。
  • 向Product Owner演示产品功能。

团队素质完整性

  • 要具备很强的集体协作精神.
  • 要具备良好的沟通能力
  • 必须能积极主动的接受新的事物, 要具备创新能力
  • 要具备极强的自我管理能力和积极主动的精神

沟通的完整性

  • Sprint启动会
  • 每日站立会议
  • Sprint回顾会

案例

验收测试驱动开发ATDD

TDD 只是开发人员的职责,通过单元测试用例来驱动功能代码的实现。ATDD在准备实施一个功能或特性之前,首先团队需要定义出期望的质量标准和验收细则,以明确而且达成共识的验收测试计划(包含一系列测试场景)来驱动开发人员的TDD实践和测试人员的测试脚本开发。面向开发人员,强调如何实现系统以及如何检验。

  • 挑选用户故事
  • 为故事写测试
  • 实现测试
  • 实现故事

结对编程

结对编程可以看做是一种敏捷化的Code Review

新结对编程

两位程序员新成结对小组, 每人一台电脑, 坐在临近的工位上, 两人合作完成一组功能(可以是两个或多个独立的模块)的设计, 代码实现. 但对已某一个模块来说设计和代码是分开的, 一个人负责设计, 另一个人负责写代码, 对于其他模块则反之.

确定冲刺计划

定义和说明

  • 目的: ST和PO共同决定在接下来的冲刺周期内的目标以及那些功能和任务需求要完成
  • 主要角色: ST, PO, SM
  • 主要输入: Product backlog, 团队的能力
  • 主要输出: Sprint Backlog

冲刺会议分两个部分 
1. 解决本次冲刺要完成哪些需求 
2. 解决这些选择的需求要如何被完成

案例

故事点估算

故事点是表述一个用户故事, 一项功能或一件工作的整体大小的一种度量单位. 数值本身不重要, 重要的是这些故事之间对比体现相对大小.

计划扑克

  • 开始时, 美人得到一张扑克, 上面有任务点(?, 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, 无穷).?代表无法估算, 无穷代表故事太大
  • 开始对故事进行估算, 先由PO介绍这个故事的描述. 接着澄清问题
  • 每一个组员从扑克中挑选可以代表这个故事的卡片, 集体亮牌
  • 最高分和最低分的组员像团队做出解释
  • 全组成员自由讨论几分钟
  • 重新打分, 直到全组统一.

敏捷估算2.0(Agile Estmating 2.0)

  • PO像团队成员介绍每一个用户故事, 确保所有需求相关的问题都在做估算前得到解决
  • 整个团队参与游戏: 一次由一人将一个故事卡片放在合适的位置, 规模小的在左,规模大的在右, 一样大的竖排. 轮流移动故事卡片, 直到整个团队都认同白板上故事卡的排序为止.
  • 团队将故事点(Story Point)分配给每个故事.

需求订单(Product Backlog)

记录用户需求的列表, 包括产品所有需要的特征.

  • 每一项包含了需求标题, 描述, 重要性, 故事点(或其他表示大小的数字)
  • 需求订单式开放的, 团队每个成员都可以编写和维护
  • 在整个项目开放生命周期内, 需求订单需要不断维护, 管理与跟踪需求变化

燃尽图

在项目完成之前, 对需要完成的工作的一种可视化表示. 燃烧故事点.每天更新一次

  • 具备可视性
  • 具备风险预估, 提醒团队目前完成情况
  • 具备可估量, 直接显示当前还需要的时间.

燃尽图常见问题

每日站立会议(Daily Scrum)

每日站立会议旨在让团队统一目标, 协调内部问题的解决, 绝非进度汇报.一般不超过15分钟.

  • 我们上次开会后你都干了什么
  • 在我们下次开会之前你要做什么
  • 每个你负责的、正在做的任务还剩下多少时间
  • 你的工作被阻碍了吗

任务板(Task board)

  • 为项目团队提供一个便利的工具用于管理他们的工作
  • 是团队成员对本冲刺的工作一目了然

任务板通常设立与项目团队日常工作的公共空间的一面墙上. 任务板上得信息包括该冲洗计划完成的用户故事和相应的任务, 分别卸载卡片上, 按照一定的方式贴在任务板上(To Do, In Progress, Done). 团队成员通过调整任务卡得位置和上面的信息反映任务的执行情况.

用户故事卡

每张卡片记录一条用户故事, 故事点.

任务卡

每个用户故事卡片通对应的多个任务卡. 每张卡片记录一条任务, 到目前为止完成该任务所需的工作量(小时).随着进展试试更新.

任务板的使用

用户故事

作为<某个角色>, 我希望<实现何种功能>, 以便<带来何种价值>.

如: 作为一个用户, 我希望在每次退出系统前得到是否保存的提示, 以便所有内容都被成功存储了.

测试驱动开发(TDD)

先开发测试用例, 然后再开发代码

2016-08-24 15:50:41 chenqiuge1984 阅读数 205

本文节选自《敏捷软件开发知识体系》一书,该书已授权CSDN正版发布,PDF下载链接请见文末。如需转载请联系中国敏捷软件开发联盟ADBOK编写组,感谢敏捷领域专家张克强老师(@zhangmike)全力帮助CSDN拿到该书电子版授权。

敏捷已经逐渐地被越来越多的企业所认同,许多软件开发公司都在极力向敏捷转型或是开始尝试敏捷。许多企业取得了成功,而许多企业则又回到了原来的老路上。为什么有的企业取得了成功,有的企业却失败了?因为敏捷看似简单,但转型实施起来并不容易,往往比预期的困难得多。实施敏捷是一场变革,这些变革不仅要求开发人员也要求企业中其他的成员进行大量的付出,除了在工程技术实践上的改变,思维模式和观念的改变更加关键。

本文收集了国际敏捷大师、知名企业转型实践经验,整理出了一些敏捷转型过程当中可以参考的模式和实践,期望能给企业敏捷转型提供一些帮助。

敏捷转型实践

(注:本文主体内容皆来自于Mike Cohn的《Scrum敏捷开发》)

改善Backlog

如同Scrum开发项目使用产品backlogs,你也应该使用改善backlog(improvement backlog)跟踪记录企业实施Scrum的工作。改善backlog列举了企业在实施Scrum过程中可以做的更好的所有事项。当IBM开始实施Scrum时,它的改善 backlog包括下列事项:

  • 增加使用Scrum的团队数量;
  • 动化测试的使用;
  • 使团队能够实现持续集成;
  • 想出如何确保每个团队都能有一名产品负责人(product owner);
  • 确定怎样度量实施Scrum的影响;
  • 增加单元测试和测试驱动开发的使用。

表1中显示的改善backlog是动态的,某些条目会被加入,某些条目则可能因为已完成或没有必要而被移出。

一个改善backlog是一份关于企业内部那些待发展的能力、待执行的工作、或待处理的问题的列表。

图片描述

表1 企业改善Backlog示例

小部门或单个项目级别的转型使用单个改善backlog。当Scrum要在部门或企业级别上实施时,因为转型的工作很大,所以需要使用多个改善backlog,这些backlog中每个都由社区创建,这些社区的成员都是那些对改善企业抱有热情,并愿意使用特别方式的个体。例如,一个社区及其对应的改善backlog可能专注于弄清楚怎样在Scrum项目上用最好的方式做自动测试,另一个则专注于如何培养并成为伟大的ScrumMasters,等等。

另外,对于大的转型,可以有一个主要的改善backlog——它会由主导企业整体转型的小组维护。

企业转型社区

发起、鼓励与支持企业引入和改进敏捷的小组被称为企业转型社区(Enterprise Transition Community,ETC)。企业转型社区的存在是为了创造一种文化、一个氛围——那些对企业的成功抱有满腔热情的人尝试做出改变,而这些人的成功又使更多的人产生更大的热情。ETC不是通过给企业强加变革来做到这点,而是通过指导实施变革的小组,消除障碍以便做好Scrum,利用为变革创造的活力与激情来做到这点的。

ETC的成员,通常不超过12人,他们来自参与Scrum转型的最高级别人员。如果一个公司在企业范围内实施Scrum,ETC应包括工程与开发的资深人员、产品管理、市场、销售、运营、人事等等各个小组的副总裁。如果是部门级别上实施Scrum,ETC可包括工程的副总裁和QA、开发、架构、交互设计、数据库等部门的领导。其中的关键是ETC要由转型发生所在级别的最为资深的人员组成。

有时,Scrum是由企业底层的人发起的。一个团队尝试了Scrum,很成功地完成一个项目,然后别的团队对此产生兴趣,于是Scrum就此传播开来。在这种情况下,ETC通常很自然是由一些早期倡导者组成,他们得到老板批准,可以花时间帮助其他团队学习Scrum。有时出现的障碍需要老板的支持,于是老板也要加入ETC。另外一种情况是在企业范围内实施Scrum时,当我们做出要在企业广泛的范围内实施Scrum的决定时,对ETC的成员组成可能更要深思熟虑。

ETC Sprints

因为ETC与Scrum开发团队一样使用Scrum,所以他们也通过sprints取得进展。每个ETC sprint以计划会议开始,以评审和回顾会议结束。这些会议和Scrum开发团队的那些会议完全一样,也经常发生同样的问题。来自KeyCorp(一家大型美国金融机构)的Thomas Seffernick,参加了他所在公司的ETC的第一次回顾会议。他回忆了团队如何犯下许多新Scrum开发团队会犯的一个共同错误——与演示工作中取得的进展相比,他们更愿意谈论计划。

ETC sprint的长度取决于ETC成员。通常来说,两周是最好的。这也是Ken Schwaber(2007.10)所推荐的sprint长度。Elizabeth Woodward是指导IBM大规模实施敏捷的ETC成员之一,他如下描述有关他们sprint长度的经历:

我们用过两周和四周的sprints。迄今为止,我们看到最成功的是两周的sprints。我相信其中的原因在于其“交付物”展示的良好势头和对外可见的进度。我们把各个社区的工作收集到一个简短的摘要中——它是一封能让人们在15分钟内就可读完的e-mail。

发起人和产品负责人

很多成功的Scrum案例都由一个明确的发起人启动和推进的,发起人是企业中需要对转型成功负责的一位资深人士。Salesforce.com非常成功的大规模转型就由公司的一位共同创始人Parker Harris发起。作为负责技术的执行副总裁,Harris处在一个绝佳的位置,可以来支持这样的一次变革——它会极大地改变Salesforce.com开发组织中每个人的工作方式。

发起人应与企业里正在计划实施转型的部门级别匹配。Salesforce.com需要公司管理层做发起人,这是因为其转型是整个企业范围的。如果是部门的转型,那么一个部门级别的领导是合适的选择。

发起人也是ETC的产品负责人。这意味着,有时ETC的产品负责人是对Scrum没有什么直接经验的人。不过没有关系,如同所有的产品负责人一样,ETC的发起人能够通过寻求其他ETC成员的帮助来履行这个职责。作为ETC最资深的成员,发起人将在转型实施的沟通中扮演重要的角色,但他不是孤立的,他可以得到其他人的帮助。

ETC的职责

ETC是一个工作小组,而不是决策委员会。在sprint计划时,ETC承诺完成一定量的工作,并在sprint结束时演示它们。然而,比这些ETC实际要完成的工作更重要的事情,那就是激发别人的兴趣。ETC成员靠自己只能取得一点成果,他们需要依靠组织的其他人去完成实施Scrum、走向敏捷所需要的大部分工作。变革管理专家Ed Olson和Glenda Eoyang 赞同这个观点:

“在一个自组织的系统里,领导的作用很重要,但创新和持久的变革依赖于企业中不同级别、不同位置的许多个体的工作。”(2001,5)

ETC最重要的职责之一是围绕Scrum的实施而创造活力。当然不是每个人都会为变革感到激动,但ETC需要点燃那些为成功实施Scrum而工作的人的热情。ETC成员如何做到这点?那就是展示自己的热情,以及参与正在发生的变革相关的建设性对话。为了激励企业中其他人,让他们参与到这类实施Scrum所需的创新和长期的变革中,ETC的职责包括:

  • 清楚表达背景。ETC不只是勾勒出企业敏捷的前景。它既要帮助雇员们懂得变革的需要,也要培养他们做出改变的意愿。这就需要清楚表达变革相关的背景:为什么?为什么是现在?为什么用Scrum?ETC成员用他们的资历、个人公信力和更多的东西去帮助其他人理解这些问题的答案。
  • 鼓励对话。美好的东西总在人们的对话中出现。争辩不同技术实践的好处,分享成功的故事,探讨失败原因以及一些其他的讨论会,可以产生不错的想法。
  • 提供资源。实施Scrum需要花费时间、精力和金钱。例如,试图学着怎样才能变得更敏捷的人(比如说,如何在复杂的代码库上写自动单元测试)可能需要授权获得某些开发项目以外的时间做这些事情。由于ETC包括了参与转型的大部分资深人员,它有能力确保时间和金钱两者的有效支持。
  • 设置合适的目标。具备清晰定义和确实可达目标的变革尝试能有10倍的可能性获得成功(引自:McKinsey & Company 2008)。ETC负责为转型设置合适的目标,并做好沟通。随着企业的改进,这些目标有可能(而且是应该)随着时间而变化。ETC可设立的目标包括,年度发布修改为季度发布,发布后缺陷率下降50%等等的目标。

额外的职责

除了鼓励人们参与转型外,ETC还有如下额外的职责:

  • 预料和处理人们的问题。ETC要尽可能预计到哪些小组或个人会极力抵触Scrum所带来的变化,并积极和他们一起解决问题。在这点上,跨职能的ETC人员组成结构很有好处,因为它能让小组从多角度对待问题。
  • 预计和消除阻碍。ETC成员负责消除任何实施Scrum的过程中横亘在企业前的障碍。但是ETC不光只是解决已知的问题,它还要能预计到有哪些阻碍,并在真正变成问题前解决它们。
  • 鼓励对实践和原则的同时关注。实施Scrum包括吸收新的实践,和尊重新的原则。企业不能接受没有原则指导的实践,也不能采纳没有被实践检验过的原则。一个有效率的ETC要寻找实践和原则之间的不平衡的地方。如果其中一个被接受的速度快于另外一个,则ETC通过在速度慢的那方展开对话,投入关注与资源,让两者回到同一起跑线。

改善社区

改善社区(Improvement community,IC)是由这样的一群人组成——他们聚集在一起,协作工作,以便改善企业中Scrum的使用。IC的成立,可能是因为有人开始注意到ETC改善backlog中的某个事项,并决定一起工作实现这个目标。或可能是因为有人发现了一个还没有被ETC探查到的改善机会,并对之抱有热情。例如IBM有5个IC,分别专注于测试自动化、持续集成、测试驱动开发、产品负责人的角色和Scrum自身的通常实践。

另外,请记住ETC最大的目标是创造一个环境,让改善社区能确认自己的目标,并自发地组织起来处理它们。

改善社区Sprint

你可能对改善社区是否也能用sprints工作有怀疑。从ETC来说,每个IC可以选择自己的sprint长度,但两周是被推荐的。自发组建的IC通常有自己的产品负责人,社区成员选举决定把时间投入到自己热情度最高的改善点。另一方面,如果IC是为了响应ETC指定的目标成立的,则通常会以ETC的某个成员为产品负责人,并与之一起计划sprint。

就是说,改善社区的存在不是为了服务于ETC,它是为了服务于客户:创建产品或系统的Scrum开发团队。尽管ETC成员会作为某些改善社区的产品负责人,同时也作为sprint评审的正式产品负责人,你还是希望从感兴趣的开发团队中找到可以作为活跃的sprint评审参与者。而且,聪明的ETC懂得,只有给予改善社区在实现目标的过程中广泛的自主权,它们才会取得最好的结果。这意味着在实际中,即使IC是为ETC指定的目标而成立的,也能够自己计划优先级,在企业用特定方式进行改善的需求和成员们愿在这些事情上投入工作的热情之间做出平衡。

在sprint计划会议上,每个改善社区挑出一件或多件它承诺能在这个sprint完成的目标。若改善社区是为响应ETC的某个特定目标而成立,那sprint计划可以这样开始:到ETC的backlog中挑选一个事项,把它划分成更小的事项,然后放进改善社区的改善backlog。用一个例子来说明这种情况。

在前面表1中显示的ETC改善backlog有一项“建立一份培养ScrumMaster的内部计划”。在ETC把它放入改善backlog后的一个月,一个改善社区成立了,它使公司的其余人清楚地知道发起这个计划会有价值。社区发起时只有三个人,但这已足够向该目标前进。第一次sprint计划会议上,他们讨论了ETC的“建立一份培养ScrumMaster的内部计划”的目标,创建了用于实现该目标的改善backlog,可参考表2。

图片描述

表2 改善社区“建立一份培养ScrumMaster的内部计划”的backlog

在sprint计划时,社区成员分担了表2的一些条目,并定义了实现这些条目的必要任务。例如,表2中的最后一项(与本地小组讨论以分享请人演讲的经费),社区定义了如下的任务:

  • 搜索网络看看本地有多少用户组。
  • 创建费用的预算表。
  • 发邮件给内部的贡献列表,看看这里是否有人与这些小组有联系。
  • 建立电话会议,介绍自己和我们在干什么。
  • 主导电话会议。看看是否有小组已经把邀请演讲者的费用和另一个公司一起分担。看看谁能和我们一起研究这个问题。
  • 和Susan一起检查预算并请求批准。

在开发团队的sprint计划会议上,社区评估每一事项,并决定能够承诺在sprint中完成的任务。两周后在sprint评审会议上,团队给产品负责人,也是ETC的一位成员,展示了一个本地用户组的列表,以及一个计划,该计划是关于每年和一个用户组一起工作两次,一起承担邀请全国知名的演讲者来此的经费。

大规模敏捷

通过收集国际敏捷大师Scott W. Ambler敏捷开发实践经验,整理出了大规模敏捷转型过程当中可以参考的一些模式和实践。(注:有关Ambler敏捷相关模型和理念,所有信息来自其网站www.Ambysoft.com)

主流的敏捷方法,例如Scrum,极限编程XP以及精益软件开发Lean等,其初衷更多的是面向小型的,在同一地点办公的团队,这一点从它们所提倡的很多敏捷实践也可以得到印证,例如每日站立会议,强调面对面的沟通等。目前由于来自产品质量、团队效率、按时交付等方面(正是很多敏捷实践所解决的问题)的压力,导致很多大型团队/企业开始考虑采纳敏捷实践。Agile Journal调查研究表明,有88%的公司,大部分超过一万名员工,开始在项目中使用或评估敏捷实践。敏捷已经是事实上的具统治地位的软件开发范式。但Ambysoft调查发现,只有53%的被调查者声称他们是在有效的“敏捷团队”,这意味着敏捷方法存在过度宣传、滥用或错用的情况,事实上即使采用敏捷,也依然存在大量的团队过程混乱、项目失败的现象。

敏捷绝对不是无组织无纪律的借口,事实上,主流的敏捷方法例如XP、Scrum,都定义和要求了相应的纪律和准则,甚至比起传统开发方式要求更加严格。需要指出的是,主流敏捷方法承认其并未提供足够的针对企业软件开发转型的指导,当团队成员数量超过一定规模时,需要针对敏捷方法进行很大程度的调整。同时,主流的敏捷方法只是对整个产品/项目生命周期交付中的部分阶段提出指导,更多的关注于开发过程主体,并非针对整个生命周期。因此针对这类企业进行调整和定制将花费大量人力物力,同时带来巨大的风险。

基于上述考虑,Scott W. Ambler提出了敏捷规模化模型Agile Scaling Model (ASM)的过程框架与演进路线。

敏捷规模化模型Agile Scaling Model (ASM)

敏捷规模化模型是Scott W. Ambler集多年大型组织/团队敏捷开发实践之大成者,它定义了一个路线,以指导组织和软件开发团队有效的采用和调整敏捷战略,以达成转型目标并规避风险。其路线图如下图所示。

图片描述

图1 敏捷规模化模型(Agile Scaling Model)

敏捷规模化模型定义了企业敏捷开发的三个层级,可以理解为从项目规模、团队规模、地域分布等因素衡量时,一个企业自上而下不同层面的工作重点;也同样可以理解为当企业进行敏捷转型时的不同阶段,在不同敏捷成熟度阶段,相对应的关注点。第一个层级即敏捷开发核心,这是以敏捷宣言、敏捷价值观为主的实践,具体内容可参见前面的敏捷开发知识体系核心内容。很多企业也正是从这个层面上开始进行敏捷转型的。在这个阶段,更加关注团队与个人的相关实践,特征是价值驱动,通过日常的高度协作,自组织的团队,以交付高质量的产品。通常是面对小型的团队,团员都所处同一开发场所,而产品相对直观,团队关注度在于开发环节。第二个层级即进行有纪律的敏捷交付(Disciplined Agile Delivery),将主流集中在构造实现方面的敏捷,扩展到从项目的初启直到最终交付的整个交付生命周期之上,特点是在价值驱动之上考虑风险管控以提升成功率,自组织团队之上辅以适当的管控加以平衡,由构造实现延伸到整个交付生命周期。与敏捷核心相似,这个阶段同样关注于小型同一地点开发的团队。第三个层级即Agility@Scale,是基于有纪律的敏捷交付基础上的进一步扩展。扩展性体现在例如团队规模变大,地域分布式的开发模式,领域特性进一步复杂化,技术的复杂性提升,以及企业层面,如企业架构,战略重用,组合管理等,以及合规性要求在项目中的比重逐渐上升。当存在上述一个或多个规模化变量时,组织应如何调整战略以解决团队面临的复杂性问题,是这个阶段重点解决的问题。

有纪律的敏捷交付 (Disciplined Agile Delivery,DAD)

DAD是一个演进,持续的提供高质量的产品,在整个交付生命周期以风险和价值进行驱动,在适度管控的框架下以高度协作的、有纪律的且自组织的方式运转。干系人的主动参与以保证团队理解和实现需求以及变更,最大化的提供业务价值。有纪律的敏捷交付团队能够视情况进行过程调整以提供可重复的结果质量交付。
DAD是一个混合的过程框架,吸取、重用并增强了众多主流敏捷方法的优点,例如Scrum、XP、OpenUP等的策略与实践。一个典型的重用就是DAD扩展了Scrum活动生命周期(如下图所示),Scrum以需求优先级对产品储备进行排序,以持续的时间段(Scrum称为Sprint冲刺,而其他方法例如DAD称为iteration迭代)增量的交付,举行每日站立会议,并且在每个阶段(sprint/iteration)结束进行演示以获取关键干系人的反馈。

图片描述

图2 Scrum生命周期关注构造阶段

DAD继承了上述Scrum的良好实践并加以采纳和增强,将其进行扩展到整个产品/项目交付生命周期。DAD的扩展具体体现在以下几个重要方面:

  1. 显性的定义了具体阶段:主流开发方法更多描述的是构造阶段,但事实上它们都会在项目起始阶段经历一个初始的投入——Eclipse Way的“热身”,OpenUP的初启阶段,Scrum的Sprint 0,其他方法的Iteration 0等。并且最终都有交付阶段(如果能交付的话),例如Eclipse Way的“游戏结束”。DAD将这些事实上存在,但没有具体说明的甚至被忽视的阶段,显性展示出来。
  2. DAD包含项目的初始阶段。在初启阶段的活动包括需求设定、架构设定、初始发布计划、项目预算、建立团队等。调查统计表明,敏捷团队在初始阶段的投入平均在4周左右,89%的团队会做一定的前期需求工作,而85%的团队会做前期的架构工作。
  3. DAD包含项目的发布阶段,称之为交付阶段,以向市场发布您的解决方案,典型的活动包括beta测试、最终测试、用户培训、文档定版、上线试运行等。
  4. 显性的指出生产活动。大部分敏捷交付团队对现存运行的系统版本有提供支持的责任,因而会收到运维团队提交的缺陷修正要求或者业务部门提交的增强的需求变更要求,通常这些要求会进行优先级排序并作为一个新的需求纳入产品储备中。但有些严重性极高的请求,尤其是严重的缺陷,可能要求开发团队停止手头的工作,即刻定位并解决问题,提供一个patch或是hot fix,并且将修正合并到此前的工作版本。Scott认为在交付生命周期中明确定义这样的活动会有利于对运维团队的支持。
  5. 显性的增强了产品储备(Product Backlog)。产品储备转化为了工作项列表,有纪律的敏捷团队不只是将需求纳入列表,同时也要处理来自于运维团队的要求例如缺陷和增强。
  6. 显性的包含了关键里程碑。DAD的一个重要方面是它不止提供例如Scrum的自组织,同时包括适度管控的框架。有纪律的敏捷团队是处在一个大型的组织当中,必须遵循组织的开发规范,与相关的团队之间进行信息交互,同时向高层管理者提供各种统计分析报告。

图片描述

图3 DAD关注完整的交付生命周期

有纪律的敏捷交付DAD具备一些重要特性:

  • 以人为本(People first)

敏捷开发以人为本,人的因素及其协作的方式是保障软件成功的最主要因素。这一理念也正是敏捷宣言的第一条,同样渗透在DAD的整体思想中。DAD强调由跨职能型人才组成的跨职能团队,以减少任务、文档的交接,以避免可能存在的信息缺失以及时间上的浪费,同时跨职能型人才更倾向于与他人紧密协作,分析技能与经验同时从他人那里学习新的技能。DAD的团队成员应该是自组织(self organizing,主动评估和计划自己的工作并迭代协作完成)以外,还应该是自律(self-disciplined,只对自己能完成的工作进行承诺并尽可能高效的完成)和自我意识(self aware,努力发掘对工作有利/有损的因素并相应调整)的。

  • 学习为先(Learning-oriented)

高效的组织往往是那些给员工营造了学习氛围的,学习氛围包括三个重要方面:1、领域知识学习:了解、探求干系人的领域有助于理解、鉴别和更好的实现需求;2、过程知识学习:学习如何在个人、团队和组织等层面进行促进;3、技术知识学习:学习软件开发及软件工程相关工具与技术。DAD在建立学习氛围方面也提出一些建议,例如基于web2.0的社区和工具等。

  • 敏捷(Agile)

DAD过程框架遵循并增强了敏捷宣言的价值和原则,强调干系人满意度以及提高投资回报率ROI,结合迭代的持续的交付以及测试驱动开发和回归测试以及重构等实践,强调使用自动化工具以支持相关实践并提升执行效率以及效果,这些原则也可以从下面的“混合过程模型”中也得到印证。

  • 混合的过程模型(A Hybrid process framework)

DAD从主流敏捷方法以及其他传统开发方法中汲取经验和实践并加以优化和结合,许多实践在敏捷社区广为讨论,例如持续集成、每日站立会议、重构等,其他实践可能广泛使用但由于种种原因并未广泛为人所知,例如初启需求设定、架构设定、生命周期结束循环测试等。DAD的过程框架是一个混合模型,它借鉴了众多方法论中的良好实践并将这些实践进行吸收和相互融合,Scrum是其中最重要的一个来源,DAD采纳了例如按优先级排序的产品待办列表、代表干系人的产品负责人、定期产生可交付的产品等,同时替换了一些难以理解的术语,例如用迭代Iteration替换Sprint。其他吸收的方法论思想例如极限编程的持续集成、重构、测试驱动、集体所有权等;敏捷建模的需求设定、架构设定、迭代建模、持续文档、适度建模等;敏捷数据中数据库相关的实践等;看板中的可视化工作以及在过程中限定工作两个重要概念,这也是对精益开发的七个原则的重要补充。

  • 解决方案而不仅是软件(Solution over software)

DAD过程将团队的关注点从开发软件转变为提供方案——恰好能为干系人提供真实的业务价值。软件固然重要,但解决干系人的问题并提供业务价值才是开发的最终目的,关注点的转变有助于帮助开发团队从整体角度看待软件开发过程。

  • 目标驱动的生命周期交付(Goal-driven delivery life cycle)

DAD关注完整的软件开发生命周期,明确定义不同阶段迭代的关注点不同,通过明确的定义初启、构造以及移交阶段,并定义轻量级的里程碑,保证在正确的时间关注正确的事情。这一点与主流敏捷方法只关注构造阶段有显著区别,可参考比较前面Scrum生命周期以及DAD完整交付生命周期两张图表。DAD的交付生命周期有几个重要特性:(1)完整的交付生命周期,涵盖从项目初启到方案交付;(2)显性的阶段,DAD定义的三个阶段也同样体现了敏捷的3C(coordinate-collaborate-conclude);(3)明确移交过程,DAD强调开发与交付的过程衔接以及对产品的运维提供支持,及时获取反馈并及时响应。(4)明确的里程碑,适度管控并有效减少风险。DAD是目标驱动的,组织和团队在项目的不同阶段目标是不同的,因而对过程需要加以适度调整以适应不同阶段的不同关注重心,为此DAD过程总结了如下表所示的目标映射以帮助组织和团队进行过程调整。

图片描述

图4 DAD完整项目过程关注目标

上面的表格仅列举出DAD过程的一些重要目标,下面是具体针对初启、构造以及交付的每一个过程,结合3C的节奏对其进行详细描述,详细内容请参见Scott Ambler 有纪律的敏捷交付相关白皮书,在此不做详细描述。

图片描述

图5 DAD初启迭代概览

图片描述

图6 DAD构造迭代概览

  • 风险和价值驱动(Risk and value driven)

DAD过程框架定义了轻量级的风险驱动策略,从项目伊始定位相关风险,例如干系人对项目愿景的认识,系统架构等。DAD通过吸取和扩展敏捷开发方法的最佳实践以减少风险影响:1、潜在可交付的软件,减少交付风险;2、构造阶段迭代结束时的演示,一方面获取干系人反馈,减少功能性风险,另一方面证明团队工作进展,减少政治风险;3、干系人主动参与,同样可以减少交付和功能性风险。DAD通过在交付生命周期显性的定义了轻量级里程碑,并明确在这些里程碑的考察点,以进一步消除相应的风险。

  • 企业意识(Enterprise aware)

DAD过程框架力图营造企业和组织内部的生态环境,同时强调敏捷开发团队需要与企业内部其他部门与团队以及现存系统合作,并非工作在真空中。企业意识对团队而言至关重要,因为团队要做的是如何更好的为企业创造价值,而不是只做自己感兴趣的,例如选择尝试新的技术,并非由于这些技术最适合项目,而是因为这有助于丰富自己的简历;或是选择重头做起,用全新的工具,全新的数据源,无视组织内可利用的现有系统和IT基础设施。DAD通过提倡诸如以下几点帮助提升企业意识:1、企业资产共享,有助于企业内部对资产的认知和使用;2、加强组织生态环境,增进企业内部团队间了解和写作;3、开发式、诚实的监管,建立企业内部基于“信任,但确认并加以指导”的企业监管策略,充分信任团队和个人的责任感,同时通过相关工具提高对项目和进度的信息透明度。4、风险驱动,加强预警机制,具体内容参见“风险与价值驱动”特性。

Agility@Scale

敏捷开发最初是针对小型的在一起工作的团队,同时项目规模和应用类型相对直接,而现今敏捷所面对的组织和项目都更加规模化,Agility@Scale正是解决敏捷规模化时面临的复杂性问题。当企业经历了敏捷核心到有纪律的敏捷交付的转型之后,规模化的因素将逐渐凸显,每一个因素都会带来一定范围的复杂性,团队结构以及工具环境都需要加以调整以适应这一情况。

团队规模化因素表现如下图所示,当规模化、复杂度上升到一定程度时,协作效率突然变得极富挑战性,同时信息流转变得困难,对开发过程管理及沟通提出更高要求,同时需要通过一定技术手段或实践方法来消除急剧上升的开发风险,例如采用构建原型、系统建模以及仿真等方式保证质量。当涉及到众多现有系统,扩展性良好的架构设计固然重要,同时需要考虑跨部门跨流程的协作问题。此外,企业不同产品、系统彼此之间市场定位、战略规划以及产品组合管理等都是需要进入企业/组织视野的。

图片描述

图8 Agility@Scale

Scott W. Ambler用一个Agile Online Bartering的例子来描述大规模的敏捷过程(参见”IBM agility@scale: Become as Agile as You Can Be”)。在此案例中Scott描述了分布式的团队在处理一个复杂系统项目时的实践,包括团队分布,团队分工,分布式团队之间的沟通与协作包括其频度,每一个迭代所关注的事情,迭代结束所进行的演示的目的及取得的结果,对合规性要求的考虑,持续集成的方式,以及部分采用的工具。这样一个案例,可以作为组织在面临类似项目时的一个参考。

Scott同时对企业进行大规模敏捷实践提出了相应的建议:

  1. 提高才是目的。敏捷做的再好也不会有人给你颁发金牌,除非是因为高效的提交了项目/产品,敏捷技术能在这一点上帮到你,但不要忘了传统社区、传统方法论同样有很多非常好的行之有效的方法,不要由于它们不属于敏捷的范畴就进行排斥。
  2. 要有计划。要帮助你的过程改进成功实施,你必须首先决定你的目标是什么,当前状态以及面临哪些挑战。
  3. 获取经验。用一个或数个中等风险的敏捷试点项目以获取组织层面的经验,并培养相关专家,同时做好思想准备,试点项目不可能尽善尽美,遇到一些问题是正常的。
  4. 显性的管理过程改进的付出。定期的总结和识别潜在的改进,并付诸行动,是广为证实的经验,明确的记录改进进展更容易帮助团队取得成功。
  5. 对员工进行投资。企业/组织需要训练、培养、指导员工敏捷的理念,过程,时间以及工具。先在试点项目试点团队进行适度培训,再由此向整个组织层面推广,不要忘记包括高级领导、项目管理者以及任何相关干系人。

点击下载《敏捷软件开发知识体系》PDF版

2017-02-16 17:29:00 xiaoxiaoyusheng2012 阅读数 322


转自:http://blog.csdn.net/uxyheaven/article/details/49618097

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

敏捷开发工程实践

项目管理

  • 迭代开发
  • 风险价值生命周期
  • 多级项目规划
  • 完整团队
  • 每日站立会议
  • 任务板
  • 燃尽图

需求管理

  • 需求订单
  • 业务流程草图
  • 用例驱动开发
  • 用户故事

架构

  • 演进的架构
  • 演进的设计
  • 基于组件的架构设计

开发

  • 结对编程
  • 测试驱动开发
  • 重构
  • 代码规范

测试

  • 单元测试
  • 并行测试
  • 测试管理

变更管理

  • 持续集成
  • 自动构建
  • 团队变更管理

敏捷开发管理实践描述

  • 定义和特征说明
  • 主要角色
  • 主要活动和最佳实践
  • 主要输入输出
  • 工作流程

敏捷开发工程实践描述

  • 定义和特征说明
  • 应用说明
  • 案例说明

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

敏捷软件开发宣言

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

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

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

核心价值观

  • 以人为本
  • 目标导向
  • 客户为先
  • 拥抱变化

敏捷开发的原则

  • 我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意。
  • 欣然面对需求变化,即使在开发后期也一样。为了客户的竞争优势,敏捷过程掌控变化。
  • 经常地交付可工作的软件,相隔几星期或一两个月,倾向于采取较短的周期。
  • 业务人员和开发人员必须相互合作,项目中的每一天都不例外。
  • 激发个体的斗志,以他们为核心搭建项目。提供所需的环境和支援,辅以信任,从而达成目标。
  • 不论团队内外,传递信息效果最好效率也最高的方式是面对面的交谈。
  • 可工作的软件是进度的首要度量标准。
  • 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
  • 坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强。
  • 以简洁为本,它是极力减少不必要工作量的艺术。
  • 最好的架构、需求和设计出自自组织团队。
  • 团队定期地反思如何能提高成效,并依此调整自身的举止表现。

敏捷开发管理实践

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还必须仔细考虑进展中的开放任务数,进展中的工作需要得到最小化,以实现精益生产率的收益。
  • Scrum Master需要找出阻碍Scrum的障碍和依赖。他们需要的优先次序和跟踪。根据优先级指定计划解决这些障碍。其中有些问题可以在团队内部解决,有些则要团队之间的协调,还有的要管理层的介入来解决.

开发团队 (Scrum Team)

  • 具有不同特长的团队成员,人数控制在5-7个左右, 跨职能, 包括开发, 需求, 测试
  • 弱化分工, 每个人都参与设计, 开发与测试
  • 确定Sprint目标和具体说明的工作成果。
  • 在项目向导范围内有权利做任何事情已确保达到Sprint的目标。
  • 向Product Owner演示产品功能。

团队素质完整性

  • 要具备很强的集体协作精神.
  • 要具备良好的沟通能力
  • 必须能积极主动的接受新的事物, 要具备创新能力
  • 要具备极强的自我管理能力和积极主动的精神

沟通的完整性

  • Sprint启动会
  • 每日站立会议
  • Sprint回顾会

案例

验收测试驱动开发ATDD

TDD 只是开发人员的职责,通过单元测试用例来驱动功能代码的实现。ATDD在准备实施一个功能或特性之前,首先团队需要定义出期望的质量标准和验收细则,以明确而且达成共识的验收测试计划(包含一系列测试场景)来驱动开发人员的TDD实践和测试人员的测试脚本开发。面向开发人员,强调如何实现系统以及如何检验。

  • 挑选用户故事
  • 为故事写测试
  • 实现测试
  • 实现故事

结对编程

结对编程可以看做是一种敏捷化的Code Review

新结对编程

两位程序员新成结对小组, 每人一台电脑, 坐在临近的工位上, 两人合作完成一组功能(可以是两个或多个独立的模块)的设计, 代码实现. 但对已某一个模块来说设计和代码是分开的, 一个人负责设计, 另一个人负责写代码, 对于其他模块则反之.

确定冲刺计划

定义和说明

  • 目的: ST和PO共同决定在接下来的冲刺周期内的目标以及那些功能和任务需求要完成
  • 主要角色: ST, PO, SM
  • 主要输入: Product backlog, 团队的能力
  • 主要输出: Sprint Backlog

冲刺会议分两个部分 
1. 解决本次冲刺要完成哪些需求 
2. 解决这些选择的需求要如何被完成

案例

故事点估算

故事点是表述一个用户故事, 一项功能或一件工作的整体大小的一种度量单位. 数值本身不重要, 重要的是这些故事之间对比体现相对大小.

计划扑克

  • 开始时, 美人得到一张扑克, 上面有任务点(?, 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, 无穷).?代表无法估算, 无穷代表故事太大
  • 开始对故事进行估算, 先由PO介绍这个故事的描述. 接着澄清问题
  • 每一个组员从扑克中挑选可以代表这个故事的卡片, 集体亮牌
  • 最高分和最低分的组员像团队做出解释
  • 全组成员自由讨论几分钟
  • 重新打分, 直到全组统一.

敏捷估算2.0(Agile Estmating 2.0)

  • PO像团队成员介绍每一个用户故事, 确保所有需求相关的问题都在做估算前得到解决
  • 整个团队参与游戏: 一次由一人将一个故事卡片放在合适的位置, 规模小的在左,规模大的在右, 一样大的竖排. 轮流移动故事卡片, 直到整个团队都认同白板上故事卡的排序为止.
  • 团队将故事点(Story Point)分配给每个故事.

需求订单(Product Backlog)

记录用户需求的列表, 包括产品所有需要的特征.

  • 每一项包含了需求标题, 描述, 重要性, 故事点(或其他表示大小的数字)
  • 需求订单式开放的, 团队每个成员都可以编写和维护
  • 在整个项目开放生命周期内, 需求订单需要不断维护, 管理与跟踪需求变化

燃尽图

在项目完成之前, 对需要完成的工作的一种可视化表示. 燃烧故事点.每天更新一次

  • 具备可视性
  • 具备风险预估, 提醒团队目前完成情况
  • 具备可估量, 直接显示当前还需要的时间.

燃尽图常见问题

每日站立会议(Daily Scrum)

每日站立会议旨在让团队统一目标, 协调内部问题的解决, 绝非进度汇报.一般不超过15分钟.

  • 我们上次开会后你都干了什么
  • 在我们下次开会之前你要做什么
  • 每个你负责的、正在做的任务还剩下多少时间
  • 你的工作被阻碍了吗

任务板(Task board)

  • 为项目团队提供一个便利的工具用于管理他们的工作
  • 是团队成员对本冲刺的工作一目了然

任务板通常设立与项目团队日常工作的公共空间的一面墙上. 任务板上得信息包括该冲洗计划完成的用户故事和相应的任务, 分别卸载卡片上, 按照一定的方式贴在任务板上(To Do, In Progress, Done). 团队成员通过调整任务卡得位置和上面的信息反映任务的执行情况.

用户故事卡

每张卡片记录一条用户故事, 故事点.

任务卡

每个用户故事卡片通对应的多个任务卡. 每张卡片记录一条任务, 到目前为止完成该任务所需的工作量(小时).随着进展试试更新.

任务板的使用

用户故事

作为<某个角色>, 我希望<实现何种功能>, 以便<带来何种价值>.

如: 作为一个用户, 我希望在每次退出系统前得到是否保存的提示, 以便所有内容都被成功存储了.

测试驱动开发(TDD)

先开发测试用例, 然后再开发代码