敏捷软件开发
收录了 敏捷软件开发 频道下的 50 篇内容
由外而内看敏捷软件开发（上）——从业务视角看敏捷
敏捷被赋予了太多的含义，甚至承载了利益，有时还让人迷惑。本文并不试图去定义敏捷。但，我们会分别从外部（业务视角）和内部（开发模式及组织视角）观察正在发生的敏捷，并提交观察报告。
由外而内看敏捷软件开发 (二) —— 从开发模式看敏捷
本文的第一篇阐述了敏捷软件开发的业务目标。业务成功是最终目标，它需要有效开发模式的保障；开发模式的实施又离不开团队组织和技术实践的支撑；最后，通过持续改进、系统优化，获得持久的成功。这一层次关系中，外层是内层的目标，内层为外层提供支持。本篇将探讨敏捷软件的开发模式。
2010 敏捷软件开发现状调查
在过去的4年中，VersionOne对敏捷社区进行了调查，以深入了解“敏捷软件开发的状况”。在今年的2010敏捷大会上，第五次年度调查揭开了序幕。这项调查试图“衡量敏捷开发实践的价值”，比如方法论的采用情况。你可以在AgileDevSurvey.com上参与调查。
工具和敏捷软件开发之间的关系
通过使用恰当的工具，可以提升敏捷软件开发的效率。Kent Beck最近发表的一篇文章中提到了工具和敏捷软件开发之间的关系。
博弈论和敏捷软件开发
博弈论最初起源于经济学，用来分析企业、市场、消费者等的行为。从那之后，其范围和运用已经扩展到了多个领域，如政治学、社会学、心理学和敏捷软件开发。
2011 年度敏捷软件开发调研结果发布
最近，VersionOne揭晓了2011年度敏捷软件开发调研结果，再一次向大家展示了敏捷应用和发展趋势的第一手资料。
和我们一起结对：交互式的敏捷软件开发视频示例
大多数程序员都熟知，学习编程技术最好的（或唯一的？）途径就是通过示例；尤其是通过观察别人怎么做。Antony Marcano和Andy Palmer的“和我们一起结对”是一个学习的好去处。
供敏捷软件开发使用的合同
虽然《敏捷宣言》中说“客户协作重于合同谈判”，合同仍然是很多开发人员和公司要面临的现实。Peter Stevens分析了10种不同类型的开发合同，并解释了每种类型对于敏捷项目的适合程度。他发现：相比固定价格合同与按时间和材料制定的合同来说，有一些合同似乎更适合敏捷项目。
将看板应用于软件开发：从敏捷到精益
许多团队仅对软件价值流（software value stream）的一部分做了优化，但是Kenji Hiranabe向我们展示了如何将精益生产中的看板跟踪系统嫁接到软件开发中，以便与更多的组织结构进行沟通。
什么是敏捷软件测试
在与不少测试从业人员讨论到敏捷的时候，被问得最多的大约是两个问题：“到底什么是敏捷软件测试？”，“敏捷软件开发还需要测试工程师吗？”。鉴于这两个问题的意义，在本敏捷测试专栏的第一篇文章中，段念先生尝试从自己的实践出发，尽可能清楚的回答这两个问题。
敏捷宣言的发起者如何完成从技术领导者到文化变革领袖的转变？
以深入采访17名敏捷宣言发起者中的12位为依据，我们将描述技术驱动的力量怎么会使得敏捷方法引起文化的变革。这则讯息说明了在采用敏捷软件开发的过程中，应该强调什么样的人性面及方法、实践及工具。
现代化敏捷简介
现代化敏捷的四项指导方针定义了一种通过更简单、更安全、更快速的方式获得出色成果的方法：塑造更出色的人员，让安全成为先决条件，更快速的尝试和学习，以及持续不断地提供价值。这些方针已被融合到我们热爱的产品和服务中。现代化敏捷并不定义需要我们遵循的角色、仪式或实践，我们可以自行选择这些方针的实现方式。
书评：敏捷模式──指向成功的路标
Ryan Cooper对Amr Elssamadisy的新书发表了评价，并认为书中提供了一种为实施敏捷量身定做的框架。本书并没有给出一种人人可用的敏捷方法，而是为读者提供一些模式和工具，用以找出哪些敏捷实践可以最有效地达到该组织机构的特定目标。
敏捷战壕里的茶话会，与 David J Bland、Brad Murphy、Peter Saddington 的小聚
周五下午的一场愉快谈话；几位知名敏捷实践者畅谈方法论世界的现状和未来趋势，展望理论发展对实践的影响。坐舒服点儿，来把瓜子，好好欣赏这些位最尖锐的敏捷教练们的唇枪舌剑吧。
20 年起义，敏捷已死，敏捷万岁
开发者，你们真的享受到敏捷开发的好处了吗？
度量和改进软件开发的工作效率
《改进软件开发工作效率》这本书为敏捷软件开发的实施提供量化支持，其中包括实践、模型和案例研究。本次采访针对作者 Randall Jensen，谈到工作效率的度量和改进、敏捷对工作效率的贡献、结对编程和团队带来的好处、软件维护中的知识留存，以及沟通的四条告诫。
到底谁应该对软件开发的质量负责？
本文讨论了什么是质量，定义质量的五种方法，卓越的质量、基于价值的质量、基于用户的质量、基于产品的质量、基于制造的质量，并讨论了整个团队都应该对质量负责。许多团队都在质量和时间之间做权衡，如果你们一开始认为速度最重要，不关注质量，那么就很有可能长期进行大量的返工，会出现很多不可维护的代码，质量将更进一步地下降。
企业中的敏捷运维
最近有很多关于敏捷运维的消息。 包括很不错的演讲、文章，还有一些激烈的讨论。 它被称作是“创业公司的秘制调味酱”。 对于我们这些并非处在创业公司或者Web 2.0公司中的人来说，它的意义何在呢？ 我们是否可以让敏捷运维在已经创建的大型企业中发挥作用呢？
回顾会议指引观念转变
这篇论文讲述了我们如何在一家公司的特定项目中指导敏捷软件开发过程的，专注于引入采用“一小时回顾会议”的机制指导团队成员认识到必要的转变并让他们自己引领这种转变。从我们的观点来看，团队成员开始自己主持回顾会议的阶段就是成功的标志。
京公网安备 11010502039052号 | 产品资质
