目录
18 关系: 交叉功能工作小组，快速應用程式開發，犹他州，统一软件开发过程，美国，看板，看板 (软件开发)，燃尽图，瀑布模型，行为驱动开发，软件开发，软件开发过程，迭代式开发，Scrum，极限编程，探索性測試，持續整合，测试驱动开发。
- 敏捷軟體開發
- 軟體專案管理
- 软件工程
- 软件开发
- 软件开发哲学
交叉功能工作小组
"Cross-function groups"或者"Cross-function work groups"可称为交叉功能工作小组。 它是指在一个组织内部进行纵向和横向的交叉，使部门之间的联系更加紧密。一般情况下，交叉功能小组会根据地区或产品种类进行划分。在这些交叉功能小组中，等级原则只被用于当管理层需要进行最终表决时。 由于交叉功能小组的特殊性，其中成员都拥有"双重角色"，即他们既是纵向组织的成员也是横向组织的成员，一般情况下，他们有至少两个直接上级。 典型举例：项目小组，发展研究部门下设项目等。.
快速應用程式開發
快速應用程式開發（原名：Rapid Application Development、縮寫：RAD）是指一種以最小幅度的規劃並迅速地將原形完成的軟體發展方法論。採用RAD進行軟體開發的規劃是和撰寫軟體本身交錯同時進行的。通常能在沒有大量預先規劃的情況下，讓軟體更快寫完、更容易變更需求。 有時也作為採用此種方法論的工具的代稱，此類工具大多支援所見即所得的介面設計畫面、顯示相關原始碼及說明文件，以及事件及例外處理的快速設定等等輔助使用者迅速完成所需功能的便捷機制。.
犹他州
犹他州（State of Utah）是美国西部的一个州。於1896年1月4日成為美國第45個州。犹他州是美国13大的州、人口排行33和人口密度倒数第10名的州。猶他州行政區劃一共有29個郡。全州人口共约285.5万（2012年人口估算），約80%人口居住於首府盐湖城。主要由耶穌基督後期聖徒教會信眾的后代和北歐移民的后裔组成，这对犹他州文化和日常生活有很大的影响。耶穌基督後期聖徒教會总部也设立在盐湖城。, the Pew Forum on Religion & Public Life, pp 99–100.
查看 敏捷软件开发和犹他州
统一软件开发过程
統一軟體開發過程（Rational Unified Process，縮寫為RUP）是一種软件工程方法，為迭代式軟體開發流程。最早由Rational Software公司開發，因此冠上公司名稱。Rational Software公司後來被IBM併購，成為IBM之下的一個部門，因此又稱IBM-Rational Unified Process。 RUP描述了如何有效地利用商业的可靠的方法开发和部署软件，是一种重量级过程（也被称作厚方法学），因此特别适用于大型软件团队开发大型项目。 在软件工程领域，与RUP齐名的软件方法还有：.
美国
美利堅合眾國（United States of America，簡稱为 United States、America、The States，縮寫为 U.S.A.、U.S.），通稱美國，是由其下轄50个州、華盛頓哥倫比亞特區、五个自治领土及外岛共同組成的聯邦共和国。美國本土48州和联邦特区位於北美洲中部，東臨大西洋，西臨太平洋，北面是加拿大，南部和墨西哥及墨西哥灣接壤，本土位於溫帶、副熱帶地區。阿拉斯加州位於北美大陸西北方，東部為加拿大，西隔白令海峽和俄羅斯相望；夏威夷州則是太平洋中部的群島。美國在加勒比海和太平洋還擁有多處境外領土和島嶼地區。此外，美國还在全球140多個國家和地區擁有着374個海外軍事基地。 美国拥有982萬平方公里国土面积，位居世界第三（依陆地面積定義为第四大国）；同时拥有接近超过3.3億人口，為世界第三人口大国。因为有着來自世界各地的大量移民，它是世界上民族和文化最多元的國家之一Adams, J.Q.; Strother-Adams, Pearlie (2001).
查看 敏捷软件开发和美国
看板
看板（Billboard），泛指基於宣傳、提醒目的而設置的文字或圖像板，常出現在交通流量較高的地區。使用高耐久性的材質，或具有透明的外框，通常為扁平的方形外觀。.
查看 敏捷软件开发和看板
看板 (软件开发)
“看板”是一种生产管理系统，由1940年代的丰田汽车公司发明。名称源自日文“看板”。在软件开发过程，可以使用用“看板卡”（经常为即时贴）来执行看板。这些卡片不是作为提高生产量的信号，而是用于记载生产数量和标记生产过程。在虚拟看板系统中，会使用虚拟看板卡。在软件开发中,我们采用虚拟看板系统来限制在制品。 由 David J.Anderson.
燃尽图
燃尽图（burn down chart）是用于表示剩余工作量的工作图表，由横轴（X）和纵轴（Y）组成，横轴表示时间，纵轴表示工作量。这种图表可以直观的预测何时工作将全部完成，常用于软件开发中的敏捷软件开发方式，也可以用于其他类型的工作流程监控。.
查看 敏捷软件开发和燃尽图
瀑布模型
Royce提倡重复地使用瀑布模型，以一种迭代的方式。但是，大多数人并不知道这一点，一些人也不相信它能被應用在現實生活中，因為过程很少能够以連續由上而下的方式进行。經常會需要回到前面的阶段，或改變前一阶段的结果。讽刺的是，在Royce 1970年的那篇文章中他提到：这种模型的目的是作为用来说明这种模式有缺陷，而不適用。事实上，软體开发相关文章中对这个名词的大量引用正是对这个广泛流行的软體开发做法的一种评判。 瀑布模型（Waterfall Model）最早強調系統開發應有完整之週期，且必須完整的經歷週期之每一開發階段，並系統化的考量分析與設計的技術、時間與資源之投入等，因此瀑布模型又可以稱為『系統發展生命週期』（System Development Life Cycle, SDLC）。由於該模式強調系統開發過程需有完整的規劃、分析、設計、測試及文件等管理與控制，因此能有效的確保系統品質，它已經成為软體業界大多數軟體開發的標準（Boehm, 1988）。.
查看 敏捷软件开发和瀑布模型
行为驱动开发
行为驱动开发（Behavior-driven development，缩写BDD）是一种敏捷软件开发的技术，它鼓励软件项目中的开发者、QA和非技术人员或商业参与者之间的协作。BDD最初是由Dan North在2003年命名D.North, ，它包括验收测试和客户测试驱动等的极限编程的实践，作为对测试驱动开发的回应。在过去数年里，它得到了很大的发展D.North, comments, 。 2009年，在伦敦发表的“敏捷规格，BDD和极限测试交流”中，Dan North对BDD给出了如下定义： BDD是第二代的、由外及内的、基于拉(pull)的、多方利益相关者的(stakeholder)、多种可扩展的、高自动化的敏捷方法。它描述了一个交互循环，可以具有带有良好定义的输出（即工作中交付的结果）：已测试过的软件。 BDD的重点是通过与利益相关者的讨论取得对预期的软件行为的清醒认识。它通过用自然语言书写非程序员可读的测试用例扩展了测试驱动开发方法。行为驱动开发人员使用混合了领域中统一的语言的母语语言来描述他们的代码的目的。这让开发者得以把精力集中在代码应该怎么写，而不是技术细节上，而且也最大程度的减少了将代码编写者的技术语言与商业客户、用户、利益相关者、项目管理者等的领域语言之间来回翻译的代价。 Dan North创造了首个BDD框架：JBehave；之后是Ruby语言的基于故事的RBehaveD.North, ，后来被纳入了RSpec项目S.Miller, 。他还与大卫赫利姆斯基、Aslak Hellesøy及其他人开发了RSpec，并一起编写了《The RSpec Book: Behaviour Driven Development with RSpec, Cucumber, and Friends》。RSpec中第一个基于故事的框架，后来被主要由Aslak Hellesøy开发的取代。 2008 年，参与了围绕BDD进行的首轮讨论的克里斯马茨，提出了特性注入(Feature Injection)Chris Matts, 的想法，使BDD可以覆盖分析空间并提供从初期的展望到编码和发布的整个软件生命周期过程的改造。.
软件开发
软件开发（Software development）是根据用户要求建造出软件系统或者系统中软件部分的一个产品开发的過程。软件开发是一项包括需求获取、开发规划、需求分析和设计、编程实现、软件测试、版本控制的系统工程。换句话说，软件开发就是一系列最终构建出软件产品的活动。软件开发可能包括研究、新的开发工作、修改、复用、重新设计（再工程）、维护，或者任何最终获得软件产品的其他活动。尤其是在软件开发过程的初始阶段，其中可能会涉及许多的部门，包括市场营销、工程设计、研究与开发以及一般意义上的管理 Joseph M.
查看 敏捷软件开发和软件开发
软件开发过程
在软件工程领域，项目生命周期刻画了一个工程从起始到完成，是如何进行计划、控制和监控的模型。在项目生命周期的早期和後期，软件架构、需求和系统定义是一个问题：.
迭代式开发
迭代式开发也被称作迭代增量式开发或迭代进化式开发，是一种与传统的瀑布式开发相反的软件开发过程，它弥补了传统开发方式中的一些弱点，具有更高的成功率和生产率。 在迭代式开发方法中，整个开发工作被组织为一系列的短小的、固定长度（如3周）的小项目，被称为一系列的迭代。每一次迭代都包括了需求分析、设计、实现与测试。采用这种方法，开发工作可以在需求被完整地确定之前启动，并在一次迭代中完成系统的一部分功能或业务逻辑的开发工作。再通过客户的反馈来细化需求，并开始新一轮的迭代。 迭代和版本的区别，可理解如下：.
查看 敏捷软件开发和迭代式开发
Scrum
Scrum是一种敏捷软件开发的方法學，用於迭代式增量软件开发过程。Scrum在英语是橄榄球运动中列陣爭球的意思。 虽然Scrum是为管理软件开发项目而开发的，它同样可以用于运行软件维护团队，或者作为计划管理方法。Scrum之间的合作称为“Scrum of Scrums”。.
查看 敏捷软件开发和Scrum
极限编程
极限编程（Extreme programming，縮寫為XP），是一种软件工程方法学，是敏捷软件开发中。如同其他敏捷方法学，极限编程和传统方法学的本质不同在于它更强调可适应性而不是可预测性。極限编程的支持者认为软件需求的不断变化是很自然的现象，是软件项目开发中不可避免的、也是应该欣然接受的现象；他们相信，和传统的在项目起始阶段定义好所有需求再费尽心思的控制变化的方法相比，有能力在项目周期的任何阶段去适应变化，将是更加现实更加有效的方法。 極限编程为管理人员和开发人员开出了一剂指导日常实践的良方；这个实践意味着接受并鼓励某些特别的有价值的方法。支持者相信，这些在传统的软件工程中看来是“极端的”实践，将会使开发过程比传统方法更加好的响应用户需求，因此更加敏捷，更好的构建出高质素软件。.
查看 敏捷软件开发和极限编程
探索性測試
探索性測試（Exploratory Testing）是軟體測試方法的一種，它的特點為在進行測試時，同時探索開發更多不同型態的測試方式，以便改善測試流程。當軟體開始測試流程後，一般測試者會使用預先設立好的測試案例來進行程式測試，而探索性測試就是為了彌補傳統的案例測試的缺點而產生。 探索性測試這個詞是由Cem Kaner在1983年提出。他將探索性測試定義為：一種強調個人自由與責任的測試方法，讓獨立的測試者可以藉由不斷的學習來改善測試的規劃與測試的執行，而在測試的過程中也會同時的改善專案達到相輔相成的效果。.
查看 敏捷软件开发和探索性測試
持續整合
持續整合（Continuous integration，縮寫CI）是一種軟體工程流程，是將所有软件工程師對於軟體的工作副本持续整合到共用主線（mainline）的一种举措。该名稱最早由葛來迪·布區（Grady Booch）在他的中提出，不过他並不支持在一天中进行数次整合。之後该举措成為極限編程（extreme programming）的一部份時，其中建議每天應整合超过一次，甚至達到數十次。在测试驱动开发（TDD）的作法中，通常還會搭配自動單元測試。持續整合的提出主要是為解決軟體進行系統整合時面臨的各項問題，極限編程稱這些問題為整合地獄（integration hell）。.
查看 敏捷软件开发和持續整合
测试驱动开发
测试驱动开发（Test-driven development，縮寫為TDD）是一種软件开发过程中的應用方法，由极限编程中倡导，以其倡导先写测试程序，然后编码实现其功能得名。测试驱动开发始于20世纪90年代。测试驱动开发的目的是取得快速反馈并使用“illustrate the main line”方法来构建程序。 测试驱动开发是戴两顶帽子思考的开发方式：先戴上实现功能的帽子，在测试的辅助下，快速实现其功能；再戴上重构的帽子，在测试的保护下，通过去除冗余的代码，提高代码质量。测试驱动着整个开发过程：首先，驱动代码的设计和功能的实现；其后，驱动代码的再设计和重构。.
另见
敏捷軟體開發
- DevOps
- Scrum
- 产品待办列表
- 傑夫·薩瑟蘭
- 持續整合
- 敏捷软件开发
- 极限编程
- 沃德·坎宁安
- 燃尽图
- 用例
- 用户故事
- 看板 (软件开发)
- 站会
- 精益软件开发
- 结对编程
- 肯·施瓦布
- 肯特·貝克
- 马丁·福勒
- 验收测试
軟體專案管理
- 90-90法则
- Phabricator
- Scrum
- V模型
- 上游 (軟體開發)
- 人月神话
- 傑夫·薩瑟蘭
- 形態基準
- 快速應用程式開發
- 敏捷软件开发
- 本質複雜度
- 没有银弹
- 特徵蔓延
- 用例
- 用例图
- 發佈管理
- 统一软件开发过程
- 變更控制
- 软件工厂
- 软件开发
- 迭代式开发
软件工程
软件开发
软件开发哲学
- KISS原则
- Scrum
- Unix哲学
- 一次编写，到处编译
- 大教堂和市集
- 开闭原则
- 形式化方法
- 敏捷软件开发
- 更糟就是更好
- 最佳实践
- 极限编程
- 测试驱动开发
- 瀑布模型
- 看板 (软件开发)
- 精益软件开发
- 行为驱动开发
- 迭代式开发
亦称为 敏捷开发。