精华内容
下载资源
问答
  • Scrum敏捷项目管理

    千次阅读 2017-04-29 03:56:32
    敏捷的背景与动机软件危机及软件工程的出现 速度是企业竞争致胜的关键因素,软件项目的最大挑战在于 一方面要应付变动中的需求 一方面要在紧缩的时程内完成项目 传统的软件工程难以满足这些要求 所以软件团队...

    敏捷的背景与动机

    软件危机及软件工程的出现
    速度是企业竞争致胜的关键因素,软件项目的最大挑战在于
    一方面要应付变动中的需求
    一方面要在紧缩的时程内完成项目
    传统的软件工程难以满足这些要求
    所以软件团队除了在技术上必须日益精进,更需要运用有效的开发流程,以确保团队能够发挥综效。这正是Agile Process (敏捷的软件开发流程)于近年来兴起的主要原因。

    软件项目的复杂性

    横轴代表需求的复杂度!
    纵轴表示技术的复杂度
    还有人力资源的复杂度
    这里写图片描述

    解决复杂性问题需要采用经验式方式

    解决问题的两种方式:
    预定义过程控制(富士康流水线生产)
    经验性过程控制(摸着石头过河)
    如果复杂度超过预定义方式的能力范围,应该采用经验性方式
    经验性方式的三大支柱:可见性、检查及适应

    敏捷的历史

    敏捷软件开发又称敏捷开发,
    从1990年代开始逐渐引起广泛关注的一些新型软件开发方法,是一种应对快速变化的需求的一种软件开发能力。
    2001年初,因观察到许多的软件团队身陷不断扩大的流程之中的困境,一群业界专家聚集在一起,勾勒出一些能让软件团队迅速工作,以及响应变化的价值观和原则。他们自称为Agile Alliance。
    之后的七个月里,他们创造具有价值的声明,也就是敏捷软件的开发宣言。
    十五人中包括:大名鼎鼎的Kent Beck(XP,TDD的创始人,Junit的创始人之一)、Ward Cunningham(Wiki概念的发明者)、Martin Fowler(《企业应用架构模式》作者)、Robert C. Martin、Ken Schwaber

    敏捷价值观之敏捷宣言

    这里写图片描述
    敏捷开发的核心思想是:以人为本,适应变化
    个体和交互胜过过程和工具:
    1、人是软件项目获得成功最为重要的因素
    2、合作、沟通能力以及交互能力比单纯的软件编程能力和工具更为重要
    3、方法和工具是死的,人是活的,人要是太“面”或者协作不好,再强大的方法和工具都是白扯;

    可以工作的软件胜过面面俱到的文档:
    1、过多的面面俱到的文档往往比过少的文档更糟
    2、软件开发的主要和中心活动是创建可以工作的软件
    3、直到迫切需要并且意义重大时,才进行文档编制
    4、编制的内部文档应尽量短小并且主题突出

    客户合作胜过合同谈判:
    1、客户不可能做到一次性地将他们的需求完整清晰地表述在合同中
    2、为开发团队和客户的协同工作方式提供指导的合同才是最好的合同

    响应变化胜过循环计划:
    1、变化是软件开发中存在的现实
    2、计划必须有足够的灵活性与可塑性
    3、短期的迭代的计划比中长期计划更有效

    敏捷开发的12个原则

    1. 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
    2. 即使到了开发的后期,也欢迎改变需求。
    3. 经常性地交付可以工作的软件,交付的间隔可以从几周到几个月,交付的时间间隔越短越好 。
    4. 在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。
    5. 围绕被激励起来的个人来构建项目。
    6. 在团队内部,最具有效果并且富有效率的传递信息的方法,就是面对面的交谈。
    7. 工作的软件是首要的进度度量标准。
    8. 敏捷过程提倡平稳的开发节奏;发起人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
    9. 不断地关注优秀的技能和好的设计会增强敏捷能力。
    10. 简单化是根本(不做过度设计和预测)。
    11. 最好的构架、需求和设计出自于自组织的团队。
    12. 每隔一定时间,团队会在如何才能更有效地工作方面进行反思并对自己的行为进行相应调整。

    什么是敏捷方法?

    敏捷方法是一类软件开发流程的泛称;
    敏捷方法是相对于传统的瀑布式软件过程提出的;
    敏捷方法可以用敏捷宣言(4条)、敏捷原则(12条)来概括;
    敏捷原则通过一系列的敏捷实践来体现出来;
    敏捷方法有很多种。

    敏捷的方法

    1. Extreme Programming (XP)极限编程
    2. Scrum
    3. Adaptive Software Development (ASD)自适应软件开发
    4. Crystal Clear and Other Crystal Methodologies水晶方法
    5. Dynamic Systems Development Method (DSDM)动态系统开发方法 等

    敏捷方法 VS. 瀑布模型

    瀑布模型
    固定的、没有弹性的。
    很困难去达到互动。
    假如说需求没有完全的被了解,或是可能需要完全地改变项目的需求,瀑布式的model是比较不适合的。
    敏捷方法
    完整地开发,每少数几周或是少数几个月里可以测试功能。
    强调在获得最简短的可执行功能的部分,能够及早给予企业价值。
    在整个项目的生命周期里,可以持续的改善、增加未来的功能。
    瀑布模型:
    瀑布模型
    敏捷方法:
    敏捷方法

    敏捷项目管理VS传统项目管理

    传统项目管理:

    1. 事先对整个项目进行估计、计划、分析
    2. 反对变更; 变更需要重新估计、重新规划
    3. 严密的合同来减少风险, 如果改变需求要走 CR 流程.
    4. 项目作为一个“黑盒子” ,对客户与供应商的可视性差.
    5. 文档和计划驱动的方法.
    6. 软件交付时间晚, 意识到风险的时间晚.
    7. WBS,甘特图,关键路径分析

    敏捷项目管理:

    1. 对整个项目做一个粗略的估计,每一次迭代都有详细的计划.
    2. 鼓励变化, 客户价值驱动开发.
    3. 信任和赋予权力;合约使变更变得简单,增加价值.
    4. 客户和开发人员之间是紧密的连续的合作关系
    5. 每次迭代都产生可交付的软件
    6. 专注于交付软件.
    7. 第一次迭代就可交付能工作的版本,风险发现的早.

    敏捷 与CMMI双剑合璧

    CMMI更加关注于流程,敏捷更加关注于人
    CMMI自顶向下,敏捷自底向上
    敏捷并不排斥必要的文档
    敏捷的很多实践是对CMMI的一种实现,比如sprint计划会议就是PP的实现,每日例会就是在做PMC
    很多CMMI4~5级的公司也在应用敏捷,比如说宝信、华为
    项目级的敏捷实践通过CMMI可以在组织级得以重用

    这里写图片描述

    eXtreme Programming

    XP我们一般称为极限编程,是最轻量级的开发流程。
    最主要的精神是
    『在客户有系统需求时,给予及时满意的可执行程序』,所以最适合需求快速变动的项目。
    它强调客户所要的是
    workable的执行码,所以把与撰写程序无关的工作降至最低,并要求客户与开发人员最好以side-by-side的方式一起工作。
    XP的实践包括:
    完整团队、计划游戏、客户测试
    简单设计、结对编程、测试驱动开发
    改进设计、持续集成、集体代码所有权
    编码标准、隐喻、可持续的速度
    这里写图片描述

    Scrum开发流程

    这里写图片描述

    为什么采用敏捷? –预期的收益

    采用敏捷方法得当的话,可以:

    1. 更加透明; 随时跟踪项目的状态和进展情况,及早发现问题和风险 .
    2. 快速交付, 每次迭代都能交付可运行的软件.
    3. 最高风险和最高优先级的需求,最优先进行开发.
    4. 改善应对变更能力, 减少大量的重计划.
    5. 改善项目沟通.
    6. 更好的客户参与, 避免错误的假设.

    总之:

    1. 提高了生产率; 减少“浪费” (不需要的文档,重复工作等) ,项目的每次迭代都有明确的目标.
    2. 提高客户满意度; 短期内产生成效, 按预期交付软件, 每次迭代结束产生可以运行的软件.
    3. 改善员工的满意度; 团队精神,减少官僚,能够规划和管理自己的工作,减少“恐慌” ,稳定的工作量(可持续的步伐).

    敏捷关键实践1——增量迭代

    1. 每个迭代有一个大约为1~4周的时间框,在SCRUM里称为一次冲刺(超过1个月的详细计划往往偏差很大)
    2. 每次迭代都应该有明确的目标
    3. 每次迭代都应该有明确的可演示的工作成果
    4. 迭代过程中项目团队应该尽量免受打扰
    5. 迭代可以将项目的压力分解到每个小的阶段,风险也能同时分解

    这里写图片描述

    敏捷关键实践2——测试驱动开发 TDD

    什么是测试驱动?

    1. 首先创建测试用例,然后开发软件通过测试(在开发代码前,首先编写测试代码)
    2. 一种设计软件的方法,而不仅仅是一种测试方法
    3. 所创建的测试用例用来指导和约束项目中的各项工作,对未来的各项工作提供一个安全的保护
    4. 不需要测试的工作不需要完成
    5. 所创建的测试用例通常替代详细的业务和技术需求定
    6. 测试也有效地驱动设计,使设计更加趋向于可行的设计
    7. 通常情况下需要自动测试的支持 (EUnit, JUnit etc.).
    8. 对于UI软件应用TDD方法有一定的困难

    敏捷关键实践3——持续集成

    极限编程称为“每日构建”
    持续集成一般利用ANT、MAVEN等工具
    日构建的好处:
    将集成风险降到最低
    降低质量风险
    提升士气
    日构建可以看做是项目的心跳,冒烟测试就像是听诊器
    日构建必须至少:成功编译、打包、发布;不含有任何明显的缺陷;通过冒烟测试

    敏捷关键实践4——面对面交流

    虽然如今通讯工具花样繁多,但面对面交流在某些场合下仍然是不可替代的;
    敏捷开发把交流缺失问题考虑在内,要求团队成员彼此直接协作,尽量创造面对面交流的机会;
    尤其当业务分析师和软件开发人员一起工作的时候,面对面的交流是很重要的。
    匿名共享需求文档只会打开曲解和误解之门,更不用说书面信息比口头交流还要慢很多。

    敏捷方法的其它实践

    1. 结对编程
    2. 每日立会
    3. 用户故事
    4. 团队工作室
    5. 频繁发布
    6. 自组织团队
    7. 重构
      这里写图片描述
      这里写图片描述
      这里写图片描述
      这里写图片描述

    重构——改善既有代码的设计

    Martin Fowler提出
    代码的坏味道
    Martin Fowler和Kent Beck列举了22种坏味道:冗余代码、冗长的方法、巨大的类、过多的参数等等
    重构可以弥补设计的不足
    简单设计的思想
    重构与测试驱动的关系
    TDD是重构的脚手架
    IDE已经对主要的重构模式提供了自动化支持:Rename, extract method, move field等等
    简单设计>>测试用例>>实现再说>>(重构>>回归测试)*

    这里写图片描述

    Scrum何时更有效?

    公司和客户一致认为应当使用敏捷方法,双方都能理解敏捷方法.
    敏捷方法对需求不完整以及经常变换的项目比较有效.
    项目可以划分成固定时间间隔的迭代, 并且可以冻结正在进行的迭代的范围
    公司和客户都有能力担当角色尤其是Product Owner 和 Scrum Master.
    项目的人员结构能够分成6到10人的团队,最好每个工作地点一个小组.(Scrum of Scrums,Scrum的扩展)
    团队成员能够以自组织的方式工作.
    项目的合同允许变更.
    固定价格的项目可以使用敏捷,但应当尽量避免。
    最好在按时间和材料付费或者按月付费的项目中进行使用、
    变更项目的范围不需要高级管理层的批准.

    敏捷特别强调人的因素

    相对于过程与工具,敏捷更强调“人”的因素。

    诚信是基础

    没有过程能够对诚信进行有效的约束

    诚信与否是有效实施敏捷过程的最大限制

    Scrum框架

    这里写图片描述

    Scrum角色

    这里写图片描述

    Scrum角色之Product Owner

    产品负责人(Product Owner)的职责如下:
    确定产品的功能。
    决定发布的日期和发布内容。
    为产品的profitability of the product (ROI)负责。
    根据市场价值确定功能优先级。
    每个Sprint,根据需要调整功能和优先级(每个Sprint开始前调整)。
    接受或拒绝接受开发团队的工作成果。

    Scrum角色之ScrumMaster

    作为Team Leader和Product owner紧密地工作在一起,他可以及时地为团队成员提供帮助。他必须:

    1. 保证团队资源完全可被利用并且全部是高产出的。
    2. 保证各个角色及职责的良好协作。
    3. 解决团队开发中的障碍。
    4. 做为团队和外部的接口,屏蔽外界对团队成员的干扰。
    5. 保证开发过程按计划进行,组织 Daily Scrum, Sprint Review and Sprint Planning
      meetings。

    Scrum角色之Scrum Team

    一般情况人数在5-9个左右
    团队要跨职能
    (包括开发人员、测试人员、用户界面设计师等)
    团队成员需要全职。
    (有些情况例外,比如数据库管理员)
    在项目向导范围内有权利做任何事情已确保达到Sprint的目标。
    高度的自我组织能力。
    向Product Owner演示产品功能。
    团队成员构成在sprint内不允许变化。

    Scrum 流程

    这里写图片描述

    Sprints(冲刺)

    Scrum的项目过程有一系列的Sprint组成。
    Sprint的长度一般控制在2-4周。
    通过固定的周期保持良好的节奏。
    产品的设计、开发、测试都在Sprint期间完成。
    Sprint结束时交付可以工作的软件。
    在Sprint过程中不允许发生变更。

    Scrum仪式之Sprint计划会议

    这里写图片描述

    Scrum仪式之Sprint计划会议

    这里写图片描述

    Scrum仪式之每日Scrum会议(Daily Scrum)

    每日Scrum会议,即团队每日例会,条件允许的话,每天都应该在同样的时间和地点,组织所有成员站立进行。
    最好是每天早晨开,一般15分钟左右,时间比较短,也有利于团队成员安排好当天的工作。
    只有团队成员可以在例会上发言,其他人员有兴趣可以参加,但只能旁听,不能发言。(小猪和小鸡的故事)
    每日Scrum会议由Scrum Master主持, Scrum团队所有成员轮流回答以下3个问题:
    昨天我完成了什么工作?
    今天我打算做什么?
    我在工作中遇到了什么困难?
    这里写图片描述

    Scrum 任务板(Task Board)

    任务板(墙)展现了在Sprint过程中所有要完成的任务。在Sprint过程中我们要不断的更新它。如果某个开发人员想到了一个任务他就可以把这个任务写下来放在任务墙上。 无论每日站会过程中或者之后,如果估计发生了变化,任务会根据变化在任务墙上做相应的调整。通常的任务板是下面这个样子:

    这里写图片描述

    Scrum仪式之Sprint评审会议

    Sprint评审会用来演示在这个Sprint中开发的产品功能给Product Owner. Product Owner会组织这阶段的会议并且邀请相关的干系人参加。
    团队展示Sprint中完成的功能
    一般是通过现场演示的方式展现功能和架构
    不要太正式
    不需要PPT
    一般控制在2个小时
    团队成员都要参加
    可以邀请所有人参加

    Scrum仪式之Sprint回顾会议

    团队的定期自我检视,发现什么是好的,什么是不好的。
    一般控制在15-30分钟
    每个Sprint都要做
    全体参加
    Scrum Master
    产品负责人
    团队
    可能的客户或其它干系人

    Scrum物件之产品订单(Product Backlog)

    一个需求的列表。
    一般情况使用用户故事来表示backlog条目
    理想情况每个需求项都对产品的客户或用户有价值
    Backlog条目按照商业价值排列优先级
    优先级由产品负责人来排列
    在每个Sprint结束的时候要更新优先级的排列

    Scrum物件之产品订单(Product Backlog)

    这里写图片描述

    Scrum物件之冲刺订单(Sprint Backlog)

    这里写图片描述

    Sprint Backlog 示例

    这里写图片描述

    Scrum物件之冲刺订单(Sprint Backlog)

    管理Sprint的backlog:
    团队成员自己挑选任务,而不是指派任务
    对每一个任务,每天要更新剩余的工作量估算
    每个团队成员都可以修改Sprint backlog,增加、删除或者修改任务

    Scrum物件之燃尽图(Burn Down Chart)

    这里写图片描述

    扩展Scrum

    一般情况一个团队的人数控制在5-9人
    大型项目可以采用多团队,通过team of teams来扩展Scrum。
    影响扩展的因素
    团队规模
    项目类型
    项目周期
    团队分布
    Scrum曾被用于超过1000人团队规模的项目。

    Scrum Of Scrums

    这里写图片描述

    Scrum项目之估计

    Scrum团队对产品需求清单的每一项的规模提供初步的估计,通常采用事件点作为单位Story Points (模糊的).
    也可采用人天或者人小时作为单位,但容易混淆: a) 实际的规模 b) 时间的单位.
    精确的估计值可以在Sprint 规划时给出, 当前阶段没有足够的信息.
    规模的相对值才有意义.
    这个估计值有助于确定优先级;
    可以采用估算扑克
    这里写图片描述

    完成的定义

    当迭代任务清单上的任务都完成时,变为“已完成”状态
    定义“已完成”的含义是非常重要的, 例如:
    如何记录软件的变化.
    使用什么样的代码分析工具 ,发现的问题应当如何处理.
    进行了什么样的测试, 结果是如何记录的, 通过标准(如覆盖率、修正的错误)是什么.
    定义“已完成”意味着定义质量上的需求.
    “已完成”是0/1变量:完成或者未完成. 所有的任务(task)都完成了迭代任务才算完成.
    在第一个迭代开始之前应该定义好,因为它会影响工作量, 而且必须文档化,这样团队和产品所有者的理解是一致的.

    完成的定义 - Example

    完成的定义
    遵循编码规范
    能在模拟器上演示
    使用PCLint 进行静态代码分析
    具有EUnit 测试套件的通过率 和执行率.
    或者使用结对编程,或者进行代码走查

    障碍

    基本上,任何阻止团队正常工作的,都可称之为障碍,例如:
    无法访问信息系统.
    所需要的信息不能及时提供或者提供的不正确,如界面规格或者其它软件模块不到位或不正确
    开发环境或者原型系统出现问题
    其他的任务分配:培训,售前支持
    缺乏必要的信息或者相应的知识

    对于团队提出的各项障碍,Scrum Master要以列表形式进行记录,

    谁来清除障碍?

    每个人
    自我管理、自我组织的团队
    Scrum Master
    产品所有者
    管理层
    其他相关的干系人

    Scrum Master 负责确定障碍已经清除,不一定亲自自己清除

    清除障碍

    某些障碍是浪费
    部分地完成工作
    额外的过程
    额外的功能
    任务转换
    等待
    缺陷

    这里写图片描述

    浪费产生的原因

    多问几个“为什么”
    对于每个标识的障碍或者浪费,问一问“为什么”浪费会存在
    多问几个“为什么”,找到造成浪费的根本原因

    这里写图片描述

    SCRUM实践

    研发部2009年开始在几个项目当中进行了SCRUM项目管理的尝试:
    营销综合停电系统开发
    FLEX-ADP开发
    海颐OA项目

    SCRUM看板

    这里写图片描述

    SCRUM燃尽图

    这里写图片描述

    SCRUM带来的改善

    项目的计划性更强了,将项目按SPRINT进行分解,每个SPRINT要进行计划和总结,每天也有立会来进行简短的总结和计划;

    引入SCRUM以后,项目团队的沟通比以往更有效,项目看板为项目团队沟通提供了一个统一的项目视图,每日立会是项目团队沟通的有效通道;

    项目的阶段性比以前更明确,通过SPRINT将项目划分成阶段,通过SPRINT演示等活动将项目整体的压力分解到每个SPRINT,这样可以有效降低项目的整体风险。

    一些常见的误解

    敏捷是拯救任何项目的银弹.
    敏捷方法只有运用得当才有效果.
    敏捷意味着 ad-hoc hacking ,不需要任何文档.
    敏捷是有严格要求的,也是面向质量的
    根据沟通的需要产生相应的文档.
    敏捷只是开发者的问题
    基本的开发方法与传统相比有显著不同, 影响项目的各个方面: 合同, 角色, 定价模型, 项目管理等.
    采用敏捷方法的开发组/项目不需要制定计划
    敏捷项目需要经常制定计划,但是不需要试图超前制定项目计划,通常这也是不可能的.
    敏捷项目的范围可以随时改变.
    变更可以等到下一次迭代开始,当前正在进行中的迭代不能变更
    只对小项目适用
    在中型和大型的项目中一样取得了成功

    总结

    Agile Software Development是软件开发所强调的一个精神,而不是一个方法。
    遵循Agile Alliance所提的四个价值观与12个原则。
    最常见的开发方式
    XP
    SCRUM
    敏捷开发过程是一个艰苦的过程,重在实践
    即使非敏捷的项目中也可以应用敏捷的实践经验
    CMMI应该与敏捷实现融合,双剑合璧

    参考ppt:
    http://download.csdn.net/detail/qq1137623160/9828941

    展开全文
  • Scrum 敏捷项目管理

    2011-08-04 16:34:56
    敏捷项目管理 ScrumMaster  保证Scrum流程顺利执行 Product Manager 负责产品质量,保证项目预期价值 Group  Scrum项目实现团队,具有完全自主性 Product Backlog 产品完成log Sprint  30天...

     

     

     
    Scrum    敏捷项目管理
    ScrumMaster    保证Scrum流程顺利执行
    Product Manager 负责产品质量,保证项目预期价值
    Group    Scrum项目实现团队,具有完全自主性
    Product Backlog 产品完成log
    Sprint    30天计划
    Sprint 评审 审查上一sprint中完成的可交付产品
    Sprint Backlog Sprint周期需完成log
    Daily Scrum (全天工作的第一件事)

     

    1.自上次的Daily Scrum后我做了什么?

    2.现在到下次Daily Scrum我准备做什么?

    3.在工作中遇到了什么困难?

    戴明循环  一种全面质量管理方法,P、D、C、A分别是英语Plan(计划)、Do(实施)、Check(检查)、 Action(处置)的缩写。经过计划、实施、检查、处置四阶段构成一个循环。每经一次循环,解决一批质量问题,使产品质量和工作质量达到一个新的水平,然后再进入下一循环。戴明循环既是一个循序渐进的流程,也是一个反复的过程和可量化的过程。
    生鱼片规则 Sprint审核时演示的潜在可交付产品功能的每一个增量都必须是完整的,包括分析、设计、编程、文档编制及任何合乎应用软件要求的步骤。即每个增量由经过完整测试和文档描述的潜在可交付功能组成。

     

    如果30天内无法将Idea转换成具备商业模式及可操作性的项目,

    如果2个月内无法找到团队核心并组成初创团队,

    如果3个月内你的Idea还没被团队充分理解并预期付诸实践,

    如果6个月内你还在筹划半年前的那个Idea,

    这个Idea已经过时勒,请下一个,这里是互联网!

    更迅捷的项目管理,

    更快速的项目决断,

    更舒适的用户体验,

    更早地实现Idea,

    好与不好交由公众来评断,

    不要闭门造车以为一切尽在掌握。

    — Reinhardt

    项目的开始至完成绝不可能是一帆风顺的过程,即使完美主义者也会不可避免地遭遇挑战,”自上而下”或”自下而上”的过程都有其无可掩盖的缺点,只有不断在实践中迭代前进,才能一步步接近真相。

    — Reinhardt

    项目自始至终周期过长,会造成心理放松,对于项目危机感缺失,以至于造成前期浪费时间,后期加班赶时间的窘相。所以我们需要通过不断地迭代,在一次次循环中完成可交付的增量,基于事实的决策远比前端预测型决策更为有效。

    — Reinhardt

     

     Scrum有3种职能者:ScrumMaster,Product Manager,Team,相互之间不渗透,各司其职。ScurmMaster负责Scrum流程顺利完成,即迭代地不断进行,Product Manager根据产品需求及市场预期制定产品Backlog,Team在自发性驱使下完成Sprint。通常过程中,30天为一个迭代周期,称之为Sprint,流程如下:

    Scrum 敏捷项目管理 - w-hongjiang - w-hongjiang的博客

    Scrum Start -> Sprint 计划会议(第一部分分析Product Backlog,第二部分解答产品Backlog,并制定Sprint Backlog) –> Sprint 迭代开始 –> Daily Scrum(Sprint 迭代)–> Sprint 评审会议(展示,提问,调整)–> Sprint 评审会议(团队总结,调整)–> Sprint 迭代结束 –> Scrum End

    Scrum 敏捷项目管理 - w-hongjiang - w-hongjiang的博客

    图:Product Backlog

    Scrum 敏捷项目管理 - w-hongjiang - w-hongjiang的博客

    图:Task Board

    Product Backlog: 是否代表所有利益相关者的最近需求,提醒大家关注最近的将来(利益相关者:投资方,团队,目标用户)

    Sprint Backlog: Sprint迭代周期内,团队需要完成的项目细则,并确保Sprint周期结束后,项目的潜在可交付性

    Scrum计划过程涉及3个问题的解答:

    1 项目投资人希望项目结束时能取得哪些成果?

    2 每个Sprint应作出哪些进展?

    3 如何使项目投资人相信该项目是有价值的投资,以及项目申报者有能力交付预期收益?

    4 计划的目的之一是说服投资者为项目注资

    Daily Scrum(全天工作的第一件事):

    5 自上次的Daily Scrum后我做了什么?

    6 现在到下次Daily Scrum我准备做什么?

    7 在工作中遇到了什么困难?

    Scrum基本原理:

    8 Scrum是经验型方法,是”可能性的艺术“

    9 Scrum使得所有事项充分可见,使“秘密交易”最小化

    10 Scrum的运作基础是个人和团队的承诺,而非严密的规划及控制。相对于强行控制计划,其忠诚度、自组织和员工责任感是更为有效的机制

    11 团队成员只有事先集体负责,承诺在固定时间内交付实际产品后,才算真正掌握Scrum

    ScrumMaster

    ScrumManager主要职责:

    12 ScrumMaster与传统项目经理区别:从传统的控制者到引导者的转变

    13 ScrumMaster需要对团队作出承诺,让团队感受到有人全心全意关注其工作,在任何情况下提供保护和援助。

    14 ScrumMaster使团队在Sprint过程中免受干预

    15 产品负责人谈论业务需求和目标,团队则讲技术。由于产品负责人很难掌握技术,ScrumMaster的主要职责之一就是教会团队谈论商业需求和目标。团队与产品负责人之间的公分母是产品Backlog

    ScrumMaster职责:

    16 排除产品开发和负责人之间的障碍,确保产品负责人直接推动开发工作

    17 教授产品负责人如何实现投资回报最大化,以及如何利用Scrum达成目标

    18 激发创造力和放权,从而改善开发团队的环境

    19 千方百计提高开发团队的生产力

    20 改善工程实践和工具,确保每个功能增量都具备潜在可交付性

    21 向各方确保团队工作进展实时更新并高度可视

    Scrum高效率探究

    限期30天Sprint的固有压力,团队成员表示“需有所付出”的相互承诺,自组织原则及跨职能责任,有助于团队成功履行职责承诺机制条理化,增加相互责任心,团队凝聚效应

    “限定时间”可向团队灌输“可能”的艺术,避免过分追求完美

    “增量交货”的举措改进工程实践

    “放权”和“自组织”能够激发创造力,提升员工满意度

    (*****) 当人们不能聚在一起面对面交流时,往往会将自己的问题抛给他人

    (****) 预估的目的是为了解每个需求自身及相对于其他需求的规模。该信息有助于划分产品Backlog的优先等级,并将之分入各个Sprint

    Scrum运行无需过于宽泛的计划,但需足以引导Scrum的经验性过程的检查与适应循环,若成本/收益及假设性数据引导适应环境更有意义地展开,项目必可收益

    团队

    团队从被管理到自我管理的转变十分困难,但在生产力和工作愉悦度方面的回报显著

    在我们的生活和工作经历中,受他人管理的习惯根深蒂固。

    Scrum真理:成功的开发需要不断检查和调整

    本质:内心深处,认为自己应在一开始便完美安排各事项,确保计划得以严格实施。需要适应调整时,责备自己为实现妥善安排全部事项。从开始就预知结果的人不会存在。

    (**) 总体度量,即在最合适的日期交付最佳、最优质的系统。实施其余度量法时应保持谨慎,确保其支持总量度量,避免削弱其效果。我们在设计度量系统时应考虑人类固有的、为取悦他人不计后果的欲望。(e.g. 代码量不应作为绩效考核标准)

    (***) 团队通常难以用产品负责人能理解的语言与之交流,若产品负责人只谈商业,团队只谈技术,双方无法交流,也就没有协作

    Scrum报告

    每个Sprint结束时还需产生正式报告

    Scrum报告:

    22 第一份列出上一次Sprint开始时的产品Backlog

    23 第二份为新Sprint开始时的产品Backlog

    24 第三份是“变更报告”,详细列出前两份报告的差别

    25 第四份为产品Backlog的“剩余时间报告”(Burndown Report)

    变更报告总结以下内容:

    26 Sprint中发生及Sprint审核的情况

    27 项目针对Sprint审核结果所做的适应调整

    28 未来Sprint重构的原因

    29 发布日期或内容重新制定的原因

    30 为何团队在Sprint中完成的需求量比预期少

    31 在产品Backlog中,未完成工作的优先等级重排情况如何

    32 团队为何比预期生产率高(低)

    不使用术语,却教会管理层使用Scrum,属于只是一种表现形式。(e.g. Ajax = 无页面刷新)

    Scrum扩展项目

    Scrum of Scrums

    Scrum实践扩展成功的关键:

    33 在扩展前构建必须的基础设施(构建扩展基础设施的非功能性需求必须在扩展开始前完成)

    34 建构基础设施的同时确保交付商业价值

    35 优化原始团队的能力,向其余团队分派至少一名初始团队成员

    项目扩展为多个团队的产品Backlog中应加入以下非功能性需求:

    36 分解业务结构以支持整洁界面的多团队开发

    37 分解系统结构以支持整洁界面的多团队开发

    38 必要时,定义并实施特定开发环境,支持多团队并置或分布的环境

    e.g. 曳光弹:射击者摸黑开冲锋枪时难以瞄准,若每50发子弹中有一颗曳光弹,便可看清方向,调整瞄准。(指明团队方向,冲破迷雾) 

    e.g. 马克吐温曾说:“没有东西比绞索更易让人集中精神。”(增加紧迫感,提高效率)

    e.g. “癫狂愚顽”:反复做同样的事情,却期待不同的结果。在预定义方法在项目管理中失败时,人们通常将原因归结于未能严格执行预定义方法。断定项目成功的关键在于加强控制和项目定义。(不断重复地用失败的方法华丽地完成另一次更大的失败

    展开全文
  • 随着敏捷开发越来越火,自然我们也不能落后,我们公司也开始向敏捷转型,前段时间请了Scrum中文网的廖老师给我们企业做了全面的scrum敏捷开发培训课,第一次对敏捷有了全新的认识! 而在我们实施敏捷的过程中,...

    随着敏捷开发越来越火,自然我们也不能落后,我们公司也开始向敏捷转型,前段时间请了Scrum中文网的廖老师给我们企业做了全面的scrum敏捷开发培训课,第一次对敏捷有了全新的认识!

    而在我们实施敏捷的过程中,Leangoo工具也在帮助我们更好的实践敏捷!

    我们先从管理产品Backlog开始...

    首先我们团队和PO一起创建一个“产品Backlog”看板,一起收集产品的需求,并且按优先级排序!再利用不同的列表来安排开发需求的排期,如图:当前迭代,下个迭代,以后的迭代和已交付

    通过sprint计划会,PO从产品Backlog中选出需求作为当前迭代的目标,我们为其新建了一个迭代看板,每个迭代看板leangoo中默认是两周,我们也是按两周进行,如图:

    研发团队再将当前迭代的需求细化 拆分成一个个任务(以卡片的形式表示),再分配给每一个团队成员(拖拽成员头像至卡片),来进行协作

    燃尽图可以显示项目进展,任务分布可以查看每个人的任务分布情况或者工作量的分布情况,任务周期可查看一个任务的执行天数

    每个迭代看板,每个任务的状态我们可以设置为“需求”“待办”“进行中”“已完成”,如下图

    如果任务需要进入下一个状态时,我们只需要拖拽卡片即可,如果任务已完成,即将卡片移至已完成列即可!

    卡片上还有很多进阶功能,附件啊 工作量啊 检查项啊上传文档啊 等等,如图:

    所以,leangoo真的帮助了我们很多,至少不用物理的便利贴了 ,这样用电子看板更方便!

    后面我还会分享更多我们的实践!

     

     

     

    展开全文
  • Scrum Santhosh Srinivasan Outline ? What is Scrum ? Why Scrum ? Scrum Practices ? Why Scrum works ? Pros and Cons ? Case Study ? Summary What is Scrum ? Scrum is an agile, lightweight process that can
  • 国内的明道、Worktile等,国外的Asana、Trello、Basecamp等,Trello是好评度比较高的 ...http://tech2ipo.com/64195Asana(项目管理)+HackPad(会议与头脑风暴)+OneDrive(文件分享)+Google 日历...

    国内的明道、Worktile等,国外的Asana、Trello、Basecamp等,Trello是好评度比较高的
    没有用专门的敏捷工具,主要是redmine + 白板:redmine用于记录故事和bug,白板记录本次迭代的故事和燃尽图

    http://tech2ipo.com/64195   Asana(项目管理)+HackPad(会议与头脑风暴)+OneDrive(文件分享)+Google 日历(日程管理)

    2012 的评论:

    项目管理这个范围太大了,分类推荐几款开源免费的吧:
    1、配置管理:SVN,没什么说的,肯定是这个了
    2、缺陷管理:TRAC、Redmine、禅道、bugfree、bugzilla
    3、任务管理:TRAC、Redmine、禅道

    我个人喜好是用SVN+TRAC,非常简洁,不过现在Redmine有超过TRAC的趋势


    1, worktile

       https://worktile.com    目前基本版本全免费(2014年11月之前, 10人以上要收费的软件哦!)

       worktile应该说是中关村范

       简单试用了一下,不错的感觉啊, 可以任务切换; 针对不同product backlog, sprint backlog  等之间切换;

       没有燃尽图??  不能设置任务/项目的周期;

       没有工作量估计, 只有截止日期,  是反 scrum的啊!!

       没有sprint的概念,   只有task  与 项目;  所以只能每个项目当sprint来管理了!!!!!!!

       支持 android iOS版本的;

       worklite 大功能都有,但是不够细致,该有的没有,没需求的到是不少,面板操作也不怎么合理,还有不少必要功能隐藏太深。用了半年,刚开始赶紧不错,但是慢慢的赶紧需求不能满足了,而且扩展伸缩太小,不同模块直接的内容不能关联。这个完全免费。

    2, Teambition

        模仿 Trello ; 付费, 免费只有基本功能;

        https://www.teambition.com/

        Teambition应该是硅谷范。teambition适合敏捷开发,但是缺少层级管理

        teambition 功能比 worktile完善,细致度也还可以,但是面板操作上很多地方还比不上worklite,细小功能的编排让人莫名其妙。刚开始用感觉很奇怪,用惯了会好点,但是日程这个功能完全不是想要的那种比不上worklite或者osc#team的。也没什么扩展伸缩。个人版免费企业版收费

    3, Redmine

        Redmine 是一个开源的、基于Web的项目管理和缺陷跟踪工具。它用日历和甘特图辅助项目及进度可视化显示。同时它又支持多项目管理。Redmine是一个自由开放 源码软件解决方案,它提供集成的项目管理功能,问题跟踪,并为多个版本控制选项的支持。

        redmine关于敏捷Scrum的插件;
        可定制的; 开源的;

        一键安装:  

                http://blog.csdn.net/benkaoya/article/details/8762935

                 https://bitnami.com/stack/redmine/installer

        http://www.redmine.org

         Git: https://github.com/redmine/redmine

         插件: Redmine Plugin Directory.      http://www.redmine.org/plugins    http://www.zhihu.com/question/19926665

              agile:     redmine-sprints/    http://www.redminecrm.com/projects/agile/pages/1       

               scrum:  https://redmine.ociotec.com/projects/redmine-plugin-scrum 

                        http://www.redmine.org/plugins/scrum-plugin

               * Bug截屏上传插件(方便测试人员报告bug) 
               * Code Review插件(进行代码审核用) 
                * 用户导入插件 
                * 问题导入插件 
                * 敏捷Scrum 插件(进行敏捷开发用)

     5, 禅道项目管理软件

           试用了一下, 感觉太复杂, scrum开发,本来讲究的是一个blackboard , 燃尽图就搞定了,  这个可好 , 整了一堆没用用的,  管理人员操作不方便,开发人员厌烦的功能!!!!!!!!!唉, 失望.................

           几个基本的白板功能, 还有收不少的费用, sign!!!

           不过复制点, 传统的项目倒可以考虑使用;

             禅道项目管理软件集产品管理、项目管理、质量管理、文档管理、组织管理和事务管理于一体,是一款功能完备的项目管理软件,完美地覆盖了项目管理的核心流程。

    4,  other saas 协作工具:

    Trello

        在使用Trello之前,我是用白板+站会的模式,有了Trello后变成了投影+坐会(晨会),但效率更高
         国外的硅谷的公司 创立的;

    Asana

        国外的:

        在用Asana之前,我也比较过颇多好评的Trello,不过我并不是颜值爱好者,虽然Trello的界面看起来更酷,但我有些核心需求它无法满足,例如任务责任人不能添加子任务并指定责任人(Checklist可以通知成员,但在被通知成员的任务清单中并没有)。现在放弃Asana的原因,主要是15个成员的限制,以及网络速度和语言。


     ScrumWorks,基本版免费使用


    5, leangoo

    https://www.leangoo.com  

    使用了一下leangoo, 能满足基本的kanban功能, 但太过于简单;

    比如下面的基本功能都没有:

      1, story 已完成工作量记录; 并且与燃尽图的配合;

      2, story 跨 看版  或者 sprint 拖放;

      3, product sprint  backlog 的联合管理;

      4, 卡片的优先级设定;最低应提供设定界面, 然后可以自动排序;

      5,  导出功能太弱了, 相关标注, 工作量, 开发者 等等信息都没有了?!

      6, 没有提供导入功能;

      7, 只有在线版本;

    6, youtrack

       http://www.tuicool.com/articles/QjEB7n

       一款类似于 JIRA的 项目管理与 bug 跟踪的软件,JetBrains 出品, intelj, phpstorm,  webstorm, Teamware(TeamCity, youtrack)

       部署管理,比较复杂,

       10人以上收费;  可能要考虑破解版:(,风险

        小团队开发,代价有点高;

      

    7, JIRA

        收费;都是按license卖的,CQ一个license 3-5W块, JIRA20个license 4W块左右。

    8, Mantis

        http://www.mantis.org.cn/index.php?s=/home/article/detail/id/50.html

         Mantis是一个基于PHP技术的轻量级的开源缺陷跟踪系统,以Web操作的形式提供项目管理及缺陷跟踪服务。在功能上、实用性上足以满足中小型项目的管理及跟踪。更重要的是其开源,不需要负担任何费用。

       推荐Mantis一键安装包,下载即用,免配置,集成了apache、php、mysql、ssl、zend、mantis等全套绿色软件

    twiki


    电子工具: 
        Trac, Redmine用于项目管理和缺陷管理;
        CruiseControl,Hudson用于持续集成;
        Git,SVN用于版本管理;
        MediaWiki用于知识管理


    teambition、Tower.im、Worktile、trello哪个好?

    用过fengche,worktile,teambition。客观的说,个人还是觉得目前同类里面teambition用户体验最佳,就是收费太贵了点。
    Worktile 与 Teambition 的优劣对比?


    shu:  

    Mantis,  youtrack

    禅道按照Scrum开发方法设计,里面有需求、用例、TODO等内容,软件本身不予评价,但是功能太多了,我想用的仅仅是一个缺陷管理软件,也许按Scrum开发的团队使用禅道更合适。


    Mantis,我还配置了Testlink,后期,增加了dokuwiki

    求缺陷管理工具bugfree,bugzilla,mantis,etraxis,bugzero,禅道,youtrack在功能方面的对比

    展开全文
  • [align=center][img]... 今年开始尝试做PM, 在我看来PM貌似就是个打杂的角色, 不管了, 先尝试一下, 因此找了一些书来看看, scrum也是我今年规划中需要了解的一个东东, 因此就选了这本书. 这本书据说是scrum...
  • 敏捷项目管理:如今,工作场所中...在此初学者指南中,我们将告诉你有关敏捷项目管理Scrum的全部内容。 目录 什么是敏捷项目管理敏捷项目管理的12条原则 为什么要使用敏捷项目管理? 什么是Scrum? 使用Scr...
  • 讲师对传统IT项目管理技能点、IT产品设计技能点、Scrum敏捷项目管理技能点进行了分类汇总,并把实际工作场景和真实案例贯穿到内容里面,通过讲解+PPT展现形式呈现给大家,本套餐的最大亮点是内容融合真实案例,通俗...
  • 互联网敏捷 Scrum项目管理

    万次阅读 2018-07-03 02:46:07
    互联网敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多...本场 Chat 着重介绍互联网 Agile 敏捷的模型以及常用项目管理流程等内容。 本场 Cha...
  • Scrum敏捷研发管理平台-Leangoo看板

    千次阅读 2018-09-10 14:54:45
    只要是在IT互联网行业工作的人肯定对 Scrum敏捷开发 都多多少少有一些了解。工欲善其事,必先利其器,那我给大家介绍一款敏捷开发项目管理工具-Leangoo。 它是由国内最早推广敏捷 也是最权威的 Scrum中文网 研发...
  • Scrum敏捷开发的项目管理

    千次阅读 2018-04-27 15:49:26
    Scrum开发的步骤及准备Scrum敏捷开发的关键字就是增量、迭代,他更重视项目团队之间的现场沟通,不向传统瀑布式开发那样需要万事具备,才开始开发,Scrum在大方向和小故事点确认好了后,团队就可以开动了。...
  • 对于互联网公司来说,速度成了企业竞争制胜的关键因素,一方面用户的需求在不断变化,另一方面采用传统开发模式的互联网哦你公司难以满足这些需求,所以诞生了敏捷开发模式 敏捷开发(Agile Development)是一种以人为...
  • 敏捷项目管理Scrum连载系列之Scrum在团队中的应用 老程的自习社 2020-03-22 21:28 往期文章 敏捷项目管理Scrum连载系列——初识Scrum 敏捷项目管理Scrum连载系列之Scrum理论与应用篇(一) 敏捷项目管理Scrum连载...
  • 基于JIRA的Scrum敏捷开发的项目管理

    千次阅读 2019-09-16 16:00:50
    Scrum开发的步骤及准备Scrum敏捷开发的关键字就是增量、迭代,他更重视项目团队之间的现场沟通,不向传统瀑布式开发那样需要万事具备,才开始开发,Scrum在大方向和小...
  • #Scrum Master——项目负责人、项目经理 保护团队不受外界干扰,是团队的领导和推进者,负责提升 Scrum 团队的工作效率,控制 Scrum 中的“检视和适应”周期过程。与 Product Owner 一起将投资产出最大化,他确保...
  • Scrum项目管理办法

    2012-03-15 16:06:36
    本人于2012.2写这片文档时有着3年的CMMI3流程项目管理经验,2年Scrum敏捷项目管理经验,共7年大中型软件公司服务经历。 所以本管理办法可为刚接触或正在推广与规范Scrum敏捷项目管理的朋友提供参考。 办法中包括了...
  • Scrum实战——敏捷软件项目管理与开发

    千次下载 热门讨论 2013-04-09 16:52:31
    Scrum实战——敏捷软件项目管理与开发》为软件项目团队提供了如何成功实施敏捷软件框架Scrum的实用指南。本书叙事清晰准确,是第一本由实践者编写的针对现实状况的实用指南。书中描述了如何使项目团队价值最大化,...
  • 只要是在IT互联网行业工作的人肯定对 Scrum敏捷开发 都多多少少有一些了解。工欲善其事,必先利其器,那我给大家介绍一款敏捷开发项目管理工具-Leangoo。 它是由国内最早推广敏捷 也是最权威的 Scrum中文网 研发...
  • Scrum敏捷分享

    2018-01-04 15:43:25
    文档详细的介绍了scrum模式,并且根据实际项目做了敏捷设想
  • SCRUM敏捷开发教程

    2019-07-05 16:56:38
    scrum敏捷开发,是一个美国统计学教授记录了多年工作经验,总结出来的一套简单易懂的开发方法,我接触过不少产品经理,惊奇发现不少产品经理的确是产品把控的非常好,输出的BRD,MRD,PRD等都非常专业,但是却没一套很...
  • Scrum敏捷开发

    2020-07-15 10:34:45
    敏捷开发中,软件项目的构建被切分成多个阶段,各个阶段的成果都经过测试,具备集成和可运行的特征。 简单地来说,敏捷开发并不追求前期完美的设计、完美编码,而是力求在很短的周期内开发出产品的核心功能,尽早...
  • SCRUM敏捷

    2018-09-03 12:09:05
    敏捷开发之 12条敏捷原则  1、我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意。 2、欣然面对需求变化,即使在开发后期也一样。为了客户的竞争优势,敏捷过程掌握变化。 3、经常地交付可以...
  • ZenTao是由青岛自然易软网络技术有限公司开发的一种开源项目管理软件,它将产品管理,项目管理,QA管理,文档管理,公司管理和待办事项管理结合在一起。 它是一款专业的项目管理软件,涵盖了软件开发项目的核心流程...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 7,082
精华内容 2,832
关键字:

scrum敏捷项目管理文档