一个团队是否有战斗力，{dy}看领导的魅力，第二看队员的水平，第三看价值观。
敏捷软件开发是一套价值观与方法论，它重视实效，反对形式化，它重视变化，胜过遵循计划。
我总结的开发准则：
1. 客户也是团队成员
客户的定义是评价我们软件好坏的人。开发人员要和客户在同一个大房间里工作，这样才能采用面对面这种效率{zg}，成本{zd1}的沟通方式，才能持续深化需求理 解。
2. 需求卡片
需求要用场景描述的形式，每张纸上一个场景，并标有表示工作量的点数。需求由用户提出，工作量点数由开发人员确定。需求描述必须能被客户、开发人员、测试 人员都看得懂，没有二义性。
3. 2周为一迭代周期
迭代之前，由客户挑选优先级{zg}的需求，列入迭代计划中。迭xx始之后，不允许客户再变更本次迭代的需求，这是要保证需求的稳定性，并迫使客户谨慎挑选。 在迭代过程中，要频繁的做模块集成，使软件随时可用，客户可随时看到可运行的软件，随时了解进度，并及时纠正其他人对需求理解的偏差。
4. 迭代完成之后，向客户演示，获得反馈
有修改的任务，则放入下一迭代计划
5. 发布周期为3个月
期间客户可随时修改需求。在执行到一半的时候，开发人员如果感觉到某些功能在发布之前做不完，就及时与客户协商，砍掉一些功能，确保发布计划的顺利执行。
7. 测试驱动开发
为保证系统的健壮性，必须采用测试驱动的开发。先写单元测试，再写功能代码。在实现需求之前或同时，编写验收测试脚本。验收测试是能够自动重复运行的脚 本，一旦测试成功，以后就绝不允许它再失败。写的所有的功能代码，都是为了能使测试通过。
8. 结对编程，频繁互换角色，频繁改变结对关系，传播知识
结对编程刚开始的时候需要磨合，效率低，但之后效率会很高，因为出错率降低了，也不容易疲劳了。但结对编程不适合难度高的需要深入思考的任务。
9. 任何人都可修改任何代码，并经常集成，经常签入，经常重构
每个人都有修改Bug和优化的责任，都要对整个项目有整体而深刻的认识。每个人每时每刻都要准备重构，时刻保持代码的{zy}化。这种情况下的重构都很小，持 续不断的小的重构才能产生优质代码。不允许出现重复代码，重复代码是维护的大敌，也是产生错误的诱因之一。
10. 不加班，保持稳定的速度
加班带来的疲劳会造成恶性循环。如果出现加班，很可能是因为任务安排不当。团队不应追求过快的开发速度，而应设法保持可持续的稳定的开发速度。
11. 努力钻研技术，定期反省
技术是降低成本的有力武器，一定要勤奋学习，定期总结和反省，才能不断进步。