关于敏捷的一些想法

从网上看到这样一句话：“敏捷开发的最重要目标就是：满足用户多变的需求，说白了就是最大程度的让客户满意。”

感觉表达的不太清楚。

感觉容易被人误解的地方主要在“用户多变的需求”上。

第一种多变，实际上就是没有从根本上了解了用户的需求。用户的需求实际是稳定的，只是比较多，也比较混乱，用户一般只能了解自己的那一小部分，所以没有用户能清楚的表达出整体需求。而由于各种条件的，用户表达自己那一部分时也有可能出现表达不清或遗漏的现象。

这种多变，正是敏捷开发所要解决的。

敏捷开发解决的是用户混乱的需求，说白了就是引导用户理清自己的需求。

第二种多变，是指说了不算，算了不说的，今天1+1=2，明天1+1=3。没有规律，只看心情。最常见的就是界面部分。今天签字确认的东西明天就要改。这种是任何方法也解决不了的。而现在国内有很多这种情况是最多的。很多软件的失败，主要还是在这一部分！

评论

2 楼 windshome 2013-07-03  

我的看法：这个和行业有关，大多数互联网产品是博主和楼上的仁兄所描述的那样，项目很多时候也是这样。

但是我所了解的很多产品，是一组相互关联的概念组成的，其需求是一组关联非常紧密的概念组成的，在这些概念的基础上，可以细化为具体的需求项，然后衍生出架构，在架构的基础上去进行细节的实现。这个时候，并不是那么容易拆开，一个迭代做几个需求的。

这样情况下，最容易发生的，就是第一个迭代做了需求1234，第二个迭代准备做56789，结果发现5的设计和实现需要把1和2的设计和实现推倒重来（概念冲突、架构上大的改变等）。

虽然敏捷里sprint0是针对这个问题的，但是这样来看sprint0变成了最最重要的一个环节。或者演变成：
1、在使用敏捷方法之前，采用传统方法完成需求的分析和评审
2、需求分析完成之后，才有传统方法完成概念设计和架构的设计
3、在此后，可以采取敏捷的方式，多次小版本迭代直至完成


或者
1、使用传统方法完成第一个版本，重点考虑产品的概念完整性和可持续性
2、后续的版本，因为没有概念上根本性的变化，采取敏捷的方式


当然，如果你的需求天然就是关联不大，那采取敏捷是应天顺人，无需争议。

因为刚听完敏捷的培训，所以有这样的体悟，对与不对，每个人有自己的评判。我的看法是，小版本迭代有些场景非常适用，有些场景需要变通一下。但是我觉得站立会议、结对编程、提高测试的重要性都非常好非常实用。

1 楼 cruiser_31 2012-03-13  

敏捷更加像是珍珠的形成,珍珠开始的时候可能只是一颗小小的沙子,蚌分泌出珍珠质把它包裹起来,液态的珍珠质变成固态,然后分泌一层新的,最后成了一颗珍珠
对于一个项目来说,刚开始解决或者实现的只是一个业务问题,一个模块.经过需求的分析、设计和编码,最后经过用户的确认后,或者还需要进行修改和再确认,然后才能够固化下来.然后去开发下一个模块解决下一个问题.就这样一步步的过来,形成了一个系统.