腾讯敏捷培训日new精品PPT课件

分组竞赛游戏——运气球
角色：运气球1人、装气球2-3人、卸气球的人2-3人、 监工计时1人
规则： •动作不能夹、藏、挟，只能抱
•只能让组内一名最瘦小的成员充当搬运工
•只要有气球掉到地上，本次运气球算0个
Round 1： 用最快的速度搬运尽可能多的气球 只能搬运一次 搬运最多气球数的队获胜，相同个数下比较两队耗时
Round 2： 用最快的速度把所有的气球运过去 可以搬运多次 全部气球搬运完成且用时最少的队获胜
目前列入敏捷方法的包括
极限编程，en:XP/en: Extreme Programming Scrum 特性驱动开发，FDD/Feature Driven Development 测试驱动设计，TDD/Test-Driven Design 敏捷数据库技术，AD/Agile Database Techniques 敏捷建模，AM/Agile Modeling 自适应软件开发，ASD/Adaptive Software
软件行业的制胜法宝
在这个快鱼吃慢鱼的时代，质量和速度成 为软件行业的制胜法宝！
什么是敏捷？ ——在动荡的业务环境中获得利益并创造
和响应变化的能力
敏捷源起、敏捷宣言
敏捷 一词来源于2001年初美国雪鸟滑雪胜地的一次敏捷方法发 起者和实践者的聚会，随后他们成立了“敏捷联盟”
雪鸟会议共同起草了敏捷软件开发宣言。其中最重要的部分就是 对一些与会者一致同意的软件开发价值观的表述：
争优势。 经常交付可以工作的软件，从几星期到几个月，时间尺度越短越好。 业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。 围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，满足他们的需
要，并相信他们能够完成任务。 在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。 可以工作的软件是进度的主要度量标准。 敏捷过程提倡可持续开发。出资人、开发人员和用户应该总是维持不变的节
Analysis Design Coding Testing
Analysis
Design Coding Testing
Analysis Design Coding Testing
适时冻结
Agile work flow
产品组
产wk.baidu.com组
产品组
开发组 测试组
开发组 测试组
开发组
…
测试组
上一次迭代 当前迭代 下一次迭代
外部压力：市场；竞争 对手；高层领导
甚至多次评审， 结果仍是四不像
Plan 评审点 Design 评审点
PMM 1个月
UI
DE
1个月+
2个月
50个UI图
甚至3个月开发需求
高Cost1
高Cost2
Code
成品
TE
…
每个版本进行回归测试，TE压力大
高Cost3
产品发布节奏
B/S 挑战 3d~1w 发布一次 C/S 挑战 1w~2w 发布一 次
应用敏捷开发
研发管理部
敏捷培训宣言
交互与气氛
over 讲义与脚本
现场投入
over 照本宣科
灵活运用白板、卡片 over 逐页播放照幻灯片
寓教于乐
over 灌输知识
上午(9:30-12:00AM)
敏捷方法概述 游戏：抱气球 迭代式软件开发方法 XP Scrum FDD 情景剧 重构和持续集成 TDD 质量驱动软件开发 游戏：standup meeting
Release1%发布出去
How to do …
迭代周期
先确定迭代长度，再划分特性粒度 迭代周期在可实践的基础上尽可能短 一个迭代至少包含两个以上特性 需求扰动
固定一个迭代的特性，有利于团队集中精力完成任务 正在开发的特性发生变更，应将其移出本次迭代 对变更的特性重新分析在下一次迭代中实施 开发组无须等待，应继续本次迭代中其他明确的特性 额外的特性
What? 迭代是一个固定的时间段Timebox 将产出一定数量的特性 包括计划、实施和回顾 将发布周期分为一系列的迭代
Why? 逐步验证产品的方向 更好地观察项目进度 节省了团队内工作流程等待时间 项目过程可控可测 根据变更及时调整特性优先级
现有开发流程的trouble时序
迫于压力被打回，所有人unhappy
项目过程时序图
现状 PMM/PM/DE/UI/TE
串行
如果没有一方“强”能控制大局，则陷 入整天开会、议而不决甚至讨论出四不 像
从串行到并行，以PM为中心
评审高效30min内， 非多人开大会的形式
<=半天轻量Test
PM/PMM 小的FDD周期滚动
DE先自己进行“外行”的UI设 计
通过server/client 开关机制
敏捷思想
传统方法
人和交互
重于
过程和工具。
可以工作的软件 重于
求全责备的文档。
客户协作
重于
合同谈判。
随时应对变化
重于
循规蹈矩。
其中位于右边的内容虽然也有其价值，但是左边的内容最为重要。
敏捷12原则
对我们而言，最重要的是通过尽早和不断交付有价值的软件满足客户需要。 欢迎需求的变化，即使在开发后期。敏捷过程能够驾驭变化，保持客户的竞
根据经验来计划迭代的产出，额外的特性给团队带来加分 一个迭代中准备比预期多一些的特性，以应对变更 准备多种大小颗粒度的特性，给较早完成的DE分配额外的小特性
迭代划分
迭代是一个系统中完整的一部分
分开实现功能、界面和数据库是伪迭代
划分依据： 需求 时间
需与接口部门协调的特性则需细分，假象对方已实现了。
下午(2:00-6:00PM)
敏捷需求表达User story及变更管理 Planning game 敏捷项目实战 游戏：搭怪兽 迭代0 Agile培训回顾及总结
敏捷方法概述
软件危机和制胜法宝 敏捷源起、敏捷宣言 敏捷十二原则
软件危机
有多少软件delay?幅度多少？ 有多少超过原始预算？幅度多少？ 有多少是启动了而未实现的？
奏。 对卓越技术与良好设计的不断追求将有助于提高敏捷性。 简单——尽可能减少工作量的艺术至关重要。 最好的架构、需求和设计都源自自我组织的团队。 每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为。
迭代式软件开发方法
Agile iterative
迭代计划 迭代回顾
Time box
-轻UI（2个UI）非全部50个， 其他48个留到后面画
-轻设计（30min手画架构图） 尝试白板展示，后续补
-轻Test 1个人 2hour~ 半天自动化Tools内部 测试环境
下次release
并行工作 UI
Design 2个
n+1cycle发布
Design 48个
Release To 1%
-CC打标记 -Release系 统简单登记