敏捷是什么
它是一个框架，一种理念，强调持续从客户那获得反馈，并根据优先级进行产品迭代。
敏捷宣言
- 个体和互动 高于 流程和工具
- 工作软件 高于 详尽的文档
- 客户协作 高于 合同谈判
- 响应变化 高于 遵循计划
敏捷宣言阐述4个价值观：
- 以人为本：重视个体间的合作互动
- 目标导向：我们最终交付的是“可使用的软件”，而不是一堆繁重的文档
- 客户为先：理解客户需求，与客户合作
- 拥抱改变：客户每一次提出新的要求，都是在帮我们逐步逼近事实真相
这4点并不是让团队放弃工具，文档，计划，而是将精力放在更核心的事上：人、产品模型、协作和迭代。
敏捷开发的12项原则
1. 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
2. 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
3. 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
4. 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
5. 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
6. 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
7. 可工作的软件是进度的首要度量标准。
8. 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
9. 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
10. 以简洁为本，它是极力减少不必要工作量的艺术。
11. 最好的架构、需求和设计出自自组织团队。
12. 团队定期地反思如何能提高成效，并依此调整自身的举止表现。
我认为，在敏捷实践的过程中，如果遇到不知道如何推进的问题时，就可以从这12个原则中去寻找答案。
敏捷落地的可行性
评估敏捷和团队成员的三观是否符合
可以尝试问以下5个问题：
你是否会愿意接手目标不明确的项目？
目标不明确，是会让参加项目的人在一段时间内迷茫，痛苦。因为这段时间里团队会遭遇到很多的质疑和挑战。敏捷项目管理中有句话，“快速失败”。而且敏捷过程提倡可持续开发，团队不断从错误中积累学习并持续迭代。这意味着我们的团队需要有勇气，有好奇心，有信心，稳定持续地等待“拨云看月”的时刻。你会如何规避项目风险？
你的团队能有多灵活？
公司阶层制度严格吗？
你怎么衡量进度？怎么定义成功？
影响敏捷落地成功概率，除了团队的价值观，还会受到组织架构，组织文化的影响。（“皮之不存毛将焉附”）
如何实施敏捷开发
Scrum + 看板（Jira Tool）
Scrum
3355
3个核心角色
Scrum Master（敏捷教练）：对应敏捷团队的PM（项目经理），职责是促进团队的工作，帮助团队熟悉与掌握敏捷的价值观与框架，帮助团队排除影响生产力的障碍，保护团队不受打扰。
Product Owner（产品负责人）：对应敏捷团队的BA（需求分析师），职责是定义需求，定义需求的优先级，定义需求的验收标准，定义产品发布内容与日期。
Scrum Team（敏捷团队）：通常来讲是敏捷的全功能团队，对交付负责，协作开发，可能跨职能部门，自组织式的扁平化团队。
3个工件
- 产品待办事项 (Product Backlog)：即产品视角的需求清单，由 Product Owner 负责维护，包括增删及优先级，用户故事是其中一种最佳实践，每项需求都需要描述其外部价值。
- 迭代待办事项 (Sprint/Iteration Backlog)：即此次迭代周期内规划要完成的内容，由团队评估和选择产品待办事项中中哪些放入迭代待办事项，团队需要一起定义“完成”的标准。
- 迭代产出成果（也叫迭代可交付产品增量 ，Increment)：即迭代结束后可对外发布的产品功能增量部分，需要关注其是可工作的软件功能增量，需要在成果展示会议（showcase) 上进行演示。
User stroy
Backlog由很多的User story组成。User story一般格式：
As a user, I need ...., so that ....
5个关键事件
- 迭代 (Sprint/Iteration)：1-4周，固定周期，固定时间开始，固定时间结束。
- 迭代规划会 (Sprint/Iteration Planning Meeting)：核心议题是下一个迭代要实现的目标和范围，对产品待办事项中的事项进行估算，以作为是否放入下个迭代的参考，输入是产品待办事项 ，输出有
- Sprint goal
- 迭代待办事项 Sprint Backlog
- Timebox
- Team capacity
- Sprint Release 计划
- 每日站会 (Daily Standup)：站会的目标是促进信息在团队内共享与透明，回答3个问题
- 本次会议之前，我做了哪些事情？
- 本次会议之后，我准备做什么事情？
- 目前我是否碰到障碍，是否需要帮助？
- 成果展示会议 (Review/Showcase)：在迭代结束开，展示本迭代的产出，团队全体参与，邀请相关干系人参与提供反馈。
评估后的有效反馈将流向Product Backlog
- 回顾会 ( Retrospective）：团队一起复盘本迭代的过程，总结经验与教训，并形成切实可行的改进清单。
- Brag (Good to maintain)
- Drag (What to move on)
- Places to improve in next Sprint (Top1-3)
过程监控中团队沟通的工具
-
Burnup Chart 燃烧图
WeChat Image_20210806151222.png
显示项目的总体目标，最初的计划，现状，Gap还有Trend。
- Burndown Chart 燃尽图
显示一个Sprint里User story的完成情况。
-
Velocity 速度
Sprint Velocity是团队在当前Sprint完成的User story point。
Average Velocity 一般是已经完成的Sprint的Velocity的平均值。
在Burnup图中，origin plan里的velocity的值一般参考过去项目Velocity。 -
DoD Definition of Done
评估User story 怎么算完成.
当DoD全都完成后，user story移交给PO review, （依据可接受标准Acceptance Criteria）决定是否close user story.
内容示例：
- 设计文档，设计review
- 完成单元测试，自测
- Test Case review
- Bugs resolved (no major bug)
- 版本发布
...
-
DoR Definition of Ready
评估User story 怎么算可以开始。
内容示例：
- 详细描述
- 可接受标准Acceptance Criteria
- 优先级
- ...
5大价值观
- 承诺 Commitment - 愿意对目标做出承诺；
- 专注 Focus – 全身心都用到承诺的工作上去；
- 开放 Openness – 团队内所有信息对所有人开放；
- 尊重 Respect – 每个人都有他独特的价值和经验；
- 勇气 Courage – 勇于承诺，履行承诺，敢于说不。
曾看到一篇文章，讲一个爸爸用敏捷的方式带孩子管理每天的事情。很有启发，所以贴上：
他有一段解释敏捷价值观的话：最后给大家一个忠告，如果真正想用敏捷的思维培养好孩子，时刻对照自己是否做到敏捷中关键的五大特性：
勇气（鼓励让孩子迎接挑战，说出真相）
开放（让孩子有更多的自主权选择学习目标）
尊重（尊重孩子们的每个意见和想法，不随便以身份去批评打压孩子）
承诺（时刻关注孩子们和自己的任务承诺，答应就要做到）
专注（让孩子们学会一次只做一件事，减少干扰）
Kanban 看板
一直使用的是Jira Board, 看板的好处
- 可视化
-
WIP原则
限制在制品WIP数量，专注一次做一件事 - 明确下一步行动
实践中常见的问题 (解决方案示例待完善)
- Daily Standup 迟到
- Sprint时间过半，但还没有user story 完成
- 跟外部部门合作受阻，提的问题处理进展不清楚
- 测试环境的硬件版本不统一
- 多语言测试的设备不够
- Sprint 最后几天大家节奏明显加快，甚至需要加班
- 需求中途变更，Scope增大
- 评估时间不够
- User story开发完成，不知道交付给谁测试
- 。。。
我的感想
两段Scrum Master实践经历，让我从一个对Scrum 懵懂朦胧的状态，成长为一个掌握基本功的Facilitator。
接下来面临的课题有：
- 如何从使用推力转换成使用拉力而促成合力
这涉及团队沟通，协调能力，以及个人影响力的打造。 - 如何从容应对变化，包括来自需求，执行等
- 结合实践深入理解体会敏捷的价值观
