这是一个创建于 4360 天前的主题，其中的信息可能已经有所发展或是发生改变。
有团队在尝试敏捷开发么？ 你对敏捷的开发怎么看？
 |
1
idleness 2012-05-19 23:35:22 +08:00
加班多了。文档没了。
|
 |
3
caomu 2012-05-19 23:42:21 +08:00  3
什么东西都有度，不应为了敏捷而敏捷。拿我个人来说，我一度为了gtd而gtd，感觉收效不大。就像设计时也不能为了简洁而故意简洁。而从实际操作来讲，把握度也是一件很难的事情，难以量化，也大概只能靠经验和感觉了。比如一般的小型团队去尝试敏捷开放，结果里面的某些要求反而引起不适，具体分析和沟通后也可以不这样做。团队开放和有时限的任务，有时还不得不有用的方法不管三七二十一就上，不过从个人来讲，略带一点完美强迫症，有时候追求极度优化和完美的开发方法倒也没什么。现实受制于条件的话，也就不得不将就吧。之所以有这段话，我也是把方法当目的的受害者，现在也还是不能从真正的目标出发有时还陷在概念名词的陷阱里呢。所以就是，如果没深入试过就去尝试，然后从结果来决定。
|
 |
4
ototsuyume 2012-05-19 23:55:48 +08:00 4
真正的敏捷我不知道怎么样，但现在某些公司所谓的敏捷开发就是某些项目经理和产品为了压榨开发而弄出来的概念，把原本2个月一个版本的开发进度压榨到一个月一个版本再压榨到半个月一个版本再到一个星期一个版本，需求可以一天变一次，然后写出来的代码没有文档没有注释，负责开发的人离职后接管他代码的人痛苦地要死，写出来的代码质量越来越差。经常版本放出去就回冒出什么问题，然后要在几天内发布修复的版本，同时新版本的开发还在进行中，到最后，整个项目的代码就是一坨屎，对，是一坨屎。然后又花两个月去重构，重构完又开始重复上面的流程。
同时，程序员忙于应付越来越无厘头的需求和维护屎一般的代码，每天工作到晚上十点，没有对象的根本就不会看到又对象的希望，又对象的会陷入变回没有对象的危机，同时技术一点都得不到提升，几年后就算给他几倍的时候还是只能写出屎一般的代码，看不到前途看不到希望，无奈离职。新进来一个对未来满怀希望的应届毕业生，又重复前人所经历的事情。 看，这就是敏捷，一些连代码都没写过的人盲目地讨好boss和客户而炒作起来的概念 |
 |
5
notedit OP @ototsuyume 这位同学激动了 你提到的需求一天一变 这个不是敏捷所提倡的 敏捷中认为需求是可变的 但要保证在一段时间内是不可变的。 当然敏捷不是万能的 根本也不会存在这么这么完美的方法。
为什么敏捷所开发出来的代码是没有文档的呢？ 造成这个的原因是什么？@ototsuyume @caomu |
 |
6
Ricepig 2012-05-20 00:22:28 +08:00
敏捷带来的都是好处，出现的问题都是你实施的问题，不是敏捷的错
敏捷提倡xxx，并不是要你xxx 每次看到敏捷，都有以上类似言论。。。 |
 |
7
muxi 2012-05-20 00:35:51 +08:00 2
@notedit 敏捷本身是一个方法学的东西，而很多公司拿着一套系统来解决一个问题，有点小题大做。
敏捷这个概念想达到的目标是：多、快、好、省，也就是尽可能能的做多功能，最快的速度完成，质量可控，投入产出比高。这个目标切中了管理者和老板的要害，而让半桶水甚至没水只会说大话的人，或者打着敏捷旗号完成自己目的的人有机可乘，这是我看到时下所谓实施敏捷公司的现状。 敏捷这个概念在国内已经被滥用到令人发指的地步，现在如果某公司说要实施敏捷，程序员大家就心知肚明要无休止加班了。 我自己在敏捷方面没有什么经验，但我看了不少这方面的书，也找真正的敏捷牛人讨教过很多，敏捷真正想达到的目标是质量和工程控制，在人员充足的条件下更好的达成目标，而国内的现状是开发和产品人员根本不足，微软可以搞敏捷，因为人家玩得起结对编程，国内哪个公司敢搞结对成本，人力成本立马翻翻。 把敏捷视为项目进行中的管理是一个短视和误解，敏捷真正想达到的目标，是投入产出不变的前提下提高质量，尽可能少浪费，不是单纯为了开发中节省成本，而是尽可能减少维护期的成本。 在国内绝大部分公司我是反对搞敏捷的，有几个主要的理由，第一，真正懂的人非常少，都瞎搞，害了公司，也害了同事。 第二，开发人员没有到那个高度，国内程序员群体整体还是比国外要低，这个很正常，这个群体的兴起也就是最近10年的事情，人家老外都几十年积累了，第三，领头人过于浮躁，这是当下很常见的毛病，几乎所有的公司都有，小公司看老板脸色，大公司要考核KPI，综上所述。国内没到那高度，还是别敏捷了，跟着人家后面玩概念，害人害己，不如在代码风格检查，文档检查，代码review，持续集成方面先做起来，可以解决实实在在的问题 步子迈大了，小心扯着蛋！ |
|
10
Ricepig 2012-05-20 01:05:41 +08:00
@notedit 可以先逐步尝试敏捷里一些实践，比如说快速迭代，代码review，然后再接触一些稍微有一点争议的特性，比如说结对，比如说测试先行等等。其实coolshell有一系列文章写的很好，虽然作者对当前的敏捷事态比较反感，但是对敏捷可能会存在的问题也一针见血。
|
 |
11
chloerei 2012-05-20 01:09:08 +08:00
当每个人说到某个东西不好，都用“这不是真正的XXX”的时候，就要知道这个东西其实是有问题的了。
|
 |
14
arthur369 2012-05-20 08:45:05 +08:00
http://blog.xiqiao.info/2011/07/15/1083 《敏捷开发》的漫画
|
|
15
idleness 2012-05-22 23:20:04 +08:00
迭代、持续集成算是比较实用的实践。
每轮迭代按story交付一定功能，测试组对交付特性专门测试，保证系统功能的增量集成，便于快速发现问题，心里会有底；持续集成除了保证代码的编译正常，自动化用例还可以检测是否有新功能开发引人了问题使旧功能不可用。目前在公司里觉着这两点是最大的好处。结对编程搞得不多，TDD要求太高做不来有老员工搞过。 用了敏捷提高的生产率不怎么可观，story安排很多东东一样做不完还是得加班。好处应该就是可控？除了敏捷没经历过其他开发模式，不好比较 看着回复我觉得有不少人是同一个大公司的呢，不知道感觉对不对 |
 |
16
marvinII 2012-05-22 23:31:17 +08:00
|
|
18
marvinII 2012-05-23 00:03:48 +08:00
@idleness IBM中国就是这样的，没敏捷时就加班。
HW是被thought works中国那帮卖万金油的忽悠的敏捷起来的吧？其实无所谓，HW怎么地加班都很猛烈。等到有一天富士康也敏捷了，那才是大行其道的时候。 |
 |
19
j 2012-05-23 00:15:11 +08:00
在实用主义的光环下,敏不敏的全看10米内的环境罢了.
|
Select Language