敏捷开发

第一次听到这个词的时候，觉得这个东西一定是十分的高大上，对于如此高大上的东西，我一般是敬而远之的。

不巧的是，认识实习的时候，华为来学校讲座，其中有一个就是关于敏捷开发的。但是由于我对敏捷开发确实不感兴趣，而且理论的东西比较多，我就一直在划水。导致讲座结束后，我对敏捷开发还是一脸懵逼的状态。

不过，由于在写后台的时候，每次代码有改动的时候，就需要经过重复的步骤部署到服务器上面。刚开始感觉还好，但是到了后面就实在无法人忍受了。这个时候脚本就排上用场了，但是脚本需要自己去维护，会有诸多不方便的地方。

之后，我接触到了 CI/CD 的时候，才发现原来 Github 还可以这样玩，之前是我太 naive 了。此外，由于代码都是由自己一人写的，每次做出修改总先要看一下效果吧?自然而然觉得这样很正常，所以，我以为的敏捷开发就是这样，不停的进行迭代，只是规模的不同。但是真的是这样吗？

Origin

说话没有需求，哪来的开发?每个项目的开发至少是有一定的需求的。这个需求从哪里来?当然是金主爸爸来提了，但是金主爸爸可能并不知道自己的具体需求是啥样的?有时候下一个需求与前一个需求是冲突的。

为了应对这种反复无常变化多端的需求，业界人士就总结出了对策。既然客户无法弄清楚自己的需求，那就让他们一点一点的提需求。举个例子客户说他想需要一个金字塔，而你知道这个项目需要很 100 年来完成，肯定不能指望一次设计就做出客户想要的样子。于是你问客户，要金字塔做什么?客户说，当坟墓。你就提出先做一个小坟墓的功能。客户同意了，于是啪啪啪一个月后，你丢给了客户一个小型地下室坟墓。客户一看，啪啪，才想明白，他要的不是金字塔，而是一个非常牛逼墓地。于是你和客户达成第二阶段设计，做一个牛逼的兵马...

如此的循环下去，每个阶段只完成一个需求，弄明白下一个需求，周而复始下去，总可以达成让客户满意的效果。我想敏捷的含义就在里面。

但这不是重点，重点是客户需要为每一个阶段付钱，你要搞定的就是让客户同意每个阶段的方案。哪怕下一个方案推到前一个方案都无所谓。既然客户原因付钱，就让他去折腾，反正最后的产品是客户的，作为"dev"的一方，总是可以拿到钱的。

就是现实版的敏捷开发了吧。哈哈哈。

Iteration

既然敏捷的含义上面已经说了，作为developer是需要按时完成每个阶段的多变的需求的。但是要如何做好每次的迭代呢?

每次迭代都是一个完整的软件开发周期，必须按照软件工程的方法论，进行正规的流程管理。

• 需求分析（requirements analysis）
• 设计（design）
• 编码（coding）
• 测试（testing）
• 部署和评估（deployment / evaluation）

Values

• 程序员的主观能动性，以及程序员之间的互动，优于既定流程和工具。
• 软件能够运行，优于详尽的文档。
• 跟客户的密切协作，优于合同和谈判。
• 能够响应变化，优于遵循计划。

Agile

然而，你以为仅仅是客户无法弄清需求吗?不仅仅是客户，连"产品设计者"也无法一次描述清楚产品的最终形态。既然，都弄不清楚具体的需求后，而且需求还会变来变去，那就用敏捷开发来让你们开心好了，这也是"敏捷"一下子流行起来的原因吧。

所以，但我们连代码的写不明白的时候，又怎么能指望我们弄明白自己的需求呢?

还是先学会写代码吧~