这个网站里涉及的主要是方法论上的层次，俯瞰着大地上的开发组织和人员。看到的问题和解决方案往往是直指本质的。 这里摘几条印象深刻的见解和需要识记的名词。 学习新知识最快的途径是将新知识纳入自己所理解的一套知识体系。所以，如何在学习的同时建立起各个技术的联系和区别是很重要的，有利于建立自己的体系。修炼好内功，在接触新知识的时候，才能很快上手并理解其本质。
软件的本质是2进制和与非逻辑。软件开发的本质是人的创造，而创造的根源在与想象，这又引出了“隐喻”和“故事”。隐喻是指从生活阅历中抽象出与所要开发的软件的运行流程相像的事件与关系。故事，则是讲述故事的方式想象软件运行的流程。
敏捷软件开发宣言：
个体和交互 胜过 过程和工具
可以工作的软件 胜过 面面俱到的文档
客户合作 胜过 合同谈判
响应变化 胜过 遵循计划
虽然右项也有价值，但是我们认为左项具有更大的价值。
敏捷开发最注重的是人，或者说个体。目标是提高个体的主动性，提高产出效率。敏捷开发要求团队一起工作，甚至还有客户。结对编程。迭代交付，三周为一个周期，每个周期都发布可用地、经过测试的代码。2到5个周期后进行一次发布。敏捷开发积极拥抱变化，主要依靠代码重构来配合变化。
敏捷开发的优点在于发布时间短和响应需求变化， 敏捷开发的缺点是可操作性差。实践者们常常走入各种各样的误区。根本原因还是人，人的主动性还有在软件开发中的行为受各种各样因素的影响。 在需求分析阶段准备两份文档。一份使用客户的术语表达客户的故事，另一份是使用软件术语表达软件实现的故事。需求分析人员是客户和项目组之间的桥梁，是客户和软件开发人员之间的桥梁， 十分类似于科手术过程，软件开发团队需要一个主刀医师，即软件架构师。软件架构师保证了整个软件的思想和架构是一个主体。而不是零散的，拼凑的。这有利于开发和维护。软件架构师在一个团队里一般只有一个，或者一个架构师团队由其中一个人作为领导。这样保证了整个软件系统的一致性。软件架构师工作的主要依据是经验。 在软件开发过程中，人是最重要的因素，而责任、权利和利益是保证这个因素发挥作用的关键。负责文化是人类社会活动中必须具备的一种文化。团队往往成为不负责任的推辞。建立负责制度的目的不是为了惩罚，而是通过利益损失的形式，表明一个事实：没有金刚钻，别揽瓷器活。也是质量保证的一个重要推动力。
敏捷建模者的个性
软件的开发是一个团队集体合作的项目，需要各个队员做出贡献，因此每个人更应该注意自己进行敏捷开发时所需要具备的素质。
很多的方法学都定义了软件开发项目中开发人员所担任的角色，同时还定义个各个角色执行的任务，尽管入席，这些方法并没有定义这些角色最适合的人选。一个人要想成功的担任某个角色，他应当很好的适应它－－虽然这并不需要人们掌握所有的技能，但人们必须要慢慢的熟悉这些技术。我的经验告诉我，要成为一个成功的敏捷建模者，下面的列出的个性是必要的：
团队竞赛
第一点，也是最重要的一点，敏捷建模者总是积极的寻求协作，因为他们意识到他们不是万事通，他们需要不同的观点，这样才能做到最好。软件开发可不是游泳，单干是非常危险的。在敏捷的字典中没有“我”这个词。
畅所欲言
敏捷建模者都有良好的沟通技巧－－他们能够表达出他们想法，能够倾听，能够主动获取反馈，并且能够把需要的写出来。
脚踏实地
敏捷建模者应当脚踏实地 他们的精力都集中在满足用户的需求上，他们不会在模型上画蛇添足，即便那双足是多么的好看。他们满足于提供可能的方案中最简单的一种，当然，前提是要能够完成工作。
好奇
敏捷建模者乐衷于研究问题，解决问题。
凡是都问个为什么
敏捷建模者看问题从不会至于表面，而是会打破沙锅问到底。他们从不会就想当然的认为一个产品或一项技术和它们的广告上说的那样，他们会自己试一试。
实事求是
敏捷建模者都非常的谦逊，他们从不认为自己是个万事通，所以他们会在建立好模型之后，用代码来小心的证明模型的正确。
根据实验
敏捷建模者应当愿意尝试新的方法，例如一项新的（或是已有的）建模技术。一般而言，他们也会接受敏捷建模开发技术，必要时，为了验证想法，他们愿意同传统的思想做斗争，例如在一个项目中减少文档数量。
有纪律
要坚持不懈的遵循敏捷建模的实践。对你来说，你可能会在不经意间说，“加上这个功能吧！无伤大雅。”或是，“我比project stakeholder更了解。”在AM的道路上要想不偏离方向，是需要一定的纪律性的。
建模误区
误区一
建模就等于是写文档
误区二
从开始阶段你可以考虑到所有的一切
误区三
建模意味着需要一个重量级的软件开发过程
误区四
必须“冻结”需求
误区五
设计是不可更改的
误区六
必须使用CASE工具
误区七
建模是在浪费时间
误区八
数据模型（Data Model）就是一切
误区九
所有的开发人员都知道如何建模
对于软件来说，最大的软肋在于逻辑思维的不可遍历性。这是测试工作存在的一个原因。 实际的软件工程师实践证明，让对软件思想有深刻理解的软件工程师进行测试，可以大幅度提高软件质量。所以，测试工作并不比软件开发轻松，让软件开发菜鸟来进行测试是不负责任的。 测试人员并不是软件开发人员的对立者。他在找出bug的同时，也要尽可能的帮助编程人员指出这种bug存在的原因以及地点。 所有论点都存在一定的上下文之中。所以学习别人的论点只是理会这个论点的思路，而不要到处生搬硬套。
需要怀疑一切。 项目管理工作的基本思路不是控制，而是创造有利的环境和顺势引导，扫清软件开发中的各种障碍。项目管理工作要与软件开发工作隔离开来。 对于软件开发者而言，你需要考虑的是风险服务，即风险响应。而不要把主要精力放在风险预防和控制上。 软件维护要在项目开始或者设计时就要予以考虑。