价值驱动
需求
资源
时间
敏捷宣言
个体交互重于过程和工具
可用的软件重于完备的文档
客户协作重于合同谈判
响应变化重于遵循计划
敏捷原则
我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。
欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。
要不断交付可用的软件，周期从几周到几个月不等，且越短越好。、
项目过程中，业务人员与开发人员必须在一起工作。
要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。
无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。
可用的软件是衡量进度的主要指标。
敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
对技术的精益求精以及对设计的不断完善将提升敏捷性。
要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。
最佳的架构、需求和设计出自于自组织的团队。
团队要定期反省如何能够做到更有效，并相应地调整团队的行为。
335
角色
产品负责人（Product Owner）
负责产品需求的提炼、条目化、优先级排序。
- Scrum主管（Scrum Master）
负责维护Scrum方法的秩序，并协助解决非技术问题。
- 开发团队（Team）
以“自组织”的相对偏平化进行管理，负责完成开发工作。
工件
产品列表（Product Backlog）
迭代任务列表（Sprint Backlog）
可交付的产品增量
活动
迭代计划会（Sprint Planning）
每日站立会（Daily Stand-up）
需求梳理会（Product Refinement）
迭代评审会（Sprint Review）
迭代回顾会（Sprint Retrospective）
用户故事
I.N.V.E.S.T原则
Idependent
Negotiable
Valuable
Estimable
Small
Testable
若有收获，就点个赞吧
0 人点赞
