Eisen's Blog

© 2024. All rights reserved.

读书笔记|Practices of an Agile Developer 2: 1 + 1 要大于 2

March 07, 2013

敏捷

距离上一篇有关这本书的读书笔记已经有相当长的时间了(大约有两年)。两年过去了,我由一个宿舍换到了另外一个宿舍,还是在过着自己相对封闭的学习生活,虽然感觉不是最优状态,但是起码还不错吧。

这次写读书笔记的时候,其实整本书都已经看完了。这次是托豆瓣阅读的福,我可以在 touch 上面看完了中文版。可能是由于我一直对译本有歧视,虽然看的很快,但是不会视书中文字如真理,还会带着怀疑去翻阅原著,不过事实证明,这本书的翻译还是很不错的,看起来整体来说也比较的顺畅。

沟通的成本

当项目由一个人变成两个人的时候,项目就会有所谓的沟通的成本了(这个说法应该是在人月神话里面知道的):首先,需要向新加入的人说清楚要做的东西是什么,为神马要做这个东西,以及怎么做的,现在处于什么状况了,然后你要做什么事情。随着人员的增加,这种说明以及规约的打成,方向的指定都便成了越发复杂的东西了。为了避免重复的工作或者是错误的理解,及时的不断的沟通是非常有必要的。书中讲解了一些策略,可以帮助团队更好的处理这些事情。

立会

沟通是为了更好的工作,不能舍本逐末,让沟通花费了工作的时间。站着开会差不多就是为了让大家觉得不自在,赶紧开完走人,避免浪费时间。

To help keep the meeting focused, everyone should limit their contribution to answering these three questions:

• What did I achieve yesterday?

• What am I planning to do today? • What’s in my way?

Each participant is given only a short amount of time to talk (about two minutes). You may want to have a timer to help those of us who have the tendency to ramble. **If you want to discuss something in greater detail, then get together with the appropriate people after the stand-up meeting **(it’s OK to say, “I need to talk to Fred and Wilma about the database” during the meeting; just don’t start going into the details).

花些时间彼此了解进度一直遇到的难题,如果会上恰好有人在你越到的问题方面有研究那太好了,你可以在会后请教他可以快速的解决问题。注意,这里要强调把那些具体而细节的东西在会后单独搞定,拖累不相干认识开会是很多会议无聊的关键所在。

发挥集体智慧

We mentioned Aristotle’s quote earlier: “It is the mark of an educated mind to be able to entertain a hought without accepting it.” You are entertaining thoughts and perspectives of others, and in the process you broaden yours.

很多 lead 都不懂这个,让下属变成按照他们意愿行事的工具,这样是可悲的。更可悲的是很多人就这么听之任之。每次这个世界陷入混乱都是因为太多没有个人主见的人对那些疯子听之任之。事实上,作为一个独立的思考体,每个人都有自己的意愿和偏好,虽然需要达到意见的一致,但是起码的看楼歪了赶紧叫停的能力是要有的吧。发挥团队的优势一方面是要鼓励各种看法,另一方面是队友们要多多提出自己的想法,不能因为一次的受挫就放弃,这也是自己提升在团队中的作用的一个好方法。

其实,沟通不简单

书中是有很多好的方法可以提升沟通的效果,但是需要一个比较根本的东西,就是对所做事情的认可。找到比较合适的人最关键。沟通不畅,项目受阻很多时候都是一些乌七八糟说不清楚的原因,彼此有隔阂神马的都不好摆到台面上。尤其是在中国,一个人一条龙,一群人一条虫,精明不用在正路上,人多嘴杂,人多事儿多,乌烟瘴气神马的就来了。

当忽悠一个人加入你的团队的时候,需要告诉他你做的东西是什么,以后什么前景,最终可以有什么回报等等等等。如果一切顺利的话,太好了,这很有可能是个好队友。但是如果他满怀质疑的听完之后,看似波澜不惊的背后有一万只羊驼在奔腾,那以后的分歧(或者说根源在分歧的问题)就会以各种形式接踵踏来。当然,由一个人变成两个人其实出现这种事情的概率比较小,因为他如果不喜欢你的东西,完全可以拒绝,处于最初阶段的东西大家都是因为喜欢做才在一起的,不喜欢完全可以不加入呀。但是如果你是一家公司,邀请一位新的同事加盟,那么他可能考虑种种因素最后决定即便是不喜欢你(们)做的东西,但是也希望在这里干一段时间。那么,坑爹的事情可能就开始了。干活的人不赞同操蛋的指挥,指挥的人容忍着操蛋的执行,进度变慢,环境变差,梦想破灭神马的都不好说。那种齐心协力的感觉是一种势,如果大势已去,那很有可能就无力回天了。

我一直都比较反对目前很多公司的那种面试形式:彼此素未平生,凭很短时间的了解,然后就决定他是否要来这家公司。这实在是太不靠谱了,而且有些面试的内容也确实无聊,须知路遥知马力日久见人心。虽然话是这么说的,但是人家确实不能说花个一年半载的去面试一个人。我比较喜欢的形式是先不要太高的要求可以让你去一家公司实习,然后根据他几个月来的表现来判定这个人的水平。(但是,悲剧的是一些公司把实习生变成了廉价劳动力,不论表现如何从来就没有正式的打算让人家转正的意愿。)我觉得好的团队未必是说要找非常厉害的人,应该是找志同道合的人。大家彼此说的来,项目的问题容易沟通,才是关键。对于技术的把握,并不是关键因素。

不过,我还有更极端的想法。目前的基础设施越发的发达,依靠很多人才能做一件事情的时代慢慢会过去,看看 kickstarter 上面的项目,很多独立的团队已经在做过去庞大的公司才能做的事情。依赖更清晰的分工以及社会化生产,设计芯片的人只需要做设计,而把生产交给别人。构建应用的人依赖 GAE 这样的平台较少设备维护以及基础设施维护的成本,更专注于自己的产品(PaaS正能量:6人团队,仅1人全职后端 支撑6000万用户,刚刚看到一篇应景的文章)。人越多,沟通成本越大,酱油出现的概率越多,项目的发展越发难以估计。控制团队的规模并让自己保持团队的成长,没准儿是未来的趋势。

得出的结论很简单:如果一个 200人的项目中,有 25 个最能干和最有开发经验的项目经理,那么开除剩下的 175 名程序员,让项目经理来编程开发。 --人月神话

要的就是这种效果。