敏捷开发是一种软件开发方法，基于迭代和增量开发，通过自组织,跨团队，沟通协作完成开发工作。
敏捷宣言的诞生： 2001年2月11日到13日，17位软件开发领域的领军人物聚集在美国犹他州的滑雪胜地雪鸟（Snowbird）雪场。经过两天的讨论，“敏捷”（Agile）这个词为全体聚会者所接受，用以概括一套全新的软件开发价值观。这套价值观，通过一份简明扼要的《敏捷宣言》，传递给世界，宣告了敏捷开发运动的开始。
敏捷软件开发宣言
我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
也就是说，尽管右项有其价值，我们更重视左项的价值。
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items _disibledevent=>http://zh.wikipedia.org/wiki/Scrum
Scrum Role 角色
Product Owner, Team, ScrumMaster, Chicken and the Pig
产品经理，团队，ScrumMaster，鸡和猪，有一则小故事
Scrum Meetings
Sprint 计划会议 Sprint Planning Meeting
需求澄清，确定那些用户故事需要在接下来的迭代里完成
根据Product Owner制定的产品或项目计划在Sprint的开始时做准备工作。
他要准备一个根据商业价值排好序的客户需求列表。这个列表就是Prodct Backlog[需求池]，一个最终会交付给客户的产品特性列表，它们根据商业价值来排列优先级。
商业价值"公式"：As a <type of user> I want <some functionality> so that <some benefit>
每日站立会 Daliy Meeting 在会议上每个团队成员回答三个问题（During the meeting, each team member answers three questions）
1. 昨天你完成了那些工作?（What have you done since yesterday?）
2. 今天天你打算做什么?（What are you planning to do today?）
3. 完成你的目标是否存在障碍?（Do you have any problems that would prevent you from accomplishing your goal?）
会议准时举行（The meeting starts precisely _disibledevent=>
评审会议（Sprint Review Meeting）评审会议在每个迭代结束后举行，在会议上团队演示此次迭代中完成了那些工作，一般会有相关的DEMO演示。
At the end of each sprint a sprint review meeting is held. During this meeting the Scrum team shows what they accomplished during the sprint. Typically this takes the form of a demo of the new features.
这个会议演示的内容应该是启动会议上确定的那些内容
During the sprint review the project is assessed against the sprint goal determined during the Sprint planning meeting
回顾会议（Sprint Retrospective Meeting）冲刺回顾会议一般限时为3个小时（The sprint retrospective meeting is timeboxed to 3 hours.）
仅团队成员参加，产品经理和ScrumMaster，产品经理选择性参加（It is attended _disibledevent=>
测试驱动开发（TDD/Test-Driven Development）测试驱动开发不是指测试人员驱动开发人员搞开发，一开始我真这么认为了，实际上测试驱动开发指以测试用例为出发点，不写一行代码的情况下，编写单元测试，从而无法通过，然后开始编写代码使之通过测试。这样做的好处是直指目标，达到目标被视为最高优先级，TDD的执行离不开重构，因为这种开发方式完全漠视设计。所以设计在开始时一定很差，通过不断的重构达到最优的代码，绝不会过度设计，也不会做偏。网上多半会说实践后你会喜欢上它，它的大概流程如下图所示：
极限编程XPXP是一个轻量级的、灵巧的软件开发方法；同时它也是一个非常严谨和周密的方法。它的基础和价值观是交流、朴素、反馈和勇气。即任何一个软件项目都可以从四个方面入手进行改善：加强交流；从简单做起；寻求反馈；勇于实事求是。XP是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期；通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。
结队编程Paring Program -即时反馈
http://kb..com/page/91650/
http://www.blogjava.net/moxie/archive/2006/09/14/69714.html
流模式（Flow）——两个程序员共同从事一个有趣又有挑战性的问题。
指导模式（Coaching）——老练的程序员在解决问题方面有经验和知识，可以与其他不能有效地独自解决问题的程序员分享。
看板Kanban - 工作可视化，专注于当下非常软的软广告：国产开源敏捷工具 - fKanban
http://www..com/a311300/archive/2010/11/18/1880776.html
ToDo, _disibledevent=>
敏捷估算扑克 - 合理的任务分解
http://community.techexcel.com.cn/010DevSuite/070Agile_Scrum/010Posts/010Agile_Poker
http://www.csaipm.com/cost/201005101141211188.htm
敏捷方法中的估算应该是由团队成员共同进行，而不是由项目经理“闭门造车”式地得出。这样做的原因之一是因为开发团队是由不同经验的同事组成，对于同一个问题，经验不同的人往往会给出不一样的解决方案。如果可以将所有人的能力集中到一起,那么最后对问题的求解也就八九不离十了。
持续集成（Continuous Integration）- 团队协作的基础http://blog.csdn.net/tony1130/article/details/1876819
http://www.hansky.com.cn/cn/dokuwiki/doku.php/corp/case/digitalchina
什么是持续集成（Continuous Integration）?
这个名词已经在软件开发领域持续了N年，一个比较简单的定义如下：
持续集成（CI）是一种实践，可以让团队在持续发布的基础上收到反馈并进行改进，不必等到开发周期后期才寻找和修复缺陷。
单元测试Unit Test - 重构的保障http://www.hudong.com/wiki/%E5%8D%95%E5%85%83%E6%B5%8B%E8%AF%95
单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。
敏捷测试 Agile Test
http://subject.csdn.net/agile-testing.htm
所谓敏捷测试，就是指测试遵循敏捷宣言进行，把开发作为顾客看待。与敏捷宣言中的“个体和交互比过程和工具更有价值”一样强调人的作用。
代码重构（Reconstruction）
Duplicated Code（重复代码）
Long Method（过长函数）
Large Class（过大的类）
Long Parameter List（过长参数列）
Divergent Change（发散式变化）
Shotgun Surgery（霰弹式修改）
Feature Envy（依恋情结）
Data Clumps（数据泥团）
Primitive Obsession（基本类型偏执）
Switch Statements（switch惊悚现身）
Parallel InheritanceHierarchies（平行继承体系）
Lazy Class（冗赘类）
Speculative Generality（夸夸其谈未来性）
Temporary Field（令人迷惑的暂时字段）
Message Chains（过度耦合的消息链）
Middle Man（中间人）
Inappropriate Intimacy（狎昵关系）
Alternative Classes with Different Interfaces（异曲同工的类）
Incomplete Library Class（不完美的库类）
Data Class（纯稚的数据类）
Refused Bequest（被拒绝的遗赠）
Comments（过多的注释）
Extract Method（提炼函数）
Inline Method（内联函数）
Inline Temp（内联临时变量）
Replace Temp with Query（以查询取代临时变量）
Introduce Explaining Variable（引入解释性变量）
Split Temporary Variable（分解临时变量）
Remove Assignments to Parameters（移除对参数的赋值）
Replace Method with Method Object（以函数对象取代函数）
Substitute Algorithm（替换算法）
Move Method（搬移函数）
Move Field（搬移字段）
Extract Class（提炼类）
Inline Class（将类内联化）
Hide Delegate（隐藏"委托关系"）
Remove Middle Man（移除中间人）
Introduce Foreign Method（引入外加函数）
Introduce Local Extension（引入本地扩展）
Self Encapsulate Field（自封装字段）
Replace Data Value with Object（以对象取代数据值）
Change Value to Reference（将值对象改为引用对象）
Change Reference to Value（将引用对象改为值对象）
Replace Array with Object（以对象取代数组）
Duplicate Observed Data（复制"被监视数据"）
Change Unidirectional Association to Bidirectional（将单向关联改为双向关联）
Change Bidirectional Association to Unidirectional（将双向关联改为单向关联）
Replace Magic Number with Symbolic Constant（以字面常量取代魔法数）
Encapsulate Field（封装字段）
Encapsulate Collection（封装集合）
Replace Record with Data Class（以数据类取代记录）
Replace Type Code with Class（以类取代类型码）
Replace Type Code with Subclasses（以子类取代类型码）
Replace Type Code with State/Strategy（以State/Strategy取代类型码）
Replace Subclass with Fields（以字段取代子类）
Decompose Conditional（分解条件表达式）
Consolidate Conditional Expression（合并条件表达式）
Consolidate Duplicate Conditional Fragments（合并重复的条件片段）
Remove Control Flag（移除控制标记）
Replace Nested Conditional with Guard Clauses（以卫语句取代嵌套条件表达式）
Replace Conditional with Polymorphism（以多态取代条件表达式）
Introduce Null Object（引入Null对象）
Introduce Assertion（引入断言）
Rename Method（函数改名）
Add Parameter（添加参数）
Remove Parameter（移除参数）
Separate Query from Modifier（将查询函数和修改函数分离）
Parameterize Method（令函数携带参数）
Replace Parameter with Explicit Methods（以明确函数取代参数）
Preserve Whole Object（保持对象完整）
Replace Parameter with Methods（以函数取代参数）
Introduce Parameter Object（引入参数对象）
Remove Setting Method（移除设值函数）
Hide Method（隐藏函数）
Replace Constructor with Factory Method（以工厂函数取代构造函数）
Encapsulate Downcast（封装向下转型）
Replace Error Code with Exception（以异常取代错误码）
Replace Exception with Test（以测试取代异常）
Pull Up Field（字段上移）
Pull Up Method（函数上移）
Pull Up Constructor Body（构造函数本体上移）
Push Down Method（函数下移）
Push Down Field（字段下移）
Extract Subclass（提炼子类）
Extract Superclass（提炼超类）
Extract Interface（提炼接口）
Collapse Hierarchy（折叠继承体系）
Form Tem Plate Method（塑造模板函数）
Replace Inheritance with Delegation（以委托取代继承）
Replace Delegation with Inheritance（以继承取代委托）
Tease Apart Inheritance（梳理并分解继承体系）
Convert Procedural Design to Objects（将过程化设计转化为对象设计）
Separate Domain from Presentation（将领域和表述/显示分离）
Extract Hierarchy（提炼继承体系）
代码Review
不想重复说了，同单元测试一样重要。
总结以上是个人经过理论学习，实践检验后总结的一篇文章，其中大部分观点、素材皆来自网络和公司敏捷活动中所得。我想要说的是，我是支持这些观点的，我认为这些方法论可以很好的指导日常开发工作，能够解决实际问题，That's All。
标签： 敏捷开发
最新评论