Someone is picking on Martin Fowler, nice.....

无视

http://jamesmckay.net/2011/07/wh ... d-feature-branches/

wil

以前一直很向往能够进入thoughtworks工作，也尝试过面试，结果第一轮电话面试被一个non-IT的mm的第一个non_IT问题直接拒掉，她先讲了一堆thoughtworks的value，然后问我的value是什么，我没遇到过这种问题，没有准备的回答了一些什么以用户需求为主，以软件质量为重，产出易维护易扩展的软件等等。“对不起，你的value和我们公司value的不匹配”（意译）直接被拒。。。。有些莫名其妙，但还是对这个公司以及martin fowler比较敬仰，直到了解了一些关于“熊节”的事迹，开始对这个公司产生了不好的印象，也没很强烈的进入到这个公司的愿望了，可能因为我天性好自由，对所有形式的“宗教”都或多或少有些抵触的原因吧

无视

原帖由 wil 于 2012-7-9 11:49 发表
以前一直很向往能够进入thoughtworks工作，也尝试过面试，结果第一轮电话面试被一个non-IT的mm的第一个non_IT问题直接拒掉，她先讲了一堆thoughtworks的value，然后问我的value是什么，我没遇到过这种问题，没有准备的回答了一些 ...

他们在open source那边是不是很有名？我们用他们的产品，所以知道一些，但不是很了解他们在open source那边的地位,martin fowler所在的公司应该不算差...

martin fowler大部分的东西我都还行，也看过他的refector,但有些论点的确听不感冒.

这是不是熊节真相？

http://www.zhangxun.com/reviews/gigix.aspx

[ 本帖最后由 无视 于 2012-7-9 12:52 编辑 ]

wil

他们对open source贡献不大，我好想没听过什么比较有名的open source tool是他们公司的。martin fowler是thoughtworks的首席科学家，他总结概括能力比较强，尤其善于给概念起名。。最主要的是他是敏捷开发的最积极的推动者之一，因此thoughtworks可以说是敏捷开发方法学的试验田

关于martin fowler，我没啥太大意见，只是他是纯oo的倡导者，这个我觉得不是所有模型都适合用oo风格来构建的

关于agile，越来越觉得这是一个宗教概念了。。

关于熊节，读过一些他的经历（可能是这个打假的发表的），没正经做两年程序员就被thoughtworks中国雇佣成为资深敏捷咨询师，因为他的IT媒体背景，所以开始对敏捷产生抵触，比如有次采访他关于tdd，他说tdd是需要悟性的，有的人一辈子也领悟不了，有的人一个礼拜就领悟了，就跟武侠小说里的神功似的。。

无视

原帖由 wil 于 2012-7-9 14:25 发表
他说tdd是需要悟性的，有的人一辈子也领悟不了

这个太扯了，这么能忽悠的人也算是个奇才，尤其这么短时间出名，中国IT界太容易神化一个人

MaxChan

关于feature branches和feature toggles的讨论也在我们公司出现过，尤其其中一个对feature toggles非常的反感，我们猜测thoughtworks的人这么热衷于feature toggles可能跟他们用SVN有关系，SVN在处理merge上有缺陷，特别是在大量的refactoring（改名，改路径）发生时merge很容易出现conflict，所以他们就不愿意做branch了，所有的开发都在trunk上，但又要做iteration release，那就只能feature toggles了。

DoubleU

他们用mercurial...

不过无论用什么vcs, merge conflicts 总是难免

无视

原帖由 MaxChan 于 2012-7-9 20:30 发表
关于feature branches和feature toggles的讨论也在我们公司出现过，尤其其中一个对feature toggles非常的反感，我们猜测thoughtworks的人这么热衷于feature toggles可能跟他们用SVN有关系，SVN在处理merge上有缺陷，特别是在 ...

你们用什么的vcs? git?mercurial? 猜测一般敢于作feature branch的team出不了这两个dvcs.

我们用feature toggle,感觉还不错。

个人觉得这方面的讨论过与注重在agile方面的release，而忽略了feature本身的意义，我们的feature既有release方面的考虑，更多的侧重在function，不同的场景feature的开关状态不同，比如上了aca,根平常状态相比，就有一部分feature被关掉，另一部分feature被打开。iteration release只是feature的其中一个应用.

另一个原因不做feature branch也是迫不得已，因为我们用ms products stack，这是公司的policy,tfs本身并不擅长branching/merging,这也是tfs被community不断诟病原因之一，或者说它不是一个很好的vcs的选择，但很多公司还在用主要是它是因为alm,这部分用户主要是非技术人员.而且msdn subscription一揽子把这些东西都搞定，没有很特殊的需要一般team懒得再去选一个第三方vcs+alm,一般的应用这种选择性价比并不高。而且存在兼容和易用方面的问题，tfs+git本身就是一个hack，用起来很不爽。

如今RC的tfs11(2012)vcs有些改进，但根本上来说仍然不是dvcs,但起码可以在local上work了，只是不能checkin，不知道它在其他方面如何，应该比之前的vss强很多.

feature toggle可以解决一般的问题，但有时不得不branching的时候，我们的原则是：两个feature要丝毫不搭界，如果有任何交集，我们都避免这么做.

很好奇你同事为什么对feature toggle这么反感，能具体说说么？

[ 本帖最后由 无视 于 2012-7-10 08:49 编辑 ]

uowzd01

进这个公司要洗脑的，和传销也差不太多了

dcc82

thoughtworks不是咨询公司吗? 以前应该是个好公司, 招聘很严格, 还要做pair programming
这公司应该用ruby用的最多了吧, 只用过它家的开源产品Selenium, 不过比不上Sahi

uowzd01

tfs最烂的应该就是不可以revert，不知道现在有没有好点？

uowzd01

CI经验不多，这个是不是应该划分到coding以外？程序员写程序才是最主要的吧？那么多feature, pattern都研究不过来

无视

原帖由 uowzd01 于 2012-7-10 10:15 发表
tfs最烂的应该就是不可以revert，不知道现在有没有好点？

还是要手动的，没辙

无视

原帖由 uowzd01 于 2012-7-10 10:20 发表
CI经验不多，这个是不是应该划分到coding以外？程序员写程序才是最主要的吧？那么多feature, pattern都研究不过来

这应该归到pattern了

MaxChan

我们没有git或mercurial，相反的，我们用的还是svn。原因是git或mercurial用在我们的项目上都大材小用了，如果只是为了解决merge产生的conflict的话。
我们的开发主要还是在trunk上，尽量避免在branch上开发，但如果碰到某些功能不能在下次iteration release前完成的，或者business要求这个功能一定要在完成后才能release的话，那就只能feature branch了。这时候，为了避免merge conflict的问题，我们就规定对feature branch要做daily merge from trunk，保证每次的merge都是小版本的改动，conflict也控制在小范围内得到解决。这是很笨的办法，但还是可以work的。
至于我那个同事为什么这个反感feature toggles，可能跟他之前的职业经验有关吧，没有问过他，只是每次说到这个他都会对之冷嘲热讽一番。另外，我们公司并不是做product的，所以并没有feature toggles的十分必要，你说的我可以理解，因为我之前公司就是作product的，feature toggles就是作为一个必须的功能存在的，跟开发方法无关了。所以，现在这里讨论的就是为了iteration release的需要而做feature toggles，还是feature branch。
我们也是倾向于尽量少的branch，开发集中就在trunk上，然后让BA教育business去接受iteration release功能逐步实现的现实。当然对BA在分解story上也是一个挑战。

无视

理解理解....

无论toggle还是branch,如果非要iteration release的话，怎么也要有种机制来控制feature的开关，可能toggle这个名字更加能反映它的实质。

feature的break down/evaluation的确对BA/scrum master是个挑战，我觉得更多的是BA的职责，一点不懂技术的BA很难胜任。

uowzd01

原帖由 无视 于 2012-7-13 14:17 发表
理解理解....

无论toggle还是branch,如果非要iteration release的话，怎么也要有种机制来控制feature的开关，可能toggle这个名字更加能反映它的实质。

feature的break down/evaluation的确对BA/scrum master是个挑战，我觉得更多的是BA的职责，一点不懂技术的BA很难胜任。

我觉得很多BA都只考虑了B，没有一点技术的SENSE，你让他们来挑战技术，NO WAY

来打我啊

看不懂

MaxChan

原帖由 无视 于 2012-7-13 14:17 发表
理解理解....

无论toggle还是branch,如果非要iteration release的话，怎么也要有种机制来控制feature的开关，可能toggle这个名字更加能反映它的实质。

feature的break down/evaluation的确对BA/scrum master是个挑战，我觉得更多的是BA的职责，一点不懂技术的BA很难胜任。

在这点上我对我们公司的BA还是相对满意，虽然都没有技术背景，但是碰到这种情况他们会来跟dev做pair。而且BA跟tester就跟我们坐一块，平常的关系都非常好。

无视

原帖由 uowzd01 于 2012-7-13 14:28 发表

我觉得很多BA都只考虑了B，没有一点技术的SENSE，你让他们来挑战技术，NO WAY

嗯，所以很多公司business spec是由BA作，然后tech 作tech spec,然后break down，prioritise,enqueue.....

好的BA需要tech这边的帮助，但应该更多的是印证，而不是让tech这边代作,这种BA很难得.

无视

原帖由 MaxChan 于 2012-7-13 15:36 发表


在这点上我对我们公司的BA还是相对满意，虽然都没有技术背景，但是碰到这种情况他们会来跟dev做pair。而且BA跟tester就跟我们坐一块，平常的关系都非常好。

不错，很好的team！！

uowzd01

原帖由 无视 于 2012-7-13 16:27 发表


嗯，所以很多公司business spec是由BA作，然后tech 作tech spec,然后break down，prioritise,enqueue.....

好的BA需要tech这边的帮助，但应该更多的是印证，而不是让tech这边代作,这种BA很难得.

经验啊，不过考虑澳洲这边的环境，有BA已经不错了，以前做了那么多鸟公司，都没有或几乎没有BA。

wil

原帖由 MaxChan 于 2012-7-13 15:36 发表


在这点上我对我们公司的BA还是相对满意，虽然都没有技术背景，但是碰到这种情况他们会来跟dev做pair。而且BA跟tester就跟我们坐一块，平常的关系都非常好。

我们公司用的是先进的"三个代表"思想指导管理的

[ 本帖最后由 wil 于 2012-7-13 19:06 编辑 ]