Take Away-敏捷notes

Volatility 波动 Uncertainty 不确定性 Complexity 复杂 Ambiguity 模糊
Vision 愿景 Understanding 理解 Clarity 清晰 Agility 敏捷

Ø 十二大原则
1. 我们最重要的目标,是通过及早和持续不断地交付有价值的软件使客户满意。
2. 欣然面对需求变化,即使在开发后期也一样。为了客户的竞争优势,敏捷过程掌控变化。
3. 经常地交付可工作的软件,相隔几星期或一两个月,倾向于采取较短的周期。
4. 业务人员和开发人员必须相互合作,项目中的每一天都不例外。
5. 激发个体的斗志,以他们为核心搭建项目。提供所需的环境和支援,辅以信任,从而达成目标。
6. 不论团队内外,传递信息效果最好效率也最高的方式是面对面的交谈。
7. 可工作的软件是进度的首要度量标准。
8. 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
9. 坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强。
10. 以简洁为本,它是极力减少不必要工作量的艺术。
11. 最好的架构、需求和设计出自自组织团队。
团队定期地反思如何能提高成效,并依此调整自身的行为表现。
Ø 四大价值观 4大宣言
个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
Ø 3 大角色
Product Owner (PO)PO是了解客户需求以及相关商业价值的团队角色,作为客户代表,定义产品功能,决定产品发布的内容和日期,对产品的投入产出负责。根据市场变化对需要开发的功能排列优先顺序,合理调整产品功能和迭代顺序。
Scrum Master (SM) 敏捷教练SM 将帮助团队消除任何阻碍团队生产力的障碍,SM的角色是培训和激励团队成员。他起到教练的作用。
Development Team (Dev.Team)开发团队由关键开发者或架构师等5-9人组成,他们各有职责但又是多面手,能独当一面又能互相支持。他们在敏捷开发在不断的组织和管理属于自己的工作,由此产生的协作力将优化团队的整体效率和能力。
Ø 5 个会议
1.产品梳理会:30min.拆分历史,分析并排列用户故事,经过分析将不明确和待完善的地方加以完成,以免将这些残余问题留到迭代计划会上。
2.迭代计划会 Sprint Planning Meeting,1-2h。选择本次迭代的目标并给出工作量估算。
3.每日站会 Daily Scrum Meeting
会议主要讨论三个问题:
- 昨天做了什么?
- 今天将要做什么?
- 有需要帮助的地方吗?
4.迭代评审会 Review Meeting
5.迭代回顾会 Retrospective Meeting
Ø 构建敏捷文化(目标):文化→价值→原则→实践→工具
优化我们的思维和行为模式,减少不必要的时间浪费,提高产品的市场满意度:MVP
MVP - minimum viable product,最小可行产品
以最简易的产品形式进入市场试错,多犯错、早犯错,然后根据错误对产品进行快速迭代。以最小的时间成本和金钱成本去试错,从而换取在市场中的快速成长的机会。
做产品的时候,很容易脱离实际的市场,而市场的变化是十分迅速的,一个“完美方案”不应该是在脑子里想出来的,而应该是切合市场,从实际的市场需求和反馈中推演出来的。
Ø Design Thinking(工具)
用户视角
设计思维五大步骤
同理心(Empathize)—— 研究用户的需求
定义(Define)—— 陈述用户的需求和问题
构思(Ideate)—— 挑战假设并创造想法
原型(Prototype )—— 开始创建解决方案
测试(Test)—— 尝试您的解决方案
Ø Backlog 管理(工具)需求管理 或 Job 管理方法
Ø Waterfall PRD 文档 VS Scrum Backlog
Waterfall PRD传统的瀑布工作模式使用详细的需求说明书来表达需求,需求人员负责做需求调研,根据调研情况编制详细的需求说明书,进行需求评审,评审之后签字确认交给研发团队设计开发。在这样的环境下,需求文档是信息传递的主体,也是一份契约。然而这种详细的PRD 文档有以下5大弊端:
1. 单向的信息传递,容易出现理解偏差。
2. 文档很正式,我们会误以为它一定是对的,不去质疑它,让我们停止作出判断。
3. 有了详细的文档,我们不会反复讨论它,相互确认。
4. 书面文档不利于团队共享责任,它扮演了证据的角色。
5. 编制详细的、表达准确需求文档需要花费大量的时间,如果需求变化频繁,维护成本更高。
Scrum Backlog敏捷使用产品Backlog来管理需求,产品 Backlog 其实就是一个优先级排序的需求清单,优先级的需求在 Backlog 的最上层。更强调团队共享责任,团队会用10%的时间梳理工作。共同目标是通过讨论协作,正确理解需求之后把这些需求变成客户真正需要的功能,而不是单向的任务传递。
1. 详尽适当(高优先级的比低优先级的技术更详细。优先级越低,细节越少)
2. 可估算(以故事点或者理想人天形式表达)
3. 演化(根据用户的不断反馈,识别出新条目会被加入Backlog里面
4. 按优先级排序(所有条目都是按照优先级排序的,最重要、优先级最高的条目最先实施,一旦完成,便从 Backlog 移除。纸质卡片)

Ø 敏捷会议原则(工具)
ü 明确会议需要达成的目标
ü 明确时间和日程 - 控制时间 40分钟以内
ü 提前通知和准备
ü 讨论行动方案,而非问题
ü 会议要得出结论 - 发出会议纪要和行动计划