呦吼5957297
敏捷软件开发的软件四条原则
递增，而不是连续的：如果开发实践是真正的敏捷精神，那么交付的工作软件是一小部分一部分递增的。
不必等到一个阶段完全完成后才开始另一个，工作也不是向大的发布日期而努力。
完成的工作，但并不是业务最终期限，驱动着敏捷交付。
但敏捷精神也承认业务操纵着最后截止日期。
避免不必要的开销：如果实践仍然是真正的敏捷精神，那么团队就致力于尽可能多地减的项目计划和文档。
与其讨论要做什么，然后再写下来，不如赶紧动手云做。
否则，就是在浪费时间在工作的工作上。
在工作对工作中，敏捷精神有利于于实际的工——作交付工作软件。
而且它也值面对面的交流通过邮件和其他书面文件。
协作：根据需求，团队成员一直与其它人进行交互，以及一些外部利益相关者。
在敏捷教练世界中，整个团队的负责人Lisa Crispin能够解决所有问题，在问题出现之前 。
真正的敏捷精神团队是自助的。
他们分配需要做的工作。
虽然每个成员承担的任务都在他们的专业技能范围内，他们还是需要与团队协作的。
没有人的工作孤立的，也没有团队本身是独立工作的。
没有业务利益相关者，以及诸如用户体验方面的外部专家的重大投入，团队就不可能使项目向前发展， 说真话：为是保证真正的敏捷，团队探讨的与项目相关的一切都要是真实的。
在一些至关重要的专业领域，如冲刺测试的编码技能，他们承认存在差距。
关于实际生产力，他们的要讲事实；这也就是说，在y时间内，团队是否有能力做x。
他们承认错误。
说真话是一项挑战，因为我们害怕承认缺点会让我们显得很弱。
但敏捷精神知道说出事实需要勇气。
承认问题需要信心，然后快速地去解决问题。
敏捷开发的遵循原则
我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
即使到了开发的后期，也欢迎改变需求。
敏捷过程利用变化来为客户创造竞争优势。
经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
围绕被激励起来的个体来构建项目。
给他们提供所需的环境和支持，并且信任他们能够完成工作。
在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈。
工作的软件是首要的进度度量标准。
敏捷过程提倡可持续的开发速度。
责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
n 不断地关注优秀的技能和好的设计会增强敏捷能力。
简单是最根本的。
n 最好的构架、需求和设计出自己组织的团队。
n 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
当软件开发随需求的变化而变化时，软件设计会出现坏味道，当软件中出现下面任何一种气味时，表明软件正在腐化。
n 僵化性：很难对系统进行改动，因为每个改动都会迫使许多对系统其他部分的其它改动。
n 脆弱性：对系统的改动会导致系统中和改动的地方在概念上无关的许多地方出现问题。
n 牢固性：很难解开系统的纠结，使之成为一些可在其他系统中重用的组件。
n 粘滞性：做正确的事情比做错误的事情要困难。
不必要的复杂性：设计中包含有不具任何直接好处的基础结构。
n 不必要的重复性：设计中包含有重复的结构，而该重复的结构本可以使用单一的抽象进行统一。
晦涩性：很难阅读、理解。
没有很好地表现出意图。
敏捷团队依靠变化来获取活力。
团队几乎不进行预先设计，因此，不需要一个成熟的初始设计。
他们更愿意保持设计尽可能的干净、简单，并使用许多单元测试和验收测试作为支援。
这保持了设计的灵活性、易于理解性。
团队利用这种灵活性，持续地改进设计，以便于每次迭代结束生成的系统都具有最适合于那次迭代中需求的设计。
为了改变上面软件设计中的腐化味，敏捷开发采取了以下面向对象的设计原则来加以避免，这些原则如下：单一职责原则（SRP）就一个类而言，应该仅有一个引起它变化的原因。
开放-封闭原则（OCP）软件实体应该是可以扩展的，但是不可修改。
n Liskov替换原则（LSP）子类型必须能够替换掉它们的基类型。
n 依赖倒置原则（DIP）抽象不应该依赖于细节。
细节应该依赖于抽象。
n 接口隔离原则（ISP）不应该强迫客户依赖于它们不用的方法。
接口属于客户，不属于它所在的类层次结构。
n 重用发布等价原则（REP）重用的粒度就是发布的粒度。
共同封闭原则（CCP）包中的所有类对于同一类性质的变化应该是共同封闭的。
一个变化若对一个包产生影响，则将对该包中的所有类产生影响，而对于其他的包不造成任何影响。
共同重用原则（CRP）一个包中的所有类应该是共同重用的。
如果重用了包中的一个类，那么就要重用包中的所有类。
环依赖原则（ADP）在包的依赖关系图中不允许存在环。
稳定依赖原则（SDP）朝着稳定的方向进行依赖。
稳定抽象原则（SAP）包的抽象程度应该和其稳定程度一致。
上述中的包的概念是：包可以用作包容一组类的容器，通过把类组织成包，我们可以在更高层次的抽象上来理解设计，我们也可以通过包来管理软件的开发和发布。
目的就是根据一些原则对应用程序中的类进行划分，然后把那些划分后的类分配到包中。
敏捷设计是一个过程，不是一个事件。
它是一个持续的应用原则、模式以及实践来改进软件的结构和可读性的过程。
它致力于保持系统设计在任何时间都尽可能得简单、干净和富有表现力。
软件开发方法之敏捷开发,你用了么
展开全部 1）敏捷开发的过程有着更强的适应性而不是预设性，从敏捷宣言的第四条响应变化高于预设计划便可以看出来。
因为软件开发过程的本身的不可预见性，很多用户在项目开始时不可能对于这个项目有着一个完整而明确的预期。
很多对软件的预期都在后期的修改和完善过程中产生。
因此高适应性显然更加符合软件工程开发的实际。
而敏捷开发实现其适应性的方式主要在于，第一，缩短把项目提交给用户的周期；第二，增加用户，业务人员，开发人员这三者之间的交流；第三，通过减少重构的成本以增加软件的适应性。
（2）敏捷开发的过程中，更加的注重人的因素。
在传统软件工程中，个人的因素很少的被考虑到分工中，每个个体都是只是整个代码开发机器的一个小小的螺丝钉，个人的意志和创造力很大程度上的被抹去为了更好的为集体服务。
而在敏捷开发过程中，每个个人的潜力被充分的考虑，应用什么技术很大程度上直接由在第一线开发的技术人员决定；每个人的特点和创造力都可以充分地发挥，这样开发出来的软件更加的具有生命力，因为他融入了开发者的心血和创意，开发者不再是进行机械的乏味的堆砌，而是创造属于自己的艺术品，这样的条件下产生的代码必然在质量上更占优势。
（3）在敏捷开发的过程中，整个项目是测试驱动的而不是文档驱动的。
不仅每个模块有着自己的相应的测试单元，开发人员在开发自己的模块的过程中必须保证自己所开发的模块可以通过这一单元的测试，并且集成测试贯穿了整个开发过程的始终。
集成测试每天会进行十几次甚至几十次，而不是像传统方法一样只有当各个模块的编码都结束了之后再进行联合调试。
这样，在软件开发的进程中每一点改动所引起的问题都容嘉容易暴露出来，使得更加容易在错误刚刚产生的时候发现问题从而解决问题。
这样就避免了在最后整个系统完成时错误隐藏的太深给调试造成极大的困难。
...
敏捷软件开发有哪些大型企业采用？
敏捷软件开发在国内和国外的情况还是很不同的。
国外追求程序员二次开发的自由度，而国内反而追求非程序员上手使用的简便性。
诸如可口可乐、谷歌、摩托罗拉、强生、沃尔玛等大型跨国企业都将敏捷软件开发服务外包给了思艾特，而国内更多的是清华大学、北京大学的图书馆采用了敏捷开发。
java入门书籍推荐
展开全部一、Java编程入门类 对于没有Java编程经验的程序员要入门，随便读什么入门书籍都一样，这个阶段需要你快速的掌握Java基础语法和基本用法，宗旨就是“囫囵吞枣不求甚解”，先对Java熟悉起来再说。
用很短的时间快速过一遍Java语法，连懵带猜多写写代码，要“知其然”。
1、《Java编程思想》 在有了一定的Java编程经验之后，你需要“知其所以然”了。
这个时候《Java编程思想》是一本让你知其所以然的好书，它对于基本的面向对象知识有比较清楚的交待，对Java基本语法，基本类库有比较清楚的讲解，可以帮你打一个良好的Java编程基础。
这本书的缺点是实在太厚，也比较罗嗦，不适合现代人快节奏学习，因此看这本书要懂得取舍，不是每章每节都值得一看的，挑重点的深入看就可以了。
2、《Agile Java》中文版 这本书是出版社送给我的，我一拿到就束之高阁，放在书柜一页都没有翻过，但是前两天整理书柜的时候，拿出来一翻，竟然发现这绝对是一本好书！这本书一大特点是以单元测试和TDD来贯穿全书的，在教你Java各种重要的基础知识的过程中，潜移默化的影响你的编程思维走向敏捷，走向TDD。
另外这本书成书很新，以JDK5.0的语法为基础讲解，要学习JDK5.0的新语法也不错。
还有这本书对于内容取舍也非常得当，Java语言毕竟类库庞大，可以讲的内容太多，这本书选择的内容以及内容的多寡都很得当，可以让你以最少的时间掌握Java最重要的知识，顺便培养出来优秀的编程思路，真是一本不可多得的好书。
虽然作者自己把这本书定位在入门级别，但我不确定这本书用来入门是不是稍微深了点，我自己也准备有空的时候翻翻这本书，学习学习。
二、Java编程进阶类 打下一个良好的Java基础，还需要更多的实践经验积累，我想没有什么捷径。
有两本书值得你在编程生涯的这个阶段阅读，培养良好的编程习惯，提高你的代码质量。
1、《重构 改善既有代码的设计》 这本书名气很大，不用多介绍，可以在闲暇的时候多翻翻，多和自己的实践相互印证。
这本书对你产生影响是潜移默化的。
2、《测试驱动开发 by Example》 本书最大特点是很薄，看起来没有什么负担。
你可以找一个周末的下午，一边看，一边照做，一个下午就把书看完，这本书的所有例子跑完了。
这本书的作用是通过实战让你培养TDD的思路。
三、Java架构师之路 到这个阶段，你应该已经非常娴熟的运用Java编程，而且有了一个良好的编程思路和习惯了，但是你可能还缺乏对应用软件整体架构的把握，现在就是你迈向架构师的第一步。
1、《Expert One-on-One J2EE Design and Development》 这本书是Rod Johnson的成名著作，非常经典，从这本书中的代码诞生了springframework。
但是好像这本书没有中译本。
2、《Expert One-on-One J2EE Development without EJB》 这本书由gigix组织翻译，多位业界专家参与，虽然署名译者是JavaEye，其实JavaEye出力不多，实在是忝居译者之名。
以上两本书都是Rod Johnson的经典名著，Java架构师的必读书籍。
在我所推荐的这些书籍当中，是我看过的最仔细，最认真的书，我当时读这本书几乎是废寝忘食的一气读完的，有小时候挑灯夜读金庸武侠小说的劲头，书中所讲内容和自己的经验知识一一印证，又被无比精辟的总结出来，读完这本书以后，我有种被打通经脉，功力爆增的感觉。
但是后来我看过一些其他人的评价，似乎阅读体验并没有我那么high，也许是因为每个人的知识积累和经验不同导致的。
我那个时候刚好是经验知识积累已经足够丰富，但是还没有系统的整理成型，让这本书一梳理，立刻形成完整的知识体系了。
3、《企业应用架构模式》 Martin的又一本名著，但这本书我只是泛泛的看了一遍，并没有仔细看。
这本书似乎更适合做框架的人去看，例如如果你打算自己写一个ORM的话，这本书是一定要看的。
但是做应用的人，不看貌似也无所谓，但是如果有空，我还是推荐认真看看，会让你知道框架为什么要这样设计，这样你的层次可以晋升到框架设计者的角度去思考问题。
Martin的书我向来都是推崇，但是从来都没有像Rod Johnson的书那样非常认真去看。
4、《敏捷软件开发 原则、模式与实践》 Uncle Bob的名著，敏捷的经典名著，这本书比较特别，与其说是讲软件开发过程的书，不如说讲软件架构的书，本书用了很大篇幅讲各种面向对象软件开发的各种模式，个人以为看了这本书，就不必看GoF的《设计模式》了。
四、软件开发过程 了解软件开发过程不单纯是提高程序员个人的良好编程习惯，也是增强团队协作的基础。
1、《UML精粹》 UML其实和软件开发过程没有什么必然联系，却是软件团队协作沟通，撰写软件文档需要的工具。
但是UML真正实用的图不多，看看这本书已经足够了，完全没有必要去啃《UML用户指南》之类的东西。
要提醒大家的是，这本书的中译本翻译的非常之烂，建议有条件的看英文原版。
2、《解析极限编程 拥抱变化》XP 这是Kent Beck名著的第二版，中英文对照。
没什么好说的，必读书籍。
3、《统一软件开发过程》UP 其实UP和敏捷并不一定冲突，UP也非常强调...
重构与模式、敏捷软件开发、领域驱动设计、企业应用架构模式,应当...
1.《重构与模式》Joshua Kerievsky科瑞夫斯盖著 看了这个你就明白什么意思了 不解释2.《领域驱动设计》（美）埃文斯 不解释3.《敏捷软件开发》Robert C.Martin所著 不解释4.《企业应用架构模式》（英）福勒 ，王怀民，周斌 译 不解释至于学习方法，首先应该学习linux内核，上述这些东西基本上都是提取内核的精华。
内核中都有体验，内核是神作，代码很优秀。
这些东西纸上学来终归没多大用，需在工程师职位干上5年+，你对这些东西就有体会了。
没有什么学习步骤，这些都是一些高级的东西，俗话说，先把代码写对，再把代码写好就行了。
敏捷开发就是迭代开发么？
展开全部 两者有关，但不是一回事迭代开发是一种软件开发的生命周期模型，与其对应的还有瀑布模型、螺旋模型等等敏捷开发是多种软件开发项目管理方法的集合，其中保护了XP、Scrum等十几种开发模式，这些开发方法有些共同点，比如重视响应变更，重视实现客户的价值，重视开发人员的自身发展等等，其核心体现在他们著名的四句原则中。
这些开发方法基本都倾向于采用迭代的软件开发生命周期模型。
简单来说，迭代模型是敏捷开发普遍使用的软件生命周期模型，敏捷开发所包含的内容比迭代模型宽泛的多。
...
有什么敏捷软件开发平台？
【敏捷项目没有需求分析吗？】 在很多人的印象中，敏捷软件开发是种类似黑客行为的过程，是程序员最爱的勾当。
不写文档，不作需求分析，没有项目经理，做什么东西完全是程序员自己的行为。
所以他们认为这样的过程无法满足真正大型项目和复杂项目的需要，因此在经过考虑后，放弃了敏捷方法。
项目经理圈子真的是这样吗？敏捷过程到底是如何做需求分析？用户故事和用例有什么区别？敏捷过程如何去管理需求的？这些是一些想要实践敏捷的人一直在困惑的事情。
我们常常看到书中讲，程序员拿到一个用户故事后，怎么计划，怎么分解，怎么写单元测试，怎么小步前进，怎么持续集成。
这是典型的程序员视角。
事实上，敏捷方法分为三部分，敏捷项目管理，敏捷需求分析，敏捷软件开发。
上述书中提到的完全是敏捷开发中的实践，很多人了解到的敏捷，只是敏捷的三分之一。
【敏捷项目中谁来做需求分析？】 在敏捷的团队中，作一个敏捷程序员确实是非常舒服的事情。
从程序员的角度来看，只需要选择一张他感兴趣的故事卡片，了解清楚该卡片的需求，开始从功能测试写代码，等通过了所有测试就完工。
基本上不需要考虑太多的事情，非常轻松愉快。
但程序员向谁去问清楚需求？故事卡片是怎样写出来的呢？让我们来关注开发前发生的事情。
了解敏捷过程的人都知道，Kent Beck在XP过程中提到了现场客户，如果一个敏捷团队能够有现场客户，这当然是最棒的事情。
但多数情况下，客户都是很忙碌的，很难全力投入到软件开发过程中。
这时候，我们就需要商务分析师这个角色，来充当客户的角色。
我在公司的团队中曾担任的就是商务分析师这个角色。
商务分析师最重要的职责就是与客户交谈，了解和分析需求，将其制作成用户故事并将需求转述给程序员。
同时，商务分析师也要代替客户负责功能验收测试。
【敏捷项目中如何进行需求分析？】 敏捷思想的核心是人与交流。
需求问题实际上是一个交流问题。
商务分析师要和客户交流，搞清楚客户到底需要什么，到底为什么需要这些东西。
商业价值是商务分析师关注的最终目标。
有了目标的指向，就可以不迷失方向。
和客户进行交流，最终目的就是挖掘出客户的商业目标。
可能大家会经常有这样的经验，客户说，我要这个功能，我想要怎么怎么样。
这时候要特别注意，他说的这些东西并不是真正的需求。
商务分析师需要详细的问客户为什么，挖掘出他真正的目标。
在这个目标下，商务分析师开始进行需求的分析：我们到底是否真的需要这个需求？有没有更好的解决方案？有没有简单并且低廉的方式？换一种形式是不是也能达到这样的需求？这个需求有多少地方涉及到以前的软件变更？ 搞清楚这些事情后，就可以写出用户故事。
用户故事的书写遵循一定的原则，一般包括三部分：＂作为（系统的一个涉众），我想要（做一件事），从而（达到一个商业价值）＂。
在书写的时候格式比较随意，可以在故事卡背面写上注释或疑问，甚至画上界面原形图。
举一个最常见的用户故事例子，“作为一个普通用户，我希望能够用用户名和密码登录，以便我能享受到个性化的服务”。
其中，用户是系统涉众，登录是他想要做的事情，而他的目标是获得个性化的服务。
从这个例子我们可以想象到，这个页面可能存在两个文本框，用于输入用户名和密码，有一个按钮来登录，并且不登录就不能看到个人资料，另外，如果用户输入错误需要提示“登录失败请重试”。
这就是可见性，也可以称为可测试性。
我们可以根据这样的可见性写出功能测试，从而驱动这个用户故事的开发，这被称为 Acceptance Driven Development。
用户故事的作用有两个，一个是作为进度跟踪的依据，一个是作为与人交谈的备忘录。
用户故事卡片并不是很精确的需求，因此不需要把事情描述的非常清楚。
将需求的详细分析推迟到实现前夕来完成，这是敏捷需求分析的精华所在。
任何提前做好的东西都会导致浪费，敏捷过程提倡足够就好，避免浪费。
不少人对用户故事和用例的区别感到疑惑。
用户故事的作用是备忘功能，而不是文档。
而用例需要详细的描述其操作步骤，以及每个异常路径，因而起到了文档的作用。
用户故事是可见的商业价值，而不是功能描述。
每个用户故事的粒度和工作量都相差不多，这和用例有很大的区别。
用户故事是小粒度的，可测试的，可见的，并且是有价值的。
【敏捷项目需求分析案例】 公司有个项目组作的是一个网游物品交易平台。
该平台是典型的互联网项目，在开工的时候客户对功能需求还不明确，但需要快速推出抢占市场，正是最适合敏捷过程的项目。
在项目伊始，商务分析师和客户做了深入的谈话，了解他的商业构想，他的盈利模式，搞清楚宏观的结构，然后思考并整理获得的结果，花1-2天时间将客户需求大略整理为几十个用户故事。
这些用户故事并不完善，不足以做好整个系统。
但对于我们开始项目的前一阵，已经足够了。
我们可以从这里开始项目。
敏捷方法希望快速交付可用的软件。
实现软件的快速交付是通过迭代来完成。
在迭代开始前，由一组有经验的开发人员大致评估一下用户故事，标记出不...
