简单概念内容网上很多，比如 https://www.cnblogs.com/qixuejia/p/5863216.html

此篇内容仅仅是点到即止，不是总结也不做深入阐述。

出发点

如果只是照搬概念和书上的内容，没有以敏捷研发模式引领出成功案例，不建议团队轻易尝试

我想，这个答案会是出奇的一致——“快”，为了占领市场份额，快速出活、快速出结果，。
但为什么能快，怎样才能快，每个人的答案一定是不完全一样，甚至完全不一样，又或者完全不清楚。

到底依赖什么(必须的要求是什么)

从软件工程的角度来看，与其他工业生产极具不同的是其“没有标准”，不存在所谓的标准化作业(SOP)或模板。任何一个看起来相近或的产品或功能包装，对于不同的团队，技术上的解决方案和方式往往不同。

在我经历或主导的增量型/迭代型研发模式中，真正要做到敏捷研发能力，有不少基础设施是必须的，而核心本质是“技术驱动”，通过技术创新以解决持续需求迭代：

  • 组织(人)本身的成熟度

    • 岗位细分
    • 有高端能力或综合能力强的角色
    • 高协作性(如结对编程、持续相互补漏等等)
    • 共识目标
    • 一定比例的冗员(健康的比例在25%-30%，无冗员时，团队持续作战难以为继)
    • 团队各角色对要实施的业务，有较快或直接的共识或理解(或者说不存在较深的业务壁垒)

  • 工具(基础技术建设)的成熟度

    • DevOPS的基础落地。比如CI/CD、自动化测试、前后端业务监控、BI等
      • 单元测试的落地与覆盖度
      • 自动化测试
    • 阶段性的持续性的模块化重构
    • 理想模型中，对应feature分支的独立测试环境(虚拟化)
    • 文档沉淀

  • 其他

    • 控制好需求(story)的流量与流速
    • 对应 Task 有明确的冲刺 sprint 时间. 即明确的 KO (kick-off) 和 Release Time
    • 有相应的且是可靠的需求变更机制

优劣

软件技术中并没有银弹，所以在采取某种方案前，辨证的分析优劣得失是很有必要的。 在我看来，大概如此：

优势

  • 快。即快速响应市场/客户、快速体验、快速验证产品方向

劣势

  • 对组织(人)的要求很高，软硬都有要求
  • 管理不当时，对个体增长可能有限(很容易是螺丝钉)，甚至失去成就感或被当成了工具人
  • 管理不当时，产品角色很容易坠入“甲方”误区，也就是与技术团队脱轨
  • 文档参考性可能相对偏弱(比如逻辑可能缺失或不严谨)
  • 可能在执行过程中出现目标模糊
  • 下游压力大于上游压力
  • 对服务资源和代码管理要求很高(如果无法独立隔离，只能做特性混合测试，容易反范式最终成为小瀑布模式)
  • 受限于国内特定文化等诸多管理情况，无法抵御上级压力带来的整个冲击——当发生时，很容易导致整个敏捷变成口号

额外的影响

  • 在敏捷研发模式中，整体的工作方式类似于管道，在前期的需求描述、变更、任务穿插(如重构、任务加入或取消)、产出制品(如需求不清晰、线上问题)等，都是需要可容忍的(所以通常不适用于如金融、2B业务或非自有组织客户等领域业务)
  • 对于实施的组织来说，其实并不关心资源(如人力情况)而是聚焦于目标推进与落地

研发模式的最佳实践

研发模式仅从理论来看，好像都很优雅，各有各论证。从个人在国内互联网十多年的有限经历来看，不论是做项目还是做软件产品，研发模式的最佳实践是以“敏捷+瀑布”进行增量迭代