有知道Agile methodology的吗？

aladding

看到好些developer的工作要求有这种 Agile methodology 经验的，有用过的同学给介绍一下。

Escribo

敏捷开发 自己GOOGLE thoughtworks的CASE STUDY就明白了

xsjrr

说白了就是多说少写，多交流少文档

o2h2o

原帖由 xsjrr 于 2010-10-6 23:25 发表
说白了就是多说少写，多交流少文档

呵呵 很概括

aladding

有没有好的case介绍一下，给个连接。

bfox

说几个大词
1. TDD test driven development
2. Building daily.

基本就覆盖了大部分了。

老外思维很奇怪，我说我开发的时候先写单元测试代码，然后写具体实现，老外不感冒。 我说我TDD, 他们就很赞同。真不理解为什么。

ericbado

Pair programming, standing meeting, card wall, continuous integration, iteration....
刚开始肯定不习惯，特别是pair，一个人在旁边看着，多怪，还要不停的说，解释。。。
启发最大的是automating test，老外的测试做的是不错，类似selenium的工具也非常强大
但是我不喜欢agile，即便以后习惯了估计也不会喜欢
没文档是很不习惯的一点，碰到人员变更，新来的一时肯定找不到北。如果资深的人离开了业务也没人能全部讲清了
说穿了agile就是做到哪是哪，如果业务简单点系统简洁点还好，大项目肯定还得用waterfall

kane2001

Pair programming很好啊一个人写代码另一个人可以在旁边睡觉  

ala

不是他们的思维问题。

TDD 是用写test case来drive你完成你的代码。这个过程是交互完成的。你的test case完成的时侯，你的代码也完成了

ericbado

混日子的确是可以的。。。不过要看跟你配对的是怎样的人。。
有些人还时不时问问，are you with me....

ala

原帖由 ericbado 于 2010-10-7 20:06 发表
Pair programming, standing meeting, card wall, continuous integration, iteration....
刚开始肯定不习惯，特别是pair，一个人在旁边看着，多怪，还要不停的说，解释。。。
启发最大的是automating test，老外的测试做的是不 ...

如果每天都交换pair，项目里的每个人都会完全明白项目的每一块。任何人变更都不会影响到项目。

每个Iteration交付给用户的都是最核心，最需要的东东，而且每个iteration都会有demo给用户，用户如果发觉需求不对，可以快速的做出变更。
如果用waterfall，很有可能，项目结束了，交付的时侯，发现很多东东都需要修改。

ala

原帖由 kane2001 于 2010-10-7 20:08 发表
Pair programming很好啊一个人写代码另一个人可以在旁边睡觉  

用TDD，很难睡觉的，反而你会发觉，时间过的好快。TDD的互动性很强的。

ericbado

这是比较理想的情况，但事实上也不是每个人都知道来龙去脉。很多时候，包括老外也是拿来主义，会用就好，不管究竟是怎么实现的

每个iteration说穿了就是小的waterfall，但是是缺乏整体规划的，很有可能后续的需求跟之前的设计是有矛盾的，或者很难沿用之前的设计。但这就是agile的特点，不要求设计可伸缩，因为不知道将来会怎么变，也就是做到哪是哪

两者总是各有利弊的。。。

njskater

Agile只是一个很general 的概念把，具体可以分到不同的实践，前两年xp很流行，最近好像scrum很火阿,不过具体操作每个公司不一样，还是要看具体情况的

findcaiyzh

pair programming用的多吗？感觉好奇怪。

kr2000

pair programming不是就不能上足迹了？看到它我还是跑吧

dalaohu

agile is all about bullshit, 資本家壓榨勞動人民的工具。

zyzbill

产品经理最高兴Agile模式了，其他人都痛苦

乱码

原帖由 findcaiyzh 于 2010-10-8 09:46 发表
pair programming用的多吗？感觉好奇怪。

不太多，很多公司不用，不过我们现在的team在用，但也不是每天8小时都在pair programming，但能做到5-6个小时。

效率和效果都不错。

如果是pair的skill set有互补性的话，而且基础理论扎实，可以相互学到很多东西.

[ 本帖最后由 乱码 于 2010-10-8 10:48 编辑 ]

乱码

原帖由 zyzbill 于 2010-10-8 10:43 发表
产品经理最高兴Agile模式了，其他人都痛苦

project进度量化，有很多可以衡量的指标，可以有效地控制成本，这是进步。

我觉得现在的问题是：

如果公司很急功近利，所有的时间都记入成本，developer没有适当的时间知识更新（在公司，不是在家），不利于developer的职业发展。
因此，developer需要更有效的time management/prioritize 的能力来应对agile.

flyspirit

Pair programming很多公司不适用。

cynosure

除了配对编程，其他都多多少少用了一点，我们遵循的是scrum，另外我们文档还是会写，只是大多都移到了内部的wiki上去了

kawara

这个以前讨论过了

http://www.oursteps.com.au/bbs/viewthread.php?tid=259426

ericbado

原帖由 乱码 于 2010-10-8 10:56 发表


project进度量化，有很多可以衡量的指标，可以有效地控制成本，这是进步。

我觉得现在的问题是：

如果公司很急功近利，所有的时间都记入成本，developer没有适当的时间知识更新（在公司，不是在家），不利于developer的职业发展。
因 ...

非常同意，知识互补固然是好事，但是pair的时候学到的东西毕竟是片面的，不系统的
比如我不会PL/SQL，pair的人帮我把PL/SQL部分实现了，但粗略的讲解感觉还没有我自学印象深（别指望对方停下手头的事手把手教你，很多时候是他把你不会的部分都做了，搭配一些简单的讲解）
还有一点，每个人处理问题的思路、顺序、方法都是不同的，有时候你很难follow另一个人在做什么，即便他边做边讲
所以我始终没觉得pair有多大的好处，我一个人做说不定还快点

乱码

原帖由 ericbado 于 2010-10-8 20:11 发表


非常同意，知识互补固然是好事，但是pair的时候学到的东西毕竟是片面的，不系统的
比如我不会PL/SQL，pair的人帮我把PL/SQL部分实现了，但粗略的讲解感觉还没有我自学印象深（别指望对方停下手头的事手把手教你，很多时候是他把 ...

很同意你的观点。

别人教的不经过消化永远别不成自己的，sql 这块更是这样，很多case要仔细揣摩+实践的,很多情况下，如果需要大数据量多场景的测试，一天也写不了几个statement.这样每天的技术总结不可缺。

pair programming也要分人，大家coding的方式是互相启发式的，而不是轮班式的，coding过程中需要很密集的交流，如果简单的赶进度，真的不如自己干来的快。我觉得pair programming很适合对coding有感觉的developer，从别人的code中，能看到些东西，好的会学习，不好的会去避免或者替对方纠正。

key

原帖由 xsjrr 于 2010-10-6 23:25 发表
说白了就是多说少写，多交流少文档

多说：是指多面对面的交流，但同时也强调多写，不过不是写正式的文档，而是正式的测试用例。
相对地说，Agile更强调少说多写，就是少用语言来表达，多用代码来表达。把东西量化，具体化，
代码化。由文档第一，变成代码第一。

key

原帖由 ala 于 2010-10-7 20:25 发表


如果每天都交换pair，项目里的每个人都会完全明白项目的每一块。任何人变更都不会影响到项目。

每个Iteration交付给用户的都是最核心，最需要的东东，而且每个iteration都会有demo给用户，用户如果发觉需求不对，可以快速的 ...

谢谢指点。
我想请教一下这个问题的操作办法：
一是如何做到每天都交换pair？或者如何频繁交换pair？是否有什么样的pair的换人规则？
轮岗制？按我的理解，换pair毕竟不是programmer喜欢自发做的事，需要有一定的规则或执行者
驱动才行。

key

原帖由 ericbado 于 2010-10-7 20:40 发表
但是是缺乏整体规划的，很有可能后续的需求跟之前的设计是有矛盾的，或者很难沿用之前的设计。但这就是agile的特点，不要求设计可伸缩，因为不知道将来会怎么变，也就是做到哪是哪

说得很对，agile就是要淡化整体规划，因为整体规划往往引入太强的前期风险。
不知道我理解你说的“沿用之前的设计”对不对，你在这里是不是指沿用之前设计的思想？
以及重用之前设计的框架？还有重用之前实现的一些程序库？这些东西似乎都不是agile
想要的东西。由于agile淡化了整体规划，带来了框架设计的基本缺失，除非团队内部
有框架设计的牛人，在大家都基本接受的情况下，通过pair和meeting的方式分享并获得
认同从而重用，不然，团队内部是不会有重要框架这回事的。

很多人说，refactor能产出可重用代码。事实上这也不是agile能guarantee的东西。
你可以refactor出自己能重用的代码，但别人用不用就不知道了。

所以，基本上需要引入大量的被广泛认可的第三方框架、第三方可重用库，这个时候
开源框架和类库就进入角色了。比如，如果你做了一只FileUtils的轮子，基本上
在团队内部是推不出去的；但如果你用了Apache Commons IO提供的FileUtils，
然后以使用经验的方式推荐给你的pair，那阻力就少了。

最后，大家就都是民工级码农，而这就是Agile要想的东西：无论你是谁，跑掉了
根本不会影响团队的运作。

key

原帖由 dalaohu 于 2010-10-8 10:22 发表
agile is all about bullshit, 資本家壓榨勞動人民的工具。

所见略同

key

原帖由 zyzbill 于 2010-10-8 10:43 发表
产品经理最高兴Agile模式了，其他人都痛苦

所见略同