Simple
简单够用，这个是最为难掌握的，说的直白点就是先采用能够想到的一个最简单的设计去实现功能，至于这个设计是不是那么的合理先不要太多的去理会，在完成了功能后可以不断的对其进行重构，其实其原理就是”一步一个台阶，直至云霄，而不是一步登天”，每个团队的不同仅在于这一个台阶能迈多高而已。
集体参与
迭代过程的设计由项目组共同参与，项目组成员可随意的发表各自对于系统实现的设计的想法。
2.3.3. 开发
开发过程中涉及的有：
编码规范
编码规范需在项目开始时即制定，这个需要根据每个公司以及团队的情况来决定，在Java编码规范中通常要涉及的有类文件规范(主要是文件的版权、文件格式等)、命名规范(包名、类名、方法名、变量名等)、注释规范。
TDD
按照先编写单元测试后进行代码编写的原则，在单元测试中主要需要对代码的逻辑、性能以及边缘进行测试。
PP
双人编程，在进行代码编写时必须两人一起进行，一人操作键盘，一人旁边观看，同时进行思考。
Code Review规范
代码复查规范需要按照各个公司以及代码规范来进行制定。
2.3.4. 重构
在开发结束后需要考虑代码的重构，主要从OO的各原则以及设计原则来进行提升，复用性、性能等都是考虑的因素。
重构时可采用IDE提供的重构支持来快速完成，对于设计的重构可以通过设计会议来共同讨论，在重构时甚至可考虑推翻原有所有的设计而进行。
2.3.5. 持续集成
持续集成采用感应版本控制工具变化而进行的原则，即有变化提交至版本控制工具时即进行持续集成，在持续集成失败或成功的情况下均发送邮件通知相关人员，项目组所有人员均可通过网站查看持续集成的情况。
持续集成中主要需要进行的工作是编译所有源码、运行单元测试、按照系统手动部署方式自动完成部署工作、运行功能测试、发布测试报告并通知相关人等。
持续集成的原则为谁造成失败谁负责。
三. 任务规范
3.1. 任务分配
在对用户故事完成设计时即可进行任务的分配，每个任务拆分到1—2天的范围内，对于难以估计的任务先进行spike之后再行分配，spike的时间限制在1周以内。
由项目组成员自行挑选任务。
3.2. 任务完成
在完成任务的过程中成员需进行任务完成时间的跟踪，原则为在开始任务时填写任务开始时间，在停止编写任务的时候填写时间点，在任务完成时勾选完成任务。
此时间也将作为将来分配任务时时间的估计，以使得对于任务的完成时间的估计能够越来越精确。
3.3. 任务跟踪
任务跟踪通过任务跟踪工具来完成，主要是任务完成的时间、任务统计等。
四. 工具
涉及的工具主要有：
任务跟踪工具
版本控制工具
持续集成工具
Bug跟踪工具
开发工具
五. 制度
5.1. 早会
早会时间大概在10---15分钟，主要是对昨日任务的回顾、难点的提出、今日的计划以及partner的挑选。
5.2. 发布会议
发布会议为里程碑计划的宣布，以使项目组成员能够明确里程碑的目标以及时间点，同时也听取项目组成员的意见。
5.3. 迭代会议
迭代会议为每个迭代周期前进行召开，以使项目组成员明白迭代目标以及时间点，同时听取项目组成员的意见。
5.4. 设计会议
设计会议在每个迭代周期开始的时候进行召开，以确认迭代中需求的设计实现、任务分配等。
5.5. 项目周报
项目于每周五下班时提交项目周报，主要是向客户、公司相关人员、项目组通报项目的进展情况、下一步工作计划。
5.6. 项目成员积分制度
项目成员积分作为对项目组成员的考核以及奖金分配的依据。
项目成员积分主要从任务的完成时间、质量、任务过程中表现出的团队合作、责任心、态度等进行评价，对表现特别出色或不合人意的进行适当的奖惩。
