我们到底在干什么

==============

编写代码, 让机器替人们完成某些**工作**!!! 如果不能很好地完成**工作**,再炫酷的代码,都毫无价值.
我们要做的,就是这件事,并且让它简单. 为了达到这个目的,你会见到各种技巧: 随处可见的复用思想, 单一职责等…

性格

==============

***沟通***

- “不要浪费别人的时间”:尽可能简短的话描述出问题及观点;

- “想法”:我们喜欢听到不一般的想法,见解;

- “就事论事”:不要将情绪带入讨论,尊重他人的想法,即使你觉得很可笑,但也有可能是你错了.

***简单***

KEEP IT SIMPLE & STUPID

***反馈***

“过度自信是编程的职业病，反馈则是其处方。” －－ Kent Beck通过图表来交流你的想法，你可以快速获得反馈，并能够按照建议行事

***谦逊***

最优秀的开发人员都拥有谦逊的美德,他们总能认识到自己并不是无所不知的。事实自己的专业领域,都能够为项目做出贡献。一个有效的做法是假设参与项目的每一个人都有相同的价值，都应该被尊重.

主张

================

***主张简单***

如果你现在不需要这样的功能, 那么现在就不必实现它. (注意:是现在,实现;并不意味着永远)

***拥抱变化***

因为变化所以美丽。你会面对很多变化,要学会从心里喜欢上它. 这样会让你每天都会期待明天的到来。但是如果你没有对应变化的能力,它会让你讨厌.

***可持续性***

软件和自然界很多动植物一样,都是在不断的”进化”; 当你在写当前版本的代码时,时不时地想一想:”这个以后可能会变化么?,会怎么变呢”.

***递增变化***

你不用在一开始就准备好一切。实际上,你就算想这么做也不太可能。而且,你不用在模型中包容所有的细节,你只要足够的细节就够了.

***记住目的***

为了展现你高超的技艺, 再去写一遍代码是错误的. 回头看再看一眼我们的目的就知道了. 时刻盯准目标,去让它 work.

***高质量的工作***

没有人喜欢烂糟糟的工作。做这项工作的人不喜欢，是因为没有成就感；日后负责重构这项工作（因为某原因）的人不喜欢，是因为它难以理解，难以更新；最终用户不喜欢，是因为它太脆弱，容易出错，也不符合他们的期望.

***快速反馈***

从开始采取行动，到获得行动的反馈，二者之间的时间至关紧要。和其他人一共开发模型，你的想法可以模技术的时候，例如白板、CRC卡片或即时贴之类的基本建模材料。和你的客户紧密工作，去了解他们的的需求，去分析这些需求，或是去开发满足他们需求的用户界面，这样，你就提供了快速反馈的机会。

***团队协作***

当你在用别人的一个API时,口中不断的:”fuck,为了调用它的接口,老子要多些20行臃肿的代码,你换种方式不就完了嘛”。 换位思考,当你在为别人编写API时, 换过来, “如果别人给我提供这样的接口参数时,我用起来爽么?”

EP 价值观

===========

时刻记住,只有你的代码被用户运行起来的时候,才体现出了它们的价值:

- 最重要的是通过尽早和不断交付有价值的软件满足客户需要;

- 我们欢迎需求的变化，即使在开发后期。敏捷过程能够驾驭变化，保持竞争优势;

- 经常交付可以工作的软件，从几星期到几个月，时间尺度越短越好;

- 开发者应该在整个项目过程中始终朝夕在一起工作;

- 围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，满足他们的需要;

- 在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈;

- 可以工作的软件是进度的主要度量标准;

- 对卓越技术与良好设计的不断追求将有助于提高敏捷性;

- 简单——尽可能减少工作量的艺术至关重要;

- 最好的架构、需求和设计都源自自我组织的团队;

- 每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为;