[敏捷工程实践]-新讲稿

社招-training

1.What is XP?

a.support to agile mangement practice
b.core of Agile

2.three level in XP

从内到外。 最里圈为个人实践，中间层为团队实践，最外层为交付实践。


3.XP for cooperation and communication

4.practices in xp



a.whole team

完整团队
一个团队中应包含完成工作需要的所有技能，包括 BA，UX，Dev，QA，DevOps等。
在 TW 并不强调角色，因为一个人可以具备多种技能。BA 可以具备 UX 技能，Dev 可以具备 QA 技能。
甚至不需要一个团队里具备所有技能，只要有成长型思维，什么都可以学嘛。

b.Small Release

小型发布
我们追求持续交付，最好每一行代码提交都能直接部署上线。反馈速度决定了学习速度，只有交付到用户手里，才能获得最真实的反馈。
这里涉及到 DevOps 相关的技术。

c.Planing Game

计划游戏
Story 的规模用点数表示，和时间没有关系，不关注每一个人的生产力，只关心整个团队一个迭代的速率。
关心一个 Story 的 Cycle Time 是否最短。
我们采用集体估算的方式，Dev，QA，BA 都可以参与。
故事点使用 Fibonacci 数列：
1，2，3，5，8，13，21...
大家一起亮出估算的点数，请点数最大的和点数最小的人分别发言。目的是分享出他们掌握的信息，让大家对齐。
然后再估一轮，就比较容易达成一致了。如果还不一致，就取个平均数，不用太纠结，估算本来就是不准的，纠结是最大的浪费。

为什么不是 1，2，3，4...？
因为对于估算来说，挨着的两个数就没什么差别。拉开一点距离，这个估的大了一点，那个估的小了一点，反而把误差就中和掉了。

d.Customer Test

用户测试
团队里最好有真实的用户，但一般不太可能，但我们可以找到比较了解用户的代表，他可以帮我们测试软件是否符合他们的真实需求。



e.Collective Ownership

集体所有权
代码不再分责任田，那个模块是你的，这个模块是我的。我的模块你不要动，有什么需求你告诉我，我来改。
集体所有权就是所有人共同拥有所有代码，每个人都有权限和自由去修改。

f.Code Standard

代码规范
所有人遵守同一套代码规范，持续集成服务器会对每一次提交的代码进行规范检查。
通过 Code Review 也可以保证代码规范性。
步骤：
1.介绍需求
2.讲代码：从上到下 从粗到细来讲 从测到实
3.记录，不陷入设计和架构的细节

g.Continous Integration

• (1.原来做软件，先模块各做各的，3 个月后集成一次，结果集成出很多问题，于是延长集成的时间，5 个月再集成，这样会发现集成更加痛苦。
  后来又了 Daily Build，每天集成一次。
  极限编程的意思是，如果一个实践有价值，就要持续去做，做到极致。
  于是就有了持续集成，每一次提交代码都集成，小步快走，频繁提交，一天集成几十次。

• (2.持续集成的纪律：

• 如果集成失败，最重要的事不是继续工作，而是修复它
• 如果集成失败，不要更新代码，除非是为了修复它

• 如果集成失败，不要提交代码

• (3.七步提交法：
  

1.将已集成的源代码复制一份到本地计算机。
2.修改产品代码和添加修改自动化测试。
3.在自己的计算机上启动一个自动化构建。
4.构建成功后，把别人的修改更新到我的工作拷贝中。
5.再重新做构建。
6.把修改提交到源码仓库。
7.在集成计算机上并基于主线的代码再做一次构建。只有这次构建成功了，才说明改动被成功的集成了。

• (4.持续集成增加写代码的乐趣
  比如 CI 灯，声音，导弹等。 集成成功就播放欢乐的声音，集成失败就播放刺耳的声音。 网上有持续集成导弹，先调整好每个人的角度，一旦谁把构建弄失败了，就朝他发射导弹。



h.Matephor

隐喻
设计模式：工程模式，策略模式，
百词斩：比喻自己是一个医生，治疗不会学习英语的病，本质是一种信息的传递，而需要做的就优化信道，使接收端收到更优质不是真的信息

h.Sustainable Pace

可持续的速率
每天工作 8 小时，每周工作 5 天。
做计划时不应该算上额外的时间。
结对编程会更消耗精力，结对一天就很累了。
业余还要花时间去学习，保持技术先进。



i.TDD

TDD
跳过，有专门的一课。






FIRST Principle
- 1.Fast: run (subset of) tests quickly (since you'll be running them all the time)
- 2.Independent: no tests depend on others, so can run any subset in any order
- 3.Repeatable: run N times, get same result (to help isolate bugs and enable automation)
- 4.Self-checking: test can automatically detect if passed (no human checking of output)
- 5.Timely: written about the same time as code under test (with TDD, written first!)

j.Refactoring

重构，结对编程

旧的不变，新的创建，一步切换，旧的再见

k.Simple Design

简单设计

很多人对于简单设计和过度设计是有争议的，过度设计没有明确的定义，但其实简单设计是有明确的定义的，它有四条规则：

1. 通过测试 - 保证需求要满足
2. 表达意图 - 该有的概念要在代码中体现
3. 消除重复 - 尽量消除重复代码
4. 最少程序元素 - 减少类、接口、属性、方法、参数、变量等程序元素

这四条规则从上到下优先级递减，但是社区里对第二条和第三条的优先级有争议。
Martin Fowler 认为第二条和第三条同等重要。

5. 实例化需求

实例化需求的方式既能清晰地表述需求，消除客户、需求分析师、开发人员与测试人员在沟通中可能产生的理解分歧；又极为融洽地支持开发人员进行有效地测试驱动，帮助测试人员条理清晰地完成对需求功能的验收和测试。

a.定义

一段很好的需求说明，加上实例（场景+数据），实际上就是她所描述的功能的验收测试
满足：

a.精确、可测
b.是真正的需求说明，而不是脚本
c.是关于业务功能的，而不是关于软件设计的

b.实例化

GIVEN从句描述的是场景的前提条件、初始状态，通常是一种现在完成时态；
WHEN从句是采取某个动作或者是发生某个事件，一定是动词，通常是一般现在时；
THEN从句用“应该…(should be…)”来描述一种期望的结果，而不用断言（assert），后者与测试关联更紧密。

c.BDD

• 1. 关注的是业务领域，而不是技术：BDD强调用领域特定语言（DSL, domain specific language）描述用户行为，定义业务需求，而不会关心系统的技术实现。
• 2.不是工具，强调的是一种协作方式：BDD要求各个角色共同参与系统行为的挖掘和定义，以实现对业务价值的一致理解。
• 3.不是关于测试的：BDD源自TDD,但重点不是关于测试，所强调的沟通与协作可以指导更好的做自动化测试。
• 4.全栈敏捷方法：BDD促使团队所有角色从需求到最后的测试验证，进行高度的协作和沟通，以交付最有价值的功能。

d.BDD怎么做？

用例场景的描述格式“GIVEN… WHEN… THEN… ”对大家都不陌生，但用这个格式写出好的用例却是非常的难，尤其是新手。这里总结几点供大家参考：

• 1.业务层抽取，业务语言描述
• 2.技术人员可懂，自动化友好
• 3.数据驱动，需求实例化

e.Example:

场景一：检查收件箱，可以看出第三个清晰明了且能体现业务价值，比较符合上面的要求。

Scenario: Check Inbox
  Given a user "Tom" with password "123"
  And a user "Jerry" with password "abc"
  And an email to "Tom" from "Jerry"
  When I sign in as "Tom" with password "123"
  Then I should see one email from "Jerry" in my inbox

Scenario: Check Inbox
  Given a user "Tom"
  And a user "Jerry"
  And an email to "Tom" from "Jerry"
  When I sign in as "Tom"
  Then I should see one email from "Jerry" in my inbox

Scenario: Check Inbox
  Given I have received an email from "Jerry"
  When I sign in
  Then I should see one email from "Jerry" in my inbox

6. 测试金字塔





7. 测试景深(Included in TDD)