敏捷开发思考
0x01 敏捷开发好么？
首先，作为一种方法论，一般都是有适用的场景的，很少“银弹”。对于软件开发，场景很多，可以从多个维度划分，toB的toC的，是不是偏业务的，还是偏底层系统的，是不是外包的，等等。
敏捷，也不例外，是一种有场景的方法论。
以前公司推行敏捷，搞个教练，不少开发的很反感，而且确实需要花费不少时间来进行准备demo，然后各种会议。有提高效率或提高整个项目的开发效率？并不能确定。效率这个事情，感觉最重要的还是需要人。
0x02 比较认同的观点
在quora上的一个问答：
Why do some developers at strong companies like Google consider Agile development to be nonsense?
其中点赞最多的一个回答：
Companies like Google have seen through all the trendy bluster surrounding agile (especially the fetid abomination that is Scrum), they’ve taken the few bits of the process that work and dumped all the management fad cruft (of which there is rather a lot). They have realised that every developer is different, each developer has their own processes that they work best with, and that the focus should be on the end product, not how to get there.
I’m OK with using a Kanban board. I’m even OK with end user-centric tasks to a certain extent. That’s more or less where it ends.
I am not OK with the stupid, asinine terminology. We’re developers. Do we really need more rubbish terminology in our lives?
I am not OK with the short-termism of ‘sprints’ that inevitably end up with you having to refactor code time and time again when the next set of ‘user stories’ come in.
I am not OK with the lack of strategic thinking when it comes to program design and software architecture.
I am not OK with blatant micromanagement masquerading as ‘the next big thing’.
I am not OK with ‘story points’ or ‘planning poker’. These are estimates of effort, not time, and hence utterly useless.
I am not OK with daily standups. The Kanban board should tell everyone what they need to know, not this silly ritual lifted straight from Alcoholics Anonymous.
I am not OK with all the other meetings either. Waste of good development time. Write me a f**king email.
I am not OK with ‘agile coaches’ - the dev world’s evangelical religious zealots peddling their ridiculous creed to companies on the promise of increased productivity, new jobs for increasingly irrelevant middle management (scrum masters and product owners) and the chance to say they do something trendy like ‘agile’, and then charge the company a fortune for the privilege.
But, most of all, I am not OK with the homogenisation of developers that takes place in Scrum environments. It’s extremely hard to be creative and do any out-of-the-box thinking when you’re being micromanaged. And there’s a whole generation of young developers coming into the workplace and thinking this is how it’s supposed to be done. WTF?
对敏捷中强调的仪式感、快速的短迭代的方式、迭代要交付可用产品等都进行了批判。
浏览了下其他的回答，很多也是对于这种短期的规划很反对。
在知乎上廖雪峰的一个回答也是满满的讽刺：
敏捷开发：我们也不知道到底要开发啥，走一步看一步吧
用户故事：老板说明天要上这个功能，怎么实现我不管
快速迭代：上次做的功能点击率太低，把广告改成全屏
用户痛点：昨天用户投诉了，把广告调整下
拥抱变化：老板天天都有新想法，大家要适应（不要怪我）
持续交付：每个版本都有问题，总是持续交给测试，交付间隔10分钟
结对开发：bug太多了，直接去测试妹子的工位边测边改
代码评审：这个代码是你审的，将来出了问题你是要负责任的
弹性工作：不限定下班时间，修完bug才能走
四个润会：（Scrum Meeting）每天早上9:00开始，想上班迟到没门
0x03 适合的场景
也是知乎上看到的一个回答，觉得比较认同：
敏捷这玩意，最开始就是所谓“定制软件开发”(Custom Software Development)界的人搞出来的概念，之后主导敏捷的大佬们，也都是这个圈子里人，那么什么叫“定制软件开发”呢？用大白话说，就是软件外包。
当然，外包也有高端和低端之分，低端被压榨得吐血，高端的知道怎么驾驭反复无常的客户，这种高端外包人士，往往有个名字叫做“咨询师”，嗯，是不是一下子高大上了很多！ 这些咨询师在和翻脸比翻书还要快的客户打交道过程中，总结出了对策，他们意识到客户都难（shi）以（mei）给（yuan）出（jian）明（de）确（da）需（sha）求（bi），指望客户一次想明白产品怎么做是不现实的，所以，干脆这样，让客户一点一点提出需求，我们也就一点一点做，做出来一点东西，让客户看一看，也许客户很满意，也许客户终于想明白真实的需求，那我们慢慢改。
打个比方，客户说他想要造一座金字塔，你作为“咨询师”，认为这座金字塔要造10年，肯定不能指望一次设计好就一口气做完，于是问客户这个金字塔是要干什么？客户说要当坟墓，于是，你提出先做一个小坟墓的功能，能装木乃伊那种。客户同意了，你哐哧哐哧做了一个月，制造了一个小型地下墓室，演示给客户看，客户看了，一拍大腿，说看到这个墓室才想明白，其实他要的不是金字塔，要的是一个有排场的墓地，这样简陋埋在地下的墓室不够牛逼，于是你和客户达成第二阶段设计，做一个带兵马俑方阵来让这个墓地显得有排场，客户同意了，于是你又哐哧哐哧做了一个月，做了一个小型兵马俑方阵。客户看了兵马俑方阵，又一拍大腿，说这个方阵还真牛逼，但是能不能增加一些现代元素，把古代兵马俑换成现代装甲兵团，你于是又…… 如此，周而复始，每个阶段只完成客户一个需要，当然，我上面只是一个荒诞的例子，但是你应该能够get到敏捷的含义。 最重要的是，客户虽然说不清最终的目标，但是同意每个小阶段的目标，也就是说，客户要为每个小阶段付钱。既然他愿意付钱，那他反复无常又怎样，毕竟，最后的产品是客户的，“咨询师”获得的是报酬。