敏捷开发

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

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

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

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

Origin

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

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

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

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

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

Iteration

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

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

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

Values

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

Agile

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

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

还是先学会写代码吧~

Last modification:November 5th, 2020 at 12:12 am
要饭啦~