开发经理的职责是确保软件产品按时保质发布。流程也为这个目标服务， 但流程本身的作用很有限。软件开发流程理论经历瀑布式，迭代式（RUP, 又称统一软件过程）以及现在的敏捷开发（敏捷在现实中几乎就是scrum），理论越来越成熟完善，但落地执行又不简单。 大量文章都在分析为什么敏捷流程在很多开发团队不起作用。比如最近看到 为什么敏捷开发在亚洲实行不了 里说， “敏捷开发需要大家当面直言问题所在，而这有悖于亚洲文化，因为亚洲人特别注意对别人表示尊重、给别人留面子，这一点与西方文化特别不同，而西方正是敏捷思想的发源地。” 从自己的亲身经历看，这纯属扯淡。讲到留面子，和稀泥，打太极拳，老美一点儿也不输给中国人。流程只是个工具，能否因地制宜执行得好，开发经理起到决定性作用。没有普适的流程，针对一个特定的团队，只有合适的流程。 全栈型的经理比较容易领导团队做正确的事情并做得够快。  能做到这一点，是不是scrum都不重要。他不必在各个方面都是专家，但至少需要能预见技术上重要的风险才能及时采取措施处理。一些技术决定对项目成败有关键性的影响，比如技术选型，搭建软件应用的架构，包括分层, 模块化，secruity, transaction, exception, audit，自动化测试等等。开发经理不必把这些工作都承担了，但至少需要把关，保证这些核心的工作没有明显疏漏。因为最终为产品发布负责的还是开发经理自己，而不是某个犯了错的程序员。不全栈，把关自然就不全面。

开发经理的各项工作中，我认为最重要的就是面试招聘。招对了人，工作中即使遇到棘手的问题，技术好素质高的队员自己就解决了。团队不怕小但要精，队员必须能独当一面。不论前台后端，经理至少应该具备足够好的技术品味过滤掉不合格的应聘者。乔布斯有个观点，一旦招了庸才，两年后，就会轮到庸才做面试招聘，很可能再招进来的还是庸才。如果开发经理不全栈，面试就要靠运气了。反过来说，资历好而水平差的程序员，也可以靠运气进好公司的。

程序员为story估时间（story point）的时候，会不会虚报呢？如果认为scrum的打牌可以避免虚报的话，可以看看上面关于留面子的讨论。即使把story的分配放在scrum打牌之后，经常大家心里已经知道哪个人做哪个story, 比如feature enhancement的story自然是这个feature之前的owner来做。打牌的人很容易会“做好人”倾向于多估时间。（再说一次，这不是中国特色，是人性）心理学有个有趣的关于撒谎的讨论，撒谎的前提是1. 我知道 2.你不知道 3.我知道你不知道。如果经理在产品某项技术上是小白，就容易出现估时间虚报的问题——这样的事情我亲见过很多次了。全栈的经理自然不会被糊弄。

程序员经常会在一个技术问题上产生不同的意见，这很正常，技术上很多事情本来就要做取舍。这时候经常需要开发经理介入做决定。经理做合理的决定不但对项目重要，对队员的个人感受也重要。决定不能是随机的选A或选B, 需要有决定的依据。程序员往往都有点小骄傲，经理技术上捉襟见肘的时候，程序员就容易想，“你还不如我呢，凭什么做决定。”

开发经理需要做coding的工作么？我认为是需要的。 英语里有句谚语， He that would command must serve。至少也要做比较多code review的工作。评价队员工作效果是开发经理的重要职责之一。技术不全面的经理经常依靠听队员自我评价（吹牛），数代码行数等这种不靠谱的方式评价工作。错误地认同或不认同严重影响团队氛围。身先士卒的经理容易长期保持住团队良好的氛围。我没有能力定义什么样的氛围才算是好的，起码，我带团队时，成员互相之间心存善意。

澄清一下自己观点：经理一定要全栈或技术精湛才能带好团队么？不是，但是很多管理的难题在全栈的经理眼里都不是问题， 比如上面提到的评价队员工作。带不好团队就无法好好职业发展么? 不是， 我见过太多靠吹牛，人事等各种非技术技巧成功哄骗二线三线经理的了。管理的路越往上走，技术越不重要，而政治越重要。问题是，作为程序员或开发经理，你的目标是把项目做好还是获得上级认可？我觉得这是职业价值观最根本的分歧， 但， 不想讨论。

猜想世界范围的开源项目沟通成本高，所以他们必须千方百计降低沟通需要，通过一些手段可以做到，比如

一，清晰，自然的架构。

二，高质量代码，代码像文档一样流畅。

三，模块化，面向接口。

四，务实的文档。

五，自动化测试。

……

有些沟通是必然免不了的，比如需求的沟通，我觉得最复杂的需求沟通往往起因于程序员不了解行业领域知识，而开源项目往往是工具类，框架类的项目，绝大多数不涉及特定行业领域知识，了解“domain”的门槛不高，所以需求方面的沟通要求天生就相对较低。我们平时工作的很多沟通来自于技术问题的沟通，我绝不怀疑，技术手段能够降低沟通技术问题的需求，而一个不那么倚重程序员沟通技术问题就能把技术做好的项目，才说明技术风险低，技术好。一些事情，比如技术选型，的确需要Involve比较多的人讨论。但是当技术选型确定，模块划分清楚，接口清晰之后，技术沟通的需求就应该比较低了。有的时候技术上会遇到一些dilemma,这样写程序不好，那样写也不对，有时候确实是因为技术本来也没有完美的解决方案，总要trade off掉一些事情。但更多时候是因为架构不好，才引发了随后的种种麻烦。程序员之间扯皮什么事情该谁做，是不是因为模块化做得不好？“xx,你给我讲讲某块代码实现吧，我懒得看了”，是程序员懒还是程序实在是一团浆糊，惨不忍睹？同一个问题A给B解答一边，给C解答一边，后面还有E,F,G….是不是早该写好文档？

coding的工作不神圣，但确实不同的人做出的设计可以大相径庭，同一个功能背后的代码也可以天差地远。做产品不是靠人堆出来的，三个臭皮匠顶不了一个诸葛亮，三个臭皮匠还不如一个臭皮匠，因为安排一个诸葛亮可以带好一个臭皮匠，三个臭皮匠能把诸葛亮也熏臭了。开发团队应该是全高手阵营，人不必多，但要个顶个而的强。玩儿开源项目的人都是有热情的程序员，往往都是高手，程序员用程序说话就好了，电话不用天天打也不耽误沟通。

跑下题说team work. 最近在想，team work表面上看是相对于个人英雄主义来说的，仔细一想，其实个人英雄主义应该是team work的前提。程序员就是要有这样的本领，当他把手放在键盘上的时候，就能源源不断创造价值。一个人没单打独斗的能力，就没资格谈team work, 笨蛋当然喜欢team work了，不然很容易暴露自己的无知和无能。

I mapped agile manifesto with the 12 principles based on my understanding below

The mapping may be debatable. But it is obvious that the first item, “individuals and interactions over processes and tools”, is the key. I only talk about the three of related principles that I think great practical guidance here.

1.Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The software product is indeed a result of intelligence. The product leads to success if individuals are fully motivated. Individuals with passion not only do their daily work, they also strive to improve the way how they work.

Years ago, a manager in my report line said that, people has to work at least eight hours every day. The working hour is more than eight hours if the time spent on the way counts. No matter you admit or not, work is part of your life. To live a happy life, you should work happily in a positive way.

That word is very impressive to me. To go a step further, let’s say, the attitude to the work is part of the attitude to the life. While a good working environment encourages good attitude of individuals, one’s attitude contributes back to the environment.

2. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation

Communication is highly emphasized in agile. It is the first value of agile in Kent’s XP book. On one hand, it is so obvious that communication is important. We work off-shore. The communication is especially crucial between Beijing and HQ. On the other hand, we should notice the communication costs. It is said, people need 15 minutes to get back to fully concentrated status after interruption. So the cost is the time the communication lasts plus 15 minutes. People should get prepared before contacting others. And to communicate at a settled time can be a good idea. Actions are needed to improve the efficiency.

Because of the time difference, we usually communicate with HQ through mails. And because of the same reason, the communication efficiency can be badly impacted. For urgent/complex issue, we can use moc. Speaking of moc, the note part of moc can also be used to communicate. It is like a broadcast.

Consider this:

Suppose we have shared Windows resource. Someone needs to access to the environment. No surprise, he just logs on directly, then there is a chance to log off others by accident. If it happens, the poor guy sends message to all members “who kicked me off just now? ”A note on moc may prevent this problem. To put the current task/sub-task on moc is also good for co-workers and supervisor.

It is just a supplement to update-status meeting, not a replacement.

Don’t blame someone if his note is ‘listening to the music’.

3. Continuous attention to technical excellence and good design enhances agility.

Individuals need to improve themselves. It would be regretful if looking back for one year and find oneself have not grown at all. People should be open to the world outside. There are ways of getting information:

1. Skimming over tech news/views on some websites, like www.theserverside.com, www.javaeye.com.

2. To get information from others, especially from colleagues.

Almost every tech guy does the first thing. Surfing the internet and finding stuff one interests in. Just a step further makes the second thing happen. Others can get useful information from the sharing.

The way of sharing can be knowledge share and just share the material. Personally, I prefer the latter. I just don’t believe in one-shot knowledge share. For instance, even if it is Gavin King, the designer of Hibernate, giving a three-hour lecture about hibernate. You don’t expect to master hibernate after the lecture. It is great that we have a library in XXX. I’ve been thinking a web –based application, like douban.com, would help in the same way. People talk about e-books, tools, open-source projects and rate on them. What is more, people share stuff on the platform. There are some benefits over real library:

1. Interaction is easier.

People comment on the stuff, rate on them, exchange notes based on them…

2. It is cheap

Some of the books in the library are easy to find electric version on line. That money could have been spent on other good books. What is more, ‘copy and paste’ of e-book doesn’t cost.

3. It promotes good atmosphere.

I believe reading changes one’s insight, and changes one from inside. It can be great if staff in XXX love reading and sharing.

Other thoughts:

There are useful techniques in agile methodologies. Scrum is agile process, and it got popular fast in China. You may have noticed ‘process’is mentioned in way of “Individuals and interactions over processes and tools”. Scrum is surely not silver bullet. Though many practices in scrum work well in many companies, it is not necessary to work well in a given team/company. It can serve as reference. A team needs to adopt the process in a proper way. Process is important. The thought behind the process is even more important. Just do whatever helps improve the product and low down the risk. And it is agile.

Agile in XXX

In XXX, ‘never lay off people’is kind of a principle, though it is not written in employee manual. It does correspond to the ‘individuals’ principle in the manifesto. If people do not need to worry about losing their jobs, they get a chance to work with whole heart and soul. I’m glad to work in such environment.

To adopt agile methodologies, individuals are required to be highly qualified. People need to be efficient and work in a professional way. It is best practice to limit the number of team members in a team, which reflects the fact that each member is expected to contribute enough.

Both ‘never lay off people’and requirements by agile call for fully qualified employee. When I joined XXX, there was paper test. But that process was abandoned later. In my opinion, to be strict in hiring is important to every company. Especially for a company with humanism culture, like XXX. I’m not saying we’d better adopt paper test again. I think we do need some hiring process to be extremely strict.