敏捷开发个人体会和分享报告

第一篇：敏捷开发个人体会和分享报告

敏捷开发个人体会和分享报告

敏捷开发，曾经对它的理解就是没有文档的快速开发，先做原型，针对原型面对面交流，按照大家认可的原型再做快速开发，多次的面对面讨论原型，不断迭代原型，针对每次迭代的原型进行快速开发。众所周知，写软件开发文档是每一个程序员都懒于做的事情，认为比较痛苦的事情，所以越来越多的人因为这点去使用敏捷开发。但是经过培训学习之后，我对敏捷开发有了一些新的理解。

首先，对敏捷开发下个定义，借用百度百科的定义。简单的说，敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

这个定义只从表面上解释了一下敏捷开发，没有具体说明怎样使用敏捷开发。下面讲一下我对敏捷开发的具体心得。

1、架构师的重要性

首先，敏捷开发对于个人能力的要求是十分高的，尤其是领导人的能力。领导者及架构师是个举足轻重的角色，需要眼观大图，并关注最终成果，这就要求领导者及架构师有深厚的行业背景、创新能力、以及架构能力。一个好的架构师，必须能考虑到产品当前使用模块、产品可以继续发展的模块以及下一代产品的方向。只有考虑到这三种模块和特性，这样的产品才能保持长期的生命力。敏捷开发也强调拥抱市场变化，这对产品架构师提出了更高的要求——深厚的业务背景、创新能力、技术洞察力和架构思想。

2、能够随时应对变化的结构，适应需求变化，并能驾驭需求变化 能够随时应对变化的结构，比遵循计划更重要。计划不要考虑太远，因为各种环境都在发生变化，随着软件的提交，需求也许会发生变化。完美的甘特图能够体现对项目的整体控制力，但是详细的甘特图也是不切合实际的。感觉一般做一周的计划，是最切合实际的。

3、尽早地、持续地交付有价值的软件来满足客户需求

经常性的交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。只要我们可以保证交付的软件可以很好的工作，那么交付时间越短，我们和客户协作就越紧密，对产品成果就更有益。虽然我们多次迭代，但并不是每次迭代的结果都需要交付给用户，敏捷开发的目标是让他们可以交付。这意味着开发小组在每次迭代中都会增加一些功能，增加的每个功能都是经过编码、测试，达到可以交付的标准。

4、严格执行单元测试

所有编程人员都知道需要做单元测试，但是有多少人可以认真对待。很少人是真的想尽办法构建测试案例，大多数人都是应付了事。所以要认真对待单元测试，无单元测试的代码严禁提交。“Y23理论”教导我们不要忽视细小的错误，如果不把细小的错误消灭掉，它会给你带来毁灭性的重创。

5、每日站立会议，面对面交流

各团队成员的工作相对比较独立，对其它成员的工作了解不多，不利于整个项目的发展，每个成员容易歇入研究的死胡同。所以在团队内部，每日站立会议、面对面交流是最具有效果并且富有效率的传递信息的方法。每日站立会议要求每个人必须定点进入会议状态。每日会议前每个人要更新自己的任务面板。每日会议中决定要签出的任务，并在会议后更新任务面板，并在任务便签上注明任务的签出人。

6、关注成果，把工作按照重要性和紧急性进行分类，权衡工作重点 团队成员围绕“眼观大图，关注成果”这一导向，把自己的近期工作按照重要性和紧急性进行分类，分为四类：

1、重要、紧急

2、重要、不紧急

3、不重要、紧急

4、不重要、不紧急。根据四类情况对自己的近期工作进行权衡，把握工作重点，紧扣要事，使近期工作得以顺利开展，使远期工作也得以顺利进行。

现在社会工作的节奏越来越快，相信敏捷开发的使用者也越来越多。通过不断的对敏捷开发方法进行改善，我相信，以后不只那些中小型项目会使用敏捷开发，而且一些大的项目也会使用。总有一天，人们使用敏捷开发时会做到驾驭自如！

第二篇：敏捷开发简介

敏捷开发简介

2009-04-21 17:46:34.0来源:e800.com.cn

关键词：Scrum精益开发敏捷开发

在软件工业界，敏捷开发已成为众多高效开发团队的制胜之道。它不仅被许多中小公司青睐，在全球一百强的企业中，敏捷也已大行其道，受到许多资深项目管理者和开发人员的推崇。欧美软件企业中，有近半企业已采用敏捷方法进行开发。大多数尚未应用敏捷的企业，也都对其有所了解，而且很多在计划实施。中国的外企，外包公司和许多知名企业也都开始采用了敏捷方法。例如，腾讯内部几乎所有的开发团队都在实施敏捷。敏捷方法给这些企业也已带来了巨大的收益。据业内资深人士和长期从事敏捷咨询的服务公司透露，采用敏捷开发的团队一般会提高3-10倍的效率，软件的质量也有了更加可靠的保证。同时，敏捷开发的应用也给团队内的每个成员提供了良好的发展机会。他们的技术和合作水平都能得到响应的提高。敏捷的成功来源于其方法本身的适用性和团队对它的深入理解和合理运用。下面我们就对敏捷开发做一个简单的介绍和讨论。敏捷开发由几种轻量级的软件开发方法组成。它们包括：极限编程（XP），Scrum，精益开发（Lean Development），动态系统开发方法（DSDM），特征驱动开发（Feature Driver Development），水晶开发（Cristal Clear）等等。所有这些方法都具有以下共同特征，它们也是敏捷开发的原则和方法：

1.迭代式开发。即整个开发过程被分为几个迭代周期，每个迭代周期是一个定长或不定长的时间块每个迭代周期持续的时间一般较短，通常为一到六周。

2.增量交付。产品是在每个迭代周期结束时被逐步交付使用，而不是在整个开发过程结束的时候一次性交付使用。每次交付的都是可以被部署到用户应用环境中被用户使用的、能给用户带来即时效益和价值的产品。

3.开发团队和用户反馈推动产品开发。敏捷开发方法主张用户能够全程参与到整个开发过程中。这使需求变化和用户反馈能被动态管理并及时集成到产品中。同时，团队对于用户的需求也能及时提供反馈意见。

4.持续集成。新的功能或需求变化总是尽可能频繁地被整合到产品中。一些项目是在每个迭代周期结束的时候

集成，有些项目则每天都在这么做。

5.开发团队自我管理。拥有一个积极的、自我管理的、具备自由交流风格的开发团队，是每个敏捷项目必不可少的条件。人是敏捷开发的核心。敏捷开发总是以人为中心建立开发的过程和机制，而非把过程和机制强加给

人。

简史

许多人认为，相比于“传统”的瀑布开发模式，敏捷开发是一种“现代”的开发模式。但是，实际上敏捷方法，特别是迭代和增量开发方法（IID）起源于20世纪30年代的一些非软件项目。而最早引入一些敏捷方法的项目之一就是20世纪60年代初的美国航天局水星计划。在这个项目中，一些极限编程方法如测试先行等也被使用。此后，迭代和增量开发被IBM联邦系统部（FSD）和沃森研究中心（Watson Research Center）采纳。有趣的是一些研究人员甚至在关于瀑布开发模式的最早的论文中发现了敏捷开发的线索。在这篇论文中，温斯顿.罗伊斯（Winston Royce）建议在一个项目中使用两次瀑布模式，也就是使用两次迭代。20世纪70年代，最早的有记载的使用迭代和增量开发的主要项目之一，是为第一艘美国三叉戟潜艇开发的第一指挥和控制系统。该项目有大约一百万行代码，进行得非常成功。迭代和增量开发从此开始稳步发展，越来越多的项目开始使用这种开发模式。在1976年，Tom Gilb在他的著作《软件度量》（“Software Metrics”）一书中阐述了他的迭代和增量开发实践，这可能就是第一部阐述这种方法的书籍。迭代和增量开发的另一次出色发挥，是在一个美国宇航局航天飞机软件的开发项目。这个项目负责开发其航空电子设备的软件系统。改项目由IBM联邦系统部（IBM FSD）在1977至1980年完成。一些典型的敏捷做法，如使用8

个周迭代以及用反馈推动开发循序渐进等方法都在该项目中得以应用。

20世纪80年代，更多的出版物和更多的项目应用进一步推进了迭代开发的发展。在1895年，巴里贝母（Barry Boehm）正式定义了使用迭代开发的螺旋模型（Spiral model）。80年代初，在美国国防部发生

了一件有趣的事情。美国国防部一直以来都要求其软件开发商在开发过程中使用严格的瀑布开发模型。但是到了1987年末，国防部开始“建议”使用迭代和增量开发作为软件开发模式。后来美国国防部的项目审查显示，早期使用瀑布模式开发的软件项目，有75%以失败告终，有些开发出来的产品根本没有被使用过，只有2%的软件产品无需大量修改就能被正常使用。

20世纪90年代，推荐使用迭代和增量开发的出版物和文献显著增加。在经历了多次有“瀑布心态”

（„waterfall mentality‟）项目的失败之后，美国国防部开始“要求”而不是像80年代那样仅仅是“建议”他们的软件开发商使用IID开发模式。Rational统一开发过程（Rational Unified Process）也是在这一时期产生并发展起来的，它具有更规范的迭代渐进过程。到2000年底，更多的敏捷方法被广泛推广并被使用于各种不同的项目中。2001年二月，一组由17位在DSDM，XP，Scrum，FSD等领域的专家组成的代表团齐聚美国犹他州，寻找这些方法的共同点。最终，这些专家制定并宣布了敏捷开发宣言。由此形成了现在我们所

认识的敏捷开发和后来的敏捷联盟。

敏捷优势

为什么瀑布模式多数情况下总会失败？为什么我们需要敏捷开发模式？这个问题在日新月异，飞速发展的今天似乎很容易解释。尽管瀑布模式能够在一个迭代周期内表现优异，但是，在如何管理需求变化面前，瀑布模式

却显得无能为力。而事实上，大多数的软件项目都具有以下一些特点：

·在初始阶段，最终用户通常不能准确得知道他们需要什么样的软件。即便知道，也很少有人能准确清楚的表

达出来。

·对于某些项目，在一开始，我们可以很好的定义其所有的功能，但是可能有很多细节只能随着项目的不断深入才能被挖掘出来。即便是我们了解了所有的细节，大多数人还是不能很好的处理这些细节，特别是在项目开

发初期。

·外部环境如客户的业务模式，技术进步，甚至是系统的终端用户都有可能在开发过程中不断改变。而预想或

试图阻止这些改变通常都是徒劳的。

·在互联网时代，许多Web应用程序的开发都是基于对远景客户的预期，而非当前用户的实际需求。在这种

情况下，变化从开始就有，而且在系统开始应用后几乎每天都会发生。

敏捷方法处理需求和技术变化主要通过迭代过程来管理。在每一次迭代周期结束时，都应交付用户一个可用的，可部署的系统。使用并体验该系统所获得的有价值的反馈意见将按顺序，在随后的迭代周期中和其它需求变化一起在产品中实现和集成。每次迭代周期应尽可能短，以便能及时频繁地处理需求变化和用户反馈。

采用敏捷开发方式将会给企业和用户带来诸多好处：

·精确。它将带给用户真正需要的软件系统。瀑布模式通常会在产品起点与最终结果之间计划出一条直线，然后沿着直线不断往前走。然而当项目到达终点时，用户通常会发现那已经不是他们想去的地方。而敏捷方法则

采用小步的方式向前走，每走完一步，都需要及时调整并为下一步确定当前的方向，直到真正的终点。·质量。敏捷方法对每一次迭代周期的质量都有严格要求。一些敏捷方法如XP等，甚至使用测试驱动开发（test-driven development），即在正式开发功能代码之前，先开发该功能的测试代码。这些都对敏捷项

目的整个开发周期提供了可靠的质量保证。

·速度。敏捷开发提倡避免较大的前期规划，认为那是一种很大的浪费。因为很多预先计划的东西都会发生改变，大规模的前期规划通常是徒劳的。敏捷团队只专注于开发项目中当前最需要的，最具价值的部分。这样能

很快地投入开发。另外，较短的迭代周期使团队成员能迅速进入开发状态。

·丰厚的投资回报率（ROI）。在敏捷开发过程中，最具价值的功能总是被优先开发，这样能给客户带来最大的投资回报率。

·高效的自我管理团队。这既是采用敏捷开发的必然结果，也是推动敏捷开发不断前进的动力。敏捷开发要求团队成员必须积极主动，自我管理。在这样的团队中工作，每个团队成员的技术能力，交流，社交，表达和领

导能力也都能得以提高。

主要的敏捷方法

极限编程（XP）

极限编程（XP）的主要目的是降低需求变化的成本。它引入一系列优秀的软件开发方法，并将它们发挥到极致。比如，为了能及时得到用户的反馈，XP要求客户代表每天都必须与开发团队在一起。同时，XP要求所有的编程都采用结对编程（pair-programming）的方式。这种方式是传统的同行审查（peer review）的一种极端表现，或者可以说是它的替代方式。

XP定义了一套简单的开发流程，包括：编写用户案例，架构规范，实施规划，迭代计划，代码开发，单元测

试，验收测试等等。

像所有其他敏捷方法一样，XP预期并积极接受变化。它具有以下的价值观或原则：

·互动交流。团队成员不是通过文档来交流，文档不是必须的。团队成员之间通过日常沟通，简单设计，测

试，系统隐喻以及代码本身来沟通产品需求和系统设计。

·反馈。反馈是一种信息的交流，能使系统更加完善。反馈也和交流密切相关，客户的实际使用、功能测试、单元测试等都能为开发团队提供反馈信息。同时，开发团队也可以通过估计和设计用户案例的方式将信息反馈

给客户。

·简单。XP提倡简单的设计，简单的解决方案。XP总是从一个简单的系统入手，并且只创建今天，而不是明

天，需要的功能模块。因为它认为，创建明天需要的功能模块可能会由于需求的变化而成为浪费。

·勇气。XP在这一点所要达到的目的（我们认为）是鼓励一些有较高风险的良好的做法。例如，它要求程序员

尽可能频繁地重构代码，必须删除过时的代码，不解决技术难题就不罢休，等等。

·团队。XP提倡团队合作，相互尊重。XP以建立并激励团队为一项重要任务。同时它把互相尊重和实际的开发习惯相结合。比如，为了尊重其他团队成员的劳动成果，每个人不得将未通过单元测试的代码集成到系统

中。因此，每个人的代码质量必须过关。

核心做法：

·小规模，频繁的版本发布，短迭代周期。

·测试驱动开发（Test-driven development）。

·结对编程（Pair programming）。

·持续集成（Continuous integration）。

·每日站立会议（Daily stand-up meeting）。

·共同拥有代码Collative code ownership.·系统隐喻（System metaphor）。

SCRUM Scrum是一个敏捷开发框架，它由一个开发过程，几种角色以及一套规范的实施方法组成。它可以被运用于

软件开发，项目维护，也可以被用来作为一种管理敏捷项目的框架。

在Scrum中，产品需求被定义为产品需求积压（product backlogs）。产品需求积压可以是用户案例，独立的功能描述，技术要求等。所有的产品需求积压都是从一个简单的想法开始，并逐步被细化，直到可以被开

发的程度。

Scrum将开发过程分为多个Sprint周期，每个Sprint代表一个2-4周的开发周期，有固定的时间长度。首先，产品需求被分成不同的产品需求积压条目。然后，在Sprint计划会议（Sprint planning meeting）上，最重要或者是最具价值的产品需求积压被优先安排到下一个Sprint周期中。同时，在Sprint计划会上，将会预先估计所有已经分配到Sprint周期中的产品需求积压的工作量，并对每个条目进行设计和任务分配。在Sprint开发过程中，每天开发团队都会进行一次简短的Scrum会议（Daily Scrum Meeting）。会议上，每个团队成员需要汇报各自的进展情况，同时提出目前遇到的各种障碍。每个Sprint周期结束后，都会有一个可以被使用的系统交付给客户，并进行Sprint审查会议（Sprint review meeting）。审查会上，开发团队将会向客户或最终用户演示新的系统功能。同时，客户会提出意见以及一些需求变化。这些可以以新的产品需求积压的形式保留下来，并在随后的Sprint周期中得以实现。Sprint回顾会随后会总结上次Sprint周期中有哪些不足需要改进，以及有哪些值得肯定的方面。最后整个过程将从头开始，开始一个新的Sprint计划会议。

Scrum定义了4种主要的角色：

·产品拥有者（Product Owner）：该角色负责产品的远景规划，平衡所有利益相关者（stakeholder）的利

益，确定不同的产品需求积压的优先级等。它是开发团队和客户或最终用户之间的联络点。

·利益相关者（Stakeholder）：该角色与产品之间有直接或间接的利益关系，通常是客户或最终用户代表。

他们负责收集编写产品需求，审查项目成果等。

·Scrum专家（Scrum Master）：Scrum专家负责指导开发团队进行Scrum开发与实践。它也是开发团

队与产品拥有者之间交流的联络点。

·团队成员（Team Member）：即项目开发人员。

Scrum提供一个敏捷开发框架，其他许多敏捷方法都可以被集成到Scrum中。比如测试驱动开发（test-

driven development）和结对编程（pair programming）等都可以被整合到Scrum中。

精益开发（LEAN DEVELOPMENT）

精益软件开发模式是从丰田公司的产品开发方法中演化而来。它主要包括两个部分：一部分是核心思想及原

则，另外一部分由一些在相应的工具构成。

精益开发的核心思想是查明和消除浪费。在软件开发过程中，错误（bugs），没用的功能，等待以及其他任何对实现结果没有益处的东西都是浪费。浪费及其源头必须被分析查明，然后设法消除。精益开发的其它原则

包括:

·强调学习。软件开发过程是一个不断学习的过程。每个团队成员都需要从日常的失败，互动，交流以及信息

反馈中学习，不断改进所开发的产品和开发效率。

·在最后时刻做决定。这样可以避免在可能改变的事情上做无谓的努力，从而有效的避免浪费。

·用最快的速度交付用户。较短的迭代周期能够加速产品的开发及交付，加快交流，提高生产力。

·给团队自主权。激励团队并让所有团队成员自我管理始终是所有敏捷方法获得成功的基本因素之一。·诚信。确保整个系统正常工作，真正满足客户的需求是整个团队需要努力坚持的诚信和和对用户的承诺。·全局观。精益开发强调整体优化的系统。无论开发的组织还是被开发的产品，从整体上考虑优化比从各个局

部去优化更高效。

对于上述的每个原则，都有一些相应的实现工具。这些工具包括价值流图（Value Stream Mapping），基于集合的开发（set-based development），拉系统（pull system），排队论（queuing theory），等

等。

和其它敏捷方法相比，精益软件更重要的是不断完善开发过程的一种思维方式。因此，将精益模式与其他敏捷

开发模式一起使用将会取得很好的效果。

其它敏捷方法

动态系统开发方法（DSDM）是由快速应用程序开发（RAD）方法演变而来的敏捷开发模式。DSDM在普遍的敏捷价值和原则的基础上，定义了更加详细的流程，以涵盖更完整的项目生命周期。它们包括项目前期活动

（pre-project activities），项目可行性研究，功能建模，设计和开发，实施或部署，项目后期维护（post-project maintenance），等等。同时，每个过程都定义了诸如如何将每个功能模型转化为实际代码，如何将原型交付最终用户使用并审查，如何处理反馈信息等的详细步骤。因此，DSDM相比于其它敏捷

方法在过程上显得比较繁重。

特征驱动开发（FDD）是另一种敏捷开发方式，它将用户的功能需求划分成更小的功能特征，然后逐步地在每个迭代周期中开发实现这些产品特征。与DSDM方式一样，FDD仍然会在项目初期对整个项目做较大的规

划和建模，以获得对该系统的全面了解。但是相比DSDM来说，FDD在这些方面简捷了一些。

Crystal Clear是另一种敏捷方法。Crystal Clear更专注于人。相比于其他的敏捷方法，它可使人获得更大的解放。据称这种方法更适合于较小规模的开发小组（由2-8个人组成）和非关键项目。Crystal Clear定义了七种属性。前3个属性-频繁的交付（frequent delivery），渗透交流（osmotic communication），反思提高（reflective improvement）-反映出基本的敏捷开发做法和价值，如周期较短的迭代式开发，自我管理的开发团队和反馈带动增量发展等等。另外的4个属性分别是：个人安全（personal safety），集中

（focus），容易接触专家用户（easy access to expert users）和技术环境（technical

environment）。其中，容易接触专家用户实际就是敏捷方法中提到的客户持续参与，但Crystal Clear对此要求比较宽松。Crystal Clear也提供了一些通用的做法，比如，它提供了三种回顾分析的方法：访谈，问卷调查和工作组。Crystal Clear的过程也是相当简单，其中涉及短的迭代周期，日常会议及持续集成等。还有其他一些敏捷方法如敏捷统一过程（Agile Unified process），上下文驱动开发（Context Driven Development），Getting Real等。这些方法都是增量和迭代开发过程，并且重视人多过于整个过程。而各种敏捷方法的区别在于它们对敏捷的不同阐释和不同侧重。理解这些方法可以帮助我们从多个角度理解敏捷

开发，并且了解更多的最佳应用。

如何选择一种敏捷方法

选择一种合适的方法取决于多种因素。在做出决定之前，我们需要充分考虑以下这些方面：

·方法的复杂度。确保你的团队或组织能够应付这种复杂度。

·社区和业界支持。流行的方法可能并不是你最理想的选择，但流行的方法 至少有较多的社区及行业支持，可

以使你受益匪浅。

·实用工具。选择一种可以为你提供支持工具的方法。一个良好的软件工具可以帮助团队有效的处理日常工

作，促进团队协作，并减少管理成本。

·你目前的开发方式以及团队关于敏捷方法的认识程度。选择一些与你当前开发方式比较接近的敏捷方法将有

助于推动该方法的实施。

·你的团队规模。较小规模的团队最好从简单的方式入手。当然，这并不意味着你必须选择那些本身就比较简单的方法如Crystal Clear。你可以选择一些相对比较全面的方法，但从简单入手。当你的团队规模逐渐扩

大，再增加相应的细节。

·你不需要只遵从一种方法。你可以为团队选择一个主要的方法（如Scrum），然后从其他方法中借鉴对你的团队或组织有所帮助的其他方式加以整合。

敏捷总是在不断发展演变，因此，没有一个人能保证目前的敏捷方法都是正确的。每个采用敏捷开发的团队都

可以通过发现并形成自己的想法和最佳实践，对敏捷开发做出自己的贡献。

相关培训服务请查看：http:///services/training

1.SCRUM SCRUM?这个单词我以前没见过,所以我就不喜欢它,呵呵.SCRUM本义表示“混乱”,它包括

多个“怪异”的方法/过程名称。比如，SCRUM将开发过程分为30天的迭代周期，每个

迭代周期叫做一个Sprint(原意:冲啊!)；每天有一个15分钟的短会，用来决定第二天的任务安排这样的短会就叫做scrum。

我不喜欢SCRUM的原因如下:

1)一个方法,搞出这么多名词,加重我们程序员的负担,不好;

2)SCRUM的迭代周期为30天,而且一个周期叫一个“冲”,那不是要累死我们程序员?

3)每天有一个15分钟的短会,唉,XX党的会多!

4)15分钟的短会叫“混乱”,那....,15分钟能结束吗?

5)SCRUM强调,开发者每天要向管理者报告项目进度,唉,我受不了了....2.Crystal Crystal根据项目规模和项目的重要性(如发射火箭的项目和一个“hello world”程序的重要性当然是不一样的)来区别项目,并赋以相应的方法,所以,crystal是方法的组合.相对于其它敏捷方法,Crystal强调软件开发流程的纪律性,所以,它比其它敏捷方法易

于使用,但它的生产率不如XP等其它敏捷方法.3.ASD（Adaptive Software Development）

ASD强调开发方法的适应性（Adaptive），这一思想来源于复杂系统的混沌理论(这个

名字大家应该都听说过了,炒股的用的很多,呵呵)。ASD不象其他方法那样有很多具体的实践做法，它更侧重于理论,因为它的作者就是搞理论出身的。

4.FDD FDD（Feature Driven Development）定义了5个流程，分别是Develop an Overall Model、Build a Features List、Plan by Feature、Design by Feature和Build by Feature。

前3个流程是在项目开始就进行的，其实总体相当于我们现在的系统分析;后两个则出

现在每次迭代周期中,FDD的迭代周期是两周,相当于我们现在的设计/编码/测试。

开发人员被归为两种，一种是主程序员，另一种是class所有者。主程序员不作具体的编程工作，但要负责将Feature和Class对应起来，并充当开发协调者、设计者、技术

支持和指导者等；class所有者则进行实际的编程。我认为这样的划分对国内的软件开

发情况不合适,因为,真正达到主程序员水平的人,太少了!

对于ASD和FDD,国内介绍的还是比较多的.5.XP

第三篇：个人制鞋开发体会

（手工）制鞋开发体会

经过近两个年头大约8个多月的细致的学习，本人对于制鞋有以下心得：

制鞋分为前期开发期与后期制作：开发期要确定的有五方面，即造型、版面、面料、工艺、色彩。造型主要是确定楦的造形及楦与跟、大底的结合形式。要确定楦的造形，楦的头形把握是造型的关键。楦的形状多变，但多是在头形上作变化。而头形又总是在三个基本形上做变化；即：圆形、三角形（尖头）和方形。每个的楦形不一，都是在基本形体上稍作些改动，使之更加完美。设计师根据上季流行的驱势，综合多方信息判断未来的流行因素，从而确定楦的头型。在楦的头形的基础上确定跟的形状及大底的组合形式。跟、底、楦的组合形式确定未来鞋子的基本形态。确定楦形就是鞋子开发的重中之重。我个人认为确定楦的造型可以从两个方面着手。

1、任何事物都不可能孤立的存在。中国的鞋子开发多是紧跟国外，多参考国外的流行资料以为己用。把握当下楦形及跟、大底与面料工艺等流行的信息。这是较简便的方法。省时、省力且经济。缺点是市场雷同产品会很多。会有撞车情况发生。

2、根据以往的流行风尚，自主开发出楦形及跟、大底的组合。费时费力，费用也高。但搞出来的产品全世界独有。容易与同行拉开距离。

3、4、楦按着要做的鞋子类形分为：凉鞋楦、浅口鞋楦、深口鞋楦、靴楦。

按做出鞋子的风格分为：时装鞋楦、休闲鞋楦、我个人按鞋跟的高度和形状分为：高跟楦、中跟楦、平跟楦、内增高楦。

5、楦与跟、大底的结合：楦的形状决定的跟的形状。比如圆头楦比较适合配圆跟，方头楦比较适合于方形跟，尖头楦则更适合比较纤细的跟。这就要设计都根据不同的造型原素来确定出最完美的组合。

其次就是确定下季的流行工艺。工艺对于现在的任何行业来说每年都会有翻新。开发新的工艺就是开发新的市场。如何去开发新的工艺也至关重要。工艺的种类繁多。就目前来说有穿线（马克线、皮条、金属条等条状装饰）、打钉、烫钻、锈花、印花（滴胶）、高周波、激光、冲孔等等。工艺的运用只不过是为了加强设计效果，各种工艺可复合使用，但并不是工艺越多越好，点睛之笔不需多嘛。

工艺的流行与面料、色彩一样，也是不断的改进完善的。是轮回的提高。所以确定当季的流行工艺同确定流行面料与流行色一样的重要。方法有以下几种：

1、取国外鞋经。多看国外的流行资料，把他们的工艺吃透。再着手开发自己的工艺方面就不会是盲人摸像。现在是个资讯时代，如何把重多的讯息分类并确定自己的目标就是开发的关键。（手工）制鞋开发体会

2、从其它服饰中取经。比如看大品牌服装、包等流行驱势。从中吸取有用的工艺为己用。

3、结合经验创造新的工艺。

再次就是流行面料。流行面料与当年的工艺与科技、社会动向、流行主题等紧密相连。比如当年流行环保或是复古等，那采用的面料就要与相应的主题相关。比如去年流行主题是自然。所以就有许多许多的动物纹样的毛皮。

流行色在鞋子方面的表现没有服装明显。黑、白、灰永远是主色系。因为对于服饰来讲鞋子永远是配饰。消费者在购买的同时会想到与服装的搭配。我个人认为认识当年服装的流行色就足够了。不过也有个例。比如“圣诞鞋”。在每年的圣诞节前，都有一段时间做“圣诞鞋”。不管当年的流行色是什么，“圣诞鞋”多以红色为主。

在搭配鞋子的色彩时不但要考虑面料质感的对比，还要考虑色彩的对比。相同的款式用不同的配色方案能出来风格完全不同的鞋子。这就是色彩的魔力。

最后是版面的开发。美工（设计师）拿到跟、大底、楦后要开发出相应的版面。开发版面除了了解流行工艺、流行面料与流行色，还要充分了解楦的形状适合做什么样的鞋子。版面的开发不但要充分考虑所用的形象或符号对空间占有的状况。还要考虑到角度的转对换对鞋子的视觉影响。因此鞋子设计是一个立体构成的过程而不是简单的平面构成。在设计版面过程中必须要从整个局面出发，最终也是企求达到整个局面符合表达意图的协调统一。这和绘画中的构图要求是一致的。如果要进行高度的概括，就是变化统一。即在统一中求变化，在变化中求统一。什么样的楦头适合什么样的版面没有固定有模式。但能做出楦本身的味道却需要细心的去体会。比如时装楦，做出的鞋子要较工细、线条较长、起伏变化较多但不失圆润。做出的鞋子要充份体现出楦形的转折起伏。休闲鞋以穿着舒适为目的，同时又不失美观。相对于时装鞋来说较为饱满宽松。所以鞋面的线条多较时装鞋简练而圆润。风格可以细腻也可粗犷一些。在按排版面时，要充分考虑到点、线、面的运用。点连成线；线的排列又组成了面。随着距离的拉远，面又变成了点。这是形式美的法则，在鞋子设计中同样适用。其实工艺、色彩与版面的设计要求与其它形式的设计要求并无不同，形式美的法则永远适用，这里我就不在过于多述。

出格师傅拿到设计图纸，要研究设计师对于这只鞋子的设计意图、工艺制作的要求及版面组合的线条走向。对于出格师傅来说，根据图纸确定线条的走向是至关重要的。因为它决定了鞋子成功于否的关键。我们常说同一只鞋子，不同的出格师傅就能出成不同的鞋子线条，这与出格师傅对鞋子的理解是有很大关系的。影响出格师傅对线条的认识最直接的因素是设计图。我看过很（手工）制鞋开发体会

多美工所绘的图纸，他能画出很潇洒的线条，但是他的线条太个性了，完全脱离了楦的形状，因此出格师傅想按图出来和设计图一样的线条是几乎没有可能的。我认为一个好的美工，在画图之前一定要把跟与楦形画准。把跟底楦的比例画准后再去画版面的线条，因为版式永远是依附于楦的。在这个基础上作文章线条才不至于飘到天上去。让出格师傅下刀时有个很好的依据。

对于一只完美的鞋子来说，后期制作部分也相当重要。后期制作分为面部与底部两个部门，对于面部来说，要按照格板做出圆顺完美的线条及车线精细是很重要的。底部的制作决定了鞋子成败关键。底部制作要求敲出完美的楦形，大底要平顺跟要正。

总之一只好的鞋子是由多个部门完美合作的结晶，任何一个环节出现问题，都不可能做出好的鞋子。一点个人拙见，不足一笑。还望各位多多指教。

设计部 TONY 2011年8月18日星期四

第四篇：敏捷开发与极限编程的简介（最终版）

敏捷开发与极限编程的简介

什么是敏捷开发？

一种以人为核心、迭代、循序渐进的开发方法。

在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。简言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。敏捷开发是由一些业界专家针对一些企业现状提出了一些让软件开发团队具有快速工作、响应变化能力的价值观和原则，并于2001初成立了敏捷联盟。他们正在通过亲身实践以及帮助他人实践，揭示更好的软件开发方法。

通过这项工作，他们认为：

·个体和交互 胜过 过程和工具

·可以工作的软件 胜过 面面俱到的文档

·客户合作 胜过 合同谈判

·响应变化 胜过 遵循计划

并提出了以下遵循的原则：

我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。

经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。

在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。

围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。

在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈。

工作的软件是首要的进度度量标准。

敏捷过程提倡可持续的开发速度。

责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。不断地关注优秀的技能和好的设计会增强敏捷能力。

简单是最根本的。

最好的构架、需求和设计出于自组织团队。

每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。

参看《敏捷开发横空出世》

极限编程（XP）是一种轻量级的软件开发方法论，XP从实践中来，是对实践的总结，也是经过实践检验的，其主要特征是要适应环境变化和需求变化，充分发挥开发人员的主动精神。XP承诺降低软件项目风险，改善业务变化的反应能力，提高开发期间的生产力，为软件开发过程增加乐趣，相信这些足以吸引每个人的眼球。

在XP的项目开发中，首先引入了四个变量：成本、时间、质量和范围，通过研究变量之间的相互作用，将项目开发分析的更加透彻，成功讲述一个项目成功的原则。

为了能成功地实施XP，XP制定四个准则：沟通、简单、反馈和勇气

和十二条原则：计划游戏、小版本、隐喻、简单设计、测试、重构、结队编程、代码集体所有、持续集成、每周工作40小时、现场客户、编码标准

以及对开发人员的工作要求：编码、测试、倾听和设计。

XP是一个非常庞大的知识库，每一项都是一门值得深究的学问。提出这些要求和原则后，XP有提出了一系列的解决方案，也就是策略，其中包含：管理策略、设施策略、计划策略、开发策略、设计策略和测试策略。在真正去实现XP时，XP又提供了将策略成功应用的实践。可以说XP为你的软件开发的指导老师。XP是从实践中来的，应此有好多人围绕XP发表了一些自己的实践经验，其中主要包括：测试驱动开发、结队编程、重构和极限编程工具。

第五篇：用友UAP打造全周期开发平台 实现敏捷开发

用友UAP打造全周期开发平台 实现敏捷开发

为了解开用友UAP平台的面纱，了解更多平台技术，5月28日记者来到用友软件园，采访了用友集团UAP中心的两位专家，重点介绍了用友UAP的平台产品之一——开发平台所包含的组件及其特性，详细讲解了开发平台如何使得敏捷开发成为可能。

用友UAP平台诞生背景

中国软件行业正在经历第三次转型的阵痛，用友UAP伴随NC产品诞生，随着业务复杂度的提升，对页面交互、页面数据处理能力都提出了新的要求，这促使全新的用友UAP开发平台诞生。

用友UAP开发平台从不同类型的软件开发过程中，研究、分析、总结和提炼了大量的设计工具、开发工具、应用开发框架、中间件、基础技术类库以及研发模式等成果，并提供了一个集成的软件开发环境。

用友集团UAP中心Java应用平台开发部经理刘昆鹏表示，用友公司“平台化发展 产业链共赢”的策略，对如何有效利用和扩展研发成果，并在不同研发层次进行独立的资产管理和发展提出了要求。另一方面，随着软件工程的不断推进，整个开发过程的各个环节更加精细化，管理人员、需求人员、设计人员、开发测试等各开发人员都需要协同工作。所以将在开发过程中所产生的最佳实践达到有效的积累，也是开发平台要解决的问题。

用友集团UAP中心Java应用平台开发部经理 刘昆鹏

UAP开发平台的核心优势

用友集团UAP中心技术支持部总经理彭立东介绍，该平台包括了覆盖软件全生命周期的需求分析、设计、开发、测试、构造、发布、运行及维护等各阶段所需的工具。基于用友UAP开发平台能够大幅度提升软件的开发效率、稳定性、可集成性及可维护性，降低软件实现的技术难度以及开发成本。

用友集团UAP中心技术支持部总经理 彭立东

用友UAP开发平台由可视化集成开发环境、应用开发框架、公共服务以及基础技术类库/中间件几个部分组成，同时从开发过程角度提供了软件配置管理与研发管理功能。可视化集成开发环境UAP Studio支持业务建模、分析、设计、开发、测试、组装、发布等开发过程的全生命周期管理，提供各种管理工具、设计器、监控工具，以及软件配置管理系统。采用模型驱动开发的方式，通过上一阶段的输出与下一阶段的输入结合，利用可视化设计器将开发过程串接起来，大大降低开发难度，降低各阶段的鸿沟和不一致性。

用友UAP开发平台的“灵魂”

随后，彭立东先生向记者重点介绍了开发平台的“灵魂”——元数据。元数据框架支持访问服务、开发服务、管理服务，支持建模开发工具整合与适配其他系统模型数据，并提供统一的查询服务，使得平台上的开发者只需要关注业务逻辑，实现了业务与技术的分离。

开发平台的实体设计器包含多种建模元素和实体元素，可以可视化的方式创建面向对象的实体组件，可通过配置代码模板，自动产生可以直接运行的业务实体源代码。

业务与技术相分离

用友UAP开发平台的应用开发框架是基于企业建模理论的，将应用软件的业务逻辑和开发技术相分离，是应用软件开发者可以仅仅关注应用的业务逻辑，而不必关注繁琐的技术实现，使得管理层与业务人员参与应用软件的开发成为可能。大大缩短研发周期、提高研发效率、加快应用开发速度、减少企业信息系统开发的风险，并保证应用开发软件的质量，实现最终用户的个性化的需求。

除了支持开发WEB应用等常见的应用类型外，还支持开发跨平台移动应用。用友UAP移动应用框架提供了数据处理、应用适配器等功能，提供移动应用商店，开发者可以在上面发布自己的移动应用产品。

用友UAP平台产品的问世，能够支持我国大型企业及公共组织更好的实现IT及软件系统的运营与运维，提升管理绩效，并帮助客户参与全球化竞争。其开发平台将开发的全过程做为资产管理起来，大量的原数据模型和可视化界面大大降低开发的难度，实现了敏捷开发。