敏捷宣言 – 个体和交互
•个体和交互
1.每个团队成员。(这是必需的，每一个项目组成员都要和别人沟通、互动，除非这个项目就他一个人)
2.发挥每个成员的特点和长处。 为个体塑造弹性的发挥空间。(刚毕业的人做PD、编程序、做测试哪来什么特点和长处，学习都来不及，所以敏捷开发是很有经验的一棒子人去做一个项目，这样各自可以发挥得淋漓至境；话句话说，不是敏捷开发也要强调发挥个人长处，例如让一个长期做功能测试的人去做编程，让DBA去做功能测试，这明显是错误的嘛)
3.合作、沟通比单纯的写程序更重要。（合作、沟通，这个任何时候、任何地方、任何项目都是必需的，沟通的目的是确认接下来所做的事情是正确的，或者程序员之间交流经验、讨论技术难点）
4.团队的意义所在 – 你不是一个人在战斗！（现在软件企业，哪个不在强调团队合作）
•过程和工具
1.过程追求标准化，限制了个体的发挥。（对于小项目可以这样做，但是，如果做产品没有标准化，产品的生命力在哪里？为了程序员个人的能力发挥，难道限制产品的扩展性、易用性，代码可以可以不用写注释了吗）
2.工具-越强大的工具学习成本越高。目标是软件开发，不是学习工具。（谬论，工具是用来提高效率的，怎么会变成拖后腿的东西呢；强大的工具一旦学成，以后可以坐享其好处，人，不能这么短视，项目，也不能这么短视）
3.选择合适的工具。（合适不合适，各有己见）
敏捷宣言 – 可以工作的软件
•可以工作的软件
1.开发的目的是交付可以工作的软件 （所以敏捷只能再小项目和业务简单的项目中运用）
2.对用户来说文档还存在一定的想像空间，会造成沟通障碍。（文档又不是一板子钉死的，用户不理解就要解释给用户听，但你总不能只带着一张嘴去跟用户说吧；或者拿着只实现了1/10功能的可交付软件去给用户看？）
3.最好的文档是代码和团队。（代码是最好的文档？但是别人也要读得懂啊，客户能读得懂吗，难道给客户培训一年再让他们去理解代码？我们程序员居然有人拿这个当理由不写文档，你说我一个测试人员有空去你们的代码吗）
•面面俱到的文档
1.没有文档的项目是个灾难（看多大的项目了，小项目没文档照样好好的）
2.文档的目的是沟通和总结，让大家明白要做什么、怎么做（这个没错）
3.提倡的文档方式-看图说话（对项目成员要求比较高；图的类型要明确下，别只画个UI,就算图了，还有流程图、用例图等等）
4.必要的时候也是需要完善文档的（啥时候？）
（是本书都会教上面这些）
敏捷宣言 – 客户合作
•客户合作
1.绝大多数软件系统是不能直接带来效益的（哪来的结论？论据呢）
2.客户对自己的需求也不是很明确的，我们需要充当顾问（有的客户确实是这样）
3.跟客户是一起来完成一件事情的，需要客户的不断反馈（什么叫以客户为中心，这就是）
•合同谈判
1.软件公司是指着合同来生存的（在鄙人看来，敏捷适合企业级的ERP\MIS,或者政府级的OA自动化项目，对电子商务类基本不适合）
2.谈判只能暂缓变化，不能阻止变化（变化是必然的）
3.合同和谈判是必须的，客户合作是企业长期发展的选择（废话）
敏捷宣言 – 响应变化
•响应变化和遵循计划
1.计划赶不上变化（根本就没有想到后面怎么做，哪来变化，本来就是很多不确定，走到哪算哪）
2.需求在变化、开发人员对业务的认识在变化、技术点在变化（废话）
3.长期计划稳定，短期迭代。2周到详细计划、一个月的粗计划、三个月的目标计划。（跟螺瀑布式迭代开发有何区别）
4.当变化没发生的时候不要猜测变化（废话，能算出会有什么变化，那是神啊）
5.着力完成本计划内的工作任务，不需要为后期工作预留过多的接口和功能冗余（这难道不是短视么？以前强调的扩展性为什么不要？如果现在不考虑，现在很爽，以后就会很痛苦，会付出几倍的汗水去实现）
6.力求设计简单清晰、降低耦合、模块可以自说明、大胆重构（降低耦合，说的轻松，没有一定的功力和时间，快速响应能做的出来吗？又要快速出可用的软件，又要低耦合，想得美）
总结
•目标是完成可以工作的软件（哪个项目不是呢）
•文档是用来沟通的中间产物（有些是，有些不是，例如帮助文档是要交付给客户的，甚至需求、设计文档和代码都是，所有权归客户所有）
•团队合作和内部沟通是很重要的，每个人都要为团队负责同时团队也要为每个人负责。（任何开发模式都要求团队合作，除非项目里只有一人）
•沟通需要争吵，不是一定要和谐。个体要极力为自己观点补充细节，更要聆听不同意见。但最终要统一意见。（误导别人，团队当然要和谐，但是要敢于发表自己的意见、敢于接受别人的批评）
•工作是需要方法的，同样沟通也是（题目太大了，说了等于没说，具体是啥方法呢）
•工作氛围是可以相互影响的，不需要太安静（和感冒一样，这主要取决于团队的领袖）
•积极面对变化（必需的）
•工作要：快乐、积极、学习、合作 （不是一个项目能做到的，跟公司的企业文化和激励制度有关）
敏捷宣言的原则
•我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意（有没有价值得客户说了算，要是一个软件烦他N次，敏捷也就OVER了）
•即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。（给客户带来好处，但是给软件开发带来麻烦，老板愿意吗）
•经常性地交付可以工作的软件，交付间隔可以从几周到几个月，交付时间间隔越短越好。
•在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。（为什么需要天天？业务是保姆啊，如果业务人员天天和开发人员在一起，那谁和客户天天在一起？）
•围绕被激励起来的个人来构建项目。给大家提供所需的环境和支持，并且信任大家能够完成工作（....）
•在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。（是的，但是不要没思考就和别人谈）
•衡量进展的重要尺度是可运行的软件。（还是适合小软件）
•敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期、稳定的开发速度（要响应经常性的需求变化，怎么保证稳定的开发速度？）
•不断地关注优秀的技能和好的设计会增强敏捷能力。（所以还是需要学习强大的工具）
•高质量完成本次迭代中最简单的工作是根本。（如何高质量？不是只要软件能运行就可以了吗，每个小任务要又快又高质量完成，怎么可能呢）
•最好的构架、需求和设计出自于自组织的团队。（废话，如果来自其它团队，沟通不是很麻烦吗）
•每隔一定时间，团队会在如何才能更有效的工作方面进行反省，然后相应地对自己的行为进行调整。（这个要看团队的领导者如何去主导这个事情，也算是团队的一个文化）
敏捷开发实践 - 团队组成
成员分类：
•团队长
•业务及需求代表
•开发人员
敏捷开发实践 – 结对编程（结对编程就是乌托邦啊）
•两个人在一台机器前共同开发一个功能模块（乌托邦）
•随时沟通、讨论、画图，随时争抢键盘编码（乌托邦）
•共同对本模块负责（乌托邦）
•每天有3-4个小时结对编程就够了，其余时间对系统和技术点研究、测试（以前没有积累吗，什么都要现学现用么，那样质量会高吗）
•结对编程的个体要经常变换，以便相互学习（说来容易，对方哪有那么容易接手的？两个人能力差不多还行，如果差别较大，那谁跟谁学啊）
敏捷开发实践 – 任务分解
•每周项目组长把任务分解成功能点，由队员来结对选择。每个功能点由两个人共同负责，一个人主负责。
•选择的任务必须按时完成。
•指定时间对任务的收回以可工作的软件为最高依据。（不用管质量和部署的复杂度吗？）
•任务尽可能短小，到Function级别（一个任务到底是功能点还是function？就算是function，是哪一层的）
•任务要分优先级别（必需的）
•鼓励队员选择非专长功能点，要有相对专长的人配合（不懂啊，为啥这样，提高团队的技能吗，但是这样能保证按时交出可工作的软件吗）
敏捷开发实践 – 重构
•单一职责原则
就一个类而言，应该仅有一个可以引起它变化的原因
•开放封闭原则
软件实体（类、模块、函数）应该是可以扩展但不可修改的
•替换原则
子类必须能够替换基类
•依赖倒置原则
细节依赖于抽象。细节是外层，抽象是内层。
•接口隔离原则
不强迫客户依赖他们不使用的方法。接口属于客户，不属于所在类的层次结构。
总结
开发项目首要的是解决项目成员之间的合作与分工，解决这个问题之后再选用一个适合团队项目开发和分工的框架引用其中的部分做指导。
开发还是要尽可能的考虑到位，拿过来就干，每个人依赖沟通，可以培训一下，分析规划和设计是有必要的，总结经验很重要，套路是可变的。
