 |
|
|
|
|
|
|
| “系统思考”源于彼得·圣吉所著的《第五项修炼-学习型组织的艺术与实务》一书，彼得·圣吉所说的第五项修炼指的就是：系统思考，什么是系统思考?系统思考是对影响系统行为的力量和相互关系进行思考的方式。简单的说，就是用系统的、整体的、全局的思维方式而不是细节的、片面的、局部的思维方式去思考解决工作生活中遇到的问题。 [详细介绍]
| |
| |
| |
|
|
|
|
SOA技术架构如何支持敏捷开发方法 |
|
| 提到架构的问题，因为SOA这种技术架构强调“随需应变，实际上敏捷也是提倡让企业更快的适应变化。技术架构上随需应变和开发方法的随需应变有什么关系，技术上的随需应变能够给开发方法上的随需应变带来上来帮助和好处? |
|
敏捷与架构 一个都不能少 |
|
| 关于敏捷开发的文章很容易给人留下这样的印象：构架并不重要，它只是偶然形成的一个晦涩的词语而已。本文则要解释的正是架构的重要作用、它在开发周期中的意义、它与开发人员的关系，以及对系统成本消耗的影响。
|
|
敏捷开发实践真的不利于架构设计吗？ |
|
| 增量迭代开发(敏捷实践之一，它意味着每次迭代的产出只是本次迭代范围内的需求)真的不利于产生好的设计吗?Scrum真的提倡“忽视架构问题”吗?如果没有敏捷技术实践的话，架构设计能有效的演化吗?测试先行式的开发真会产生优雅的设计吗?在红绿条提示下的重构循环只在局部小范围内有效吗?
|
|
在敏捷开发中采用演进式架构设计 |
|
| 在敏捷开发过程中，我们还需要对系统架构进行设计吗?事实上，Martin Fowler在《Is Design Dead?》一文中已经给出了答案，那就是我们同样不能忽略对系统架构的设计。与计划性的设计(Planned Design)不同，我们需要演进式的设计(Evolutionary Design)。在敏捷开发的生命周期中，我们通过每一次迭代来丰富与更新我们的设计方案，以使其最大限度地符合客户对系统的需求。这里所指的需求，包括功能性需求和非功能性需求。
|
|
面向模式的软件架构：并发 |
|
| 选择什么样的并发架构会对多线程软件的设计和性能产生极大的影响，而对分布式软件的影响尤为明显。然而，还没有一种并发架构是适合所有的负载情况和平台的。本章所介绍的四种并发模式可以应对多种并发问题——从将异步并发处理与同步并发处理组合起来到将对共享组件的访问进行同步，同时保证性能和吞吐量的最大化。
|
|
以人为本：敏捷开发面面观 |
|
| 敏捷开发(agile development)是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。简言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
|
|
|
传统与敏捷 N杯水与一整桶水的区别 |
|
| 在具体的敏捷开发过程中，究竟是哪一点最为吸引人们的目光?敏捷开发吸引人的潜力在何处?我们来听听作为作为敏捷开发过程中的开发者Paulo Caroli，他是如何理解敏捷开发的魅力的?他对敏捷开发又是如何理解的呢?
| |
|
|
敏捷思维:从方法论看架构设计 |
|
| 方法论对软件开发而言意味着什么？我们如何看待软件开发中的方法论？方法论能够成为软件开发的救命稻草吗？在读过此文后，这些疑惑就会得到解答。
|
|
|
|
|
|
|
|
|
随着敏捷开发在过去几年来日益流行，许多公司正在考虑如何利用敏捷开发流程和技术。虽然我不是敏捷开发的倡导者，但是敏捷开发技术已证明在某些类型的组织和项目中是非常有益的。 在开发流程和与流程开发相关的问题中，敏捷性已成为热门话题，因为：
企业希望能够更快地对市场变化做出反应。
IT 部门希望交付结果而不需要正式（或通常）的六个月发布周期。 开发人员喜欢稳定的开发环境，以便能够在其中集中精力处理正在构建的软件的功能和质量。
敏捷开发并非对所有的组织、项目或客户都适合。存在某些使得敏捷开发适合于某些组织而不太适合其他组织的条件。此外，一如既往地，实际执行流程的是人员（并且人员具有各种各样的类型）。 |
·专题策划/制作：郑重
·联系电话：15810387786
·MSN：zhlovezh@hotmail.com·邮件：zhengzhong@yesky.com |
|
|
