一.什么是敏捷?敏捷是神马?
1.敏捷各路诸侯:
OpenUP、精益开发、极限编程(UP)、SCRUM、MSF(微软解决方案框架)、水晶方法、特性驱动开发
2.敏捷的四大宣言:
个体和互动更加优于流程和工具
工作的软件更加由于详尽的文档
客户合作更加优于合同谈判
相应变化更加优于遵循计划
3.十二准则
1.我们的最高目标是,通过尽早和持续地交付有价值的软件来满足客户
2.登建对霸苦需竞争程是在项目开发后期,要善于利用霸求
3.要不断交付可用的软件,周期从几周到几个月不等,且越短越好。
4.项目过程中,业务人员与开发人员必须在一起工作
5.龍无程目人员,给他们以所需要的环境和支持,井相信他们
6.无论是团队内还是团队间,最有效的沟通方法是面对面的交谈。
7.可用的软件是衡量进度的主要指标8敏捷过程提倡可持续的开发。
8.项目方、开发人员和用户应该能够保持恒久糖定的进展速度
9.对技术的精益求精以及对设计的不断完善将提升敏捷性
10.要做到简洁,即尽最大可能减少不必要的工作。这是一门艺术。
11最佳的架构、需求和设计出自于自组织的团队。
12团队要定期反省如何能够做到更有效,并相应地调整团队的行为
4.SCRUM是神马?
SCRUM是近年来最火的敏捷方法论
SCRUM中文翻译为:橄榄球;
SCRUM适用于大中小型项目
SCRUM核心内容:团队架构和软件研发框架
二.SCRUM的团队架构
1.传统的团队架构
项目经理带领下有:系统分析员、软件设计师、程序员、测试工程师、实施工程师、配置管理员、QA
2.实际的团队架构(分等级层次)
项目经理(团队的头)下带领的:
两种决策——系统分析员、软件设计师
以程序员为核心
测试工程师和实施工程师次之
配置管理员和QA为末端
3.SCRUM的团队角色:产品负责人、SCRUM Master、“自组织”的开发团队
4.产品负责人=产品经理?
产品负责人的主要职责:
提供愿景
提供边界
提供用户故事的优先级
结果为产品负责人≠产品经理
5.团队协作示例
团队协作有产品负责人、业务分析师、测试人员和程序员构成
其中共需完成10项任务,各自任务如下
产品负责人:讨论用户需求、给FedEx指定测试
业务分析师:讨论用户需求、给FedEx指定测试、调查DHL、给DHL指定测试
测试人员:讨论用户需求、给FedEx指定测试、FedEX测试自动化、给DHL指定测试、DHL测试自动化、加入构建
程序员:讨论用户需求、支持FedEX设计、编码和单元测试、加入构建、支持DHL设计、编码和单元测试
三.SCRUM佳实践
1.用户故事:
示例:-作为网络的所有者,我希望能统计广告的点击次数,以便我能清楚广告收益
标准格式:-作为……角色——从用户的角度来思考问题
-希望系统可以......(目标)——思考系统要实现什么功能,达到什么效果等
-以便......(原因)——思考这个功能对于用户有什么价值
非常方便讨论!
2.用户故事的难点:
需求由一系列大小不一定的用户故事组成
最开始的用户故事往往是大故事,需要拆分为中故事,小故事。
难点:
发现和提炼用户故事,由粗到细的拆分用户故事,实现用户故事的优先级分派到不同的sprint中去实现
3.开始分解用户故事:
从第一个用户故事开始分解。
-细分“以便......”这部分
-反向思考“希望系统可以......”部分
进行系统涉众分析,列出关键用户
-思考个用户在本项目上的利益所在
-思考“希望系统可以”这部分
-思考“以便......”这部分,确认“希望系统可以......”这部分的是否合适
4.用户故事到底要拆分到多细?
两大标准:
-能在一个Springt中完成
-加入满意条件(详细要求)
例如:
-以下用户故事可在一个Sprint中完成:
作为负责市场的副总裁,我想在评估以往广告促销活动的效果时可以选择节假日季节,以便我能确认那些有利润的促销活动。
“满意条件”示例:
确保它可以工作在大部分零售节假日
支持跨2个日历年的节日
节假日季节可以从某个节假日到另一个设定
节假日季节可以设置为改节假日前面的某些天
不用支持中国的春节
四.Product Backlog和Sprint Backlog
1.Product Backlog:
-中文翻译:产品代办列表
-产品需要完成的所有用户故事的集合
-用户故事有大有小,既有史诗级别,也有小颗粒级别。
2.Sprint Backlog:
-中文翻译:冲刺代办列表
-Sprint中需要完成的所有用户故事的集合
-Sprint中的用户故事都可以在该Sprint中完成,并且都应该有满意条件
3.Sprint-1
一个Sprint就是一个小版本
建议时长是一个月
一个Sprint并不是一个“小瀑布”
-很难区分需求、设计、编码、测试阶段
-所有工作基于对用户故事的讨论
-测试先行,测试驱动,单元测试必不可少
-设计也是“涌现”式的
4.Sprint-2
产品负责人和“自组织”开发团队商量并规划每个Sprint的用户故事
估算用户故事:
精准估算有“满意条件”的用户故事
精准估算规划在Sprint中的用户故事
粗略估算或暂不估算大中粒度的用户故事
估算由“自组织”开发团队负责
精准估算时,单位建议为小时;粗略估算时,单位建议为天
5.Burn Down Chart(燃尽图)
用来追踪Sprint未完成工作的情况
以未完成工作为纵轴,第1天到第30天为横轴,用户故事、故事点和工作量为计量单位
理想曲线为未完成的工作由第一天到第30天称直线y=-x降低,到第30天为0
实际曲线在第一天到第十五天小幅度降低,第十六天到第三十天大幅度降低,并在第三十天为零
6.Sprint中的一些最佳实践
结对编程
持续集成
测试驱动、测试自动化
每日会议
Lessons Learned(经验教训总结)