2008年4月15日
胡铭娅(Michelle Hu)，IT168技术频道资深编辑，曾任电子工业出版社计算机图书事业部编辑，编辑出版了多本畅销计算机图书。2007年加入IT168技术频道，负责.NET、SQL Server等微软技术相关频道，以及IT人生、图书等栏目。专注于微软技术跟踪报道和推广，对.net技术有着独特的理解。
前面的话谁说女子不如男，多有巾帼胜英雄。在微软MVP的大阵营里，自然不乏巾帼专家们的秀丽身影，她们在各自的领域以其过人的魅力与出类拔萃的能力赢得了尊重。在七月流火的季节里，微软公布了2008年度7月新一届MVP的名单。这其中作为IT168技术频道资深编辑的胡铭娅小姐的当选倍为引人注目。对于这样一位“美丽与智慧并重，时尚与技术前行”的美女MVP，以其在.NET技术领域中做出的卓越贡献，得到了微软MVP项目组的一致肯定，首次当选MVP。这位被誉为“中国最美丽的MVP”以其敏锐的视野、独特的见解、秀丽的文笔，有力地推动了.NET与SQL Server技术在中国，尤其是在技术社区的推广。
随着这一届MVP名单的新鲜出炉，笔者第一时间连线这位美女MVP，并有幸获得她的允许，与读者分享她的经历与体会。
采访手记主持人：胡铭娅小姐，首先恭喜你获得微软的MVP称号！可以先简单地介绍一下你自己吗？
胡铭娅：谢谢。我主要从事于技术编辑工作，目前担任IT168技术频道资深编辑，之前曾任电子工业出版社计算机图书事业部编辑，在此期间，编辑出版了多本计算机畅销图书。2007年，我加入IT168技术频道，主要负责.NET、SQL Server等微软技术的相关频道，以及IT人生、图书等栏目。我非常专注于微软技术的跟踪报道和推广，同时对.NET技术有着独特的理解。
主持人：据说你这次是北京市08年7月当选的唯一的一位女性MVP，在这里可否给大家谈谈你当选mvp时的感受吗？
胡铭娅：感觉自己真的非常幸运。这首先得感谢微软能给我这个机会与荣誉，同时还要感谢身边的一些MVP朋友在技术上给予我的帮助。正是他们在初期引导我进入微软技术圈子，为我传道解惑，并时刻给我鼓励与帮助。
主持人：请问你是何时进入IT行业的？能否谈谈你对这个行业的认识？
胡铭娅：进入IT行业是我当初考大学时就决定了的。家长曾给我很多其它的建议，但是出于对计算机的爱好与兴趣，我仍然决定选择计算机专业。我在大学的时候曾经做过一个论坛，在那个时候还没有.NET技术，我记得当时是用ASP编写的。论坛维持了大约3年，后来一直为其不停地寻找服务器（因为支持ASP的空间不再免费）。由于学业比较繁忙，又面临毕业找工作等问题，就无奈放弃了。现在想来还有些后悔，因为在那个时候完全没有意识到他的商业价值，呵呵 :)
我在毕业之后一直希望能够从事与计算机相关的职业。2004年，一个偶然的机会，我来到了电子工业出版社计算机图书事业部，从此开始了我的IT人生之旅。
在我看来，IT行业是高新科技产业，一个不断创新的行业，也是智力密集型行业，当中的每一个人都要有清晰的头脑、敏锐的眼光、快速的反应和学习能力。IT 行业是目前中国和发达国家发展差距相对较小的产业。相信通过我们的不断努力，一定有机会追上，甚至超越发达国家的计算机水平。
主持人：我们知道MVP是微软为那些在微软技术领域中作出突出贡献、在某个技术领域具有较高造诣，或者对于推广微软技术发挥巨大力量的技术人员所颁布的全球性奖项。对于从事微软技术开发的人员而言，可以说是微软官方能够授予的最高荣誉。对于一位新的MVP而言，你能谈谈对微软MVP的认识吗？
胡铭娅：微软最有价值专家 (MVP)可以是：以微软技术为主题的作家、讲师、培训师；IT业界的业内知名专业人士，通过印刷媒体、博客或其它形式分享经验和观点的专家; 参与和微软技术有关的项目，担任主要角色的技术和管理人员; 建立讨论微软技术的技术网站，担任主要角色的技术和管理人员; 参与微软中文新闻组，积极地帮助论坛用户解决疑难问题的技术论坛高手；参与其他第三方的微软技术论坛，积极地帮助论坛用户解决疑难问题的技术论坛高手。
我现在的工作主要围绕最新微软技术动向进行，包括选题策划、社区活动、高端访谈、技术分析、培训讲座等。另外，作为微软（北京）.net俱乐部一员，积极参与线上线下活动，为社区做出贡献，这些工作都得到了微软的认可。所以即使是女孩子，只要能发挥自己的力量，给MS带来价值，一样能得到MS的认可，成为 MVP。说不定你也行啊！！！
主持人：你被誉为中国最美丽的MVP，那么请问你是如何让枯燥的技术与美丽前沿的时尚完美结合的？
胡铭娅：是这样吗？实在是让我受宠若惊了。这个称呼对我来说是莫大的荣幸，真是要谢谢大家了。其实，我觉得IT行业和时尚行业有一个共性，那就是更新速度快。“爱美之心人皆有之”，当你对自己有了充分的自信，相信你做起别的工作也会更加地得心应手。其实这源于你对生活的理解。
主持人：是啊，信心确实是成功的源泉。不过，我们却不得不面对这样一个事实，就是在软件行业内，女性从业者仍然属于凤毛麟角，更遑论取得成功者。那么你作为这个行业的出类拔萃者，可有什么经验与体会与我们共同分享？
胡铭娅：“出类拔萃”我不敢当，只不过是有一些见解而已。在软件行业，更新速度快，工作压力大，行业竞争激烈，软件从业者确实面临诸多困难。对于这些困难，我觉得关键要保持对技术的热情。只有找到自己的兴奋点，那么无论做什么，都不会觉得累。
主持人：在软件行业，同样离不开媒体的推波助澜，尤其是出版社和技术网站，为技术的普及与推广做出了重要的贡献。你曾经就职于出版社，现在又是技术网站的资深编辑，请问你是怎么看待技术编辑与技术开发之间的关系呢？
胡铭娅：他们之间有一个共性，就是都要求有一定的专业技术背景和实践能力。但两者之间是不同的。技术编辑还要具备媒体敏感性，良好的分析能力，能深刻理解技术含义，编程并不是他的优势和特长。虽然他有自己擅长的某一种技术，但他对相关的各项技术都有了解，他能以宏观的角度来看待技术发展，对技术的发展具有前瞻性。而开发人员其实更多的是专注于某一种技术，在某一种技术上有很深的造诣。工作职责不同，在不同的岗位上，做出的贡献是不一样的。
主持人：面对你这样一位时尚美女，总是谈技术未免太枯燥了些。可否轻松一些，给我们谈谈你的业余生活？
胡铭娅：工作之余，我喜欢去郊外走走，放松一下紧张的神经。有时候也会和好友们一起去K歌、尝试“开发”各种美食等:)。有时候我也喜欢安静地听音乐或看书、看杂志。
主持人：最后一个问题，但绝对是最重要的一个问题，相信大多数网友也是最迫切希望知道答案的问题，那就是你心目中的白马王子会是怎样的？
胡铭娅：呵呵:) 我想，我心中的白马王子应该是有责任感、有爱心，支持我、可以信任，而且可以互相帮助的人吧。
主持人：非常感谢胡铭娅小姐能够在百忙之中接受我的采访。希望你在微软技术频道做出更多精彩的技术专题，谢谢！
胡铭娅：谢谢！
博客园专访：
http://news.cnblogs.com/interview/humingya/
书名很酷炫，内容更精彩。最近InfoQ中国的编辑李剑（小刀）呕心沥血的译作《硝烟中的Scrum和XP》隆重推出，读者响应甚众。在第三届敏捷大会上，小刀“坐台”签名，免费派送本书之实体书，引发一轮抢书高潮。本着推广敏捷的宗旨，InfoQ又特别免费推出本书的电子版，以飨读者。小刀的翻译，可谓行云流水，绝妙好辞如行山阴道，应接不暇。读者读的是洋思想，享受的却是纯正的中国风。最重要的是在本书中，敏捷不再是思想的玄谈，而是方法的实践；不再是理论的空幻，而是实际的运用。废话不说，且看InfoQ对本书的介绍：
在本书中，作者Henrik Kniberg讲
述了他在一年的时间里，带领40人的团队实施Scrum的过程。他们试过了多种团队尺寸（3～12人）、sprint长度（2～6星期），定义“完成”的
不同方式，不同的backlog格式，各种测试策略，在多个Scrum团队之间进行同步的多种方式。他们还尝试过XP实践——持续集成、结对编程、测试驱
动开发等等，还试过了把XP跟Scrum组合。
本书描述的是一个成功敏捷团队的工作过程，没有理论、没有引用、没有脚注、没有废话。读者可以把它当作一些基础实践的入门指南，帮助团队进行正确实施——但不能模仿，你需要了解自己所处的环境，进而对具体实践做出取舍，创造出属于自己的过程。
免费下载此书：硝烟中的Scrum和XP（
免费下载这本书（PDF）
）
欢迎免费下载InfoQ中文站发布的其他迷你书，同时欢迎您向更多朋友推广，在您的博客和相关论坛中发布这些迷你书的摘要和链接，以让大家了解这些书的内容，访问InfoQ中文站下载阅读。
.NET相关：Visual Studio .NET使用技巧手册
架构相关：领域驱动设计精简版
Java相关：Grails入门指南、深入浅出Struts2
敏捷相关：Scrum Checklists中文版
ps: 这是我在hp写的命题作文，E文不好，请见谅。
Abstract
Scrum is an iterative incremental process of Software development
commonly used with Agile Software Development. Especially, Scrum will
help us to manage the project more efficiently because it is an
adaptive process. However, applying the Scrum Methodology should depend
on the different situation during the process of project development.
It’s a big issue to solve. This article gives an example to elaborate
how to manage the project with Scrum.
Introduction
Software development is a complex endeavor. So the most difficult
problem is how to handle the complexity through by the science of
project management. Many scientists and software engineers raised a
great number of methodologies for project management such as Waterfall,
UP and Agile. In contrast to the heavy methodologies including
Waterfall and UP, Agile is enough flexible to embrace the change, more
light to be mastered by project team members, and more focuses on the
communication and release of the usable software rapidly. Agile
methodologies include eXtreme Programming, Scrum, Feature Driven
Development and Crystal etc.
Scrum was raised by Hirotaka Takeuchi and Ikujiro Nonaka in 1986. The skeleton is shown in Figure 1.
Figure 1
The lower circle represents an iteration of development activities that
occur one after another. In Scrum, it was called Sprint. Each Sprint is
an iteration of 30 consecutive calendar days. The output of each sprint
is an increment of product. The upper circle represents the daily
inspection that occurs during the sprint, in which the individual team
members meet to inspect each others’ activities and make appropriate
adaptations.
There are three roles in Scrum including ScrumMaster, Product Owner and
Team. The ScrumMaster is responsible for the Scrum process, for
teaching Scrum to everyone involved in the project, for implementing
Scrum and ensuring that everyone follows Scrum rules and practices. The
Product Owner is responsible for representing the interest of
stakeholders and creating the project’s initial overall requirement
which was called the Product Backlog, for using the Product Backlog to
ensure that the most valuable functionality is produces first and built
upon. The team is responsible for developing functionality. Teams are
self-managing, self-organizing, and cross-functional, and they are
responsible for figuring out how to return Product Backlog into an
increment of functionality within an iteration and managing their own
work to do so.
Problem Statement
Without doubt, Scrum is one of most popular agile methodologies now.
It, however, is not easy to apply it to project management. Considering
about the following situations please:
1. If the culture of your organization is contradictious with Scrum,
and your leader always interrupts you during the process of project
development, what should you do?
2. If your team members are not familiar with Scrum, and they don’t understand the heart and rules of Scrum, what should you do?
3. Furthermore if your team members didn’t master the basic skills of
Agile developing such as pair programming, Test Driven Development etc,
what should you do?
4. If your customers always change their requirement, they are not clear what they want even, what should you do?
Our Solution
In fact, we can’t find out the “Silver Bullet” to solve these problems.
We know Scrum is an adaptive process. Scrum makes many rules which
should be followed, but not hidebound. It’s agile and flexible. It
allows us to adjust the way to achieve the goal of project.
The answer to the first question is operating within the culture of the
organization. Don’t fight against the culture of your company. If you
are ScrumMaster, you’d better walk a fine line between the
organization’s need to make changes as quickly as possible and its
limited tolerance for change. You can adopt Scrum by starting small. At
the same time, you should try your best to persuade your leader to
support you. Sometimes your leader will build the bridge between the
agile world and non-agile for you. Of course, it needs change, but
these changes must be culturally acceptable. If not, you must
acquiesce. The ScrumMaster is a sheepdog of the team, and his job is to
protect the team from impediments during the Sprint. Remember that the
precondition of which everything is going on well is that the sheepdog
cannot be dead. After all, Scrum is the art of the possible.
Right, we hope our team members are all software craftsman so that
everything is Ok. Unfortunately, the real world is not as good as that
we expect. In fact, the situation in which most of team members are all
apprentices is more common. It is true that it is difficult to hire the
experienced software engineer in this industry. So the problem we must
solve is how to train them. We should draw up a training plan. Before
it, we must understand the skill set of everybody. We need to assign
the mentors to the fresh guys. Of course, the best way of training is
practice. We should assign the task to them according to their ability.
At the same time, we have to add the task duration because they are not
familiar with the related skills. Besides, Pair programming is a good
way to handle it.
The great character of Scrum is enough flexible to embrace the change.
Scrum is an iterative and incremental process. The iteration is very
short (30 days) so that we can change our plan in time. The incremental
development will provide the good policy to submit the release rapidly.
The increment product can give our customers confidence. And the
customers can understand the difference between what they want and what
we provide though by the running software. Scrum emphasis on the
communication between the team and customers. Product Owner of Scrum is
responsible for communicating with the customers and creating the
product backlog. In case the customers changed their requirements, the
Product Owner will discuss with ScrumMaster and Team. If the change is
acceptable, it is added into the product backlog. If the change is
within the sprint which the team is developing, the sprint has to halt,
and re-open the new sprint. Beside, the daily scrum will help each team
member understand the current statue of the project, and the sprint
review meeting will show the result of the sprint to the customers in
order to get the feedback from the customers, the sprint retrospection
meeting will prompt the Scrum process framework and practices.
Evidence that the Solution Works
Now we complete the first sprint of the project on time. In a month, we
went through the whole lifecycle of the software development from the
requirement analysis to designing, coding and testing. Each member is
familiar with the Scrum gradually. Everything is going on well such as
Daily Scrum, Team Work and Sprint Development. In the end of this
sprint, we submit the increment product to our customers and get the
feedback from the customers. The most important achievement is that our
customers approve our approach to develop the product.
Competitive Approaches
We don’t follow the rule of Agile Methodology strictly. For instance,
most of team members are accustomed to the TDD (Test Driven
Development), so we adopt the traditional way to design and develop the
software such as Use Case Driven Development instead of TDD. But we
require everybody must write the test case for classes and components.
We organize the pair programming group to prompt each other.
Because our customers are off-site, so we require our Product Owner
must be in-site and cooperate with them in full time. We create the
communication schedule for the customers to understand the customers’
requirement. The Product Owner is empowered to handle everything with
requirement.
Especially, the ScrumMaster of our project protects the team from the
rest of the non-agile world. We get the enough resources and backup.
For example, we have our own agile coach to direct how to apply the
Scrum to our project. He can help us to solve the key problem when we
are confused of Scrum Methodology.
Current Status
The project is going on well. The first sprint is very successful. Team
members are all confidence. They regard the Scrum as the effective and
enjoyable process. The customers are satisfied with our process. Most
of risks had already solved because we emphasis on them and add them as
the tasks into the sprint backlog.
Next Steps
Next month, we are going to hold the Sprint retrospective meeting to
find out the existed problems in the first sprint. Then we will create
the backlog for next sprint. In this sprint, we will develop the most
important domain module and let it workable.
Conclusions
Scrum is an excellent agile methodology to release the software product
rapidly and correctly. It gives all team members the new management
responsibilities. The process of the project management is visible and
controllable. The ScrumMaster and Product Owner don’t need to write the
redundant documents and draw up the unrealistic project plan. The team
members become more active due to self-organizing and self-managing.
References
1. Agile Project Management with Scrum, Ken Schwaber
2. Software Craftsmanship, Pete McBreen
3. Applying UML And Patterns, Craig Larman
捷道·敏捷堂发布：http://www.agiledon.com/post/2008/07/Scrum-Practice-In-PM.aspx
在敏捷开发过程中，我们还需要对系统架构进行设计吗？事实上，Martin Fowler在《Is Design
Dead?》一文中已经给出了答案，那就是我们同样不能忽略对系统架构的设计。与计划性的设计（Planned
Design）不同，我们需要演进式的设计（Evolutionary
Design）。在敏捷开发的生命周期中，我们通过每一次迭代来丰富与更新我们的设计方案，以使其最大限度地符合客户对系统的需求。这里所指的需求，包括
功能性需求和非功能性需求。
在Agile Journal四月刊中，IBM's Methods Group的敏捷专家Scott W.
Ambler详细地阐述了在敏捷语境中的架构设计方法，他提出了所谓“架构预测（Architectural
Envisioning）”的方法，以应对敏捷开发中逐步演进的架构设计过程。
Scott指出，敏捷模型驱动开发（Agile Model Driven
Development，AMDD）明确地包括了初始需求分析与架构建模，这个过程发生在敏捷项目开发的第0次迭代中。所谓第0次迭代，就相当于项目的热
身活动，是项目得以启动的基础。在此迭代期间，团队需要充分地理解项目的范围，甄别可行地技术策略。这个阶段所能够收集到的信息将有助于你对整个项目最初
的粗略估计，以制定合适的项目计划，从而获得启动项目的资金与足够的支持。
更多内容，请阅读发表在捷道·敏捷堂的
文章。
“敏捷方法”本为舶来品，追求的是灵活、小巧、敏捷地应对软件开发过程中的变化，而不像某些重量级开发方式那般笨拙不堪，流于形式，而忽略了软件开发的变
化万端。敏捷重思想、重精神、重原则、重实践，而轻形式、轻过程、轻方法、轻管理，讲究的是敏捷为本，交流至上，持续改进，因地制宜。若体会了敏捷思想，
只要遵循敏捷的基本原则，各种方法皆可敏捷。若未曾领会敏捷的真谛，那么即使应用了敏捷方法，也不过是“空有其形，大失其意”，终究是“画虎不成反类
犬”！
敏捷方法并非玄之又玄的“道”，不过对于国人来讲，用“道”来阐释敏捷之精神，至少可以避免陷入某种思维定势，少去许多约束与条条框框。至于如何去理解
“道”的含义，就需要实际去推行敏捷方法，从而在过程中去体悟。《敏捷之道》电子杂志荟萃了国内诸多敏捷专家或爱好者的思想体会、工作实践以及个人
认识，是发表在
捷道·敏捷堂的优秀文章摘选，其目的在于推广敏捷方法的实践与运用。
本期电子杂志精选了7篇文章，分为敏捷思考、敏捷实践、敏捷方法、敏捷工具、好书推荐五个栏目。由于
捷道·敏捷堂还处于草创时期，因而文章内容或有不足之处，或有偏颇之处，不过套用许多电视台的用语，那就是文中观点仅代表作者个人意见，仅供参考。文章包括：
印第安人的灵魂——敏捷回顾
印第安人在赶了3天路后，会停下来小憩一天，因为他要等着自己的灵魂跟上来。敏捷开发在经历了一次迭代或者冲刺（Sprint）后，也需要休整，以等待团队的灵魂跟上来，这一过程被称之为“敏捷回顾（Agile Retrospectives）”。
解开最后期限的镣铐
在大型遗留系统基础上运作重构项目
本文以ThoughtWorks中国公司与客户合作的咨询项目为背景，为读者介绍如何在一个大型遗留系统的基础上组织和运作重构项目，从而切实有效地改善系统质量。
单元测试实践小结
异地分布式敏捷软件开发
异地分布式软件开发（Distributed Software Development）是指由多个位于不同地理位置的团队进行同一个软件项目的开发过程。
McDonald & Scrum
Scrum是一种敏捷方法，强调快速反应，讲求人的配合等等。而其团队组织方式是多功能型，由具有各种才能的人组成足以达成既定任务的团队。
欲善敏捷开发 先利敏捷工具
敏捷开发的潮流并不是由敏捷工具来推动的。但近年来，为了更好地支持敏捷开发，敏捷工具也有了很大的发展。
杂志下载，请访问：
敏捷之道第一期
鉴于产品开发目的的不同，微软永远不可能与开源社区走到同一条道路上来，但并不排斥双方有合作的可能。然而，让我们感到奇怪的是，一直以来微软对于开源的态度始终让人捉摸不定，时而漠不关心，时而高调抨击，时而又主动示好。
目前，我们唯一可以肯定的是，微软不再视开源为洪水猛兽，甚至于一步一步的，微软也在亦步亦趋的踏入开源社区的领域，例如微软成立的开源实验室，公布 Windows和.NET Framework的部分源代码，以及成立类似于SourceForge的开源网站CodePlex。分析动机，有业内专家指出，微软真正关心的的问题不是一个公司是否是开源性质，而是这个公司是否可以帮助销售微软的平台产品。真是一语道破天机！商业利益是凌驾于一切之上的。
我们观微软的态度，已经有了与开源和睦相处的苗头。那么，微软对于开源项目，尤其是对于开源的.NET项目究竟保有怎样的态度呢？最近，Redmond Developer News的编辑Michael Desmond就提出了这样一个疑问，那就是：开源.NET项目是否受到微软的冷遇？
文章提到了Redmond在去年六月对Jeff Atwood的专访。Jeff是Coding Horror Developer Blog的创始人，他对.NET领域的开源项目贡献良多，除了进行博客创作之外，同时还创建了自己的开源项目Stackoverflow.com。
Jeff在Coding Horror Developer Blog上曾经承诺，会将广告收入的一部分回赠给开源社区。近日，Jeff兑现了他的这一承诺，将5000美元的奖金颁发给了ScrewTurn Wiki开源项目的开发者Dario Solera。ScrewTurn Wiki是一个基于ASP.NET的Wiki引擎。实际上，奖励仅仅表明了Jeff的一种态度，那就是感谢那些为.NET开源开发领域作出卓越贡献的开发者们。
这正是Jeff举措的关键目的。Jeff认为“开源项目在微软体系中被当成了二等公民。”他说道：“微软错误地降低了对开源项目的支持，而事实上这些开源项目对.NET世界贡献良多。”他相信微软作为开发工具的提供商，其命运取决于公司是否愿意改变其一贯的做法。
Jeff的观点颇具争议性。实际上，在全球的.NET开发人员中，有很多都使用了各种开源工具，例如DotNetNuke、MbUnit、NAnt、 NHibernate和ZedGraph。而开发人员使用的.NET开源工具还有很多，以上列出的仅仅是冰山一角而已。微软也正在积极地参与和响应与开源社区（CodePlex、IronPython和IronRuby项目、Mono开发等）的合作。
那么，开源.NET项目的开发者们为何没有切实感受到微软对他们的支持呢？
确实，微软虽然在自己的开发工具中集成了部分优秀的开源.NET工具，但这些工具终究是凤毛麟角。此外，微软虽然对开源项目提供了一定的支持，但这种支持与微软对其商业产品的庞大投入相比，实在是九牛一毛。
很多时候，微软表面上对开源社区的支持，实质上却是醉翁之意不在于酒。例如，微软在四月初发布了与开源兼容的XAML/WPF规范，允许开源项目使用这些规范。这或许是微软的示好之举，对于开源开发起到了一定的促进作用，但此举的背后却代表着微软可以借助开源的东风进一步推广WPF与XAML。
微软对开源.NET项目确实提供了一定的支持，但很多时候，微软却是以其强势地位对开源项目给与了沉重的打击。例如微软于去年推出的MVC Framework以及LINQ，它确实为.NET开发者带来了极大的便利。但随之而来的，却极大地影响了Castel MVC Framework以及NHibernate的发展。显然，集成在Visual Studio中，并作为.NET Framework一部分的MVC Framework和LINQ对于普通的.NET开发人员而言，更具有吸引力。但对于开源社区而言，却是极大的挫败。
显然，Michael Desmond提出的所谓“开源.NET项目遭遇微软冷遇”的观点是站不住脚的。微软不可能忽视开源社区的力量。相反，微软会极度关注开源社区的发展，一旦意识到某个开源项目的商业价值，或者感觉到它对微软产品的威胁，微软这头猛兽就会主动出击，或者吞并蚕食，或者打造利器与之分庭抗礼，进而掠夺市场占有率。这是微软的一贯伎俩，因为微软在面对商业竞争时，永远都不会坐以待毙。
本文最初发表于
IT168。
几天前，
InfoQ发表了文章《
给敏捷团队发奖金就像在刀尖上跳舞》，单从标题就可以看出其中的“惊心动魄”，显然我们需要高超的技艺，以及皮粗肉糙的脚底，就像某些非洲土著那样，方才能够游刃有余地舞动在刀尖之上。
确实如此，通过发奖金的形式来激励团队成员，本身就是一把双刃剑，弄得不好，可能就会破坏团结，导致彼此之间的矛盾与冲突，这对于一个团队而言是绝对致命的。然而，如果一个团队缺乏合理的激励方式，又无法调动成员的积极性。如何取舍，真是伤透脑筋。
现在，让我们思考一个场景。项目成功结束了，要奖励整个团队与团队成员所付出的艰辛吗？当然要，那么应该如何奖励，才能在避免吃大锅饭的情况下，既能避免团队成员之间不必要的勾心斗角，又能最大程度地激励成员的工作热情，从而皆大欢喜呢？从玩具到游戏，我的思考是抛开传统的奖金策略，采用如下的另类激励机制：
1、“技术玩具”
2、小礼品
3、自由控制的时间
4、教育与培训机会
5、选择团队成员的权利
6、开发游戏
适当的奖励可以让我们踢开刀刃，自在轻舞，但必须还要谨记如下两个原则：
1、在奖励优秀的开发人员的同时，不要忘记对优秀团队的奖励；
2、奖励方式应因人而异，必须最大程度地投合员工的喜好。
更多内容，敬请阅读
捷道·敏捷堂发表的我的文章《
从玩具到游戏，另类的项目激励机制》
博客园自从建站开始没有多久，我就成为了其中的一员，说句毫不谦虚地话，我可以算是博客园的元老了。数载春秋，博客园在不断的壮大与成长，随之相伴的是我的成长与发展。在这期间，博客园为我们创造了无数多的价值。所谓“滴水之恩，当涌泉相报”，不过，我却不知道各位园友是否体会到了这些价值？突发奇想，想问问大家，博客园为你带来了什么价值？
我想先说说自己，若以重要程度排序，依次是：
1、提高了自己的技术水平；
2、认识了许多朋友；
3、开阔了自己的视野；
4、有了自己的技术积累，出了书，翻译了书，也算是出了名；
5、当上了微软的MVP，这得益于博客园；
6、是自己的资料库后备，需要解决问题的时候，可以看看博客园。
那么，你呢？
摘要: 学习WCF已有近两年的时间，其间又翻译了Juval的大作《Programming WCF Services》，我仍然觉得WCF还有更多的内容值得探索与挖掘。学得越多，反而越发觉得自己所知太少，直到现在，我也认为自己不过是初窥WCF的门径而已。“学以致用”，如果仅仅是希望能够在项目中合理地应用WCF，那么对于程序员而言，可以有两种选择，一种是“知其然而不知其所以然”，只要掌握了WCF的基础知识，那么...
阅读全文