吐槽敏捷开发

敏捷的由来

在2001年，17 个程序员大佬聚集在犹他州的雪鸟（Snowbird），提出了一种“通过做并帮助他人做”的新软件开发方式。通过这项工作，宣言的签署者了解到这些原则将在软件开发领域对他们产生多大的帮助——但他们不知道他们的想法会以多快的速度传播到他们的行业之外。

敏捷的价值观（道，第一原则）

• Individuals and interactions over processes and tools 个人和交互胜过流程和工具
• Working software over comprehensive documentation 可工作软件优于综合文档
• Customer collaboration over contract negotiation 客户协作而非合同谈判
• Responding to change over following a plan响应变化而不是遵循计划

敏捷的原则（敏捷的法）

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity--the art of maximizing the amount of work not done--is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

1. 我们的首要任务是通过早期和持续交付有价值的软件来满足客户。
2. 欢迎不断变化的需求，即使是在开发后期。敏捷流程利用变化来获得客户的竞争优势。
3. 频繁地交付可工作的软件，从几周到几个月不等，并且倾向于较短的时间范围。
4. 业务人员和开发人员必须在整个项目中每天一起工作。
5. 围绕积极进取的个人建立项目。为他们提供所需的环境和支持，并相信他们会完成工作。
6. 向开发团队和在开发团队内部传达信息的最有效和最有效的方法是面对面的交谈。
7. 工作软件是进度的主要衡量标准。
8. 敏捷流程促进可持续发展。赞助商、开发者和用户应该能够无限期地保持恒定的步伐。
9. 对卓越技术和良好设计的持续关注可提高敏捷性。
10. 简单性——最大化未完成工作量的艺术——是必不可少的。
11. 最好的架构、需求和设计来自自组织的团队。
12. 团队定期反思如何提高效率，然后相应地调整和调整其行为。

敏捷的术

• Scrum
• Kanban
• ……

敏捷的器（会议）

• 冲刺计划会
• 每日站会
• 产品展示会Demo
• 反思会
• Board
• 任务纸条

这个是对敏捷的基本理解。

首先绝对需要肯定的是敏捷的四个价值观。就是敏捷的第一原则，后续的所有内容都是第一原则的推演。针对特定问题，每个人对敏捷不同理解而做出不同的解决方案。

道是对的，因为它是最虚无缥缈的。比如说“合适的才是正确的。”把这句话放到软件开发中，我觉得也是正确的。但是如何理解“合适”呢？如果做出正确的东西呢，就都没有说了。

然后再说说敏捷的术。

术其实是人对道的理解，对特定问题根据“道、法”的原则去做出最合适的方法论。越到后面，就越具体。值得抨击的也越多。

现在谈到敏捷就是Scrum, Kanban，因为“道”太虚无缥缈了，如果你谈敏捷就说只谈价值观，那么如何在公司里面实施敏捷呢？如何说你们公司是一个敏捷公司呢？敏捷教练应该怎么做才能推行敏捷呢？

敏捷教练要做的就是传播敏捷的方法论。然后就把这套方法论推到各个团队（我有一把锤子，看到所有的问题都像是钉子）。

Scrum, Kanban就有了用武之地了，然后就是需要的各种会议，需要仪式感。看看敏捷所有的流程都走到了吗？这样才可以衡量敏捷教练做的好不好，敏捷在公司内推动的全面不全面。后面还需要什么流程来慢慢完善公司敏捷的推动。

下面我们再回过来看看“道”

Individuals and interactions over processes and tools 个人和交互胜过流程和工具。

其实敏捷第一句还是推崇人，对的人要比对的流程更重要。

但是我们也反思一下，自己是这么有主观能动性的人吗？如果不是，可能流程还是需要的。但是感觉重流程还是有点点反敏捷。

还有一点不喜欢敏捷的是，我们说不出敏捷的缺点是什么，什么地方不适用。感觉敏捷是万能药。如果一个东西是万能药，那么他就是假的了。想想江湖术士的大力丸，它是包治百病的。只要在软件开发过程中，你选取的任何技术都需要做权衡，没有一个东西是又快又准确又扩展性好。你总是要选择他好的地方，而忍受他的缺点。

如果敏捷的方法都是好的，那只能说明我不理解他，或者推销的人没有告诉我全部。

道法术器是一步一步演进来的，但是有时候我们只看到了最后我们接触的事情，而忘记了他最开始想要干什么，想解决什么问题，是在什么背景下产生的。

我理解的敏捷想解决的问题和背景。

产生的背景：

2001年初，那个时候软件的方法论还不那么的成熟。敏捷的出现是想解决当时环境下，瀑布开发模型下产生的各种问题。

• 改不完的详尽复杂文档，一遍一遍的修改。
• 没有成熟的软件开发方案，导致代码混乱，难于修改，不可维护。
  • 面向过程编程？
  • 各个层次没有拆分？ JSP 里面嵌入SQL语句？
  • 没有成熟的编程方法论
• 不成熟的用户，长时间开发完成以后，发现不是自己想要的东西（自已原以为这样就OK了，发现其实不是。）。

现在的情况是什么样子的，

• 成熟的用户（每个人每天都在使用大量的APP,浏览各种网页，成熟的办公自动化产品。）
• 成熟的开发流程
  • 各种编程方法论
    • 设计模式
    • 测试驱动开发（不喜欢，不理解）
    • 领域驱动开发
  • 各种编程框架
    • Spring boot
    • Spring cloud
    • 微服务
    • 消息中间件

成熟的开发人员都可以满足成熟的用户的需求。

时代在变化，有些敏捷的方法论也许过时了，不适用了，但是敏捷宣言，敏捷原则绝对是正确的。

下面是自己编的一个小故事，

原来世上有一种恶龙危害人间，人们对它一点办法都没有，生活在它的迫害之下。直到有一天，一个叫做“洪七公”的少年，不知道在什么地方习得“降龙十八掌”杀掉了恶龙。人们都敬仰他为英雄，他也怕自己的神技消失，便不辞辛苦的传于一名少年。

少年敏而好学，花了10年的时间终于学成归来。发现世上并没有恶龙了。一天他发现如果经过改造以后，降龙十八掌也可以用来杀牛。聪明的少年，经过10年的努力，细细打磨，把它变成一个屠牛的功夫。然后开宗立派，基于少年的威名。收徒无数，开宗立派。

突然一天，少年发现村口竟然有人卖“屠牛刀”,一个成年人使用屠牛刀也可以杀牛。他就列举了“屠牛刀”的种种危害。而遍布世界的他们徒弟们也都声援师傅的决定。屠牛刀终被世人视作最丑陋的东西。

少年的徒弟们也都是聪慧异常，把师傅传授的屠牛神技用来杀羊，宰鸡，捶背，割麦子。经过各种改良以后，并发现他可以处理所有的问题。

其实“降龙十八掌”没有对错，他可以屠龙，在当代也可以屠龙。把他用到对的地方就是对的。敏捷宣言放到什么地方都是对的。

Scrum 只是人们针对一个问题，通过敏捷宣言找到的答案。（少年苦心钻研的屠牛掌法）。

Scrum master 却认为Scrum 可以处理所有问题，导出宣讲，试图解决所有问题。因为他们肯定不回去承认他们学到的东西是不对的。也不愿意承认他们的方法有解决不了的问题。

突然想到了一句话“老科学家有两种解释，老的科学家还有一种是老科学的家。”一个老科学家不会成为自己研究的方向是错误的。新的科学不会马上代替旧的科学。直到研究旧科学的人都去世了，新的科学才可以站住。

我觉得现在敏捷适用的方向是:

1. 需要快速推向市场的，占领市场的项目
2. 需要得知用户反馈的（面向互联网而不是企业内部，企业内部的需要好好谈需求，挖掘用户到底要什么，而不是用户说要什么）
3. 小企业
   1. 我只有10万块钱创业，是用2W做广告还是做系统
   2. 在分迭代开发完以后，已经付了1W的工资了。我这系统够用不够用。发现其实已经能满足了大部分功能了。后面10000的开发费用，也只能带来5000的利益。那我就不开发了。在陪了2000给开发团队后。所有人都会得到好处。
      1. 创业者用了12000块钱得到了想要的系统
      2. 程序员一个月原来可以赚10000，现在赚了12000.

为什么是小企业呢？其实就是PO真正知道自己的利益再什么地方。

但是到了大公司里面，PO不关心公司赚不赚钱，而关心有了这个项目，我的位置就稳固了。那么企业就不会得到敏捷的好处。

最后想说一句就是“合适的才是最好的。”而什么是合适的，如果找到合适的才是最难的。