敏捷资料Word下载.docx
- 文档编号:15088949
- 上传时间:2022-10-27
- 格式:DOCX
- 页数:14
- 大小:27.82KB
敏捷资料Word下载.docx
《敏捷资料Word下载.docx》由会员分享,可在线阅读,更多相关《敏捷资料Word下载.docx(14页珍藏版)》请在冰豆网上搜索。
正确理解敏捷(敏捷理念解读)
深入理解“聚焦客户价值”的要点
深入理解“激发团队”的要点
深入理解“适应变化”的要点
敏捷团队、完整团队
应会
敏捷工作件实践
敏捷技术实践和敏捷管理实践
我司敏捷开发实施策略
敏捷推行的指导意见、敏捷推行三步走策略、2009年项目级敏捷实施要求(业务目标、范围)
持续集成的要求、软件代码的质量要求
什么是项目级敏捷?
什么是版本级敏捷?
4
如何开展首次实施敏捷?
5
敏捷角色在我司可能的角色人选?
6
敏捷实施场景
----------------------------------------------------
敏捷诞生的历史背景:
软件开发顺应时代变化,从重型过程转向轻量型敏捷
敏捷宣言:
个体和交互胜过过程和工具;
可以工作的软件胜过面面俱到的文档;
客户合作胜过合同谈判;
响应变化胜过遵循计划.
敏捷的常见误解:
误解一:
敏捷开发意味着可以不需要文档、设计和计划
误解二:
敏捷只是一些优秀实践,或者是优秀实践的结合
误解三:
敏捷只适用于小项目开发
误解四:
敏捷只会对研发产生改变
误解五:
管理者不需要亲自了解敏捷,只需要管理上支持就可以了
误解六:
引入敏捷只需要按照既定的步骤去做就可以了
误解七:
敏捷是CMM的替代品,是另一种流程
误解八:
敏捷只注重特性的快速交付,在敏捷下架构不重要了
统一认识:
敏捷=理念+优秀实践+具体应用
理念:
聚焦客户价值(Value),消除浪费
激发团队(Team)潜能,加强协作.
细化1:
团队是价值的真正创造者,应加强团队协作、激发团队潜能
细化2:
软件开发是一种团队活动,首先应做到提升沟通效率降低交流成本
不断调整以适应(Adapting)变化:
不断的根据经验调整,最终交付达到业务目标的产品
-----------------------------------------------------------------------------------------
优秀实践:
业界敏捷优秀实践概览
电信业:
系统解剖,缺陷管理和决策,需求决策;
Scrum:
产品backlog(带优先级的产品清单),迭代计划会议,Scrummaster,ProductOwner;
XP
:
计划游戏,重构,稳定开发节奏,测试驱动开发,机队编程,代码集体所有,隐喻;
Scrum和XP共有的实践:
回顾会议,客户参与验收,每日站立会议,完整团队;
以上三种实践共有的部分:
持续集成,迭代交付;
------------------------------------------------------------------------------
具体应用:
因地制宜选择适合的敏捷实践;
团队在透彻理解敏捷理念的基础上,可以灵活选择最适合自己的实践,避免教条化;
敏捷转型是系统性工程
敏捷转型是系统工程,覆盖7个方面:
实践、绩效考核、组织、过程、文化、管控、技术和业务对齐
敏捷在敏捷转型不同阶段,敏捷转型框架的7个方面引入的优先级不一样,初期以实践为主
深入理解敏捷理念
1深入理解“聚焦客户价值”
2标识和消除软件开发中的浪费
3交付刚刚好的系统
4随时构建质量,不容忍缺陷
5及时消除技术债务,持续保持快速响应
深入理解“激发团队”
1认清团队的基本事实
2敏捷方式下管理者的转变
3敏捷方式下团队成员的转变
深入理解“适应变化”
1认请“客户是逐步发现真正需求”
2小批量是快速交付的关键
3通过迭代计划不断调整以适应需求变化
4应持续保持良好的软件架构
5利用多层次反馈不断调整以逼近目标
浪费类别
浪费举例
部分完成的工作
部分完成但没有最终落地的工作(没有转化成代码的设计文档;
未及时合入的代码导致引发后续更多同步工作量)。
未应用特性
开发完成但没有被客户应用的特性(交换机2000多个功能客户只用了1%)。
再次学习
人员频繁流动导致经验不能积累,反复重新学习;
在多个环节移交时,
接收信息者也需要重新学习;
拥有某领域的专家,但在开发过程中需要此领域经验时,他却没参与,而是团队重新摸索。
移交
知识信息的传递总是伴随信息丢失,隐形知识尤其困难,分工过细往往导致过多不必要的移交(如详细设计和实现分离,造成大量设计信息丢失)。
任务切换
研究表明多任务工作会导致效率下降20%-40%(员工多头工作或杂事繁多)。
延迟
因任务或资源相互依赖而导致工作停滞(集成时被关键模块阻塞,等待测试环境就绪)。
7
缺陷
解决缺陷活动本身就是浪费,而且缺陷越遗留到后端浪费越大。
聚焦客户价值,交付刚刚好的系统
在项目明显超负荷时,管理者简单地期望靠团队workharder来解决,最终导致:
1质量下降2项目延期3客户不满意4团队疲劳5埋下长期隐患
当质量、进度、资源冲突时,能改变的只有项目范围,即选择“交付刚刚好的系统”.
1产品交付前,客户往往期望多而全的功能,产品交付后,客户把稳定的质量放在首位,尤其在电信领域,客户对产品质量要求是Alwayswork,不是Sometimes。
2与其为了满足多而全的功能导致交付延迟,质量不稳定,不如按时交付刚刚好的系统,保证其高质量运行。
3交付刚刚好的系统,基于对客户需求的深入理解,并花时间了解细节,简化(simplify)需求(降低复杂性)而不是简单地拒绝需求(delete)。
4做到“交付刚刚好的系统”,同时需要管理者有足够的勇气和果断决策
聚焦客户价值,随时构建质量,不容忍缺陷
1缺陷遗留带来高额成本:
2从项目一开始就随时构建质量:
聚焦客户价值,及时消除技术债务,持续保持快速响应
1常见技术债务:
日益腐烂的架构、圈复杂度高的代码、低的测试自动化率、不及时清除的静态检查告警等。
2为什么会有技术债务:
为满足短期商业目标,不影响其外部表现的情况下,会在技术方面进行一定的让步,这种让步虽对当前版本的质量影响甚微,
但会严重影响后续版本响应客户需求的能力,从而形成技术债务。
3对待技术债务的态度:
技术债务是有成本的,如不及时偿还,会随时间积累利息变高,导致开发效率大幅下降,
从而降低客户响应能力。
因此对待技术债务的态度是加以管理并及时偿还(如及时重构)。
激发团队,认清团队的基本事实
关于团队激励:
当团队自管理时效率最高;
人们对自己做出的承诺比别人要求的承诺更认真;
人们会尽力做到最好;
在强大的压力下努力工作,人们会自然而然地降低对质量的要求
关于团队绩效:
当团队成员不被打扰时,工作效率最高
当团队解决自我问题时,提升最快
广泛的、面对面的交流是团队工作最高效的方式
关于团队构建:
团队生产率大于相同数目的个体生产率之和
当不同技能领域的人员组成团队并聚焦于工作时,产品更健壮
关键:
信任是高绩效团队的基石
激发团队,敏捷方式下管理者的转变
1管理者努力“激发”团队:
2通过目标来牵引团队自主工作
3帮助团队提供资源,排除障碍
4营造团队自我管理的工作氛围
5作为教练辅导团队进步
6基于简单原则的管理,原则简单但必须被遵守
敏捷方式下对管理者最大的挑战是学会放松”控制”(loosecontrol)
激发团队,敏捷方式下团队成员的转变
1团队成员是“全方位的积极参与者”:
2共同参与计划制定和任务安排
3团队协作贯穿工作始终
4面对面交流是主要沟通方式
5关注团队目标,共担责任
6能力要求更广,主动学习适应岗位要求
从被动到主动的心态转变是团队成员适应敏捷开发的关键
----------------
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 敏捷 资料
![提示](https://static.bdocx.com/images/bang_tan.gif)