各知识领域的敏捷实践
敏捷在范围、进度、质量、沟通、风险、采购中的做法
P513
这一需求。
- 如果相关方只关注某个需求,并认为这个需求优先级最高,也可以把100点都投给
P514
各知识领域中的敏捷-范围
- 优先级排序技术-风险与价值
P515
宽带德尔菲技术之规划扑克
- 各知识领域中的敏捷-范围
- 用户故事估算-故事点数
- 故事点就是敏捷开发创造出来的用来表示开发任务工作量的单位。
- 故事点数是一种相对估算法。
- 敏捷项目发布规划时,通常采用规划扑克(斐波那契数列)估算出“用户故事点数”,为
- 迭代提供进度证据。
P516
下放在桌子上(不要让别人看到你选的数字)
- 大和最小的估算者,要说明为何要选这个点数,然后回到步骤4,直到达成决议为止。
- 1. 每位估算者手上拿着有“斐波那契数列”数字的扑克牌
- 2. PO给出一个用户故事清单,团队同意其中的一个用户故事值为5分
- 3. 产品负责人向参与者朗读一个高优先级的用户故事
- 4.每位参与者先出一张认为他对这则用户故事所需要工作量估算一致的扑克牌,并将牌面朝
- 5. 所有参与者同时把牌翻过来
P517
用户故事估算-来和估算
- 各知识领域中的敏捷-范围
- 当有大量的用户故事时,很可能其中的许多用户故事非常相似,并且只需要相似的工作
- 量来完成,可以采用亲和估算方法。
- 对用户故事快速进行分类,然后再对这些故事类别进行估算。
- 用户故事的大小就像T恤的尺码一样。
- 非常小(XS)
- 非常大(XL)
P518
快速处理,没有正式的变更控制委员会
- v 范围可以更改,可以删除低优先级的功能
- 尽量保持进度和成本不变,对范围进行调整
P519
课件第 519 页
- 各知识领域中的敏捷-范围最小可行产品(MVP)是一种避免开发出并不是客户真正需要的产品,防止功能镀金的开发策略用于收集早期用户反馈,判断产品方向是MVP不是每个迭代做出产品的一部分,而是每次迭代都要交付一个可用的最小功能集合,这个集合的功能可以满足用户的基本需求,虽不完善但至少可用然后逐次迭代做出满足客户预期的产品,直至最后完全满足客户需求关注:我们是否在做对的事情?
- 最小可售功能(MMF)代表功能包足够完整到可以为用户或市场提供价值,同时也足够小,以直接作为独立产品或服务进行销售在软件项目中,增量交付的方式让客户可以更早地获取可用功能,从而早期受益增量交付在帮助团队获得早期投资回报的时候,也获得了早期的反馈,为后续的功能开发提供了参考一般使用此法主要的目的是抢占市场先机关注:我们能卖什么来赚钱
P520
发布计划明确了可工作的功能的总体发布时间表。
- 各知识领域中的敏捷-进度产品愿景是产品的目的地或最终目标产品路线图是产品需求的总体描述,它为开发这些需求设立了一个总体的时间框架。
- 迭代(冲刺)计划中,Scrum团队确定冲刺目标,列出能够在冲刺中完成且支持项目总体目标的需求。
- 品恐素驱,发布计划产品路线图驱动发布1发布2发布3发布计划各个迭代发布计划创建迭代0迭代1迭代2迭代3迭代n迭代计划安排特选代计划性开发进度特性A通过用户故事(按故(用户故事1)特件A(用户故事2(用户故事3)特性B特件C(用户故事④)用户故事5)特性D优先级排序的特性事点估算)交付的已任务A5小时创建的任务(按小为交付用户故事而任务B8小时时估算)任务C4小时任务D12 小时
P521
特性发布特性发布描述
- 各知识领域中的敏捷-进度
- 阶段1:产品愿景价值路线图发布产品
- 描述:产品目标及其与公司战[每次发布计划]
- 负责人:PO阶段7:冲刺回顾
- 频率:至少每年一次描述:团队通过改善环境和流
- 阶段2:产品路线图程来优化效率
- 负责人:Scrum团队
- 描述:构成产品愿景的产品特性频率:当每个冲刺结束时
- 负责人:PO阶段6:冲刺评审
- 频率:至少每半年一次描述:演示可工作的产品
- 负责人:PO和开发团队
- 阶段3:发布计划频率:当每个冲刺结束时
- 最高优先级次高优先级
- 特性发布特性发布描述:特定产品功能的发布时间
- 阶段5:每日例会
- 负责人:PO描述:确定并协调当天任务的优先级
- 频率:至少每季度一次负责人:开发团队
- 阶段4:冲刺计划
- 描述:确定具体的冲刺目标和任务
- 频率:每个冲刺开始时
P522
关键产品目标
- 设定产品愿景
- 产品愿景是产品的目的地或最终目标
- 负责人:产品负责人PO
- 频率:至少每年一次
- 产品愿景声明必须清楚地说明产品的目标,通常使用电梯游说或产品盒
- 关键产品目标:正在开发的这个产品将如何为公司带来收益?
- 客户:谁会使用这个产品?
- 需求:客户为什么需要这个产品?
- 竞争:与类似的产品相比,这个产品如何?
- 主要差异:与当前的主注产品或竞争对手的产品相比,该产品有何差异?
P523
电梯游说电梯游说为了
- 电梯游说电梯游说为了:目标客户谁:他想要什么(需求)这个: 产品是什么(产品名字)是一个:提供什么功能不同于:不像其他竞争者产品的具有这样或那样的缺点我们的产品:有哪些特色(差异)
- 电梯游说样例为了喜欢吃水果的人他(们)想要在网络上购买新鲜水果这个购买水果的APP是一个产地直发团购应季水果的应用它提供全国各地应季新鲜水果的团队功能不像超市、水果店等场所,水果类别有限、价格较高、新鲜度较差我们的水果来源辐射全国,依照订单即时采摘,顺丰快递次日达,保持水果新鲜,没有经销商中间加价。
P524
课件第 524 页
- 一个立体纸盒,用以表达产品的卖点诉求与重点信息,可能方便与相关方沟通产品愿景Y 正面:产品名称主要卖点或主题产品描述特色列表英式软香面包你的丰肉耐人写味
- 产品盒样例V 将产品愿景销售出去的展现方法想象产品将要上架销售包含要传递给客户的图像以及简短描述使用的“语言”很重要
P525
创建产品路线图
- 产品路线图是产品需求的总体描述,它为
- 开发这些需求设立了一个总体的时间框架。
- Apple Innovation Roadmap 2014-2019*
- 可以使用产品路线图来对需求进行分类、
- 排定优先级、确定发布时间表
- 负责人:产品负责人PO
- 频率:至少每半年一次
- 产品路线图勾画出产品多个版本的演变过程,
- 是项目层面的粗粒度计划,关注的是目标而
- 不是细节。
- 产品路线图用于明确项目的中长期目标,也iHoe.
- 用于和项目干系人的沟通。
- innovation projection 2014-2015.Incremertal model impeovementsand
P526
根据Scrum团队的速度,估算所需的冲刺次数
- 发布是指部署到市场上的一组可用的产品特性,发布计划明确了可工作的功能的总体
- 评审产品待办事项列表和产品路线图,以此来决定能支持发布目标的最高优先
P527
各知识领域中的敏捷-进度
- 速度:是指在敏捷项目进行中,一次迭代中团队可以完成的用户故事总点数,速度也称为
- 吞吐量或生产率,在第7版中也叫批量大小。
- 可以帮助我们基于上一个迭代完成的故事点数来评估团队后续的工作能力。
- 经常会在开始的几个迭代中不一致,随着工作的持续开展,会慢慢稳定下来。
- 不同团队间对比速度有实际意义吗?
- in the units you use
P528
干扰,从而减少因为任务切换而带来的浪费
- 个小时,一个站会的时间盒是15分钟
- 时间盒为我们创造了一定程度上的工作秩序,并
- 保证了工作环境的一致性,确保工作不被中断和
P529
课件第 529 页
本页以图示或版式为主,文字内容请对照课件原页查看。
P530
看板的字面意思是“广告招牌”,将所有工作可视化。
- 各知识领域中的敏捷-进度
- 看板(Kanban Boards)是大卫•安德森发现的方法,其根本是丰田汽车的JIT准时制。
- 产品 Backlog开发完成测试完成上线准备项(日期:MM.DD)
P531
们要不断的更新它
- 各知识领域中的敏捷-进度
- Scrum任务板(Task Boards)展现了我们在Sprint过程中所有要完成的任务。在Sprint过程中我
- 们要不断的更新它。无论每日站会过程中或者之后发生了变化,会根据变化在任务墙上做相应
P532
累积流量图在制品数量减少,带来周期时间缩短
- wMW啪wwMWwmm8mw哟wmw4哒哒ww8wwz
P533
课件第 533 页
- 各知识领域中的敏捷-进度在制品(WIP)占用了项目资金,过多会产生一些问题,比如:WIP隐藏了工作过程中的瓶颈WIP存在返工的风险敏捷方法提出要限制WIP
- 发布/完成发布/完成WIP太低:人员烃常先闲置WIP太多:造成工作流阳塞发布/完成WIP合适:基本不会有人闲置,平均1.5~2个
P534
课件第 534 页
- 过。
- 因此,测试驱动开发可以保证需求被正确实现,因为测试和开发同时进行且开发一直持续到测试通
P535
开发团队中的每一位成员都可以对任何部分的代码进行编写和修改
- 由于代码经过多人处理,因此更加有利于成员迅速发现问题
- 每天对完成的代码进行一次或多次集成来生成可运行的软件
- 在集成过程中,能够使开发团队的成员检查正在实现的用户故事是否可以同产
- 通过持续集成来定期检查冲突,从而保证产品质量
P536
敏捷对于分散式办公,可以考虑
- 敏捷对于分散式办公,可以考虑:追逐太阳、鱼缸窗口、远程结对。
- 开每日会议。
- 追逐太阳的开发过程是一种每天结束时将工
- 作移交给下一个工作地点(可能相差很多时区)
- 别在美国和中国,部分时间彼此重叠,以便工作
P537
各个地点之间建立长期视频会议链接,创建
- 作滞后问题。
- 进行互动,减少了身处不同地点工作所固有的协
P538
各知识领域中的敏捷-沟通
- 是一种由两名团队成员结对、同时从事同一工作项目的技术。而远程结对是通过使用虚拟会议工
- 具来共享屏幕,包括语音和视频链接,建立远程对接。只要考虑了时区差异因素。这种方法几乎和面
- 对面的结对一样有效。
P539
持续更新项目信息,要放在团队或其他干
- 团队内部,信息传达最有效的方法都是面对面的交谈。
- 或其他必须要有操作才看到的地方。
- 敏捷推荐面对面沟通方式,这是敏捷12原则里面第6个原则提到的—无论是对开发团队还是
- 系人容易看到的地方,而不是放在计算机
P540
课件第 540 页
- 各知识领域中的敏捷-沟通开会也是一种沟通方式会议类型冲刺计划会为本次冲刺计划工作每日站会团队成员同步工作进冲刺评审会评审冲刺结果,寻求冲刺回顾会反思工作过程,团队持续改进工作方式
- 召开时间主要步骤①产品负责人澄清故事②团队估算大小③选择故事作 迭代目标①昨天完成了哪些工作②今天计划做哪些工作③有什么困难①开发团队演示功能增量迭代后期②客户、产品负责人等给予反馈③整理反馈、更新产品待办事项列表①澄清目的迭代后期②征求建议③选择关键改进条目④制定行动计划
- 关键参与人员产品负责人敏捷教练开发团队敏捷教练开发团队产品负责人、客户、主要干系人、敏捷教练、开发团队产品负责人敏捷教练开发团队
P541
课件第 541 页
- 各知识领域中的敏捷-风险刺探/探针Spike基于风险的刺探,以一个短的、有时间限制的努力,进行快速试验,用以发现一个降低项目风险的方法,以协助团队获得问题答案并決定前时方向当团队采用新的技术或工具时,进行刺探是非常必要的
- 风险燃尽图风险燃尽图可以快速地告知干系人项目风险是否按照正确的方向发展,或风险严重等级在增加。通过风险燃尽图,干系人可以速查随着时间项目风险管理的绩效。
P542
冲刺中的测试引入了快速失败的理念
- 成本投入到需求、设计、开发的长期工作后,在测试阶段才发现这些问题。
- 开发团队经过几次冲刺后即可识别阻碍产品开发取得进展的关键问题,不必在将大量
P543
这样一来,变更只针对适应型工作,而不会对主体协议造成影响。
- 这种情况下,可以通过主体协议,来管辖整体协作关系,而将适应型工作定入附录或补充文件。
- 风险共担式采购模型,让买方和卖方共担项目风险和共享项目奖励、
P544
课件第 544 页
本页以图示或版式为主,文字内容请对照课件原页查看。