- 敏捷中管理相关方
对于客户：面对面交谈
对于团队：有共同的理解、目标 - 敏捷中识别风险的会议：每日站会
- 敏捷中负责批准用户故事：由产品负责人负责批准或拒绝用户故事。
- 敏捷中不会迭代的过程：制定项目章程
- 敏捷中审查绩效：“绩效”即在确定的时间内，完成多少用户故事。这个完成情况可以通过燃尽燃起图来展示。
- 敏捷中的计划
1）项目章程：提供项目目标、成本、预算等总体概述；列有积极参与项目的利益相关者清单；敏捷章程通常记录在白板上。要素：愿景、使命、成功标准。
2）发布计划：表明团队在已识别的项目目标和限制因素下如何实现产品愿景；定义一个产品发布的版本或者一个具体可交付成果的增量。关键信息：团队的平均历史速度、一个发布计划内的迭代次数。
3）迭代计划：为完成任务或故事而将执行的一系列活动；开发人员的任务，指出他们需要完成的用户故事。应该识别：实现的主题和目标、定位团队开始迭代工作的位置。
发布计划与迭代计划区别：发布计划期待产品的发布，而迭代计划只关注迭代长度。发布计划基于用户故事，迭代计划基于任务计划。 - 水晶方法
研究参与项目的人数、项目优先级、关键属性。 - 敏捷中不会迭代的流程：制定项目章程
10.PO与团队意见不一致：按PO的意见执行。 - 重构
重构应该被重点关注，尤其是在发现问题后，立即在下一个迭代关注。 - 未完项迭代进度计划和按需进度计划
未完项迭代进度计划：适用于适应型生命周期的滚动式规划，如敏捷开发方法。
按需进度计划：适用于看板体系，如当资源可用时从未完项中提出来展开。 - 敏捷中的会议区分
- 迭代回顾会：经验总结、流程改进。解决问题、接下来迭代的改进计划；反思团队绩效，目的是提升团队工作效率。(如面临质量问题时通过该会分析原因)
- 迭代评审会：反馈，下一步计划。展示验收，小组向产品负责人展示和验收迭代工作结果，发现的问题或改进将被累积到产品待办列表（无需提变更请求）；讨论下次冲刺的高级别计划。
- 冲刺计划会议 ：明确目标、细化任务。决定本次迭代完成哪些任务，如何完成。
- 待办列表梳理会：创建用户故事、拆解用户故事、排序等。
排序方法：MoSCoW、Kano模型、100点、相对量级
待办列表梳理会完成，冲刺规划会议才能开始。 - 敏捷中的对比
- 发布规划：确定迭代次数
- 产品路线图：确定发布次数
- 迭代待办事项列表：确定用户故事数 - 技术债务
往往指的是质量风险、质量问题。 - 敏捷中的注意点
不用需求跟踪矩阵；
无需提交变更请求，变更无需CCB；
速度、任务由团队成员决定；
采购设备等由团队决定和安排；
和相关方讨论需求是PO的职责；
没有sprint章程，只有sprint目标和项目章程；
管理质量的主要方式：评审会和回顾会；
敏捷团队管理不需要找指导委员会批准；
项目章程/愿景是由PO去澄清的； - 敏捷中的问题检测
- 识别问题：每日站会、冲刺回顾会 - 敏捷中的风险管理
- 风险识别：需求收集、计划扑克、迭代和冲刺计划、scrum会议、迭代或冲刺评审、回顾会 - 敏捷中的质量管理
定义已完成的定义（Dod）、回顾会、评审会 - Kaizen
持续改进的会议：站会、迭代评审、回顾会（通过障碍日志）
看板的限制WIP可以改善流程 - 群集与群体开发
群集：多个团队成员集中于单一问题上，协同解决。
群体开发：不集中于单一问题 - 围绕积极的个人构建项目
给他们需要的环境和支持，相信他们能够完成工作。 - 产品待办列表和迭代待办列表
产品待办列表里工作项的添加：PO决定
迭代待办列表里工作项的添加：团队决定 - 每日站会
提出障碍、风险、问题
不报告项目状况。敏捷教练不会在会上为开发人员提供指导。
会审查问题和障碍，不会审查冲突。 - 敏捷团队缺知识缺协作
添加跨职能团队成员 - 风险是记录在风险登记册，而非风险日志
- 发布规划和产品路线图
发布规划：记录了推出前的迭代次数
产品路线图：记录了发布次数 - 技术问题
应鼓励团队自己处理 - 敏捷中验证绩效改进
审查燃起图，即确定时间内完成多少用户故事。 - 每日站会
团队可分享障碍、风险、问题 - 开发人员在迭代过程中离开公司
确定其他跨职能团队是否有人能接手 - 重构：是解决技术债务的
- 看板三大特性
可视化、限制在制品、周期时间
扫一扫
06-19
1662
1662
06-08
1948
1948
03-12
2441
2441
06-10
1117
1117
06-07
651
651
10-24
401
401
11-21
1377
1377
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
