敏捷开发概述

3355

角色

User

• 用户，如审核同学

PO

• 确保做正确的事情
• 需求分析，定义产品需求并确定优先级（敏捷比较看重优先级）
• 原始需求细化成Story，形成Backlog
• 迭代需求澄清会，负责对团队进行需求澄清。团队的输入
• 输出需求文档，文档中包括基本的原型图

非敏捷的管理，此角色缺失现象比较严重。正常来说，不应该是研发内的人。

Scrum Master

• 确保正确的做事
• 确保团队不被打扰
• 组织会议，计划会，评审会，站会

SE

• 把PO的需求转化为研发可开发的功能与系统
• 架构设计，数据库设计，模块间（并不是所有的，模块内部的接口）交互流程
• 输出系统设计文档

MDE

• 负责模块的设计
• 可以迭代的周四和周五可以进行MDE，详细设计，然后下一周周一到周三开发（一周一迭代）

SWE（软件工程师）

• 开发、单元测试

TSE

• 测试方案，确保全流程测试

UE

• 交互设计

仪式感

计划会

• 2周的计划会，4小时内
• 全员参加，不是PO与Master讲下面人听，最好分小组，然后小组复述

站会

• 昨天做了什么、今天计划做什么、遇到的问题
• 提出问题（只说明需要谁支持），而不解决问题

评审会

• 尽量不需要刻意准备
• 可研发自己demo
• 如果没有

回顾会

• No Blame，菜做不好，不一定是厨子问题
• 做的好的地方，不好的地方，改进措施（需要具体）

每个会议由自己的会议，评审、回顾、下次的计划可以一起开，但要分清楚每个会议的focus。

QA

敏捷团队一般人员是否非稳定？

建议稳定，相互了解，方便沟通

迭代任务无法完成？

敏捷强调时间点，如果此迭代无法完成，推到下个迭代。

考核？

kpi肯定做不到公平。如果用敏捷这种方式，考核更关注团队，对每个人trust，考核也更关注整个团队的，而弱化个人的考核。

一定要遵循这些实践？

不一定，可以进行实验，如果不合适，就不采用。