貌似你不是最远，Andy 貌似在东五环。。。本来想选朝阳大悦城的，结果那除了金钱豹，就没啥可选的了。。。

都是 SCM ，欢迎 PM，dev，测试，ops 等来踢场子，呵呵

因为这只是聚会，欢迎带家属。如果觉得实在无聊，家属也可以逛逛金源燕莎。

@ 北京-kilo 看看你嵌套里面的几个变量 %vname% %newstr% 等 肯定得不到 这需要使用变量延迟 setlocal enabledelayedexpansion 然后变量用! 代替%

携程是不是在上海？

这里是别人的一点提示。

SMTP 比较好设置，应该没什么问题。

52e​ invalid credentials ​

LDAP: error code 49 - 80090308 一般就是通过你给的用户信息去验证时候没有通过。也就是以你的配置用用户/密码去连接失败了。

值得思考的文章。

曾经做过 subversion 和 bugzilla 集成。其实都大同小异。

Subversion 肯定是可以和 JIRA 集成的。具体看这里 https://confluence.atlassian.com/display/JIRA/Integrating+JIRA+with+Subversion

Teamforge 自带了 Subversion，用起来还不错。

@ 知名不具呀：主要考虑复用，可以直接 mapping 到多个 projects.例如你有 100 个 projects,现在公司要统一添加一个新的 issue type.

知名不具 解释的和官网的解释差不多。如果每个项目都直接关联到 Issue Type,那么如果项目很多，比如 100，想统一添加一类新的 issue type，那么就需要添加 100 次。 而如果每个项目都是和 issue type scheme 想关联。那么只需要改一次 issue type scheme 就可以了。

哦，多谢反馈。虚惊一场。

atlassian 官方有解释

What is an 'issue type scheme'? An 'issue type scheme' defines a subset of issue types, which:

restricts the set of available issue types for a project, and controls the order of available issue types and the default issue type shown to your users for a project. (info) The 'default issue type' is the issue type displayed in the selection-box when a user creates an issue. A single issue type scheme can be 're-used' across multiple projects, so that a group of similar projects (i.e. projects which might be used for similar purposes) can share the same issue type settings.

For example, all projects in your company may fit one of two 'purpose' categories:

Development-related projects or Support-related projects. Hence, you could create one scheme called Development Issue Type Scheme (with issue types Bug and Feature) and another called Support Issue Type Scheme (with issue types Development Query and Support Request). You can then associate each of these schemes with the appropriate project(s), for which there may be a plethora.

This provides your users with a different set of issue types based on the project they decide to create issues in and furthermore reflects the purpose behind creating these issues.

Your future maintenance workload is minimised, because any change you make to an issue type scheme is made across all projects that are associated with the scheme. In the example above, adding a new issue type to all support-related projects only requires the simple step of adding the issue type to the Support Issue Type Scheme. https://confluence.atlassian.com/display/JIRA/Associating+Issue+Types+with+Projects

啊，被墙了么？应该不会吧。请大家确认下。

这个我还真没设置过。你可以配好了，看一下。

[i=s] 本帖最后由 laofo 于 2014-6-12 18:54 编辑

我们是这样用的。

一个系统分成几个模块，一个模块分成几个 feature。这个时候我们就分项在 Redmine 中建立一个个的 Feature。 建立完 Feature 之后，我们就可以建立 Task，然后把 Task 关联到这个 Feature 上。也就是说一个 Feature 可能由很多实际的 Task 构成。完成这么多 Task ，也就实现了这个 Feature。 而且通过查看 Feature，就可以在下面看到各个 Task 的执行情况。完成与否，完成的百分比等，很方便。可以起到个划分系统和组织 task 的作用。

我觉得复用是其中的一个考虑。 比如自身有一套模板可以供你使用。如果你觉得模板不太好用，那么你可以在系统模板的基础上建立新模板，在新模板上进行修改。 如果你在系统模板上直接修改，势必会影响到其它项目。因为这毕竟是全局的设置。

比如你在 ProjectA 上直接对 issue type scheme 修改了，那 ProjectB 关联的 issue type scheme 咋办？

你们在用这个？

你不是后浪？

加班与效率 陈皓 http://coolshell.cn/articles/10217.html

微博上看到了这么一个贴子，就像以前在《腾讯，竞争力 和 用户体验》中批评过腾讯说自己的核心竞争力是员工加班一样，我顺着 Winter 的回复也批评了一下这个微博——

“靠加班超越对手？！劳动密集型么？我要是对手的话，我就来趁机挖人了，直接摁死你……//@ 寒冬 winter: 当一个管理者的智慧无法衡量一支团队的产出的时候，他就会把 “工时” 当做最后的救命稻草，死死抱住——这是他唯一听得懂的东西了。”

然后，@ 玄了个澄的在微博里 at 我说，他在微信里看了@Fenng 关于加班的言论，希望我评论一下。我看了一下大辉的文章，虽然写得有点散乱，但是我和他的一些观点还是很类似的，我主要在这里加强一下我的看法。

[b] 关于加班 [/b] 认为加班是公司的核心竞争力，或是超越对手的手段，是一种相当 Ridiculous 的想法。这说明管理者们已经想不到自己公司的核心价值了。

是的，这些靠堆功能没有灵魂的产品的价值就只剩下比谁跑得快了。他们愚蠢和思维有限的大脑里已经区分不出来，“跑得快” 和 “跑得好” 的差别了。产品的发展不是短跑，而是长跑，甚至更像是登山，登山比的不是快，而比的是策略，比的是意志，目的是登顶。并不是谁一开始爬得快谁就能最先登顶的，你往往被超越的时候都在后半程。对于一些危险的雪山来说，登顶的人通常都是要做好非常很充分的准备，并且在登山的过程中学会如何保留体力，学会如何步步为营的，从来不强行登顶。

在《Rework》摘录及感想 中提到过两点

条件受限是好事，因为条件受限可以让你小材大用，让你没有办法再用蛮力来完成工作，让你必需去思考使用知识密集型的解决方案来更聪明的解决问题。 工作狂往往不得要领。他们花大把大把的时间去解决问题，他们以为能靠蛮力来弥补思维上的惰性，其结果就是折腾出一堆粗糙无用的解决方案。 就像人肉手动的织布机一样，当面对大量订单的时候，一个简单粗暴的方法就是拼命地加人和拼命地工作来换取更大的生产力。只有你在人手不够或是人力成本太高的情况下，你才会去想是不是可以优化一下工具，制造一个更有效率更有生产力的工具。

在中国，劳动力的成本不高，而管理者们的智力和能力有限，所以，在这个环境下，尤其在 KPI 和数字的重压下，管理者们是非常非常容易想到需要靠加人或是加班来提高产能的。所以，他们放弃了知识密集型的创新，而采用了劳动密集型的简单粗暴的方式，长期下来，导致了自己再也不会思考，导致了只会使用人肉解决问题。

于是，当全自动化的织布机出现的时候，这种劳动密集型的公司分分钟就成为了历史。这样的例子太多太多了，看看历史就知道了。

当然，有时候，我们需要冲刺还是要适当偶尔加班的，但这绝对不应该是常态和长期的，不然，这必然是一种饮鸩止渴的行为。

另外，我还要多说几种情况：

1）如果你的员工就像在《软件公司的两种管理》中所说的，像 Widget Factories 那样，净是些 X 型的人的话，那么，你也只有使用加班和加人这种方式，就像长城和金字塔的建设过程一样，就像富士康一样，你的团队本质是不会思考只能用鞭子去抽他们的方式去管理。于是，你也只能用 “狼性” 来呼唤你的员工像那些低智商的野兽一样的行事。

2）有时候，我们需要去 “卡位”，需要很快地去实现一个东西占领市场，这需要加班。就像 Win95 和 Intel 的奔腾芯片的浮点数问题一样。但是千万不要忘了，你在卡完位后，得马上把你产品的质量搞上去，不然，你一样会死得很难看。（Windows 是有两个团队的，一个团队是用来占领市场的，另一个团队是安心搞发展的）注意：“卡位” 从某种程度上来说应该是一种有价值的事，但我们依然要思考是否在用蛮力行事。

3）另外，有的人工作就是生活，生活就是工作，所以，对他来说，这不是一种工作，而是一种事业。我认可这样的精神和热情，但是，我还是想让这样的人反思一下自己，有没有用一种更为聪明的方式来从事自己的事业？而不是用蛮力。

无论上述的哪种情况，我们都可以看到，只要你进入了劳动密集型，靠人和靠加班来解决问题，并沉迷并深 陷其中不能自拔，那们，你终有一天会玩到尽头的。

[b] 关于效率 [/b] 很多人不知道什么叫效率，他们以为效率就是：单位时间单位人数下干更多的活。这是错的！效率不是比谁干的活多，而是比谁干得活有更大的价值。效率的物理公式是：有用功/总功。换句话说，效率就是：单位时间和人数产生的价值。所以，提高效率，并不是加人，也不是干更多的活，而是，你这么多人干出来了多少有价值的东西。

有了公式，我们也就知道怎么来提高效率了。

1）增加有用功

你得多问问你的需求方，为什么要加这个需求？干这个事到底有多大的价值？能让多少人受益？ 你得多问问你的需求方，能不能稍微简化一下需求，这样可以让我付出的努力更少一些？ 你得要多去思考一下，你是在干一个建筑队的活呢？还是在干一个装修队的活？ 你得要多去思考一下，业务上和用户的最大的痛点是什么？ 关于增加有用功，再说两点：

像乔布斯那样，告诉你的产品经理或是业务方，你现在提的 10 需求，我只能做 3 个，会是哪 3 个？为什么是这 3 个？有用功的来源不是拼命做需求，而是砍需求。 关于创造价值，我们要干的不是像百度的 “竞价排名” 那样，把钱从别人口袋里搬运到自己的口袋里，而是要像 “英国工业革命” 或是 “硅谷” 那样，把价值真正的创造出来。

2）降低总功

你得多问问自己，你有多少时间是在干一些支持性而不是产出性的工作？ 你得多问问自己，有没有残酷无情地减少重复劳动的劳动密集型的工作？ 你得多问问自己，自己的管理者和员工的能力和素质有没有在降低你的团队执行的成本？

3）形成合力

有一个很不错的产品经理对我说，他看了南京那两个小女孩被饿死的消息，感到很震惊。与之有关联的每一方都说自己尽力，但是最终结果人还是饿死了，你几乎不敢相信这是真的。

但是，类比一下我们的项目，这种事似乎又发生在我们的公司当中，尤其是大公司中。每一个团队都说自己尽力了，结果项目就是没做好，底层团队说自己只干底层，已经尽力了，前端说自己只负责前端，也尽力了，后端说自己只管后端，不管前端和底层，运维说对于这样的设计和部署自己也尽力了，产品经理，运营都这样说，自己尽力了。你会发现，你几乎很难批评他们，因为他们的确如他们所说的那样，把他们自己的那块都做得很好了，而且的确做得很好了。但是，最终的结果却是：整个产品问题很多。

所以说，效率不是每个团队各自的效率，而是整个团队对整个产品负责的共同使命，这样才会现整体的效率。没有整体的效率，只有个体的效率，最终也等于没有效率。

[b] T-Shirt Size Estimation[/b]

Amazon 用一种 T-Shirt Size 估计的方式来做项目。

产品经理会对每一条需求评估上业务影响力的尺寸，如：XXXL 影响一千万人以上或是可以占到上亿美金的市场，XXL，影响百万用户或是占了千万金级别以上的市场，后面还有 XL，L，M，S，这样下来。 开发团队也一样，要评估投入的人员时间成本，XXXL 表示要干 1 年，XXL 干半年，XL 干 3 个月，L 干两个月，M 干一个月，S 干两周以下。等等。 于是，

当业务影响力是 XL，时间人员成本是 S，这是最高优先级。 当业务影响力是 M，时间人员成本是 M，这是低优先级。 当业务影响力是 S，时间人员成本是 XL，直接砍掉这个需求。因为是亏的。 当业务影响力是 XXL，时间人员成本是 XXL，需要简化需求，把需求简化成 XL，时间人员成本变成 M 以下。 大家感受一下吧。

好了，我就说这么多，欢迎大家讨论。

（全文完）

步骤详细、明确、没废话，赞

请获奖的朋友赶紧发邮件，别不好意思，呵呵

关于什么的资料呢？和具体版面相关的，你可以上传到相应版块。其他如《其它工具》和《技术文章》也可以上传。

孤陋寡闻了。以前直接写 outsourcing

可以压缩成每个不大于 2M 的压缩包上传。

我才疏学浅，不得行啊。另外我这人不容易被洗脑，怕过去存活率不高。