团队协作--没有代码的战争

真实处境

  是的,你是某个跨国大公司中的一个优秀的程序员，你的老板,总是和颜悦色地哼着小调来查看你的程序。你还有一个梦幻般的团队，大家配合地很好，什么敏捷、迭代开发你都搞得很定。你总可以按时下班回家，兴许还能和某个PLMM共度晚餐。

  但事实是你正从电脑键盘上爬起来，睡眼朦胧，瞧见屏幕里项目经理频繁的用IM催促你赶紧交付，开着的IDE布满了//DEBUG、//FIX、//TODO。架构师从旁边隔间探出头来，不怀好意的对你说项目有些地方还要变动，其实旁边放着五百页的设计文档已经被他改了八遍了。这时老板来了，把他手里拿着厚厚的客户投诉单，啪的一声丢掉你面前，学着《飞黄腾达》里那个有钱人一样对你说“You're fired!”。

  是什么造成了如此不堪的局面？


从个人表演到团队协作

  曾几何时，程序员可以将策划、编码、等工作一个人包揽，设计也许只是几张草图，文档也是在脑海中随意发挥，总而言之代码写出来就行，其他的都不重要了。

  随着程序的复杂化，越来越多的人加入到程序的构建中，程序的设计和策划渐渐被人们重视起来了。曾经的“给我一个hacker”到了“给我给我一个好的团队”。

  程序构建的团队协作原意是保证程序的质量和效率，但其实其中却是暗藏风暴。团队间的沟通不明、分工不清、信仰大战造成的后果是可怕的，引据《代码大全》中的统计，前期策划的成败影响了将来交付程序的质量的好坏。策划不好的程序甚至比代码写的不好的程序更为糟糕--这是开发过程中，一场团队之间，没有代码的战争。

  但这场重要的战争肯定是被我们忽略了，因为市面上讲述团队合作的书籍少之又少。《代码大全》？《编程之美》？它们帮不了你，它们只告诉你怎么去编程，而没有告诉你怎么去和别人一起合作着编程，你需要的是一本真实讲述团队协作，关于如何和你的同事们交流、沟通的书，如何解决开发中非代码问题的书，一本直面这场没有代码的战争的书。


为什么需要这本书？

  微软项目总监Eric Brenchner，拥有6个不同公司工作的体验，28年工作经验，完全可以说是一位项目专家。

  他写的关于项目管理的书籍《代码之道》中，共收录了49个栏目，在这里他解剖了开发过程中关于团队协作、软件编码、测试、项目管理等各种各样的你有可能在团队协作中遇到难题。

  作为一名程序员，你对自己的项目感到不满意吗？看看“第2章 过程改进，没有魔法”、”第3章 根除低下的效率”和“第5章 软件质量不是梦”吧。
  对自己的编程生涯感到迷惘？看看作者总结的职场经验“第7章 职业生涯历险”和“第8章 自我完善”吧。
  或者你正努力成为一名合格的项目经理，你希望向作者这位项目大师取经，那你可以看看“第1章 项目的不当管理”和“第9章 成为管理者，而不是邪恶的化身”
  再者，也许你对微软充满了兴趣，你也可以看看第十章“第10章 微软，你会喜欢它的”

  总之，关于团队的事情，这里都能找到你想要的答案，《代码之道》是难得的项目管理书籍中最简单易懂的一本，书中也充满了诙谐幽默的的语言，它教你怎么对付你那对软件一窍不通但是主宰你钱包的老板，让你面对项目经理林林种种的需求时不再手忙脚乱，告诉你如何在工作和生活之间找一个平衡。

  市面上各种各样的代码书籍能让你成为一个合格的coder，但是要成为一名合格的programmer，团队协作是必不可少的，作为一个团队中合格的一份子，代码书帮不了你，但《代码之道》可能是你的好朋友。

  如果你正像文章开头的那个倒霉蛋一样在团队协作中处境尴尬，迫切希望走出困境，那《代码之道》是应该是一本你必不可少的书。项目经理，甚至是老板，也应该拥有一本。

  之后，你可以继续按时下班，和PLMM再续前缘了。

自己沙发~

有错误不足之处大家指出吧。

书评的角度不错，支持一下！

团队合作相当重要，这本书是写给项目经理来看的，当然代码工人最好也能掌握
一盘散沙那是乌合之众，要算只能算是一个“团伙”，根本称不上“团队”