敏捷开发让程序员越老越值钱？

　　35岁危机是程序员绕不过去的一个问题，各路大V已经讨论过各种解决方案：转行、做自媒体、干副业、考公。。。。
　　如果有人说敏捷软件开发可以让程序员越老越值钱，你会是什么感觉？
　　估计有不少人要跳起来了：敏捷开发已经变味，成了压榨程序员的工具，成了需求不断变更的借口！还能让我越来越值钱，这不扯吗？！
　　我最近看了一篇文章（阅读原文可达），是对一家公司的CEO采访，文章提到：现代的软件工程借鉴了工业生产的方式，强调流程可控性，把软件开发也拆分成需求分析、架构设计、详细设计、编码、测试、部署、运维等独立的步骤。
　　于是程序员‘前面’有架构师、需求分析师、项目经理等等，他们敲定了整个软件的框架和功能，最后剩下大量的代码工作，留给程序员去填。然而‘前面’的环节才是最有价值的。
　　由于代码的工作量非常大，需要占用诸多人力，一些欧美软件公司在做好了前期的需求、设计、架构之后，将代码外包给更具人力成本优势的其他国家的软件公司来做。
　　在这种模式下，很多程序员的职业生涯一直就是在写代码，就是可以被替换的组件，尤其是在中国这个人数众多，激烈竞争的市场，随着年龄增大，精力不济，被更年轻的更有活力的组件给替换掉。
　　与传统模式不同，敏捷开发更依赖程序员的能力，更能体现和提升程序员的价值。传统模式下程序员开始工作时，问的第一个问题是：需求是什么？
　　敏捷程序员应该问的问题是：问题是什么？
　　因为敏捷程序员一定要去碰客户，了解业务，了解需求，然后解决客户的问题，而不仅仅是写代码。
　　敏捷程序员会身兼数职，不仅仅是需求分析和设计，有时甚至需要熟知客户所在行业的业务特性和行业特征，以便提供更有针对性的服务和解决方案。
　　不同的客户会有不同的需要解决的问题。我们认为程序员需要去理解这些，并且提高自身解决问题的能力。随着年龄增长、阅历增加，经验不断地累积，他解决问题的能力会不断提升。
　　因此在敏捷模式下，程序员是越老越值钱。
　　从大的方面来说，我是认同这个说法的。
　　我们应该深入的从两个层次讨论一下。
　　1。到底什么能力能让程序员越老越值钱？
　　越老越值钱的本质是经验可以积累，在IT界，技术变化太快，很难积累。
　　什么东西可以积累呢？
　　一种是做基础软件开发，操作系统、数据库、编程语言。。。。。。这些领域需要长期的积累，并且技术变化很慢，只要技术不断精进，可以越老越吃香。
　　另外一种就是项目开发，用技术解决客户业务问题是极其关键的一个能力。
　　客户的业务问题多种多样，需要不同的架构、不同的技术方案来应对，就像医生看病一样，经验不断积累，成功解决问题的次数越多，经验越丰富。
　　如果你有过多次成功的项目交付经验，公司肯定会把下一个项目交给你，而不是一个刚入行的年轻人。
　　即使是离开公司也不怕，轻松找到下家，自己有人脉还可以单干。
　　所以大家可以想想，自己能不能和客户面对面的进行顺畅的沟通，帮助他把真正的需求提取出来，然后做出架构设计，详细设计，最终写代码给实现了。
　　如果项目太大，能不能组织一帮人，领导一帮人，一起把这个项目完成了。
　　我觉得这才是程序员真正的能力，它更像是一种复合体：业务分析架构设计领导力（项目管理）。
　　2。敏捷开发能让程序员具备这种能力吗？
　　现在很多公司的敏捷开发都是伪敏捷，也有计划会议，每日站会，回顾会议，但都是做做样子而已。
　　有其型而没其神，这样的敏捷开发只会让程序员心生厌恶。
　　我一直认为，敏捷宣言的大牛们所说的敏捷对程序员的要求是非常非常高的，甚至是一种精英程序员的模式。
　　想想看，你需要能和客户流畅沟通，和客户建立牢固的信任关系；需要能做设计；能写出高质量的代码，能测试，会重构，最好能TDD；需要和伙伴高效率的交流、结对；捎带手还能写出抓住重点的、简明扼要的文档。
　　这样的程序员可以说是无所不能，他们组成的特种小分队，无论在什么模式下都能成功，敏捷开发的那些实践只是助推剂而已。
　　敏捷开发强调和客户协作，程序员会直面客户，会逼着程序员提升沟通能力和业务分析能力，见到客户就想躲，肯定是搞不起来的。
　　敏捷开发要求程序员参与设计，提倡价值驱动，风险驱动，需要不断演进的架构（以便应对变化），也会逼着程序员在架构设计能力上不断提升，不断积累。
　　对照前面说的业务分析架构设计领导力，剩下的就是程序员领导力这一块儿了。
　　可见，理想的敏捷对程序员的能力提升肯定大有好处，但是在国内我们最常见的就是毫不讲理的、做不完的需求，不顾代码质量的疯狂发布，以及走了样的敏捷架子。
　　这样的敏捷，不但对能力提升毫无帮助，还会不断压榨程序员，把程序员变成可替换的组件。