【分享】关于看板和Scrum究竟选哪个，下面是比较中性的理解
Both Kanban and Scrum are designed to help teams build better products with fewer obstacles along the way. However, a lot of teams still question whether they should use Kanban or Scrum in order to deliver outstanding value to their customers. But the reality is that you shouldn’t choose between the two; rather, you should discover which practices work best for your team and flex the system accordingly.
Regardless of whether you use Kanban, Scrum or anything in between, there are a few basic management practices that you need to adopt to be able to achieve sustainable predictability.
Both Kanban and Scrum are designed to help teams build better products with fewer obstacles along the way. However, a lot of teams still question whether they should use Kanban or Scrum in order to deliver outstanding value to their customers. But the reality is that you shouldn’t choose between the two; rather, you should discover which practices work best for your team and flex the system accordingly.
Regardless of whether you use Kanban, Scrum or anything in between, there are a few basic management practices that you need to adopt to be able to achieve sustainable predictability.
#敏捷转型#
问：从“抵触”到“接受”，如何正确引导团队进行敏捷转型？
答：敏捷这个概念已经提出很多年了。敏捷对开发团队的角色做了划分，并且对各个角色的能力作出了高要求，另外对工作流程，迭代周期都提出了理想定义，这实际上是对组织架构的一个颠覆。
国内的很多互联网大企业在敏捷转型上已经取得了不错的应用效果，但很多传统行业的企业在转型过程中，还是有着重重阻碍。
1. 传统企业内部推进敏捷转型落地的过程中，都存在哪些问题和阻力？
首先在企业内部，无论做任何变革，都需要有一个过程。不同的人，针对同样一件事，由于个人立场不同，得出的结论也可能不一样。因此在敏捷导入过程中，也存在这样的问题。在团队初始使用敏捷的阶段，最大的问题就是团队成员的抵触情绪。抵触可以有多种形式，主动的或被动的，公开的或隐蔽的。
主动抵抗可能仅限于少数脾气暴躁但与世隔绝的人，它可能会蔓延到更多的人。“主动抵制的人可能会试图破坏敏捷转型的过程，他们会四处乱说敏捷开发，试图说服人们放弃它。”随着不满的蔓延，它会削弱士气，因此隔离抗议者并让尝试他们加入转型是很重要的。
但也不用因此产生过多焦虑，因为实际上决定开展敏捷转型后，公开抵制并不常见。更多会遇到的情况其实是被动抵抗。“被动的抵抗者假装顺从这个过程，站起来并口头上表达支持，但他们的态度是：“谁在乎？”。
因此在敏捷的导入过程中，如何引导团队成员去接受，去积极地实践敏捷是关键所在（图1）。
2. 从敏捷能解决的提升开发效能的方面上入手，对症下药
团队效能的提升涉及到管理流程、技术架构、工具自动化等方方面面的因素，而敏捷关注于需求与开发之间的管理流程问题。基于不同的团队现状，敏捷也有不同的表现形式，这里就不作赘述。
但总体来说，企业做敏捷转型，仍然有一定的流程可以遵循（图2）。
如果企业完全是从原来瀑布开发模式做转型，那么首先在团队层面需要引入看板方式，让团队能够很好的可视化现有流程。只有可视化现有流程，才能识别并优化团队的瓶颈问题。
其次，当团队能够熟练使用看板以后，就可以把团队的组织流程转变成Scrum。Scrum比起Kanban模式的优点在于对团队的动作做了更多的规范化，这样更有利于团队建立统一的开发节奏。
第三，当团队的组织流程运行顺畅以后，就可以在技术架构层面引入更多的实践，例如：优化团队的开发框架、修复以前的技术债等。
最后，当团队级别的效能提升到一定阶段以后，就可以把敏捷相关的实践拓展到整个IT部门，并且推进业务部门一起来做尝试。这块就涉及到规模化敏捷推广和业务敏捷的相关内容了，后续再详细展开谈谈，记得持续关注我们喔~
问：从“抵触”到“接受”，如何正确引导团队进行敏捷转型？
答：敏捷这个概念已经提出很多年了。敏捷对开发团队的角色做了划分，并且对各个角色的能力作出了高要求，另外对工作流程，迭代周期都提出了理想定义，这实际上是对组织架构的一个颠覆。
国内的很多互联网大企业在敏捷转型上已经取得了不错的应用效果，但很多传统行业的企业在转型过程中，还是有着重重阻碍。
1. 传统企业内部推进敏捷转型落地的过程中，都存在哪些问题和阻力？
首先在企业内部，无论做任何变革，都需要有一个过程。不同的人，针对同样一件事，由于个人立场不同，得出的结论也可能不一样。因此在敏捷导入过程中，也存在这样的问题。在团队初始使用敏捷的阶段，最大的问题就是团队成员的抵触情绪。抵触可以有多种形式，主动的或被动的，公开的或隐蔽的。
主动抵抗可能仅限于少数脾气暴躁但与世隔绝的人，它可能会蔓延到更多的人。“主动抵制的人可能会试图破坏敏捷转型的过程，他们会四处乱说敏捷开发，试图说服人们放弃它。”随着不满的蔓延，它会削弱士气，因此隔离抗议者并让尝试他们加入转型是很重要的。
但也不用因此产生过多焦虑，因为实际上决定开展敏捷转型后，公开抵制并不常见。更多会遇到的情况其实是被动抵抗。“被动的抵抗者假装顺从这个过程，站起来并口头上表达支持，但他们的态度是：“谁在乎？”。
因此在敏捷的导入过程中，如何引导团队成员去接受，去积极地实践敏捷是关键所在（图1）。
2. 从敏捷能解决的提升开发效能的方面上入手，对症下药
团队效能的提升涉及到管理流程、技术架构、工具自动化等方方面面的因素，而敏捷关注于需求与开发之间的管理流程问题。基于不同的团队现状，敏捷也有不同的表现形式，这里就不作赘述。
但总体来说，企业做敏捷转型，仍然有一定的流程可以遵循（图2）。
如果企业完全是从原来瀑布开发模式做转型，那么首先在团队层面需要引入看板方式，让团队能够很好的可视化现有流程。只有可视化现有流程，才能识别并优化团队的瓶颈问题。
其次，当团队能够熟练使用看板以后，就可以把团队的组织流程转变成Scrum。Scrum比起Kanban模式的优点在于对团队的动作做了更多的规范化，这样更有利于团队建立统一的开发节奏。
第三，当团队的组织流程运行顺畅以后，就可以在技术架构层面引入更多的实践，例如：优化团队的开发框架、修复以前的技术债等。
最后，当团队级别的效能提升到一定阶段以后，就可以把敏捷相关的实践拓展到整个IT部门，并且推进业务部门一起来做尝试。这块就涉及到规模化敏捷推广和业务敏捷的相关内容了，后续再详细展开谈谈，记得持续关注我们喔~
ScrumMaster不是：
不是Scrum项目经理
不是Scrum开发经理
不是敏捷专家
不是敏捷教练
不是敏捷教练项目经理
不是敏捷顾问
不是敏捷教练顾问
不是敏捷交付经理
不是敏捷项目交付经理
不是Scrum Project Manager
不是Scrum Development Manager
不是 Agile Expert
不是 Agile Coach
不是 Agile Coach Project Manager
不是 Agile Consultant
不是 Agile Coach Consultant
不是 Agile Delivery Manager
不是 Agile Project Delivery Manager
ScrumMaster就是ScrumMaster！
不是Scrum项目经理
不是Scrum开发经理
不是敏捷专家
不是敏捷教练
不是敏捷教练项目经理
不是敏捷顾问
不是敏捷教练顾问
不是敏捷交付经理
不是敏捷项目交付经理
不是Scrum Project Manager
不是Scrum Development Manager
不是 Agile Expert
不是 Agile Coach
不是 Agile Coach Project Manager
不是 Agile Consultant
不是 Agile Coach Consultant
不是 Agile Delivery Manager
不是 Agile Project Delivery Manager
ScrumMaster就是ScrumMaster！
✋热门推荐