笔记

模式一：不知不觉。 ----毫无观念，初始管理。
模式二：例行公事。 ----用工具
模式三：驾驭自如。 ----
模式四：未雨绸缪。 ----为后面的规划，设计目前的设计。

敏捷开发痛苦原因： 把缺陷放在了开发侧来发掘和解决。

反复无常模式。

提升驱动力：
第一：来自企业自身的驱动力。
第二: 来自客户端驱动力。
第三：问题本身的驱动力。

三个方面：

1.建立清晰管理模型。明确目标。
2.明确目标要逐层分解和计划。 ----让开发和管理都知道。---依靠工具。 
   例子：各个项目经理写三个月的产品规划。
     ---非常模糊。
        解决方法：a组和b组。--review互看。
3.目标是可视化的,要所有人都要知道目标是什么。
  -----目前我们部门没能做到的。
  汇报：1.上周做什么。 2.下周做什么。 3.遇到什么问题困难。
 
4.反馈作用：
   1.现在处于什么位置。 3天--做了两个星期。
   2.规划完后，目标是什么位置。最终方向的是什么地方。 行动如何到目标位置。有能力调整方向。
     要交互可用的软件。你需要有能力做到。设计和编码。

   客户：为什么要两个星期就要上线？？工作方式：
   清晰个管理模型。一个星期演示。

5.结对编程：目的：1.每个人都了解你的业务。 2.代码在团队中间

敏捷失败原因：     ----设计开发能力跟不上。---重构，设计。----解决复杂度。

6.心态上的不同： 开发人员未来完成开发人物，  开发经理要完成用户体验。

user story：用户角度去写，
1.卡片本身，代表需求的存在。
2.代表一段对话和交流。从前到后，需求分析 开发 测试 部署沟通。
3.用户的确定性，做完的条件 验证的条件。

表达：xyz
x--用户
y--功能，希望什么功能，以便用户目标
z--价值

用户功能，以便于。。。

user story原则：
1.可以独立开发 
2.对客户来说，这个user story是可协商的。
3.是要有价值的，即用户为什么要实现该功能。
4.工作量大小是可评估的。
5.可测试验证，站在客户的用户视觉，来验证。

user story的过程就是 把信息进行分解，分类转换成可实现的条目。

注意：开发人员开发完成 让 业务人员 确认验收，才能提交测试。  业务分析师认为有问题，要第一时间打回去开发人员修改。

user story需求分析
spy

TDD开发

可视化：story work

敏捷+个人能力（oop面向对象 TDD）