什么是敏捷

• 目标是快速响应变化，快速迭代，快速验证
• kanban
• Scrum-3个角色，5个会议，3套工具
  SM, PO, Dev Team
  需求澄清会、计划会、每日站立会、评审会、回顾会
  产品功能列表、迭代任务、燃尽图
• 文化氛围-团队作战，团队幸福感

敏捷的效果

• 能快速响应变化
• 能得到很高的产品的稳定性和扩展性
  美国一个项目2个亿2年没有做完，敏捷后2000万，大半年就完成了
  有人装修房子，一般大半年，还可能有各种问题。但是使用看板和站立会后，2个月又快又好地装修完了。
• 敏捷能无所不能????

敏捷宣言(四种核心价值)

• 个体和互动高于流程和工具
• 工作的软件高于详尽的文档
• 客户合作高于合同谈判
• 响应变化高于遵循计划

不做草包族

草包族不是中国的骂人语句

二战期间在南太平洋有一些土人，看到飞机降落在地面，卸下来一包包的好东西，其中一些是送给他们的。
二战后他们仍然希望能发生同样的事，于是他们在同样的地点铺飞机跑道，两旁还点上了火，盖了间小茅屋，派人坐在那里，头上绑了两块木头（假装是耳机）、插了根竹子（假装是天线），以为这就等于控制塔里的领航员了——然后他们等待、等待飞机降落。
他们被称为草包族，他们每件事都做对了、一切都十分神似，看来跟战时没什么两样；但这行不通：飞机始终没有降落下来。这是为什么我叫这类东西为“草包族科学”，因为它们完全学足了科学研究的外表，一切都十分神似，但是事实上它们缺乏了最重要的部分——因为飞机始终没有降落下来。 。

所有的敏捷方法我们都学了，敏捷工具都用了，是不是就敏捷了？

Be Agile, Not Do Agile

如果出现下面的情况，又何来敏捷呢：

• PO不能有效把关产品价值方向
• 架构师无法实现产品高稳定性扩展性
• 成员无法完成本职工作，天天埋雷
• 工作内容无法度量，工作结果无法度量

高效小团队

小团队的原因

• 大团队无法快速响应
  协程酒店无线团队，APP开发60人左右，1个月1个版本，产品经理给出PRD，60人一起参加需求评审会，经过需求评审会、需求PK会、范围确认会才能最终敲定版本APP的需求列表。遇到产品需求变更，以及新增需求时，还需要进行change评审会议、昌吉架构评审会议等。团队太大，过程中出现任何一点变化，都需要通知到团队的每个人，沟通成本极高。
• 大团队，修改一个ui图标，都会需要拉上产品经理、UI、软件工程师、测试等一大堆人讨论很久。可能会需要各种沟通、协调。
• 虚拟团队 ，沟通协调工作也非常大

敏捷团队

• 人数较少
• 3个角色
• 理想的敏捷团队：
  所有人都是自我驱动
  团队能自我完善，人员职位不是任命的，是主动承担自然形成的

个人敏捷心得

• 敏捷需要工作内容可度量，工作结果可度量
• 推荐持续交付的双环理论：