文/明道团队
什么是敏捷？
敏捷开发是一种基于增量、迭代的开发方式。敏捷方法具有开放性的特点，它们并不会在一开始就做深入的产品规划，而是鼓励用户持续性进行产品体验反馈，再根据用户需求来进行调整。
跨职能团队将会根据产品需求优先级在一段时间内进行产品迭代，而进行迭代的最终目的是研发出潜在可发行的软件版本。
敏捷方法中，项目负责人会鼓励项目成员与利益相关方当面沟通、共同协作，让产品和客户需求与公司目标保持一致。
敏捷是指任何与敏捷宣言（Agile Manifesto）的理念相一致的过程。2001年2月，17位软件研发人员在犹他州开会讨论了轻量级开发方法。他们发表了《敏捷软件开发宣言》（Manifesto for Agile Software Development），其中包括四项价值观和12项原则。敏捷宣言与传统的项目管理知识体系（PMBOK）指南和标准形成了鲜明对比。 
敏捷方法论的12项原则
敏捷宣言列出了12项原则来指导团队如何执行敏捷。这些原则是：
- 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
- 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
- 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
- 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
- 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
- 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
- 可工作的软件是进度的首要度量标准
- 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
- 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
- 以简洁为本，它是极力减少不必要工作量的艺术。
- 最好的架构、需求和设计出自自组织团队。
- 团队定期地反思如何能提高成效，并依此调整自身的举止表现。
敏捷的优势
敏捷这一理念起源于20世纪90年代，由众多轻量级软件开发方法演化而来，它更侧重于灵活性、持续改进和速度。敏捷开发的出现让不喜欢线性瀑布式开发的项目经理有了新的选择。
敏捷有这几大优势：
- 拥抱改变：通过缩短规划周期，在项目期间能够灵活的做出调整变更。因此敏捷总会有机会来重新整理产品客户需求，让团队在几周内调整项目方向。
- 无需非常清楚最终目标：敏捷对于没有明确定义最终目标的项目是非常有利的。随着项目推进，目标将会变得更加清晰，开发过程可以很容易地适应不断变化的需求。
- 更快速、高质量的交付：将项目分解为不同的迭代（可管理单元），让团队能够专注于高质量的开发、测试和协作的环节。每次在迭代中的测试都将意味着我们能够更快的发现问题和解决问题。并且我们可以通过高频的迭代交付高质量的软件。
- 注重团队意识：敏捷非常强调当面沟通和高频沟通的重要性。团队成员在一起工作中相互了解、各司其职。
- 听取客户的意见：客户在项目进行中将会看到很多潜在可交付的软件版本，听取他们的想法，从中获取对产品迭代有利的意见。同时对他们而言，通过与项目团队的合作可以增加归属感。
- 持续性迭代与改进：敏捷开发鼓励用户和团队成员在整个项目中不断提供产品体验反馈，从中吸取经验，为后续版本的迭代提供基础。
敏捷的缺点
通常我们认为敏捷的灵活性在整个项目中起积极作用，但它也互有利弊。产品交期难以确定，可视化文档可能被忽视，甚至连最终交付的产品与初衷大相径庭。
敏捷的缺点如下：
- 项目规划不太具体：有时很难确定软件的交期。虽然敏捷是基于时间节点来进行交付，但项目经理会不断调整任务优先级，导致原本该交付项目跳票。同时，项目中任何新增用户需求都会花费额外的时间，从而延长整个项目进度。
- 对项目成员的能力要求高：敏捷团队通常很小，所以需要团队成员熟练掌握各个领域的技能。同时，他们还得对选用的敏捷方法无异议。
- 研发阶段时间压力大：团队投入全力进行研发是敏捷最成功的环节。在整个敏捷中需要项目成员积极参与、相互协作，但比传统的开发方法更耗时。这也意味着需要研发团队明确给出各阶段时间点并且准时交付。
- 文档可能会被忽视：敏捷宣言提倡用软件替代各类纸质文档来进行管理整个过程，因此团队成员可能会不再重视文档。虽然纸质文档本身并不会影响项目是否成功，但团队还是得在文档和用软件进行讨论之间找到平衡点。
- 最终产品可能与初衷大相径庭：最初的敏捷项目可能没有一个明确的计划，因此最终产品看起来可能与最初的目标完全不同。由于敏捷非常灵活，所以可以根据不断变化的客户反馈来添加新的迭代，这可能会导致最终的交付成果大不相同。
敏捷开发周期
敏捷开发周期中包含下面几个阶段，值得注意的是，单独某个阶段尽量不要重复；同时整个周期中可能同时进行多个阶段，这样在保证灵活性的同时在不断推进开发进度。
- 产品规划：一旦某个想法被认为可行，项目团队就会一起努力确定其功能。这个阶段的目标是将想法细分成更小的工作（产品特性），然后将每个特性划分优先级，并将其分配给不同的迭代版本。
- 需求分析：这个阶段需要和产品经理、利益相关者和用户进行多次会议讨论来确定业务需求。研发团队需要收集信息（比如谁将使用该产品以及他们将如何使用该产品等）。这些要求必须详细、可量化，同时具有相关性。
- 产品设计：根据前一阶段确定的产品需求而进行研发系统和设计软件。团队需要考虑产品或解决方案的雏形。而测试团队需要提出下一阶段的测试规划。
- 产品研发：此阶段主要研发和测试优先级高的产品特性，并准备安排迭代（遵循迭代和增量开发方法[IID]）。由于没有可交付的产品特性，因此研发阶段从最小模型开始迭代，这次迭代为之后研发提供基础。
- 产品测试：代码开发完成后开始进行单元测试、集成测试、系统测试和验收测试，以确保产品能够满足客户需求并匹配用户故事。
- 部署产品：测试完成后，我们可以将产品提交给客户。但是部署产品并不代表项目已经结束，客户在使用产品中遇到的新问题依旧需要项目团队去解决。
实施敏捷的方法
敏捷仅是一个框架，在具体执行敏捷开发时，我们会用到不同类型的敏捷方法：
- 极限编程（XP）：简称XP，旨在根据客户需求不断提高产品质量和团队响应能力。XP的原则包括反馈、简易假设和拥抱改变。
- 特性驱动开发（FDD）：这种开发形式会研究行业优秀案例并将研究成果——行业需求的产品特性加入到迭代和增量中。FDD的五项基础流程有：建立整体模型、构建产品特性列表、按产品特性规划、按产品特性设计、按产品特性构建。
- 自适应系统开发（ASD）：自适应系统开发认为项目应该始终处于适应状态。ASD有三个重复周期：推测、协作和学习。
- 动态系统开发方法（DSDM）：DSDM的项目交付框架适用于软件研发和非IT解决方案。它解决了IT项目中的常见问题，如预算超支、项目超期以及用户参与度低。DSDM的八项原则是：专注于业务需求、按时交付、精诚协作、不妥协产品质量、从企业基础逐步构建、研发迭代、持续沟通和展示控制。
- 精益软件开发（LSD）：精益软件开发采用精益生产和精益IT原则，并将其应用到软件开发中。LSD的七项原则有：消除浪费、持续学习、尽晚决定、尽快交付、赋予团队权力、建立诚信、统筹全局。
- 看板：日语中“视觉标志”或“卡片”的代名词，敏捷开发的可视化框架。看板将持续性的推进系统小更新。其原则包括：工作流可视化、控制流程中的工作量、管理和改进工作流、明确目的、持续改进。
- Crystal Clear：Crystal Clear是Crystal系列方法的一种。适用于六到八名研发人员的团队，比起关注项目进度和工件，它更聚焦于人的发展。执行Crystal Clear的三项原则：经常向用户提供可用的迭代、进行反思性改进、通过渗透式沟通来促进合作。
- Scrum：Scrum是实施敏捷的最流行方式之一。这是遵循一套不变的角色、职责和会议，病反复进行软件迭代的模型。Sprints通常持续一到两周，可以帮助团队定期进行软件迭代。
敏捷中如何进行项目预算
如果没有前期深入的规划，许多项目经理都不确定如何来计算敏捷项目的成本和预算。
无论我们使用哪种方法开展项目，在项目开始之前估算成本都会是一个挑战。尽管如此，敏捷与其他方法相比，有其独特的估算公式，那就是通过结合项目总时间和总成本。
首先，我们画一张燃尽图，用燃尽率来估算剩余多少冲刺阶段(sprints)，以及项目何时结束。然后，根据成员的每小时工资来计算团队的成本。将每个人的费用乘以每周工作小时数，然后将其乘以冲刺周数。一旦估算出团队的初始预算，就可以增加其他成本，例如技术、旅行或设备。
您也可以将每个用户故事分解为任务。一旦您了解了完成每项任务需要的小时数后，就可以估算出项目预算。
最后，您可以使用计划扑克来估计开发目标所需的工作量。计划扑克是一种基于共识的、游戏化的技术，用于评估开发目标的工作量。每个团队成员通过在桌面上玩牌来进行估算（这些卡片的数字面朝下），而无需大声说出来。然后展示卡片并与整个团队一起讨论估算。
敏捷和配对编程
结对编程是极限编程（XP）落地的一种方式。会让两位研发人员共用一个工作台（其中包括共享一个屏幕、键盘和鼠标）。这项技术的目的是鼓励更好的沟通、发现问题和确认解决方案。敏捷项目中经常使用结对来快速交付高质量的产品，但这是否有必要呢？
答案取决于研发成员、公司文化和结对目标。对于一些项目和程序员来说，配对可能会提高工作项目。但这并不意味着它适合所有的项目。我们最好在执行前先来做一次尝试，看项目组是否真的合适。
敏捷如何解决软件需求
敏捷帮助项目团队快速洞悉客户最主要的需求。通过持续的当面沟通和反馈，让项目团队和利益相关者就能够快速理解项目并发现优先级高的需求。
敏捷团队用产品需求列表（backlogs）来管理用户故事和其他需求。开始迭代前，研发团队将会确定下次交付的产品会包含哪些功能。这种协作方式确保了优先级高的需求能得到优先处理。即使后期频繁的出现产品需求变化，我们也能及时做更新。
敏捷能够用于非IT的项目？
敏捷虽然一般来说是为软件开发而创建的，但它依然可以被用于其他许多项目和行业。
当我们用敏捷开发落地其他项目和行业时，需要明确一点，敏捷开发是源于精益生产和组织学习的原则。而这两项原则并不是一定得基于软件才能落实的，同理敏捷也一样。而敏捷中用的方法，比如每日站会和可视化管理，对于任何行业都非常容易上手。
目前用敏捷方法落地非IT的案例并不多，但也不至于完全没有。例如，孤独星球的合伙律师凯特·沙利文用敏捷方法，使用白板和看板、站会、按优先级服务、周期性迭代和定期回顾，改变了其法律事务的服务交付流程。
当根据需求找到合适的方法，我想我们一定有机会在非IT项目中用上敏捷方法。可以先尝试用白板和看板、每日站会或周会，看看团队的反馈如何。
如何开始着手使用敏捷
我们可以先从每日站会来快速切入来实施敏捷。每日站会由于很容易融入你所用过的其他项目管理方法中（甚至包括瀑布开发），所以项目成员不需要经过特意的培训或是知识储备，大家每天大概花上10分钟左右时间，让每个人讨论下近两天工作进度和遇到的问题就可以。
如果你希望一次性完全切换到敏捷，我们可能得先了解为什么研发团队和整个项目组需要做出这种调整和改变。比如，有哪些任务是研发团队认为该做和不该做的，他们想要改善什么等等。然后再进行敏捷评估，全面了解所用的人员、技能和技术。
在开始敏捷时，对于方法的选择上并没有完全的对错，因为敏捷的本质就是灵活的。所以我们只要选择适合您和团队的方法就好了。
文章来源：smartsheet
由明道团队编译、整理
您可以点击此处【订阅】获取更多敏捷开发的资料，我们将定期向您邮箱推送相关文章、培训资料和案例。
