如何确定你的团队是否适用敏捷
对从事项目管理的人员来说，敏捷已经成为一场席卷全国的风潮。但敏捷并不是什么新事物，它已经有20多年的历史。是不是所有的团队都可以采用敏捷管理?敏捷是不是一个可以解决所有项目困境的万能灵药?
肯定不是。但敏捷确实是一种非常好的项目管理方法。敏捷团队也确实拥有一些独特的优势。
在敏捷开发出现之前，瀑布模型是采用得最多的开发方式，但是随着软件需求的不断增加和软件规模的不断扩大，瀑布模型逐渐地呈现出了种种弊端，主要有三个方面：
1、研发周期过长，导致研发跟不上业务发展的节奏;
2、研发不能很好地响应需求变化，导致客户满意度低;
3、不能很好地管控风险。
为了解决瀑布模型的弊端，敏捷呼之欲出。
一、什么是敏捷管理?
先从字面上理解，敏捷一词包含了两层含义：
一是“灵活”——检查调整，游刃有余;
二是“快速”——天下武功，唯快不破。
既满足产品开发过程中需求的动态变化，又能通过短迭代管理监控项目的实时效果。究其本质而言，敏捷管理方法很简单：就是“检查与调整”循环。
举个例子：
客人到餐馆来点菜(新项目)
不确定客户想吃什么的时候，通常选好餐厅后会先看看餐厅的菜单(客户往往提不出具体的需求)
根据图文菜单，客人点了十个菜(根据原型和设计稿，基本确定了需求)
后厨开始准备(项目启动)
配菜、炒菜，先上了两盘，让客人尝了尝味道(先提供可用实例给客户用)
客人说还不错，后厨继续准备后面的菜，陆续上菜(不断迭代，不断测试)
上菜过程中，客人突然发现有个菜的味道太淡了，让后厨加了点盐又端上来了(敏捷的好处，可以不断测试和需求变更)
又上了两盘，不够辣，又拿到后厨加了辣(敏捷的坏处，需求没有提前明确，反复迭代，增加了工作量)
到最后两盘时，客人要求换两个菜，还好没炒(迭代的好处，随时接受需求变更)
客人吃完，很满意(基本满足了全部的要求)
二、适合用敏捷的情况
现在让我们回到开头的问题，什么情况下适合用敏捷?
首先什么情况下敏捷不是最佳选择?比如需求基本是确定的。当项目具备可靠的历史记录作为开发基准时，最好采用瀑布式开发方法。
适用敏捷的情况可能比较多，我们列举几个主要的情况，欢迎大家补充：
1、产品需求不确定时
这种情况下，敏捷可以使项目更快启动，并让产品负责人参与到开发过程中。用敏捷的方式，我们就不用在不确定客户是否会满意的情况下花时间记录产品需求，负责人可以在开发新产品功能时，把客户反馈作为开发过程的一部分，以最快的速度将功能呈现，以最小的代价进行试错。
2、敏捷是最佳选择时
因为软件开发过程本身就允许整个系统中的部分功能先进行开发、测试和交付。这就意味着某些特定功能的交付时间会早于其他功能。敏捷则允许开发团队单独测试和部署这些功能，从而确保开发效率。
3、管理层支持时
在传统的开发团队中，项目经理需要提供明确的方向。而在敏捷开发中，敏捷教练则会鼓励开发团队提出最适合产品开发和产品负责人的方案。管理层必须赋予团队必要的自由，要提供能让团队快速成长的指导和方向，而不是控制团队的每一步行动。
敏捷可以为企业带来文化和期望层面的转变，因为它鼓励团队赋权，让团队负责做出决策并承担相应的风险。敏捷为项目经理提供了更多的选择，帮助其解决项目进度中的各类问题，让他们有可能更好地管理项目。
4、团队成员拥有从失败中学习的意愿时
快速试错，更快速地从失败中学习。传统的开发方式试图在项目启动前描述所有的需求，这么做会浪费大量时间，尤其是在开发新产品时。所以一旦有了想法就应该立刻进行开发，即使当前的产品并非产品负责人想要的。这样做的目的是要通过不断的反馈来调整产品方向并继续开发。
肯定不是。但敏捷确实是一种非常好的项目管理方法。敏捷团队也确实拥有一些独特的优势。
在敏捷开发出现之前，瀑布模型是采用得最多的开发方式，但是随着软件需求的不断增加和软件规模的不断扩大，瀑布模型逐渐地呈现出了种种弊端，主要有三个方面：
1、研发周期过长，导致研发跟不上业务发展的节奏;
2、研发不能很好地响应需求变化，导致客户满意度低;
3、不能很好地管控风险。
为了解决瀑布模型的弊端，敏捷呼之欲出。
一、什么是敏捷管理?
先从字面上理解，敏捷一词包含了两层含义：
一是“灵活”——检查调整，游刃有余;
二是“快速”——天下武功，唯快不破。
既满足产品开发过程中需求的动态变化，又能通过短迭代管理监控项目的实时效果。究其本质而言，敏捷管理方法很简单：就是“检查与调整”循环。
举个例子：
客人到餐馆来点菜(新项目)
不确定客户想吃什么的时候，通常选好餐厅后会先看看餐厅的菜单(客户往往提不出具体的需求)
根据图文菜单，客人点了十个菜(根据原型和设计稿，基本确定了需求)
后厨开始准备(项目启动)
配菜、炒菜，先上了两盘，让客人尝了尝味道(先提供可用实例给客户用)
客人说还不错，后厨继续准备后面的菜，陆续上菜(不断迭代，不断测试)
上菜过程中，客人突然发现有个菜的味道太淡了，让后厨加了点盐又端上来了(敏捷的好处，可以不断测试和需求变更)
又上了两盘，不够辣，又拿到后厨加了辣(敏捷的坏处，需求没有提前明确，反复迭代，增加了工作量)
到最后两盘时，客人要求换两个菜，还好没炒(迭代的好处，随时接受需求变更)
客人吃完，很满意(基本满足了全部的要求)
二、适合用敏捷的情况
现在让我们回到开头的问题，什么情况下适合用敏捷?
首先什么情况下敏捷不是最佳选择?比如需求基本是确定的。当项目具备可靠的历史记录作为开发基准时，最好采用瀑布式开发方法。
适用敏捷的情况可能比较多，我们列举几个主要的情况，欢迎大家补充：
1、产品需求不确定时
这种情况下，敏捷可以使项目更快启动，并让产品负责人参与到开发过程中。用敏捷的方式，我们就不用在不确定客户是否会满意的情况下花时间记录产品需求，负责人可以在开发新产品功能时，把客户反馈作为开发过程的一部分，以最快的速度将功能呈现，以最小的代价进行试错。
2、敏捷是最佳选择时
因为软件开发过程本身就允许整个系统中的部分功能先进行开发、测试和交付。这就意味着某些特定功能的交付时间会早于其他功能。敏捷则允许开发团队单独测试和部署这些功能，从而确保开发效率。
3、管理层支持时
在传统的开发团队中，项目经理需要提供明确的方向。而在敏捷开发中，敏捷教练则会鼓励开发团队提出最适合产品开发和产品负责人的方案。管理层必须赋予团队必要的自由，要提供能让团队快速成长的指导和方向，而不是控制团队的每一步行动。
敏捷可以为企业带来文化和期望层面的转变，因为它鼓励团队赋权，让团队负责做出决策并承担相应的风险。敏捷为项目经理提供了更多的选择，帮助其解决项目进度中的各类问题，让他们有可能更好地管理项目。
4、团队成员拥有从失败中学习的意愿时
快速试错，更快速地从失败中学习。传统的开发方式试图在项目启动前描述所有的需求，这么做会浪费大量时间，尤其是在开发新产品时。所以一旦有了想法就应该立刻进行开发，即使当前的产品并非产品负责人想要的。这样做的目的是要通过不断的反馈来调整产品方向并继续开发。
欢迎供稿“职来职往®”栏目，投稿邮箱：support@jsdfl.cn
上一条：
没有了
下一条：
店长带新员工四步法，有效又省力
