2015-11-03 16:30:22 uxyheaven 阅读数 17959
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10427 人正在学习 去看看 CSDN讲师

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

敏捷开发工程实践

项目管理

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

需求管理

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

架构

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

开发

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

测试

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

变更管理

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

敏捷开发管理实践描述

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

敏捷开发工程实践描述

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

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

敏捷软件开发宣言

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

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

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

核心价值观

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

敏捷开发的原则

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

敏捷开发管理实践

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)

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

2010-08-05 14:58:00 ws715 阅读数 3052
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10427 人正在学习 去看看 CSDN讲师

一  引言
  
      近来,在BOSS系统团队敏捷开发熏陶和感染下,对敏捷开发求知是蠢蠢欲动. 心动不如行动. 咱也不能被动接受挨打吧. 这几天向战斗在BOSS一线具体参入人员问了卷,
实施敏捷开发大哥们们请教. 感觉是个好东西.它是对传统的以瀑布模式为主的项目管理一次抽取精华和改进(个人认为,PMB项目管理的理念,敏捷开发中具体方法都有它的影子,只是浓缩精华).但觉得脑子里只是一些零散的概念,没有对敏捷开发系统理解。没有整体把握,底气不足,作为敏捷开发中注重以人为主,团队自管的思想, 咱也提不出好的改进意见 . 不利于敏捷持续发展. 于是利用中午和晚上时间在网上下载一些敏捷开发文档学习 , 赶快来武装自己。与时俱进,落后就要挨打哦!
 
   系统学习了敏捷中两个方法(极限编程和Scrum),结合以前学习的pmb以传统的过程为主,强调文档:一个阶段的输出就是下一个阶段的输入,文档是个阶段衔接的唯一信息。
有点像工厂流水线作业. 这一综合,思想就有点火化了。感触敏捷开发体现了一些我们平常生活、人生哲理。就不再太罗嗦,言归正卷了。
 
    
二  敏捷开发所体现的哲理
 
    1、与时俱进,不断改进,不断完善理想
 
       敏捷开发中一个重要的思想就是要在具体项目中不断改进。主张要不断完善,发现问题,勇于针对具体的问题,引起敏捷方法实践
     勇于重构代码。这些理念在我们生活中也同样受用。古人云:知错就改,人无完人。也是要求我们要勇于承认自己的不足,只要我们有勇气
     发现问题,分析问题,勇于改进。这样我们才能够前进。哲学上讲矛盾的原理也是一样的。
 
    2、集中力量解决重点问题,小步前进,稳扎稳打,步步为营
      
      敏捷开发注重迭代开发,增量的进行工作,小步前进,不停的思考、反省和总结,不停地进行自我调整、完善、改进. 这种方法很明显是能够
    及时发现问题、总结问题,降低项目中的需求风险和开发进度风险(需求列表排了优先级,前期就可以把客户确认的重点需求投入精力做好,
    后面迭代sprint周期能够根据前一个周期srpint情况来及时调整和改进).
 
    3、注重以人为本的思想,注重参入、沟通、反馈
 
        敏捷开发中的极限编程方法论中实践原理中很多体现了这些理念。如:让客户编写user Story,让客户参入具体的功能需求编写过程中;sprint周期
    中定期加强为客户的沟通;客户与开发人员尽量在一起办公;开发人员集中办公,及时沟通;结对编程;隐喻(一些好的规范,专业术语提前在团队
    中集成共识) ,代码共用,晨会等.
        
         这些方法在我们实际生活同样实用.毕竟任何东西还是要由人来做的。因此在各个场合都会存在调动人的积极因素来影响环境和事物。
 
     4、简单原则
 
          极限编程体现跟踪客户的需求变化,既然需求是变化的,所以对于目前的需求就不必过多地考虑扩展性的开发,讲求简单设计,
     实现目前需求即可。简单设计的本身也为短期迭代提供了方便,若开发者考虑“通用”因素较多,增加了软件的复杂度,开发的

     迭代周期就会加长。简单设计包括四方面含义:

                  1、通过测试。2、避免重复代码。3、明确表达每步编码的目的,代码可读性强。

 

       简单哲理在我们生活中也是无处不见,感觉最明显是我们穿的衣服更简朴和舒适,更适合我们个性展示;还有大家经常说复杂问题简单化,简单生活,

    快乐生活等都体现对人生豁达、快乐的态度.

 

     ......

 

三  建议

 

    1、民主参入度有待加强

      

       这几天我问了近十几位一线参入BOSS和CRM敏捷开发人员(大部分是合作方)。主要涉及对敏捷的认知,参入度,参入角色等。发现大家基本还是认同敏捷,

      但是对一些具体的实践方法还是存在模糊的认识,甚至抵触心理。比如:结队编程 (实际上结队编程在运用时是要根据实际情况而定,有一定边界条件。

      像对新员工,对核心关健业务,对sprint迭代检查过程中发现大家编程问题等,这时可以实施结队编程).其次有就是对敏捷基本都没有一个完整的概念。如:

      敏捷中的基本思想,敏捷中几个主要方法,敏捷每个方法用途和使用的条件等。最后,就是参入访问的人基本都没有接触过敏捷开发软件,对一些天天写在墙上的

      “燃尽图”都不知道,缺少参入意识(写这个时,徐志明发Mingle的使用知会,希望大家在使用这个软件时对敏捷起到加深理解作用。应早该一点发给我们啊!) 。

 

        a  敏捷开发人员是以人为本,着重的实施还是得靠大家,需要大家共同的参入、支持和理解。希望领导在具体实施过程中让更多的人参与进入。

             参入过程中要加强PL的职责和引导大家作用。让更多一线工作人员,特别是合作方,有一个认同感,尊重感。调动他们的积极性和主动性

        b  加强团队组织建设,落实负责人责任制。现在感觉BOSS团队上层参入讨论敏捷很活跃,根据实际的项目运用了敏捷开发中权限编程、Scrum和传统方法结合,

           政策和方向都是正确的,但是到下面pl下一级具体落实下,需要pl对敏捷开发能够灵活运用,引导本组人员进行敏捷开发学习,讨论、参入.

 

    2、 每日晨报内容要根据具体的情况而定

 

       我们进行的晨报大家现在都认可了,大实现中也取得一定效果。但是感觉有些组还是基于它所表现的三种基本的形式(今天做了什么,明天做什么,所遇到困难).

       个人觉得晨报的内容要根据项目、各个小组具体的情况而定,不可一概而定,基于形式。

 

          a、 根据sprint周期后总结中发现问题,针对性在下一阶段的sprint周期中引入晨报内容。如:在sprint周期总结中发现大家编程不规范,在Daily Scrum meeting

              注重检查编码规范问题;如:上次CRM团队检查代码质量时发现一些问题,在下几个Daily Scrum meeting中注重检查代码质量问题,至到问题解决为至。

         

          b、 根据项目开发不同阶段制定Daily Scrum meeting;

 

         个人认为引为这个东东,还是为了解决问题。在过程中不断改进。

 

    3、 技术专家人员支持、重视有待加强

 

         来华为两年了,感觉这边是很重视业务的,不注重技术。毕竟BOSS业务比较复杂,业务重要是不言而遇。但是在实际的BOSS维护中,发现很多的二线问题、bug单

       都是由技术引起。而一些有经验的老员工,管理人员很少参入到技术当中把关。以至BOSS一些问题单每月每天循环出现。虽然现在引入了测试驱动开发、持久集成等

       方法,但是一些核心业务还是需要技术专家来监督。

 

       a 、 对一些核心代码,关键业务,除了要进行测试外,更重要是专家技术人家承担起负责,对其功能指导、监督、检查,

            必要时可结队编程;

       b、  在团队内部要形成一种气氛和文化,技术和业务都重要。甚至在待遇方面要落实;

 

    .............

 

     看见BOSS团队根据我们实际出发引入敏捷开发,甚感高兴,有喜的事,现在已取一定成果。愿我以上的感悟对我们团队有所帮助和启发

2012-07-30 15:41:59 DrifterJ 阅读数 3195
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10427 人正在学习 去看看 CSDN讲师

公司所有开发组目前都在提倡敏捷开发,我所在的开发组也没有out,刚刚发版的产品我们就引入了敏捷开发的一些概念--虽然还比较粗糙,但整体感觉还是蛮好的。发版后,有一段空闲期,闲来无事,看到同事桌上有本《轻松Scrum之旅--敏捷开发故事》,就借过来读了一下,通篇就是一个产品的敏捷开发过程,从概念和使用方法上看,能有不小收获。这次就写一下自己初次体验敏捷的一些感受和这本书的一点读后感。

先说一下自己在实际开发中的一些感受吧。

敏捷开发整体来说是一种思想,但凡是思想的东西就不会局限于某种或某几种应用之上。敏捷也不例外,软件开发作为一种智力工程,只是敏捷的一个应用而已。具体到实际的应用,思想就会被具化为一些行之有效的手段和指导原则。敏捷在实际软件开发有XP,RUP,Scrum等多种应用框架,这些框架基本都是一些指导原则的集合,我们实际开发中采用了Scrum,但中间也采用了其他框架的一些非常优秀的指导原则!这其实也体现了敏捷的部分思想:不拘泥于形式!

使用Scrum,首先要有功能看板,现在有很多软件形式的看板,我们第一次使用敏捷,果断没有使用这种看板,而是采用了更具视觉冲击力的实物看板,我们开发经理用周末打造了如下看板:

上面就是我们组大而帅的功能看板,那他的作用是啥呢?上面在不同格子上贴的便签又是啥呢?我先简介概括一下我们使用敏捷的步骤,这些问题你就会有了答案的。

我们第一次是这样使用Scrum的(其中的一些步骤和涉及到的用词和标准Scrum有所区别,这个我后面会分析):

1》 部门经理,开发经理,需求人员将产品进行分解,分解为一些较大的点,然后根据重要性和难易度将这些点分为3个迭代周期,即3个迭代周期后,产品整体及出炉了。

2》 开始每一次迭代前,部门经理,开发经理会将这个迭代的大点进行细分成一些小点,大小通常控制在1~3天。

3》 开始具体一次迭代,我们首先会开一个任务分配会议,时长大约1个多小时,开发经理给出所有的上述分解出的小点,挨个“招标”。如果有人感兴趣,举手示意即可,对于没人认领的点,开发经理最后会根据时间,强制分配给某人。

4》 开始迭代,首先所有人将自己的开发点写在便签上,并且贴在上述看板自己对应行的【准备】列中。这个看板“行”是和开发人员对应的,一人一行。“列”是和任务过程对应的,通常包括:准备;进行中;自测;完成。

5》 每天早晨9:00,开发经理会组织所有开发人员在看板前集合,举行每日例会,时长通常在20-30分钟。每个开发人员必须发言,发言内容为:昨天我做了什么事情,我遇到了什么困难,今天我要做什么事情。说的过程,同时移动任务便签到看板相应的列上。每个任务便签上都写有该任务的完成时间,如果开发时间和进度不匹配,开发经理会立即发现并进行沟通。

6》 一次迭代完成后,部门经理,开发经理,需求人员,所有开发人员,测试人员会开一次评审会议,时长大约2个小时,这期间主要是开发人员向所有与会者展示这次迭代的开发成果。测试人员也了解一下产品的使用方法,便于马上开展的测试工作。

这就是我们的敏捷过程,借用部门经理的话,这就是“山寨版”敏捷......但我们还是在这几条步骤下,经过3次迭代,产品成功发版了。其中也遇到了一些问题,比较典型的如下:

1》 任务分解粒度太粗!2~3天的任务,通常会产生拖延,因为这个时间本身就是估算的,任务时间长,说明其包含的功能点多,每个功能点有一点延迟,整个任务就有延迟,一个任务有延迟,最后往往会波及到整个迭代的时长!我们这3个迭代最后多出现了延时情况。

2》 任务粒度太粗还有另一个问题时,功能点的遗漏!这个问题甚至会拖延到测试时才被发现,只能临时将其添加到下次迭代中,影响了下次迭代的开发。

3》 开发人员受外界影响太大!我们开发人员不仅要参与这个产品的发版,同时还要参与维护以前的产品。这种时间没法计算到迭代周期中,但同样会影响迭代周期的计划时长。

4》 分解任务分配时间时,代码评审和自测的时间估量的太少,导致每次迭代后交付给测试的产品小问题太多。虽然整体流程可以走通,但仍热让测试团队怨气颇大!

这就是我们第一次自我敏捷的过程和期间产生的一些问题。如果仅仅从“敏捷的实施”这个角度看,我们的敏捷是失败的。因为我们没有按时优质的交付每一次迭代成果,最后的产品也产生了拖延。

 

然后再说一下我读完《轻松Scrum之旅--敏捷开发故事》一书后,对Scrum的一些收获吧,其中还有和我自己的敏捷开发进行的对比。先说一下Scrum中涉及到的一些名词:

1》 Product Owner:产品所有者,这个人发起一个产品的开发,并且负责将产品通过User Story的形式进行描述,并对所有User Story按优先级排序,给出一个大概的开发时间。我上述描述中“部门经理”就是我们那个产品的Produce Owner。

2》 Product Backlog:产品的功能点的总纲,即所有的User Story。最后Scrum是否完成,就看这个Backlog中是否还有剩余User Story。敏捷中允许Product Backlog发生变化,这分为两点:一是前面迭代中完成的部分发生了需求变化,则将这部分放到未完成的Backlog中,另一个是没有开发的部分发生变化。并且如果Scrum的整体周期很难变化,可以视开发进度从Product Backlog中将部分User Story移出。

3》 User Story:产品的一个开发点,通常是一个较大的点,从用户角度进行描述。一个大的User Story通常会包括多个较小的User Story。较小的User Story会包含多个Task。

4》 Task:产品的一个小的开发点,我们进行开发忘功能看板上贴便签上,写得就应该是Task。每个Task的时长通常为0.5~1天。从这个角度看,我上述描述的自己的敏捷对Task的大小没有控制好,这点确实对开发影响很大!

5》 Scrum Master:Scrum团队的负责人。负责一个Scrum团队和Product Owner交流的一个人。Scrum强调团队的自我管理性,即开始Scrum后,这个团队就相对封闭了,不应受外界影响。这个团队的一个开放口就是Scrum Master 。这个人负责团队与外界沟通,并且阻止外界对团队的影响。我上述描述自己的敏捷中,开发经理就相当这个角色。

6》 Sprint:中文翻译就是“冲刺”, 我上面描述自己的敏捷提到的“迭代”就等同于Sprint。实际实施Scrum中,就是要完成几个Sprint。一个Sprint时间通常为2周~2个月,这个视产品大小而定。

7》 Sprint Backlog:一个迭代过程中需要完成的功能点列表。这个列表就是从Product Backlog中挑选出来的。

8》 Sprint Planning Meeting:Sprint计划会议。这个会议是开始一个Sprint的标志会议。通常分为两部分,第一是Product Owner,Scrum Master,所有开发人员,用户(如果有的话最好)同时参加,共同决定这次Sprint中要完成Product Backlog中哪些功能,如果此刻又不明白的地方,Scrum Master和开发人员必须和Product Owner进行充分沟通,直到明白为止。第二是Scrum Master 和所有开发人员参加,将这次Sprint中的User Story分解为Story,每个Story完成时间控制在0.5~1天,并且由开发人员按兴趣领取相应的Task。注意代码评审和自测也要分别作为一个Task存在。

9》 Daily Scrum Meeting:每日例会。由Scrum Master和所有开发人员参与的例会。这个是Scrum的精髓,Scrum Master控制一个Spint的进度就是根据这个会议。

10》 Sprint Review Meeting: Sprint评审会议。每次Sprint后对整个Sprint的成果向Product Owner,测试进行演示的一个会议,是一个Sprint完成的标志。

11》 Sprint Retrospective Meeting:Sprint回顾会议。这个会议由Scrum Master 和全体开发人员参加,大家讨论一下在刚刚结束的一个Sprint中的所得和所失。是一个Scrum团队自我成长和进步的最好的方式,大家互相提出自己的建议并发现问题,进行团队经验累积。我上述自己的敏捷没有这个会议,这个是一大损失!

这些都是这本书提到的一些Scrum概念,在实际应用中,我们的一些东西和这个肯定会略有不同,这个无关紧要,但其中一些重要的步骤,比如最后8~11 这个4个,是不可或缺的!

Scrum是软件开发中对敏捷的一组具体的应用指导原则,他强调面对面的沟通(一个Scrum团队最好保持在6~8人,并且大家办公位置能在一起),欢迎变化,弱化文档(他强调代码和注释是最好的文档),并且不提倡加班(对于视加班为常态的广大IT“民工”真是一大福音啊)。

实施Scrum中,有几点是要提前有所防备的。Scrum欢迎变化,所以我们就不可避免会有一些需求的变动或开发人员请假的一些情况,所以我们在安排时间时尽可能留一些预留时间,这个长度视经验而定。如果在实施过程中,预感到进度出现滞后的现象,Scrum Master要及时和Product Owner进行沟通,暴露问题所在,提前做出调整,如延长一定时间或者去掉一些User Story。

Scrum中涉及一个功能看板,这个看板很重要,可以用实物看板(我上述描述的敏捷过程所用),目前也有很多Scrum实施软件,如ScrumWorks(这本书中使用的软件),这个软件好像是收费的,所以我也没用过,但貌似功能很强大!不仅能有实物看板一切功能,而且还支持自动绘制“燃尽图”,这是一个整个项目进度的可视化显示,从网上找到的燃尽图,大家可以看一下:

红线表示计划进度路线,蓝线表示实际进度路线。蓝线在上面,表示进度有所滞后,蓝线在下面表示进度有所加快。如果不用ScrumWorks这类软件,我们如果需要这种可视化图片,需要自己手动进行。

这就是自己先糊里糊涂经历过敏捷而后又细细品味后敏捷的一点入门小得,总结一下,敏捷就是一种思想,是一种以人为出发点的一种管理哲学,可以应用在各种领域。在软件工程领域,Scrum是一组具体的敏捷实施指导原则,概念清晰,比较适合初次采用敏捷的开发团队使用。

 

2019-09-26 23:39:17 u012088066 阅读数 12
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10427 人正在学习 去看看 CSDN讲师

一.敏捷测试总体介绍

敏捷测试是遵从敏捷软件开发原则的一种测试实践。敏捷开发把测试集成到了整个开发流程中而不再把它当成一个独立的阶段。敏捷测试主要的核心内涵有三个:

  1.遵从敏捷开发的原则(强调遵守)

  2.测试被包含在整体开发流程中(强调融合)

  3.跨职能团队

二.敏捷测试的特点

  1.更强调协作

  敏捷开发人员和测试人员工作得更加紧密,喜欢更直接的沟通方式而不是通过邮件文档这种一来一回反反复复的沟通方式

  2.更短周期

  需求验证或者测试的时间不再是按月计算而是按天或者按小时计算。用户验收测试在每个周期的结尾都会进行。

  3.更灵活的计划

   敏捷测试也需要拥抱变化,测试计划不再是一成不变的文档而是会根据情况进行灵活调整

  4.更高效的自动化

  相比传统测试,自动化在敏捷测试中扮演了极为重要的角色。它是实现快速交付确保质量的一种非常有效的手段。

 

2019-05-29 14:29:41 weixin_43054542 阅读数 962
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10427 人正在学习 去看看 CSDN讲师

一.关于敏捷开发的概念

敏捷开发的思想自进入国内以来,已经经过多年的发展,概念也不断完善,通常认为这是一种以人为核心、迭代、循序渐进的开发方法。

在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。也就是说把一个整体的大项目分成多个相互联系的但又可以独立运行的小项目,并根据计划分别完成,并保证软件在此过程中一直处于可用状态,这就是其迭代式开发的特色。

  二.敏捷开发的优势

敏捷开发确实是项目进入实质开发迭代阶段,用户很快可以看到一个基线架构版的产品。敏捷注重市场快速反应能力,也即具体应对能力,客户前期满意度高。

1、敏捷开发属于增量式开发,对于需求范围不明确,需求变更较多的项目而言,可以很大程度上响应及拥抱变化。

2、对于互联网产品而言,市场风向转变很快,需要一种及时快速的交付形式,而敏捷开发则能更好地适用于此。

3、敏捷开发可最大程度体现80/20法则的价值,通过增量迭代,每次都优先交付那能产生80%价值效益的20%功能,能最大化单位成本收益。

三、误区

关于敏捷开发应当认为是一种轻量级、高效的平台,而不是纯粹的越快越好。

四、特点

1. 个体和交互胜过过程和工具

2.可以工作的软件胜过面面俱到的文档(但并非不需要文档)

3. 客户合作胜过合同谈判

4.响应变化胜过遵循计划

五、核心原则

1.主张简单

2.拥抱变化

3.第二个目标是可持续性

4.递增的变化

5.令投资最大化

6.有目的的建模

7.多种模型

8.高质量的工作

9.快速反馈

10.软件是你的主要目标

11.轻装前进

六、敏捷开发与瀑布模型开发

瀑布模型开发

敏捷开发

曾经有大牛分享了一个很有趣的“敏捷和瀑布”的例子,这里拿来一起分享。

1、敏捷开发

客人到餐馆来点菜(新项目)不确定客户想吃什么的时候,通常选好餐厅后会先看看餐厅的菜单(客户往往提不出具体的需求)根据图文菜单,客人点了10个菜(根据原型和设计稿,基本确定了需求)后厨开始准备(项目启动)配菜、炒菜,先上了两盘,让客人尝了尝味道(先提供可用实例给客户用)客人说还不错,后厨继续准备后面的菜,陆续上菜(不断迭代,不断测试)上菜过程中,客人突然发现有个菜的味道太淡了,让后厨加了点盐又端上来了(敏捷的好处,可以不断测试和需求变更)又上了两盘,不够辣,又拿到后厨加了辣(敏捷的坏处,需求没有提前明确,反复迭代,增加了工作量)到最后两盘时,客人要求换两个菜,还好没炒(迭代的好处,随时接受需求变更)客人吃完,很满意(基本满足了全部的要求)。

2、瀑布模型开发

客人到餐馆来点菜(新项目)不确定客户想吃什么的时候,通常选好餐厅后会先看看餐厅的菜单(客户往往提不出具体的需求)根据图文菜单,客人点了十个菜(根据原型和设计稿,基本确定了需求)后厨开始准备(项目启动)根据客人的下单配菜,炒菜(基本上不会主动去了解完整需求)半个小时了,菜还没上桌,客人饿极了(项目启动后很长一段时间客户什么都看不到)再过了二十分钟,十个菜都一起上来了(项目最终一次交付)客人说,有几个菜挺好的,但是有个菜味道淡了,有两个不够辣,还有两盘重复了想换掉(我是买单的,我要变需求)这时候大堂经理来了,说,“味道淡了可以加盐,不辣可以加辣,但是换菜不行,已经炒好的那两盘菜也是要算成本的”(瀑布的坏处,需求变更比较麻烦)于是,后厨只给客户加了盐,加了辣客人吃完,不是很满意,下次不来了(没有满足需求)。

七、总结

就目前来看,在实际管理项目的过程中,大多数并没有严格的按照敏捷或瀑布模式,都是各自掺杂了其他的方法,因为在实际项目的过程中,过于强调模式意义不大,重要的是能不能预防问题的发生或者在问题出现之后能不能以最小的成本解决,而模式更多的是起到一个参考作用,“实际大于主义”。

Learun(力软)近十年来一直专注于敏捷开发框架的研发,目前v7.0经典框架已经在各行各业得到应用,适用于OA、ERP、CRM、BI、BPM、HRM、SAAS、移动app、电商系统后台等多种企业信息系统。

 

【笔记】敏捷开发

阅读数 156

没有更多推荐了,返回首页