欢迎光临散文网 会员登陆 & 注册

Take Away-敏捷notes

2023-04-05 14:51 作者:爱吃樱桃的小柴犬  | 我要投稿

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分钟以内

ü 提前通知和准备

ü 讨论行动方案,而非问题

ü 会议要得出结论 - 发出会议纪要和行动计划

  


 


Take Away-敏捷notes的评论 (共 条)

分享到微博请遵守国家法律