敏捷开发整体计划_敏捷开发计划纸牌 - CSDN
  • 敏捷开发和迭代开发

    2019-06-27 17:05:44
    敏捷开发与迭代式开发是整体与局部的关系 敏捷开发敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发,在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试...

    敏捷开发与迭代式开发是整体与局部的关系

     

    敏捷开发:敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发,在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。敏捷开发过程中,只有开发团队,没有各个开发环节工种(分析师、设计师、架构师等)的划分,所有的工作都是团队会议明确、按照时间节点和任务节点交付。敏捷开发是针对传统的瀑布开发模式的弊端而产生的一种新的开发模式,目标是提高开发效率和响应能力。除了原则和实践,模式也是很重要的,多研究模式及其应用可以使你更深层次的理解敏捷开发。

    迭代开发:每次只设计和实现这个产品的一部分, 逐步逐步完成的方法叫迭代开发, 每次设计和实现一个阶段叫做一个迭代。在迭代式开发方法中,整个开发工作被组织为一系列的短小的、固定长度(如3周)的小项目,被称为一系列的迭代。每一次迭代都包括了需求分析、设计、实现与测试。迭代是敏捷开发中被划分出来的一个周期实现方式。可理解如下: 迭代一般指某版本的生产过程,包括从需求分析到测试完成; 版本一般指某阶段软件开发的结果,一个可交付使用的产品。迭代开发和敏捷开发都是弥补了传统开发方式中的一些弱点,具有更高的成功率和生产率。

     

    1、在项目初期先挑选系统核心架构的需求来实现,待系统核心架构完成后,再在系统核心架构的基础上不断的添加其他功能模块,通过累加开发的方式,来不断的完善系统,并在完善系统时,对系统的瑕疵或不足,不断的进行重构和改进设计工作。通过多个迭代的敏捷开发,并且每个迭代都会产生一个可使用的产品。这样一来,我们就会达到降低产品开发风险的目的。

     

    敏捷建模不可缺少,UML规范就是给我们提供建模标准的,建模不但能够促进你团队内部的开发人员之间沟通、还能够促进你的团队和你的project stakeholder之间的沟通,通过画一两张图来代替几十甚至几百行的代码,建模成为简化软件和软件(开发)过程的关键,而且比代码更容易控制和改变。这一点对开发人员而言非常重要-它简单,容易发现出新的想法,随着你(对软件)的理解的加深,也能够很容易的改进。

    3、有目的的建模,开发软件需要使用多种模型,因为每种模型只能描述软件的单个方面,但是要特别强调,我们没有必要每次应用所有的模型,而应该针对系统的具体情况,挑选能够解决问题的模型,不应该毫无意义的建模。首先,你要确定建模的目的以及模型的受众,在此基础上,再保证模型足够正确和足够详细。只要基于现有的需求进行建模,日后需求有变更时,再来重构这个系统。尽可能的保持模型的简单和完整。

    4、并行创建模型,和团队他人一同开发模型,你的想法可以立刻获得反馈,特别是你的工作采用了共享建模技术的时候由于每种模型都有其长处和短处,没有一个模型能够完全满足建模的需要。例如你在收集需求时,你需要开发一些基本用例或用户素材,一个基本业务流程等。敏捷建模者会发现在任何时候,同时进行多个模型的开发工作,要比单纯集中于一个模型要有效率的多。

    5、持续测试和集成,每个迭代,我们都在做增加新功能和变更需求,产生新的版本,因此不断进行测试和集成,已达到可交付的产品,但是无论如何变更,模型都可以是最轻量级的持续改进,以保证最终的完整性和准确性。

     

    针对中大型的软件开发来说,用例驱动、架构为中心的,无论是从需求用例还是测试用例,都可以统一对应,保证过程的完整统一。敏捷开发是一个轻装前进的过程,每一个过程都只关注当前的任务,但是在开始之前,我们必须要高瞻远瞩,综合评定,无论是在一开始的架构模型还是开发过程中的每一个系统模型,都要有合适的取舍,但是也要有考虑可扩展,可变更,可迭代的过程。

     

     

    传统的瀑布式开发,也就是从需求到设计,从设计到编码,从编码到测试,从测试到提交大概这样的流程,要求每一个开发阶段都要做到最好。
    特别是前期阶段,设计的越完美,提交后的成本损失就越少。

    迭代式开发,不要求每一个阶段的任务做的都是最完美的,而是明明知道还有很多不足的地方,却偏偏不去完善它,而是把主要功能先搭建起来为目的,以最短的时间,
    最少的损失先完成一个“不完美的成果物”直至提交。然后再通过客户或用户的反馈信息,在这个“不完美的成果物”上逐步进行完善。

    螺旋开发,很大程度上是一种风险驱动的方法体系,因为在每个阶段之前及经常发生的循环之前,都必须首先进行风险评估。

     

    敏捷开发优点:

     1、降低风险
      2、得到早期用户反馈
      3、持续的测试和集成
      4、使用变更
      5、提高复用性
    --------------------- 
    作者:ouyanghaitao 
    来源:CSDN 
    原文:https://blog.csdn.net/ouyanghaitao/article/details/84923309 

    展开全文
  • 敏捷开发知识体系整体框架 敏捷开发工程实践 项目管理 迭代开发 风险价值生命周期 多级项目规划 完整团队 每日站立会议 任务板 燃尽图 需求管理 需求订单...

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

    敏捷开发工程实践

    项目管理

    • 迭代开发

    • 风险价值生命周期

    • 多级项目规划

    • 完整团队

    • 每日站立会议

    • 任务板

    • 燃尽图

    需求管理

    • 需求订单

    • 业务流程草图

    • 用例驱动开发

    • 用户故事

    架构

    • 演进的架构

    • 演进的设计

    • 基于组件的架构设计

    开发

    • 结对编程

    • 测试驱动开发

    • 重构

    • 代码规范

    测试

    • 单元测试

    • 并行测试

    • 测试管理

    变更管理

    • 持续集成

    • 自动构建

    • 团队变更管理

    敏捷开发管理实践描述

    • 定义和特征说明

    • 主要角色

    • 主要活动和最佳实践

    • 主要输入输出

    • 工作流程

    敏捷开发工程实践描述

    • 定义和特征说明

    • 应用说明

    • 案例说明

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

    敏捷软件开发宣言

    • 个体和互动 高于 流程和文档

    • 工作的软件 高于 详尽的文档

    • 客户合作 高于 合同谈判

    • 响应变化 高于 遵循计划

    • 也就是说, 尽管右项有其价值, 我们更重视左项的价值.

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

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

    核心价值观

    • 以人为本

    • 目标导向

    • 客户为先

    • 拥抱变化

    敏捷开发的原则

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

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

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

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

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

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

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

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

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

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

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

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

    敏捷开发管理实践

    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)

    blob.png

    主要输入输出

    • 产品订单(Product Backlog)

    • 冲刺订单(Spring Backlog)

    • 燃尽图(Burndown Chart)

    • 新的功能增量

    工作流程

    项目管理过程

    • 在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)

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

    展开全文
  • 什么是敏捷开发

    2019-05-31 10:49:56
    敏捷开发(Agile)是一种以人为核心、迭代、循序渐进的开发方法。 在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。 简单地来说,敏捷开发并不追求前期完美...

    敏捷开发(Agile)是一种以人为核心、迭代、循序渐进的开发方法。

    在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。

    简单地来说,敏捷开发并不追求前期完美的设计、完美编码,而是力求在很短的周期内开发出产品的核心功能,尽早发布出可用的版本。然后在后续的生产周期内,按照新需求不断迭代升级,完善产品。

    是谁这么厉害,提出了敏捷开发思想?是一位名叫 Martin Fowler 的美国大叔。

    大叔不但是敏捷开发的创始人之一,还在面向对象开发、设计模式、UML 建模领域做出了重要贡献。目前担任 ThoughtWorks 公司的首席科学家。

    敏捷开发模式的分类
    敏捷开发的实现主要包括 SCRUM、XP(极限编程)、Crystal Methods、FDD(特性驱动开发)等等。其中 SCRUM 与 XP 最为流行。

    同样是敏捷开发,XP 极限编程 更侧重于实践,并力求把实践做到极限。这一实践可以是测试先行,也可以是结对编程等,关键要看具体的应用场景。

    SCRUM 则是一种开发流程框架,也可以说是一种套路。SCRUM 框架中包含三个角色,三个工件,四个会议,听起来很复杂,其目的是为了有效地完成每一次迭代周期的工作。在这里我们重点讨论的是 SCRUM。

    SCRUM 的工作流程

    学习 Scrum 之前,我们先要了解几个基本术语:

    Sprint:冲刺周期,通俗的讲就是实现一个“小目标”的周期。一般需要 2-6 周时间。
    User Story:用户的外在业务需求。拿银行系统来举例的话,一个 Story 可以是用户的存款行为,或者是查询余额等等。也就是所谓的小目标本身。
    Task:由 User Story 拆分成的具体开发任务。
    Backlog:需求列表,可以看成是小目标的清单。分为 Sprint Backlog 和 Product Backlog。
    Daily meeting:每天的站会,用于监控项目进度。有些公司直接称其为 Scrum。
    Sprint Review meeting: 冲刺评审会议,让团队成员们演示成果。
    Sprint burn down:冲刺燃尽图,说白了就是记录当前周期的需求完成情况。
    Release:开发周期完成,项目发布新的可用版本。
    在这里插入图片描述
    如上图所示,在项目启动之前,会由团队的产品负责人(Product owner)按照需求优先级来明确出一份 Product Backlog,为项目做出整体排期。

    随后在每一个小的迭代周期里,团队会根据计划(Sprint Plan Meeting)确定本周期的 Sprint Backlog,再细化成一个个 Task,分配给团队成员,进行具体开发工作。每一天,团队成员都会进行 Daily meeting,根据情况更新自己的 Task 状态,整个团队更新 Sprint burn down chart。

    当这一周期的 Sprint backlog 全部完成,团队会进行 Spring review meeting,也就是评审会议。一切顺利的话,会发布出这一版本的 Release,并且进行 Sprint 回顾会议(Sprint Retrospective Meeting)。

    那么,现实中的 Scrum 是什么样的情景呢?看看下面的照片就知道了:
    在这里插入图片描述
    敏捷开发与 DevOps
    DevOps 是 Development 和 Operations 的合成词,其目标是要加强开发人员、测试人员、运维人员之间的沟通协调。如何实现这一目标呢?需要我们的项目做到持续集成、持续交付、持续部署。

    时下流行的 Jenkins、Bamboo,就是两款优秀的持续集成工具。而 Docker 容器则为 DevOps 提供了强大而有效的统一环境。
    在这里插入图片描述
    在这里插入图片描述

    展开全文
  • 敏捷开发知识体系整体框架敏捷开发工程实践项目管理 迭代开发 风险价值生命周期 多级项目规划 完整团队 每日站立会议 任务板 燃尽图 需求管理 需求订单 业务流程草图 用例驱动开发 用户故事 架构 演进的架构 演进的...

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

    敏捷开发工程实践

    项目管理

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

    需求管理

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

    架构

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

    开发

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

    测试

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

    变更管理

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

    敏捷开发管理实践描述

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

    敏捷开发工程实践描述

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

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

    敏捷软件开发宣言

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

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

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

    核心价值观

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

    敏捷开发的原则

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

    敏捷开发管理实践

    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)

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

    展开全文
  • 敏捷开发,瀑布式开发,XP,TDD,SCRUM,Lean,FDD,DSDM你了解多少?本篇文章是有关敏捷软件开发方法学及应用的基础知识。敏捷开发是有关团队怎么样合作去实现一个常规目标。敏捷开发并不仅仅适用于软件开发者,也...
  • 敏捷开发实战经验

    2018-05-30 18:22:35
    敏捷开发越来越火热,但在实际应用当中很多时候都是只有敏捷的“形”,却缺少敏捷的“神”,还只是在摸索中。敏捷开发对产品经理/程序员的要求都是很高的,此外还需要各个... 在《Scrum:兼顾计划与灵活的敏捷开发...
  • 本博将通过 讲解敏捷开发概念->敏捷开发架构思想->开发环境搭建->项目源码敏捷开发构建、拆分 等逐步带您走进android敏捷开发的世界。 学敏捷开发,开启 架构师之路..(夸张了呵呵,其实没有,这是基础) 注:本系列...
  • 敏捷开发 vs 传统模式

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

    2019-09-02 10:34:44
    敏捷开发  敏捷开发,现在大多数团队都在推崇敏捷开发模式  笔者最开始理解的时候,也在疑惑到底什么是敏捷开发,带来的好处又是什么?  笔者也只是一个入行没多久的新手,以下只是笔者自己对于敏捷开发的一些...
  • 传统的软件开发模式需要经历问题评估、计划解决方案、设计系统架构、开发代码、测试、部署和使用系统、维护解决方案等过程,如下图↓ 采用传统软件开发模式的最大问题是开发周期过长,迭代速度慢。移动互联网行业...
  • 1,提要 软件开发是一个系统工程,包括最初的可行性分析、再到设计、开发、测试、维护等整个生命周期。在这个过程中某些阶段的失误或说是变化,都可能增加...传统瀑布模式和新型的敏捷开发就是其中最常用的方法,后
  • 说一下你对敏捷开发的理解,为什么要使用敏捷开发? 》瀑布模型的典型问题就是周期长,发布烦,变更难。 》敏捷开发就是快速迭代,持续集成,拥抱变化。     所谓“敏捷”,顾名思义,可以通俗...
  • 接下来,将由浅入深地来分析分析敏捷开发的基本概念,然后说明一下敏捷开发的代表–XP(极限编程)与Srcum过程。敏捷开发概念与价值观敏捷开发运动历史相对于整个软件开发而言算是较为悠久的,其真正开始的标志是01年2...
  • 敏捷开发中的PO即Product Owner,产品或业务负责人,即熟悉该产品所有业务相关的逻辑、流程、设置等方面事宜的人员,一般可由产品经理担任,也可由熟悉业务的开发人员担任。如果敏捷团队是在一起办公的,建议由产品...
  • 2018年,力软敏捷开发框架的APP在线制作平台已经逐步成熟。你不需要任何的编程技术,自己就可以通过力软敏捷开发框架上面的APP应用,拼图式自己快速搭建出一个手机互联网APP。 在整体框架都已经搭建好了,开发者...
  • 前段时间给大家整理了敏捷开发的流程,最近在整理敏捷开发项目的流程和管理制度,其整理的项目管理规程如下,这份规程也不完全算是敏捷专属的项目管理规程,主要是在结合我们公司实际的情况下编写出来的,大家在实际...
  • ThoughtWorks的敏捷开发

    2018-07-23 11:19:45
    ThoughtWorks的敏捷开发方法一直是一种神秘存在。在敏捷开发还没有主流化的年代,为了让外界理解ThoughtWorks全球团队怎么做敏捷,我们商定了一个“60% Scrum + 40% XP”的经典答案。当然其实ThoughtWorks的敏捷开发...
  • 一 引言 近来,在BOSS系统团队敏捷开发熏陶和感染下,对敏捷开发求知是蠢蠢欲动. 心动不如行动. 咱也不能被动接受挨打吧. 这几天向战斗在BOSS一线具体参入人员问了卷,实施敏捷开发大哥们们请教. 感觉是个好东西.它是...
  • 如何理解敏捷开发

    2019-01-04 16:16:15
    一、什么是敏捷开发敏捷开发,以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。 二、敏捷开发的特点 敏捷是以人为中心的软件开发方法,保持简洁的代码,经常性测试以及及时地交付应用的功能...
1 2 3 4 5 ... 20
收藏数 32,141
精华内容 12,856
关键字:

敏捷开发整体计划