《敏捷开发方法：为什么大厂都在用，小团队却总用错？》
刚毕业那会进了一家所谓的“敏捷转型”公司，差点把我整疯。
每天早上九点半站会，每个人站着说三句话：昨天干了啥，今天要干啥，遇到什么问题。
就我们那十来个人的团队，站会能开半小时。
有人翻半天看板找自己的卡片，有人扯一堆无关紧要的琐事，最后大家腿都站麻了，该解决的问题还是没解决。
说白了，就是换了个壳子的形式主义。
敏捷开发敏捷宣言原文海报
看到没？从根子里，敏捷就是反流程僵化的。结果现在倒好，很多公司把敏捷搞成了新的僵化流程。
为了凑故事点，整个团队坐下来吵一下午，一个需求到底算3个点还是5个点，争得面红耳赤。
为了对齐迭代，一周开三次会，正经写代码的时间没剩几个小时。
这不叫敏捷。这叫耍流氓。
说实话，敏捷从诞生那天起，就不是为了让老板方便管人，是为了让开发干活更顺，能更快拿出好用的东西给用户。
互联网创业团队敏捷开发看板实拍
敏捷宣言第一条就说了，个体和互动高于流程和工具。你把看板做的再漂亮，故事点估的再精准，如果团队还是层级分明，开发不敢提反对意见，产品说改就改根本不跟你商量，那这套东西就是摆设。
我之前跟一个做了十年的敏捷教练聊天，他说，百分之八十的公司敏捷转型失败，根本不是团队学不会流程，是管理层放不下手里的权力。
原来什么都得老板审批，需求说改就改，现在搞敏捷，还是那一套，只是让你多开几个会，多填几个表，能成功才怪。
敏捷本质上是把交付的责任还给团队，把决策的权力下放给听得见炮声的人。
领导只需要给目标，不需要管你每天几点站会，一个需求估几个点。对吧？
什么样的团队，真的适合用敏捷开发方法？
说句实在话，敏捷不是银弹。不是所有团队都要赶着凑这个热闹。
你要是做航天嵌入式软件，做银行核心系统，需求从一开始就定死，不能出一点错，那瀑布模型比敏捷靠谱一万倍。本来就不需要变，你瞎迭代什么？出了错谁担得起？
适合用敏捷的，基本都是那几类：
第一类，面向C端的互联网产品，需求变化快，需要快速试错。你做个社交APP，不可能提前一年把所有功能都定死，得跟着用户的反馈走，小版本快速迭代，试错成本低，错了马上改，比憋一年出个垃圾产品强太多。
第二类，创业团队，资源少时间紧，要抢市场。你本来就没工夫写几百页的需求文档，一步步走流程，先做个能用的出来，跑通模式再说，刚好契合敏捷的思路。
第三类，做创新业务的大厂团队，方向不明确，要探索。原来的大团队流程慢，拆成小的敏捷团队，每个团队试不同的方向，成了就放大，败了就砍掉，损失也小。
不过话说回来，小团队想用对敏捷，真的别搞太复杂。你就抓住三个核心就行：
第一，小版本交付，别憋大活。哪怕一次只做一个小功能，也要做的能用能测，别搞半年都拿不出东西。
第二，打掉部门墙，有事当面聊。产品开发测试坐一块，别产品写完需求扔给开发，开发写完扔给测试，出了问题互相甩锅。
第三，接受不完美，允许改需求。本来就是冲着变化来的，别抱着一开始的需求死磕，用户说不好就改，没什么大不了的。
很多小团队，上来就学大厂搞规模化敏捷，十来个人的团队，搞那么多层级那么多流程，纯粹是自讨苦吃。
你就记住，敏捷是帮你提高效率，不是给你加包袱。适合自己的，才是对的。
别被“敏捷”这两个字PUA了，它本来就是救急的
很多人不知道，敏捷开发方法不是哪个大厂设计出来的管理工具，它是一群被瀑布模型坑惨了的程序员，凑在一起搞出来的“造反宣言”。 上世纪九十年代，软件开发基本都是瀑布流：需求分析→设计→编码→测试→交付，一步走不了就别迈下一步。 那会软件卖给企业，需求提前定死，改一个需求要走一堆审批，等改完交付，客户的业务都变了。 17个程序员受不了这套，1997年凑在犹他州的滑雪胜地开了个会，最后整出来那份敏捷宣言，核心就是四句话：个体和互动高于流程和工具，可工作的软件高于详尽的文档，客户合作高于合同谈判，响应变化高于遵循计划。敏捷开发敏捷宣言原文海报
看到没？从根子里，敏捷就是反流程僵化的。结果现在倒好，很多公司把敏捷搞成了新的僵化流程。
为了凑故事点，整个团队坐下来吵一下午，一个需求到底算3个点还是5个点，争得面红耳赤。
为了对齐迭代，一周开三次会，正经写代码的时间没剩几个小时。
这不叫敏捷。这叫耍流氓。
说实话，敏捷从诞生那天起，就不是为了让老板方便管人，是为了让开发干活更顺，能更快拿出好用的东西给用户。
敏捷开发方法的核心，根本不是流程，是人
我见过做的最好的敏捷团队，是之前合作过的一个创业小团队。 八个人，产品开发测试运营全齐，没有专门的敏捷教练，没有贴满便签的 fancy 看板，甚至连正式的站会都没有。 每天早上大家坐到位置上，随口聊两句今天要做的事，谁卡壳了喊一声，旁边的人放下手里的活就过来帮忙。 两周出一个测试版，直接丢到用户群里收反馈，周末改完下周就更正式版。 那一年他们版本更了四十多次，产品上线半年就拿到了百万级用户，比隔壁那个天天喊敏捷转型，花几十万请教练的团队快了不止一倍。 为什么？因为他们抓对了核心。互联网创业团队敏捷开发看板实拍
敏捷宣言第一条就说了，个体和互动高于流程和工具。你把看板做的再漂亮，故事点估的再精准，如果团队还是层级分明，开发不敢提反对意见，产品说改就改根本不跟你商量，那这套东西就是摆设。
我之前跟一个做了十年的敏捷教练聊天，他说，百分之八十的公司敏捷转型失败，根本不是团队学不会流程，是管理层放不下手里的权力。
原来什么都得老板审批，需求说改就改，现在搞敏捷，还是那一套，只是让你多开几个会，多填几个表，能成功才怪。
敏捷本质上是把交付的责任还给团队，把决策的权力下放给听得见炮声的人。
领导只需要给目标，不需要管你每天几点站会，一个需求估几个点。对吧？
什么样的团队，真的适合用敏捷开发方法？
什么样的团队，真的适合用敏捷开发方法？
说句实在话，敏捷不是银弹。不是所有团队都要赶着凑这个热闹。
你要是做航天嵌入式软件，做银行核心系统，需求从一开始就定死，不能出一点错，那瀑布模型比敏捷靠谱一万倍。本来就不需要变，你瞎迭代什么？出了错谁担得起？
适合用敏捷的，基本都是那几类：
第一类，面向C端的互联网产品，需求变化快，需要快速试错。你做个社交APP，不可能提前一年把所有功能都定死，得跟着用户的反馈走，小版本快速迭代，试错成本低，错了马上改，比憋一年出个垃圾产品强太多。
第二类，创业团队，资源少时间紧，要抢市场。你本来就没工夫写几百页的需求文档，一步步走流程，先做个能用的出来，跑通模式再说，刚好契合敏捷的思路。
第三类，做创新业务的大厂团队，方向不明确，要探索。原来的大团队流程慢，拆成小的敏捷团队，每个团队试不同的方向，成了就放大，败了就砍掉，损失也小。
不过话说回来，小团队想用对敏捷，真的别搞太复杂。你就抓住三个核心就行：
第一，小版本交付，别憋大活。哪怕一次只做一个小功能，也要做的能用能测，别搞半年都拿不出东西。
第二，打掉部门墙，有事当面聊。产品开发测试坐一块，别产品写完需求扔给开发，开发写完扔给测试，出了问题互相甩锅。
第三，接受不完美，允许改需求。本来就是冲着变化来的，别抱着一开始的需求死磕，用户说不好就改，没什么大不了的。
很多小团队，上来就学大厂搞规模化敏捷，十来个人的团队，搞那么多层级那么多流程，纯粹是自讨苦吃。
你就记住，敏捷是帮你提高效率，不是给你加包袱。适合自己的，才是对的。