个体和交互胜过过程与工具人是软件开发中最重要的因素，开发团队要能做到团结协作，人与人面对面的交流、沟通，是最高效的途径。可以工作的软件胜过面面俱到的文档比起在客户会议上只是向客户展示文档，时刻可以运行和提交的软件，更有价值、更受欢迎。客户协作胜过合同与谈判承认需求是无法在软件开发周期的早期阶段完全收集清楚的，所以持续的客户参与和沟通非常重要。响应变化胜过遵循计划敏捷开发注重快速响应变化，以及持续交付价值。敏捷是一种价值观，“胜过”不是好的意思，是价值观取向的体现。敏捷认为右边的各项有其价值，但敏捷更重视左边各项的价值。在代表敏捷联盟介绍宣言的时候，Jim Highsmith解释敏捷运动并不是反对方法论：敏捷运动并不是反方法论的，实际上，我们许多人希望能重新建立方法论这个词的公信力。我们想恢复一种平衡。我们拥抱建模，但不是只为了画些图纸填满落满灰尘的公司仓库。我们拥抱文档，但并不是编写动辄上百页的文档但从不维护。我们做计划，但我们意识到在混乱的环境中做计划的限制。那些把XP、Scrum或者其他敏捷方法论的提倡者认做是黑客的人，是出于对方法论和黑客这个词最初定义的无知。
12条原则
- 通过快速交付有用的软件让客户满意
- 欢迎变化的需求，即使变化发生在开发阶段这么晚
- 频繁交付可以工作的软件（几周而不是几个月）
- 在业务人员和开发者之间存在每日紧密的沟通
- 项目由自我驱动的个人共同参与，他们应该得到信任
- 面对面的对话是沟通的最好形式
- 可以工作的软件是进度的主要衡量标准
- 可持续的开发节奏，能够维持不变的步调
- 对技术卓越和良好设计的持续关注
- 简单性是本质——最大化未完成工作数量的艺术
- 自组织团队
- 对变化的环境有规律的适应
写在后面：敏捷开发方法的核心思想概括起来，是“以人为本”和“响应变化”。以人为本敏捷方法认为，人是软件开发中最重要的因素。敏捷开发的理念是充分的信任团队能够很好的完成任务，它们注重调动团队的能动性，以积极、愉悦、乐观的心态完成软件开发，并致力于提升团队的能力。响应变化传统的软件开发强调的是足够清晰的需求，并制定详细的文档，按照预定的计划逐一进行开发、测试。这样的方式在制定好计划之后拒绝变化，无法应对市场的变化和客户对需求的实时更改，后续的维护必将会付出巨大的代价。而敏捷方法则是以最简的方式来迎接变化，客户在整个开发过程中都是参与者，开发团队能够在最短的时间内得到市场的反馈，不断响应需求的变更，从而使得最终的产品能够充分的符合用户的要求，并持续交付有价值的软件。
第一条，快速交付有用的软件，完全不具备，开发完成，并不部署，希望能看到真实数据，在不能看到真实数据，不能做到更好的时候，仍旧坚持要数据，导致后面乱的一团糟，也并不总结经验。
第二条，并不欢迎变化，当然，这所有团队成员都不会欢迎，在快速交付的基础上，迭代开发，如果未完成开发最好，完成了开发应该快速迭代。
第三条，完全不具备
第四条，具备
第五条，部分具备，对人员要求比较高
第六条，具备（没有问题管理系统，沟通极度困难）
第七条，这个基本上是我这边保证的，包括自动化部署系统
第八条，基本不具备，经常会中断，转去进行做部署运维等操作
第九条，这个组内并不支持，个人依旧在坚持
第十条，组内未形成该氛围，也未见到项目的一个总体规划及对项目的拆分
第十一条，自组织导致团队人员经常丢失，未达到复用的目的，也涉及到利益分配上的问题，未形成一个良好的氛围，干多干少都差不多
第十二条，个人还做不到，组内其他人都无所谓，适应性应该比我好
干活效率我应该是很高的，但是感觉干着没意思，也学不到什么东西，都是些皮毛……干活时，代码写到一半就时不时会中断，敏捷变成日常加塞任务。个人觉得敏捷很重要的一点就是拆分任务，发挥大家的积极性，让大家主动认领。还有个挺无语的问题，原型交给开发和测试画，画画救火可以，但是意思是作为常态，开发和测试在开发的时候，需求发生变更，本就要付出更多心力维护代码，此时任务重叠，经常导致原型物理模型等文档不再维护，成为废弃在仓库的废纸，压力全部后置，项目经理没有产品经理沟通需求，不画界面原型，口头沟通，客户不能快速看到效果，并不符合敏捷的快速迭代。
自动化程度极低，测试环境和开发环境不能分离，敏捷开发居然不使用git……
项目来了，有些是必须做的，项目经理也没有列出，组内员工并没有积极主动改进的意愿，这和敏捷存在巨大冲突。在此做个记录，项目管理并不容易，需要不断地改进，在这里做个记录。
制度不完善，活不好干。写着写着就突然要部署，还不清楚现场环境，要申请哪些资源，架构图也没画……开发和运维重叠，开发和设计重叠……说起来都是人，活不好干……
