过程和方法对于结果只有次要影响,首要的影响是人。
人不是插入即兼容的编程装置,如果想要项目取得成功,就必须构建起具有合作精神的自组织的团队。
合作、沟通以及交互能力要比单纯的编程能力更为重要。
过多的文档比过少的文档更糟,编写以及代码的同步会花费更多的时间。直到迫切需要并且意义重大时,才来编写文档。
成功的项目需要频繁、有序的客户反馈。成功的关键在于和客户之间真诚的合作。
在“充满激烈讨论的屋子”里工作,生产率非但不会降低,反而会成倍的提高。
软件项目不是全速的短跑,而是马拉松长跑。团队必须有意识的保持稳定、适中的速度。Xp的规则不允许团队加班工作,在版本发布前一周是唯一的例外。
编写单元测试是一种验证行为,更是一种设计行为。同样,它更是一种编写文档的行为。
饭是要吃的,忽略掉清洁工作并不能真正加快用餐速度。(重构)
敏捷设计是一个过程,不是一个事件,它是一个持续的应用原则、模式以及实践来改进软件的结构和可读性的一个过程。它致力于保持系统设计在任何时间都尽可能简单、干净、富有表现力。
变化的轴线仅当变化实际发生时才具有真正的意义,如果没有任何征兆,那么去应用SRP或者任何其他的原则是不明智的。
抽象类和它们的客户的关系要比和实现它们的类的关系更密切。
开发人员应该仅对程序中呈现出频繁变化的那部分做出抽象,拒绝不成熟的抽象和抽象本身一样重要。
转载于:https://www.cnblogs.com/QuitGame/archive/2006/02/08/327299.html