全文 1738 字，预计阅读时长 94分钟 认真分享，交真心朋友，我是罗小布 微信：rob3721
敏捷这个词在我脑海已经停留了有 5 年之久了，有好的，有不好的， 所有的信息都来至于一些野路子，且我相信很多执行敏捷没有提升效率的人，有些永远排斥的人，有些执行到最后终止的人，他们对敏捷的理解和认知，都是片面、有偏差，且来自一些零碎的野路子，我也是其中之一。关于敏捷我把认为还不错思考写在这里，希望对大家有启发：
1 对于敏捷，需要一个团队、乃至整个公司，在认知上要达成共识，且都是正确的理解，没有错误的解读，这是所有一切能执行下去的前提。所以就需要敏捷教练和系统培训。
2 对于敏捷「快」的误解： ① 不是说用了敏捷方法后，敲代码的速度变快了，而是把大任务拆分成了小目标来实现，缩短反馈周期，达到更及时的反馈。每一个小目标的完成，都需要第一时间交互出去给客户验收。
② 敏捷宣布完成的标志：我们工作的结束点不应该是把之前所有计划的工作做完，而是把客户需要的工作做完，不是要干完所有的事情，而是以验收方满意为标准。虽然在研发前定了 10 个小目标，但在完成第 5 个后，客户就非常满意，不太需要后面的功能了，这个时候，整个项目就宣告结束。不需要再浪费时间在客户不太需要的需求上。但是如果你是把 10 个小目标一起完成后，再交到客户手上，实际上你是多付出了 5 个小目标的成本。做得多不等于价值大，做的每一件事情确保是客户所需、客户所急。
所以对敏捷中的「快」应该理解成应对及时、反馈及时，交付快、反馈快，目的是为了满足客户的需求，保证项目符合客户的要求，同时让开发人员少走弯路，避免带来沟通和需求理解错误的试错成本。加快反馈循环来提升流转效率、固定小团队(尽可能保持在 10 人一下的规模)、优先级需求池(客户的优先级)、客户参与、实时验收都是可以考虑的实践思路。
3 吸纳敏捷带来的好处，抛弃敏捷的局限和不适用的东西。这样组合起来使用会更有效率。毕竟我们正面对着一个易变、不确定、复杂、模糊的世界，而敏捷快速响应变化、允许试错、小步快跑的特点无疑是符合时代潮流的。
4 能达到敏捷原则和宣言目的的方法我们统称为敏捷方法，只是常见的，大家耳熟能详的有每日站会、看板……。方法的目的是解决实际问题，所以在使用方法之前，先对项目团队做好诊断工作，现在面临的问题是什么，痛点是什么，根据问题提出合适的方案，而不是把所有市面上听说过的「敏捷方法」全用上去
5 以「项目」为中心的管理改为以「产品」为中心的管理。只有这样才能让业务战略与产品战略合二为一，让整个团队目标一致，劲儿往一处使
6 关于站会：尽可能只是相关干系人，把无关人员清除在外，来节省大家的时间。很多时候一个会，10 个人发言，只有其中一人的发言对我有用，但是我必须被迫坐着听完另外 9 个人的发言。站会的目的是进度、信息公开透明，告知给相关干系人，以及是否需要他人协助来完成未来的工作
7 关于看板：看板的维度尽可能的小，打个比方，在一个看板里面尽可能体现的是「直属关系」，像「旁系」「七大姑八大姨」就不要混合在一个看板里面。为什么工作中容易出现看板混乱？导致阅读不直观，从而对任务管理导致误差。其主要是对任务边界不清，无法定性是「直属关系」还是「旁系关系」。在做事前首先确定的是边界，其次才是怎么推进，用什么技术手段或工具推进。
8 关于跨部门沟通：最直接导致效率低下的原因就是，信息不对等。信息有偏差，导致理解歧义，从而方向判断错误，最终导向结果不符合预期。这个就需要站会或其他的会议，尽可能把项目的实时近况通知到所有相关干系人。对于平时不参与本项目的人员，在沟通时，一定要有耐心把背景交代清楚。另外最为重要的是，对方的执行过程中，要实时去关心动态，确保方向没有出现偏差，在自己预设的轨道上运行。
9 关于目标：近期计划一定是具体到可实施的，远期目标计划是粗略的。对于什么是具体到可实施。我是这样认为的，什么样的电影剧本才是一个好的剧本呢，每一句话都能拍摄出来，能通过摄像头能呈现出来，这就是可实施。他笑了和他嘴角上扬，露出了标准的 C 形笑容，很明显后者是可实施的，甚至已经给出了验收标准。
10 关于拆需求：不管是使用哪种拆分方法，做需求拆分的目的，都是把大需求拆成一个个能够独立开发测试的小需求。从而形成原子提交。和上一点提到的，可实施是有共性的，这里更强调的是尽可能独立、闭环性的规整出一个个小需求。
