我相信群里肯定有很多 project leader 或者 team leader。相信你们也会遇到各种类似的问题。
列一些我发现的问题：
当一个团队到达 5-10 个人以上的时候，给团队分工和调节团队间的协作，已经比你自己亲自从操刀整代码要来的更有生产力。
你每天应该更每一个组员有一定的交流时间，或者开一个小会，一个极端的例子，如果你是一个雇员，你领导 1 个月都不来找你，你是否感觉到一种失落感？马上就不 motivated。但是组员多了之后，必然造成你自己大量时间浪费。
让组员 motivated，充满激情，除了给组员自由舒适的环境，明确而又能充满的目标，
既然作为一个 team leader 你还得负责所有的技术问题，有技术难题你得解决，组员间做的 code 有冲突不能协作好你得负责，所有人写的代码质量你的看，你还得自己写一些代码。你们有什么办法来安排这些？
当然个人觉得如果每一个组员都能对自己做的部分负责，而不是一有问题就推给 leader，那么 leader 当然就好做了。问题是，有些时候 team member 会制造麻烦，制造 bug，就是起了很多负作用，不怕神一样的对手，就怕猪一样的队友。这个时候你要 review 他做的东西，一个一个指导，还不如你自己重新写一边来的快。但是每个团队总会有这样的人。你你们会如何处理？
有些时候很多团队会过度 over engineering，而不考虑大体，特别是 team leader 自己都是非常 geek 的时候。很多时候可以通过简单的方法快速实现。但是如果这样的话 team member 就认为没挑战，不好玩。这个时候你们怎么权衡？
我相信发现问题要比解决问题还要重要。抛砖引玉。
我发现 ruby china 没有管理分支，这个应该有。
1、分工的时候工具很重要，trello 又被我提到了。 2、的确，不过大家很熟的话，也是能省则省了，偶尔的题外话还是必要的。 3、期望值有点高，很多时候还是 self management 4、我估计 lz 是遇到一点怨气了 5、和 4 一样 6、三个字“莫较真”。出了问题必然大家一起扛，比如拖延工期，反复除错，代码重写等等。如果觉得气氛不对就等等再聊。话多了的确让人烦，尤其南北差异的时候，哈哈。
最近总结的一句话，一座山爬不过去就绕过去。
楼主提到的的确是很常见的情况，但是抛开具体场景，讨论这些情况的套路个人觉得意义不大。 很多时候，具体的问题，解决方案都是很取巧的，跟当事所有人的性格，可变通的解决方案多少，团队可调配的外部资源，都有关系。
当然，我的意思不是说楼主提问没意义，只是楼主如果可以提出一些具体问题，给出跟问题有关的人的特点，问题的各种替代方案，团队还有那些其他资源可用，或许大家能说出一个比较好的方法。
也有可能，楼主把这些具体情况都写出来后，可能自己就发觉最佳方案了。
对于 4,5，我深有同感，有时团队里就是有这样的队友
提交的代码总是不 ruby style。比如说变量名
=或者=>前后没有空格，代码格式没有对齐、感觉难看等等小问题。和他说这些点点碎碎的小事情，次数多了，也没有什么太多的改进，就累觉不爱了。觉得本来不是应该讨论项目实际的一些问题吗？怎么总是这些低级层面上纠结呢？对于一些 bug 的修改，总是为了修复这个 bug 而修复，方法简单粗暴。就感觉是在为了完成这个任务一样。而我觉得不应该是这样，有些 bug 的引入是有些更进一步原因的，应该多想想，把代码写得更完整，并为团队里其他人提供好用的 API.
然后我就感觉心情不好，团队其他人和那些开源的项目为你提供了这么直观好用的方案，让你直接看 README 就可以干活了；并把代码也写得工整，让他人看得舒服明白。而一些队友却不长心，就不能站在对方的角度来考虑一下问题吗？感觉这样的人，说得难听一点，就像是团队中的“寄生虫”一般。
我也来抛砖引玉一下。我们团队的运作方式——
- 基于 Scrum 和 Kanban 的 agile，但我们更要求的是“常识”，而并非按部就班的按照所谓的“agile”理念来行事。中心思想——不要人云亦云的盲目追随 agile。
- 我们用 TargetProcess 来管理项目。之前用了很久的 PivotalTracker，但我们项目的复杂度已经超越了 PivotalTracker 的能力领域。中心思想——使用一个能提高团队效率的工具非常重要。
- 保护团队，用最硬的盾牌来抵挡公司老总和上层管理的侵入。比如，我们公司目前三个团队，我们团队是唯一一个从未加班过的团队。
- 为团队谋求更多的利益——比方说水果零食、不定期的团队午餐聚会、等等之类的。一个 happy 的团队才会有效率。
- 通过 code review 和其他媒介严格把控代码质量。大到 implementation 方式，小到一个空格——code review 时一定要对事不对人的指出更正与改进的地方。慢慢的让团队里的所有成员都不自觉的撰写出质量相当的代码。
- 鼓励团队成员互相 review 代码，而并不是把 review 的重任扛在自己一个人的肩上。鼓励时不时的 pairing。
- 学会“let go”，而并非一意孤行的要求团队成员按照自己的方式来实现项目的内容。
- 在“上层”面前尽量褒奖团队成员的成果。
- 有过错自己担当，千万不能说“哦，那是因为某某某……”。
- 把控时间——无论是开会，讨论，或是 standup 时，提醒成员也提醒自己，不要跑题，不要无谓的浪费时间徘徊在没有结论的议题上。
- 每 6-8 周我会分别与团队每个成员进行一对一的 casual chat。
- 学会聆听。
- 开会，甚至是平常，有 action points 一定要记下，并设定好时间去实行。实行完毕后告知团队。
- 合理分工。尽量避免系统里的东西只有团队中的某一个成员熟悉。
- 时刻观察代码的综合质量与走向，自己必须清楚代码的大方向与架构。
说到底，作为一个 TL，团队的合作效率是最重要的。每时每刻都应该竖起耳朵张大眼睛看有没有什么问题需要及时解决。
团队里没有“我”，只有“我们”。
每 6-8 周我会分别与团队每个成员进行一对一的 casual chat。 你这个是怎么做到的？一对一还能 casual？因为一般大家都是觉得“领导找谈话”还一对一的。你可能会问一下，觉得公司怎么样啊，工作如何啊。有些人可能会很简单抱怨，或者有些人抱怨比较难说出口，反正指导抱怨了也没有用，就说 fine. good. 这样的谈话有时候你是怎么做到一对一还能 casual?
我相信 casual talk 最主要的是让成员放松，然后能够说出他们想说的。让他对一些不满能够得到对改善的期待或者理解和包容。
中国人的习惯就是碰到面，如果比较谈得来的，都会对你坦白对你说一些不开心的事情，这样才觉得好。但是老外问你 how's going with xxx，99% 的回复都是 good, fine. 跟没说似的。日本人还不愿意抱怨给你听一些真心的想法。所以难度更大了。:)
有一次公司碰到一个别的组的日本同事。我不问他最近如何，直接问，最近有什么不爽的，抱怨啥的，出来分享一下。然后开始狗扯羊肠子，扯出一大堆不满来了。可能这个就是你说的 casual talk?
在你看来澳洲人会不会非常傲慢，本土人相对来说比较傲慢一点？ 很多外国人在国外的时候会不会比较 sensitive，特别在歧视方面敏感度比较高一点？
我觉得在国外的开发者其实有着更多的很多在国内开发的人感受不到的体验。
比如语言，你开玩笑的时候，跟外国人不能用地道的英语开，跟本地人必须要用地道的开，然后当场很多外国的人时候，你老是说地道的话，那些外国人听不懂就很难融入。我不知道是不是只有中国人有种通过说一些你很了解的东西跟你套一些近乎，或者说也是跟一个陌生人展开话题的手段。当语言有问题的时候，总会有这样那样的隔阂，这个比文化来的冲击更大。 文化主要会体现在价值观更一些习惯上的差距，但是大家在国外大家比较能够接受这些差距和区别。 但是文化的不同直接影响你们之间的谈话，扯淡聊天的顺利程度。尤其是中西方各国，他们学英语很多词都能猜出来。他们看的动画片，电影，音乐，生活方式跟亚洲可能差距很多，导致很多笑话到你这里就不好笑了。这个其实是非常苦恼的。
你在国外这么久，从小就过去了，你觉得，你跟本土人的感觉是不是已经没有差别了？
就我在这边接触下来的而言，没感觉到有特别傲慢，歧视（你指的是种族歧视吗？）也还好。偶尔也是会遇到些人品有问题或是不厚道的，但总体而言，至少就 ruby 社区而言，还是很和谐的。
语言和文化一直是个难题。澳大利亚是个移民国，各方神圣都聚集在一块儿。虽说本地人语言上占优势，但只要不影响工作上的交流就没什么问题——我的英语也是第二语言，但工作方面的交流没有问题所以也这么熬过来了。新移民或某些工作签证的就相对劣势了，如果英文不好的话。
#19 楼 @hlxwell 我们在用 trello，另外基于 trello 做了个小工具。 开发和日常事务建议分开，用两个看板。 关于你问题的 4 和 5，推荐你看下 https://medium.com/the-year-of-the-looking-glass/85aa70a0b87d
我最近看《程序员的呐喊》，作者讲了谷歌的管理办法，完全否定了敏捷方法。 只有季度的项目展示，平时没有进度表之类的。
感觉都被敏捷洗脑了，谷歌的做法更符合规律，一个人整天想进度，怎么做得出好的软件呢？
尤其是公司内项目。外包可能还是需要进度。
#23 楼 @hlxwell #22 楼 @SharpX 3 比 7 的比例，个人喜欢第二种，也就是 jave 风格，省一行，更紧凑，从结尾向上就能找到哪个 if http://bit.ly/1h7NZz0
- 基于 Scrum 和 Kanban 的 agile，但我们更要求的是“常识”，而并非按部就班的按照所谓的“agile”理念来行事。中心思想——不要人云亦云的盲目追随 agile。
好东西
- 我们用 TargetProcess 来管理项目。之前用了很久的 PivotalTracker，但我们项目的复杂度已经超越了 PivotalTracker 的能力领域。中心思想——使用一个能提高团队效率的工具非常重要。
好东西
- 保护团队，用最硬的盾牌来抵挡公司老总和上层管理的侵入。比如，我们公司目前三个团队，我们团队是唯一一个从未加班过的团队。
尽力，但有的时候力有不逮
- 为团队谋求更多的利益——比方说水果零食、不定期的团队午餐聚会、等等之类的。一个 happy 的团队才会有效率。
做到了，而且建立了每天中午轮流由一个人买好吃（自愿，大部分都是吃了别人的，自己也会分享的）的习惯，大家都很开心
- 通过 code review 和其他媒介严格把控代码质量。大到 implementation 方式，小到一个空格——code review 时一定要对事不对人的指出更正与改进的地方。慢慢的让团队里的所有成员都不自觉的撰写出质量相当的代码。
做到了，其实严谨让容易建立威信
- 鼓励团队成员互相 review 代码，而并不是把 review 的重任扛在自己一个人的肩上。鼓励时不时的 pairing。
不只是互相review，更重要的是互助，不然啥都找领导会痛苦死
- 学会“let go”，而并非一意孤行的要求团队成员按照自己的方式来实现项目的内容。
放手，相信团队成员，更容易有惊喜，留出20%以上的功能给团队成员自由畅想
- 在“上层”面前尽量褒奖团队成员的成果。
必须护住，孩子都是要背后打，当外人面一定要保护好
- 有过错自己担当，千万不能说“哦，那是因为某某某……”。
包容一些，比如看到一些小错，也不要说，很多人自己心里都清除的，你给他的自由，他给好的代码
- 把控时间——无论是开会，讨论，或是 standup 时，提醒成员也提醒自己，不要跑题，不要无谓的浪费时间徘徊在没有结论的议题上。
开会应该像女生的裙子，越短越好，当然前提是沟通清楚
- 每 6-8 周我会分别与团队每个成员进行一对一的 casual chat。
我一般是年后或者假日后做，放开了，听各种抱怨和期望，建议等，偶尔也要解答一下疑惑
- 学会聆听。
做领导的基本功课，即使你不懂，也要听，很多时候，他讲完后自己就发现问题了，如果你不听，互相就没有信任感，以后什么事儿都不愿和你说
- 开会，甚至是平常，有 action points 一定要记下，并设定好时间去实行。实行完毕后告知团队。
言必行，行必果，以身作则
- 合理分工。尽量避免系统里的东西只有团队中的某一个成员熟悉。
这个其实最难，这时候知识面宽广就显得非常重要了，然后按照每个人的特点分配，孙子说：庙算多者胜
- 时刻观察代码的综合质量与走向，自己必须清楚代码的大方向与架构。
心中有数，大事儿小事都要有数，另外坐在一起，在持续交付中做好code review