敏捷浅谈

        “敏捷（Agile），即创造和响应变化的能力。”国际敏捷联盟（The Agile Alliance）是这样定义“敏捷”的。
在这个 “VUCA”时代，任何组织不仅谋求当下的生存力和竞争力，而且它们也意识到唯有拥抱变化才是永恒的主题，因此更希望自己具有不断适应难以预测变化的能力。在面对不确定性时，我们往往会尝试很多种可能有效的方法，通过收集、分析和学习，做出相对应的调整，如此反复。如何能在更短的周期内完成更高的投入产出比，则是敏捷所关心的问题。
        从上世纪90年代开始，人们试图以敏捷的方式开展工作。在软件开发领域，传统的软件构建方式逐渐被摒弃，在实践中先后诞生了一些颇受关注的轻量级的软件开发方法。2001年，17位软件开发人员聚集在犹他州的Snowbird，讨论他们各自领域对于工作的想法以及各种软件开发方法，寻找其中的共性，最终提出了著名的“敏捷宣言”以及12项原则，正式宣告了敏捷开发运动的开始。
 

       对于传统的软件开发方法的一个非常著名的模型是瀑布模型，瀑布模型强调的是过程，阶段和检验控制，也就是说再每一个阶段过程中，都要有一个检验控制，来判断这个阶段是否完成了或达到完成的标准，才能进入下一阶段。这就造成了，当人被人为的划分到不同阶段从事不同的工作的时候，前一阶段的工作没有完成，他是不能进入下一阶段的。而敏捷特别具有应对快速变化需求的软件开发能力，他特别注重软件开发中人的作用。

      在传统软件开发中都会发现一个问题，当我们参加一个阶段性的评审，相关的干系人才会到评审现场对完成的工作提出评审，但在开发过程中，评审相关关系人并不会特别参与和重视软件团队的工作，只有在这个评审点上才会关注。但敏捷会强调开发团队、业务人员和干系人是否紧密协作，这个紧密协作是否能在一个短的时间周期进行一个快速的检验或反馈，他提倡面对面的沟通和快速的信息流动和共享，通过频繁交付新的需求增量来支撑业务的快速变化和发展。这里注意，频繁交付新的需求增量，这实际上为业务人员和干系人提供了一个检验和验证的一个工具，也就是说，我们并不是通过书面或者介绍告诉业务是不是ok的，而是强调一个可工作的软件发布上线后，业务人员是否对功能的认可。

       而敏捷开发模式则提供了一种新的模式，即小步快走，不断调整，快速迭代!你需求不明朗没关系，我们先做一小丢丢，对了就继续不对也不至于说损失很大，调整方向也来得及，通过这种模式不断纠正最后不断趋近客户最终想要的东西。
团队成员之间的信任和开放式的沟通、协作、适应是敏捷的核心，而在团队中形成产品质量、可用性和完整性等方面的统一标准，持续优化工作规则和流程则是自组织的体现。敏捷倡导者和实践者坚信，自组织是敏捷开发团队发挥最佳的灵活性、创造力和生产力以应对变化的能力源泉。
适用敏捷的项目、团队
         一些研究数据表明，不是所有敏捷开发项目都能取得成功，也并非所有瀑布模式的项目一定会失败。理智的软件开发团队应在对产品、项目和团队特性分析的基础上，选取更合适的开发模式。
任何项目都会受到三类条件的约束：
•    范围：即项目的目标、任务以及相关方的期望是什么；
•    时间：即规定项目需要在多长时间内完成；
•    资源：包括项目的经济成本和人力资源。
        项目管理就是在三者之间寻找一个相对平衡的点，以便让项目尽可能实现预期的进展和结果。在判断采取哪种开发模式时，我们可以自问：是用更长的时间，甚至冒着延迟的风险，交付一个足够好的产品？还是尽早推出一个可用的产品，通过市场反馈和高频迭代让它持续变好？
瀑布模式的逻辑是将项目范围，也就是客户提出的产品需求作为固定条件，基于此预估软件开发项目所需要的时间和资源，形成项目计划。假如某开发团队在日程表走过一半的时候，发现几乎无法在计划的发布日期前完成剩下的工作内容，要么他们不得不将发布日期推迟，要么向项目增派更多人力 —— 显然这样将会增加项目成本，还不一定确保项目能按新调整的计划完成。为了避免这种窘境，采用瀑布模式的软件开发项目往往没具备以下特征：
•    在开发启动前，项目的所有需求都非常明确、清晰，不会在开发过程中变更，并以此作为里程碑或最终交付的验收标准；
•    开发团队做过类似的产品，对于需求足够熟悉和有把握。
        对敏捷开发而言，“大而全”的产品被拆分成若干个小迭代，如果将每次迭代看作一个项目，那么项目范围中最为关键的是以交付一个可面向市场的、可工作的产品作为目标基调，先将迭代周期长度或产品发布的时间节点（时间条件）、开发团队产能（资源条件）确定下来，再反过来考虑在这些条件下，按最需要实现的需求或功能的优先级排序，尽力能将产品做到什么程度。相比瀑布模式，敏捷开发更适合这样的项目：
•    对于开发团队来说是一个新的挑战；
•    产品需求复杂或不确定；
•    相关方对上市时间的要求大于对产品完善程度的要求。
那么，敏捷开发适合什么样的团队呢？如何确定敏捷是否适合你的团队？
        在心态层面，尽管敏捷原则性的内容易于理解，但由于缺少特别标准、普适的实践方法，刚开始接受敏捷的团队需要有足够的勇气和耐心试错、磨合，从实践中总结经验以适应敏捷的开发风格。在技能层面，敏捷团队希望它的成员都是多面手，这样在开发过程中的任何时刻，每个人都可在不同的任务上以不同角色贡献自己的力量，从而确保团队能够高效释放产能，在有限的迭代周期内完成更多任务。在协作层面，敏捷团队推崇开放和相互信任的关系，乐于保持高频、双向、充分的沟通互动，让产品用户及其他相关方参与完整的开发旅程。
        除了团队本身以外，当我们谈论敏捷时，也需要关注敏捷开发团队所在的组织能否为他们的敏捷实践提供一个有力的支持环境，这就需要组织高层对于敏捷价值观有高度认同、对于敏捷基本理念和概念有正确理解，并给予敏捷开发团队足够的信任、自主权和精进空间。